Say Goodbye to Digital Certificates on IoT Devices

Mark Lambe

51% of enterprises claim to have issues with digital certificates.

From an IoT industry perspective, this is troubling. But how did we get to this?

An interesting way for me to share a reason as to why the problem exists is to chart our evolution of delivering an IoT connectivity service.

When we started the Asavie IoT service journey some years ago, we recognized like many others, that IoT should not be on the public internet. We saw that many IoT devices were simply ill-equipped to deal with cyber threats on the internet.

“51% of enterprises claim low ability to detect and respond to digital certificate and key misuse.”

source Help Net Security


Self-serve a Private Mobile Network slice

As a network as a service provider, we recognized that the Asavie platform offered enterprises a viable alternative by using mobile connectivity. A private mobile network slice, that takes IoT out of the line of fire of cyberattacks. Hence, Asavie SD IoT was born.

However, in those early days of IoT in the cloud, the operational technology (OT) team had to engage with the information technology (IT) team to architect their private cloud service for data collection.

The remaining issue was to then secure access to the IoT edge. A problem that we continue to solve today with Asavie SD IoT. By extending the mobile network into the virtual private cloud (VPC), both the IoT device and traffic are protected.


Seamless Cloud Access

However, the beauty with the Asavie solution is that the trust of the device connecting to the cloud can be attested using a standard SIM card. As the SIM identity is tamper-proof, enterprises have an easy way to authenticate, authorize and secure the data transit into the VPC.

As time progresses, things change and so did the cloud service providers (CSP) offerings. The CSPs recognized the complexity of architecting secure application services and so began offering public domain accessible IoT services. From an OT perspective, this solved a significant pain – no need for IT to build and maintain the service architecture.


Who left the PKI cat out?

What I think is interesting, it is at this point that the CSP put a managed public key infrastructure (PKI) in the hands of the OT. The CSP had simplified the journey of seeding trust in devices with digital certificates. Making secure access management to the cloud simple for OT. I sometimes see this as the starting point for “Shadow IoT”.  Where IT no longer has visibility over IoT and the security posture of the devices.

Fast forward to today, and we are now seeing the headlines like above, that enterprises are worried about potential vulnerabilities. The impact is that “Shadow IoT” is now cemented in the enterprise as a legitimate security issue.

One of the problems we foresaw with public IoT services, is that the certificates were (still are in many cases) being manually handled i.e. downloaded from the cloud and uploaded to the IoT device. This is where the security gap occurs. The digital certificate private keys are being stored in a potentially unsecured location, creating the vulnerability we see mentioned in the news article.


Adieu to X.509 certificates

As part of the evolution of the Asavie SD IoT service, we set to building an automation framework that would remove the need for human eyes and fingers. The idea is that the private network would provision the digital credential based on the unique identity of the SIM.

Once we provisioned the credential, we needed to store it somewhere. At Asavie we take our security seriously and the only place the credential could be stored was in a private key management service (KMS). So today, users of Asavie SD IoT have a highly scalable KMS vault, which is a native element inside their private mobile network slice.

However, the Asavie SD IoT implementation is unique as it can proxy connections on behalf of the IoT devices. The result is that the credential no longer needs to be put on the IoT device. The digital certificate is only accessed by the proxy service when the device wants to send data to the cloud. The result is that there are no human touchpoints or access to the private keys, closing the security vulnerability gap.


Future Proofed Access

The need to roll credentials on IoT is where we are today in the news article. With OT struggling because the device is no longer accessible, and the misuse of digital certificates now being touted as a security risk.

A key advantage of the Asavie SD IoT service, from a digital credential perspective, is that users can roll over credentials as often as they like (daily if necessary) with no disruption or update needed on the IoT device.


Leap to safer IoT deployments

If you are battling the quagmire of IoT digital credentials or looking to simplify your IoT deployment get in touch: