DRIP Entity Tag (DET) for Unmanned Aircraft System Remote Identification (UAS RID)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 April 2022.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

2. Terms and Definitions

3. The Hierarchical Host Identity Tag (HHIT)

The Hierarchical HIT (HHIT) is a small but important enhancement over the flat HIT space. By adding two levels of hierarchical administration control, the HHIT provides for device registration/ownership, thereby enhancing the trust framework for HITs.¶

HHITs represent the HI in only a 64 bit hash and uses the other 32 bits to create a hierarchical administration organization for HIT domains. Hierarchical HIT construction is defined in Section 3.5. The input values for the Encoding rules are in Section 3.5.1.¶

A HHIT is built from the following fields:¶

• IANA prefix (max 28 bit)¶
• 32 bit Hierarchy ID (HID)¶
• 4 (or 8) bit HIT Suite ID¶
• ORCHID hash (96 - prefix length - Suite ID length bits, e.g. 64) See Section 3.5¶

The Context ID for the ORCHID hash is:¶

    Context ID :=  0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40

A python script is available for generating HHITs [hhit-gen].¶

     HIT Suite             Four-bit ID    Eight-bit encoding
     HDA Assigned 1            NA         TBD3 (suggested value 0x0E)
     HDA Assigned 2            NA         TBD4 (suggested value 0x0F)

100.hhit.arpa   IN PTR      raa.bar.com.

     Algorithm
     profiles    Values

     EdDSA       TBD1 (suggested value 13) [RFC8032]    (RECOMMENDED)

     Algorithm    Curve            Values

     EdDSA        RESERVED         0
     EdDSA        EdDSA25519       1 [RFC8032]
     EdDSA        EdDSA25519ph     2 [RFC8032]
     EdDSA        EdDSA448         3 [RFC8032]
     EdDSA        EdDSA448ph       4 [RFC8032]

     HIT Suite        4-bit ID                   8-bit encoding
     RESERVED         0                          0x00
     EdDSA/cSHAKE128  TBD2 (suggested value 5)   0x50   (RECOMMENDED)

ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )

where:

Prefix          : A constant 28-bit-long bitstring value
                  (IANA IPv6 assigned).

OGA ID          : A 4-bit long identifier for the Hash_function
                  in use within the specific usage context.  When
                  used for HIT generation this is the HIT Suite ID.

Encode_96( )    : An extraction function in which output is obtained
                  by extracting the middle 96-bit-long bitstring
                  from the argument bitstring.

ORCHID     :=  Prefix (p) | Info (n) | OGA ID (o) | Hash (m)

where:

Prefix (p)      : An IANA IPv6 assigned prefix (max 28-bit-long).

Info (n)        : n bits of information that define a use of the
                  ORCHID.  n can be zero, that is no additional
                  information.

OGA ID (o)      : A 4 or 8 bit long identifier for the Hash_function
                  in use within the specific usage context.  When
                  used for HIT generation this is the HIT Suite ID.

Hash (m)        : An extraction function in which output is m bits.

p + n + o + m = 128 bits

    cSHAKE128(Input, L, "", Context ID)

    Input      :=  Prefix | Additional Information | OGA ID | HOST_ID
    L          :=  Length in bits of hash portion of ORCHID

    Hash[L](Context ID | Input)

    Input      :=  Prefix | Additional Information | OGA ID | HOST_ID
    L          :=  Length in bits of hash portion of ORCHID

    Hash[L]    :=  An extraction function in which output is obtained
                   by extracting the middle L-bit-long bitstring
                   from the argument bitstring.

    Hash[L](Context ID | Input)

    Input      :=  HOST_ID
    L          :=  96
    Context ID :=  0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

    Hash[L]    :=  An extraction function in which output is obtained
                   by extracting the middle L-bit-long bitstring
                   from the argument bitstring.

    Hash[L](Context ID | Input)

    Input      :=  HOST_ID
    L          :=  96
    Context ID :=  0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA

    Hash[L]    :=  The L bit output from the hash function

    Prefix | OGA ID | Hash Output

4. Hierarchical HITs as Remote ID DRIP Entity Tags (DET)

Hierarchical HITs are a refinement on the Host Identity Tag (HIT) of HIPv2 [RFC7401]. HHITs require a new Overlay Routable Cryptographic Hash Identifier (ORCHID [RFC7343]) mechanism as described in Section 3.5. HHITs for UAS ID (DET) also use the new EdDSA/SHAKE128 HIT suite defined in Section 3.4 (GEN-2 in [drip-requirements]). This hierarchy, cryptographically embedded within the HHIT, provides the information for finding the UA's HHIT registry (ID-3 in [drip-requirements]).¶

TYPE-1

A static, manufacturer assigned, hardware serial number per ANSI/CTA-2063-A "Small Unmanned Aerial System Serial Numbers" [CTA2063A].¶

TYPE-2

A CAA assigned (presumably static) ID.¶

TYPE-3

A UTM system assigned UUID [RFC4122]. These can be dynamic, but do not need to be.¶

For HHITs to be used effectively as UAS IDs, F3411 should add UAS ID type 4 as DET.¶

Serial Number   :=  MFR Code | Length Code | MFR SN

where:

MFR Code        : 4 character code assigned by ICAO.

Length Code     : 1 character Hex encoding of MFR SN length (1-F).

MFR SN          : Alphanumeric code (0-9, A-Z except O and I).
                  Maximum length of 15 characters.

    8653FZ2T7B8RA85D19LX

5. DRIP Entity Tags (DET) in DNS

There are two approaches for storing and retrieving the DET using DNS. These are:¶

• As FQDNs in the .aero TLD.¶
• Reverse DNS lookups as IPv6 addresses per [RFC8005].¶

A DET can be used to construct an FQDN that points to the USS that has the Public/Private information for the UA (REG-1 and REG-2 in [drip-requirements]). For example, the USS for the HHIT could be found via the following: Assume the RAA is 100 and the HDA is 50. The PTR record is constructed as:¶

    100.50.det.uas.aero   IN PTR      foo.uss.aero.

The individual DETs are potentially too numerous (e.g. 60 - 600M) and dynamic (new DETs every minute for some HDAs) to actually store in a signed, DNS zone. The HDA SHOULD provide DNS service for its zone and provide the HHIT detail response. A secure connection (e.g. DNS over TLS) to the authoritative zone may be a viable alternative to DNSSEC.¶

The DET reverse lookup can be a standard IPv6 reverse look up, or it can leverage off the HHIT structure. Assume a prefix of 2001:30::/28, the RAA is 10 and the HDA is 20 and the DET is:¶

    2001:30:a0:145:a3ad:1952:ad0:a69e

A DET reverse lookup could be to:¶

    a69e.ad0.1952.a3ad.145.a0.30.2001.20.10.det.arpa.

A 'standard' ip6.arpa RR has the advantage of only one Registry service supported.¶

    $ORIGIN  5.4.1.0.0.a.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
    e.9.6.a.0.d.a.0.2.5.9.1.d.a.3.a    IN   PTR

6. Other UTM uses of HHITs beyond DET

HHITs might be used within the UTM architecture beyond DET (and USS in UA ID registration and authentication). This includes a GCS HHIT ID. The GCS may use its HIIT if it is the source of Network Remote ID for securing the transport and for secure C2 transport (e.g. [drip-secure-nrid-c2]).¶

Observers may have their own HHITs to facilitate UAS information retrieval (e.g., for authorization to private UAS data). They could also use their HHIT for establishing a HIP connection with the UA Pilot for direct communications per authorization (this use is currently outside the scope). Further, they can be used by FINDER observers, (e.g. [crowd-sourced-rid]).¶

7. DRIP Requirements addressed

This document in the previous sections provides the details to solutions for GEN 1 - 3, ID 1 - 5, and REG 1 - 2 as describled in [drip-requirements].¶

8. DET Privacy

There is no expectation of privacy for DETs; it is not part of the Privacy Normative Requirements, Section 4.3.1, of [drip-requirements]. DETs are broadcast in the clear over the open air via Bluetooth and WiFi. They will be collected and collated with other public information about the UAS. This will include DET registration information and location and times of operations for a DET. A DET can be for the life of a UA if there is no concern about DET/UA activity harvesting.¶

Further, the MAC address of the wireless interface used for Remote ID broadcasts are a target for UA operation aggregation that may not be mitigated through address randomization. For Bluetooth 4 Remote ID messaging, the MAC address is used by observers to link the Basic Message that contains the RID with other Remote ID messages, thus must be constant for a UA operation. This message linkage use of MAC addresses may not be needed with the Bluetooth 5 or WiFi PHYs. These PHYs provide for a larger message payload and can use the Message Pack (Msg Type 0xF) and the Authentication Message to transmit the RID with other Remote ID messages. However it is not manditory to send the RID in a Message Pack or Authentication Message, so allowance for using the MAC address for UA message linking must be maintained. That is, the MAC address should be stable for at least a UA operation.¶

Finally, it is not adequate to simply change the DET and MAC for a UA per operation to defeat historically tracking a UA's activity.¶

Any changes to the UA MAC may have impacts to C2 setup and use. A constant GCS MAC may well defeat any privacy gains in UA MAC and RID changes. UA/GCS binding is complicated with changing MAC addresses; historically UAS design assumed these to be "forever" and made setup a one-time process. Additionally, if IP is used for C2, a changing MAC may mean a changing IP address to further impact the UAS bindings. Finally an encryption wrapper's identifier (such as ESP [RFC4303] SPI) would need to change per operation to insure operation tracking separation.¶

Creating and maintaining UAS operational privacy is a multifaceted problem. Many communication pieces need to be considered to truly create a separation between UA operations. Simply changing the UAS RID only starts the changes that need to be implemented.¶

9. ASTM Considerations

ASTM will need to make the following additional value to the "UA ID" in the Basic Message (Msg Type 0x0):¶

Type 4:

This document UA ID of DRIP Entity Tags, DET (see Section 4).¶

The DET authors will participate in ASTM to enact this change.¶

10. IANA Considerations

This document requests IANA to make the following changes to the IANA "Host Identity Protocol (HIP) Parameters" registry:¶

Host ID:

This document defines the new EdDSA Host ID with value TBD1 (suggested: 13) (see Section 3.4.1) in the "HI Algorithm" subregistry of the "Host Identity Protocol (HIP) Parameters" registry.¶

EdDSA Curve Label:

This document specifies a new algorithm-specific subregistry named "EdDSA Curve Label". The values for this subregistry are defined in Section 3.4.1.¶

HIT Suite ID:

This document defines the new HIT Suite of EdDSA/cSHAKE with value TBD2 (suggested: 5) (see Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry.¶

HIT Suite ID eight-bit encoding:

This document defines the first eight-bit encoded HIT Suite IDs as defined in Section 5.2.10 of [RFC7401]. These are the new HDA domain HIT Suites with values TBD3 and TBD4 (suggested: 0x0E and 0x0F) (see Section 3.2.1). IANA is requested to expand the "HIT Suite ID" subregistry of the "Host Identity Protocol (HIP) Parameters" registry to show both the four-bit and eight-bit values as shown in Section 5.2.10 of [RFC7401] and add these new values that only have eight bit representations.¶

11. Security Considerations

The 64-bit hash in HHITs presents a real risk of second pre-image cryptographic hash attack Section 11.2. There are no known (to the authors) studies of hash size to cryptographic hash attacks. A PYTHON script is available to randomly generate 1M HHITs that did not produce a hash collision which is a simpler attack than a first or second pre-image attack.¶

However, with today's computing power, producing 2^64 EdDSA keypairs and then generating the corresponding HHIT is economically feasible. Consider that a *single* bitcoin mining ASIC can do on the order of 2^46 sha256 hashes a second or about 2^62 hashes in a single day. The point being, 2^64 is not prohibitive, especially as this can be done in parallel.¶

Now it should be noted that the 2^64 attempts is for stealing a *specific* HHIT. Say there are roughly 1,024 HHITs for which you'd be happy stealing any one of. Then rather trying to satisfy a 64-bit condition on the cSHAKE128 output, you need only satisfy a 54-bit condition (since you have 2^10 more opportunities for success).¶

Thus, although the PROBABILITY of a collision or pre-image attack is low Section 11.2 in a collection of 1,024 HHITs out of a total population of 2^64, it is computationally and economically feasible. Thus the HHIT registration and HHIT/HI registration validation is STRONGLY recommended.¶

The DET Registry services effectively block attempts to "take over" or "hijack" a DET. It does not stop a rogue attempting to impersonate a known DET. This attack can be mitigated by the receiver of the DET using DNS to find the HI for the DET. As such, use of DNSSEC and DNS over TLS by the DET registries is recommended.¶

The 60 bit hash for DETs with 8 bit OGAs have a greater hash attack risk. As such its use should be restricted to testing and to small, well managed UAS/USS.¶

Another mitigation of HHIT hijacking is if the HI owner (UA) supplies an object containing the HHIT and signed by the HI private key of the HDA such as Appendix B.1 as discussed in Section 4.6.¶

The two risks with hierarchical HITs are the use of an invalid HID and forced HIT collisions. The use of a DNS zone (e.g. "det.arpa.") is a strong protection against invalid HIDs. Querying an HDA's RVS for a HIT under the HDA protects against talking to unregistered clients. The Registry service [drip-registries], through its HHIT uniqueness enforcement, provides against forced or accidental HHIT hash collisions.¶

Cryptographically Generated Addresses (CGAs) provide an assurance of uniqueness. This is two-fold. The address (in this case the UAS ID) is a hash of a public key and a Registry hierarchy naming. Collision resistance (more important that it implied second-preimage resistance) makes it statistically challenging to attacks. A registration process ([drip-registries]) within the HDA provides a level of assured uniqueness unattainable without mirroring this approach.¶

The second aspect of assured uniqueness is the digital signing (attestation) process of the DET by the HI private key and the further signing (attestation) of the HI public key by the Registry's key. This completes the ownership process. The observer at this point does not know WHAT owns the DET, but is assured, other than the risk of theft of the HI private key, that this UAS ID is owned by something and is properly registered.¶

Appendix A. EU U-Space RID Privacy Considerations

EU is defining a future of airspace management known as U-space within the Single European Sky ATM Research (SESAR) undertaking. Concept of Operation for EuRopean UTM Systems (CORUS) project proposed low-level Concept of Operations [corus] for UAS in EU. It introduces strong requirements for UAS privacy based on European GDPR regulations. It suggests that UAs are identified with agnostic IDs, with no information about UA type, the operators or flight trajectory. Only authorized persons should be able to query the details of the flight with a record of access.¶

Due to the high privacy requirements, a casual observer can only query U-space if it is aware of a UA seen in a certain area. A general observer can use a public U-space portal to query UA details based on the UA transmitted "Remote identification" signal. Direct remote identification (DRID) is based on a signal transmitted by the UA directly. Network remote identification (NRID) is only possible for UAs being tracked by U-Space and is based on the matching the current UA position to one of the tracks.¶

The project lists "E-Identification" and "E-Registrations" services as to be developed. These services can follow the privacy mechanism proposed in this document. If an "agnostic ID" above refers to a completely random identifier, it creates a problem with identity resolution and detection of misuse. On the other hand, a classical HIT has a flat structure which makes its resolution difficult. The Hierarchical HITs provide a balanced solution by associating a registry with the UA identifier. This is not likely to cause a major conflict with U-space privacy requirements, as the registries are typically few at a country level (e.g. civil personal, military, law enforcement, or commercial).¶

Appendix B. Example HHIT Self Attestation

This section shows example uses of HHIT RID to prove trustworthiness of the RID and attestation of registration to the RAA|HDA. These are examples only and other documents will provide fully specified attestations. Care has been taken in the example design to minimize the risk of replay attacks.¶

This ownership/attestation of a HHIT can be proved in 84 bytes via the following HHIT Self Attestation following [drip-authentication] format:¶

• 4 byte Signing Timestamp¶
• 16 byte HHIT¶
• 64 byte Signature (EdDSA25519 signature)¶

The Timestamp MAY be the standard UNIX time at the time of signing. A protocol specific timestamp may be used to avoid programming complexities. For example, [F3411-19] uses a 00:00:00 01/01/2019 offset.¶

To minimize the risk of replay, the UA SHOULD create a new Self Attestation, with a new timestamp, at least once a minute. The UA MAY precompute these attestations and transmit during the appropriate 1 minute window. 1 minute is chosen as a balance between attestation compute time against risk. A shorter window of use lessens the risk of replay.¶

The signature is over the 20 byte Timestamp + HHIT.¶

The receiver of such an attestation would need access to the underlying public key (HI) to validate the signature. This may be obtained via a DNS query using the HHIT. A larger (116 bytes) Self Attestation could include the EdDSA25519 HI. This larger 116 attestation allows for signature validation before HHIT lookup to prove registration attestation.¶

Appendix C. Calculating Collision Probabilities

The accepted formula for calculating the probability of a collision is:¶

    p = 1 - e^{-k^2/(2n)}


    P   Collision Probability
    n   Total possible population
    k   Actual population

The following table provides the approximate population size for a collision for a given total population.¶

                       Deployed Population
     Total            With Collision Risk of
     Population         .01%            1%

     2^96                 4T           42T
     2^72                 1B           10B
     2^68               250M          2.5B
     2^64                66M          663M
     2^60                16M          160M

Authors' Addresses