Why IoT needs Secure Messaging

Hi. My name is Mrinal Wadhwa.

I'm CTO at Ockam and I'm passionate about enabling a future where autonomous machines work together, using intelligent algorithms, to improve the way we live and work.

The status quo, however, is that most connected applications, today, are not very secure, private or dependable ... at Ockam, we are determined to change that.

Machines, within the Internet of Things, operate by exchanging messages, with cloud services and other connected machines.

If we wish to build applications that are secure against attackers, malware, ransomware etc.

Applications that can safely carry our customers’ private and proprietary data.

Applications that are dependable ... in crucial scenarios like health care, public utilities, transportation, and manufacturing.

If we wish to build such trustworthy applications …

Then we must ensure that the messages that carry configuration data, sensor readings, control instructions and firmware updates ...

These messages are safe against eavesdropping, tampering, and forgery.

Regrettably, most IoT and Edge applications that are built and deployed today are unable to provide these three basic protections… protection against eavesdropping, tampering, and forgery of messages.

These weaknesses are usually due to the following four reasons:

1. Implicit Trust in network boundaries.

A naive way to protect messages that are flowing between applications … is to create physical or virtual network boundaries and only allow select trusted machines into such boundaries.

This, sort-of, worked when there were a lot fewer computers in the world and those computers were fixed to a desktop or a server cabinet.

IT and OT departments have learnt that network boundaries cannot be enforced in the modern landscape … of mobile devices, internet of things, cloud applications and a remote workforce.

It is also unrealistic to expect home users to successfully guard their network boundaries when it is increasingly common for homes to have a large number of connected devices that come and go.

Unfortunately, many IoT and edge applications in homes and in industrial environments are still built with implicit trust in network boundaries.

Here’s an example of a connected switch from a prominent vendor .. if anyone sends THIS message to the switch… the switch reveals whether it is ON or OFF

If they send this other message …. the switch will turn ON.

It is trivial for an attacker to tamper or forge such messages and remotely take-control of the switch because the embedded application code in the switch implicitly trusts all incoming messages without authenticating the sender or validating the integrity of the message.

Secure applications should not do this they should instead place Zero Trust in Network Boundaries

Every message, that is received by an application, must carry a proof to assure that the message wasn’t tapered or forged.

A dependable application must be able to dynamically decide if it has enough assurance to trust and act on the information or a command received in a specific incoming message.

2. The second reason connected applications often have weaknesses is that their architecture lacks the ability to establish mutual trust.

It is common for IoT application architects to take inspiration from how they design browser based web applications and only establish trust in cloud services with one-way authentication. They decide that it's okay to not authenticate devices because it seems too complicated to manage unique credentials in a large fleet of devices …

And that their devices are just simple sensors … so they don’t need to authenticate or authorize them.

This is a flawed trade off, because if their business and its customers are relying on the information collected by these sensors, then there is incentive, for an attacker, to tamper or forge that information.

Dependable IoT applications must instead be able to mutually authenticate and authorize … all exchanges of sensed information and control instructions.

3. The third common reason for vulnerabilities in connected applications is … poor management of credentials.

Once application developers discern that in order to have trust-worthy, dependable information flowing within their applications they need to mutually authenticate and authorize all exchange of messages …

Once they discern this … they are faced with some hard challenges …

To ensure that sensor readings and command acknowledgements sent by remote devices cannot be forged or tampered each device must possess unique cryptographic keys and credentials.

How should a system generate, deliver and store these UNIQUE credentials in a large fleet of thousands of devices?

Every IoT development team ends up hand rolling mechanisms for provisioning keys, activating devices and bootstrapping trust.

This is often a source of mistakes like default passwords or hard coded secrets.

Architects are faced with further daunting challenges if they wish to follow good security hygiene and make these device credentials short-lived, routable and revocable.

Teams shouldn’t have to design ad-hoc protocols for enrollment and access control in devices; they need simple and proven tools to safely manage keys and credentials at scale.

4. The fourth common reason for weaknesses in connected applications is the lack of end-to-end safety for messages at the application layer

To protect en-route messages against eavesdropping, tampering, and forgery … we usually need a cryptographic secure channel protocol.

Most IoT message transport protocols support some way to establish a secure channel.

However, such secure channel protocols have traditionally been tightly coupled to their corresponding transport protocols.

Their security guarantees are limited by the length and duration of a single transport layer connection.

This constraint, often leads to application architectures that violate the foundational security principle of least privilege ... exposing applications to a vulnerability and liability surface that is a lot bigger than it needs to be.

It is common, for messages in intelligent, connected applications, to traverse a complex path that isn’t a simple point-to-point transport protocol connection.

To support occasionally connected devices, low power radio protocols and containerized microservices... messages usually travel via a number of message queues and caches, often over a series of network layer connections… before reaching their end destination.

Since, the protections offered by traditional secure channel protocols are limited by the length and duration of a point-to-point transport connection these traditional protocols are unable to keep our application messages safe along their entire path.

A compromise of a third party cloud service, or a network intermediary or low power radio gateway can cause our application data and commands… to be snooped on, tampered or forged.

Secure, Private and Dependable connected applications, instead… need end-to-end trust in application layer messages … they need end-to-end encrypted secure channels.

To summarize: Implicit trust in network boundaries, lack of mutual, end-to-end trust in information and commands that are exchanged at the application layer, and poor management of credentials - are the root causes that are holding back developers from building and scaling... secure, private and dependable connected applications.

At Ockam, we’ve built … easy to use, open source programming libraries and protocols … that make it simple to tackle all of these core challenges.

We’ve made it simple, for you, to build dependable connected applications that place zero trust in network boundaries and third party infrastructure.

Applications that safely exchange credentials to provide granular, attribute based, privacy preserving, policy driven, access control over connected machines to your users.

Applications .... that communicate Securely and privately using end-to-end encrypted, mutually authenticated channels

Applications that embrace the principle of least privilege and can be dependable parts of a future with autonomous systems.

If you're interested in learning more about Ockam's approach to Secure Messaging, we're discussing our protocols and architecture openly on the Ockam Proposals repository and on Ockam Discussions, come join us.