Leveraging the particle platform's crypto libraries for user code?

Based on what I’ve read, the particle platform uses a crypto library (looks like TropicSSL) to communicate with the cloud API. Is there any support for using this from user code to avoid reimplementing the wheel? How about using the device’s keypair to secure communication with hosts other than the particle cloud?

Also judging by previous discussions, you’re using CoAP as well. Any support for using that from user code?

It certainly seems a shame to have all this useful library code loaded in the base firmware if it’s not callable from user code!

Source is available. The CoAP stuff is non-standard ( as it uses TCP instead of UDP ) and most messages are hard coded headers with a payload attached, so there aren’t many libraries to speak of. If you take a look in the spark_protocol.cpp file in the previous link you can see how they do it.

CoAP is fairly simple to implement, it’s just packing bytes together in the UDP buffer and sending it out. The tricky part is doing things like caching and re-sending confirmable messages and keeping track of which messages have been ACKed. I suppose that’s why the spark folks decided to use TCP instead, which handles that kind of stuff for you.

Right, I know the source is available - my question was, can we link to it in our user code rather than including it (or a different library) a second time and wasting space? For that matter, can we expect it to remain stable, or is it considered an internal implementation detail?

Then there’s the issue of the higher level protocol - is it using TLS, and if so can we leverage it for our own TLS connections? If not, is there a concept of an ‘encrypted and authenticated connection’ we can reuse?

Good questions. Maybe someone more familiar with that section of the source can help you.

As for whether things will remain stable, things will change within each patch. That’s true for any code base not entirely under your control.
I know these are ‘hobbyist’ devices but if you’re concerned something might break you should have regression tests for the expected behaviour of functions you use, even the user facing and HAL functions have changed the return values between patches of the base firmware.
The other option is to find a stable patch and use that as your development source, and only update once you decide the next patch is stable to your needs.

The question is whether Particle consider this functionality as part of their public interface, or an internal implementation detail (I suspect the latter, but it’d be nice to convince them to make it the former); if the latter, they may change it at any time without warning, but if it’s public, we can expect some degree of stability and deprecation warning.

this may help

Indeed, thanks! It looks like the compiler must include the header file when compiling the main module, even.

It’d still be good to get some official news from Particle as to whether we can expect this to be stable or not.

Hey @nickjohnson, good question — the tropicssl AES implementation is definitely not part of our documented public API. It should continue to work for the foreseeable future, but at some point down the road (2016 summer/fall?) we’ll create a publicly documented API for crypto tasks.

Thanks for the details. I might go ahead and port the uNaCL library to Particle, then.

1 Like

That sounds awesome. Please do that!

FYI, I have forked the Cryptosuite project to work with the Photon. So far I have only debugged the SHA256 and HMAC SHA256 portion as that is all I need at the moment, but think I have worked through the major issues required to get any of it to work. Take a look and see if this or other parts might be useful to you. My interest is to sign data transmissions to insure they are not tampered with or faked. In this application I don’t really care if the info is seen by others, just that it is authentic. Its pretty fast, taking less that 1 msec to hash the examples.

Github