[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!
- [CFRG] 16 byte signature Robert Moskowitz
- Re: [CFRG] 16 byte signature Natanael
- Re: [CFRG] 16 byte signature Robert Moskowitz
- Re: [CFRG] 16 byte signature Dan Collins
- Re: [CFRG] 16 byte signature Natanael
- Re: [CFRG] 16 byte signature Robert Moskowitz