DRIP                                                        R. Moskowitz
Internet-Draft                                            HTT Consulting
Intended status: Standards Track                                 S. Card
Expires: 29 October 2020                                 A. Wiethuechter
                                                           AX Enterprize
                                                           27 April 2020


               UAS Operator Privacy for RemoteID Messages
                draft-moskowitz-drip-operator-privacy-02

Abstract

   This document describes a method of providing privacy for UAS
   Operator information specified in the ASTM UAS Remote ID and Tracking
   messages.  This is achieved by encrypting, in place, those fields
   containing Operator sensitive data using a hybrid ECIES.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 29 October 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.



Moskowitz, et al.        Expires 29 October 2020                [Page 1]


Internet-Draft              Operator Privacy                  April 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Operator - USS Security Relationship  . . . . . . . . . .   5
   4.  System Message Privacy  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Rules for encrypting System Message content . . . . . . .   5
     4.2.  Rules for decrypting System Message content . . . . . . .   6
     4.3.  Using AES-CFB16 in the System Message . . . . . . . . . .   6
     4.4.  Using Speck in the System Message . . . . . . . . . . . .   6
     4.5.  Using a Feistel scheme in the System Message  . . . . . .   7
     4.6.  Using AES-CTR in the System Message . . . . . . . . . . .   7
   5.  DRIP Requirements addressed . . . . . . . . . . . . . . . . .   7
   6.  ASTM Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.1.  CFB16 Risks . . . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  Speck Risks . . . . . . . . . . . . . . . . . . . . . . .   8
     8.3.  Crypto Agility  . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   11. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Feistel Scheme . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document defines a mechanism to provide privacy in the ASTM
   Remote ID and Tracking messages [F3411-19] by encrypting, in place,
   those fields that contain sensitive UAS Operator information.  An
   example of such, and the initial application of this mechanism is the
   8 bytes of UAS Operator (hereafter called simply Operator) longitude
   and latitude location in the System Message.  This meets the Drip
   Requirements [drip-requirements], Priv-01.

   It is assumed that the Operator registers a mission with a USS.
   During this mission registration, the Operator and USS exchange
   public keys to use in the hybrid ECIES.  The USS key may be long
   lived, but the Operator key SHOULD be unique to a specific mission.
   This provides protection if the ECIES secret is exposed from prior
   missions.

   The actual Tracking message field encryption MUST be an "encrypt in
   place" cipher.  There is rarely any room in the tracking messages for
   a cipher IV or encryption MAC.  There is rarely any data in the
   messages that can be used as an IV.  A number of ciphers are proposed



Moskowitz, et al.        Expires 29 October 2020                [Page 2]


Internet-Draft              Operator Privacy                  April 2020


   here that can encrypt exactly 64 bits.  It is not a simple, encrypt
   these 64 bits with these ECIES derived key.  The Operator may move
   during a mission and these fields change, correspondingly.  Further,
   not all messages will be received by the USS, so each message's
   encryption must stand on its own, but not be at risk of attack by the
   content of other messages.

   Future applications of this mechanism may be provided.  The content
   of the System Message may change, requiring encrypting a different
   amount of data.  At that time, they will be added to this document.

2.  Terms and Definitions

2.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Definitions

   B-RID
      Broadcast Remote ID.  A method of sending RID messages as 1-way
      transmissions from the UA to any Observers within radio range.

   CAA
      Civil Aeronautics Administration.  An example is the Federal
      Aviation Administration (FAA) in the United States of America.

   ECIES
      Elliptic Curve Integrated Encryption Scheme.  A hybrid encryption
      scheme which provides semantic security against an adversary who
      is allowed to use chosen-plaintext and chosen-ciphertext attacks.

   GCS
      Ground Control Station.  The part of the UAS that the remote pilot
      uses to exercise C2 over the UA, whether by remotely exercising UA
      flight controls to fly the UA, by setting GPS waypoints, or
      otherwise directing its flight.

   Observer
      Referred to in other UAS documents as a "user", but there are also
      other classes of RID users, so we prefer "observer" to denote an
      individual who has observed an UA and wishes to know something
      about it, starting with its RID.




Moskowitz, et al.        Expires 29 October 2020                [Page 3]


Internet-Draft              Operator Privacy                  April 2020


   N-RID
      Network Remote ID.  A method of sending RID messages via the
      Internet connection of the UAS directly to the UTM.

   Net-RID DP
      Network RID Display Provider.  Logical entity that aggregates data
      from Net-RID SPs as needed in response to user queries regarding
      UAS operating within specified airspace volumes, to enable display
      by a user application on a user device.  Under the FAA NPRM, not
      recognized as a distinct entity, but a service provided by USS,
      including Public Safety USS that may exist primarily for this
      purpose rather than to manage any subscribed UAS.

   RID
      Remote ID.  A unique identifier found on all UA to be used in
      communication and in regulation of UA operation.

   UA
      Unmanned Aircraft.  In this document UA's are typically though of
      as drones of commercial or military variety.  This is a very
      strict definition which can be relaxed to include any and all
      aircraft that are unmanned.

   UAS
      Unmanned Aircraft System.  Composed of Unmanned Aircraft and all
      required on-board subsystems, payload, control station, other
      required off-board subsystems, any required launch and recovery
      equipment, all required crew members, and C2 links between UA and
      the control station.

   USS
      UAS Service Supplier.  Provide UTM services to support the UAS
      community, to connect Operators and other entities to enable
      information flow across the USS network, and to promote shared
      situational awareness among UTM participants.  (From FAA UTM
      ConOps V1, May 2018).

   UTM
      UAS Traffic Management.  A "traffic management" ecosystem for
      uncontrolled operations that is separate from, but complementary
      to, the FAA's Air Traffic Management (ATM) system.










Moskowitz, et al.        Expires 29 October 2020                [Page 4]


Internet-Draft              Operator Privacy                  April 2020


3.  The Operator - USS Security Relationship

   All CAAs have rules defining which UAS must be registered to operate
   in their National Airspace.  This includes UAS and Operator
   registration in a USS.  Further, operator's are expected to report
   flight missions to their USS.  This mission reporting provides a
   mechanism for the USS and operator to establish a mission security
   context.  Here it will be used to exchange public keys for use in
   ECIES.

   The operator's public key SHOULD be unique for each mission.  The USS
   public key may be unique for each operator and mission, but not
   required.  For best post-compromise security (PCS), even the USS
   public key should be changed over some operational window.

   The public key algorithm should be Curve25519 [RFC7748].
   Correspondingly, the ECIES 128 bit shared secret should be generated
   using KMAC as specified in sec 5 of [new-crypto].

4.  System Message Privacy

   The System Message contains 8 bytes of Operator specific information:
   Longitude and Latitude of the Remote Pilot of the UA.  The GCS can
   encrypt these as follows.

   The 8 bytes of Operator information are encrypted, using the ECIES
   128 bit shared secret with one of the cipher's specified below.  The
   choice of cipher sys_msgis based on USS policy and is agreed to as
   part of the mission registration.  AES-CFB16 is the recommended
   default cipher.

   ASTM Remote ID and Tracking messages [F3411-19] SHOULD be updated to
   allow Bit 2 of the Flags byte in the System Message set to "1" to
   indicate the Operator information is encrypted.

   The USS similarly decrypts these 8 bytes and provides the information
   to authorized entities.

4.1.  Rules for encrypting System Message content

   If the Operator location is encrypted the encrypted bit flag MUST be
   set to 1.

   The Operator MAY be notified by the USS that the mission has entered
   a location or time where privacy of Operator location is not allowed.
   In this case the Operator MUST disable this privacy feature and send
   the location unencrypted or land the UA or route around the
   restricted area.



Moskowitz, et al.        Expires 29 October 2020                [Page 5]


Internet-Draft              Operator Privacy                  April 2020


   If the Operator looses connectivity to the USS, the privacy feature
   SHOULD be disabled or land the UA.

   If the mission is in an area or time with no Internet Connectivity,
   the privacy feature MUST NOT be used.

4.2.  Rules for decrypting System Message content

   An Observer receives a System Message with the encrypt bit set to 1.
   The Observer sends a query to its NET-RID DP containing the UA's ID
   and the encrypted fields.

   The NET-RID DP MAY deny the request if the Observer does not have the
   proper authorization.

   The NET-RID DP MAY reply to the request with the decrypted fields if
   the Observer has the proper authorization.

   The NET-RID DP MAY reply to the request with the decrypting key if
   the Observer has the proper authorization.

   The Observer MAY notify the USS that content privacy for a UAS in
   this location/time is not allowed.  If the Observer has the proper
   authorization for this action, the USS notifies the Operator to
   disable this privacy feature.

4.3.  Using AES-CFB16 in the System Message

   CFB16 is defined in [NIST.SP.800-38A], Section 6.3.  This is the
   Cipher Feedback (CFB) mode operating on 16 bits at a time.  This
   variant of CFB can be used to encrypt any multiple of 2 bytes of
   cleartext.

   The Operator includes a 64 bit UNIX timestamp for the mission time,
   along with its mission pubic key.  The Operator also includes the UA
   MAC address (or multiple addresses if flying multiple UA).

   The 128 bit IV for AES-CFB16 is constructed by the Operator and USS
   as: SHAKE128(MAC|UTCTime, 128).

   AES-CFB16 would then be used to encrypt the Operator information.

4.4.  Using Speck in the System Message

   Speck [ISO.29167-22] is a 64 bit block cipher and can be applied
   directly to the 8 bytes Operator information, using the 128 bit
   Operator/USS shared secret.




Moskowitz, et al.        Expires 29 October 2020                [Page 6]


Internet-Draft              Operator Privacy                  April 2020


4.5.  Using a Feistel scheme in the System Message

   If the encryption speed doesn't matter, we can use the following
   approach based on the Feistel scheme.  This approach is already being
   used in format-preserving encryption.  The Feistal scheme is
   explained in Appendix A.

4.6.  Using AES-CTR in the System Message

   If 2 bytes of the System Message can be set aside to contain a
   counter that is incremented each time the Operator information
   changes, AES-CTR can be used as follows.

   The Operator includes a 64 bit UNIX timestamp for the mission time,
   along with its mission pubic key.  The Operator also includes the UA
   MAC address (or multiple addresses if flying multiple UA).

   The high order bits of an AES-CTR counter is constructed by the
   Operator and USS as: SHAKE128(MAC|UTCTime, 112).

   AES-CTR would then be used to encrypt the Operator information.

5.  DRIP Requirements addressed

   This document provides solution to PRIV-1 for PII in the ASTM System
   Message.

6.  ASTM Considerations

   ASTM will need to make the following changes to the "Flags" in the
   System Message:

   Bit 2:
      Value 1 for encrypted; 0 for cleartext (see Section 4).

7.  IANA Considerations

   TBD

8.  Security Considerations

   An attacker has no known text after decrypting to determine a
   successful attack.  An attacker can make assumptions about the high
   order byte values for Operator Longitude and Latitude that may
   substitute for known cleartext.  There is no knowledge of where the
   operator is in relation to the UA.  Only if changing location values
   "make sense" might an attacker assume to have revealed the operator's
   location.



Moskowitz, et al.        Expires 29 October 2020                [Page 7]


Internet-Draft              Operator Privacy                  April 2020


8.1.  CFB16 Risks

   Using the same IV for different Operator information values with
   CFB16 presents a cyptoanalysis risk.  Typically only the low order
   bits would change as the Operators position changes.  Thus the first
   2 encrypted bytes would not change, and only subsequent bytes would.
   The risk is mitigated due to the short-term value of the data.
   Further analysis is need to properly place risk.

8.2.  Speck Risks

   The use of Speck for the block cipher has risks.  Speck has been
   extensively analyzed and generally rejected as an AES alternative.
   But here it is being used as a 64 bit block cipher which AES is not.
   The risk is mitigated as the key is used to protect a limited number
   of blocks.  In a 4 hour mission with a System Message every 10
   seconds, there are only 1,440 applications of the Speck cipher,
   provided that the operator reported to the UA a new location within
   those 10 second windows.

8.3.  Crypto Agility

   The Remote ID System Message does not provide any space for a crypto
   suite indicator or any other method to manage crypto agility.

   All crypto agility is left to the USS policy and the relation between
   the USS and operator.  The selection of the ECIES public key
   algorithm, the shared secret key derivation function, and the actual
   symmetric cipher used for on the System Message are set by the USS
   which informs the operator what to do.

9.  Acknowledgments

   The recommendation to use Speck for the block cipher comes after
   discussions on the IRTF CFRG mailing list.  Better known ciphers will
   not work for this situation without changes to the System Message
   content.

10.  Normative References

   [NIST.SP.800-38A]
              Barker, E., Chen, L., and R. Davis, "Recommendation for
              key-derivation methods in key-establishment schemes",
              National Institute of Standards and Technology report,
              DOI 10.6028/nist.sp.800-56cr1, April 2018,
              <https://doi.org/10.6028/nist.sp.800-56cr1>.





Moskowitz, et al.        Expires 29 October 2020                [Page 8]


Internet-Draft              Operator Privacy                  April 2020


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.  Informative References

   [drip-requirements]
              Card, S., Wiethuechter, A., and R. Moskowitz, "Drone
              Remote Identification Protocol (DRIP) Requirements", Work
              in Progress, Internet-Draft, draft-card-drip-reqs-01, 24
              March 2020,
              <https://tools.ietf.org/html/draft-card-drip-reqs-01>.

   [F3411-19] ASTM International, "Standard Specification for Remote ID
              and Tracking", February 2020,
              <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.

   [ISO.29167-22]
              ISO - International Organization for Standardization,
              "Crypto suite SPECK security services for air interface
              communications", November 2018,
              <https://www.iso.org/standard/70389.html>.

   [new-crypto]
              Moskowitz, R., Card, S., and A. Wiethuechter, "New
              Cryptographic Algorithms for HIP", Work in Progress,
              Internet-Draft, draft-moskowitz-hip-new-crypto-04, 23
              January 2020, <https://tools.ietf.org/html/draft-
              moskowitz-hip-new-crypto-04>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

Appendix A.  Feistel Scheme

   This approach is already being used in format-preserving encryption.









Moskowitz, et al.        Expires 29 October 2020                [Page 9]


Internet-Draft              Operator Privacy                  April 2020


   According to the theory, to provide CCA security guarantees (CCA =
   Chosen Ciphertext Attacks) for m-bit encryption X |-> Y, we should
   choose d >= 6.  It seems very ineffective that when shortening the
   block length, we have to use 6 times more block encryptions.  On the
   other hand, we preserve both the block cipher interface and security
   guarantees in a simple way.

   How to encrypt an m-bit plaintext X using an n-bit block cipher
       E = {E_K} for n > m?

       Enc(X, K):
         1. Y <- X.
         2. Split Y into 2 equal parts: Y = Y1 || Y2
         (let us assume for simplicity that m is even).
         3. For i = 1, 2, ..., d do:
           Y <- Y2 || (Y1 ^ first_m/2_bits(E_K(Y2 || Ci)),
         where Ci is a (n - m/2)-bit round constant.
         4. Y <- Y2 || Y1.
         5. Return Y.

       Dec(Y, K):
         1. X <- Y.
         2. Split X into 2 equal parts: X = X1 || X2.
         3. For i = d, ..., 2, 1 do:
           X <- X2 || (X1 ^ first_m/2_bits(E_K(X2 || Ci)).
         4. X <- X2 || X1.
         5. Return X.

Authors' Addresses

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI 48237
   United States of America

   Email: rgm@labs.htt-consult.com


   Stuart W. Card
   AX Enterprize
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: stu.card@axenterprize.com






Moskowitz, et al.        Expires 29 October 2020               [Page 10]


Internet-Draft              Operator Privacy                  April 2020


   Adam Wiethuechter
   AX Enterprize
   4947 Commercial Drive
   Yorkville, NY 13495
   United States of America

   Email: adam.wiethuechter@axenterprize.com












































Moskowitz, et al.        Expires 29 October 2020               [Page 11]