- Joined
- Jun 27, 2006
- Messages
- 23,048
- Thread Author
- #1
Secure communication in the cloud normally involves the following:
Using a cryptographic protocol such as the TLS takes care of data encryption and integrity, and also allows the client to validate the identity of the server by validating its digital certificate.
For IoT devices, validating the identity of the client presents a unique challenge. Unlike traditional consumer devices such as PCs and phones, IoT devices are typically not operated by humans who can enter a password, recognize a picture or solve a CAPTCHA.
In this post, we will look at how to write apps for Windows IoT Core that can authenticate to Azure, while protecting the security-sensitive information on the device.
TPM: Enterprise-Grade Security for Small Devices
Storing secure information, such as a password or a certificate, on a device could make it vulnerable to exposure. A leaked password is a surefire way to compromise the security of a device or an entire system. Human operators take pains to avoid divulging secret information and IoT devices should too, but they must do it better than humans.
In the Windows family, the technology that underpins the security of the OS – the Trusted Platform Module (TPM) – is also available on Windows IoT Core and can be used to secure IoT devices.
At a very high level, a TPM device is a microcontroller that can store data and perform computations. It can be either a discrete chip soldered to a computer’s motherboard, or a module integrated into the SoC by the manufacturer – an approach particularly well suited for small devices.
Inside the TPM
A key capability of the TPM is its write-only memory. If the data cannot be read once written, you might question how can it be useful. This is where TPM’s compute capability comes in – even though the security-sensitive data cannot be read back, TPM can compute a cryptographic hash, such as the HMAC, based on that data. It’s impossible to uncover the secret given the hash, but if the secret is known to both parties of communication, it is possible to determine whether the hash received from another party was produced from that secret.
This is the basic idea behind using cryptographic keys: the secret – called the shared access key – is established and shared between the IoT device and the cloud during the device provisioning process. From that point on, an HMAC derived from the secret will be used to authenticate the IoT device.
Device Provisioning
The tool that provisions Windows IoT Core devices is called the IoT Core Dashboard, and can be downloaded here.
The dashboard produces an image of the OS and securely connects your device to Azure by associating the physical device with the device Id in the Azure IoT Hub, and imprinting the device-specific shared access key to the devices’ TPM.
For devices that don’t have a TPM chip, the tool can install a software-emulated TPM that, while providing no security, allows you to use the same programming model as the one used for the hardware TPM. This way you can develop your app using a maker device (such as Raspberry Pi 2 or 3) and have security “light up” on a device with the hardware TPM, without having to change the app.
To connect your device to Azure, click on the “Connect to Azure” tab:
Link Removed
You will be asked to log in to your Azure account (you can get a free trial subscription here if you don’t have one already), pick the desired instance of Azure IoT Hub and associate your physical device with it.
If you don’t have any IoT Hub instances in your Azure subscription, the tool will let you create a free instance. You shouldn’t worry about accidentally running up a bill in your subscription – unless you explicitly ask for it, the dashboard will not create any paid services on your behalf.
Once you have selected the IoT Hub and the device ID to associate your device with, you can imprint the shared access key of that device on your TPM:
Link Removed
Reconfiguring the Device
Normally you would only use the dashboard for configuring your device for the first time. What if you need to reconfigure your device later? In that case, connect to your device using the Link Removed and open the “TPM configuration” tab.
The Portal allows you to configure additional TPM properties, such as the logical device Id – this way your device can have several identities, which can be useful if you are running different apps that connect to Azure on behalf of different device Ids.
You can find more information on configuring TPM through the Windows Device Portal here.
Show Me The Code!
We have previously described how to connect to Azure using the device credentials retrieved from the IoT Hub. All of this continues to work, but now you can also use a new approach that doesn’t involve keeping the connection string in the app. This means that the same app can work on any provisioned device. You don’t have to insert the connection string in the code after checking it out from source control. No need to remember to remove it before checking the code back in.
When your app runs on a provisioned device, it can extract the device-specific connectivity information at runtime from the TPM.
To connect to Azure IoT Hub from a provisioned device, use the TpmDevice class from the Microsoft.Devices.Tpm library (available as the NuGet package). Get the device information stored in the desired slot (typically slot 0), then retrieve the name of the IoT Hub, the device Id and the Link Removed (the string containing the HMAC produced from the shared access key) and use that to create the DeviceClient:
Link Removed
At this point, you have a connected deviceClient object that you can use to send and receive messages.
The full working sample is available here.
Where Do We Go from Here?
Clearly, security doesn’t end here. Having the token stored in the TPM means that it cannot be extracted or cloned – a bad guy cannot “put on the internet”. However, if the physical access to the device is unprotected, an attacker can install a malicious app on it. Likewise, a discreet TPM can be removed and plugged into another device running an unauthorized app.
If an important process decision depends on the data coming from a sensor (say, a thermometer) attached to the device, an attacker with a blow torch can make it produce wrong data.
Finally, if the health of your system depends on the condition of a particular device, it can be compromised by a low-tech attacker with a sledgehammer.
With all that in mind, using the TPM technology for storing device credentials is an important step towards productizing your IoT solution. TPM allows you to write secure code, so you can be assured that your cloud resources are only consumed by authorized devices and you can trust the data coming from these devices – if access to them has been physically protected.
Post written by Artur Laksberg, a principal software engineer in Windows
Continue reading...
- Data encryption: hiding what is sent
- Data integrity: protecting data from being tampered with
- Authentication: validating the identity of the parties in the communication
Using a cryptographic protocol such as the TLS takes care of data encryption and integrity, and also allows the client to validate the identity of the server by validating its digital certificate.
For IoT devices, validating the identity of the client presents a unique challenge. Unlike traditional consumer devices such as PCs and phones, IoT devices are typically not operated by humans who can enter a password, recognize a picture or solve a CAPTCHA.
In this post, we will look at how to write apps for Windows IoT Core that can authenticate to Azure, while protecting the security-sensitive information on the device.
TPM: Enterprise-Grade Security for Small Devices
Storing secure information, such as a password or a certificate, on a device could make it vulnerable to exposure. A leaked password is a surefire way to compromise the security of a device or an entire system. Human operators take pains to avoid divulging secret information and IoT devices should too, but they must do it better than humans.
In the Windows family, the technology that underpins the security of the OS – the Trusted Platform Module (TPM) – is also available on Windows IoT Core and can be used to secure IoT devices.
At a very high level, a TPM device is a microcontroller that can store data and perform computations. It can be either a discrete chip soldered to a computer’s motherboard, or a module integrated into the SoC by the manufacturer – an approach particularly well suited for small devices.
Inside the TPM
A key capability of the TPM is its write-only memory. If the data cannot be read once written, you might question how can it be useful. This is where TPM’s compute capability comes in – even though the security-sensitive data cannot be read back, TPM can compute a cryptographic hash, such as the HMAC, based on that data. It’s impossible to uncover the secret given the hash, but if the secret is known to both parties of communication, it is possible to determine whether the hash received from another party was produced from that secret.
This is the basic idea behind using cryptographic keys: the secret – called the shared access key – is established and shared between the IoT device and the cloud during the device provisioning process. From that point on, an HMAC derived from the secret will be used to authenticate the IoT device.
Device Provisioning
The tool that provisions Windows IoT Core devices is called the IoT Core Dashboard, and can be downloaded here.
The dashboard produces an image of the OS and securely connects your device to Azure by associating the physical device with the device Id in the Azure IoT Hub, and imprinting the device-specific shared access key to the devices’ TPM.
For devices that don’t have a TPM chip, the tool can install a software-emulated TPM that, while providing no security, allows you to use the same programming model as the one used for the hardware TPM. This way you can develop your app using a maker device (such as Raspberry Pi 2 or 3) and have security “light up” on a device with the hardware TPM, without having to change the app.
To connect your device to Azure, click on the “Connect to Azure” tab:
Link Removed
You will be asked to log in to your Azure account (you can get a free trial subscription here if you don’t have one already), pick the desired instance of Azure IoT Hub and associate your physical device with it.
If you don’t have any IoT Hub instances in your Azure subscription, the tool will let you create a free instance. You shouldn’t worry about accidentally running up a bill in your subscription – unless you explicitly ask for it, the dashboard will not create any paid services on your behalf.
Once you have selected the IoT Hub and the device ID to associate your device with, you can imprint the shared access key of that device on your TPM:
Link Removed
Reconfiguring the Device
Normally you would only use the dashboard for configuring your device for the first time. What if you need to reconfigure your device later? In that case, connect to your device using the Link Removed and open the “TPM configuration” tab.
The Portal allows you to configure additional TPM properties, such as the logical device Id – this way your device can have several identities, which can be useful if you are running different apps that connect to Azure on behalf of different device Ids.
You can find more information on configuring TPM through the Windows Device Portal here.
Show Me The Code!
We have previously described how to connect to Azure using the device credentials retrieved from the IoT Hub. All of this continues to work, but now you can also use a new approach that doesn’t involve keeping the connection string in the app. This means that the same app can work on any provisioned device. You don’t have to insert the connection string in the code after checking it out from source control. No need to remember to remove it before checking the code back in.
When your app runs on a provisioned device, it can extract the device-specific connectivity information at runtime from the TPM.
To connect to Azure IoT Hub from a provisioned device, use the TpmDevice class from the Microsoft.Devices.Tpm library (available as the NuGet package). Get the device information stored in the desired slot (typically slot 0), then retrieve the name of the IoT Hub, the device Id and the Link Removed (the string containing the HMAC produced from the shared access key) and use that to create the DeviceClient:
Link Removed
At this point, you have a connected deviceClient object that you can use to send and receive messages.
The full working sample is available here.
Where Do We Go from Here?
Clearly, security doesn’t end here. Having the token stored in the TPM means that it cannot be extracted or cloned – a bad guy cannot “put on the internet”. However, if the physical access to the device is unprotected, an attacker can install a malicious app on it. Likewise, a discreet TPM can be removed and plugged into another device running an unauthorized app.
If an important process decision depends on the data coming from a sensor (say, a thermometer) attached to the device, an attacker with a blow torch can make it produce wrong data.
Finally, if the health of your system depends on the condition of a particular device, it can be compromised by a low-tech attacker with a sledgehammer.
With all that in mind, using the TPM technology for storing device credentials is an important step towards productizing your IoT solution. TPM allows you to write secure code, so you can be assured that your cloud resources are only consumed by authorized devices and you can trust the data coming from these devices – if access to them has been physically protected.
Post written by Artur Laksberg, a principal software engineer in Windows
Continue reading...
