DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)
updates
Extracted elements (31)
HHITs provide statistical uniqueness through second-preimage resistance combined with a mandatory registration process, which together enforce global uniqueness. This contrasts with UUIDs or X.509 subject names, where the same identifier can legitimately appear in multiple certificate authorities with no mechanism to enforce uniqueness of ownership.
ORCHIDv2 (RFC 7343) does not cryptographically bind the IPv6 prefix or OGA ID to the HI hash, because such attacks were considered DoS-only. HHITs bind all ORCHID content through the hash function, so a DET recipient with the underlying HI can directly trust and act on all fields, enabling self-claimed hierarchy discovery.
The HID was split into two equal 14-bit fields (RAA and HDA) rather than an asymmetric split. With 193 ICAO member states each potentially needing ~8 RAAs plus commercial allocations, 16,384 (2^14) RAAs was deemed adequate. Similarly, 16,384 HDAs per RAA provides sufficient space for large delivery service operators requiring millions of anti-tracking RIDs per year.
For ORCHIDv2 backward compatibility (RFC 7343/RFC 7401), ORCHID decoding is selected by the prefix: HITs use 2001:20::/28 with a 4-bit OGA ID and 96-bit hash, while HHITs use the HHIT-specific prefix (2001:30::/28) with an 8-bit OGA ID and 64-bit hash. The Prefix and OGA ID are NOT included in the hash input for HIPv2.
A HI and its DET SHOULD NOT be transferable between UAs or between replacement electronics. The private key for the HI SHOULD be held in a cryptographically secure component to preserve the binding between the UA and its identifier.
A mapping service (e.g., DNS) MUST provide a trusted (e.g., via DNSSEC) conversion of the 4-character CTA 2063-A Manufacturer Code to the high-order 58 bits (Prefix | HID) of the HHIT.
An RAA MUST provide services to allocate HDAs to organizations, and MUST at minimum maintain a DNS zone for HDA zone delegation for discovering HIP RVS servers. It SHOULD have a public policy on obtaining an HDA.
HHIT registration is a MUST, and HHIT/HI registration validation SHOULD be performed by Observers either through registry lookups or via broadcasted registration proofs, because 2^64 EdDSA keypair generation is computationally and economically feasible with current hardware.
The IPv6 HHIT prefix MUST be distinct from the flat-space HIT prefix (2001:20::/28) allocated in RFC 7343. Without a distinct prefix, the first 4 bits of the RAA would be misinterpreted as the HIT Suite ID by HIPv2.
The ORCHID length MUST be 128 bits. For HHITs with a 28-bit prefix, 8-bit OGA ID, and 28-bit HID, this leaves 64 bits for the hash; 64 bits is considered the minimum acceptable hash size given pre-image attack risks.
The MAC address of the wireless interface used for Broadcast Remote ID must remain stable for at least one UA operation, since Bluetooth 4 observers use it to link the Basic ID Message to other Remote ID messages. Changing DET and MAC per operation is insufficient to defeat UA tracking without also changing GCS MAC, IP addresses, and encryption wrapper identifiers.
There is no expectation of privacy for DETs. They are broadcast in the clear over Bluetooth and Wi-Fi and can be correlated with DET registration information and UA operational history. A DET may be persistent for the life of a UA if activity harvesting is not a concern.
A Hierarchical Host Identity Tag (HHIT) is a valid but non-routable IPv6 address that serves as a self-asserting identifier. When used for UAS Remote ID, HHITs are called DRIP Entity Tags (DETs). They encode an explicit administrative hierarchy in the ORCHID construction, enabling registry discovery via DNS or RDAP.
DETs can be stored in DNS either as FQDNs (e.g., "RAA.HDA.20010030.hhit.arpa.") or as standard IPv6 reverse lookups under ip6.arpa. The HDA SHOULD provide DNS service for its zone. The DNS entry can also serve as a DET revocation service by returning a revocation record instead of the HI RR.
The EdDSA/cSHAKE128 suite (HHIT Suite ID value 5) uses cSHAKE128 as the hash function with KMAC128 as the HMAC and EdDSA as the signature algorithm family. The cSHAKE128 output length is variable (at most 96 bits) and used directly in the ORCHID without truncation.
The HDA (HHIT Domain Authority) is a 14-bit field (16,384 HDAs per RAA) assigned by an RAA to entities such as ISPs or UAS Service Suppliers. HDAs must maintain public and private UAS registration information and should maintain RVS servers for HIP-enabled clients.
The HHIT Suite ID (HHSI) is an 8-bit value that specifies the HI and hash algorithms, and is a superset of the 4-bit and 8-bit HIT Suite IDs defined in RFC 7401. Values 1–31 map to existing HIT Suite IDs; values 32–255 are HHIT-specific. Values 254 and 255 are reserved for HDA Private Use.
The RAA (Registered Assigning Authority) is a 14-bit field (16,384 possible RAAs) identifying the business or organization managing a registry of HDAs, such as the FAA or JCAB. It forms the high-order half of the 28-bit Hierarchy ID.
The updated ORCHID construction is: Prefix (p bits, max 28) | Info (n bits) | OGA ID (4 or 8 bits) | Hash (m bits), where p+n+o+m = 128. The Info field carries the HHIT hierarchy bits (HID), and all fields are included in the cSHAKE128 hash input to protect against substitution attacks.
IANA created the "Drone Remote ID Protocol" registry group with two subregistries: HHIT Prefixes (Expert Review) and HHIT Suite IDs (IETF Review). Registration requests for HHIT Prefixes must be sent to [email protected] and decided within three weeks.
IANA has allocated the prefix 2001:30::/28 as the initial DET IPv6 prefix in the IANA IPv6 Special-Purpose Address Registry. This prefix is forwardable, globally reachable, and not reserved-by-protocol.
IANA updated the HIP Parameters registry to add: EdDSA Host ID algorithm (value 13), a new EdDSA Curve Label subregistry (IETF Review) with values for EdDSA25519, EdDSA25519ph, EdDSA448, and EdDSA448ph, and HIT Suite ID EdDSA/cSHAKE128 (value 5).
The HHIT Suite IDs subregistry defines an 8-bit value space: RESERVED (0), RSA,DSA/SHA-256 (1), ECDSA/SHA-384 (2), ECDSA_LOW/SHA-1 (3), EdDSA/cSHAKE128 (5), HDA Private Use 1 (254), HDA Private Use 2 (255). Values 1–31 MUST be replicated as HIT Suite IDs.
Post-quantum cryptography is explicitly out of scope for DRIP due to the severe message size constraints of UAS Broadcast Remote ID. Because a UA may use a unique DET per operation, the attack window is bounded by operation duration. The HHIT Suite ID field allows a future post-quantum algorithm to be added.
The 64-bit ORCHID hash size presents a real risk of second pre-image attack. A single bitcoin mining ASIC can perform approximately 2^62 SHA-256 hashes per day, making 2^64 EdDSA keypair generation feasible in parallel. For a fleet of 1,024 UAs, an attacker need only satisfy a 54-bit condition, further reducing difficulty.
The DET collision risk within a single RAA/HDA domain: there is a 0.01% probability of collision at a population of 66 million and a 1% probability at 663 million. The DET registration process MUST reject collisions, forcing the UAS to generate a new HI and reapply, which also defeats adversarial collision generation.
The DET in the ASTM Basic ID Message (Msg Type 0x0) provides no trust assertion; the 20-byte UA ID field cannot contain a full HHIT (16 bytes) plus a meaningful signature. A minimum of 88 bytes is required to prove ownership of a DET using a full EdDSA signature, which is only achievable via the ASTM Authentication Message (Msg Type 0x2).
The DET Registry blocks attempts to take over or hijack a DET, but does not prevent impersonation of a known DET by a rogue. Mitigation requires observers to use DNS to retrieve the HI for the DET; use of DNSSEC by DET registries is recommended. HDA-signed endorsements of the UA's HHIT provide an additional mitigation.
The 128-bit HHIT is composed of: a variable IPv6 prefix (max 28 bits), a 28-bit Hierarchy ID (HID) split into a 14-bit RAA and 14-bit HDA, an 8-bit HHIT Suite ID (HHSI), and a 64-bit ORCHID hash (when prefix is 28 bits). All fields are cryptographically bound through the cSHAKE128 hash.
The HIP HOST_ID parameter for EdDSA hosts contains a 16-bit EdDSA Curve label, a 16-bit NULL field, and the Public Key in octet-string format per RFC 8032. EdDSA25519 (value 1) and EdDSA448 (value 3) are RECOMMENDED curves.
When encoding a HHIT as a CTA 2063-A Serial Number, the low-order 72 bits (HHIT Suite ID | ORCHID hash) SHALL be left-padded with 3 zero bits to form a 75-bit number encoded into 15 characters using a custom Base32 alphabet (digits 0–9 and uppercase letters excluding O, I, Z, S). The manufacturer MUST use Length Code F (15).