Wireless Encryption Between Galileo and a MSP430

[Mark] recently finished his latest project, where he encrypts wireless communications between the new Intel Galileo and a Texas Instruments MSP430. The wireless interfaces used are the very common nRF24L01+ 2.4GHz transceivers, that had a direct line of sight 15 feet range during [Mark]‘s tests. In his demonstration, the MSP430 sends an encrypted block of data representing the state of six of its pins configured as inputs. This message is then received by a sketch running on the Galileo and stored in shared memory. A python script then wakes up and is in charge of decrypting the message. The encryption is done using AES-128bits in Electronic Codebook mode (ECB) and semaphores are used to prevent simultaneous accesses to the received data. As it is the first project using an Intel Galileo we received, don’t hesitate to send us a tip if you found other ones.

11 thoughts on “Wireless Encryption Between Galileo and a MSP430

  1. I’m thinking shared a shared one time pad would be interesting to use instead, especially if you have an SD card, but the internal flash can store quite alot if you only need to send 6 bits.

    It would be interesting to get a crypto analysis of this hack, I mean he mentions several problem areas himself.

    1. I would agree with you one time pad is the only way to go these days to guarantee security. But how in hell do you “completely destroyed the pad after use”. If it is stored on flash then you would be just burning through the lifetime write cycles of the flash in no time at all. Distributing and then fully destroying the pad as it is used are always a difficult problem.

  2. I have to wonder why the 2.4ghz parts seem so interesting to people when they also make the nRF905? It has a lower data rate but a longer rang than the 2.4 parts

    1. ummm… cost?
      I didn’t do an exhaustive search, but it seems like it’s much easier to find very cheap nRF24L01+ modules.

  3. 1. No message integrity, can replay and tamper.
    2. Worst block cipher mode, messages are distinguishable.
    3. Top comment suggests switching to ECC out of the blue, makes wrong statement about benefit of ECC, and doesn’t take into account developer capabilities demonstrated.

    Remove the encryption. It complicates and bloats the code while providing no security.

    Focus on something else, like the neat use of IPC to integrate Python + MSP430 over wireless.

    1. I agree completely :) In hindsight I should have moved this sentence up into the introduction: “Granted, the point of this demo was not to demonstrate a complete security solution (that would require a key exchange protocol, better AES mode, etc).”

      To be honest, I added in the encryption at the last minute. I wanted the IPC demo to do something more interesting than to just have Python print exactly what it read from shared memory (since you could just do a system call from the sketch). So when I came across the PyCrypto library and a version of AES that would fit on the MSP430 I just went with it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s