Limmat unveiled at Embedded World

NETMF & Gadgeteer
1

For anyone interested in our NETMF flagship board, here a page with the slides of the talk about the Limmat platform that I gave today at [em]Embedded World[/em] in Nürnberg:

http://www.limmat.co/2015/02/26/limmat-unveiled-at-embedded-world-in-nürnberg/

For those interested in more details: please register on the Limmat mailing list, then you’ll get access to the 10 page technical companion paper, which mentions NETMF:

Only a small number of Limmat reference boards is available, for prospective licensees of the platform, so it is not intended for makers (and is rather expensive to produce in small volumes). Still, I think it may be interesting as an example of what can be done with NETMF as platform. Of course, we have used our [em]NETMF for STM32[/em] port, which is also the basis for GHI Cerb* firmware, the Netduino 2 firmware, our Mountaineer board firmware, the MikroBus.NET board firmware, and Justin’s super cool creations.

Cuno

PS
And no, the picture was not taken during my talk, but 20 minutes earlier :naughty:

11 Likes
2

@ Cuno - Congrats. While I’m bummed that it’s not a device marketed at makers, hopefully it’ll still benefit the broad NETMF community as a whole.

BTW - I’d love to see some info on your approach to securing things on both the BLE and HTTP side. One of my biggest worries when it comes to IoT gateways is whether they’re secure by default. Way too many IoT products targeted at consumers seem to treat security as an afterthought, if they’ve thought of it at all.

3

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:
http://www.mountaineer.org/resources/tidbits/using-the-nacl-crypto-library/

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:
http://www.mountaineer.org/resources/tidbits/using-in-field-updates/

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:
http://blogs.msdn.com/b/clemensv/archive/2014/02/10/service-assisted-communication-for-connected-devices.aspx

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…

Cuno

PS
Did I mention that managed code and a code base smaller than Linux is good for endpoint security :smiley:

1 Like
4

PS
I’ve mentioned BMW as an example of this in my talk. They put the same secret keys in all their cars. When you break one, you’ve broken them all. And someone did. Bad publicity…
http://www.scmagazineuk.com/bmw-connecteddrive-flaw-exposes-2-million-cars-to-remote-unlocking/article/396868/

5

Ouch! Betting that gave someone a VERY bad day.

6

@ Cuno - Had to blog about that article…too good to pass up. And if it draws a little more attention to Limmat, so much the better. :slight_smile:

3 Likes
7

Congrats, Cuno. Any chance the presentation was video recorded?

8

Yeah: really a great, great work!

9

@ Cuno, thanks for sharing :dance:

10

I would really like to see a Gadgeteer module with LISA-U200 onboard.
@ Cuno - Does LISA-U200 need many external components to operate?

11

I don’t think it was recorded.

12

Seeing it is no problem at all. It is the module to the left of the Mountaineer USB Mainboard in the attached picture.

We used this 3G module, and our BLE module, to create an early prototype of Limmat.

13

@ Cuno - Do you have any plans on selling it as a standalone Gadgeteer module?

Apart from u.fl connector, which I think is not prototyping friendly, it looks to be a very nice module indeed.

14

I don’t know whether changing the connector would lead to major layout changes or not. On Limmat, we’ve used another connector.

We currently have two layout versions, one for battery power and one for a 5 V supply. Combining the two would have required a larger PCB or more layers.

The module supports a nested layout, so you can either use the larger LISA modules (6 bands) or the smaller SARA modules (4 bands), with the same PCBs.

If anyone wants to produce such a board, they can contact me. We could provide the Gerber files. However, they’d have to write their own driver. We have one of course, but limited to our needs and it has dependencies on an internal Oberon framework, and no Gadgeteer support.

15

[quote=“Cuno”]
If anyone wants to produce such a board, they can contact me.[/quote]
PS
Engineering samples of the u-blox modules are rather expensive.