Use EAP-TLS

Azure Sphere supports the use of Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) to connect to Wi-Fi networks. EAP-TLS is not supported over Ethernet.

EAP-TLS for Wi-Fi is a common authentication method in security-focused scenarios. It provides significantly greater security than using the SSID password as a global secret but requires additional work to ensure that the Azure Sphere device and the network are properly configured and authenticated.

The EAP-TLS protocol specification is detailed in RFC 5216. The Azure Sphere OS does not directly implement the EAP-TLS protocol; instead, it incorporates an open-source wpa_supplicant component that implements the protocol.

Terminology

Access Point (AP): A networking hardware device that allows other Wi-Fi devices to connect to a wired network.

Certificate: A public key and other metadata which is signed by a CA.

Certificate Authority (CA): An entity that signs and issues digital certificates.

CA Certificate: The root CA certificate that the RADIUS server's authentication certificate chains to. This public key may be stored on the Azure Sphere device.

Client Certificate: The certificate and private key that are used to authenticate to the network. The client certificate and its paired private key are stored on the Azure Sphere device.

Key Pair: A cryptographically bound set of keys. In many scenarios, a key pair means a public key and a private key; in the Azure Sphere EAP-TLS scenario, however, key pair indicates the client certificate and its private key.

Private Key: A key that should not be exposed to any entity except the trusted owner.

Public key infrastructure (PKI): The set of roles, policies, hardware, software, and procedures that are needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.

Remote Authentication Dial-In User Service (RADIUS): A networking protocol that operates on port 1812 and provides centralized Authentication, Authorization, and Accounting (AAA or Triple A) management for users who connect to and use a network service. A RADIUS server receives authentication data from a client, validates it, and then enables access to other network resources.

Rivest–Shamir–Adleman (RSA): A public-key cryptosystem that is based on RFC 3447).

Supplicant: The wireless client. The Azure Sphere device is a supplicant.

Overview of EAP-TLS authentication

The following diagram summarizes the process by which an Azure Sphere device uses the EAP-TLS protocol to authenticate.

1. When an Azure Sphere device requires access to a network resource, it contacts a wireless access point (AP). Upon receiving the request, the AP asks for the device's identity and then contacts the RADIUS server to initiate the authentication process. Communications between the access point and the device use the EAP encapsulation over LAN (EAPOL) protocol.

2. The access point recodes the EAPOL messages to RADIUS format and sends them to the RADIUS server. The RADIUS server provides authentication services for the network on port 1812. The Azure Sphere device and the RADIUS server carry out the authentication process through the access point, which relays the messages from one to the other. When authentication is complete, the RADIUS server sends a status message to the device. If authentication succeeds, the server opens the port for the Azure Sphere device.

3. After successful authentication, the Azure Sphere device can access other network and internet resources.

Server authentication and Device authentication describe the authentication process in more detail.

Server authentication

Server authentication is the first step in mutual EAP-TLS authentication. In mutual authentication, not only does the RADIUS server authenticate the device, but the device authenticates the server. Server authentication is not strictly required, but we strongly recommend that you configure your network and devices to support it. Server authentication helps to ensure that a rogue or impostor server cannot compromise the security of the network.

To enable server authentication, your RADIUS server must have a server authentication certificate that is signed by a CA. The server authentication certificate is a "leaf" at the end of the server's certificate chain, which may optionally include an intermediate CA, and eventually terminates in a Root CA.

When a device requests access, the server sends its entire certificate chain to the device. Azure Sphere does not enforce time validation checks on the server authentication certificate or chain, because the device cannot synchronize the OS time to a valid time source until it has authenticated to the network. If the device is configured to trust a Root CA that matches the server's Root CA, it validates the server's identity. If the device does not have a matching Root CA, server authentication fails and the device will be unable to access network resources. You must be able to update the RootCA on the device from time to time, as described in Update a Root CA certificate.

Device authentication

After server authentication completes, the device sends its client certificate to establish its credentials. The device may also pass a client ID. The client ID is optional information that some networks may require for authentication.

The specific requirements for successful device authentication may vary, depending on how your particular network is configured. The network administrator may to require additional information to prove the validity of your Azure Sphere devices. Regardless of the configuration, you must be able to update the device certificate from time to time, as described in Update a client certificate.

Azure Sphere EAP-TLS platform

The Azure Sphere EAP-TLS platform provides the following capabilities for network configuration and management:

• Load a .PEM file that contains the device's client certificate and private key for Wi-Fi EAP-TLS connections.
• Configure the Wi-Fi interface to use EAP-TLS. The .PEM file that contains the device's client certificate must be present on the device.
• Connect to an existing non-EAP-TLS network to get a device certificate and private key, enable an EAP-TLS network, and connect to the EAP-TLS network.
• Enable applications to use the device authentication and attestation (DAA) certificate used for HTTPS connections to authenticate to a certificate store.
• WifiConfig API to manage Wi-Fi networks.
• Certstore API to manage certificates.

All other EAP-TLS network components are the responsibility of the local network administrator.

EAP-TLS network setup

The setup of the EAP-TLS network is the responsibility of your network administrator. The network administrator must define the public-key infrastructure (PKI) and ensure that all network components conform to its policies. Network setup and configuration includes, but is not limited to, the following tasks:

• Set up the RADIUS server, acquire and install its CA certificate, and establish the criteria for a device to prove its identity.
• Configure your Azure Sphere devices with the root CA of the RADIUS server, so that they can authenticate the server.
• Acquire a client certificate and private key for each device and load them onto the device.

EAP-TLS certificate acquisition and deployment describes how to acquire and deploy certificates in various networking scenarios.

The certificate and private key for client authentication must be provided in PEM format. The private key may be provided in PKCS1 or PKCS8 syntax, with or without a symmetric key password for the private key. The root CA certificate must also be provided in PEM format.

The following table lists the information used in configuring an EAP-TLS network for Azure Sphere.