| Internet-Draft | Operator Privacy | April 2020 |
| Moskowitz, et al. | Expires 4 October 2020 | [Page] |
This document describes a method of providing privacy for Operator 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.¶
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 4 October 2020.¶
Copyright (c) 2020 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.¶
This document defines a mechanism to provide privacy in the ASTM Remote ID and Tracking messages [F3411-19] by encrypting, in place, those fields that contain sensitive Operator information. An example of such, and the initial application of this mechanism is the 8 bytes of Operator longitude and latitude location in the System Message.¶
It is assumed that the Operator registers a mission with a USS. During this mission registration, the Operator and USS exchange public keys to use in the hybrid ECIES. The USS key may be long lived, but the Operator key SHOULD be unique to a specific mission. This provides protection if the ECIES secret is exposed from prior missions.¶
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. There is rarely any data in the messages that can be used as an IV. A number of ciphers are proposed here that can encrypt exactly 64 bits. It is not a simple, encrypt these 64 bits with these ECIES derived key. The Operator may move during a mission and these fields change, correspondingly. Further, not all messages will be received by the USS, so each message's encryption must stand on its own, but not be at risk of attack by the content of other messages.¶
Future applications of this mechanism may be provided. The content of the System Message may change, requiring encrypting a different amount of data. At that time, they will be added to this document.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
All CAAs have rules defining which UAS must be registered to operate in their National Airspace. This includes UAS and Operator registration in a USS. Further, operator's are expected to report flight missions to their USS. This mission reporting provides a mechanism for the USS and operator to establish a mission security context. Here it will be used to exchange public keys for use in ECIES.¶
The operator's public key SHOULD be unique for each mission. The USS public key may be unique for each operator and mission, but not required. For best post-compromise security (PCS), even the USS public key should be changed over some operational window.¶
The public key algorithm should be Curve25519 [RFC7748]. Correspondingly, the ECIES 128 bit shared secret should be generated using KMAC as specified in sec 5 of [new-crypto].¶
The System Message contains 8 bytes of Operator specific information: Longitude and Latitude of the Remote Pilot of the UA. The GCS can encrypt these as follows.¶
The 8 bytes of Operator information are encrypted, using the ECIES 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 mission registration. AES-CFB16 is the recommended default cipher.¶
Bit 2 of the Flags byte is set to "1" to indicate the Operator information is encrypted.¶
The USS similarly decrypts these 8 bytes and provides the information to authorized entities.¶
CFB16 is defined in [NIST.SP.800-38A], 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 mission time, along with its mission 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, 128).¶
AES-CFB16 would then be used to encrypt the Operator information.¶
Speck [ISO ...., Reference needed] is a 64 bit block cipher and can be applied directly to the 8 bytes Operator information, using the 128 bit Operator/USS shared secret.¶
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. The Feistal scheme is explained in Appendix A.¶
If 2 bytes of the System 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 mission time, along with its mission 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, 112).¶
AES-CTR would then be used to encrypt the Operator information.¶
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.¶
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. Thus the first 2 encrypted bytes would not change, and only subsequent bytes would. The risk is mitigated due to the short-term value of the data. Further analysis is need to properly place risk.¶
The use of Speck for the block cipher has risks. Speck has been extensively analyzed and generally rejected as an AES alternative. But here it is being used as a 64 bit block cipher which AES is not. The risk is mitigated as the key is used to protect a limited number of blocks. In a 4 hour mission with a System Message every 10 seconds, there are only 1,440 applications of the Speck cipher, provided that the operator reported to the UA a new location within those 10 second windows.¶
The Remote ID System Message does not provide any space for a crypto suite indicator or any other method to manage crypto agility.¶
All crypto agility is left to the USS policy and the relation between the USS and operator. 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.¶
The recommendation to use Speck for the block cipher comes after discussions on the IRTF CFRG mailing list. Better known ciphers will not work for this situation without changes to the System Message content.¶
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.¶
How to encrypt an m-bit plaintext X using an n-bit block cipher
E = {E_K} for n > 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.
¶