UPDATE: also see my teardown of the CipherUSB

The illusion of security

Recently, I bought some Addonics CipherUSB devices. Their claim is that it provides NIST-certified AES-256 encryption.

It is based off a chip by a company called eNOVA.

I have no reason to doubt the claimed AES-256 encryption implementation contained in the chip is NIST-certified, but there are intermediate steps in their implementation that are cloaked in secrecy.

That is really scary and seriously erodes the security for the end user.

To load an AES-256 key into the device, a user has to employ a provided (Windows-only) password utility. This software accepts a text password (up to 32 characters), and then uses some mystery key derivation algorithm to determine the AES-256 key that gets programmed into the device.

The trouble is this: why should anyone blindly trust the password utility?

In order for a user to get the security benefit of AES-256, the key derivation algorithm must produce as much entropy as possible in the resultant AES key.

Because it is a mystery algorithm, there could be a deliberate or accidental backdoor. If the algorithm is poor, effectively producing a much smaller key, it might not really be secure at all. You think that you are getting a 256-bit key, but you might effectively be getting a far smaller key.

For those readers who perhaps don't see the gravity of this, perhaps an example is needed. Say you are playing a guessing game where you ask someone to pick a number from, say, 1 to 100. If you can stack the deck by ensuring that this person only chooses values that are multiples of 20 (20, 40, 60, 80, 100) for example, you've changed the difficultly of guessing the number from 1 in 100 to 1 in 5. The security in having a 256-bit key is based on each of the keys being equally likely; if this is not the case, security is much weakened even though the key is "256-bit".

I'm tempted to quote some of (outrageous) things Addonics tech support had to say, but I'm not sure it would help things. Let's just summarize with: "We see no reason that you have to know any more detail in the design of this product".

I think my suggestion that the password utility provide a mechanism to let the user load an AES 256-bit key directly was a good one. It means they don't have to disclose their mystery algorithm, but users don't have to blindly trust it if they don't want to.

*IF* they did this, it would then be possible to independently verify that the provided AES key is indeed downloaded by irreparably breaking open the device and reading the serial PROM. One could also verify it non-destructively by checking the cipher text written to the hard drive. (Note: their more expensive CBC model uses an undocumented IV to salt/initialize the AES engine, so it may only be possible verify their cheaper (perhaps less secure) ECB model.)

So, claiming security is one thing; actually delivering is quite another.


back to main page contact