< draft-moskowitz-drip-operator-privacy-09.txt   draft-moskowitz-drip-operator-privacy-10.txt >
DRIP R. Moskowitz DRIP R. Moskowitz
Internet-Draft HTT Consulting Internet-Draft HTT Consulting
Intended status: Standards Track S. Card Intended status: Standards Track S. Card
Expires: 10 April 2022 A. Wiethuechter Expires: 10 October 2022 A. Wiethuechter
AX Enterprize AX Enterprize
7 October 2021 8 April 2022
UAS Operator Privacy for RemoteID Messages UAS Operator Privacy for RemoteID Messages
draft-moskowitz-drip-operator-privacy-09 draft-moskowitz-drip-operator-privacy-10
Abstract Abstract
This document describes a method of providing privacy for UAS This document describes a method of providing privacy for UAS
Operator/Pilot information specified in the ASTM UAS Remote ID and Operator/Pilot information specified in the ASTM UAS Remote ID and
Tracking messages. This is achieved by encrypting, in place, those Tracking messages. This is achieved by encrypting, in place, those
fields containing Operator sensitive data using a hybrid ECIES. fields containing Operator sensitive data using a hybrid ECIES.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 April 2022. This Internet-Draft will expire on 10 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Operator - USS Security Relationship . . . . . . . . . . 4 3. The Operator - USS Security Relationship . . . . . . . . . . 4
3.1. ECIES Shared Secret Generation . . . . . . . . . . . . . 4 3.1. ECIES Shared Secret Generation . . . . . . . . . . . . . 4
4. System Message Privacy . . . . . . . . . . . . . . . . . . . 5 4. System Message Privacy . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 48 skipping to change at page 2, line 48
This document defines a mechanism to provide privacy in the ASTM This document defines a mechanism to provide privacy in the ASTM
Remote ID and Tracking messages [F3411-19] by encrypting, in place, Remote ID and Tracking messages [F3411-19] by encrypting, in place,
those fields that contain sensitive UAS Operator/Pilot information. those fields that contain sensitive UAS Operator/Pilot information.
Encrypting in place means that the ciphertext is exactly the same Encrypting in place means that the ciphertext is exactly the same
length as the cleartext, and directly replaces it. length as the cleartext, and directly replaces it.
An example of and an initial application of this mechanism is the 8 An example of and an initial application of this mechanism is the 8
bytes of UAS Operator/Pilot (hereafter called simply Operator) bytes of UAS Operator/Pilot (hereafter called simply Operator)
longitude and latitude location in the ASTM System Message (Msg Type longitude and latitude location in the ASTM System Message (Msg Type
0x4). This meets the Drip Requirements [drip-requirements], Priv-01. 0x4). This meets the Drip Requirements [RFC9153], Priv-01.
It is assumed that the Operator, via the UAS, registers an operation It is assumed that the Operator, via the UAS, registers an operation
with its USS. During this operation registration, the UAS and USS with its USS. During this operation registration, the UAS and USS
exchange public keys to use in the hybrid ECIES. The USS key may be exchange public keys to use in the hybrid ECIES. The USS key may be
long lived, but the UAS key SHOULD be unique to a specific operation. long lived, but the UAS key SHOULD be unique to a specific operation.
This provides protection if the ECIES secret is exposed from prior This provides protection if the ECIES secret is exposed from prior
operations. operations.
The actual Tracking message field encryption MUST be an "encrypt in The actual Tracking message field encryption MUST be an "encrypt in
place" cipher. There is rarely any room in the tracking messages for place" cipher. There is rarely any room in the tracking messages for
skipping to change at page 3, line 49 skipping to change at page 3, line 49
2.1. Requirements Terminology 2.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Definitions 2.2. Definitions
See Drip Requirements [drip-requirements] for common DRIP terms. See Section 2.2 of [RFC9153] for common DRIP terms.
ECIES ECIES
Elliptic Curve Integrated Encryption Scheme. A hybrid encryption Elliptic Curve Integrated Encryption Scheme. A hybrid encryption
scheme which provides semantic security against an adversary who scheme which provides semantic security against an adversary who
is allowed to use chosen-plaintext and chosen-ciphertext attacks. is allowed to use chosen-plaintext and chosen-ciphertext attacks.
Keccak (KECCAK Message Authentication Code): Keccak (KECCAK Message Authentication Code):
The family of all sponge functions with a KECCAK-f permutation as The family of all sponge functions with a KECCAK-f permutation as
the underlying function and multi-rate padding as the padding the underlying function and multi-rate padding as the padding
rule. rule. It refers in particular to all the functions referenced
from [NIST.FIPS.202] and [NIST.SP.800-185].
KMAC (KECCAK Message Authentication Code): KMAC (KECCAK Message Authentication Code):
A PRF and keyed hash function based on KECCAK. A PRF and keyed hash function based on KECCAK.
3. The Operator - USS Security Relationship 3. The Operator - USS Security Relationship
All CAAs have rules defining which UAS must be registered to operate All CAAs have rules defining which UAS must be registered to operate
in their National Airspace. This includes UAS and Operator in their National Airspace. This includes UAS and Operator
registration in a USS. Further, operator's are expected to report registration in a USS. Further, operator's are expected to report
flight operations to their USS. This operation reporting provides a flight operations to their USS. This operation reporting provides a
skipping to change at page 10, line 41 skipping to change at page 10, line 41
strength of the function (KMAC128 or KMAC256) and provided that a strength of the function (KMAC128 or KMAC256) and provided that a
long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185.
For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 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 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 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations
(each 2 SHA256 operations) in HKDF. (each 2 SHA256 operations) in HKDF.
11. Normative References 11. Normative References
[NIST.FIPS.202]
Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions", National Institute of
Standards and Technology report,
DOI 10.6028/nist.fips.202, July 2015,
<https://doi.org/10.6028/nist.fips.202>.
[NIST.SP.800-185] [NIST.SP.800-185]
Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived
functions: cSHAKE, KMAC, TupleHash and ParallelHash", functions: cSHAKE, KMAC, TupleHash and ParallelHash",
National Institute of Standards and Technology report, National Institute of Standards and Technology report,
DOI 10.6028/nist.sp.800-185, December 2016, DOI 10.6028/nist.sp.800-185, December 2016,
<https://doi.org/10.6028/nist.sp.800-185>. <https://doi.org/10.6028/nist.sp.800-185>.
[NIST.SP.800-38A] [NIST.SP.800-38A]
Dworkin, M., "Recommendation for block cipher modes of Dworkin, M., "Recommendation for block cipher modes of
operation :: methods and techniques", National Institute operation :: methods and techniques", National Institute
skipping to change at page 11, line 30 skipping to change at page 11, line 37
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12. Informative References 12. Informative References
[drip-requirements]
Card, S. W., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements", Work in Progress, Internet-Draft, draft-
ietf-drip-reqs-18, 8 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
reqs-18>.
[F3411-19] ASTM International, "Standard Specification for Remote ID [F3411-19] ASTM International, "Standard Specification for Remote ID
and Tracking", February 2020, and Tracking", February 2020,
<http://www.astm.org/cgi-bin/resolver.cgi?F3411>. <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
Appendix A. Feistel Scheme Appendix A. Feistel Scheme
This approach is already being used in format-preserving encryption. This approach is already being used in format-preserving encryption.
According to the theory, to provide CCA security guarantees (CCA = According to the theory, to provide CCA security guarantees (CCA =
Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should
choose d >= 6. It seems very ineffective that when shortening the choose d >= 6. It seems very ineffective that when shortening the
block length, we have to use 6 times more block encryptions. On 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 other hand, we preserve both the block cipher interface and security
guarantees in a simple way. guarantees in a simple way.
 End of changes. 12 change blocks. 
19 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/