Sleepwalking Into Chaos ... Developers Who Scale Existing Methods into IoT

Introduction

We need to see IoT development as a new opportunity to build an Internet where security is localised, and where it is greatly exposed both in a physical way and a cyber way. The network too often has to exist in an isolated form, and where each of the devices and network connections could be stripped down to reveal any secret element.

A study by Cambridge Centre for Risk Studies, for example, estimate that a large-scale power outage in the UK would result, in the worst case, of losses over five years of ￡442 billion from UK GDP. They conclude that the most plausible route would be to bring down the substations and cause blackouts for up to 13 million people, for several weeks at a time.

Cyber physical

On the Internet, we store our encryption keys on the servers, and then we protect them from external access. With IoT was have no such barriers, so if you use PKI and run local services, you have to store your private keys somewhere.

The only way forward is the setup of trust domains, and which operate independently from the rest of the Internet, and where the normal rules of trust do not apply. If the private key of Verisign was to be hacked, would we be able to go round every device which uses a Verisign certificate and revoke it?

Along with the general lack of skills in cryptography by developers, there's some worrying developments with IoT as developers just seem to be sleepwalking into scaling PKI into an vast infrastructure. Who is really thinking this through, and how we create massively-connected sensor and control networks? At present where there's a security breach, we go around our servers and patch. If there was a security breach on the private key of a car manufacturer, so you think they will be able to go round all their cars and patch them?

There is great debate within car manufacturers on the best way forward in patching their systems. With Volkswagen, we said the company trying to hide a large-scale vulnerability against their cars:

Still thinking of securing with a single key

When you have designers creating systems with a single decryption you really have to worry. In a recent case, GCHQ discovered that the company who were implementing smart meters in the UK were going to use a single decryption key for the whole network:

Add to this is that developers just think they can scale the existing PKI methods into a massive infrastructure. Is Verisign really going to certify the identity of our car and all the subsystems within it? At present PKI struggles in a Web infrastructure, where few people understand its complexities, so it's hardly going to be useful within an IoT environment.

Trust networks

The usage of trust networks is possibly the only way forward. Kerberos is one method that could be used, but it's rather complex for an IoT environment:

 Identity-Based Encryption (IBE), though, could provide a strong solution. With this we can create unique identities within our trust environment, and then generate encryption keys, each of which can exist for given time intervals.

Lack of understanding and due diligence

The Superfish vulnerability showed that if a company like Lenovo can break PKI and then leave a key pair on a machine, any company could do it:

There's so many examples too of self-signed certificates being used within highly trusted systems. We have seen that even a company like Dell can fall into the same trap. With this it, like Lenovo, included pre-installed software, and included a self-signed root authority (CA), and which is used to identify where Web sites are trustworthy (know as "eDellRoot"). Intruders could then easily extract the private key from the certificate, and then use this to listen to any traffic that was generated when using the certificate, and also to impersonate valid Web sites (as the private key is used to sign a fingerprint, and which is validated by the public key).

The eDellroot certificate has since been seen on a number of computer systems which connect to the Internet, including within a SCADA (supervisory control and data acquisition) system, which are often seen as requiring the highest level of security (as they often control safety critical equipment).

Along with this there is a second vulnerability using  a CA named "DSDTestProvider", which did also exposed the same major vulnerability, where an intruder could create fake certificates which pretended to be valid Web sites, as the system would trust any site which are trusted by the CA. Along with this an intruder can sign email messages, software drivers, Web services, and many other things, while also intercepting secure traffic.

With the Dell situation, IT departments can easily path systems, but if the flaw is within an energy or health care application, it could cause major problems.

Conclusions

Any developer who starts thinking that they will use a single secret key to secure their devices has really not been thinking things through. In a company I can revoke my certificates and renew on the loss of the private, in a network which is physically separate and accessible, this will be a challenge.