Back in 2012, the LIFX light bulb launched on Kickstarter, and was quite successful. This wireless LED lightbulb uses a combination of WiFi and 6LoWPAN to create a network of lightbulbs within your house. Context Information Security took a look into these devices, and found some security issues.
The LIFX system has a master bulb. This is the only bulb which connects to WiFi, and it sends all commands out to the remaining bulbs over 6LoWPAN. To keep the network up, any bulb can become a master if required. This means the WiFi credentials need to be shared between all the bulbs.
Looking into the protocol, an encrypted binary blob containing WiFi credentials was found. This binary could easily be recovered using an AVR Raven evaluation kit, but was not readable since it was encrypted.
After cracking a bulb apart, they found JTAG headers on the main board. A BusBlaster and OpenOCD were used to communicate with the chip. This allowed the firmware to be dumped.
Using IDA Pro, they determined that AES was being used to encrypt the WiFi credentials. With a bit more work, the key and initialization vector was extracted. With this information, WiFi credentials sent over the air could be decrypted.
The good news is that LIFX fixed this issue. Now they generate an encryption key based on WiFi credentials, preventing a globally unique key from being used.
Since the Hackaday community started working on our offline password keeper, Mooltipass, we’ve received several similar projects in our tips line. The Final Key may be the most professional looking one yet. Similarly to the Mooltipass, it is based on an Atmel ATMega32U4 but only includes one button and one LED, all enclosed in a 3D printed case.
The Final Key is connected to the host computer via USB and is enumerated as a composite Communication Device / HID Keyboard, requiring windows-based devices to install drivers. AES-256 encrypted passwords are stored on the device and can only be accessed once the button has been pressed and the correct 256 bit password has been presented through the command line interface. Credentials management and access is also done through the latter. Unfortunately, the Arduino source code can’t be found on [cyberstalker]’s website, so if you see interesting features that you would like to be integrated in Mooltipass you may send us a message to our Google Group.
[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.
[Travis Goodspeed] posted a preview of what he’s working on for this Summer’s conferences. Last weekend he gave a quick demo of sniffing AES128 keys on Zigbee hardware at SOURCE Boston. The CC2420 radio module is used in many Zigbee/802.15.4 sensor networks and the keys have to be transferred over an SPI bus to the module. [Travis] used two syringe probes to monitor the clock line and the data on a TelosB mote, which uses the CC2420. Now that he has the capture, he’s planning on creating a script to automate finding the key.
[Rodney Thayer] gave a 2 hour seminar on cryptographic technology. It was designed to give the audience a working knowledge for dealing with vendors. He gave some rules of thumb for choosing encryption. In order of preference, when doing symmetric key crypto: use AES with a minimum 128bit key, if not that 3-key Triple-DES, or last RC4 with 128bit key. For hashing: SHA 256 preferred, SHA 1 if you can’t do any better, and MD5 if you can’t SHA. For public key: RSA using at least a 2048bit key. The top choices in these lists were picked because they’ve stood up to years of scrutiny. One major theme of talk was to never roll your own crypto algorithm or buy someone elses. Proprietary algorithms get broken all the time, like the GSM A5 crypto we talked about earlier this year.