The Need For Trust
As IoT propagates deeper into our lives, security mechanisms must be standardized to provide a clear and transparent view into how secure each and every connected device truly is. One of the show stoppers for mass adoption of consumer IoT products, is the lack of a convenient way for end users to estimate if a certain product can be considered safe and can be trusted for daily use.
One example is the connected camera market, which suffers from a lack of trust following few widely known security breaches, including a hack of Trendnet in 2012, which exposed sleeping babies and children and prompted an FTC investigation, as well as Insecam, a Russian site that linked to 73,000 unsecured security camera locations across 256 countries and was shut down by authorities this past November.
Taking the problem one step further, a man-machine relationship of trust is not enough. The true added business value of IoT comes from collaboration and open M2M protocols between vendors. By exposing open APIs and exchanging information with other devices, an IoT vendor starts to depend on the product security of another vendor — not just their own. Imagine the stock price of an autonomous vehicle manufacturer in case of one deadly accident caused by hacked traffic control systems.
Traditional Trust Vendors
A separation of powers between software providers and trust vendors (CA – certificate authorities) has existed for decades in the field of web security. For example, SSL vendors sell asymmetric crypto-certificates used for encrypting the channel between the browser and a secure web-server. More important is the fact that SSL certificates provide a convenient way for a bank customer to ensure that he is actually browsing the bank website and not a fake site. A consumer may not be familiar with an online bike shop, but should trust well known certificate vendors to ensure that the bike shop business actually exists.
Microsoft successfully manages a software signature ecosystem based on certificates, to protect users from installing software from untrusted sources. This mechanism supports certificate revocation if a software vendor is reported to do bad things. Installation of unsigned software will trigger a scary window or will not be allowed at all (in case of software requiring kernel mode permissions).
The Issues with Traditional Trust Model in IoT
Asymmetric certificate provides two basic benefits – to identify the machine we are communicating with and to provide a secure encrypted peer to peer channel.
When replicating this mechanism to the world of IoT, a basic long-term certificate is not sufficient. Connected devices are usually more vulnerable to cyber-attacks due to several factors, including:
- They reside in hostile environments usually uncontrolled by the vendor.
- Computational power (and/or battery limitations) is not sufficient for sophisticated security mechanisms to run on the device.
- They cannot support signature based anti-virus tools which depend on frequent updates.
- Automatic firmware upgrades are complicated and less frequent.
What we need is to extend the basic concept of certificates with ability to deliver trust in terms of cyber security – a more dynamic, score-based way to validate the device.
The Organic Trust Score
An Organic Trust Score is an attempt to define a standardized and convenient way for machines and humans to decide whether a certain device can be trusted before interacting with it. The score is to be provided for a time-limited period, by a well-known trust vendor, according to the following criteria:
- Vendor applied security measures (encryption, authentication, access control) according to device classification (life critical, business critical, consumer, etc.).
- Ongoing real-time analyses of deployed device and its environment.
- Known threats and discovered vulnerabilities in the current version of software.
Figure 1- Organic Trust Score criteria
Trust vendors would issue a cryptographic certificate with a recently measured Organic Trust Score (and a list of discovered problems affecting the score). Temporary certificate hold or permanent revocation procedures would be applied after a critical security event (i.e. real time breach, critical vulnerability discovered). For example a surveillance camera will be shut down and CISO will be reported in the case of a detected attack, stopping the device immediately from being used for malicious purposes.
Organic Trust Protocol
For an Organic Trust Score to be viable, it needs to be a part of signed certificate. The well known X.509 certificate is widely supported and could be a good candidate with a few changes:
- The issuing period should be significantly shorter to the period applicable for a certain class of devices.
- The Trust Score can easily be added inside the certificate as a certificate extension.
- Certificate whitelisting can be used for temporary disabling devices.
- Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used for permanently disabling problematic devices.
- New certificates with updated Trust Score can reissued following discovered breach or firmware update.
As IoT continues to expand, I expect existing trust vendors like VeriSign, GeoTrust, and other to lead the way in playing the role of issuing authority, while adopting new technologies and paradigms to support the required criteria.
Meir Tseitlin is a CTO of Imubit, provider of Endpoint Security Solution for IoT