We've discussed why you don't fix IVs for AES-CBC. We've touched on the limitations of only using symmetric keys in your application. We've even covered the challenges of protecting symmetric keys. But one sin we have not discussed is fixing your keys. And here's why: it is so obvious you shouldn't do this that nobody would ever do that. Right?
Unfortunately, while analyzing an IoT device, I saw this shocking case. These guys are heavy users of polarSSL/mbedTLS's AES routines. This makes it easy to pick apart where the app moves around the IV and key. That led me to these two horrors, side-by-side:
I actually forced myself to review my analysis results one more time before I could accept it. This application definitely, for some period of time, uses a fixed-per-application AES key. The information is now free...
But it didn't stop there. Armed with a PCAP and this new information, I set to work. Some messages, for the device discussed before, did not decrypt using the device key we stole. To jog your memory, the key we pulled from the SQLite3 database was:
F2F167202865DE0F5FD8547F954BCB6EThat we had some messages we couldn't deal with was perplexing, but I left it on the back burner. Armed with this new knowledge, I picked out one of the two messages that didn't decrypt with the device key. Using the above key (with the same IV):
This is some form of registration request from the controller, if I had to guess. The SM-T113 is the model number of my Samsung throwaway tablet. So let's apply this analysis to the response from the device:
Holy shit. Is that... that can't be... yes it is... our device's key.
Sometimes, when analyzing a device or a system, you need to suspend disbelief. The disassembly doesn't lie: but sometimes the analyst can trick themselves. I couldn't believe this when I saw it - it is just so wrong.
You should never fix your key. If you're lucky, people like me will steal it and post it on their blog. If you're unlucky, you become the vector for something that could be a PR nightmare.
But it Gets Worse
Remember those slick demos using 802.11 frame sizes as a way to covertly exfiltrate data? By modulating a message by varying frame sizes, and repeating the message enough times, it will get out to a passive listener. This was a pretty cool hack, and is something companies should keep an eye out for.
And this is not something a responsible engineer would use for a production device. This is not a way to provision a device with an SSID and WPA key. Even if you think you're being clever (looking right at you, TI's CC3000 team), you're not. Here's why: you're sending out the keys to the castle. There's no way to negotiate a one-time key. This is an unreliable channel: too unreliable for a large message. So you have to keep the message simple. This means most implementations will use a fixed AES key (see above for why this is bad). Or, in this case, they don't even bother with a key: they just send the SSID and WPA2-PSK key unencrypted.
This means any passive listener can watch for the right traffic patterns. These are the same patterns sought by the device(s) you're provisioning. All devices from this vendor use the same pattern. A cheap USB 802.11 dongle in monitor mode is all you need to pick this up.
The Inevitable Conclusion
And sometimes, dear vendor, you need to hire a consultant. If you recognize the key and IV above, please get in touch with me. You need help.
An Update (8/23/2016)
If you Google for the IV, it shows up everywhere. The vendor used the CAVP IVs for AES CBC. Even more secure to use a well-known IV, right?