- Ockam raises a $12.5m Series A to build a remote-first, high-performance team.
- Ockam at Oktane 2021 - A builders guide to Trust.
- How we build Ockam as a High Performance Team
- Zero Trust in Time Series Data?
- Diffie-Hellman Key Exchange: How Does it Work?
- Zero-to-IPO: Charting Ockam’s Route
- Ockam: A Philosophy on Open Source Software Design
- How to Make Your First Open Source Contribution
- Public Key Encryption Explained
- Where Should Open Source Communities Chat?
- What are Cryptographic Keys?
- Ockam at Oktane 2020 - The Future of Trust
- Even this website is open source...
- Why IoT needs Secure Messaging
- Open Source is the Internet’s Most Important Integrator
- IOT Device Security is Not One-and-Done
- Why Ockam loves open source, and you should too!
- A Beginners Guide to the STRIDE Security Threat Model
- Media Links
- Ockam Raised Seed Funds to Empower The Builders Of A Seamless Connected Future.
- The Next Wave In Developer Tools Will Be The Catalyst That Enables The Internet Of Things.
- The Nine-Factors Of A Well Tuned Network Of Connected Devices
- Introduction to building Trust Architectures
- What's the story behind the Ockam name?
Why IoT needs Secure Messaging
Published 2020-03-28 by Mrinal Wadhwa
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:
- 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.
- 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 tradoff, 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.
- 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, rotable 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.
- 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.