Please send me your email address, then I’ll mail you the companion paper. Or register on the Limmat mailing list at www.limmat.co :whistle: There’s a bit of info about our security approach in there.
There exists a standard security mechanism for BLE, using AES128, which is ok, at least for now. In the original specification, the Bluetooth SIG naively used their own homegrown key exchange mechanism which - surprise surprise - was easily broken. With the 4.2 spec, they now use standard Diffie Hellman.
An alternative to the BLE standard would be to join the Apple HomeKit garden on top of BLE. Apple defined its own security protocol (HomeKit Accessory Protocol). End-to-end security with mutual authentication and perfect forward secrecy (you can find some info on the Web from a WWDC presentation).
We simply love Apple’s choice of crypto algorithms: elliptic curves by Dan Bernstein. Hm, did I mention that we ported such algorithms and integrated them into NETMF some time ago, and even have highly optimized versions for various Cortex-M cores, with their critical parts written in assembly language? Now imagine if we also had an implementation of Apple’s protocol that used these algorithms :think:
For remote Limmat firmware updates, we use MFUpdate with encrypted and signed firmware images, deployed via Azure (probably will become a topic for some future blog post on the Limmat site). Here our starting point for that:
As for TLS, we have integrated PolarSSL (now called mbed TLS). On-chip RAM of the MCU is sufficient - this is no OpenSSL junk!
Then we are fans of the approach that Clemens Vasters (Azure ServiceBus) calls service-assisted communication:
Incoming ports be banned for edge devices!
Oufff, it was a hyperbusy day in Nürnberg. Now that I’m back in Zürich I have to stop and go to sleep…
Did I mention that managed code and a code base smaller than Linux is good for endpoint security