Internet-Draft LTE-D Physical Layer Device Authenticati October 2023
Yang, et al. Expires 19 April 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-yu-deviceauthentication-01
Published:
Intended Status:
Informational
Expires:
Authors:
Y. Yang
China Automotive Innovation Corporation
P. Guo
China Automotive Innovation Corporation
J. Yu
Purple Mountain Laboratories, China

LTE-D Physical Layer Device Authentication Protocol

Abstract

This document describes a physical layer device authentication protocol based on the physical layer unclonable fingerpint (PUF) technique for LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle-to-Everything), to help the LTE-D message receiver confirm the identity of the LTE-D message sender.

PUF utilizes intrinsic nonlinear characters of the transmission signal to identificate the devices and coresponding wireless signal transmitters, and is suitable for critical vehicular communication scenarios by its immunity against traditional cryptographic attacks.

The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism.

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 3 April 2024.

Table of Contents

1. Introduction

LTE Direct (LTE-D), a subprotocol of LTE V2X (Vehicle-to-Everything), is designed for device-to-device communication within vehicular environments. LTE-D lies in its potential to enable direct, efficient, and low-latency communication between nearby devices, fostering enhanced safety, cooperative driving, and diverse applications in the automotive landscape.

To realize the benefits and ensure the integrity and security of communications, authentication mechanisms for high-level security are imperative.

A novial technique called physical layer unclonable fingerpint (PUF) is proposed for device authentication, which does not rely on cryptographic algorithms or keys, but utilizes intrinsic nonlinear characters of the transmission signal to identificate devices with coresponding wireless signal transmitters, and is suitable for enhancing the security of critical vehicular communication scenario by tis immunity against traditional cryptographic attacks.

A PUF system is composed by two kinds of components, the capturing frontends and the identification backend.

A PUF capture frontend is often implemented by a Software Radio Platform (SRP), which captures wireless signals and extracts device characters (device fingerprint) from them.

A PUF identification backend is a program with a database of pre-collected device fingerprints of varied devices, which takes device fingerprint as input and outputs the identification result.

This document describes an physical layer device authentication protocol based on the PUF technique to help the LTE-D message receiver confirm the identity of the LTE-D message sender. The protocol can be seamlessly integrated into the LTE-D communication system, and compatible with the traditional cryptography-based authentication mechanism.

2. Conventions and Definitions

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.

[RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3

3. Device Authentication Protocol

The device authentication protocol contains only two messages and only involves the receiver, equipped with a PUF capture frontend, and the authenticator, equipped with a PUF identification backend. Notice that the sender does not need more interactions than normal LTE-D communication processes, and the traditional first step of authentication, i.e. initiating the authentication, is understood by the action of sending messages.

3.1. Device Authentication Request

The Receiver initiates the authentication process by sending a request to the Authenticator.

                +---------------------------+---------+
                | Field                     | Length  |
                +---------------------------+---------+
                | Message Type              | 8 bits  |
                +---------------------------+---------+
                | Endian Type               | 1 bits  |
                +---------------------------+---------+
                | Reserved                  | 7 bits  |
                +---------------------------+---------+
                | Receiver ID               | 16 bits |
                +---------------------------+---------+
                | Serial Number             | 32 bits |
                +---------------------------+---------+
                | Timestamp                 | 64 bits |
                +---------------------------+---------+
                | Nonce                     | 64 bits |
                +---------------------------+---------+
                | Signal Data Length        | 32 bits |
                +---------------------------+---------+
                | Signal Data               | variable|
                |                           | length  |
                +---------------------------+---------+
Figure 1: Table of fields included in the request
  1. Message Type (8 bits)

    8 bits for fixed message type, i.e., 0x10, for Device Authentication Request.

  2. Endian Type (1 bits)

    0 for little endian, 1 for big endian.

  3. Receiver ID (32 bits)

    Unique identifier for the Receiver.

  4. Serial Number (32 bits)

    A serial number indicating the receive order of the message.

  5. Timestamp (64 bits)

    A timestamp indicating when the request was generated.

  6. Nonce (64 bits)

    A random value generated by the device to prevent replay attacks.

  7. Signal Data Length (32 bits)

    The length of the following signal data, in octets.

  8. Signal Data (variable length)

    Data captured by the SRP of the receiver that contains enough information to authentication.

3.2. Device Authentication Response

The Authenticator processes the request, comparing the signal data with the pre-collected fingerprints and decoding the data by the PUF Backend, then sends the result back to the Receiver.

                +---------------------------+---------+
                | Field                     | Length  |
                +---------------------------+---------+
                | Message Type              | 8 bits  |
                +---------------------------+---------+
                | Endian Type               | 1 bits  |
                +---------------------------+---------+
                | Confidence Coefficient    | 7 bits  |
                +---------------------------+---------+
                | Sender ID                 | 16 bits |
                +---------------------------+---------+
                | Serial Number             | 32 bits |
                +---------------------------+---------+
                | Timestamp                 | 64 bits |
                +---------------------------+---------+
                | Nonce                     | 64 bits |
                +---------------------------+---------+
                | Decoded Data Length       | 32 bits |
                +---------------------------+---------+
                | Decoded Data              | variable|
                |                           | length  |
                +---------------------------+---------+
Figure 2: Table of fields included in the response
  1. Message Type (8 bits)

    8 bits for fixed message type, i.e., 0x20, for Device Authentication Response.

  2. Endian Type (1 bits)

    0 for little endian, 1 for big endian.

  3. Confidence Coefficient (7 bits)

    The confidence coefficient of the following calculated sender ID given by the PUF backend, in percent, from 0 to 100. Any value above 100 is illegal.

  4. Sender ID (32 bits)

    • Unique identifier for the Sender, identified by the Authenticator with the pre-collected fingerprints.

    • The ID 0xFFFFFFFF is reserved for unknown sender.

  5. Serial Number (32 bits)

    A serial number corresponding with the request.

  6. Timestamp (64 bits)

    A timestamp indicating when the response was generated.

  7. Nonce (64 bits)

    A random value generated by the device to prevent replay attacks.

  8. Decoded Data Length (32 bits)

    The length of the following decoded data, in octets.

  9. Decoded Data (variable length)

    Data decoded by the signal data from the coresponding authentication request message.

4. Security Considerations

To ensure the confidentiality, integrity, and authenticity of communication within the LTE-D Physical Layer Device Authentication Protocol, it is crucial to employ strong encryption and integrity mechanisms for the exchanged messages among all the parties of the protocol. Leveraging Transport Layer Security (TLS)[RFC8446] is highly recommended for this purpose.

5. IANA Considerations

This document does not require any actions or registrations with the Internet Assigned Numbers Authority (IANA).

6. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.

Authors' Addresses

Yanzhao Yang
China Automotive Innovation Corporation
Peng Guo
China Automotive Innovation Corporation
Jiabao Yu
Purple Mountain Laboratories, China