Internet-Draft RFF ACCESS February 2022
Fang, et al. Expires 21 August 2022 [Page]
Workgroup:
Southeast University
Internet-Draft:
draft-dawei-access-authentication-physical-layer-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Fang
Southeast University
A. Hu
Southeast University
H. Fu
Southeast University
Y. Jiang
Southeast University

IoT Access Authentication Framework based on Radio Frequency Fingerprint and Fingerprint Expression Specification

Abstract

This document specifies the uniform expression and format of different kinds of wireless radio frequency fingerprints. It also specifies the structure and functions of wireless authentication framework on fingerprints, including the specification of the signal frames' structure. This document is applicable to the construction and management of secure access at the edge of the Internet of things. This document assumes that the reader is familiar with some concepts and details regarding physical layer security.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 21 August 2022.

Table of Contents

1. Introduction

The classical device-authentication methods includes MAC address, pre-shared key. However, the MAC address is easy to be imitated. Radio frequency fingerprint (RFF) is a physical layer inherent characteristic for a device. Utilizing the RFF for terminal access control, it is possible to realize identity authentication by received waveforms.

Some RFF features can be used for classification and identification. Different kinds of RFF extraction algorithms would generate features with different expressions[I-D.linning-authentication-physical-layer]. Hybrid features would be used to improve identification relability in practical use.So The wireless access control system based on RFF must support different kinds of fingerprint expressions and be compatible with the existing authentication framework. Besides uniforming the RFF expressions could make the framework suitable for a variety of IoT devices. As a new authentication key, RF fingerprint is incorporated into the access control system. This requires the unified expression format, coding, control signal frame, status code and other specifications of fingerprint.

2. Glossary

IoT Device Access Gateway

Trust Center

Lower Computer

CSMA/CD

ASCII

3. RF Fingerprint Access Control Framework

RF fingerprint access control framework uses RF fingerprint as the authentication token for access. It is different from the traditional authentication mode which depends on the pair of MAC address and secure key. It substitutes the secure key with RF fingerprint. When a new network device requests access, if its MAC address is illegal, the access framework will directly reject it. If its MAC address is legal, it will then be judged whether its fingerprint matches its MAC address. If not, it will be considered as an illegal and disguised device with a fake MAC address.

Limited to the weak computing ability of IoT edge devices and the requirement of RF fingerprint extraction algorithm, the access control framework adopts a three-party authentication model. It includes the claimant, relying party, the verifier, and the relationships among them is shown in Figure 1. The claimant refers to the IoT device requesting access to the network. The relying party refers to the nodes which is responsible for access control in the IoT network, such as the central node device or the lower computer of the IP interface. The verifier refers to a trusted third party for RF fingerprint extraction and identification. The verifier and the relying party can be the same entity.

  +-------------------+              +-------------------+
  |     Claimant      | <----------> |   relying party   |
  +-------------------+              +-------------------+
           ^                                    ^
           |                                    |
           |                                    |
           |                                    |
           |                                    |
           |                                    v
           |                          +-------------------+
           +----------------------->  |     verifier      |
                                      +-------------------+

Figure 1: Authentication Model

Figure 2 shows the network architecture after deploying the network model of Figure 1. The RF fingerprint wireless access control system mainly includes physical layer equipment access gateways, authentication servers, proxy servers, signal collectors, etc. The relying party is an entrance gateway of the IP network, or the trust center which is a special device in an IoT network. Therefore, the communication between the relying party and the proxy server requires an appropriate interface. The black and white list of the system is stored in the authentication server.

  +-------------+       +---------------+       +----------------+
  | New Device  |       |  Intermediate |       |  PHY Gateway   |
  | (Claimant)  |<----->|  Device Node  |<----->| /Trust Center  |
  |             |       |               |       | (Relying Party)|
  +-------------+       +---------------+       +----------------+
      ^                                                |   ^
      |                                                |   |
      |                                       1.request|   |4.result
      |        Trusted Environment                     |   |
      |    +-------------------------------------------+--------+
      |    |                                           |   |    |
      |    |                                           v   |    |
      |    | +---------------+ 2.request with RFF +------------+|
      |    | |Authentication | <--------------    |    Proxy   ||
      |    | |    Server     |  -------------->   |  (extract  ||
      |    | +---------------+   3.result         |   feature) ||
      |    |                                      +------------+|
      |    |                                           |  ^     |
      |    |                                           |  |     |
      |    |                                           v  |     |
      |    |                                  +---------------+ |
      +----+--------------------------------> |     Signal    | |
           |                                  |    Collector  | |
           |                                  +---------------+ |
           |                                                    |
           +----------------------------------------------------+
Figure 2: RFF Access Control Model

Detailed access process is described as follows. When a new device applies to join a network, it should firstly establish a connection to parent node. The IP address of the new device is preseted or assigned by its parent node before authenticattion. After the preliminary connection is established, the parent node sends an authentication request, which carries the MAC address of the new device, to the relying party. The relying party sends an authentication request to the proxy server, and the proxy server uses the analog signals received from the new device to extract. Then the proxy server sends a request frame containing the fingerprint to the authentication server.

The signal collector usually keeps monitoring the entire system. Since the wireless network device adopts the CSMA/CD strategy for sending signals, the request frame for joining a network would be captured by the signal collector in real time. Sampling data is already stored in the proxy server before the relying party requests authentication. If the proxy server does not capture the claimant's connection request signal, it will return a status code, ?no fingerprint collected?, to the relying party. Therefore, there are three kinds of status code for authentication: legal, illegal and no fingerprint collected.

The relying party executes access control according to the authentication status code, such that:

4. Specification of Basic Functions of Access Control Framework

The certification service of the verifier shall be independent and impartial, and its authentication results should help to establish a trust relationship between the application system and new IoT device.

The IoT device application layer protocol should provide specific signaling and functional processes for access control framework. Specifically:

The verifier needs to be in a secure and trusted environment. For example, proxy servers, authentication servers, and signal collectors are deployed in a security intranet.

All communication interfaces in the framework should be reliable.

The relying party and the authenticating party should adopt encrypted communication mode, using an independent, preset session key.

The access authentication framework does not specify the fingerprint extraction method and authentication mechanism, and has nothing to do with the signal protocol type of the IoT devices. But all kinds of fingerprints should have a unified expression form.

5. Specification of Fingerprint Expression

5.1. Common RF Fingerprint Types

RF fingerprints mainly include frequency offset, phase offset, power spectral density, adaptive filter coefficients, differential constellation, etc. They could be mainly divided into two types: graphics and numerical values, both of which can be transformed into a one-dimensional vector. According to the type of IoT device and the type of communication protocol, the identification algorithm adopts single or multiple RFF features. Fingerprint identification algorithm classifies and identifies the devices through the differences among feature vectors. Features of one device is stable and similar in different time. Differences of features among different devices are obvious and easy to classify.

5.2. Specification of Expression Format

RF fingerprint is expressed as a one-dimensional vector including no more than 30 elements. If it exceeds 30 elements, feature dimension reduction is required. For features that cannot be reduced to less than 30 elements, feature segmentation and packet transmission shall be carried out.

The one-dimensional RFF feature vector shall fully reflect the fingerprint characteristics of the devices. The feature vector of the same device shall remain relatively stable, while the feature vectors of different devices shall maintain distinguishable differences.

5.3. Specification of Fingerprint Compression Coding

The original fingerprint vector dimension is less than 30 dimensions, and the data storage form is floating point or integer. The compression coding process is presented as follows:

  • Normalize the fingerprint vector , scale the numerical value in (- 1,1).
  • For each one-dimensional vector, convert it to binary decimal and 24 significant digits are reserved. The first bit is the sign bit. The sign bit 0 indicates that the value is positive and 1 indicates that the value is negative.
  • The 64 symbols 48 ~ 90 and 97 ~ 117 in the ASCII code table are used as the mapping table. The 24 bit binary is grouped into 4 groups according to 6 bits. Convert every 6-bit binary decimal to 1-bit 64 decimal. Then map the 64-decimal symbol to an ASCII symbol according to the index. Thus, each one-dimensional data coding dimension is decoded by 4 ASCII symbols.
  • Convert all dimensions of all vectors to ASCII symbols and splice them into strings. The string length is less than or equal to 120 characteristics. This string is the fingerprint formal expression.

6. Specification of Control Message in Framework

The control message is compatible with radius protocol, in which attributes, functions and maximum length are in accordance with radius protocol.

The control message is compatible with RADIUS protocolRFC 2865 [RFC2865], in which attributes, functions and maximum length are in accordance with radius protocol.

6.1. RFF Access Message Format

The message format shall at least contain five fields: frame type, identifier, frame length, authenticator and attribute. The detailed description is shown in Figure 3.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Code      |   Identifier  |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                  Respones Authenticator                       |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Attributes ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: RFF Access Message Format

Code

  • Describe the type of message. 1 indicates access request message, while 2 indicates access accept message.

Identifier

  • Identify the message serial number, which is used to match the request message and response message, and detect the request message retransmitted within a period of time.

Length

  • The length of access control message. Bytes exceeding the length value are ignored as padding characters. If the actual length of the received message is less than the value of length, the message will be discarded.

Response Authenticator

  • Verify the response message of servers. Authenticator in the request message is a random number, followed by MD5 of shared key and random number.

Attributes

  • The Attribute field is variable in length. It is the content body of the message. attributes is encoded in Type/Length/Value triplets.

6.2. Attributes Format

The Attribute for RFF access control is specified from atrributes in RADIUS. It only needs one attribute. In a triplet,the first element is the MAC address of the new device,which is a fixed length for devices of one kind. The second element is the length of the triplet. The third element is the encoded fingerprint. Figure 4 shows the structure of the attribute.

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    MAC address    |   Length  |         Fingerprint           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Atrribute Format

7. IANA Considerations

This document includes no request to IANA.

8. Security Considerations

This section will address only security considerations associated with the use of RF fingerprint access control framework. Encrypted communication is required when the access control message is transmitted between the IoT trust center and the third-party server. If the third party is not credible, the access system loses credibility. Therefore, it is necessary to ensure that the relying party and the verifier are in a secure and trusted environment.

9. References

9.1. 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/info/rfc2119>.

9.2. Informative References

[I-D.linning-authentication-physical-layer]
Peng, L. and A. Hu, "Authentication by Physical Layer Features", Work in Progress, Internet-Draft, draft-linning-authentication-physical-layer-00, , <http://www.ietf.org/internet-drafts/draft-linning-authentication-physical-layer-00.txt>.
[RFC2865]
Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, , <https://www.rfc-editor.org/info/rfc2865>.

Authors' Addresses

Dawei Fang
Southeast University
No.2 SiPaiLou
Nanjing
JiangSu, 210096
China
Aiqun Hu
Southeast University
No.2 SiPaiLou
Nanjing
JiangSu, 210096
China
Hua Fu
Southeast University
No.2 SiPaiLou
Nanjing
JiangSu, 210096
China
Yu Jiang
Southeast University
No.2 SiPaiLou
Nanjing
JiangSu, 210096
China

mirror server hosted at Truenetwork, Russian Federation.