Archive for the ‘Crypto’ Category

Wow, I’m still in shock about this. Believe it or not, the FIPS status of OpenSSL has been pulled by NIST. Sure enough, if you cruise on over to the NIST site and click right under the big red sign that says “revoked” for the cert, you get a page saying that there ain’t no cert.

Apparently, here’s what happened: some vendor (I still have yet to find a reference to which one) couldn’t take the competitive pressure in the marketplace and decided to complain to NIST – citing a technicality about which code is or isn’t interpreted to be inside OpenSSL’s “cryptographic boundary.” And now, OpenSSL needs to be heavily modified in order to get recertified.

My take? This is dirty pool. Why? First, any software product is going to be open to debate about which underlying libraries can or can’t be considered inside the software’s “cryptographic boundary.” Commercial products, however, are more difficult for competitors to reverse engineer in order to make a complaint like this one. I’d bet that a similar complaint could be lodged against any commercial product distributed as a binary image out there. Maybe a similar complaint could be made about CAPI. Who knows? But reverse engineering CAPI is hard (no source) so competitors don’t go there. Reverse engineering OpenSSL, on the other hand, is easy.

But what really fries my bacon is that this kind of action is detrimental to the user community – the users are left holding the bag. Users of the product in the federal government, suddenly finding themselves using a non-validated product (and now out of compliance with FISMA), are left scrambling to find a way to meet their accredidation requirements – all at healthy taxpayer exense. I think it’s reprehensible that a vendor would look to get ahead at the expense of users – healthy competition is fine, but making the users pay for your own failings isn’t.

Just my two cents.

Last week, the “Energy and Commerce” Committee of the US House of Representatives approved HR 4127, the “Data Accountability and Trust Act”. In case you haven’t heard of it, this bill basically does what SB1386 did, but at the federal level rather than at the state level – unless, of course, the data is encrypted. So what does that mean? According to the bill:

ENCRYPTION- The term `encryption’ means the protection of data in electronic form in storage or in transit using an encryption algorithm implemented within a validated cryptographic module that has been approved by the National Institute of Standards and Technology or another comparable standards body recognized by the Commission, rendering such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data. Such encryption must include appropriate management and safeguards of such keys to protect the integrity of the encryption.

Now, that’s interesting. I’m reading the line about to “validated cryptographic module… approved by [NIST]…” to mean FIPS 140-2. In the past, I’ve been hard on FIPS 140 since I think that in some cases a certification requirement can trump common sense. SB-1386 does not specify what, exactly, “encrypted” means, saying disclosure is required only when “…whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person…” The issue, of course, being that “encrypted” (or “unencrypted” for that matter) can mean different things to different people. Somebody could use EFS under Windows 2000, adding absolutely no security to the data on the machine, but yet claim “safe harbor” under 1386. Not so in this new bill. So, kudos to the House for stepping up to the plate and actually putting in some safeguards to make sure that this provision means something.

Of course, given the fact that not a day week goes by where we don’t have some new disclosure about stolen PII, I’m not sure that we’re going to see anyone using this new and harder to meet safeharbor requirement. But that’s another matter.

You know when you’re expecting something, and you know it’s going to be really cool – but it seems so far away that you think that it will never happen? Well, that was the case for me with OpenSSL’s FIPS 140-2 certification. It’s been a long time coming, but it’s finally here. The cert is in place, opening up a world of opportunity for engineers working in the federal space.

Good news for the security community, but probably bad news for us since it slightly outdates the FIPS “selecting a library” portion of our book.

Wow – this is disconcerting. Apparently, using an encryption program is evidence enough that you are up to something shady. A judge deciding that encrypted files (privacy of my data) directly supports evidence of criminal activity basically translates to the determination by the legal system that “only criminals need privacy.” I’m concerned not only because of the implications in the digital world, but the implications in the physical one – think for a moment what the ramifications of “only criminals need privacy” would be in a physical context… Scary, right?

Aritcle about the “state of affairs” in quantum cryptography. While almost completely content-free, the conclusion of this article where Martin Illsley says, “[Quantum cryptography] still needs biometric proof” did sufficiently raise my hackles enough to comment.

Will someone please explain to me how quantum cryptography and biometrics are related? I’m just not seeing it… Unless the photons in question are bouncing off my fingerprint, iris, or retina, I would contend that the two technlogies are completely unrelated…

In addition to being unrelated, I keep going on record, having worked for a biometrics company at one point, that biometrics are in some cases worse than a password or token. Just ask the poor guy who lost his finger for his beamer a few weeks back.

Simmonds, head of security for “pharmaceutical giant ICI” called for more email encryption” because “it’s built into every email product.” There are no silver bullets. For example, Mr. Simmonds may be well versed in the phamaceutical space, but apparently isn’t versed in current SEC regulations which require email archives for 7 years. The ability to archive isn’t built into every browser, bringing a world of compliance pain and suffering for folks in FS listening to this advice. Bottom line: be careful who you listen to, know what’s right for your company, and understand that there’s rarely a panacea or a free lunch…

NW Fusion has an article up titled “SSL-based VPNs are superior.” The conclusion by the arguably biased author, Chris Hopen, CTO of Aventail an SSL VPN provider, is yes. But it all depends on one’s definition of superior and particularly on a corporation’s business needs.

For ‘anywhere’ access that doesn’t require software, other than a browser, on the client-side, SSL VPNs are definitely a fantastic option. But for companies that aren’t able to feed all their remote access needs through a browser presenation layer, SSL VPNs can be restrictive.

For a more in-depth look at this issue check out this month’s Information Security Magazine cover feature VPNs: Tunnel Visions, by Lisa Phifer.

And don’t forget, the definition of superior directly relates to how well a technology meets your business needs.

Ellen Messmer takes a practical look at why AES (Advanced Encryption Standard) hasn’t deployed more quickly.

Short and sweet run down on what to think about before selecting a VPN solution for your company’s remote access.

One of the biggest considerations with IPSec is that client software is required. SSL VPNs traditonally use the browser as a client. While this increases mobility (any terminal with a browser will work), it requires data and applications to come through the browser presenation layer. The referenced NWFusion article states that file sharing isn’t native to most SSL VPNs, which is true, but there are products, such as Citrix Metaframe that enable file and disk sharing support, as well as access to legacy applications through a browser portal which can make the SSL option more useful for enterprises.

“Cisco Systems Inc. on Monday will launch a series of new and enhanced security management and virtual private network offerings.

Among the new offerings is the Cisco IP Solutions Center V 3.0, which allows users to set up common configurations for multiple VPN devices from a central location and push those out to remote sites. The tool also allows the VPN tunnels to be pushed out from a central location to remote locations, according to early user Carol Henson, director of IT for the U.S. Department of Agriculture, Rural Development, in St. Louis.”

It’s about time Cisco started offering this kind of remote control for VPN deployment.