A new security concept is emerging and consolidating more and more in recent years: the so-called zero-trust security model.
In particular, in the IoT market, security is a crucial element to be considered. This is generally addressed by having your cloud gateway service trusting your devices. Still, when you have something too precious to be sent into the cloud, you also need to think about how your devices trust your cloud gateway, as you would not like having your data transmitted to a malicious endpoint.
Trusting Device vs. Trusting the Cloud Gateway
As mentioned above, frequently, addressing the challenge of trusting a device is handled by merely choosing the best attestation mechanism available (according to your hardware specs) to confirm your device's identities when connecting to a platform service like Azure IoT Hub.
For example, IoT Hub supports symmetric key, X.509 thumbprint, and X.509 CA (also known as client certificates) attestation methods.
This allows your cloud endpoint to verify that your device is what it states it is.
Ok, this is fine; the cloud portion now can trust the Devices, but what about if a malicious entity performs a DNS Spoofing (https://it.wikipedia.org/wiki/DNS_spoofing) attack and allows your devices to point to a forged alternative cloud gateway?
To provide a quick refresh: a DNS Spoofing happens when an attacker manages to let your DNS query results in a different IP address for the target host. In this case, let's assume that instead of obtaining the IP address of your IoT Hub, you got an IP address of a forged malicious endpoint pretending to be your cloud gateway!
How can you check this out?
TLS Support in IoT Hub
There is excellent news for you.
IoT Hub supports Transport Layer Security (TLS): IoT Hub TLS Support
What does this mean, and how can it be leveraged?
It means that when your device attempts a connection to it, IoT Hub presents server certificates to connecting clients.
Those certificates are part of a chain-of-trust, and clients could check against those certificates to ensure that the Cloud Gateway is what it states it is.
Chain of Trust?
A chain-of-trust is the practice of validating the security of components up to the "root of trust" (https://en.wikipedia.org/wiki/Chain_of_trust).
In particular, in the context of TLS, your endpoint certificate is typically signed by another certificate that could be a root certificate or an intermediate certificate.
Root certificates are "self-signed," and you usually trust them because they are emitted by "Certification Authorities" (those are well-known entities wisely recognized in the business of security); they are your "root of trust".
Typically OSs have those "well-known CAs" in a certificate store, and you do not have to do anything special to accept and recognize them.
So, as a super high-level summary: you got a Root Certificate that signs an Intermediate Certificate that signs your endpoint Certificate.
That's what happens for IoT Hub Certificates: a well-known CA signs Microsoft-owned Intermediate Certificate with a Root Certificate (Baltimore Cybertrust Root CA); then IoT Hub Server Certificates are signed by one of those Microsoft Intermediate Certificates.
Here are some announced changes in these certificate chains, which are valuable to keep in mind: IoT Hub Cert Update.
Another critical point to remember is that certificates expire, or better, they have a specific validity period (start/end).
Let me elaborate a bit further on this later.
IoT Hub SDKs
Ok, how does IoT Hub SDKs deals with that?
In a nutshell: it's a trade-off between operational complexity and ensuring protection against all the possible attack vectors.
Most IoT Hub SDKs only validate that the Root Certificates match the expected one (as mentioned before: Baltimore Cybertrust Root CA) while not enforcing Intermediate Certificates.
Checking against Server Certificate chain-of-trust is a practice known as "Certificates pinning".
Certificates Pinning
- What's Certificate Pinning?
- Could it mitigate DNS Spoofing?
- Does it add operational complexity?
Let's tackle these three questions one by one.
1) Certificate pinning is the practice to restrict what certificates are considered valid for a particular endpoint.
If you don't do that explicitly, you are usually trusting any certificate presented by your endpoint backed by any well-known Root Certificate trusted by your system.
You can "pin" the Root Certificate, Intermediates, or even your specific endpoint certificate.
2) Well, it could help to mitigate it, yes.
If you "pin" Certificates, you are just restricting the range of acceptable certificate chains. This means that a potential attacker needs to generate a certificate signed by that specific chain to make its rouge endpoint accepted.
While IoT Hub Root Certificate is a well-known public CA, the intermediate certificates are privately-owned by Microsoft.
An attacker couldn't forge a certificate for its malicious endpoint pretending to be an IoT Hub Gateway as long as it has no access to the private key of Microsoft intermediate certificates.
3) Yes, this could add complexity. Remember, before I've mentioned before that certificates have a life span. It means they expire over time. Root Certificates typically have "some years" of life span while intermediates rotate more frequently (around 6 months or so far, but they might as well have a longer validity period). This is the extra operational complexity to which I refer.
If you build an IoT client which "pins intermediates", you need to ensure that whenever those intermediates refresh, you can update your client upfront before it cuts itself out because it didn't recognize your cloud gateway certificates chain anymore.
How to check Intermediates
An approach would be using OpenSSL to decode the IoT Hub cert:
openssl x509 -in "Wildcard IoT.cer" -text -noout
Once you find the Intermediates cert you can just verify that the IoT Hub Certificate was signed by that specific Intermediate:
openssl verify -verbose -CAfile "Microsoft RSA TLS CA 02.cer" "Wildcard IoT.cer"
where the first certificate is the Intermediate and the second is your specific IoT Hub Certificate
The latest Intermediate certs can be found here:
https://techcommunity.microsoft.com/t5/internet-of-things/azure-iot-tls-changes-are-coming-and-why-you-should-care/ba-p/1658456
There are two main certs:
- Microsoft RSA TLS CA 01
- Microsoft RSA TLS CA 02
Final note
While the practice of certificate pinning is generally not encouraged, there are still some valid reasons to adopt it, especially when the rewards of being protected from man-in-the-middle attack are worth the extra effort.
Microsoft
