Binary Blob Apocalypse – Firmware + Cryptography = less Security
A couple of years ago we had a chat with one of our sponsors, Attingo. They are specialised in data recovery from all kinds of media and in all kinds of conditions. Since vendors keep secrets from the rest of the world, the data rescuers do a lot of reverse engineering in order to decode the mysteries of firmware blobs. Guess what they recommend: Don’t trust important tasks to firmware code! It’s the worst software written on this planet. If software gets something wrong, firmware is the best candidate for big SNAFUs. Solid state disks (SSDs) have recently joined the gallery of failures.
Carlo Meijer and Bernard van Gastel have published an article titled Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs). They analysed the implementation of hardware full-disk encryption of several SSDs. What they found is no surprise to the connaissuers of firmware. The code has critical weaknesses that allow the extraction of „protected“ data even without knowledge of the key(s). The actual secret key is not derived from tge chosen password for the device. What’s worse is the use of Bitlocker on top of these SSDs. If the storage hardware advertises encryption capabilities, then Bitlocker will happily delegate these tasks to the hardware/firmware and do nothing of its own. The standard Opal from the Trust Computing Group doesn’t help, because it is not correctly implemented in the storage media.
So short of implementing your own crypto, do not rely on a single layer of protection. If you delegate all the solutions of your problems to a binary firmware blog, then you are lost. Apart from the fact that firmware is usually never updated, it may contains more bugs and design flaws than anything piled on top. Use an extra layer of crypto such as LUKS or VeryCrypt. Better safe than $INSERT_FAVOURITE_VENDOR_TECHNOLOGY_HERE.