**NOTE: I'm currently editing the project description for Hackaday Prize Final Submission, and things may appear badly organized until this is complete. This might take until the deadline of the 27th, so sorry about the fumbling around with all this**
Links to project details (GIT, Wiki, Docs) are on the left. The laziest introduction to this project is the 2-minuite video created for The Hackaday Prize quarterfinals (i.e. the first video I made):
A slightly longer introduction appeared as a 5-minuite video for the semifinals (i.e. the second video), see below:
The most commitment is reading this page! Well if you are still reading, strap yourself in...
What's This About?
Lots of people have tried to design secure systems, and alas there is lots of failures. But what if you did everything correct: no buffer overflows, no unsanitized inputs, no default passwords. Unfortunately this isn't good enough - even perfectly implemented encryption algorithms such as AES-256 will reveal encryption keys. It's not due to incorrect implementation, it's a fundamental artefact of their design.
This has been known for a long time - the first paper on this was published in 1998. But if you are an engineer or independent researcher tools to get started are expensive, or require you to do a lot of work yourself scripting together lower-cost tools. This project is my attempt to eliminate this problem.
I'm eliminating the problem for good by making my tools open source. Because this whole area is an active research area, the tools need to be open source. This isn't a case of attempting to seem sexy by adding the word 'open-source', but placing something of commercial value into the open-source domain, in the hope it spurns a larger community. Think of something like Wireshark - it's extremely valuable, and could easily be sold as a high-end product. But most of that value comes from it being open source, and hence containing a huge array of protocol dissectors, far beyond what a commercial vendor could support.
It's also worth stressing that there is no 'tricks' in the open-source nature of this project. It's not just part of the design that's open source, and I've already had people build these units from PCB design files (so I know they are complete!). Again the objective of this is project is to open up this area of research to a much wider audience. I'm hoping the commercial value I'm giving up (by allowing anyone to make these units, and not forcing them to buy them from me) is far outweighed by the community this project builds up.
It's useful to point out how critical this field of embedded security has become, and why it's interesting to see attacks against AES (which I tend to focus on in my demos). The 'Internet of Things' requires some wireless communication network - be it IEEE 802.15.4, ZigBee (which uses 802.15.4), or Bluetooth Low Energy. Since these are wireless protocols security is of paramount importance - and the designers acknowledge that. Attacks against AES are interesting because all three of the previous protocols use AES-128 for security. Unfortunately AES-128 isn't just a "check box" that indicates your system is secure, despite one document being bold enough to list that because Bluetooth low energy has 128 bit AES, it's "secure against attack and hacking" (see page 45). The idea that implementations are secure because the underlying algorithm is secure will cost somebody a lot of money when it blows up in their face, and they have to fix millions of already deployed devices.
Assuming designers aren't foolish enough to send encryption keys over SPI (see Travis Goodspeed with his example attacks), and have actually done the implementation correctly, and haven't introduced backdoors, we can still break the AES implementation. This isn't a theoretical attack, but a real-world attack that every embedded designer needs to understand. It's clear that very few embedded engineers are aware of this issue, based on how infrequently it is...Read more »