All in Crypto Disasters
IoT and computer security fears are at the forefront of the news cycle. Foreign hackers, malfeasants from America or government-sponsored entities are hacking your home...
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.
Public Key Cryptography simplifies authentication. We can use a public key to authenticate firmware updates signed with the private key. Everything seems pretty clear at this point. But we need to keep our keys secure! How can we approach that...
So we stole the keys to the castle, now what? Let's look at how we can take the key and IV we've extracted for our device to decrypt the payloads. Then we can start reverse engineering the communication protocol used by the device.
IoT devices are resource constrained. Oftentimes vendors will go to great lengths to avoid using TCP. This is not a bad decision on its own: UDP is stateless. But that means you're rolling your own resiliency in.
We now know that a naive, hash-based approach has trivial weaknesses. HMAC on its own prevents image modification. But it's likely easy to steal the key for either scheme. If all devices use the same key, forging a compromised firmware image is easy. So what are our options?
Nothing will leave your product more vulnerable than a badly designed firmware update process.
If there's one thing that is often screwed up, in all systems, it's cryptography.