End to end encryption
Establish secure channels over multiple hops
Last updated
Was this helpful?
Establish secure channels over multiple hops
Last updated
Was this helpful?
As part of the mediam project, we also reviewed and tested what other projects are building. We've evaluated ockam's proposal for secure channels, which is based on actor messaging. The aim of the platform is to support various types of transport, although . This part was used as an option in the remote update mechanism, between the device and the scheduler.
Contrary to generic channels, this solution only supports HTTP. However, it better fits the requirements of advanced authorization protocols such as GNAP. Encryption layers such as TLS are used to provide secure communications, however only direct connections are secure. If for whatever reasons (CDN, load balancer, proxies, TLS inspection gateways, etc.), multiple hops are required, it is again possible to tamper with the message.
An is a digital signature over an HTTP request or response, so that the content can be protected over multiple hops. We integrated this specification into IETF GNAP. A prototype was implemented.
The building blocks are :
according to the rules defined in the draft
This part was used in the remote update mechanism, in the communication between the vendor and the scheduler, and optionally between the device and the scheduler.
Within IETF GNAP, we also defined other methods (including mutual TLS) to and tokens, instead of relying on bearer tokens. Also, the IETF GNAP opens the possibility for , not limited to JWT, and supporting capabilities (cf our prototype , which will be proposed as an IETF standard).