Kat and Xianzhi already know about
this article about Spyrus' Hydra Privacy Card, because they've both heard me gripe about it over the last couple of days.
The online version doesn't have the same title as the print version, which is a shame. "First Look" is much better than the whole "Like the Greek Hydra, the Hydra PC has many uses" bit. The print title doesn't even make any sense.
Next, the article lists the whole "designed for validation under FIPS 140-2" bit. Can't really blame the authors for this, as it's listed on the
Spyrus website and in the
Hydra PC data sheet. But, if you look at NIST's
Cryptographic Module Validation Program FAQ (.pdf format), you might notice the following:
Commonly used conformance claims
A vendor makes the following claims of conformance to FIPS 140-1 or FIPS 140-2. Are they
acceptable?
- The module has been designed for compliance to FIPS 140-2. no
- The module has been validated and has received Certificate #495.yes
Yes, I'm aware that Spyrus isn't the only company doing this, but NIST specifically mentions the claim as being unacceptable. One could blame the article for "Most important, however, Hydra can support storage of classified data under U.S. government standards." Hey, guys: NIST says that the whole "designed for validation" isn't valid.
The article also mentions that the Hydra PC is "a fully functional computer", which, as pointed out by Xianzhi this weekend, also applies to his wristwatch. While it might be true, it doesn't necessarily tell us what "fully functional" actually accomplishes.
The following passage is not very clear:
"Cryptographically, Hydra supports AES, ECC (Elliptic Curve Cryptography), SHA-2, SHA-512 and ECC-521. Default key lengths are ECC P-384, AES-256 and SHA-384."
Now, any of the parties that have had to put up with crypto ranting over the last few months should be able to pick out the two SHAs as hash algorithms. AES is a symmetric cipher. ECC uses asymmetric keys. Note that the Hydra also supports two- and three-key triple DES, ECDH and ECMQV key agreements, and ECDSA signatures.
Maybe I'm just very off here, but isn't it a bit odd to relate to key lengths with algorithms? Key lengths are usually defined as some number of bits, are they not? Would it not suffice to say that the Hydra PC defaults to 256 and 384 bit keys?
"When the PIN is set up, it is hashed and
the encryption key is derived from the hash. When the user enters a PIN, the process is reversed."
Now the way this reads, it means that when a user enters a PIN, the encryption key somehow gets unhashed. Which means there's a reversible hash function at play here, which just wouldn't be right. The article probably means that the user-entered PIN is submitted to a hash function, which outputs a value which is compared to the hash value stored on the Hydra. Note that the process doesn't get reversed, because cryptographic hash functions are ideally one-way.
It's the whole "what do we store and how" thing: user login/passwords shouldn't be stored in the database in plain text; we'll go and hash them (possibly with more than one hash) before adding the values to the database. Then, when a user logs in, we'll input the information provided by the user to the same sequence of hash functions, and compare the output to the stored values from the database. We aren't "reversing" anything. It's a comparison.
I'm not going to pick at the article more at this time, because I need to get some sleep.
