idnits 2.17.1 draft-moskowitz-drip-operator-privacy-04.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 (28 May 2020) is 1429 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: 29 November 2020 A. Wiethuechter 6 AX Enterprize 7 28 May 2020 9 UAS Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-04 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 29 November 2020. 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 4. System Message Privacy . . . . . . . . . . . . . . . . . . . 4 58 4.1. Rules for encrypting System Message content . . . . . . . 4 59 4.2. Rules for decrypting System Message content . . . . . . . 5 60 5. Operator ID Message Privacy . . . . . . . . . . . . . . . . . 5 61 5.1. Rules for encrypting Operator ID Message content . . . . 6 62 5.2. Rules for decrypting Operator ID Message content . . . . 6 63 6. Cipher choices for Operator PII encryption . . . . . . . . . 6 64 6.1. Using AES-CFB32 . . . . . . . . . . . . . . . . . . . . . 6 65 6.2. Using a Feistel scheme . . . . . . . . . . . . . . . . . 7 66 6.3. Using AES-CTR . . . . . . . . . . . . . . . . . . . . . . 7 67 7. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 7 68 8. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10.1. CFB32 Risks . . . . . . . . . . . . . . . . . . . . . . 8 72 10.2. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 8 73 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 12. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 9 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 This document defines a mechanism to provide privacy in the ASTM 82 Remote ID and Tracking messages [F3411-19] by encrypting, in place, 83 those fields that contain sensitive UAS Operator/Pilot information. 84 Encrypting in place means that the ciphertext is exactly the same 85 length as the cleartext, and directly replaces it. 87 An example of and an initial application of this mechanism is the 8 88 bytes of UAS Operator/Pilot (hereafter called simply Operator) 89 longitude and latitude location in the System Message. This meets 90 the Drip Requirements [drip-requirements], Priv-01. 92 It is assumed that the Operator registers an operation with a USS. 93 During this operation registration, the Operator and USS exchange 94 public keys to use in the hybrid ECIES. The USS key may be long 95 lived, but the Operator key SHOULD be unique to a specific operation. 96 This provides protection if the ECIES secret is exposed from prior 97 operations. 99 The actual Tracking message field encryption MUST be an "encrypt in 100 place" cipher. There is rarely any room in the tracking messages for 101 a cipher IV or encryption MAC. There is rarely any data in the 102 messages that can be used as an IV. The AES-CFB32 mode of operation 103 proposed here can encrypt a multiple of 4 bytes. 105 The System Message is not a simple, one-time, encrypt the PII with 106 the ECIES derived key. The Operator may move during a operation and 107 these fields change, correspondingly. Further, not all messages will 108 be received by the USS, so each message's encryption must stand on 109 its own and not be at risk of attack by the content of other 110 messages. 112 Another candidate message is the optional Operator ID Message with 113 its 20 character Operator ID field. The Operator ID does not change 114 during an operation, so this is a one-time encryption operation for 115 the operation. The same cipher SHOULD be used for all messages from 116 the UAS and this will influence the cipher selection. 118 Future applications of this mechanism may be provided. The content 119 of the System Message may change to meet CAA requirements, requiring 120 encrypting a different amount of data. At that time, they will be 121 added to this document. 123 2. Terms and Definitions 125 2.1. Requirements Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2.2. Definitions 135 See Drip Requirements [drip-requirements] for common DRIP terms. 137 ECIES 138 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 139 scheme which provides semantic security against an adversary who 140 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 142 3. The Operator - USS Security Relationship 144 All CAAs have rules defining which UAS must be registered to operate 145 in their National Airspace. This includes UAS and Operator 146 registration in a USS. Further, operator's are expected to report 147 flight operations to their USS. This operation reporting provides a 148 mechanism for the USS and operator to establish an operation security 149 context. Here it will be used to exchange public keys for use in 150 ECIES. 152 The operator's ECIES public key SHOULD be unique for each operation. 153 The USS ECIES public key may be unique for each operator and 154 operation, but not required. For best post-compromise security 155 (PCS), the USS ECIES public key should be changed over some 156 operational window. 158 The public key algorithm should be Curve25519 [RFC7748]. 159 Correspondingly, the ECIES 128 bit shared secret should be generated 160 using KMAC as specified in sec 5 of [new-hip-crypto]. 162 4. System Message Privacy 164 The System Message contains 8 bytes of Operator specific information: 165 Longitude and Latitude of the Remote Operator (Pilot in the field 166 description) of the UA. The GCS MAY encrypt these as follows. 168 The 8 bytes of Operator information are encrypted, using the ECIES 169 derived 128 bit shared secret, with one of the cipher's specified 170 below. The choice of cipher is based on USS policy and is agreed to 171 as part of the operation registration. AES-CFB32 is the recommended 172 default cipher. 174 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 175 allow Bit 2 of the Flags byte in the System Message set to "1" to 176 indicate the Operator information is encrypted. 178 The USS similarly decrypts these 8 bytes and provides the information 179 to authorized entities. 181 4.1. Rules for encrypting System Message content 183 If the Operator location is encrypted the encrypted bit flag MUST be 184 set to 1. 186 The Operator MAY be notified by the USS that the operation has 187 entered a location or time where privacy of Operator location is not 188 allowed. In this case the Operator MUST disable this privacy feature 189 and send the location unencrypted or land the UA or route around the 190 restricted area. 192 If the UAS looses connectivity to the USS, the privacy feature SHOULD 193 be disabled or land the UA. 195 If the operation is in an area or time with no Internet Connectivity, 196 the privacy feature MUST NOT be used. 198 4.2. Rules for decrypting System Message content 200 An Observer receives a System Message with the encrypt bit set to 1. 201 The Observer sends a query to its USS Display Provider containing the 202 UA's ID and the encrypted fields. 204 The USS Display Provider MAY deny the request if the Observer does 205 not have the proper authorization. 207 The USS Display Provider MAY reply to the request with the decrypted 208 fields if the Observer has the proper authorization. 210 The USS Display Provider MAY reply to the request with the decrypting 211 key if the Observer has the proper authorization. 213 The Observer MAY notify the USS through its USS Display Provider that 214 content privacy for a UAS in this location/time is not allowed. If 215 the Observer has the proper authorization for this action, the USS 216 notifies the Operator to disable this privacy feature. 218 5. Operator ID Message Privacy 220 The Operator ID Message contains 20 bytes for Operator the ID. The 221 GCS MAY encrypt these as follows. 223 The 20 bytes Operator ID is encrypted, using the ECIES derived 128 224 bit shared secret, with one of the cipher's specified below. The 225 choice of cipher is based on USS policy and is agreed to as part of 226 the operation registration. AES-CFB32 is the recommended default 227 cipher. 229 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 230 allow Operator ID Type in the Operator ID Message set to "1" to 231 indicate the Operator ID is encrypted. 233 The USS similarly decrypts these 20 bytes and provides the 234 information to authorized entities. 236 5.1. Rules for encrypting Operator ID Message content 238 If the Operator ID is encrypted the Operator ID Type field MUST be 239 set to 1. 241 The Operator MAY be notified by the USS that the operation has 242 entered a location or time where privacy of Operator ID is not 243 allowed. In this case the Operator MUST disable this privacy feature 244 and send the ID unencrypted or land the UA or route around the 245 restricted area. 247 If the UAS looses connectivity to the USS, the privacy feature SHOULD 248 be disabled or land the UA. 250 If the operation is in an area or time with no Internet Connectivity, 251 the privacy feature MUST NOT be used. 253 5.2. Rules for decrypting Operator ID Message content 255 An Observer receives a Operator ID Message with the Operator ID Type 256 field set to 1. The Observer sends a query to its USS Display 257 Provider containing the UA's ID and the encrypted fields. 259 The USS Display Provider MAY deny the request if the Observer does 260 not have the proper authorization. 262 The USS Display Provider MAY reply to the request with the decrypted 263 fields if the Observer has the proper authorization. 265 The USS Display Provider MAY reply to the request with the decrypting 266 key if the Observer has the proper authorization. 268 The Observer MAY notify the USS through its USS Display Provider that 269 content privacy for a UAS in this location/time is not allowed. If 270 the Observer has the proper authorization for this action, the USS 271 notifies the Operator to disable this privacy feature. 273 6. Cipher choices for Operator PII encryption 275 6.1. Using AES-CFB32 277 CFB32 is defined in [NIST.SP.800-38A], Section 6.3. This is the 278 Cipher Feedback (CFB) mode operating on 32 bits at a time. This 279 variant of CFB can be used to encrypt any multiple of 4 bytes of 280 cleartext. 282 The Operator includes a 64 bit UNIX timestamp for the operation time, 283 along with its operation pubic key. The Operator also includes the 284 UA MAC address (or multiple addresses if flying multiple UA). 286 The 128 bit IV for AES-CFB32 is constructed by the Operator and USS 287 as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the ASTM 288 Message_Type ensures a unique IV for each Message type that contains 289 PII to encrypt. 291 AES-CFB32 would then be used to encrypt the Operator information. 293 6.2. Using a Feistel scheme 295 If the encryption speed doesn't matter, we can use the following 296 approach based on the Feistel scheme. This approach is already being 297 used in format-preserving encryption (e.g. credit card numbers). The 298 Feistal scheme is explained in Appendix A. 300 6.3. Using AES-CTR 302 If 2 bytes of the Message can be set aside to contain a counter that 303 is incremented each time the Operator information changes, AES-CTR 304 can be used as follows. 306 The Operator includes a 64 bit UNIX timestamp for the operation time, 307 along with its operation pubic key. The Operator also includes the 308 UA MAC address (or multiple addresses if flying multiple UA). 310 The high order bits of an AES-CTR counter is constructed by the 311 Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112). 312 Inclusion of the ASTM Message_Type ensures a unique IV for each 313 Message type that contains PII to encrypt. 315 AES-CTR would then be used to encrypt the Operator information. 317 7. DRIP Requirements addressed 319 This document provides solution to PRIV-1 for PII in the ASTM System 320 Message. 322 8. ASTM Considerations 324 ASTM will need to make the following changes to the "Flags" in the 325 System Message: 327 Bit 2: 328 Value 1 for encrypted; 0 for cleartext (see Section 4). 330 ASTM will need to make the following changes to the "Operator ID 331 Type" in the Operator ID Message: 333 Operator ID Type 334 Value 1 for encrypted Operator ID (see Section 5). 336 9. IANA Considerations 338 TBD 340 10. Security Considerations 342 An attacker has no known text after decrypting to determine a 343 successful attack. An attacker can make assumptions about the high 344 order byte values for Operator Longitude and Latitude that may 345 substitute for known cleartext. There is no knowledge of where the 346 operator is in relation to the UA. Only if changing location values 347 "make sense" might an attacker assume to have revealed the operator's 348 location. 350 10.1. CFB32 Risks 352 Using the same IV for different Operator information values with 353 CFB32 presents a cyptoanalysis risk. Typically only the low order 354 bits would change as the Operators position changes. The risk is 355 mitigated due to the short-term value of the data. Further analysis 356 is need to properly place risk. 358 10.2. Crypto Agility 360 The ASTM Remote ID Messages do not provide any space for a crypto 361 suite indicator or any other method to manage crypto agility. 363 All crypto agility is left to the USS policy and the relation between 364 the USS and operator. The selection of the ECIES public key 365 algorithm, the shared secret key derivation function, and the actual 366 symmetric cipher used for on the System Message are set by the USS 367 which informs the operator what to do. 369 11. Normative References 371 [NIST.SP.800-38A] 372 Barker, E., Chen, L., and R. Davis, "Recommendation for 373 key-derivation methods in key-establishment schemes", 374 National Institute of Standards and Technology report, 375 DOI 10.6028/nist.sp.800-56cr1, April 2018, 376 . 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 384 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 385 May 2017, . 387 12. Informative References 389 [drip-requirements] 390 Card, S., Wiethuechter, A., Moskowitz, R., and A. Gurtov, 391 "Drone Remote Identification Protocol (DRIP) 392 Requirements", Work in Progress, Internet-Draft, draft- 393 ietf-drip-reqs-01, 25 May 2020, 394 . 396 [F3411-19] ASTM International, "Standard Specification for Remote ID 397 and Tracking", February 2020, 398 . 400 [new-hip-crypto] 401 Moskowitz, R., Card, S., and A. Wiethuechter, "New 402 Cryptographic Algorithms for HIP", Work in Progress, 403 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 404 January 2020, . 407 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 408 for Security", RFC 7748, DOI 10.17487/RFC7748, January 409 2016, . 411 Appendix A. Feistel Scheme 413 This approach is already being used in format-preserving encryption. 415 According to the theory, to provide CCA security guarantees (CCA = 416 Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 417 choose d >= 6. It seems very ineffective that when shortening the 418 block length, we have to use 6 times more block encryptions. On the 419 other hand, we preserve both the block cipher interface and security 420 guarantees in a simple way. 422 How to encrypt an m-bit plaintext X using an n-bit block cipher 423 E = {E_K} for n > m? 425 Enc(X, K): 426 1. Y <- X. 427 2. Split Y into 2 equal parts: Y = Y1 || Y2 428 (let us assume for simplicity that m is even). 429 3. For i = 1, 2, ..., d do: 430 Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), 431 where Ci is a (n - m/2)-bit round constant. 432 4. Y <- Y2 || Y1. 433 5. Return Y. 435 Dec(Y, K): 436 1. X <- Y. 437 2. Split X into 2 equal parts: X = X1 || X2. 438 3. For i = d, ..., 2, 1 do: 439 X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 440 4. X <- X2 || X1. 441 5. Return X. 443 Acknowledgments 445 The recommended ciphers come from discussions on the IRTF CFRG 446 mailing list. 448 Authors' Addresses 450 Robert Moskowitz 451 HTT Consulting 452 Oak Park, MI 48237 453 United States of America 455 Email: rgm@labs.htt-consult.com 457 Stuart W. Card 458 AX Enterprize 459 4947 Commercial Drive 460 Yorkville, NY 13495 461 United States of America 463 Email: stu.card@axenterprize.com 465 Adam Wiethuechter 466 AX Enterprize 467 4947 Commercial Drive 468 Yorkville, NY 13495 469 United States of America 471 Email: adam.wiethuechter@axenterprize.com