Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Light-weight security also for Netduino?

Started by Cuno, Apr 13 2014 09:14 AM

Please log in to reply

6 replies to this topic

#1 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 09:14 AM

If you are interested in strong cryptography on STM32 microcontrollers, as used in the newer Netduinos, you may be interested in our latest Mountaineer Firmware 4.3.1 Beta 3.

This new beta release, which is based on our NETMF for STM32 open source software like the firmware of the Netduino 2 family, contains a new experimental crypto library:

Oberon.NaCl is a light-weight cryptographic library for NETMF-based IoT devices. It is a small and easy-to-use tool box that you can use to build secure communication protocols, secure firmware update mechanisms, etc.

It is based on NaCl, pronounced "salt", a highly regarded suite of cryptographic algorithms designed and implemented by D. Bernstein et. al. It can be implemented efficiently even on single-chip microcontrollers and supports both symmetric and asymmetric cryptography.

A great introduction is given by Marco Poponi here:
http://www.tinyclr.i...1-platform.aspx

Links to examples and additional background are given here:
http://www.mountaine...crypto-library/

We are considering to contribute our code, along with a test suite, as a new core component of NETMF. Under the Apache 2.0 open source license, like the rest of NETMF. This will depend on the community feedback. At the moment, we see Oberon.NaCl as an experimental feature that may or may not find its way into the final release of the Mountaineer firmware.

Microsoft told us that they intend to set up a community process for contributions like this one. Until that process is in place, we use this forum here as a sounding board. Please let us know whether you feel that such a library would add value to NETMF, whether you see any issues with the API, and especially how you would like to use the library.

I�d like to thank Dan Berstein and his team for their impressive work and for making it public domain, Marc for finding and choosing NaCl, Pascal for implementing, testing and documenting our adaptation, Beat for understanding the involved math in-depth and for seeing the optimization potential of an already fast implementation, and Stephan, Etan and Thomas for multiple API and code reviews.

Cuno

Nevyn likes this

Back to top

#2 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 09:23 AM

Here some additional comments by Pascal, who was the main developer working on this library. They are relevant especially if you want to implement a protocol on top of NaCl:

DJB provides a really good protocol example on his curvecp webpage: http://curvecp.org/packets.html . I really recommend to have a look at his website before implementing any protocol or message exchange based on NaCl (ZeroMQ also implements the same protocol as well: https://github.com/zeromq/libcurve ). The base protocol is also useful if you want to encrypt multiple messages with the same private key.

On Mountaineer the hardware number generator is used to generate keys. On .NET we use the System.Security.Cryptography.RandomNumberGenerator to get a cryptographic random number generator for keys (we don't use System.Random which is a pseudo-random number generator).

The C# implementation doesn't allocate additional internal memory. A byte array passed to CryptoBox.Box is directly passed into the NaCl C-library. Hence the C# library requires C-style padding.

CryptoBox uses CryptoSecretBox internally. CryptoBox has an additional step where the shared key is computed (CryptoBox.BeforeNm) and fed into CryptoSecretBox (AfterNm).

The library can be tested here: https://bitbucket.or...acl.samples/src (it works on both Windows and the new Mountaineer 4.3.1 beta 3 release)

Additional information regarding the NaCl implementation can be found on the Mountaineer website: http://www.mountaine...crypto-library/

Back to top

#3 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 11:28 AM

A clarification: Oberon.NaCl mainly consists of C code, plus a C# wrapper (interop code). If we see enough interest, we will publish the complete source code as part of the final release of NETMF for STM32. Then anyone will be able to integrate the library into their own custom NETMF firmware.

Back to top

#4 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 13 April 2014 - 11:41 AM

Hi Cuno,

Cool stuff. What other types of devices out there support this cryptography protocol? Or is this meant to be a lightweight crypto protocol for related devices?

Chris

Back to top

#5 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 12:08 PM

Cool stuff. What other types of devices out there support this cryptography protocol? Or is this meant to be a lightweight crypto protocol for related devices?

Hi Chris

It's not a protocol, but rather a toolbox that you could use to build your own protocol on top of it. Of course, if you run your own protocol, you need control over both end points: on the device and in the cloud (or wherever the other end point is).

Bernstein himself has proposed a protocol based on NaCl, CurveCP:

http://curvecp.org/packets.html

This protocol is used e.g. in ZeroMQ, a light-weight alternative to AMQP:

http://hintjens.com/blog:34

Eventually, some of Bernstein's algorithms might end up in a revised version of the TLS standard:

http://tools.ietf.or...s-curve25519-03

Some of his algorithms are already supported in specific TLS implementations, e.g. by Google:

https://www.imperial...7/chacha20.html

Cuno

Back to top

#6 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 12:15 PM

We have measured the run times for the most important NaCl primitives on a random byte array for different lengths on a Mountaineer board (see nacl_stm32f4.png)

Although CryptoBox uses two different operations to encrypt (CryptoBox.Box) and decrypt (CryptoBox.Open) data we plotted only one operation, as both operations require the same time.
Looking at the plots we can observe that for byte arrays smaller than about 1 KB, constant time is required to encrypt and sign a byte array. In CryptoBox, this constant part is due to basic overhead:

Computing shared key using Curve25519

Interop calls from C# to the C library

The rest of the time is used for computing the stream cipher XSalsa20 on the data and storing it into the output array.
In CryptoSign, the constant part is due to:

Computing a hash of the secret key

Additional curve operations

Interop calls from C# to the C library

Beyond 1 KB, we observe that the rest of time is used for computing SHA 512 on the dataset. Compared to CryptoBox, CryptoSign uses far more curve operations.
The same thing can be observed when benchmarking the reference implementation of NaCl on a Windows PC (see nacl_i7).

Attached Files

nacl_stm32f4.png 10.31KB 1 downloads
nacl_i7.png 14.46KB 1 downloads

Back to top

#7 Cuno

Advanced Member

Members
144 posts

LocationZ�rich / Switzerland

Posted 13 April 2014 - 06:12 PM

Cool stuff. What other types of devices out there support this cryptography protocol? Or is this meant to be a lightweight crypto protocol for related devices?

Oh, not to forget some other protocols and platforms that use Bernstein algorithms: Tor, Moxie Marlinspike's TextSecure, SSH, OpenBSD, Apple AirPlay, Google Chromium.