idnits 2.17.1 draft-moskowitz-drip-operator-privacy-02.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 (27 April 2020) is 1454 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 October 2020 A. Wiethuechter 6 AX Enterprize 7 27 April 2020 9 UAS Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-02 12 Abstract 14 This document describes a method of providing privacy for UAS 15 Operator information specified in the ASTM UAS Remote ID and Tracking 16 messages. This is achieved by encrypting, in place, those fields 17 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 October 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 4.3. Using AES-CFB16 in the System Message . . . . . . . . . . 6 61 4.4. Using Speck in the System Message . . . . . . . . . . . . 6 62 4.5. Using a Feistel scheme in the System Message . . . . . . 7 63 4.6. Using AES-CTR in the System Message . . . . . . . . . . . 7 64 5. DRIP Requirements addressed . . . . . . . . . . . . . . . . . 7 65 6. ASTM Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8.1. CFB16 Risks . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.2. Speck Risks . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.3. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 8 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 11. Informative References . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Feistel Scheme . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document defines a mechanism to provide privacy in the ASTM 80 Remote ID and Tracking messages [F3411-19] by encrypting, in place, 81 those fields that contain sensitive UAS Operator information. An 82 example of such, and the initial application of this mechanism is the 83 8 bytes of UAS Operator (hereafter called simply Operator) longitude 84 and latitude location in the System Message. This meets the Drip 85 Requirements [drip-requirements], Priv-01. 87 It is assumed that the Operator registers a mission with a USS. 88 During this mission registration, the Operator and USS exchange 89 public keys to use in the hybrid ECIES. The USS key may be long 90 lived, but the Operator key SHOULD be unique to a specific mission. 91 This provides protection if the ECIES secret is exposed from prior 92 missions. 94 The actual Tracking message field encryption MUST be an "encrypt in 95 place" cipher. There is rarely any room in the tracking messages for 96 a cipher IV or encryption MAC. There is rarely any data in the 97 messages that can be used as an IV. A number of ciphers are proposed 98 here that can encrypt exactly 64 bits. It is not a simple, encrypt 99 these 64 bits with these ECIES derived key. The Operator may move 100 during a mission and these fields change, correspondingly. Further, 101 not all messages will be received by the USS, so each message's 102 encryption must stand on its own, but not be at risk of attack by the 103 content of other messages. 105 Future applications of this mechanism may be provided. The content 106 of the System Message may change, requiring encrypting a different 107 amount of data. At that time, they will be added to this document. 109 2. Terms and Definitions 111 2.1. Requirements Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 2.2. Definitions 121 B-RID 122 Broadcast Remote ID. A method of sending RID messages as 1-way 123 transmissions from the UA to any Observers within radio range. 125 CAA 126 Civil Aeronautics Administration. An example is the Federal 127 Aviation Administration (FAA) in the United States of America. 129 ECIES 130 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 131 scheme which provides semantic security against an adversary who 132 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 134 GCS 135 Ground Control Station. The part of the UAS that the remote pilot 136 uses to exercise C2 over the UA, whether by remotely exercising UA 137 flight controls to fly the UA, by setting GPS waypoints, or 138 otherwise directing its flight. 140 Observer 141 Referred to in other UAS documents as a "user", but there are also 142 other classes of RID users, so we prefer "observer" to denote an 143 individual who has observed an UA and wishes to know something 144 about it, starting with its RID. 146 N-RID 147 Network Remote ID. A method of sending RID messages via the 148 Internet connection of the UAS directly to the UTM. 150 Net-RID DP 151 Network RID Display Provider. Logical entity that aggregates data 152 from Net-RID SPs as needed in response to user queries regarding 153 UAS operating within specified airspace volumes, to enable display 154 by a user application on a user device. Under the FAA NPRM, not 155 recognized as a distinct entity, but a service provided by USS, 156 including Public Safety USS that may exist primarily for this 157 purpose rather than to manage any subscribed UAS. 159 RID 160 Remote ID. A unique identifier found on all UA to be used in 161 communication and in regulation of UA operation. 163 UA 164 Unmanned Aircraft. In this document UA's are typically though of 165 as drones of commercial or military variety. This is a very 166 strict definition which can be relaxed to include any and all 167 aircraft that are unmanned. 169 UAS 170 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 171 required on-board subsystems, payload, control station, other 172 required off-board subsystems, any required launch and recovery 173 equipment, all required crew members, and C2 links between UA and 174 the control station. 176 USS 177 UAS Service Supplier. Provide UTM services to support the UAS 178 community, to connect Operators and other entities to enable 179 information flow across the USS network, and to promote shared 180 situational awareness among UTM participants. (From FAA UTM 181 ConOps V1, May 2018). 183 UTM 184 UAS Traffic Management. A "traffic management" ecosystem for 185 uncontrolled operations that is separate from, but complementary 186 to, the FAA's Air Traffic Management (ATM) system. 188 3. The Operator - USS Security Relationship 190 All CAAs have rules defining which UAS must be registered to operate 191 in their National Airspace. This includes UAS and Operator 192 registration in a USS. Further, operator's are expected to report 193 flight missions to their USS. This mission reporting provides a 194 mechanism for the USS and operator to establish a mission security 195 context. Here it will be used to exchange public keys for use in 196 ECIES. 198 The operator's public key SHOULD be unique for each mission. The USS 199 public key may be unique for each operator and mission, but not 200 required. For best post-compromise security (PCS), even the USS 201 public key should be changed over some operational window. 203 The public key algorithm should be Curve25519 [RFC7748]. 204 Correspondingly, the ECIES 128 bit shared secret should be generated 205 using KMAC as specified in sec 5 of [new-crypto]. 207 4. System Message Privacy 209 The System Message contains 8 bytes of Operator specific information: 210 Longitude and Latitude of the Remote Pilot of the UA. The GCS can 211 encrypt these as follows. 213 The 8 bytes of Operator information are encrypted, using the ECIES 214 128 bit shared secret with one of the cipher's specified below. The 215 choice of cipher sys_msgis based on USS policy and is agreed to as 216 part of the mission registration. AES-CFB16 is the recommended 217 default cipher. 219 ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to 220 allow Bit 2 of the Flags byte in the System Message set to "1" to 221 indicate the Operator information is encrypted. 223 The USS similarly decrypts these 8 bytes and provides the information 224 to authorized entities. 226 4.1. Rules for encrypting System Message content 228 If the Operator location is encrypted the encrypted bit flag MUST be 229 set to 1. 231 The Operator MAY be notified by the USS that the mission has entered 232 a location or time where privacy of Operator location is not allowed. 233 In this case the Operator MUST disable this privacy feature and send 234 the location unencrypted or land the UA or route around the 235 restricted area. 237 If the Operator looses connectivity to the USS, the privacy feature 238 SHOULD be disabled or land the UA. 240 If the mission is in an area or time with no Internet Connectivity, 241 the privacy feature MUST NOT be used. 243 4.2. Rules for decrypting System Message content 245 An Observer receives a System Message with the encrypt bit set to 1. 246 The Observer sends a query to its NET-RID DP containing the UA's ID 247 and the encrypted fields. 249 The NET-RID DP MAY deny the request if the Observer does not have the 250 proper authorization. 252 The NET-RID DP MAY reply to the request with the decrypted fields if 253 the Observer has the proper authorization. 255 The NET-RID DP MAY reply to the request with the decrypting key if 256 the Observer has the proper authorization. 258 The Observer MAY notify the USS that content privacy for a UAS in 259 this location/time is not allowed. If the Observer has the proper 260 authorization for this action, the USS notifies the Operator to 261 disable this privacy feature. 263 4.3. Using AES-CFB16 in the System Message 265 CFB16 is defined in [NIST.SP.800-38A], Section 6.3. This is the 266 Cipher Feedback (CFB) mode operating on 16 bits at a time. This 267 variant of CFB can be used to encrypt any multiple of 2 bytes of 268 cleartext. 270 The Operator includes a 64 bit UNIX timestamp for the mission time, 271 along with its mission pubic key. The Operator also includes the UA 272 MAC address (or multiple addresses if flying multiple UA). 274 The 128 bit IV for AES-CFB16 is constructed by the Operator and USS 275 as: SHAKE128(MAC|UTCTime, 128). 277 AES-CFB16 would then be used to encrypt the Operator information. 279 4.4. Using Speck in the System Message 281 Speck [ISO.29167-22] is a 64 bit block cipher and can be applied 282 directly to the 8 bytes Operator information, using the 128 bit 283 Operator/USS shared secret. 285 4.5. Using a Feistel scheme in the System Message 287 If the encryption speed doesn't matter, we can use the following 288 approach based on the Feistel scheme. This approach is already being 289 used in format-preserving encryption. The Feistal scheme is 290 explained in Appendix A. 292 4.6. Using AES-CTR in the System Message 294 If 2 bytes of the System Message can be set aside to contain a 295 counter that is incremented each time the Operator information 296 changes, AES-CTR can be used as follows. 298 The Operator includes a 64 bit UNIX timestamp for the mission time, 299 along with its mission pubic key. The Operator also includes the UA 300 MAC address (or multiple addresses if flying multiple UA). 302 The high order bits of an AES-CTR counter is constructed by the 303 Operator and USS as: SHAKE128(MAC|UTCTime, 112). 305 AES-CTR would then be used to encrypt the Operator information. 307 5. DRIP Requirements addressed 309 This document provides solution to PRIV-1 for PII in the ASTM System 310 Message. 312 6. ASTM Considerations 314 ASTM will need to make the following changes to the "Flags" in the 315 System Message: 317 Bit 2: 318 Value 1 for encrypted; 0 for cleartext (see Section 4). 320 7. IANA Considerations 322 TBD 324 8. Security Considerations 326 An attacker has no known text after decrypting to determine a 327 successful attack. An attacker can make assumptions about the high 328 order byte values for Operator Longitude and Latitude that may 329 substitute for known cleartext. There is no knowledge of where the 330 operator is in relation to the UA. Only if changing location values 331 "make sense" might an attacker assume to have revealed the operator's 332 location. 334 8.1. CFB16 Risks 336 Using the same IV for different Operator information values with 337 CFB16 presents a cyptoanalysis risk. Typically only the low order 338 bits would change as the Operators position changes. Thus the first 339 2 encrypted bytes would not change, and only subsequent bytes would. 340 The risk is mitigated due to the short-term value of the data. 341 Further analysis is need to properly place risk. 343 8.2. Speck Risks 345 The use of Speck for the block cipher has risks. Speck has been 346 extensively analyzed and generally rejected as an AES alternative. 347 But here it is being used as a 64 bit block cipher which AES is not. 348 The risk is mitigated as the key is used to protect a limited number 349 of blocks. In a 4 hour mission with a System Message every 10 350 seconds, there are only 1,440 applications of the Speck cipher, 351 provided that the operator reported to the UA a new location within 352 those 10 second windows. 354 8.3. Crypto Agility 356 The Remote ID System Message does not provide any space for a crypto 357 suite indicator or any other method to manage crypto agility. 359 All crypto agility is left to the USS policy and the relation between 360 the USS and operator. The selection of the ECIES public key 361 algorithm, the shared secret key derivation function, and the actual 362 symmetric cipher used for on the System Message are set by the USS 363 which informs the operator what to do. 365 9. Acknowledgments 367 The recommendation to use Speck for the block cipher comes after 368 discussions on the IRTF CFRG mailing list. Better known ciphers will 369 not work for this situation without changes to the System Message 370 content. 372 10. Normative References 374 [NIST.SP.800-38A] 375 Barker, E., Chen, L., and R. Davis, "Recommendation for 376 key-derivation methods in key-establishment schemes", 377 National Institute of Standards and Technology report, 378 DOI 10.6028/nist.sp.800-56cr1, April 2018, 379 . 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 387 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 388 May 2017, . 390 11. Informative References 392 [drip-requirements] 393 Card, S., Wiethuechter, A., and R. Moskowitz, "Drone 394 Remote Identification Protocol (DRIP) Requirements", Work 395 in Progress, Internet-Draft, draft-card-drip-reqs-01, 24 396 March 2020, 397 . 399 [F3411-19] ASTM International, "Standard Specification for Remote ID 400 and Tracking", February 2020, 401 . 403 [ISO.29167-22] 404 ISO - International Organization for Standardization, 405 "Crypto suite SPECK security services for air interface 406 communications", November 2018, 407 . 409 [new-crypto] 410 Moskowitz, R., Card, S., and A. Wiethuechter, "New 411 Cryptographic Algorithms for HIP", Work in Progress, 412 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 413 January 2020, . 416 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 417 for Security", RFC 7748, DOI 10.17487/RFC7748, January 418 2016, . 420 Appendix A. Feistel Scheme 422 This approach is already being used in format-preserving encryption. 424 According to the theory, to provide CCA security guarantees (CCA = 425 Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should 426 choose d >= 6. It seems very ineffective that when shortening the 427 block length, we have to use 6 times more block encryptions. On the 428 other hand, we preserve both the block cipher interface and security 429 guarantees in a simple way. 431 How to encrypt an m-bit plaintext X using an n-bit block cipher 432 E = {E_K} for n > m? 434 Enc(X, K): 435 1. Y <- X. 436 2. Split Y into 2 equal parts: Y = Y1 || Y2 437 (let us assume for simplicity that m is even). 438 3. For i = 1, 2, ..., d do: 439 Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)), 440 where Ci is a (n - m/2)-bit round constant. 441 4. Y <- Y2 || Y1. 442 5. Return Y. 444 Dec(Y, K): 445 1. X <- Y. 446 2. Split X into 2 equal parts: X = X1 || X2. 447 3. For i = d, ..., 2, 1 do: 448 X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)). 449 4. X <- X2 || X1. 450 5. Return X. 452 Authors' Addresses 454 Robert Moskowitz 455 HTT Consulting 456 Oak Park, MI 48237 457 United States of America 459 Email: rgm@labs.htt-consult.com 461 Stuart W. Card 462 AX Enterprize 463 4947 Commercial Drive 464 Yorkville, NY 13495 465 United States of America 467 Email: stu.card@axenterprize.com 468 Adam Wiethuechter 469 AX Enterprize 470 4947 Commercial Drive 471 Yorkville, NY 13495 472 United States of America 474 Email: adam.wiethuechter@axenterprize.com