It’s estimated that nearly 21 billion IoT devices will be deployed by the end of 2020, almost double the amount from 2018. This is good for both users and manufacturers, who will have more selection and sales. However, it poses a significant challenge for the cybersecurity professionals charged with keeping these devices and networks secure.
As IoT device popularity has soared, so have attempts to hack them. Some worrying examples include:
- The Mirai botnet that infected over 600,000 IoT devices and used them to create the largest DDoS attack on record. Its attacks took many huge sites (including Netflix, Amazon, and Twitter) offline and caused over $100 million in damage.
- The FDA warned in 2019 that certain Medtronic insulin pumps could be compromised by hackers. This would give hackers the potential to over or under-deliver insulin, causing major health issues for diabetics using the devices.
- Researchers have demonstrated several vectors of attack to utilize Amazon’s Alexa or Google Home to eavesdrop on users or hack private accounts.
- An exploit in home camera and baby monitoring devices, including Ring and Google Nest, that allowed hackers to use cameras that people have installed to spy on their owners.
While experts have warned of the dangers of IoT devices for years, the industry itself has had considerable difficulty implementing successful and holistic security measures. There are several reasons that IoT devices are especially vulnerable to attack. One of the biggest is the extensive chain of production that can see a number of third-parties contribute to a single device, making it difficult to create a secure “factory floor” environment. Another problem is that, once deployed, these devices can be difficult to securely update for discovered software bugs and flaws. At the same time, their small footprint makes them unsuitable for traditional endpoint protection solutions such as antivirus.
The primary defense for IoT devices rests on using a public key infrastructure (PKI), which provisions each device with an identity that’s underpinned by a security certificate. This certificate allows a device to authenticate the private key it uses to securely communicate with both its server and user. But what happens if a device is compromised? How can it be stopped from further compromising an entire network? This is where a certificate revocation list (CRL) comes in.
What is a certificate revocation list?
Certificates are a foundational element of public key infrastructure, which in turn is a vital piece of modern internet. These digital certificates are used to authenticate the parties that they’ve been issued to and create a hierarchy of trust. Technology implementations like two-factor authentication, code signing, digital signatures on documents, etc. all rely on this model of trust.
PKI certificates are issued by a CA (certificate authority). The CAs are responsible for creating as well as managing these certificates. The PKI service itself and it’s management can be done either via professional third-party service providers or built in-house. The integrity of the entire PKI infrastructure depends on the security of and trust in the CA. In addition to ultra-secure facilities, a critical element to maintain that trust is established processes for dealing with common certificate security issues, such as:
- Compromised keys (such as when a device has been hacked and its private keys stolen)
- A certificate user no longer being trusted
- Changes in how the certificate is used
- Errors in the certificate itself (such as Apple, Google, and others revoking millions of certificates with 63-bit serial numbers when they were supposed to be 64-bit)
In order to maintain trust, CAs revoke or suspend the eligibility of certificates that no longer meet their standards. These are then collected on a certificate revocation list, which creates a blacklist of security certificates that have been suspended before their expiration date (expired certificates would be suspended in any case and are not on the revocation list). Any server or user attempting to communicate with a compromised device will be told that the certificate they are using is not valid. This process is known as revocation checking and happens before any attempt to create a connection.
The certificate revocation list is digitally signed and time-stamped by the CA (though sometimes this is performed by a third-party certificate revocation list provider), giving the list the same authority as the certificates being issued.
In a world where billions of devices are communicating independently, it is essential for companies to have an automatic warning system about insecure communications. Without an updated and easily checked CRL, it would be virtually impossible to warn the server about every potentially compromised device that tries to communicate with it.
Certificate revocation lists and Seacert
When deciding upon a PKI provider to create a trusted environment for your IoT device network, it’s important to determine whether they keep an X.509 certificate revocation list and how it is maintained. Intertrust’s Seacert is a managed PKI solution that provides secure identities to IoT devices and has already provisioned more than two billion devices globally. Seacert offers a full range of services to keep devices secure throughout their lifecycle including certificate revocation signing and hosting.
*** This is a Security Bloggers Network syndicated blog from Intertrust Technologies - Security Blogs authored by Prateek Panda. Read the original post at: https://www.intertrust.com/blog/certificate-revocation-lists-and-iot-devices/