idnits 2.17.1 draft-moskowitz-drip-operator-privacy-03.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 (8 May 2020) is 1448 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: 9 November 2020 A. Wiethuechter 6 AX Enterprize 7 8 May 2020 9 UAS Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-03 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 9 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 . . . . . . . . . . 5 57 4. System Message Privacy . . . . . . . . . . . . . . . . . . . 5 58 4.1. Rules for encrypting System Message content . . . . . . . 5 59 4.2. Rules for decrypting System Message content . . . . . . . 6 60 5. Operator ID Message Privacy . . . . . . . . . . . . . . . . . 6 61 5.1. Rules for encrypting Operator ID Message content . . . . 7 62 5.2. Rules for decrypting Operator ID Message content . . . . 7 63 6. Cipher choices for Operator PII encryption . . . . . . . . . 7 64 6.1. Using AES-CFB16 . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Using a Feistel scheme . . . . . . . . . . . . . . . . . 8 66 6.3. Using AES-CTR . . . . . . . . . . . . . . . . . . . . . . 8 67 7. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 8 68 8. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 10.1. CFB16 Risks . . . . . . . . . . . . . . . . . . . . . . 9 72 10.2. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 9 73 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 75 13. Informative References . . . . . . . . . . . . . . . . . . . 10 76 Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 a mission with a USS. 93 During this mission 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 mission. 96 This provides protection if the ECIES secret is exposed from prior 97 missions. 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. A some AES modes of operation 103 are proposed here that 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 mission 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 a mission, so this is a one-time encryption operation for the 115 mission. The same cipher SHOULD be used for all messages from the 116 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 B-RID 136 Broadcast Remote ID. A method of sending RID messages as 1-way 137 transmissions from the UA to any Observers within radio range. 139 CAA 140 Civil Aeronautics Administration. Two CAAs are the US Federal 141 Aviation Administration (FAA) and European Union Aviation Safety 142 Agency (EASA). 144 ECIES 145 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 146 scheme which provides semantic security against an adversary who 147 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 149 GCS 150 Ground Control Station. The part of the UAS that the remote pilot 151 uses to exercise C2 over the UA, whether by remotely exercising UA 152 flight controls to fly the UA, by setting GPS waypoints, or 153 otherwise directing its flight. 155 Observer 156 Referred to in other UAS documents as a "user", but there are also 157 other classes of RID users, so we prefer "observer" to denote an 158 individual who has observed an UA and wishes to know something 159 about it, starting with its RID. 161 N-RID 162 Network Remote ID. A method of sending RID messages via the 163 Internet connection of the UAS directly to the UTM. 165 RID 166 Remote ID. A unique identifier found on all UA to be used in 167 communication and in regulation of UA operation. 169 UA 170 Unmanned Aircraft. In this document UA's are typically though of 171 as drones of commercial or military variety. This is a very 172 strict definition which can be relaxed to include any and all 173 aircraft that are unmanned. 175 UAS 176 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 177 required on-board subsystems, payload, control station, other 178 required off-board subsystems, any required launch and recovery 179 equipment, all required crew members, and C2 links between UA and 180 the control station. 182 USS 183 UAS Service Supplier. Provide UTM services to support the UAS 184 community, to connect Operators and other entities to enable 185 information flow across the USS network, and to promote shared 186 situational awareness among UTM participants. (From FAA UTM 187 ConOps V1, May 2018). 189 UTM 190 UAS Traffic Management. A "traffic management" ecosystem for 191 uncontrolled operations that is separate from, but complementary 192 to, the FAA's Air Traffic Management (ATM) system. 194 3. The Operator - USS Security Relationship 196 All CAAs have rules defining which UAS must be registered to operate 197 in their National Airspace. This includes UAS and Operator 198 registration in a USS. Further, operator's are expected to report 199 flight missions to their USS. This mission reporting provides a 200 mechanism for the USS and operator to establish a mission security 201 context. Here it will be used to exchange public keys for use in 202 ECIES. 204 The operator's ECIES public key SHOULD be unique for each mission. 205 The USS ECIES public key may be unique for each operator and mission, 206 but not required. For best post-compromise security (PCS), even the 207 USS ECIES public key should be changed over some operational window. 209 The public key algorithm should be Curve25519 [RFC7748]. 210 Correspondingly, the ECIES 128 bit shared secret should be generated 211 using KMAC as specified in sec 5 of [new-crypto]. 213 4. System Message Privacy 215 The System Message contains 8 bytes of Operator specific information: 216 Longitude and Latitude of the Remote Operator (Pilot in the field 217 description) of the UA. The GCS MAY encrypt these as follows. 219 The 8 bytes of Operator information are encrypted, using the ECIES 220 derived 128 bit shared secret, with one of the cipher's specified 221 below. The choice of cipher is based on USS policy and is agreed to 222 as part of the mission registration. AES-CFB16 is the recommended 223 default cipher. 225 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 226 allow Bit 2 of the Flags byte in the System Message set to "1" to 227 indicate the Operator information is encrypted. 229 The USS similarly decrypts these 8 bytes and provides the information 230 to authorized entities. 232 4.1. Rules for encrypting System Message content 234 If the Operator location is encrypted the encrypted bit flag MUST be 235 set to 1. 237 The Operator MAY be notified by the USS that the mission has entered 238 a location or time where privacy of Operator location is not allowed. 239 In this case the Operator MUST disable this privacy feature and send 240 the location unencrypted or land the UA or route around the 241 restricted area. 243 If the Operator looses connectivity to the USS, the privacy feature 244 SHOULD be disabled or land the UA. 246 If the mission is in an area or time with no Internet Connectivity, 247 the privacy feature MUST NOT be used. 249 4.2. Rules for decrypting System Message content 251 An Observer receives a System Message with the encrypt bit set to 1. 252 The Observer sends a query to its USS Display Provider containing the 253 UA's ID and the encrypted fields. 255 The USS Display Provider MAY deny the request if the Observer does 256 not have the proper authorization. 258 The USS Display Provider MAY reply to the request with the decrypted 259 fields if the Observer has the proper authorization. 261 The USS Display Provider MAY reply to the request with the decrypting 262 key if the Observer has the proper authorization. 264 The Observer MAY notify the USS through its USS Display Provider that 265 content privacy for a UAS in this location/time is not allowed. If 266 the Observer has the proper authorization for this action, the USS 267 notifies the Operator to disable this privacy feature. 269 5. Operator ID Message Privacy 271 The Operator ID Message contains 20 bytes for Operator the ID. The 272 GCS MAY encrypt these as follows. 274 The 20 bytes Operator ID is encrypted, using the ECIES derived 128 275 bit shared secret, with one of the cipher's specified below. The 276 choice of cipher is based on USS policy and is agreed to as part of 277 the mission registration. AES-CFB16 is the recommended default 278 cipher. 280 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 281 allow Operator ID Type in the Operator ID Message set to "1" to 282 indicate the Operator ID is encrypted. 284 The USS similarly decrypts these 20 bytes and provides the 285 information to authorized entities. 287 5.1. Rules for encrypting Operator ID Message content 289 If the Operator ID is encrypted the Operator ID Type field MUST be 290 set to 1. 292 The Operator MAY be notified by the USS that the mission has entered 293 a location or time where privacy of Operator ID is not allowed. In 294 this case the Operator MUST disable this privacy feature and send the 295 ID unencrypted or land the UA or route around the restricted area. 297 If the Operator looses connectivity to the USS, the privacy feature 298 SHOULD be disabled or land the UA. 300 If the mission is in an area or time with no Internet Connectivity, 301 the privacy feature MUST NOT be used. 303 5.2. Rules for decrypting Operator ID Message content 305 An Observer receives a Operator ID Message with the Operator ID Type 306 field set to 1. The Observer sends a query to its USS Display 307 Provider containing the UA's ID and the encrypted fields. 309 The USS Display Provider MAY deny the request if the Observer does 310 not have the proper authorization. 312 The USS Display Provider MAY reply to the request with the decrypted 313 fields if the Observer has the proper authorization. 315 The USS Display Provider MAY reply to the request with the decrypting 316 key if the Observer has the proper authorization. 318 The Observer MAY notify the USS through its USS Display Provider that 319 content privacy for a UAS in this location/time is not allowed. If 320 the Observer has the proper authorization for this action, the USS 321 notifies the Operator to disable this privacy feature. 323 6. Cipher choices for Operator PII encryption 325 6.1. Using AES-CFB16 327 CFB16 is defined in [NIST.SP.800-38A], Section 6.3. This is the 328 Cipher Feedback (CFB) mode operating on 16 bits at a time. This 329 variant of CFB can be used to encrypt any multiple of 2 bytes of 330 cleartext. 332 The Operator includes a 64 bit UNIX timestamp for the mission time, 333 along with its mission pubic key. The Operator also includes the UA 334 MAC address (or multiple addresses if flying multiple UA). 336 The 128 bit IV for AES-CFB16 is constructed by the Operator and USS 337 as: SHAKE128(MAC|UTCTime|Message_Type, 128). Inclusion of the ASTM 338 Message_Type ensures a unique IV for each Message type that contains 339 PII to encrypt. 341 AES-CFB16 would then be used to encrypt the Operator information. 343 6.2. Using a Feistel scheme 345 If the encryption speed doesn't matter, we can use the following 346 approach based on the Feistel scheme. This approach is already being 347 used in format-preserving encryption (e.g. credit card numbers). The 348 Feistal scheme is explained in Appendix A. 350 6.3. Using AES-CTR 352 If 2 bytes of the Message can be set aside to contain a counter that 353 is incremented each time the Operator information changes, AES-CTR 354 can be used as follows. 356 The Operator includes a 64 bit UNIX timestamp for the mission time, 357 along with its mission pubic key. The Operator also includes the UA 358 MAC address (or multiple addresses if flying multiple UA). 360 The high order bits of an AES-CTR counter is constructed by the 361 Operator and USS as: SHAKE128(MAC|UTCTime|Message_Type, 112). 362 Inclusion of the ASTM Message_Type ensures a unique IV for each 363 Message type that contains PII to encrypt. 365 AES-CTR would then be used to encrypt the Operator information. 367 7. DRIP Requirements addressed 369 This document provides solution to PRIV-1 for PII in the ASTM System 370 Message. 372 8. ASTM Considerations 374 ASTM will need to make the following changes to the "Flags" in the 375 System Message: 377 Bit 2: 378 Value 1 for encrypted; 0 for cleartext (see Section 4). 380 ASTM will need to make the following changes to the "Operator ID 381 Type" in the Operator ID Message: 383 Operator ID Type 384 Value 1 for encrypted Operator ID (see Section 5). 386 9. IANA Considerations 388 TBD 390 10. Security Considerations 392 An attacker has no known text after decrypting to determine a 393 successful attack. An attacker can make assumptions about the high 394 order byte values for Operator Longitude and Latitude that may 395 substitute for known cleartext. There is no knowledge of where the 396 operator is in relation to the UA. Only if changing location values 397 "make sense" might an attacker assume to have revealed the operator's 398 location. 400 10.1. CFB16 Risks 402 Using the same IV for different Operator information values with 403 CFB16 presents a cyptoanalysis risk. Typically only the low order 404 bits would change as the Operators position changes. Thus the first 405 2 encrypted bytes would not change, and only subsequent bytes would. 406 The risk is mitigated due to the short-term value of the data. 407 Further analysis is need to properly place risk. 409 10.2. Crypto Agility 411 The ASTM Remote ID Messages do not provide any space for a crypto 412 suite indicator or any other method to manage crypto agility. 414 All crypto agility is left to the USS policy and the relation between 415 the USS and operator. The selection of the ECIES public key 416 algorithm, the shared secret key derivation function, and the actual 417 symmetric cipher used for on the System Message are set by the USS 418 which informs the operator what to do. 420 11. Acknowledgments 422 TBD 424 12. Normative References 426 [NIST.SP.800-38A] 427 Barker, E., Chen, L., and R. Davis, "Recommendation for 428 key-derivation methods in key-establishment schemes", 429 National Institute of Standards and Technology report, 430 DOI 10.6028/nist.sp.800-56cr1, April 2018, 431 . 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, 435 DOI 10.17487/RFC2119, March 1997, 436 . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 13. Informative References 444 [drip-requirements] 445 Card, S., Wiethuechter, A., and R. Moskowitz, "Drone 446 Remote Identification Protocol (DRIP) Requirements", Work 447 in Progress, Internet-Draft, draft-card-drip-reqs-02, 20 448 April 2020, 449 . 451 [F3411-19] ASTM International, "Standard Specification for Remote ID 452 and Tracking", February 2020, 453 . 455 [new-crypto] 456 Moskowitz, R., Card, S., and A. Wiethuechter, "New 457 Cryptographic Algorithms for HIP", Work in Progress, 458 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 459 January 2020, . 462 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 463 for Security", RFC 7748, DOI 10.17487/RFC7748, January 464 2016, . 466 Appendix A. Feistel Scheme 468 This approach is already being used in format-preserving encryption. 470 According to the theory, to provide CCA security guarantees (CCA = 471 Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 472 choose d >= 6. It seems very ineffective that when shortening the 473 block length, we have to use 6 times more block encryptions. On the 474 other hand, we preserve both the block cipher interface and security 475 guarantees in a simple way. 477 How to encrypt an m-bit plaintext X using an n-bit block cipher 478 E = {E_K} for n > m? 480 Enc(X, K): 481 1. Y <- X. 482 2. Split Y into 2 equal parts: Y = Y1 || Y2 483 (let us assume for simplicity that m is even). 484 3. For i = 1, 2, ..., d do: 485 Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), 486 where Ci is a (n - m/2)-bit round constant. 487 4. Y <- Y2 || Y1. 488 5. Return Y. 490 Dec(Y, K): 491 1. X <- Y. 492 2. Split X into 2 equal parts: X = X1 || X2. 493 3. For i = d, ..., 2, 1 do: 494 X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 495 4. X <- X2 || X1. 496 5. Return X. 498 Authors' Addresses 500 Robert Moskowitz 501 HTT Consulting 502 Oak Park, MI 48237 503 United States of America 505 Email: rgm@labs.htt-consult.com 507 Stuart W. Card 508 AX Enterprize 509 4947 Commercial Drive 510 Yorkville, NY 13495 511 United States of America 513 Email: stu.card@axenterprize.com 514 Adam Wiethuechter 515 AX Enterprize 516 4947 Commercial Drive 517 Yorkville, NY 13495 518 United States of America 520 Email: adam.wiethuechter@axenterprize.com