Re: [CFRG] 16 byte signature

[Robert Moskowitz <[e-mail]>]

On 6/15/22 11:12, Dan Collins wrote:
> Rob,
>
> Can I ask where you're getting the 8 bytes per message from? If you're 
> replacing the 3 byte PI field, are you replacing it with a longer 
> field in order to fit the 11 bit counter and the 64 bit partial 
> signature? Or are you sending an additional message using one of the 
> reserved type codes?



The message is effectively 51-bits (lose 5 for the TC).  have an 11-bit 
minute counter to allow for one signed ICAO number per minute.  Enough 
for most RF coverage times.  This leaves 40-bits left for the other 5 bytes.

>
> Also - this may be relevant to the size of your counter as well as the 
> amount of space you have - the position and velocity fields are 
> already transmitted twice each per second while airborne. (Other 
> status and ID fields are transmitted at slower and variable rates.)

Yes.  To do an effective security over many messages, there would have 
to be what amounts to a signed hash-block on another channel. Much like 
the Manifest Authentication Message in draft-ietf-drip-auth for UAS 
Remote ID.

But the idea here is to have an occational proof of ICAO number 
message.  If such a thing is of interest remains to be seen.

Interesting thought process at least.

>
> Regards,
> Dan Collins
>
> On Wed, Jun 15, 2022 at 11:00 AM Robert Moskowitz 
> <[e-mail]> wrote:
>
>     BLS?
>
>
>     On 6/15/22 10:24, Natanael wrote:
>>
>>
>>     Den ons 15 juni 2022 15:52Robert Moskowitz
>>     <[e-mail]> skrev:
>>
>>         Manned Aviation's ADS-B (what Air Traffic Control and
>>         flightware.com <http://flightware.com>
>>         uses) is highly constrained:  112 bits!
>>
>>         https://mode-s.org/decode/content/ads-b/1-basics.html
>>
>>         Now aviation is looking at this oops design with only perhaps
>>         60%
>>         deployment (mostly in major flight areas).  It has been
>>         generally held
>>         that nothing can be done with this baby to secure it from
>>         spoofing
>>         attacks and the like, so I decided to play around.
>>
>>         Here is the frame format:
>>
>>         1–5        5     DF     Downlink Format
>>         6–8        3     CA     Transponder capability
>>         9–32      24     ICAO   ICAO aircraft address
>>         33–88     56     ME     Message, extended squitter
>>         (33–37)  (5)     (TC)   (Type code)
>>         89–112    24     PI     Parity/Interrogator ID
>>
>>
>>
>>         I have worked out a scheme where I could have 8 bytes per
>>         packet for
>>         some payload that is able to replace PI (e.g. a sig).  Since
>>         this is
>>         basically a static message, I put in a 1 min counter of 11
>>         bits and use
>>         a new key pair each day for 1440 signings of the Aircraft
>>         Address.
>>
>>         Can't do anything with 8 bytes, but 2 approaches for 16 bytes
>>         by using 2
>>         frames are possible.
>>
>>         So is there any signature 'safe' to use for 1440 (or 720)
>>         sigs of 16
>>         bytes length.  An attack would have to be during that 24 hour
>>         period (or
>>         12 hour) to spoof that an Aircraft Address is within RF range.
>>
>>         The actual keypairs can be of any practical length.
>>
>>         There would be a whole X.509 PKI behind this to manage the
>>         usage period
>>         of a keypair.
>>
>>         Not too concern about International Dateline crossings at
>>         this point!
>>
>>         BTW, where this is important, over major airports, the RF is
>>         already
>>         overused for various messaging, so adding 2 frames per
>>         aircraft per
>>         minute is possible, but there will be push back for more.
>>
>>         And to protect the 'real' ADS-B messages that actually have a
>>         message
>>         content could only be done via a back channel. And then you
>>         get into
>>         the ADS-C mess!
>>
>>
>>     BLS seems closest to plausible at a security level evaluated in
>>     bits estimated to half the signatures size, so at 16 bytes / 128
>>     bits you get 64 bits of security. It's absolutely on the low end,
>>     even smaller organizations are capable of breaking that in short
>>     time spans.
>>
>>     You'd have to have really fast key rotations, I'm talking about
>>     key lifetimes of under an hour even if you're optimistic. You
>>     might just even want to roll a new key for every broadcast. At
>>     that point verifiers would need to be online to retrieve the most
>>     recent signing key to confirm the message is both authentic and
>>     fresh. However, at that point with key rollovers that fast you
>>     may as well go for a symmetric authentication tag scheme and
>>     require a request to a trusted server to check validity of the
>>     message directly, rather than checking the public key.
>>
>>     There's another scheme that claims 80 bits of security at a
>>     signature length of 110 bits, so it fits in with a solid margin
>>     in the space available, however I hadn't even heard of it until I
>>     started looking today and I don't know if it has held up to
>>     cryptoanalysis;
>>
>>     https://eprint.iacr.org/2016/911
>>
>>     _______________________________________________
>>     CFRG mailing list
>>     [e-mail]
>>     https://www.irtf.org/mailman/listinfo/cfrg
>
>     _______________________________________________
>     CFRG mailing list
>     [e-mail]
>     https://www.irtf.org/mailman/listinfo/cfrg
>