Automatic IoT Edge Certificate Management with GlobalSign EST
(Republish from Feb 15, 2023) When it comes to managing IoT devices, security is of the utmost importance. But you’d also rest easier if devices are secure without concern about manual certificate management. In this post, we'll show you a solution that streamlines IoT Edge certificate management using GlobalSign's IoT Edge Enroll EST service. An Analogy Think of each IoT Edge device as a new driver, ready to hit the road and communicate with the IoT Hub. And like a new driver, each device needs its own set of credentials that need renewal. Here's how GlobalSign's EST service makes it a breeze: Birth Certificate: During manufacturing, each device is given a unique Initial Device Identifier (IDevID) certificate and private key (ideally, something like Trusted Computing Group’s (TCG) Trusted Platform Module’s (TPM) Endorsement Key (EK) certificates with factory burnt secured hardware backed private keys). This is like the device's birth certificate, proving its identity. Driver's License: When the device connects for the first time, it uses its IDevID to authenticate with GlobalSign for certificate signing request (CSR). In return, GlobalSign provides a short-lived Locally Significant Device Identifier (LDevID) certificate from a trusted root CA. This LDevID acts as the device's driver's license, allowing it to operate for some time. The LDevID serves as the device's unique identifier in IoT Hub, registered through Device Provisioning Service (DPS). Automatic Renewal: To make sure your devices never lose their communication privileges, IoT Edge automatically renews the LDevID certificates before expiration. Like a driver license renewal, but automated! By using GlobalSign's EST service, you can enjoy secure certificate management for your IoT Edge devices. It's like having a personal assistant renewing your driver's license for you. Give it a try to start streamlining your IoT Edge certificate management. Prerequisites An IoT hub and Device Provisioning Service linked to it. A GlobalSign demo account: Sign up for Test Your Azure IoT Edge PoC with live device certificates from GlobalSign's IoT Edge Enroll. You'll receive an email with details for your EST server endpoint within a few days, including three endpoints (IDevID, LDevID, and Edge CA). Reply to the GlobalSign contact and ask to: Enable X.509 authentication (mTLS) for both the LDevID and the Edge CA endpoints Turn off “re-enrollment forcing” (the default behavior with GlobalSign IoT Edge Enroll is that it notices that a previously issued certificate was presented and "upgrade" the request to the reenrollment workflow. This overrides the subject CN to be the same as the previously issued certificate. Typically, customers would use a separate CA for the bootstrap/idevid, so in practice this outcome usually wouldn't be seen. But for simplicity of this post, it’s easier to ask GlobalSign to respect the certificate signing request (CSR) and not perform the “upgrade”). Linux machine, VM, or device with IoT Edge installed: Don't provision the IoT Edge device identity. Create the IDevID In this section, we create the IDevID certificate, which serves as the device's birth certificate. It’s a one-time process that occurs during device manufacturing, and ensures that the initial secret value for first-time authentication to GlobalSign never leaves the factory. Later, when the device wakes up, it will use the IDevID certificate to get a driver's license, or the LDevID certificate. On your local machine or SSH into the IoT Edge device, create directories to store certificates and private keys for IoT Edge and assign ownership of these directories to the "aziotcs" certificate service and "aziotks" key service. sudo mkdir -p /var/aziot/secrets sudo mkdir /var/aziot/certs -p Retrieve the GlobalSign demo root CA certificate with curl and convert it to PEM format using openssl. This certificate serves as the common root of trust between IoT Edge, GlobalSign, and DPS (and thus IoT Hub). curl https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/cacerts| openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out globalsign-root.cert.pem Use openssl to create a new private key and certificate signing request (CSR). openssl req -nodes -new -subj /CN=IDevID -sha256 -keyout IDevID.key.pem -out IDevID.csr Send the CSR to GlobalSign's simple enroll EST endpoint using curl, to obtain the IDevID certificate that is signed with the root CA and paired with the private key created earlier. curl -X POST --data-binary "@IDevID.csr" -H "Content-Transfer-Encoding:base64" -H "Secret-Value: <YOUR-SECRET-VALUE>" -H "Content-Type:application/pkcs10" https://<YOUR-IDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/simpleenroll | openssl base64 -d | openssl pkcs7 -inform DER -outform PEM -print_certs | openssl x509 -out IDevID.cert.pem Move the certificates and private keys to the directories you created earlier, and give the IoT Edge certificate and key services the appropriate permissions to the PEM files and directories. sudo cp *cert.pem /var/aziot/certs sudo cp *key.pem /var/aziot/secrets sudo chown aziotcs:aziotcs /var/aziot/certs/*.cert.pem sudo chmod 644 /var/aziot/certs/*.cert.pem sudo chown aziotks:aziotks /var/aziot/secrets/*.key.pem sudo chmod 600 /var/aziot/secrets/*.key.pem sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets Use the ls command to verify that the files are in place with the proper permissions and match the expected values. $ sudo ls -lR /var/aziot /var/aziot: total 8 drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 11 14:38 certs drwx------ 2 aziotks aziotks 4096 Jan 11 14:38 secrets /var/aziot/certs: total 8 -rw-r--r-- 1 aziotcs aziotcs 1298 Jan 11 14:38 IDevID.cert.pem -rw-r--r-- 1 aziotcs aziotcs 1383 Jan 11 14:38 globalsign-root.cert.pem /var/aziot/secrets: total 4 -rw------- 1 aziotks aziotks 1704 Jan 11 14:38 IDevID.key.pem Prepare DPS for provisioning Here's how to get DPS ready for device provisioning: If you haven’t already done so, create an IoT hub and DPS, then link them together. Go to the DPS instance in Azure portal, then select Certificates > Add. In the pop-up, select your GlobalSign EST root CA certificate. You can use SFTP, VS Code Remote Extension to copy it from the IoT Edge device, or use curl to get it again. Select Set certificate status to verified on upload so that you can skip proof-of-possession. Click Save. Create a DPS enrollment group. Make sure attestation type is set to Certificate, IoT Edge device is set to True, certificate type is set to CA Certificate, and the root CA you just uploaded is set as the Primary Certificate. Now, your DPS is ready to provision the IoT Edge device when it wakes up, using the root CA certificate as the trusted source of authentication. Configure and start the IoT Edge device In this section, we set up the IoT Edge device with its birth certificate (IDevID) to communicate with the GlobalSign EST server and receive its driver license (LDevID). The LDevID allows the device to talk to DPS and get the proper authorization for communication with IoT Hub. On the IoT Edge device, create a config file config.toml. Replace marked parameters with details from your GlobalSign account and DPS. # The CA cert of the demo root we got from earlier [cert_issuance.est] trusted_certs = ["file:///var/aziot/certs/globalsign-root.cert.pem"] # Empty because the LDevID (device ID) and Edge CA endpoints are different [cert_issuance.est.urls] # Use the IDevID cert and private key for authentication to EST [cert_issuance.est.auth] identity_cert = "file:///var/aziot/certs/IDevID.cert.pem" identity_pk = "file:///var/aziot/secrets/IDevID.key.pem" # DPS provisioning with X.509 certificate # Replace with ID Scope from your DPS [provisioning] source = "dps" global_endpoint = "https://global.azure-devices-provisioning.net" id_scope = "<DPS-ID-SCOPE e.g 0AB12345678>" [provisioning.attestation] method = "x509" registration_id = "my-device-id" # Get LDevID (device ID) cert from EST with auto renew [provisioning.attestation.identity_cert] method = "est" common_name = "my-device-id" url = "https://<YOUR-LDEVID-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [provisioning.attestation.identity_cert.auto_renew] threshold = "80%" retry = "4%" # Get Edge CA from EST also with auto renew [edge_ca] method = "est" url = "https://<YOUR-EDGE-CA-ENDPOINT>.est.edge.dev.globalsign.com:443/.well-known/est/" [edge_ca.auto_renew] threshold = "80%" retry = "4%" Copy the file over as root and apply configuration with iotedge config apply. This also starts the IoT Edge device. sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply Verify that the configuration was successful by using the iotedge check command. You should see successful checks on the connection with DPS and the status of certificates and keys. You can also check in your DPS Enrollment Group > Registration Records or IoT Hub to see that the IoT Edge device is registered (shown below). Note: if you haven’t configured an IoT Edge deployment, you might see an error about edgeHub container being missing in iotedge check and a 417 in IoT Hub. That’s normal until you add the deployment via Set modules. On the device, check the new certificates from the EST server. In the "/var/lib/aziot/certd/certs" directory, you should see three different certificates starting with "estid", "aziotedgeca", and "deviceid". Use OpenSSL to inspect them. Note: the certificate names are randomly generated, use "ls" to find their names and paste them into the OpenSSL command. sudo ls /var/lib/aziot/certd/certs sudo openssl x509 -text -in /var/lib/aziot/certd/certs/estid-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/aziotedgedca-<GUID>.cer sudo openssl x509 -text -in /var/lib/aziot/certd/certs/deviceid-<GUID>.cer sudo openssl x509 -in /var/aziot/certs/IDevID.cert.pem -text | head -n 10 That’s it! When the time (80% to expiration) comes, IoT Edge will automatically renew both the device ID and the Edge CA certificates without manual intervention. Simplify IoT Edge Security This blog showed how to configure IoT Edge devices for secure communication using X.509 certificates without the need for manual certificate management. By using this approach, organizations can securely and efficiently manage their IoT Edge devices at scale, streamlining device enrollment and reducing the risk of security breaches. To adapt the example to fit your needs, consider the following: Security level: Your security requirements may vary based on your use case. Consider whether a unique IDevID certificate per device is necessary or if sharing the same certificate among multiple devices is acceptable. It's important to never store the initial EST secret value on the device in plaintext. Comprehensive security: For a more robust security approach, refer to The blueprint to securely solve the elusive zero-touch provisioning of IoT devices at scale | Azure. Dev/test scenarios: IoT Edge also supports basic authentication (username/password) for EST servers. To Restart If you need to restart midway through, stop the IoT Edge service first, delete any certificates and keys that were generated, reapply the config, and restart IoT Edge. sudo iotedge system stop sudo sh -c "rm /var/lib/aziot/certd/certs/*" sudo sh -c "rm /var/lib/aziot/keyd/keys/*" sudo cp config.toml /etc/aziot/config.toml sudo iotedge config apply sudo iotedge system logs -- -fEnable an Industrial Dataspace on Azure
What is an Industrial Dataspace? An industrial dataspace is an environment designed to enable the secure and efficient exchange of data between different organizations within an industrial ecosystem. Developed by the International Data Spaces Association, it focuses on key principles such as data sovereignty, interoperability, and collaboration. These principles are crucial in the context of Industry 4.0 where interconnected systems and data-driven decision-making optimize industrial processes and create resilient supply chains. A tutorial with step-by-step instructions on how to enable an industrial dataspace on Azure is available here. Use Case: Providing a Carbon Footprint for Produced Products One of the most popular use cases for industrial dataspaces is providing the Product Carbon Footprint (PCF), an increasingly important requirement in customers' buying decisions. The Greenhouse Gas Protocol is a common method for calculating the PCF, splitting the task into scope 1, scope 2, and scope 3 emissions. This example solution focuses on calculating scope 2 emissions from simulated production lines using energy consumption data to determine the carbon footprint for each product. Accessing the Reference Implementation The Product Carbon Footprint reference implementation can be accessed here and deployed to Azure with a single click. During the installation workflow, all the required components are deployed to Azure. This reference implementation supports data modelling with IEC standard Open Platform Communication Unified Architecture (OPC UA), aligned with the OPC Foundation Cloud Initiative. It also uses the IEC standard Asset Administration Shell (AAS) to provide product semantics, creating a Product Carbon Footprint AAS for simulated products and storing it in an AAS Repository. Finally, the implementation uses the IEC/ISO standard Eclipse Dataspace Components (EDC) to establish the trust relationship between the manufacturer and the customer, enabling the actual PCF data transfer via an OpenAPI-compatible REST interface. Conclusion Enabling an industrial dataspace on Azure can help manufacturers meet regulatory requirements, optimize industrial processes, and improve customer engagement by leveraging modern cloud technologies and standards to provide a secure and efficient data exchange environment, ultimately driving transparency and sustainability in the manufacturing industry.Partners accelerating industrial transformation with Azure IoT Operations
In the digital age, the essence of innovation lies not only in groundbreaking technology but also in the power of collaboration. At Microsoft, we have always recognized that our success is intertwined with the success of our partners. Our platform products, including the newly released Azure IoT Operations, are designed to be the foundation upon which our partners can build transformative solutions. These collaborations are more than just business arrangements; they are the bedrock of a thriving ecosystem that drives innovation, addresses customer needs, and propels industry standards forward. Partnerships enable us to extend our reach and impact far beyond what we could achieve alone. By combining our technological prowess with the domain expertise and creativity of our partners, we create a dynamic synergy that fosters groundbreaking advancements. This collaborative spirit is vital as we navigate the complexities of the Internet of Things (IoT) landscape, where diverse applications and specialized knowledge are paramount. Our partners bring unique perspectives and capabilities to the table, ensuring that Azure IoT Operations can cater to a broad spectrum of industries and use cases.Transforming Manufacturing with the Help of Ontologies
For over three years, Microsoft has been contributing to the Digital Twin Consortium’s open-source initiative. The most successful open-source project the DTC runs is the Manufacturing Ontologies project available at: https://github.com/digitaltwinconsortium/ManufacturingOntologies We examine our most recent contributions.
