If someone were to ask me what the most important aspect of building a successful connected business was, without hesitation I’d say security. The reason is simple. You can have the best/coolest/innovative product on the market, but if sensitive information (customer or otherwise) is put at risk, there is very little room to recover from reputational and punitive damages that a security breach can render.
We learned this the hard way with Internet security breaches and the IoT is facing the same fate. Well sort of. Given the potential sensitivity of the data that’s generated, and the always-on nature of IoT devices, the security challenge plaguing the IoT is unique and must be treated as such. We can’t take yesterday’s security and conform it to the IoT – it must be purpose-built.
So let’s talk about one way Xively has approached security. Many IoT platforms, including Xively, use digital certificates to protect communication between IoT devices and the server. Employing a digital certificate is a common means of verifying that a user or device on the Internet is who he/she claims to be, thus establishing a trusted communications channel between the two entities.
A certificate authority (CA) signs and issues a digital certificate to validate that Xively is indeed Xively, for example. When a device connects, it is presented with this certificate. The certificate includes a variety of parameters, such as a start and end date, as well as the algorithm used to encrypt the data. At the receiving end, the IoT device checks these parameters against the information it already has to validate the server. If the parameters match, the device creates a TLS connection to the server through which the service and device can securely communicate.
This is where most IoT platforms end their validation checks.
The problem with ending the check there, is that cccasionally certificates are revoked. This can happen for any number of reasons, but the bottom line is that a revoked certificate indicates the service can no longer be trusted. It’s possible the algorithm was compromised. Or that the private key of the certificate, or its signing certificate, has been stolen which can easily lead to a security breach via a man-in-the-middle (MITM) attack.
This is a perfect example of one of the unique challenges with the IoT security. An IoT device doesn’t know that a digital certificate is revoked unless it specifically checks. This is where the Online Certificate Status Protocol (OCSP) comes in. The OCSP checks the revocation status of a digital certificate helping to ensure that only trusted devices are being connected to trusted platforms. Because this check is an essential step in creating a strong security posture, we work with our customer to add OCSP to their IoT devices.
OCSP is not without its limitations, however. A traditional OCSP check requires the device to build a separate connection to the Certificate Authority’s OCSP response server – something many IoT devices don’t have the horsepower to do. To remediate that issue we’ve added OCSP stapling which reduces the power needed by providing the response during the initial connection process by the Xively server, rather than the Certificate Authority.
Security is something we take very seriously and we ensure that all the partners and customers share those same values. We work off the idea that doing the bare minimum is never enough. We take security several steps further than even the conventional best practices require in an effort to help bring to market the best and most secure IoT products available.