| We are building open source SDKs is multiple languages, for multiple environments to enable the following 3 things: 1. Generate, store & use secret cryptographic keys safely - in hardware or behind a tighter security boundary. There are Add-ons for Crypto Hardware Modules, Secure Enclaves, TPMs, TEEs, HSMs etc. 2. Use the above safely stored keys to establish secure, mutually authenticated, end-to-end encrypted channels. This secure channel protocol is decoupled from the network protocols which allows the secure channels to span across multiple transport layer connections and networks. This is kinda like an end-to-end encrypted connections that are established when you use signal or whatapp messaging ... but in our case we enable that between IoT devices and services and make it easy for application developers to have granular control on it. Imagine for example an end to end encrypted connection between your phone and your connected door bell - so the vendor of the door bell can help route the data but cannot see/store/modify/analyze the video data outside your door. In a hospital, a patient's private data is not exposed to every device or network or vendor in the path of collecting that data (there are typically 100s of such parties), it could instead be revealed only to the patient and their doctor. In an industrial setting, control commands to a critical machine cannot be compromised by compromising a weak network in the path of the command or business proprietary data is not revealed to every device or network vendor in the path of the data - instead they only get maintenance access to the component they are responsible for. It's important to note here that confidentiality is only one guarantee that is provided by encryption, the other two guarantees of data integrity and authentication are critical components that are missing in a lot of deployed IoT today. Our goal here is to give IoT application developers granular control to apply the Principle of Least Privilege to their IoT systems - which usually today have wide open attack surfaces with thin/weak boundaries. 3. Equipped with the above two foundational elements we want to enable easy solutions to scenarios that are very common in IoT. Usually application developers end up having to design ad-hoc solutions for these, our goal is to provide open source, vetted solutions for these common scenarios, for example: Bootstrapping Trust / Device Enrollment in IoT is very hard at scale - to have cryptographically secured, mutually authenticated channels one has to some how generate unique keys in thousands/millions of devices and bootstrap trust between devices and services without leaking these keys, we are building an enrollment protocol based on Signals X3DH to make this as simple as calling a few functions. Key Management is very hard at scale - Once you have unique keys provisioned in thousands/millions of devices, this only provides security for a short period of time ... you have to think about secure rotation and revocation of keys without physically touching every devices (which is cost prohibitive)... we are making that as easy as calling a few functions. Authorization is very hard at scale - IoT systems have a variety authorization use cases .. I might want to authorize a friend to use my car, only for a day, without giving them my cryptographic key forever ... An industrial maintenance engineer may only be authorized to see internal telemetry data of a machine for a day etc.
We are building a general solution of such exchange of credentials and capabilities that is secure, provides granular control and respects privacy. Checkout our github repo for how we're building all of this:
https://github.com/ockam-network/ockam |