UAS Operator Privacy for RemoteID Messages
HTT Consulting
Oak Park
MI
48237
USA
rgm@labs.htt-consult.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
stu.card@axenterprize.com
AX Enterprize
4947 Commercial Drive
Yorkville
NY
13495
USA
adam.wiethuechter@axenterprize.com
Internet
DRIP
RFC
Request for Comments
I-D
Internet-Draft
RID
This document describes a method of providing privacy for UAS
Operator/Pilot information specified in the ASTM UAS Remote ID and
Tracking messages. This is achieved by encrypting, in place, those
fields containing Operator sensitive data using a hybrid ECIES.
Introduction
This document defines a mechanism to provide privacy in the ASTM
Remote ID and Tracking messages by encrypting, in place, those fields that
contain sensitive UAS Operator/Pilot information. Encrypting in
place means that the ciphertext is exactly the same length as the
cleartext, and directly replaces it.
An example of and an initial application of this mechanism is the
10 bytes of UAS Operator/Pilot (hereafter called simply Operator)
Longitude, Latitude, and Altitude location in the ASTM System
Message (Msg Type 0x4). This meets the Drip Requirements, Priv-01.
It is assumed that the Operator, via the GCS, registers an
operation with its USS. During this operation registration, the
GCS and USS exchange public keys to use in the hybrid ECIES. The
USS key may be long lived, but the GCS key SHOULD be unique to a
specific operation. This provides protection if the ECIES secret is
exposed from prior operations.
The USS public key MAY be its DET key, but the GCS SHOULD be an
operation unique public key per above. This is possible, as EdDSA
keys can be converted to X25519 keys per Curve25519. Thus the GCS can convert the
USS DET key, but send, during operation registration an ephemeral
X25519 key.
The actual Tracking message field encryption MUST be an "encrypt in
place" cipher. There is rarely any room in the tracking messages
for a cipher IV or encryption MAC (AEAD tag). There is rarely any
data in the messages that can be used as an IV. The AES-CFB16 mode
of operation proposed here can encrypt a multiple of 2 bytes.
The System Message is not a simple, one-time, encrypt the PII with
the ECIES derived key. The Operator may move during a operation
and these fields change, correspondingly. Further, not all messages
will be received by the USS via Network Remote ID, so each
message's encryption must stand on its own and not be at risk of
attack by the content of other messages.
Another candidate message is the optional ASTM Operator ID Message
(Msg Type 0x5) with its 20 character Operator ID field. The
Operator ID does not change during an operation, so this is a
one-time encryption for the operation. The same cipher SHOULD be
used for all messages from the UAS and this will influence the
cipher selection.
Future applications of this mechanism may be provided. The content
of the System Message may change to meet CAA requirements,
requiring encrypting a different amount of data. At that time,
they will be added to this document.
Editor note: The Rules for allowing encryption need to be updated
to handle the UA operating in Broadcast Remote ID only mode. That
is conditions where the USS cannot notify the UAS to stop
encrypting.
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.
- ECIES
-
Elliptic Curve Integrated Encryption Scheme. A hybrid
encryption scheme which provides semantic security against
an adversary who is allowed to use chosen-plaintext and
chosen-ciphertext attacks.
- Keccak (KECCAK Message Authentication Code):
-
The family of all sponge functions with a KECCAK-f
permutation as the underlying function and multi-rate
padding as the padding rule. It refers in particular to
all the functions referenced from and
.
- KMAC (KECCAK Message Authentication Code):
-
A PRF and keyed hash function based on KECCAK.
The Operator - USS Security Relationship
All CAAs have rules defining which UAS must be registered to
operate in their National Air Space (NAS). This includes UAS and
Operator registration in a USS. Further, operators are expected
to report flight operations to their USS. This operation reporting
provides a mechanism for the USS and operator to establish an
operation security context. Here it will be used to exchange
public keys for use in ECIES.
The UAS's ECIES public key SHOULD be unique for each operation.
The USS ECIES public key may be unique for each UAS and
operation, but not required. For best post-compromise security
(PCS), the USS ECIES public key should be changed over some
operational window.
The public key algorithm should be Curve25519. Correspondingly, the ECIES 128
bit shared secret should be generated using KMAC.
ECIES Shared Secret Generation
The KMAC function provides a new, more efficient, key derivation
function over HKDF . This
will be referred to as KKDF.
HKDF needs a minimum of 4 hash functions (e.g. SHA256). KKDF does
an equivalent shared secret generation in a single Keccak Sponge
operation.
When the USS - UAS Operation Security Context is established, the
GCS provides the UA ID for the operation (null padded to 20
characters per ), a 256
bit random nonce, and an ephemeral X25519 key to the USS. These
are inputs, along with the USS key and a 256 bit random nonce to
produce the shared secret as follows.
A 64 bit UNIX timestamp from the USS for the operation time is also
included in the Operation Security Context. This will be used in
the IV construction (as in ).
Per ,
Section 4.1, Option 3:
L is the derived key bit length. Since only a single key is
needed, L=128.
S is the byte string 01001011 || 01000100 || 01000110, which
represents the sequence of characters "K", "D", and "F" in 8-bit
ASCII.
There are special security considerations for IKM per . The IKM as follows:
System Message Privacy
The System Message contains 10 bytes of Operator specific
information: Longitude, Latitude and Altitude of the Remote Operator (Pilot
in the field description) of the UA. The GCS MAY encrypt these as
follows.
The 10 bytes of Operator information are encrypted, using the ECIES
derived 128 bit shared secret, with one of the cipher's specified
below. The choice of cipher is based on USS policy and is agreed to
as part of the operation registration. AES-CFB16 is the
recommended default cipher.
ASTM Remote ID and Tracking messages SHOULD be updated to allow Bit 5 of the Flags
byte in the System Message set to "1" to indicate the Operator
information is encrypted.
The USS similarly decrypts these 10 bytes and provides the
information to authorized entities.
Rules for encrypting System Message content
If the Operator location is encrypted the encrypted bit flag MUST
be set to 1.
The Operator MAY be notified by the USS that the operation has
entered a location or time where privacy of Operator location is
not allowed. In this case the Operator MUST disable this privacy
feature and send the location unencrypted or land the UA or route
around the restricted area.
If the UAS loses connectivity to the USS, the privacy feature
SHOULD be disabled or land the UA.
If the operation is in an area or time with no Internet
Connectivity, the privacy feature MUST NOT be used.
Rules for decrypting System Message content
An Observer receives a System Message with the encrypt bit set to
1. The Observer sends a query to its USS Display Provider
containing the UA's ID and the encrypted fields.
The USS Display Provider MAY deny the request if the Observer does
not have the proper authorization.
The USS Display Provider MAY reply to the request with the
decrypted fields if the Observer has the proper authorization.
The USS Display Provider MAY reply to the request with the
decrypting key if the Observer has the proper authorization.
The Observer MAY notify the USS through its USS Display Provider
that content privacy for a UAS in this location/time is not
allowed. If the Observer has the proper authorization for this
action, the USS notifies the Operator to disable this privacy
feature.
Operator ID Message Privacy
The Operator ID Message contains the 20 byte Operator ID. The GCS
MAY encrypt these as follows.
The 20 bytes Operator ID is encrypted, using the ECIES derived 128
bit shared secret, with one of the cipher's specified below. The
choice of cipher is based on USS policy and is agreed to as part of
the operation registration. AES-CFB16 is the recommended default
cipher.
ASTM Remote ID and Tracking messages SHOULD be updated to allow Operator ID Type in
the Operator ID Message set to "1" to indicate the Operator ID is
encrypted.
The USS similarly decrypts these 20 bytes and provides the
information to authorized entities.
Rules for encrypting Operator ID Message content
If the Operator ID is encrypted the Operator ID Type field MUST be
set to 1.
The Operator MAY be notified by the USS that the operation has
entered a location or time where privacy of Operator ID is not
allowed. In this case the Operator MUST disable this privacy
feature and send the ID unencrypted or land the UA or route around
the restricted area.
If the UAS loses connectivity to the USS, the privacy feature
SHOULD be disabled or land the UA.
If the operation is in an area or time with no Internet
Connectivity, the privacy feature MUST NOT be used.
Rules for decrypting Operator ID Message content
An Observer receives a Operator ID Message with the Operator ID
Type field set to 1. The Observer sends a query to its USS Display
Provider containing the UA's ID and the encrypted fields.
The USS Display Provider MAY deny the request if the Observer does
not have the proper authorization.
The USS Display Provider MAY reply to the request with the
decrypted fields if the Observer has the proper authorization.
The USS Display Provider MAY reply to the request with the
decrypting key if the Observer has the proper authorization.
The Observer MAY notify the USS through its USS Display Provider
that content privacy for a UAS in this location/time is not
allowed. If the Observer has the proper authorization for this
action, the USS notifies the Operator to disable this privacy
feature.
Cipher choices for Operator PII encryption
Using AES-CFB16
CFB16 is defined in , Section 6.3. This is the Cipher
Feedback (CFB) mode operating on 16 bits at a time. This variant
of CFB can be used to encrypt any multiple of 2 bytes of cleartext.
The Operator includes a 64 bit UNIX timestamp for the operation
time, along with its operation pubic key. The Operator also
includes the UA MAC address (or multiple addresses if flying
multiple UA).
The 128 bit IV for AES-CFB16 is constructed by the Operator and
USS as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the
ASTM Message_Type ensures a unique IV for each Message type that
contains PII to encrypt.
AES-CFB16 would then be used to encrypt the Operator information.
Using a Feistel scheme
If the encryption speed doesn't matter, we can use the following
approach based on the Feistel scheme. This approach is already
being used in format-preserving encryption (e.g. credit card
numbers). The Feistal scheme is explained in .
Using AES-CTR
If 2 bytes of the Message can be set aside to contain a counter
that is incremented each time the Operator information changes,
AES-CTR can be used as follows.
The Operator includes a 64 bit UNIX timestamp for the operation
time, along with its operation pubic key. The Operator also
includes the UA MAC address (or multiple addresses if flying
multiple UA).
The high order bits of an AES-CTR counter is constructed by the
Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112).
Inclusion of the ASTM Message_Type ensures a unique IV for each
Message type that contains PII to encrypt.
AES-CTR would then be used to encrypt the Operator information.
DRIP Requirements addressed
This document provides solution to PRIV-1 for PII in the ASTM System Message.
ASTM Considerations
ASTM will need to make the following changes to the "Flags" in
the System Message (Msg Type 0x4):
- Bit 5:
-
Value 1 for encrypted; 0 for cleartext (see ).
ASTM will need to make the following changes to the "Operator ID
Type" in the Operator ID Message (Msg Type 0x5):
- Operator ID Type
-
Value 1 for encrypted Operator ID (see ).
Security Considerations
An attacker has no known text after decrypting to
determine a successful attack. An attacker can make assumptions
about the high order byte values for Operator Longitude and
Latitude that may substitute for known cleartext. There is no
knowledge of where the operator is in relation to the UA. Only if
changing location values "make sense" might an attacker assume to
have revealed the operator's location.
CFB16 Risks
Using the same IV for different Operator information values with
CFB16 presents a cyptoanalysis risk. Typically only the low order
bits would change as the Operators position changes. The risk is
mitigated due to the short-term value of the data. Further
analysis is need to properly place risk.
Crypto Agility
The ASTM Remote ID Messages do not provide any space for a crypto
suite indicator or any other method to manage crypto agility.
There can be different crypto pieces for components for different
DET OGAs. For example, a document specifying Operator Privacy for
DETs with an OGA=3 (ECDSA/SHA-384) would probably use SHA/HMAC
rather than SHAKE/KMAC.
All other aspects of crypto agility is left to the USS policy and
the relation between the USS and operator/UAS. The selection of
the ECIES public key algorithm, the shared secret key derivation
function, and the actual symmetric cipher used for on the System
Message are set by the USS which informs the operator what to do.
Key Derivation vulnerabilities
warns about using
Curve25519 and Curve448 in Diffie-Hellman for key derivation:
Designers using these curves should be aware that for each public
key, there are several publicly computable public keys that are
equivalent to it, i.e., they produce the same shared secrets. Thus
using a public key as an identifier and knowledge of a shared
secret as proof of ownership (without including the public keys in
the key derivation) might lead to subtle vulnerabilities.
This applies here, but may have broader consequences. Thus two
endpoint IDs are included with the Diffie-Hellman secret.
KMAC Security as a KDF
Section 4.1 of NIST SP 800-185 states:
"The KECCAK Message Authentication Code (KMAC) algorithm is a PRF
and keyed hash function based on KECCAK . It provides
variable-length output"
That is, the output of KMAC is indistinguishable from a random
string, regardless of the length of the output. As such, the
output of KMAC can be divided into multiple substrings, each with
the strength of the function (KMAC128 or KMAC256) and provided that
a long enough key is used, as discussed in , Section
8.4.1.
For example KMAC128(K, X, 512, S), where K is at least 128 bits,
can produce 4 128 bit keys each with a strength of 128 bits. That
is a single sponge operation is replacing perhaps 5 HMAC-SHA256
operations (each 2 SHA256 operations) in HKDF.
Standard Specification for Remote ID and Tracking - F3411−22a
ASTM International
Feistel Scheme
This approach is already being used in format-preserving encryption.
According to the theory, to provide CCA security guarantees (CCA =
Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should
choose d >= 6. It seems very ineffective that when shortening the
block length, we have to use 6 times more block encryptions. On the
other hand, we preserve both the block cipher interface and
security guarantees in a simple way.
m?
Enc(X, K):
1. Y <- X.
2. Split Y into 2 equal parts: Y = Y1 || Y2
(let us assume for simplicity that m is even).
3. For i = 1, 2, ..., d do:
Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)),
where Ci is a (n - m/2)-bit round constant.
4. Y <- Y2 || Y1.
5. Return Y.
Dec(Y, K):
1. X <- Y.
2. Split X into 2 equal parts: X = X1 || X2.
3. For i = d, ..., 2, 1 do:
X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)).
4. X <- X2 || X1.
5. Return X.
]]>
Acknowledgments
The recommended ciphers come from discussions on the IRTF CFRG
mailing list.