| < 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/ | ||||