Subject: [Drip] Encoding HHIT as CTA-2063-A serial numbers for RemoteID Broadcast Modules

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Jan 2021 08:58:49 -0500

In the FAA Remote ID final rules, the Remote ID Broadcast Module is 
generally defined.  This module is intended to provide Remote ID 
functionality for UA that don't have it built in.  But there are limits 
imposed on these modules.

A big limitation is they are NOT allowed to use Session IDs (like HHITs) 
only the "serial number of the module".

The FAA says:

The FAA adopts the use of the ANSI/CTA-2063-A standard because using a 
single accepted format for serial numbers helps ensure consistency in 
the broadcast of the message element.

====================

It is not so easy to map the 16 byte HHIT into the 20 character 2063-A 
serial number.

The serial number consists of 3 fields:

MC - Manufacturer Code (maintained by ICAO) of 4 characters.
L - Length Code of 1 character of values 1 - F.
MSN - Manufacturer's Serial Number of max 15 characters.

each character has 34 possible values.

There are 34^4 (1,336,336) possible Manufacturer Codes.  We would have 
to provide a MC - RAA|HDA mapping facility.  An Observer code get the 
mapping from some service (e.g. DNS) and optionally maintain a local 
cache (for disconnected use).  This lookup SHOULD also provide the HHIT 
IPv6 Prefix, as there MAY be more than one possible value (e.g. the ICAO 
GRAIN prefix for commercial UA operating under ICAO guidelines and on 
the GRAIN network).

The serious challenge comes in mapping the 2^4 valued HIT Suite ID and 
2^64 bit hash into the 15 MSN characters.

If we limit a character to 32 values, that is 2^5, or 13 characters can 
encode the hash and 1/2 a character the Suite ID. This leaves 1 1/2 
character for the Manufacturer to encode model numbers and other 
interesting bits of stuff.  Perhaps that is enough for Broadcast Module 
Manufacturers.

Or if we use all 34 possible values: 34^13 > 2^66 (8.11E19 > 7.38E19).  
So we can encode the hash and 4 Suite IDs into 13 characters, leaving a 
full 2 characters for the Manufacturer to encode model numbers and other 
interesting bits of stuff.  4 Suite IDs may be enough for the current 
EDDSA/SHAKE, a future EDDSA/LWC, and 2 PQ Suite IDs.

I lean toward the later approach.  A bit of code for en/decoding into 34 
values is small.  I did a generalized base conversion back in CPS301 in 
FORTRAN in '68.  Probably standard C code around someplace for this today.

Of course that fact that *I* was able to do this makes it easy in my 
view.  Others may be wiser than me!

This will go into the next version of the drip-rid draft and part of the 
drip-arch.

How this would work:

The Observer gets a Basic Message with a 2063 formatted RemoteID.  The 
MC is in the MC/RRA|HDA table.  The Observer decodes the RID into the 
underlying HHIT.  This HHIT is used by the UA in Authentication 
Messages, and the Observer is able to verify those messages.

Thoughts?  Opinions?

I will not be writing this up until next week.  I am attending the IACR 
Real World Crypto virtual conference in virtual Amsterdam this week.  
Last year I got the idea to create the crowd-sourced-rid design from the 
Apple "Find My" presentation. So far this year, I see changes I will 
have to make to that in the ECIES mode to mirror changes made in DTLS 
1.3 to mitigate a UDP attack...

See the "Robust Channels: Handling Unreliable Networks in the Record 
Layers of QUIC and DTLS 1.3" for the attack in question.

recording are on IACR's youtube channel.

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 12 Jan 2021 09:31:25 -0500

I am strongly in favor of prototyping, demonstrating & standardizing this.

I am weakly opposed to a 34 character encoding, which good programmers can
code, but others are likely to find confusing (making the whole scheme a
harder sell).

I am moderately opposed to giving ourselves room for only 4 HHIT Suite
indices, as cryptosystems inevitably are deprecated eventually (some after
a long useful life, some after a short one).

There are also some interesting possibilities depending on how
"manufacturer" is defined and whether re-manufacturing is allowed; FAA
language in the final rule about implementing a broadcast module via a
firmware update to the UA (rather than a strap-on puck) suggests this.

On Tue, Jan 12, 2021, 8:59 AM Robert Moskowitz <[email-masked]>
wrote:

> single accepted format for serial numbers helps ensure consistency in the
> broadcast of the message element.
>
> ====================
>
> There are 34^4 (1,336,336) possible Manufacturer Codes.  We would have to
> provide a MC - RAA|HDA mapping facility.  An Observer code get the mapping
> from some service (e.g. DNS) and optionally maintain a local cache (for
> disconnected use).  This lookup SHOULD also provide the HHIT IPv6 Prefix,
> as there MAY be more than one possible value (e.g. the ICAO GRAIN prefix
> for commercial UA operating under ICAO guidelines and on the GRAIN network).
>
> Or if we use all 34 possible values: 34^13 > 2^66 (8.11E19 > 7.38E19).  So
> we can encode the hash and 4 Suite IDs into 13 characters, leaving a full 2
> characters for the Manufacturer to encode model numbers and other
> The Observer gets a Basic Message with a 2063 formatted RemoteID.  The MC
> is in the MC/RRA|HDA table.  The Observer decodes the RID into the
> underlying HHIT.  This HHIT is used by the UA in Authentication Messages,
> and the Observer is able to verify those messages.
>
>
> Thoughts?  Opinions?
>
> Real World Crypto virtual conference in virtual Amsterdam this week.  Last
> year I got the idea to create the crowd-sourced-rid design from the Apple
> "Find My" presentation.  So far this year, I see changes I will have to
> make to that in the ECIES mode to mirror changes made in DTLS 1.3 to
> mitigate a UDP attack...
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 21 Jan 2021 09:35:11 -0500

Last week during IACR Real World Crypto conference, I spoke in a side 
chat with Brian Murry (I think) of Clover.  Clover makes credit card POS 
devices.  Within the credit card payment system, it seems, there is a 
Base36 encoding.  The ed/decoding works fast and easy to implement.  
However, it does not perform "to scale" on the massive database lookups 
needed in the credit card payment systems backends.  Brian said that 
they would have been better served and could have worked with a Base32 
encoding.

Now the backends (UTM/USS) here will probably not have to deal with the 
volumes seen in credit card systems.  But this is valuable advice from 
"been there, done that, and oops."

That said, when I get to updating drip-rid (only drip-arch in front of 
it) I will go with Base32.  I will also look at drip-arch and see if 
there should be a few words about HHITs encoded within CTA-2063-A serial 
numbers.

On 1/12/21 9:31 AM, Card, Stu wrote:
> I am weakly opposed to a 34 character encoding, which good programmers 
> can code, but others are likely to find confusing (making the whole 
> scheme a harder sell).
>
> indices, as cryptosystems inevitably are deprecated eventually (some 
> after a long useful life, some after a short one).
>
> On Tue, Jan 12, 2021, 8:59 AM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     In the FAA Remote ID final rules, the Remote ID Broadcast Module
>     is generally defined.  This module is intended to provide Remote
>     ID functionality for UA that don't have it built in.  But there
>     are limits imposed on these modules.
>
>     A big limitation is they are NOT allowed to use Session IDs (like
>     HHITs) only the "serial number of the module".
>
>     The FAA says:
>
>     The FAA adopts the use of the ANSI/CTA-2063-A standard because
>     using a single accepted format for serial numbers helps ensure
>     consistency in the broadcast of the message element.
>
>     ====================
>
>     It is not so easy to map the 16 byte HHIT into the 20 character
>     2063-A serial number.
>
>     There are 34^4 (1,336,336) possible Manufacturer Codes. We would
>     have to provide a MC - RAA|HDA mapping facility. An Observer code
>     get the mapping from some service (e.g. DNS) and optionally
>     maintain a local cache (for disconnected use).  This lookup SHOULD
>     also provide the HHIT IPv6 Prefix, as there MAY be more than one
>     possible value (e.g. the ICAO GRAIN prefix for commercial UA
>     operating under ICAO guidelines and on the GRAIN network).
>
>     The serious challenge comes in mapping the 2^4 valued HIT Suite ID
>     and 2^64 bit hash into the 15 MSN characters.
>
>     If we limit a character to 32 values, that is 2^5, or 13
>     characters can encode the hash and 1/2 a character the Suite ID. 
>     This leaves 1 1/2 character for the Manufacturer to encode model
>     numbers and other interesting bits of stuff.  Perhaps that is
>     enough for Broadcast Module Manufacturers.
>
>     Or if we use all 34 possible values: 34^13 > 2^66 (8.11E19 >
>     7.38E19).  So we can encode the hash and 4 Suite IDs into 13
>     characters, leaving a full 2 characters for the Manufacturer to
>     encode model numbers and other interesting bits of stuff.  4 Suite
>     IDs may be enough for the current EDDSA/SHAKE, a future EDDSA/LWC,
>     and 2 PQ Suite IDs.
>
>     I lean toward the later approach.  A bit of code for en/decoding
>     into 34 values is small.  I did a generalized base conversion back
>     in CPS301 in FORTRAN in '68.  Probably standard C code around
>     someplace for this today.
>
>     Of course that fact that *I* was able to do this makes it easy in
>     my view.  Others may be wiser than me!
>
>     This will go into the next version of the drip-rid draft and part
>     of the drip-arch.
>
>     How this would work:
>
>     The Observer gets a Basic Message with a 2063 formatted RemoteID. 
>     The MC is in the MC/RRA|HDA table.  The Observer decodes the RID
>     into the underlying HHIT.  This HHIT is used by the UA in
>     Authentication Messages, and the Observer is able to verify those
>     messages.
>
>
>     Thoughts?  Opinions?
>
>     I will not be writing this up until next week.  I am attending the
>     IACR Real World Crypto virtual conference in virtual Amsterdam
>     this week.  Last year I got the idea to create the
>     crowd-sourced-rid design from the Apple "Find My" presentation. 
>     So far this year, I see changes I will have to make to that in the
>     ECIES mode to mirror changes made in DTLS 1.3 to mitigate a UDP
>     attack...
>
>     See the "Robust Channels: Handling Unreliable Networks in the
>     Record Layers of QUIC and DTLS 1.3" for the attack in question.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>