UAS Operator Privacy for RemoteID Messages

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 9 November 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.¶

Table of Contents

2. Terms and Definitions

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 ECIES public key SHOULD be unique for each mission. The USS ECIES public key may be unique for each operator and mission, but not required. For best post-compromise security (PCS), even the USS ECIES 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 Operator (Pilot in the field description) of the UA. The GCS MAY encrypt these as follows.¶

The 8 bytes of Operator information are encrypted, using the ECIES derived 128 bit shared secret, with one of the cipher's specified below. The choice of cipher is 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.¶

5. Operator ID Message Privacy

The Operator ID Message contains 20 bytes for Operator the ID. The GCS MAY encrypt these as follows.¶

The 20 bytes Operator ID is encrypted, using the ECIES derived 128 bit shared secret, with one of the cipher's specified below. The choice of cipher is 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 Operator ID Type in the Operator ID Message set to "1" to indicate the Operator ID is encrypted.¶

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

6. Cipher choices for Operator PII encryption

7. DRIP Requirements addressed

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

8. 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).¶

ASTM will need to make the following changes to the "Operator ID Type" in the Operator ID Message:¶

Operator ID Type

Value 1 for encrypted Operator ID (see Section 5).¶

9. IANA Considerations

TBD¶

Appendix A. Feistel Scheme

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

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