BRSKI-CLE: A Certificateless Enrollment framework in BRSKI

Introduction There are various constrained IoT devices in the hospital, such as anesthesia syringe pumps, electrocardiogram monitors, smart bed cards, etc. The access gateway is required to authenticate each connected IoT device. Otherwise, adversaries can easily steal medical data through illegally accessed devices. Certificates are widely utilized for authentication nowadays. However, the RAM that can be used for authentication is commonly less than 10 KB in constrained medical IoT devices. Moreover, some extremely constrained medical IoT devices only have about 8 KB RAM. These constrained IoT devices are also common in scenarios other than in the hospital. The IoT devices with around 10 KB RAM are defined as Class 1 constrained devices in . The limited RAM resources make the Class 1 constrained IoT devices hard to use certificates. Even using CBOR to encode certificates, the certificate chain is also heavy for the Class 1 constrained IoT devices. The CBOR encoded certificate chain in 4 length is around 4 KB, in 2 length is about 1.5 KB as shown in . The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol provides a solution for secure zero-touch (automated) bootstrap of new (unconfigured) devices that are called "pledges". After being authenticated by the server "registrar", a pledge presents its key material to the network and acquires a network-specific identity. This process is called "enrollment". BRSKI typically uses Enrollment over Secure Transport (EST) , which is based on certificates, as the enrollment protocol. Other alternative enrollment protocols in BRSKI, such as Constrained BRSKI, BRSKI-AE and , are also based on certificates. This document describes a certificateless enrollment framework in BRSKI (BRSKI-CLE) for constrained IoT devices. Considering the evolution towards quantum-safe algorithms, the framework is based on the Key Encapsulation Mechanism (KEM). The framework uses the public key of the server end to encapsulate the symmetric key. The server end only needs to configure one public key to handle an enormous amount of client ends (the IoT devices). Compared with encapsulating by the public key of the client end, such as EDHOC , a unique public key is required to be configured on each IoT device. When the amount of IoT devices is huge, encapsulating by the public key of the client end is less efficient in deployment. The client end is assumed to have previously known the server end's public key in . Otherwise, the client end cannot encapsulate the symmetric key by the server end's public key. In the BRSKI scenario, a pledge cannot previously know a domain server's public key. Thus, the KEM-based authentication mechanism in cannot be utilized in the enrollment of BRSKI directly. The mutual authentication between the pledge and the registrar in BRSKI can also make by EDHOC, as shown in . Moreover, the pledge's credential is supported transporting by reference rather than by value. Therefore, cooperating with the authentication mechanism shown in , a constrained IoT device has no need to configure a public key to identify itself for the whole bootstrapping process. An authentication centre (AC) is used for issuing lightweight credentials, such as CBOR Web Tokens (CWTs), to the pledges in the enrollment phase of BRSKI. This document does not specify any lightweight credentials.

Terminology AC: The authentication centre provides the credential issuance for the pledges. Domain: The set of entities that share a common local trust anchor. enrollment: The process where a device presents key material to a network and acquires a network-specific identity. imprint: The process where a device obtains the cryptographic key material to identify and trust future interactions with a network. This process is the step before enrollment, as defined in BRSKI . Pledge: The prospective (unconfigured) device, which has an identity installed at the factory.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Architecture The architecture of the components in BESKI-CLE is shown in . Compared with the architecture of BRSKI, the CA is replaced by the AC. The AC can be implemented on the registrar or as a backend domain component. After imprinting, the pledge can use BESKI-CLE to obtain a lightweight credential from the AC. It is assumed that the communication between the registrar and the AC is protected by a security protocol, such as TLS or DTLS, and they can authenticate each other using the security protocol.

Architecture Overview ............<-------> (AC) | . | | EDHOC | | EDHOC | | . | | . | | +-----+-----+ . |IDevID | . +------------+ | BESKI-CLE . | | . +-----------------+----------+ . | | . | | . | | . | Authentication Centre(AC) | . +-------+ . | | . . +----------------------------+ . . . ................................................ "Domain" Components ]]>

Mutual authentication between the pledge and registrar EDHOC can be a lightweight substitute of TLS for the mutual authentication between the pledge and registrar, as described in . Moreover, the pledge's credential is supported transporting by reference rather than by value. Thus, there is no need to configure a credential or a public key on the pledge to identify itself for the mutual authentication. The message flow of transporting credentials by reference is shown in , as described at the bottom of Figure 3 in . ID_CRED_I is used to identify the pledge's authentication credential CRED_I. Pledge sends ID_CRED_I to the registrar in the message_3 of EDHOC. The registrar may use ID_CRED_I to obtain the pledge's credential CRED_I from the MASA. Credential lookup of CRED_I may involve MASA or other credential databases.

Enrollment framework After imprinting, the pledge begins the process of enrollment. A basic protocol flow is shown in .

Basic Protocol Flow | | | | | (B) Public Key Request | | +------------------------->| (B) Public Key Request | | +-------------------------->| | | | | | (C) Public Key | | (C) Public Key |<--------------------------+ |<-------------------------+ | | | | | (D) [Credential Request] | | +------------------------->| (D) [Credential Request] | | +-------------------------->| | | | | | (E) | | (E) |<--------------------------+ |<-------------------------+ | | | | [] Indicates messages protected using AC's public key. <> Indicates messages protected using a symmetric key. ]]>

Registering Pledge's ID (A):: After authenticating the pledge successfully during imprint, the registrar registers the pledge's ID on the AC. The pledge's ID is the unique identity set by the pledge's vendor, such as the MAC address. The AC may record the pledge's ID on the allowlist.
Requesting a public key (B):: The pledge makes a public key request to the AC. The pledge should send its ID in the request.
Public key response (C):: If the pledge's ID is on the allowlist, the AC returns its public key to the pledge.
Credential request (D):: The pledge interacts with the AC to request a local credential. Firstly, the pledge generates a symmetric key and encapsulates the symmetric key by the received public key. Secondly, the pledge sends the encapsulated key to the AC for credential transporting.
Credential response (E):: Firstly, the AC decapsulate the symmetric key by its private key. Secondly, the AC generates a credential for the pledge and encrypts the credential by the received symmetric key. Lastly, the AC sends the encrypted credential to the pledge.