idnits 2.17.1 draft-moskowitz-drip-operator-privacy-00.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 (31 March 2020) is 1486 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: 2 October 2020 A. Wiethuechter 6 AX Enterprize 7 31 March 2020 9 Operator Privacy for RemoteID Messages 10 draft-moskowitz-drip-operator-privacy-00 12 Abstract 14 This document describes a method of providing privacy for Operator 15 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 2 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 . . . . . . . . . . 4 57 4. System Message Privacy . . . . . . . . . . . . . . . . . . . 4 58 4.1. Using AES in the System Message . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6.1. Crypto Agility . . . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 9. Informative References . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 This document defines a mechanism to provide privacy in the ASTM 70 Remote ID and Tracking messages [F3411-19] by encrypting, in place, 71 those fields that contain sensitive Operator information. An example 72 of such, and the initial application of this mechanism is the 73 Operator longitude and latitude location in the System Message. 75 It is assumed that the Operator registers a mission with a USS. 76 During this mission registration, the Operator and USS exchange 77 public keys to use in the hybrid ECIES. The USS key may be long 78 lived, but the Operator key SHOULD be unique to a specific mission. 79 This provides protection if the ECIES secret is exposed from prior 80 missions. 82 The actual Tracking message field encryption MUST be an "encrypt in 83 place" cipher. There is rarely any room in the tracking messages for 84 a cipher IV or encryption MAC. There is rarely any data in the 85 messages that can be used as an IV. A cipher that meets this 86 requirement is SPECK [Need Reference]; which is an initial 87 recommendation. There are risks with this cipher, only partially 88 mitigated by the ephemeral nature of the sensitive Operator 89 information in the Tracking messages and the short-lived nature of 90 the ECIES secret. Other ciphers will be investigated. 92 Future applications of this mechanism may be provided. At that time, 93 they will be added to this document. 95 2. Terms and Definitions 97 2.1. Requirements Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 2.2. Definitions 107 B-RID 108 Broadcast Remote ID. A method of sending RID messages as 1-way 109 transmissions from the UA to any Observers within radio range. 111 CAA 112 Civil Aeronautics Administration. An example is the Federal 113 Aviation Administration (FAA) in the United States of America. 115 ECIES 116 Elliptic Curve Integrated Encryption Scheme. A hybrid encryption 117 scheme which provides semantic security against an adversary who 118 is allowed to use chosen-plaintext and chosen-ciphertext attacks. 120 GCS 121 Ground Control Station. The part of the UAS that the remote pilot 122 uses to exercise C2 over the UA, whether by remotely exercising UA 123 flight controls to fly the UA, by setting GPS waypoints, or 124 otherwise directing its flight. 126 Observer 127 Referred to in other UAS documents as a "user", but there are also 128 other classes of RID users, so we prefer "observer" to denote an 129 individual who has observed an UA and wishes to know something 130 about it, starting with its RID. 132 N-RID 133 Network Remote ID. A method of sending RID messages via the 134 Internet connection of the UAS directly to the UTM. 136 RID 137 Remote ID. A unique identifier found on all UA to be used in 138 communication and in regulation of UA operation. 140 UA 141 Unmanned Aircraft. In this document UA's are typically though of 142 as drones of commercial or military variety. This is a very 143 strict definition which can be relaxed to include any and all 144 aircraft that are unmanned. 146 UAS 147 Unmanned Aircraft System. Composed of Unmanned Aircraft and all 148 required on-board subsystems, payload, control station, other 149 required off-board subsystems, any required launch and recovery 150 equipment, all required crew members, and C2 links between UA and 151 the control station. 153 USS 154 UAS Service Supplier. Provide UTM services to support the UAS 155 community, to connect Operators and other entities to enable 156 information flow across the USS network, and to promote shared 157 situational awareness among UTM participants. (From FAA UTM 158 ConOps V1, May 2018). 160 UTM 161 UAS Traffic Management. A "traffic management" ecosystem for 162 uncontrolled operations that is separate from, but complementary 163 to, the FAA's Air Traffic Management (ATM) system. 165 3. The Operator - USS Security Relationship 167 All CAAs have rules defining which UAS must be registered to operate 168 in their National Airspace. This includes UAS and Operator 169 registration in a USS. Further, operator's are expected to report 170 flight missions to their USS. This mission reporting provides a 171 mechanism for the USS and operator to establish a mission security 172 context. Here it will be used to exchange public keys for use in 173 ECIES. 175 The operator's public key SHOULD be unique for each mission. The USS 176 public key may be unique for each operator and mission, but not 177 required. For best post-compromise security (PCS), even the USS 178 public key should be changed over some operational window. 180 The public key algorithm should be Curve25519 [RFC7748]. 181 Correspondingly, the ECIES 128 bit shared secret should be generated 182 using KMAC as specified in sec 5 of [new-crypto]. 184 4. System Message Privacy 186 The System Message contains 8 bytes of Operator specific information: 187 Longitude and Latitude of the Remote Pilot of the UA. The GCS can 188 encrypt these as follows. 190 The 8 bytes of Operator information are encrypted, using the ECIES 191 128 bit shared secret with Speck64/128. 193 Bit 2 of the Flags byte is set to "1" to indicate the Operator 194 information is encrypted. 196 The USS similarly decrypts these 8 bytes and provides the information 197 to authorized entities. 199 4.1. Using AES in the System Message 201 If 2 bytes of the System Message can be set aside to contain a 202 counter that is incremented each time the Operator information 203 changes, AES-CTR can be used as follows. 205 The Operator includes a 64 bit UNIX timestamp for the mission time, 206 along with its mission pubic key. The Operator also includes the UA 207 MAC address (or multiple addresses if flying multiple UA). 209 The high order bits of an AES-CTR counter is constructed by the 210 Operator and USS as: LTRUNC(HASH(MAC|UTCTime), 14). 212 AES-CTR would then be used to encrypt the Operator information. 214 5. IANA Considerations 216 TBD 218 6. Security Considerations 220 The use of Speck for the block cipher has risks. Speck has been 221 extensively analyzed. The risk is mitigated as the key is used to 222 protect a limited number of blocks. In a 4 hour mission with a 223 System Message every 10 seconds, there are only 1,440 applications of 224 the Speck cipher, provided that the operator reported to the UA a new 225 location within those 10 second windows. 227 Further, an attacker has no known text after decrypting to determine 228 a successful attack. There is no knowledge of where the operator is 229 in relation to the UA. Only if changing location values "make sense" 230 might an attacker assume to have revealed the operator's location. 232 6.1. Crypto Agility 234 The Remote ID System Message does not provide any space for a crypto 235 suite indicator or any other method to manage crypto agility. 237 All crypto agility is left to the USS policy and the relation between 238 the USS and operator. The selection of the ECIES public key 239 algorithm, the shared secret key derivation function, and the actual 240 symmetric cipher used for on the System Message are set by the USS 241 which informs the operator what to do. 243 7. Acknowledgments 245 The recommendation to use Speck for the block cipher comes after 246 discussions on the IRTF CFRG mailing list. Better known ciphers will 247 not work for this situation without changes to the System Message 248 content. 250 8. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 258 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 259 May 2017, . 261 9. Informative References 263 [F3411-19] ASTM International, "Standard Specification for Remote ID 264 and Tracking", February 2020, 265 . 267 [new-crypto] 268 Moskowitz, R., Card, S., and A. Wiethuechter, "New 269 Cryptographic Algorithms for HIP", Work in Progress, 270 Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23 271 January 2020, . 274 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 275 for Security", RFC 7748, DOI 10.17487/RFC7748, January 276 2016, . 278 Authors' Addresses 280 Robert Moskowitz 281 HTT Consulting 282 Oak Park, MI 48237 283 United States of America 284 Email: rgm@labs.htt-consult.com 286 Stuart W. Card 287 AX Enterprize 288 4947 Commercial Drive 289 Yorkville, NY 13495 290 United States of America 292 Email: stu.card@axenterprize.com 294 Adam Wiethuechter 295 AX Enterprize 296 4947 Commercial Drive 297 Yorkville, NY 13495 298 United States of America 300 Email: adam.wiethuechter@axenterprize.com