Make OSCORE (application-layer security for CoAP) usable in RIOT

[chrysn]

Description

The OSCORE protocol promises to provide lightweight security for data-in-transit between constrained devices. Support for it would benefit RIOT-OS especially if CoAP examples would out-of-the-box provide the security we all expect from the IoT.

Useful links

• Latest specification (assignment of an RFC number pending)

Plan

I'm about to write a portable implementation of that protocol and to wrap it up as a RIOT package; in the course of that I'd appreciate feedback from the RIOT community on the API design and may have individual pull requests for gcoap to allow integrating such a module at all.

[kb2ma]

The rumors are true, then! We look forward to this work, @chrysn.

[chrysn]

The work-in-progress library is online at https://gitlab.com/oscore/liboscore; currently it consists mostly of API documentation.

With respect to integration in RIOT, I envision two consecutive steps (described for server application, but same for client applications):

• "light integration": The OSCORE library is available as a pkg, and bindings are in place that allow OSCORE to access a nanocoap message. Application authors can write a resource handler by receiving the package from RIOT (on a hook for /, because that's what all OSCORE message look like from the outside), passing the nanocoap package on to the OSCORE library and then using the OSCORE library's functions to extract request information (possibly dispatching to the right resource handler manually); then they build an OSCORE response message out of the nanocoap response message, use OSCORE methods to put their data in (oscore_msg_encrypted_set_code(...) etc), have it finish it, and send it back off.

  Not the most fashionable user experience, but can work without changing a thing in RIOT (well, once #11437 and possibly one or the other similar PR are through), is a good first step, and can later still be useful for very small applications.

• "deep integration": Application authors write their code as they always would, and only check for whether the request came in from an authenticated client (and 4.01 out -- or maybe we add a "needs security" flag on the resource). That'll probably work on gcoap level, and will need changes in gcoap to support variable transports. It should be simple to do once gcoap supports eg. CoAP-over-TCP, but as I understand, remote addresses are currently UDP sockets and not a union-of-all-transport-addresses.

  In the course of this, bindings inverse to those of light integration will be added, describing how a nanocoap "add this option" can be executed on the OSCORE message's API. (Doing that may, depending on the option details, call nanocoap's "add this option" again but on the underlying CoAP-over-UDP message).

Currently I'm focused on the first step, and https://gitlab.com/oscore/oscore-implementation/blob/master/API-SKETCH.rst describes the rough idea, and the concrete documentation (as far as the sketch was transferred to C so far) is available on https://oscore.gitlab.io/oscore-implementation/group__oscore__native__msg.html.

I'd appreciate any feedback both on the integration steps (especially: Does deep integration align well with the roadmap for Gcoap?) and the proposed APIs.

edit: update liboscore link (Kaspar)

[emmanuelsearch]

@kaspar030 @kb2ma any opinions on this?

[emmanuelsearch]

@bergzand might also have some opinion too wrt to libcose ?

[chrysn]

@bergzand might also have some opinion too wrt to libcose ?

We're tracking that primarily at https://github.com/bergzand/libcose/issues/89 at the moment.

[emmanuelsearch]

@chrysn what's the latest status? Do you have any ETA for your OSCORE code (possibly still in WIP state) so that people can start playing with that in RIOT?

[mp3patel19]

Hi @chrysn can i integrate LibOSCORE with LibCOAP as per current status of your library? Actually we have application on LibCOAP and we want to use OSCORE, so given the current status of LibOSCORE, is it possible?

[biboc]

Any update on this @chrysn ? We're interested in using it

[chrysn]

The biggest holdup is the inflexibility of the CoAP APIs to accommodate drivers. Work on making that more modular is being done in a student group at Dresden, but I don't know how far that has progressed since its kick-off at the IETF hackathon in November.

In parallel, I'm starting to assemble libOSCORE and lakers (an EDHOC implementation) into a usable stack from the Rust side around riot-rs. Accessing that composition from C can become possible when the API refactoring gets done, but would probably need a driving use case (because all current applications I know of lean toward going through Rust anyway). This includes things like stdio-over-CoAP.

What are your use case requirements?