chrysn / aiocoap

The Python CoAP library
Other
267 stars 120 forks source link

OSCORE example #184

Open StefanHri opened 4 years ago

StefanHri commented 4 years ago

Is there an usage example for OSCORE clien/server similar to the standard CoAP client/server examples here: https://aiocoap.readthedocs.io/en/latest/examples.html

chrysn commented 4 years ago

Not yet. The closest to are the plugtest client and server programs in contrib/oscore-plugtest but they need to be used with some care. An example of how to set up aiocoap-client as an OSCORE client is also out there in the libOSCORE documentation (starting at "Cryptography setup", everything before is for the embedded device).

Good point, I'm putting it on the to-do list.

(Ideally, that'd be all much smoother to set up once LAKE is there to allow setup with PFS and sender ID negotiation, but admittedly, OSCORE needs to be usable on its own just as well).

lemikev commented 3 months ago

Any update on this issue? I have implemented an EDHOC hanshake and I will like to know how to setup OSCORE based on the generated PRK_exporter, C_R & C_I.

chrysn commented 3 months ago

There are some updates:

Which EDHOC implementation are you working with?

(Leaving the issue open because while there is documentation on OSCORE, there is no easy-to-use immediate example; I'll probably consider it done when EDHOC is part of the examples, as OSCORE on its own is not a reasonable example).

StefanHri commented 3 months ago

You may simply consider the examples in usocore-uedhoc. They work out-of-the- box on Linux and Zephyr OS.

chrysn commented 3 months ago

Looking at an OSCORE-EDHOC example that interoperates across implementations is certainly a good thing, will look into that. Is there a public instance running with this example somewhere?

I think that examples of "only OSCORE" are sending the wrong message to users: Unless one is using EDHOC, the ACE OSCORE profile, KUDOS or the non-normative OSCORE appendix B.2 example mechanism (which KUDOS provides a proper replacement for), using provided OSCORE key material is really hard (like, understand you can't backup your device, understand the error modes of your key/config storage), and users building on such examples are bound to be in trouble later.

lemikev commented 3 months ago

About "Which EDHOC implementation are you working with?" I built my own EDHOC handshake in python. It's a simple 500 lines script. This script is used as reference implementation for an embedded C project.

Our requirements make the integration existing libs sometime difficult :

I have not yet found how to initialize OSCORE with the (PRK_exporter, C_R, C_I) generated by the handshake. My next step was to run in debug the cli version as describe in documentation on OSCORE setuphttps://aiocoap.readthedocs.io/en/latest/stateofoscore.html to see how the OSCORE API works.

Unless you can provide my an example on how this OSCORE initialisation is done.

Thanks for your fast reply Have a great day!

[edit: Trimmed fullquote copy. --chrysn]

StefanHri commented 3 months ago

Hi everyone,

Christian, I don't have a public endpoint to test, but we can arrange a small interoperability test like we wanted to do during the hackathon. I'll send you an email to avoid cluttering the discussion here.

I also agree that relying solely on OSCORE isn't very scalable due to the challenges with key management.

chrysn commented 3 months ago

@lemikev: The easiest route for you is probably subclassing the oscore classes as is done in aiocoap's aiocoap/edhoc.py _EdhocContextBase/EdhocRecipientContext/EdhocResponderContext (or in aiocoap/oscore.py FilesystemSecurityContext; that one might be relevant if you want to do the full database integration). The three classes are not even a page each, and if you don't implement all roles, you'll just need half of it anyway.

If you publish what you are working on, we might figure out together which of the parts of the OSCORE context we'd need to turn into public interfaces … well, it might be even a valuable addition to general users. Currently, contexts created by EDHOC are only persisted in RAM.