End to end encryption
Establish secure channels over multiple hops
Generic channels
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 only TCP is currently implemented. This part was used as an option in the remote update mechanism, between the device and the scheduler.
HTTP message signatures
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 HTTP message signature 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 :
content canonicalization 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.
Other proofs of key possession methods
Within IETF GNAP, we also defined other methods (including mutual TLS) to prove possession of keys and tokens, instead of relying on bearer tokens. Also, the IETF GNAP opens the possibility for various types of tokens, not limited to JWT, and supporting capabilities (cf our prototype biscuitsec.org, which will be proposed as an IETF standard).
Last updated