Operator Privacy for RemoteID Messages
draft-moskowitz-drip-operator-privacy-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Robert Moskowitz , Stuart W. Card , Adam Wiethuechter | ||
| Last updated | 2020-04-02 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-moskowitz-drip-operator-privacy-01
DRIP R. Moskowitz
Internet-Draft HTT Consulting
Intended status: Standards Track S. Card
Expires: 4 October 2020 A. Wiethuechter
AX Enterprize
2 April 2020
Operator Privacy for RemoteID Messages
draft-moskowitz-drip-operator-privacy-01
Abstract
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.
Status of This Memo
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 Notice
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.
Moskowitz, et al. Expires 4 October 2020 [Page 1]
Internet-Draft Operator Privacy April 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Operator - USS Security Relationship . . . . . . . . . . 4
4. System Message Privacy . . . . . . . . . . . . . . . . . . . 5
4.1. Using AES-CFB16 in the System Message . . . . . . . . . . 5
4.2. Using Speck in the System Message . . . . . . . . . . . . 5
4.3. Using a Feistel scheme in the System Message . . . . . . 5
4.4. Using AES-CTR in the System Message . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. CFB16 Risks . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Speck Risks . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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.
Moskowitz, et al. Expires 4 October 2020 [Page 2]
Internet-Draft Operator Privacy April 2020
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.
2. Terms and Definitions
2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Definitions
B-RID
Broadcast Remote ID. A method of sending RID messages as 1-way
transmissions from the UA to any Observers within radio range.
CAA
Civil Aeronautics Administration. An example is the Federal
Aviation Administration (FAA) in the United States of America.
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.
GCS
Ground Control Station. The part of the UAS that the remote pilot
uses to exercise C2 over the UA, whether by remotely exercising UA
flight controls to fly the UA, by setting GPS waypoints, or
otherwise directing its flight.
Observer
Referred to in other UAS documents as a "user", but there are also
other classes of RID users, so we prefer "observer" to denote an
individual who has observed an UA and wishes to know something
about it, starting with its RID.
N-RID
Network Remote ID. A method of sending RID messages via the
Internet connection of the UAS directly to the UTM.
RID
Remote ID. A unique identifier found on all UA to be used in
communication and in regulation of UA operation.
Moskowitz, et al. Expires 4 October 2020 [Page 3]
Internet-Draft Operator Privacy April 2020
UA
Unmanned Aircraft. In this document UA's are typically though of
as drones of commercial or military variety. This is a very
strict definition which can be relaxed to include any and all
aircraft that are unmanned.
UAS
Unmanned Aircraft System. Composed of Unmanned Aircraft and all
required on-board subsystems, payload, control station, other
required off-board subsystems, any required launch and recovery
equipment, all required crew members, and C2 links between UA and
the control station.
USS
UAS Service Supplier. Provide UTM services to support the UAS
community, to connect Operators and other entities to enable
information flow across the USS network, and to promote shared
situational awareness among UTM participants. (From FAA UTM
ConOps V1, May 2018).
UTM
UAS Traffic Management. A "traffic management" ecosystem for
uncontrolled operations that is separate from, but complementary
to, the FAA's Air Traffic Management (ATM) system.
3. The Operator - USS Security Relationship
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].
Moskowitz, et al. Expires 4 October 2020 [Page 4]
Internet-Draft Operator Privacy April 2020
4. System Message Privacy
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.
4.1. Using AES-CFB16 in the System Message
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.
4.2. Using Speck in the System Message
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.
4.3. Using a Feistel scheme in the System Message
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.
Moskowitz, et al. Expires 4 October 2020 [Page 5]
Internet-Draft Operator Privacy April 2020
4.4. Using AES-CTR in the System Message
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.
5. IANA Considerations
TBD
6. 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.
6.1. 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. 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.
6.2. Speck Risks
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.
Moskowitz, et al. Expires 4 October 2020 [Page 6]
Internet-Draft Operator Privacy April 2020
6.3. Crypto Agility
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.
7. Acknowledgments
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.
8. Normative References
[NIST.SP.800-38A]
Barker, E., Chen, L., and R. Davis, "Recommendation for
key-derivation methods in key-establishment schemes",
National Institute of Standards and Technology report,
DOI 10.6028/nist.sp.800-56cr1, April 2018,
<https://doi.org/10.6028/nist.sp.800-56cr1>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
[F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[new-crypto]
Moskowitz, R., Card, S., and A. Wiethuechter, "New
Cryptographic Algorithms for HIP", Work in Progress,
Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23
January 2020, <https://tools.ietf.org/html/draft-
moskowitz-hip-new-crypto-04>.
Moskowitz, et al. Expires 4 October 2020 [Page 7]
Internet-Draft Operator Privacy April 2020
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
Appendix A. 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.
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.
Authors' Addresses
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Stuart W. Card
AX Enterprize
Moskowitz, et al. Expires 4 October 2020 [Page 8]
Internet-Draft Operator Privacy April 2020
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: stu.card@axenterprize.com
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Moskowitz, et al. Expires 4 October 2020 [Page 9]