Executive Summary
Companies are increasingly looking to use their Internet of Things (IoT) architecture to support the digital transformation of their businesses. But one of the main roadblocks that prevents rapid IoT solutions deployment is security. To address this, it is required to adhere to industry security best practices, covering data protection and each IoT component as part of the infrastructure, as well as the overall solution. Intel has teamed up with strategically important ecosystem partners like Red Hat to harden the IoT security by supporting specific usage models and workflows required by Top 100 customers. While each company is on its own digital transformation journey, the underlying guiding principles are generally similar. These guiding principles, based on open source implementations pave the way for general ecosystem scale, where individual features not only work in harmony together but can also be enabled and used independently.
As part of the networking infrastructure, Edge Devices are typically being tethered by a wired connection. But this option brings several negative factors such as very high deployment costs, long lead time to deploy each device, complexity of adding devices located in areas not served by wired network, and security concerns if the right measures are not put in place. A more flexible option, addressing these issues, is to use a secure Wi-Fi infrastructure in which Authentication plays a key function. This paper focuses on a novel and highly secure mechanism to authenticate Edge Devices on Enterprise Wi-Fi networks using state of the art technologies, including hardware root of trust based on TPM 2.0.
Authors
Cesar Martinez Spessot
Intel Corporation
Engineering Director
Senior IoT Solutions Architect
Marcos Carranza
Intel Corporation
Sr. Software/Solutions Architect
Nicolas Oliver
Intel Corporation
Software Engineer
Lakshmi Talluru
Intel Corporation
Sr. Director Digital Transformation
Ishu Verma
Red Hat
Emerging Technologies Evangelist
Securing Wi-Fi Authentication at the Edge
Overview
One of the key barriers for the digital transformation within the modern enterprise are high deployment costs, that could be even higher than the new hardware being added. By consolidating workloads to run on multipurpose devices, which include higher processing capacity, the costs can be amortized across many functions served by this device, but this approach still requires long lead time and is not very flexible. A Wi-Fi infrastructure can help fully resolve these issues by using the right state of the art technologies, standards and building blocks. A key consideration is about how to authenticate new devices added to the infrastructure.
IEEE 802.1X is a network access control standard which includes authentication. It defines the encapsulation of the Extensible Authentication Protocol (EAP) over IEEE 802. EAP is better than other alternatives (e.g. WPA, WEP) because of the combination of security and usability. As part of EAP, there are many different authentication types such as EAP-MD-5, PEAP, etc. with EAP-TLS being the more secure alternative. Although, EAP-TLS supports User/Password mode, Private/Public key mode is the recommended alternative for keeping a highly secure environment. Automation and the use of this mode allows for unattended operations and the possibility of using Hardware Root of Trust based on TPM 2.0. User/Password mode usually takes time away from value-add activities, requiring additional support tasks to manage credentials and expirations.
Required Components:
The components required on this secure infrastructure are:
- Edge Devices (also known as IoT Gateway): they have enough processing power to serve multiple IoT functions simultaneously. These edge devices are deployed close to sensors, receive data directly from them, and interact with actuators to perform specific actions. These devices are standardized by IT including the hardware and software stacks to process sensor data and connect with back end systems, being Wi-Fi a key requirement for connectivity. These devices should also include:
- Trusted Platform Module (TPM): part of the Edge Device, as an additional hardware component, or as a firmware component running in the Intel(R) Platform Trust Technology component. TPM is required to establish Hardware Root of Trust and key management.
- Operating System with Security and Network Tools: highly secure operating system with TPM2-TSS, TPM2-Tools, TPM2-PKCS11, Network Manager, WPA-Supplicant, GNU TLS Tools and Open-SSL packages.
- Enterprise Wi-Fi Infrastructure: includes all the sub-components required for enabling Enterprise Wi-Fi authentication using EAP-TLS with Public Key Cryptography:
- Wi-Fi Access Point: they are devices providing Wi-Fi coverage across the facilities. The selected device must support EAP-TLS which nowadays is the more secure authentication mechanism.
- RADIUS Server: it is a centralized Authentication, Authorization and Accounting component.
- Public Key Infrastructure (PKI): it is a component to manage certificates and keys.
Edge Device Configuration Process
The configuration was performed using the Red Hat’s Fedora Internet of Things (IoT) operating system. Fedora IoT is a Fedora Edition focused on being a strong foundation for the IoT ecosystem. Fedora IoT provides a trusted open source platform to build solutions for the Smart Home, industrial Gateways and Smart Cities segments, or to deploy Data Analytics Workloads with Artificial Intelligence and Machine Learning. Red Hat produces regular rolling release to keep the Fedora IoT ecosystem up to date, using the rpm-ostree package layering model to provide the atomic updates functionality needed for this type of deployments. An important aspect of the Fedora IoT distribution is its focus on security and trust, providing the latest available technologies in Firmware, BIOS and Kernel security and integrity, as well as the latest available packages for the interaction between the application workloads and TPM 2.0. Fedora IoT is also a pioneer in the adoption of the TPM PKCS11 Interface to enable the EAP-TLS configuration that we describe in this article. The configuration involves the following steps:
- Network Private Key Generation
- Network Certificate Generation
- EAP-TLS Network Connection Configuration
Network Private Key Generation: The step involves creating a Network Private Key, that will be used to authenticate the Edge Device on the Enterprise Wi-Fi infrastructure. It is fundamental to keep this Private Key in a secure location and implement the necessary safeguards to prevent it from being disclosed. For this purpose, the Private Key is generated internally in the TPM 2.0 device and it is never disclosed externally. Given that the TPM is a cryptographic device, the Edge Device Networking stack needs to be able to access the key material stored in it. For this purpose, the Public Key Cryptography Standards (PKCS) group has defined the PKCS#11 standard providing a generic interface to access cryptographic tokens. We use the TPM2-TSS library and TPM2-PKCS11 module to create a PKCS#11 store and request the creation of the Private Key to the TPM.
Example:
mkdir -p /etc/tpm2_pkcs11
tpm2_ptool init
tpm2_ptool addtoken --pid=1 --sopin=sopin --userpin=userpin --label=label
tpm2_ptool addkey --algorithm=rsa2048 --label=label --userpin=userpin
Network Certificate Generation: This step involves using the cryptographic token created in the previous step to generate a Certificate Signing Request (CSR). A CSR is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. A Certificate Authority (CA) will use the CSR to create the Network Certificate, but it does not require access to the TPM stored Private Key. The certificate created with a CSR will only work with the private key that it was generated with. To generate the CSR, we use OpenSSL using the TPM2-PKCS11 component as the cryptographic engine. The Private Key is accessed using the standard PKCS11 URI.
Example:
PKCS_URI="pkcs11:model=Intel;manufacturer=Intel;serial=0000000000000000;token=label;id=%32%62%37%30%65%62%36%32%66%33%32%62%31%63%65%37;object=0;type=private;pin-value=userpin"
CERTIFICATE_SUBJECT="/C=FR/ST=Radius/L=Somewhere/O=Example Inc./CN=testing/emailAddress=testing@test.com"
openssl req \
-new \
-engine pkcs11 \
-keyform engine \
-key "${PKCS_URI}" \
-subj "${CERTIFICATE_SUBJECT}" \
-out client.csr
The CSR is then provided to the Certificate Authority in the Public Key Infrastructure, which generates the Network Certificate and provides it to the Edge Device. EAP-TLS Network Connection Configuration: This step consists of generating the EAP-TLS Network Configuration. In addition to the Private Key and Network Certificate obtained in the previous steps, the CA Certificate is also required for the setup. The CA certificate is used by the Edge Device to verify that it is talking with a trusted Wi-Fi Access Point. To configure this connection, the Network Manager component is used. Network Manager will automatically scan for Wi-Fi signals, and authenticate the Edge Device using the configured EAP-TLS parameters:
- 802-11-wireless.ssid: The Service Set Identifier (SSID) of the Enterprise Wi-Fi network
- 802-11-wireless-security.key-mgmt: Key Management Security configuration
- 802-1x.eap: EAP method to use in authentication
- 802-1x.identity: Identity for the EAP authentication method
- 802-1x.ca-cert: Path to the Certificate Authority certificate
- 802-1x.client-cert: Path to the provided Network Certificate
- 802-1x.private-key: PKCS#11 URI to access the Private Key in the cryptographic device
nmcli connection add type wifi ifname wlp1s0 con-name 'SSID' \
802-11-wireless.ssid SSID \
802-11-wireless-security.key-mgmt wpa-eap \
802-1x.eap tls \
802-1x.identity testing \
802-1x.ca-cert /etc/pki/SSID/ca.pem \
802-1x.client-cert /etc/pki/SSID/client.crt \
802-1x.private-key 'pkcs11:model=Intel;manufacturer=Intel;serial=0000000000000000;token=label;id=%32%62%37%30%65%62%36%32%66%33%32%62%31%63%65%37;object=0;type=private;pin-value=userpin' \
802-1x.private-key-password-flags not-required
EAP-TLS Authentication with TPM Credentials
To initiate the authentication process, we use the Network Manager component, activating the connection previously configured:
Example:
nmcli conection up SSID
The authentication process between the Edge Device and the Wi-Fi Access Point can be summarized as follow:
- The Edge Device looks for the SSID published by the Wi-Fi Access Point using a Wi-Fi scan operation. Once it is found, it executes the Wi-Fi association process.
- The Wi-Fi Access Point proposes the authentication method as EAP-TLS. The Edge Device verifies that it is communicating with a trusted Wi-Fi Access Point using the CA Certificate configuration.
- The Edge Device presents its Network Certificate to the Wi-Fi Access Point. The Wi-Fi Access Point now offloads the authentication request to the RADIUS Server. It is important to note that the Edge Device does not interact directly with the RADIUS Server, the Wi-Fi access point is used as a proxy between them. The RADIUS Server confirms that the Network Certificate was provided by the Certificate Authority. Now it needs to confirm if the Edge Device is the owner of the Private Key. For this purpose, a challenge is presented to the Edge Device, consisting on a nonce encrypted with the Public Key presented in the Network Certificate, that can only be decrypted by the Private Key used to generate the Certificate.
- The Edge Device receives the challenge, and resolve it using its TPM Private Key through the PKCS#11 interface. The decrypted nonce is then used to generate a signature, that will be presented to the RADIUS server to prove that the Edge Device was able to solve the challenge (and it is the owner of the Private Key).
- The RADIUS Server receives the solved challenge and notify the Wi-Fi Access Point that the authentication process was successful. Now the Wi-Fi Access Point can provide the necessary network configuration to finalize the setup (IP Address, Gateway Address, etc.).
- The authentication process is periodically re-executed over the duration of the Wi-Fi session.
Now that we have established a secure authentication process to protect the Enterprise Wi-Fi infrastructure, we need to address its usability and scale aspects. It is fundamental to assure that any measure applied to improve the usability and scale aspect of this solution should not compromise the security aspect. For this purpose, we will rely on additional components to implement a reference automated process to allow deploying Edge Devices at scale.
Case Study - Automating the Authentication Process for Industrial Scenarios
Assumptions
This is based on the following industry’s common assumptions:
- Edge devices are deployed in OT managed environment that requires air gapping critical infrastructure from IT network. The access to these edge devices behind the firewall is highly restricted.
- Pre-shared keys for Wi-Fi authentication may compromise network security depending on how they are managed (e.g. unique keys can be copied, or not securely stored).
- There is a highly secure device, named ‘Authenticator Proxy Device’ referred in this paper, which will assist deployment personnel on initial setup. This device will be running on a secure location with no access to non-authorized personnel. Firewall is configured to allow this specific device to have access to PKI.
- Public Key Infrastructure (PKI) is available on the enterprise business network. A Signing Server is provided with an API to process CSRs and return Network Certificates.
- RADIUS Server is available and addressable by Wi-Fi Access Points.
Additional Components for Automation
The involved components, shown in Figure 1, are:
- Authenticator Proxy Device: it is a secure device with access to the enterprise business network. This device may be using wired connectivity (ethernet) and can reach the PKI. Securing this device with additional measures is recommended, such as locating it in a controlled area, and utilizing remote attestation to continuously verify the integrity of the state of device (including the firmware, bootloader, and software stack). This device will also provide a wired connection (Ethernet) to new devices to be onboarded to the wireless network (in total, at least, 2 ethernet ports may be required).
- Device Manager (DM): it is a centralized component required to manage the lifecycle of devices and the Software and Firmware deployed on them. To maximize the security, this case study considers an on-prem deployment for this component available on the business network. There is also an Edge Device side counterpart component named Agent (see in Figure 1 on Edge Device).
Figure 1
Interaction Between Components
Infrastructure setup
Initially, during infrastructure setup, the PKI issues a new CA certificate that is installed and configured on the RADIUS Server. Also, an Authenticator Proxy Device must be deployed and made available for assisting in the authentication process of new Wi-Fi capable Edge Devices.
Wired Authenticator Proxy steps
There are several steps that will happen using a wired ethernet connection between the new Edge Device that have to be authorized and the Authenticator Proxy Device. The new Edge Device includes an enterprise standard Operative System image having a Device Management Agent, TPM2-TSS, TPM2-Tools, TPM2-PKCS11, WPA-SUPPLICANT, OPEN-SSL, GNUTLS-Tools and Network Manager. On the Device Manager side (Server), an Initial Campaign is generated for Edge Devices so each new device can get the initial setup actions during its first interaction.
Additionally, the authentication requirement for new Edge Devices is based on their TPM Endorsement Keys. The Endorsement Keys are statistically unique keys present in every TPM module that can be used to uniquely identify an Edge Device. The Device Management server requires knowing the Public Part of the Endorsement Key of devices that are going to be enrolled. This step is known as pre-registration. An additional security measure will be a whitelisting requirement, which requires a human or automatic event to notify the Device Management server that an Edge Device will start its enrollment process.
The steps executed in this automated process are:
- The new Edge Device to be authorized is connected to the Authenticator Proxy Device through an Ethernet interface, which will provide connectivity to the Edge Device using the Authenticator Proxy Device as a proxy.
- The new Edge Device is powered on.
- During the first boot, the Device Management Agent will trigger the derivation of the Public part of the TPM Endorsement Key), named EKpb in Figure 1.
- The Device Management Agent triggers the Provisioning Request to the Device Manager passing the EKpb.
- The Device Management Server validates that this EKpb is pre-registered (and possibly whitelisted) and if so, returns an encrypted nonce that can be only validated using the EKpr (Endorsement Key Private Key) protected on the TPM.
- The Device Management Agent decrypts the nonce using the EKpr.
- The Device Management Agent requests an Authentication Token to securely connect to the Device Management Server on any further interaction, passing the decrypted nonce as a proof of identity.
- The Device Management Servers returns the Authentication token (e.g. JWT file).
- All this is a regular wired TPM based secure onboarding process.
Wireless Certificate Provisioning
Once the Device Management Agent on the Edge Device has an Authentication Token, it is ready to get the Initial Campaign. The Device Management Agent checks for available campaigns for devices labeled as Wi-Fi. The Device Management Server provides the Initial Campaign. This campaign includes the required artifacts to establish the EAP-TLS connection described before, and the actions to start the process for Wi-Fi credential generation:
- Initialize PKCS11 store, generates a CSR using OpenSSL and the PKCS#11 standard
- Send the CSR to the Signing Server API from PKI. The Signing Server receives the CSR and return the Network Certificate. The need of the Authenticator Proxy Device is to be able to access the Signing Server which resides on the business network. The Firewall only allows the Authenticator Proxy Device to send CSRs to the Signing Server and blocks any other request to the Signing Server.
- The Device Management Agent (as part of the campaign action execution) configures the Enterprise Wi-Fi Network connection as described above.
- The Device Management Agent sets the Enterprise Wi-Fi Network connection as AutoConnect, which will trigger the authentication process automatically when the Enterprise Wi-Fi Network is in range.
Final Wireless Physical Deployment
Once the Edge Device is fully provisioned it can be deployed on the final location. It must be deployed in the range of any of the Enterprise Wi-Fi Access Points available in the facility.
- The Edge Device is powered on in the new deployment location.
- The EAP-TLS Authentication process is automatically executed when the Enterprise Wi-Fi Network is detected.
- The Edge Devices gets its network configuration and becomes available for executing workloads.
Network Certificate Renewal Process
Since Network Certificates can be revoked or they can reach the configured expiration date, it is required to have a flow for renewing certificates. It is not recommended to generate certificates with expiration dates too far in the future. Also, the Private Key that was already generated by the TPM will be used again to issue a new Certificate Signing Request and getting a new Network Certificate with updated expiration date.
In Figure 2, the renovation process is presented, showing the interaction between the involved components.
Figure 2
The Authenticator Proxy Device is used again as a proxy, since as previously mentioned, the firewall rules only allow that specific device to contact the Signing Server for CSR. Note that this interaction requires making the Authenticator Proxy Device reachable from the Edge Device through the network (e.g., the Authenticator Proxy Device needs to be accessible to devices on the Enterprise Wi-Fi Network)
- This is triggered from the Device Management Server by generating a new campaign containing the required actions to renovate the Network Certificate.
- The Device Management Agent gets the new campaign and requests a new CSR using the TPM2-PKCS11 module as the cryptographic engine.
- The Authenticator Proxy Device includes a certificate renovation service which will receive the new CSR from the Edge Device and send it to the Singing Server. Once the new certificate is generated, it is returned to the Edge Device and installed in the path previously configured.
Conclusion
This whitepaper provides a clear definition and BKMs on how to authenticate Edge Devices using Wi-Fi infrastructure using state of the art technologies for reducing deployment costs while increasing security and flexibility. By using this mechanism based on IEEE 802.1X it is possible to extend this to wired connections, making the approach more scalable and helping simplify the security and overall management of devices.