DRIP Authentication Formats
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
stu.card@axenterprize.com
HTT Consulting
Oak Park
MI
48237
USA
rgm@labs.htt-consult.com
Internet
DRIP
RFC
Request for Comments
I-D
Internet-Draft
HIP
DRIP
This document describes how to include trust into the ASTM
Remote ID specification defined in ASTM 3411-19
under a Broadcast Remote ID (RID) scenario. It defines a few
different message schemes (based on the Authentication Message)
that can be used to assure past messages sent by a UA and also act
as an assurance for UA trustworthiness in the absence of Internet
connectivity at the receiving node.
Introduction
UA Systems (UAS) are usually in a volatile environment when it
comes to communication. UA are generally small with little
computational (or flying) horsepower to carry standard
communication equipment. This limits the mediums of communication
to few viable options.
Observer systems (e.g. smartphones and tablets) place further
constraints on the communication options. The Remote ID Broadcast
messages MUST be available to applications on these platforms
without modifying the devices.
The ASTM standard focuses on two ways of communicating to a UAS for
RID: Broadcast and Network.
This document will focus on adding trust to Broadcast RID in the
current (and an expanded) Authentication Message format.
DRIP Requirements Addressed
The following will be addressed:
- GEN 1: Provable Ownership
-
This will be addressed using the Certificate Message types
(, ).
- GEN 2: Provable Binding
-
This will be addressed using the Wrapped ASTM Message, Manifest Message and Message
Pack Signature types
(, ,
).
- GEN 3: Provable Registration
-
This will be addressed using the Certificate Message types
(, ).
Terms and Definitions
Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Definitions
See for common DRIP terms.
- Aircraft
-
In this document whenever the word Aircraft is used it is refering
to an Unmanned Aircraft (UA) not a Manned Aircraft.
- HI
-
Host Identity. The public key portion of an asymmetric
keypair from HIP. In this document it is assumed that the
HI is based on a EdDSA25519 keypair. This is supported by
new crypto defined in .
- HIT
-
Host Identity Tag. A 128 bit handle on the HI. Defined in
HIPv2 .
- HHIT
-
Hierarchical Host Identity Tag. A 128 bit handle on the HI
contain extra information not found in a standard HIT.
Defined in .
Background
Problem Space And Document Focus
The current standard for Remote ID (RID) does not, in any
meaningful capacity, address the concerns of trust in the UA space
with communication in the Broadcast RID environment. This is a
requirement that will need to be addressed eventually for various
different parties that have a stake in the UA industry.
The following subsections will provide a high level reference to
the ASTM standard for Authentication Messages and how their current
limitations effect trust in the Broadcast RID environment.
ASTM Authentication Message
The above diagram is the format defined by ASTM that is the
frame which everything this document fits into. The specific
details of the ASTM headers are abstracted away as they are not
necessarily required for this document.
DRIP Authentication Framing Formats
Currently the ASTM AuthType of 0xD should be used to denote DRIP based Authentication.
General Frame
DRIP Header
The DRIP Header is used to signal what kind of Authentication under
DRIP that the message is using.
DRIP Authentication Data
This field has a maximum size of 223 bytes. If the data is less than
223 bytes and a page is only partially filled then the rest of the
partially filled page must be null padded.
Wrapper Frame
This framing resides within the General Frame's DRIP Authentication Data
().
UA Hierarchical Host Identity Tag
To avoid needing the UAs HHIT via the ASTM Basic ID in a detached
fashion the 16 byte HHIT is included in the wrapper frame.
The HHIT for the UA (and other entities in the RID and greater UTM system under DRIP)
is an enhancement of the Host Identity Tag (HIT) of HIPv2 introducing hierarchy as defined in
HHIT.
Using Hierarchical HITs for UAS RID
is outlined in HHIT based UAS RID.
Trust Timestamp
Trust Timestamp MUST be current UNIX time plus an offset
into the future. To avoid replay attacks the Trust Timestamp
field must be well founded.
When wrapping a Vector (Position) Message the payload
WILL contain (by ASTM rules) constantly changing data, this
includes its own timestamp. This timestamp is only 2 bytes,
which is easily attacked and only expresses the 1/10th of seconds
since the last hour.
Other message types, such as Basic ID and Self-ID are static
messages with no changing data. To protect a replay of these
signed messages the Trust Timestamp is the field during signing
to be guaranteed to change.
The offset used against the UNIX timestamp is not defined in this
document. Best practices to identify a acceptable offset should
be used taking into consideration the UA environment, and propagation
characteristics of the messages being sent.
Authentication Data
This field has a maximum of 116 bytes in length.
Signature
The wrapper signature is generated using the private key half of the the UAs
Host Identity (HI) and is done over all preceding data. ASTM/DRIP Headers are
exclude from this operation.
Forward Error Correction
To help Bluetooth 4 achieve the goal of reliable receipt of paged messages a
Forward Error Correction (FEC) scheme is introduced and is mandatory under DRIP.
Due to the nature of Bluetooth 4 and the existing ASTM paging structure an optimization
can be used. If a Bluetooth frame fails its CRC check, then the frame is dropped without notification to
the upper protocol layers. From the Remote ID perspective this means the loss of a complete
frame/message/page. In Authentication Messages, each page is already numbered so the loss of a page allows
the receiving application to build a "dummy" page filled with nulls (other than the ASTM Header
which is known).
A compliant implementation of this standard MUST use Reed Solomon for the FEC. With this the entire authentication
message (all pages, including headers) are used to generate 23 bytes of parity.
This parity is appended in one full page (always the last) allowing for recovery when any single page
is lost in transmission.
If more than one page is lost (>1/5 for 5 page messages, >1/10 for 10 page messages) than the error
rate of the link is already beyond saving and the application has more issues to deal with.
Bluetooth 4.X Formats
With Bluetooth 4.X formatting the goal is to attempt to bring reliable receipt of
paged messages.
Certificate
This DRIP Authentication type uses the General Frame format (), filling the
DRIP Authentication Data () field with a 200 byte Certificate and 23 bytes
of Reed Solomon FEC.
What this grants is the ability to authenticate UA Remote ID when
the receiving device of the observer (e.g. a smartphone with a
dedicated RID application) has no Internet service (e.g. LTE
signal).
The Certificate: Registry on Aircraft (Cra) is in practice a binding claim between the Registry and
the Aircraft, asserting the relationship between the two entities.
Cra signs another certificate, Caa (Certificate: Aircraft on Aircraft),
that is created during UA provisioning.
Importantly this certificate allows offline signature verification
from the UA. This is as the UA HI is included in the certificate.
Also included is the HHIT of the Registry to check the local
shortlist of Registries that the Observer device trusts (mapping HHITs
to HIs).
More details about Caa, Cra, other certificates and the provisioning
process can be found in .
ASTM Message Wrapper
This DRIP Authentication type uses the Wrapper Frame format (), filling the
Authentication Data () field with an ASTM Message (all types except
Message Pack [0xF] and Authentication [0x2]).
The DRIP AuthType (in the DRIP Header) MUST be set to 0xFF (255).
Manifest
This DRIP Authentication type uses the Wrapper Frame format (), filling the
Authentication Data () field with hashes of previously
sent messages.
By hashing previously sent messages and signing them we gain trust
in UAs previous reports. An observer who has been listening for any
length of time can hash received messages and cross check against
listed hashes. The signature is signed across the list of hashes.
Hash Algorithm And Operation
The hash algorithm used for the Manifest Message is the same hash algorithm used in creation of
the HHIT that is signing the Manifest.
A standard HHIT would be using cSHAKE128 from
. With cSHAKE128, the hash is computed as follows:
The message MAC is prepended to the message, as the MAC is the only
information that links UA messages from a specific UA.
Pseudo-blockchain Hashes
Two special hashes are included; a previous manifest hash,
which links to the previous manifest message, as well as a
current manifest hash. This gives a pseudo-blockchain provenance to the
manifest message that could be traced back if the observer
was present for extended periods of time.
In regards to the creation and use of the current manifest
hash field:
-
During creation and signing of this message format this field
MUST be set to 0. So the signature will be based on this field
being 0, as well as its own hash. It is an open question of if
we compute the hash, then sign or sign then compute.
-
There a few different ways to cycle this message. We can "roll
up" the hash of 'current' to 'previous' when needed or to
completely recompute the hash. This mostly depends on the
previous note.
Limitations
A potential limitation to this format is dwell time of the UA. If the UA is not
sticking to a general area then most likely the Observer will not obtain many
(if not all) of the messages in the manifest. Without the original messages
received no verification can be done. Examples of such scenarios include
delivery or survey UA.
Recommendations
Under ASTM Bluetooth 4.X rules, transmission of dynamic messages are at least every 1 second
while static messages (which is what Authentication is classified under) are sent at least
every 3 seconds.
Under DRIP the Certificate Message MUST be transmitted to properly meet the GEN 1 and
GEN 3 requirement.
The ASTM Message Wrapper and Manifest both satisfy the GEN 2 requirement. At least one MUST be implemented to
comply with the GEN 2 requirement.
A single Manifest can carry at most (using the full 10 page limit and 8 byte hashes) 12 unique hashes of previously
sent messages (of any type). This results in a total of 22 (12 + 10) frames of Bluetooth data being transmitted
over Bluetooth.
In comparison the Message Wrapper sends 6 pages (each a single frame) for each
wrapped message. For backwards compatibility the implementation should also send the standard
ASTM message that was wrapped for non-DRIP compliant receivers to obtain. This method results in
84 total Bluetooth frames (12 + (12 * 6)) sent.
The question of which is better suited is up to the implementation.
Bluetooth 5 Formats
Under ASTM specification, Bluetooth 5 transport of Remote ID is to use the
Message Pack (Type 0xF) format for all transmissions. Under Message Pack all
messages are sent together (in Message Type order) in a single Bluetooth frame (up to 250 bytes).
Message Packs are required by ASTM to be sent at a rate of 1 per second
(like dynamic messages).
This gives the benefit of no longer is there any message or page fragmentation in
transmission. For this reason the recommended use of FEC such as Reed Solomon
using in Bluetooth 4.X is not needed here and is impractical.
Any of the Bluetooth 4.X formats can theoretically be used during Bluetooth 5
operation under ASTM, however the following subsections define a number
of formats optimized for Message Pack and Bluetooth 5.
Certificate
With Message Pack the following MUST be included in it when sending a DRIP Certificate Message:
1x Location Message
1x Authentication Message, DRIP AuthType 0
The Certificate Message (without FEC) only needs 9 pages for transmission, allowing the final
25 bytes to be used for a Location message.
Message Pack Signature
The DRIP Message Pack Signature is a DRIP AuthType 1.
All messages in the message pack (excluding the Authentication Message
itself) is signed.
Security Considerations
TBD
ASTM Considerations
-
Increase Authentication Page Count maximum from 5 to 10.
-
Add Authentication Type for DRIP.
Acknowledgments
Ryan Quigley and James Mussi at AX Enterprize for early prototyping to find holes in the draft specifications.
References
Normative References
Informative References
Standard Specification for Remote ID and Tracking
ASTM International
Thoughts on ASTM Authentication Message
The format standardized by the ASTM is designed with a few major
considerations in mind, which the authors of this document feel put significant
limitations on the expansion of the standard.
The primary consideration (in this context) is the use of the
Bluetooth 5.X Extended Frame format. This method allows for a 255
byte payload to be sent in what the ASTM refers to as a
"Message Pack".
The idea is to include up to five standard ASTM Broadcast RID
messages (each of which are 25 bytes) plus a single authentication
message (5 pages of 25 bytes each) in the Message Pack. The
reasoning is then the Authentication Message is for the entire
Message Pack.
The authors have no issues with this proposed approach; this is a
valid format to use for the Authentication Message provided by the
ASTM. However, by limiting the Authentication Message to ONLY five
pages in the standard it ignores the possibility of other
formatting options to be created and used.
Another issue with this format, not fully addressed in this document
is fragmentation. Under Bluetooth 4.X, each page is sent separately
which can result in lose of pages on the receiver. This is disastrous
as the loss of even a single page means any signature is incomplete.
With the current limitation of 5 pages, Forward Error Correction (FEC)
is nearly impossible without sacrificing the amount of data sent. More
pages would allow FEC to be performed on the Authentication Message pages
so loss of pages can be mitigated.
All these problems are further amplified by the speed at which UA fly and the
Observer's position to receive transmissions. There is no guarantee
that the Observer will receive all the pages of even a 5 page Authentication
Message in the time it takes a UA to traverse across their line of sight.
Worse still is that is not including other UA in the area, which congests
the spectrum and could cause further confusion attempting to collate
messages from various UA. This specific problem is out of scope for this
document and our solutions in general, but should be noted as a design
consideration.