[CFRG] 16 byte signature

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 15 June 2022 13:52 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC8C159482 for <cfrg@ietfa.amsl.com>; Wed, 15 Jun 2022 06:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWiEs1Ehn2Gb for <cfrg@ietfa.amsl.com>; Wed, 15 Jun 2022 06:52:25 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B435DC157B5E for <cfrg@ietf.org>; Wed, 15 Jun 2022 06:52:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0B8FC626A8 for <cfrg@ietf.org>; Wed, 15 Jun 2022 09:51:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PQ9WHae4cZ35 for <cfrg@ietf.org>; Wed, 15 Jun 2022 09:51:32 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5A8B66267D for <cfrg@ietf.org>; Wed, 15 Jun 2022 09:51:32 -0400 (EDT)
Message-ID: <701bdccc-c9d7-c4f6-900e-492233edab57@htt-consult.com>
Date: Wed, 15 Jun 2022 09:52:13 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
To: cfrg@ietf.org
Content-Language: en-US
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/p2_lUNBQTjCPOQ4I96MInKthDCU>
Subject: [CFRG] 16 byte signature
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 13:52:30 -0000

Manned Aviation's ADS-B (what Air Traffic Control and 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!