CBC implementation

Hey,

our goal is to implement a basic DTLS [1] implementation for RIOT. For the beginning we just want to support PSK ciphersuites [2] (particularly TLS_PSK_WITH_AES_128_CBC_SHA and TLS_PSK_WITH_AES_256_CBC_SHA). By browsing through the RIOT codebase we found an existing AES implementations which works quite well. There also exist a cbcmode.h in sys/include/crypto/ which should be for cipher block chaining but there is no actual implementation. Am I missing here something or does RIOT only have these function declarations (without defintions) for cbc?

Greetings Jonni and Nico

PS: for interested people we implemented a basic AES (without CBC) shell to play around. You can find it on github [3].

[1] http://tools.ietf.org/html/rfc6347 [2] http://tools.ietf.org/html/rfc4279 [3] https://github.com/cholin/RIOT/tree/features/aes_example/examples/aes

Hey.

Ok then I think we'll have to go for a new cbc implementation for RIOT. A bit reinventing the wheel because there exist several good aes implementation like in PolarSSL [1] (licensed under GPLv2 or later) which already includes AES-CBC. Anyway thanks for your help!

Greetings Nico

[1] https://polarssl.org/aes-source-code

Why not TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_AES_128_CCM? (Those are the ones you’ll need with CoAP.)

Grüße, Carsten

Well for simplicity reasons. I think AES in CBC-mode is much easier to implement for a constrained environment like embedded devices and there exist several good reference implementations. As this DTLS implementation for RIOT is part of a software project lecture at the Freie Universität Berlin we try to divide our project into several consecutive tasks which are easy to solve. If there is time we can extend the implementation with support for TLS_PSK_WITH_AES_128_CCM_8 as mentioned in RC6655 [1] and Dice-Draft [2] for CoAP.

Greetings Nico

[1] https://tools.ietf.org/html/rfc6655 [2] http://tools.ietf.org/html/draft-ietf-dice-profile-01

Well, for TLS_PSK_WITH_AES_128_CBC_SHA you do need to implement HMAC. I’m not sure about the exact relative complexities of (CBC + HMAC) and (CTR + CBC-MAC), but I don’t think that the latter is more complex in any appreciable way.

Grüße, Carsten

As far as I understood DTLS you have to implement HMAC anyway for the cookie calulcation in the handshake protocol (RFC 6347 - Page 17) indepedent of selected ciphersuite to counter Denial-of-Service. But as you see we are currently still researching. I'll consider implementing TLS_PSK_WITH_AES_128_CCM_8 instead of TLS_PSK_WITH_AES_128_CBC_SHA after we have a better deep understanding of DTLS.

Greetings Nico

Hi Nico,

if I get it right, PolarSSL already provides CCM mode by `aes_crypt_ctr()` from which I'd guess effort needed to implement CCM can be considered lower than CBC_SHA mode. Especially it probably has a smaller memory footprint since it doesn't need any hashing functionality. Also, many (modern) MCUs provide crypto coprocessors to calculate AES in HW. (But that would be out of scope of your SWP I guess :))

Best, Thomas

((I didn't notice that my mail bounced and only Nico got it.))

There also exist a cbcmode.h in sys/include/crypto/ which should be for cipher block chaining but there is no actual implementation. Am I missing here something or does RIOT only have these function declarations (without defintions) for cbc?

Hi Nico,

no it's only the header. The function names aren't prefixed and don't follow the coding conventions. In doubt replace the header file.

If you implement cbc, then you might want to call your module "crypto_cbc". The files you need to amend are "sys/Makefile", "sys/Makefile.include", and probably "Makefile.dep". Then copy any folder in "sys/crypto", rename it to e.g. "sys/crypto/cbc" and amend it's Makefile.

Greetings René

Well, regardless of what PolarSSL provides I'd ask Nico if he and his team could use/port another library.

So, Nico, could you use another library? RIOT is licensed as LGPL and PolarSSL is GPL. Though you probably will fulfill the requirements of your lecture, you won't provide anything for "mainline RIOT" at all if you (have to) use a more restrictive license. We simply won't be able to merge your extensions, without relicensing RIOT as GPL.

If it is only about the HMAC implementation, then you can find many many BSD-ish implementations out there in the Internet. I don't know what else you with need, but please look if you can find another source for your DTLS implementation if you intend to mainline your code.

Greetings, René

We have this in mind. I think we will look into GnuTLS (LGPL), TinyDTLS (MIT) [1] or Contiki-DTLS (BSD) [2].

Greetings Nico

[1] http://tinydtls.sourceforge.net/ [2] https://code.google.com/p/contiki-dtls

Nico Geyso <Nico.Geyso@FU-Berlin.de> writes:

We have this in mind. I think we will look into GnuTLS (LGPL), TinyDTLS (MIT) [1] or Contiki-DTLS (BSD) [2].

tinyDTLS provides CCM using Aaron Gifford's SHA256 implementation for the HMAC and the rijndael code from OpenBSD. There are also stand-alone versions of that code I can contribute if you are interested.

Gruesse Olaf

I'm currently looking at your implementation of CCM in tinyDTLS [1]. Seems simple but if you have a stand-alone implementation anyway I would be interested!

Greetings Nico

[1] http://tinydtls.sourceforge.net/ccm_8c_source.html