DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)
Extracted elements (30)
Hash algorithm selection for the Manifest is tied to the HHIT Suite ID of the signing DET: cSHAKE128 DETs compute cSHAKE128(ASTM Message, 64, "", "Remote ID Auth Hash") while ECDSA/SHA-384 DETs use a left-truncated SHA-384. This keeps cryptographic agility aligned with the DET's own algorithm negotiation rather than introducing a separate negotiation.
Legacy Transports (Bluetooth 4.x) lack lower-layer FEC and use one-way RF broadcasts that prohibit ACK/NACK-based loss recovery. DRIP therefore defines an application-level single-page XOR parity scheme, placed in the Additional Data field outside the signed payload, to enable recovery of a single erased Authentication Page without requiring interactive protocols.
The DRIP Wrapper over Extended Transports clears the Evidence field after signing and relies on co-located ASTM Message Pack content for verification. This approach is functionally equivalent to ASTM Authentication Type 0x3 (Message Set Signature) but avoids dependence on the ASTM validator system architecture, which requires Internet connectivity that offline Observers may not have.
The Manifest includes both Previous and Current Manifest Hash fields to create an auditable ledger of provenance. The DRIP Link (BE:HDA,UA) hash is included so there is a direct signature by the UA over the Broadcast Endorsement, preventing trivial replay attacks by tying every Manifest to the endorsed UA keypair.
Because DRIP-unaware Observers may not process Authentication Messages, DRIP Wrapper messages must be sent in addition to (not in place of) the original ASTM Messages they encapsulate. Wrapped messages are effectively sent twice: once in the clear per F3411 requirements and once authenticated within the Wrapper.
A UA MUST: send DRIP Link using BE: Apex, RAA at least once per 5 minutes; send DRIP Link using BE: RAA, HDA at least once per 5 minutes; send DRIP Link using BE: HDA, UA at least once per minute; and send any non-DRIP-Link DRIP Authentication Format with dynamically signed unique, unpredictable data at least once per 5 seconds.
DRIP Link MUST NOT use the UA-Signed Evidence Structure, as it will not fit in the ASTM Authentication Message with the intended content of a Broadcast Endorsement.
DRIP transmitters are REQUIRED to fit Authentication Data / Signature data within the first 9 pages (Page Numbers 0 through 8), and the Length field MUST NOT exceed 201 octets. This constraint ensures consistent formatting across both Legacy and Extended Transports.
DRIP Wrappers MUST be sent in addition to any required ASTM Messages in a given jurisdiction. An implementation MUST NOT send DRIP Wrappers in place of any required ASTM Messages it may encapsulate, resulting in wrapped messages being transmitted twice.
Observers MUST hash all received ASTM Messages and cross-check them against hashes in received Manifests. At least one ASTM Message Hash in a Manifest MUST be from an F3411 message containing nonce-like data to prevent replay attacks.
Observers MUST validate all signatures received, which requires the Host Identity (HI) to correspond to a DET. HIs MAY be retrieved from a local cache if present; the cache is pre-configured with well-known HIs and further populated by received Broadcast Endorsements and DNS lookups.
The Observer MUST perform a DNS query, when connectivity allows, to obtain a previously unknown Host Identity. If a query cannot be performed, the message SHOULD be cached by the Observer to be validated once the HI is obtained.
The Observer MUST perform validation of the data being received in Broadcast RID. When correlation of different data streams does not match within acceptable thresholds, the data MUST be rejected as if the signature failed to validate.
The same application-layer information defined in F3411 MUST be transmitted over all physical-layer interfaces performing RID, because Observer transports may be limited. If an Observer can support multiple transports, it should use the latest data regardless of transport.
To prove possession of the private key associated with the DET, the UA MUST sign and send data that is unique and unpredictable but easily validated by the Observer. Verification of this signed data MUST be performed by the Observer as part of the received UAS RID information trust assessment.
When sending data over a medium that does not have underlying FEC (e.g., Legacy Transports such as Bluetooth 4.x), FEC per Section 5 MUST be used. FEC MUST NOT be used in Message Packs sent over Extended Transports, as those already provide lower-layer FEC.
DRIP defines four SAM Types within ASTM Authentication Type 0x5 (Specific Authentication Method): DRIP Link (0x01) for Broadcast Endorsements, DRIP Wrapper (0x02) for signing full ASTM Messages, DRIP Manifest (0x03) for hashes of ASTM Messages, and DRIP Frame (0x04) for future extensibility.
The DRIP Manifest creates a signed ledger of hashes of previously sent ASTM Messages, enabling retrospective authentication without retransmission. The three mandatory header hashes (Previous Manifest, Current Manifest, and DRIP Link BE:HDA,UA) establish chain-of-custody and tie the endorsed UA key to the Manifest chain.
IANA created the 'DRIP Frame Types' registry within the 'Drone Remote ID Protocol' registry group. Values 0x01–0x9F use Expert Review, 0xA0–0xEF use First Come First Served, and 0xF0–0xFF are reserved for Experimental Use. Registration requests are reviewed at [email protected] within a three-week period.
IANA created the 'DRIP SAM Types' registry within the 'Drone Remote ID Protocol' registry group as a mirror of ASTM allocations. New additions require Standards Action coordinated with ICAO as ASTM's designated registrar. Values 0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest), and 0x04 (DRIP Frame) are allocated to IETF.
DRIP depends on DNS for key retrieval, but specification of particular DNS security options and transports is out of scope for this document. The DRIP-REG specification will define applicable best common security practices such as DNSSEC per RFC 9364, given that many participating nodes have limited processing power and poor QoS paths.
F3411 lacks replay protection. DRIP mitigates replay attacks by requiring Observers to verify a chain of DRIP Links and then verify that a Wrapper or Manifest authenticates nonce-like data (unique, frequently changing, easily validated content such as a Location/Vector Message), confirming the sender possesses the private key corresponding to the claimed DET.
The VNA Timestamp offset for UA-signed messages should be shorter than any flight duration (under one hour) but long enough for Observers to process messages (more than a few seconds). An offset of approximately 2–5 minutes is recommended for typical UA scenarios as of 2024; DRIP Link VNA offsets are determined by the DIME and addressed in DRIP-REG.
Wrapper provides an attached signature over full F3411 message content (up to 4 messages) but cannot directly bind to the trust chain. Manifest explicitly binds to the trust chain via the BE:HDA,UA hash and supports up to 11 messages but imposes Observer overhead to store and compare received message hashes. Manifests produce 25 total frames vs. 36 for Wrappers in typical operation.
DRIP defines nine Observer authentication states: None (Black, no auth received), Partial (Gray, missing pages), Unsupported (Brown, unknown SAM Type), Unverifiable (Yellow, missing public key), Verified (Green, valid signature and content validation), Trusted (Blue, Verified with vetted DIME chain), Questionable (Orange, mixed Verified/Unverified), Unverified (Red, failed), and Conflicting (Purple, mixed Trusted/Unverified). States transition based on signature outcomes and DIME trust policy.
FEC encoding places XOR parity data (always 23 octets) in the Additional Data field, aligned to start on a new Authentication Page via null padding. The ADL field is set to the number of padding octets plus 23 parity octets. The Last Page Index is incremented by the number of additional pages required.
The DRIP Frame format contains a 1-octet Frame Type field followed by up to 111 octets of Frame Evidence Data, all encapsulated in the UA-Signed Evidence Structure. At publication only an Experimental range (0xF0–0xFF) is defined; Frame Type content is left to future specifications.
The DRIP Link format contains: VNB Timestamp by Parent (4 octets), VNA Timestamp by Parent (4 octets), DET of Child (16 octets), HI of Child (32 octets), DET of Parent (16 octets), and Signature by Parent (64 octets over all preceding fields using the Parent DET keypair).
The DRIP Manifest Evidence field begins with three mandatory 8-octet hashes (Previous Manifest Hash, Current Manifest Hash, and DRIP Link BE:HDA,UA Hash) followed by up to 11 ASTM Message Hashes of 8 octets each. A maximum of 10 ASTM Message Hashes is RECOMMENDED.
The UA-Signed Evidence Structure contains: VNB Timestamp (4 octets), VNA Timestamp (4 octets), Evidence (0–112 octets, format defined by enclosing SAM Type), UA DRIP Entity Tag (16 octets), and UA Signature (64 octets over preceding fields using the UA DET keypair).