my name is Francesco Ermini, and I’m student in electronics and telecommunication engineering at the University of Florence,Italy.
My current Ms.C. thesis is about IoT secure communications. Our testbed is made by some UDOO Quad boards, with Linux + RiOT as operating systems (the UDOO can host two OSes at once).
I checked the GSOC ideas page, and I found the Bluetooth Low Energy driver one. Although interesting, using BTLE wouldn’t rally match my current work.
However, we also found that the XBee shield is not yet supported in RiOT (open bug / feature request). This would match a bit more my thesis work, and my (evil) tutor would be happier.
My question is: what about implementing the XBee driver (including the dynamic security keys setup) ?
Cool that you are working with the UDOO boards! BLE development with these boards would indeed be a little difficult, as I don’t know any shields without fully integrated network stack, that would allow for access to the BLE link layer.
Porting the Xbee device to RIOT is unfortunately already almost finished  - I am just sitting on the last fixes and will release a PR in the next couple of days…
The security aspect however is not yet included. Taking this to a more general approach (valid for not only the xbee device) is however a very hot topic. Here I would indeed see a project for GSOC. Do you have already any further ideas what you would like to do in this direction? It would be nice, if you could roughly sketch our your ideas, so we can discuss them further.
Thanks for the Xbee driver,I’ll wait the PR for testing!
The security aspect is about including in RIOT the possibility to dynamically insert a set of encryption keys at run time through an external channel (I have a collegue working on NFC driver on RIOT).
Basically,the keys I want to exchange are those concering the 802.15.4 protocol,but we can use the same technique for RPL or CoAP.
Sounds very interesting! There is quite some demand for this inside (and outside) of our community. Regarding GSOC - do you have already a rough idea about an architecture and a high-level project plan on how you would like to structure this as a GSOC project? I encourage you to share this with us, so we can help you to improve it! Cheers, Hauke
The aim of the project is to avoid the use of hardcoded keys inside the firmware and add more flexibility in keys management.
So we need an API that performs the following tasks:
Wait for an input that just says “hey, install a new key”
i.e the NFC gateway detects an NFC device in his range or an UART device has been plug.
Check the security parameters.
i.e a device identifier, a timeout for reading the payload,the protocol to use…other parameters and finally the key
Create a database of all the informations received and guarantee that nobody steels them!
In case of 802.15.4, since the encryption is done by the hardware of the Xbee, the best solution consists of get rid of the key right after the key is set into the Xbee.
In case of RPL and CoAP the idea is to store the key in a secure storage or a volatile area so that a device tampering could lead to key deletion
Implement the functions that will set the security keys into the desired protocol/device
Finally at the end of the project we’ll test the encrypted communications of the nodes