idnits 2.17.1 draft-moskowitz-drip-operator-privacy-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 October 2021) is 932 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 10 April 2022 A. Wiethuechter 6 AX Enterprize 7 7 October 2021 9 UAS Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-09 12 Abstract 14 This document describes a method of providing privacy for UAS 15 Operator/Pilot information specified in the ASTM UAS Remote ID and 16 Tracking messages. This is achieved by encrypting, in place, those 17 fields containing Operator sensitive data using a hybrid ECIES. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 10 April 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 55 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Operator - USS Security Relationship . . . . . . . . . . 4 57 3.1. ECIES Shared Secret Generation . . . . . . . . . . . . . 4 58 4. System Message Privacy . . . . . . . . . . . . . . . . . . . 5 59 4.1. Rules for encrypting System Message content . . . . . . . 6 60 4.2. Rules for decrypting System Message content . . . . . . . 6 61 5. Operator ID Message Privacy . . . . . . . . . . . . . . . . . 6 62 5.1. Rules for encrypting Operator ID Message content . . . . 7 63 5.2. Rules for decrypting Operator ID Message content . . . . 7 64 6. Cipher choices for Operator PII encryption . . . . . . . . . 7 65 6.1. Using AES-CFB16 . . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Using a Feistel scheme . . . . . . . . . . . . . . . . . 8 67 6.3. Using AES-CTR . . . . . . . . . . . . . . . . . . . . . . 8 68 7. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 8 69 8. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10.1. CFB16 Risks . . . . . . . . . . . . . . . . . . . . . . 9 73 10.2. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 9 74 10.3. Key Derivation vulnerabilities . . . . . . . . . . . . . 10 75 10.4. KMAC Security as a KDF . . . . . . . . . . . . . . . . . 10 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 77 12. Informative References . . . . . . . . . . . . . . . . . . . 11 78 Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 12 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This document defines a mechanism to provide privacy in the ASTM 85 Remote ID and Tracking messages [F3411-19] by encrypting, in place, 86 those fields that contain sensitive UAS Operator/Pilot information. 87 Encrypting in place means that the ciphertext is exactly the same 88 length as the cleartext, and directly replaces it. 90 An example of and an initial application of this mechanism is the 8 91 bytes of UAS Operator/Pilot (hereafter called simply Operator) 92 longitude and latitude location in the ASTM System Message (Msg Type 93 0x4). This meets the Drip Requirements [drip-requirements], Priv-01. 95 It is assumed that the Operator, via the UAS, registers an operation 96 with its USS. During this operation registration, the UAS and USS 97 exchange public keys to use in the hybrid ECIES. The USS key may be 98 long lived, but the UAS key SHOULD be unique to a specific operation. 99 This provides protection if the ECIES secret is exposed from prior 100 operations. 102 The actual Tracking message field encryption MUST be an "encrypt in 103 place" cipher. There is rarely any room in the tracking messages for 104 a cipher IV or encryption MAC (AEAD tag). There is rarely any data 105 in the messages that can be used as an IV. The AES-CFB16 mode of 106 operation proposed here can encrypt a multiple of 2 bytes. 108 The System Message is not a simple, one-time, encrypt the PII with 109 the ECIES derived key. The Operator may move during a operation and 110 these fields change, correspondingly. Further, not all messages will 111 be received by the USS, so each message's encryption must stand on 112 its own and not be at risk of attack by the content of other 113 messages. 115 Another candidate message is the optional ASTM Operator ID Message 116 (Msg Type 0x5) with its 20 character Operator ID field. The Operator 117 ID does not change during an operation, so this is a one-time 118 encryption operation for the operation. The same cipher SHOULD be 119 used for all messages from the UAS and this will influence the cipher 120 selection. 122 Future applications of this mechanism may be provided. The content 123 of the System Message may change to meet CAA requirements, requiring 124 encrypting a different amount of data. At that time, they will be 125 added to this document. 127 Editor note: The Rules for allowing encryption need to be updated to 128 handle the UA operating in Broadcast Remote ID only mode. That is 129 conditions where the USS cannot notify the UAS to stop encrypting. 131 2. Terms and Definitions 133 2.1. Requirements Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2.2. Definitions 143 See Drip Requirements [drip-requirements] for common DRIP terms. 145 ECIES 146 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 147 scheme which provides semantic security against an adversary who 148 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 150 Keccak (KECCAK Message Authentication Code): 151 The family of all sponge functions with a KECCAK-f permutation as 152 the underlying function and multi-rate padding as the padding 153 rule. 155 KMAC (KECCAK Message Authentication Code): 156 A PRF and keyed hash function based on KECCAK. 158 3. The Operator - USS Security Relationship 160 All CAAs have rules defining which UAS must be registered to operate 161 in their National Airspace. This includes UAS and Operator 162 registration in a USS. Further, operator's are expected to report 163 flight operations to their USS. This operation reporting provides a 164 mechanism for the USS and operator to establish an operation security 165 context. Here it will be used to exchange public keys for use in 166 ECIES. 168 The operator's ECIES public key SHOULD be unique for each operation. 169 The USS ECIES public key may be unique for each operator and 170 operation, but not required. For best post-compromise security 171 (PCS), the USS ECIES public key should be changed over some 172 operational window. 174 The public key algorithm should be Curve25519 [RFC7748]. 175 Correspondingly, the ECIES 128 bit shared secret should be generated 176 using KMAC [NIST.SP.800-185]. 178 3.1. ECIES Shared Secret Generation 180 The KMAC function provides a new, more efficient, key derivation 181 function over HKDF [RFC5869]. This will be referred to as KKDF. 183 HKDF needs a minimum of 4 hash functions (e.g. SHA256). KKDF does 184 an equivalent shared secret generation in a single Keccak Sponge 185 operation. 187 When the USS - UAS Operation Security Context is established, the UAS 188 provides its UAS ID (null padded to 20 characters per [F3411-19]) and 189 a 256 bit random nonce to the USS. These are inputs, along with the 190 ECDH keys to produce the shared secret as follows. 192 A 64 bit UNIX timestamp for the operation time is also included in 193 the Operation Security Context. This will be used in the IV 194 construction. 196 Per [NIST.SP.800-56Cr1], Section 4.1, Option 3: 198 Shared Secret = KMAC128(salt, IKM, L, S) 200 L is the derived key bit length. Since only a single key is needed, 201 L=128. 203 S is the byte string 01001011 || 01000100 || 01000110, which 204 represents the sequence of characters "K", "D", and "F" in 8-bit 205 ASCII. 207 salt = Nonce-USS | Nonce-UAS 209 There are special security considerations for IKM per [RFC7748]. The 210 IKM as follows: 212 IKM = Diffie-Hellman secret | USS-ID | RID 214 4. System Message Privacy 216 The System Message contains 8 bytes of Operator specific information: 217 Longitude and Latitude of the Remote Operator (Pilot in the field 218 description) of the UA. The GCS MAY encrypt these as follows. 220 Editors Note: The next version of [F3411-19], currently in ballot, is 221 adding a 2 byte Operator Altitude field, thus increasing the Operator 222 specific information to 10 bytes. This change will be delineated via 223 Protocol Version field. It is this future shift from a multiple of 4 224 bytes to a multiple of 2 bytes that is the reason to change from 225 CFB32 in earlier drafts to CFB16 used now. 227 The 8 bytes of Operator information are encrypted, using the ECIES 228 derived 128 bit shared secret, with one of the cipher's specified 229 below. The choice of cipher is based on USS policy and is agreed to 230 as part of the operation registration. AES-CFB16 is the recommended 231 default cipher. 233 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 234 allow Bit 5 of the Flags byte in the System Message set to "1" to 235 indicate the Operator information is encrypted. 237 The USS similarly decrypts these 8 bytes and provides the information 238 to authorized entities. 240 4.1. Rules for encrypting System Message content 242 If the Operator location is encrypted the encrypted bit flag MUST be 243 set to 1. 245 The Operator MAY be notified by the USS that the operation has 246 entered a location or time where privacy of Operator location is not 247 allowed. In this case the Operator MUST disable this privacy feature 248 and send the location unencrypted or land the UA or route around the 249 restricted area. 251 If the UAS looses connectivity to the USS, the privacy feature SHOULD 252 be disabled or land the UA. 254 If the operation is in an area or time with no Internet Connectivity, 255 the privacy feature MUST NOT be used. 257 4.2. Rules for decrypting System Message content 259 An Observer receives a System Message with the encrypt bit set to 1. 260 The Observer sends a query to its USS Display Provider containing the 261 UA's ID and the encrypted fields. 263 The USS Display Provider MAY deny the request if the Observer does 264 not have the proper authorization. 266 The USS Display Provider MAY reply to the request with the decrypted 267 fields if the Observer has the proper authorization. 269 The USS Display Provider MAY reply to the request with the decrypting 270 key if the Observer has the proper authorization. 272 The Observer MAY notify the USS through its USS Display Provider that 273 content privacy for a UAS in this location/time is not allowed. If 274 the Observer has the proper authorization for this action, the USS 275 notifies the Operator to disable this privacy feature. 277 5. Operator ID Message Privacy 279 The Operator ID Message contains the 20 byte Operator ID. The GCS 280 MAY encrypt these as follows. 282 The 20 bytes Operator ID is encrypted, using the ECIES derived 128 283 bit shared secret, with one of the cipher's specified below. The 284 choice of cipher is based on USS policy and is agreed to as part of 285 the operation registration. AES-CFB16 is the recommended default 286 cipher. 288 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 289 allow Operator ID Type in the Operator ID Message set to "1" to 290 indicate the Operator ID is encrypted. 292 The USS similarly decrypts these 20 bytes and provides the 293 information to authorized entities. 295 5.1. Rules for encrypting Operator ID Message content 297 If the Operator ID is encrypted the Operator ID Type field MUST be 298 set to 1. 300 The Operator MAY be notified by the USS that the operation has 301 entered a location or time where privacy of Operator ID is not 302 allowed. In this case the Operator MUST disable this privacy feature 303 and send the ID unencrypted or land the UA or route around the 304 restricted area. 306 If the UAS looses connectivity to the USS, the privacy feature SHOULD 307 be disabled or land the UA. 309 If the operation is in an area or time with no Internet Connectivity, 310 the privacy feature MUST NOT be used. 312 5.2. Rules for decrypting Operator ID Message content 314 An Observer receives a Operator ID Message with the Operator ID Type 315 field set to 1. The Observer sends a query to its USS Display 316 Provider containing the UA's ID and the encrypted fields. 318 The USS Display Provider MAY deny the request if the Observer does 319 not have the proper authorization. 321 The USS Display Provider MAY reply to the request with the decrypted 322 fields if the Observer has the proper authorization. 324 The USS Display Provider MAY reply to the request with the decrypting 325 key if the Observer has the proper authorization. 327 The Observer MAY notify the USS through its USS Display Provider that 328 content privacy for a UAS in this location/time is not allowed. If 329 the Observer has the proper authorization for this action, the USS 330 notifies the Operator to disable this privacy feature. 332 6. Cipher choices for Operator PII encryption 333 6.1. Using AES-CFB16 335 CFB16 is defined in [NIST.SP.800-38A], Section 6.3. This is the 336 Cipher Feedback (CFB) mode operating on 16 bits at a time. This 337 variant of CFB can be used to encrypt any multiple of 2 bytes of 338 cleartext. 340 The Operator includes a 64 bit UNIX timestamp for the operation time, 341 along with its operation pubic key. The Operator also includes the 342 UA MAC address (or multiple addresses if flying multiple UA). 344 The 128 bit IV for AES-CFB16 is constructed by the Operator and USS 345 as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the ASTM 346 Message_Type ensures a unique IV for each Message type that contains 347 PII to encrypt. 349 AES-CFB16 would then be used to encrypt the Operator information. 351 6.2. Using a Feistel scheme 353 If the encryption speed doesn't matter, we can use the following 354 approach based on the Feistel scheme. This approach is already being 355 used in format-preserving encryption (e.g. credit card numbers). The 356 Feistal scheme is explained in Appendix A. 358 6.3. Using AES-CTR 360 If 2 bytes of the Message can be set aside to contain a counter that 361 is incremented each time the Operator information changes, AES-CTR 362 can be used as follows. 364 The Operator includes a 64 bit UNIX timestamp for the operation time, 365 along with its operation pubic key. The Operator also includes the 366 UA MAC address (or multiple addresses if flying multiple UA). 368 The high order bits of an AES-CTR counter is constructed by the 369 Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112). 370 Inclusion of the ASTM Message_Type ensures a unique IV for each 371 Message type that contains PII to encrypt. 373 AES-CTR would then be used to encrypt the Operator information. 375 7. DRIP Requirements addressed 377 This document provides solution to PRIV-1 for PII in the ASTM System 378 Message. 380 8. ASTM Considerations 382 ASTM will need to make the following changes to the "Flags" in the 383 System Message (Msg Type 0x4): 385 Bit 5: 386 Value 1 for encrypted; 0 for cleartext (see Section 4). 388 ASTM will need to make the following changes to the "Operator ID 389 Type" in the Operator ID Message (Msg Type 0x5): 391 Operator ID Type 392 Value 1 for encrypted Operator ID (see Section 5). 394 9. IANA Considerations 396 TBD 398 10. Security Considerations 400 An attacker has no known text after decrypting to determine a 401 successful attack. An attacker can make assumptions about the high 402 order byte values for Operator Longitude and Latitude that may 403 substitute for known cleartext. There is no knowledge of where the 404 operator is in relation to the UA. Only if changing location values 405 "make sense" might an attacker assume to have revealed the operator's 406 location. 408 10.1. CFB16 Risks 410 Using the same IV for different Operator information values with 411 CFB16 presents a cyptoanalysis risk. Typically only the low order 412 bits would change as the Operators position changes. The risk is 413 mitigated due to the short-term value of the data. Further analysis 414 is need to properly place risk. 416 10.2. Crypto Agility 418 The ASTM Remote ID Messages do not provide any space for a crypto 419 suite indicator or any other method to manage crypto agility. 421 All crypto agility is left to the USS policy and the relation between 422 the USS and operator/UAS. The selection of the ECIES public key 423 algorithm, the shared secret key derivation function, and the actual 424 symmetric cipher used for on the System Message are set by the USS 425 which informs the operator what to do. 427 10.3. Key Derivation vulnerabilities 429 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 430 for key derivation: 432 Designers using these curves should be aware that for each public 433 key, there are several publicly computable public keys that are 434 equivalent to it, i.e., they produce the same shared secrets. Thus 435 using a public key as an identifier and knowledge of a shared secret 436 as proof of ownership (without including the public keys in the key 437 derivation) might lead to subtle vulnerabilities. 439 This applies here, but may have broader consequences. Thus two 440 endpoint IDs are included with the Diffie-Hellman secret. 442 10.4. KMAC Security as a KDF 444 Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: 446 "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and 447 keyed hash function based on KECCAK . It provides variable-length 448 output" 450 That is, the output of KMAC is indistinguishable from a random 451 string, regardless of the length of the output. As such, the output 452 of KMAC can be divided into multiple substrings, each with the 453 strength of the function (KMAC128 or KMAC256) and provided that a 454 long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. 456 For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 457 produce 4 128 bit keys each with a strength of 128 bits. That is a 458 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations 459 (each 2 SHA256 operations) in HKDF. 461 11. Normative References 463 [NIST.SP.800-185] 464 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 465 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 466 National Institute of Standards and Technology report, 467 DOI 10.6028/nist.sp.800-185, December 2016, 468 . 470 [NIST.SP.800-38A] 471 Dworkin, M., "Recommendation for block cipher modes of 472 operation :: methods and techniques", National Institute 473 of Standards and Technology report, 474 DOI 10.6028/nist.sp.800-38a, 2001, 475 . 477 [NIST.SP.800-56Cr1] 478 Barker, E., Chen, L., and R. Davis, "Recommendation for 479 key-derivation methods in key-establishment schemes", 480 National Institute of Standards and Technology report, 481 DOI 10.6028/nist.sp.800-56cr1, April 2018, 482 . 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 490 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 491 May 2017, . 493 12. Informative References 495 [drip-requirements] 496 Card, S. W., Wiethuechter, A., Moskowitz, R., and A. 497 Gurtov, "Drone Remote Identification Protocol (DRIP) 498 Requirements", Work in Progress, Internet-Draft, draft- 499 ietf-drip-reqs-18, 8 September 2021, 500 . 503 [F3411-19] ASTM International, "Standard Specification for Remote ID 504 and Tracking", February 2020, 505 . 507 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 508 Key Derivation Function (HKDF)", RFC 5869, 509 DOI 10.17487/RFC5869, May 2010, 510 . 512 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 513 for Security", RFC 7748, DOI 10.17487/RFC7748, January 514 2016, . 516 Appendix A. Feistel Scheme 518 This approach is already being used in format-preserving encryption. 520 According to the theory, to provide CCA security guarantees (CCA = 521 Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 522 choose d >= 6. It seems very ineffective that when shortening the 523 block length, we have to use 6 times more block encryptions. On the 524 other hand, we preserve both the block cipher interface and security 525 guarantees in a simple way. 527 How to encrypt an m-bit plaintext X using an n-bit block cipher 528 E = {E_K} for n > m? 530 Enc(X, K): 531 1. Y <- X. 532 2. Split Y into 2 equal parts: Y = Y1 || Y2 533 (let us assume for simplicity that m is even). 534 3. For i = 1, 2, ..., d do: 535 Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), 536 where Ci is a (n - m/2)-bit round constant. 537 4. Y <- Y2 || Y1. 538 5. Return Y. 540 Dec(Y, K): 541 1. X <- Y. 542 2. Split X into 2 equal parts: X = X1 || X2. 543 3. For i = d, ..., 2, 1 do: 544 X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 545 4. X <- X2 || X1. 546 5. Return X. 548 Acknowledgments 550 The recommended ciphers come from discussions on the IRTF CFRG 551 mailing list. 553 Authors' Addresses 555 Robert Moskowitz 556 HTT Consulting 557 Oak Park, MI 48237 558 United States of America 560 Email: rgm@labs.htt-consult.com 561 Stuart W. Card 562 AX Enterprize 563 4947 Commercial Drive 564 Yorkville, NY 13495 565 United States of America 567 Email: stu.card@axenterprize.com 569 Adam Wiethuechter 570 AX Enterprize 571 4947 Commercial Drive 572 Yorkville, NY 13495 573 United States of America 575 Email: adam.wiethuechter@axenterprize.com