idnits 2.17.1 draft-moskowitz-drip-operator-privacy-05.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 (21 August 2020) is 1344 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: 22 February 2021 A. Wiethuechter 6 AX Enterprize 7 21 August 2020 9 UAS Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-05 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 22 February 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 . . . . . . . 5 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 . . . . 6 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-CFB32 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10.1. CFB32 Risks . . . . . . . . . . . . . . . . . . . . . . 9 73 10.2. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 9 74 10.3. Key Derivation vulnerabilities . . . . . . . . . . . . . 9 75 10.4. KMAC Security as a KDF . . . . . . . . . . . . . . . . . 9 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 77 12. Informative References . . . . . . . . . . . . . . . . . . . 10 78 Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 11 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 System Message. This meets 93 the Drip Requirements [drip-requirements], Priv-01. 95 It is assumed that the Operator registers an operation with a USS. 96 During this operation registration, the Operator and USS exchange 97 public keys to use in the hybrid ECIES. The USS key may be long 98 lived, but the Operator 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. There is rarely any data in the 105 messages that can be used as an IV. The AES-CFB32 mode of operation 106 proposed here can encrypt a multiple of 4 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 Operator ID Message with 116 its 20 character Operator ID field. The Operator ID does not change 117 during an operation, so this is a one-time encryption operation for 118 the operation. The same cipher SHOULD be used for all messages from 119 the UAS and this will influence the cipher selection. 121 Future applications of this mechanism may be provided. The content 122 of the System Message may change to meet CAA requirements, requiring 123 encrypting a different amount of data. At that time, they will be 124 added to this document. 126 2. Terms and Definitions 128 2.1. Requirements Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 2.2. Definitions 138 See Drip Requirements [drip-requirements] for common DRIP terms. 140 ECIES 141 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 142 scheme which provides semantic security against an adversary who 143 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 145 Keccak (KECCAK Message Authentication Code): 146 The family of all sponge functions with a KECCAK-f permutation as 147 the underlying function and multi-rate padding as the padding 148 rule. 150 KMAC (KECCAK Message Authentication Code): 151 A PRF and keyed hash function based on KECCAK. 153 3. The Operator - USS Security Relationship 155 All CAAs have rules defining which UAS must be registered to operate 156 in their National Airspace. This includes UAS and Operator 157 registration in a USS. Further, operator's are expected to report 158 flight operations to their USS. This operation reporting provides a 159 mechanism for the USS and operator to establish an operation security 160 context. Here it will be used to exchange public keys for use in 161 ECIES. 163 The operator's ECIES public key SHOULD be unique for each operation. 164 The USS ECIES public key may be unique for each operator and 165 operation, but not required. For best post-compromise security 166 (PCS), the USS ECIES public key should be changed over some 167 operational window. 169 The public key algorithm should be Curve25519 [RFC7748]. 170 Correspondingly, the ECIES 128 bit shared secret should be generated 171 using KMAC. 173 3.1. ECIES Shared Secret Generation 175 The KMAC function provides a new, more efficient, key derivation 176 function over HKDF [RFC5869]. This will be referred to as KKDF. 178 HKDF needs a minimum of 4 hash functions (e.g. SHA256). KKDF does 179 an equivalent shared secret generation in a single Keccak Sponge 180 operation. 182 When the USS - UAS Operation Security Context is established, the USS 183 provides a 20 Character USS ID and a 256 bit random nonce to the USS. 184 These are inputs, along with the ECDH keys to produce the shared 185 secret as follows. 187 Per [NIST.SP.800-56Cr1], Section 4.1, Option 3: 189 Shared Secret = KMAC128(salt, IKM, L, S) 191 L is the derived key bit length. Since only a single key is needed, 192 L=128. 194 S is the byte string 01001011 || 01000100 || 01000110, which 195 represents the sequence of characters "K", "D", and "F" in 8-bit 196 ASCII. 198 salt = Nonce-USS | Nonce-UAS 200 There are special security considerations for IKM per [RFC7748]. The 201 IKM as follows: 203 IKM = Diffie-Hellman secret | USS-ID | RID 205 4. System Message Privacy 207 The System Message contains 8 bytes of Operator specific information: 208 Longitude and Latitude of the Remote Operator (Pilot in the field 209 description) of the UA. The GCS MAY encrypt these as follows. 211 The 8 bytes of Operator information are encrypted, using the ECIES 212 derived 128 bit shared secret, with one of the cipher's specified 213 below. The choice of cipher is based on USS policy and is agreed to 214 as part of the operation registration. AES-CFB32 is the recommended 215 default cipher. 217 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 218 allow Bit 2 of the Flags byte in the System Message set to "1" to 219 indicate the Operator information is encrypted. 221 The USS similarly decrypts these 8 bytes and provides the information 222 to authorized entities. 224 4.1. Rules for encrypting System Message content 226 If the Operator location is encrypted the encrypted bit flag MUST be 227 set to 1. 229 The Operator MAY be notified by the USS that the operation has 230 entered a location or time where privacy of Operator location is not 231 allowed. In this case the Operator MUST disable this privacy feature 232 and send the location unencrypted or land the UA or route around the 233 restricted area. 235 If the UAS looses connectivity to the USS, the privacy feature SHOULD 236 be disabled or land the UA. 238 If the operation is in an area or time with no Internet Connectivity, 239 the privacy feature MUST NOT be used. 241 4.2. Rules for decrypting System Message content 243 An Observer receives a System Message with the encrypt bit set to 1. 244 The Observer sends a query to its USS Display Provider containing the 245 UA's ID and the encrypted fields. 247 The USS Display Provider MAY deny the request if the Observer does 248 not have the proper authorization. 250 The USS Display Provider MAY reply to the request with the decrypted 251 fields if the Observer has the proper authorization. 253 The USS Display Provider MAY reply to the request with the decrypting 254 key if the Observer has the proper authorization. 256 The Observer MAY notify the USS through its USS Display Provider that 257 content privacy for a UAS in this location/time is not allowed. If 258 the Observer has the proper authorization for this action, the USS 259 notifies the Operator to disable this privacy feature. 261 5. Operator ID Message Privacy 263 The Operator ID Message contains 20 bytes for Operator the ID. The 264 GCS MAY encrypt these as follows. 266 The 20 bytes Operator ID is encrypted, using the ECIES derived 128 267 bit shared secret, with one of the cipher's specified below. The 268 choice of cipher is based on USS policy and is agreed to as part of 269 the operation registration. AES-CFB32 is the recommended default 270 cipher. 272 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 273 allow Operator ID Type in the Operator ID Message set to "1" to 274 indicate the Operator ID is encrypted. 276 The USS similarly decrypts these 20 bytes and provides the 277 information to authorized entities. 279 5.1. Rules for encrypting Operator ID Message content 281 If the Operator ID is encrypted the Operator ID Type field MUST be 282 set to 1. 284 The Operator MAY be notified by the USS that the operation has 285 entered a location or time where privacy of Operator ID is not 286 allowed. In this case the Operator MUST disable this privacy feature 287 and send the ID unencrypted or land the UA or route around the 288 restricted area. 290 If the UAS looses connectivity to the USS, the privacy feature SHOULD 291 be disabled or land the UA. 293 If the operation is in an area or time with no Internet Connectivity, 294 the privacy feature MUST NOT be used. 296 5.2. Rules for decrypting Operator ID Message content 298 An Observer receives a Operator ID Message with the Operator ID Type 299 field set to 1. The Observer sends a query to its USS Display 300 Provider containing the UA's ID and the encrypted fields. 302 The USS Display Provider MAY deny the request if the Observer does 303 not have the proper authorization. 305 The USS Display Provider MAY reply to the request with the decrypted 306 fields if the Observer has the proper authorization. 308 The USS Display Provider MAY reply to the request with the decrypting 309 key if the Observer has the proper authorization. 311 The Observer MAY notify the USS through its USS Display Provider that 312 content privacy for a UAS in this location/time is not allowed. If 313 the Observer has the proper authorization for this action, the USS 314 notifies the Operator to disable this privacy feature. 316 6. Cipher choices for Operator PII encryption 318 6.1. Using AES-CFB32 320 CFB32 is defined in [NIST.SP.800-38A], Section 6.3. This is the 321 Cipher Feedback (CFB) mode operating on 32 bits at a time. This 322 variant of CFB can be used to encrypt any multiple of 4 bytes of 323 cleartext. 325 The Operator includes a 64 bit UNIX timestamp for the operation time, 326 along with its operation pubic key. The Operator also includes the 327 UA MAC address (or multiple addresses if flying multiple UA). 329 The 128 bit IV for AES-CFB32 is constructed by the Operator and USS 330 as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the ASTM 331 Message_Type ensures a unique IV for each Message type that contains 332 PII to encrypt. 334 AES-CFB32 would then be used to encrypt the Operator information. 336 6.2. Using a Feistel scheme 338 If the encryption speed doesn't matter, we can use the following 339 approach based on the Feistel scheme. This approach is already being 340 used in format-preserving encryption (e.g. credit card numbers). The 341 Feistal scheme is explained in Appendix A. 343 6.3. Using AES-CTR 345 If 2 bytes of the Message can be set aside to contain a counter that 346 is incremented each time the Operator information changes, AES-CTR 347 can be used as follows. 349 The Operator includes a 64 bit UNIX timestamp for the operation time, 350 along with its operation pubic key. The Operator also includes the 351 UA MAC address (or multiple addresses if flying multiple UA). 353 The high order bits of an AES-CTR counter is constructed by the 354 Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112). 355 Inclusion of the ASTM Message_Type ensures a unique IV for each 356 Message type that contains PII to encrypt. 358 AES-CTR would then be used to encrypt the Operator information. 360 7. DRIP Requirements addressed 362 This document provides solution to PRIV-1 for PII in the ASTM System 363 Message. 365 8. ASTM Considerations 367 ASTM will need to make the following changes to the "Flags" in the 368 System Message: 370 Bit 2: 371 Value 1 for encrypted; 0 for cleartext (see Section 4). 373 ASTM will need to make the following changes to the "Operator ID 374 Type" in the Operator ID Message: 376 Operator ID Type 377 Value 1 for encrypted Operator ID (see Section 5). 379 9. IANA Considerations 381 TBD 383 10. Security Considerations 385 An attacker has no known text after decrypting to determine a 386 successful attack. An attacker can make assumptions about the high 387 order byte values for Operator Longitude and Latitude that may 388 substitute for known cleartext. There is no knowledge of where the 389 operator is in relation to the UA. Only if changing location values 390 "make sense" might an attacker assume to have revealed the operator's 391 location. 393 10.1. CFB32 Risks 395 Using the same IV for different Operator information values with 396 CFB32 presents a cyptoanalysis risk. Typically only the low order 397 bits would change as the Operators position changes. The risk is 398 mitigated due to the short-term value of the data. Further analysis 399 is need to properly place risk. 401 10.2. Crypto Agility 403 The ASTM Remote ID Messages do not provide any space for a crypto 404 suite indicator or any other method to manage crypto agility. 406 All crypto agility is left to the USS policy and the relation between 407 the USS and operator. The selection of the ECIES public key 408 algorithm, the shared secret key derivation function, and the actual 409 symmetric cipher used for on the System Message are set by the USS 410 which informs the operator what to do. 412 10.3. Key Derivation vulnerabilities 414 [RFC7748] warns about using Curve25519 and Curve448 in Diffie-Hellman 415 for key derivation: 417 Designers using these curves should be aware that for each public 418 key, there are several publicly computable public keys that are 419 equivalent to it, i.e., they produce the same shared secrets. Thus 420 using a public key as an identifier and knowledge of a shared secret 421 as proof of ownership (without including the public keys in the key 422 derivation) might lead to subtle vulnerabilities. 424 This applies here, but may have broader consequences. Thus two 425 endpoint IDs are included with the Diffie-Hellman secret. 427 10.4. KMAC Security as a KDF 429 Section 4.1 of NIST SP 800-185 [NIST.SP.800-185] states: 431 "The KECCAK Message Authentication Code (KMAC) algorithm is a PRF and 432 keyed hash function based on KECCAK . It provides variable-length 433 output" 435 That is, the output of KMAC is indistinguishable from a random 436 string, regardless of the length of the output. As such, the output 437 of KMAC can be divided into multiple substrings, each with the 438 strength of the function (KMAC128 or KMAC256) and provided that a 439 long enough key is used, as discussed in Sec. 8.4.1 of SP 800-185. 441 For example KMAC128(K, X, 512, S), where K is at least 128 bits, can 442 produce 4 128 bit keys each with a strength of 128 bits. That is a 443 single sponge operation is replacing perhaps 5 HMAC-SHA256 operations 444 (each 2 SHA256 operations) in HKDF. 446 11. Normative References 448 [NIST.SP.800-185] 449 Kelsey, J., Change, S., and R. Perlner, "SHA-3 derived 450 functions: cSHAKE, KMAC, TupleHash and ParallelHash", 451 National Institute of Standards and Technology report, 452 DOI 10.6028/nist.sp.800-185, December 2016, 453 . 455 [NIST.SP.800-38A] 456 Dworkin, M., "Recommendation for block cipher modes of 457 operation :", National Institute of Standards and 458 Technology report, DOI 10.6028/nist.sp.800-38a, 2001, 459 . 461 [NIST.SP.800-56Cr1] 462 Barker, E., Chen, L., and R. Davis, "Recommendation for 463 key-derivation methods in key-establishment schemes", 464 National Institute of Standards and Technology report, 465 DOI 10.6028/nist.sp.800-56cr1, April 2018, 466 . 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 474 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 475 May 2017, . 477 12. Informative References 479 [drip-requirements] 480 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 481 "Drone Remote Identification Protocol (DRIP) 482 Requirements", Work in Progress, Internet-Draft, draft- 483 ietf-drip-reqs-03, 13 July 2020, 484 . 486 [F3411-19] ASTM International, "Standard Specification for Remote ID 487 and Tracking", February 2020, 488 . 490 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 491 Key Derivation Function (HKDF)", RFC 5869, 492 DOI 10.17487/RFC5869, May 2010, 493 . 495 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 496 for Security", RFC 7748, DOI 10.17487/RFC7748, January 497 2016, . 499 Appendix A. Feistel Scheme 501 This approach is already being used in format-preserving encryption. 503 According to the theory, to provide CCA security guarantees (CCA = 504 Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 505 choose d >= 6. It seems very ineffective that when shortening the 506 block length, we have to use 6 times more block encryptions. On the 507 other hand, we preserve both the block cipher interface and security 508 guarantees in a simple way. 510 How to encrypt an m-bit plaintext X using an n-bit block cipher 511 E = {E_K} for n > m? 513 Enc(X, K): 514 1. Y <- X. 515 2. Split Y into 2 equal parts: Y = Y1 || Y2 516 (let us assume for simplicity that m is even). 517 3. For i = 1, 2, ..., d do: 518 Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), 519 where Ci is a (n - m/2)-bit round constant. 520 4. Y <- Y2 || Y1. 521 5. Return Y. 523 Dec(Y, K): 524 1. X <- Y. 525 2. Split X into 2 equal parts: X = X1 || X2. 526 3. For i = d, ..., 2, 1 do: 527 X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 528 4. X <- X2 || X1. 529 5. Return X. 531 Acknowledgments 533 The recommended ciphers come from discussions on the IRTF CFRG 534 mailing list. 536 Authors' Addresses 538 Robert Moskowitz 539 HTT Consulting 540 Oak Park, MI 48237 541 United States of America 543 Email: rgm@labs.htt-consult.com 545 Stuart W. Card 546 AX Enterprize 547 4947 Commercial Drive 548 Yorkville, NY 13495 549 United States of America 551 Email: stu.card@axenterprize.com 553 Adam Wiethuechter 554 AX Enterprize 555 4947 Commercial Drive 556 Yorkville, NY 13495 557 United States of America 559 Email: adam.wiethuechter@axenterprize.com