LTE-D Physical Layer Device Authentication Protocol
draft-yu-deviceauthentication-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yanzhao Yang , Peng Guo , Jiabao Yu | ||
| Last updated | 2024-04-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yu-deviceauthentication-02
Network Working Group Y. Yang
Internet-Draft P. Guo
Intended status: Informational China Automotive Innovation Corporation
Expires: 16 October 2024 J. Yu
Purple Mountain Laboratories, China
April 2024
LTE-D Physical Layer Device Authentication Protocol
draft-yu-deviceauthentication-02
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 October 2024.
Yang, et al. Expires 16 October 2024 [Page 1]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Device Authentication Protocol . . . . . . . . . . . . . . . 3
3.1. Device Authentication Request . . . . . . . . . . . . . . 3
3.2. Device Authentication Response . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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 novel technique called physical layer unclonable fingerprint (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 identify devices with
corresponding wireless signal transmitters, and is suitable for
enhancing the security of critical vehicular communication scenario
by tis immunity against traditional cryptographic attacks.
Yang, et al. Expires 16 October 2024 [Page 2]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
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.
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.
Yang, et al. Expires 16 October 2024 [Page 3]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
+---------------------------+---------+
| 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)*
Yang, et al. Expires 16 October 2024 [Page 4]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
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)*
Yang, et al. Expires 16 October 2024 [Page 5]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
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 corresponding
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.
Yang, et al. Expires 16 October 2024 [Page 6]
Internet-Draft LTE-D Physical Layer Device Authenticati April 2024
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, March 1997,
<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,
May 2017, <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, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Authors' Addresses
Yanzhao Yang
China Automotive Innovation Corporation
Email: yangyanzhao@t3caic.com
Peng Guo
China Automotive Innovation Corporation
Email: guopeng@t3caic.com
Jiabao Yu
Purple Mountain Laboratories, China
Email: yujiabao@pmlabs.com.cn
Yang, et al. Expires 16 October 2024 [Page 7]