Entries Tagged "AES"

Page 3 of 3

Seagate Encrypted Drive

Seagate has announced a product called DriveTrust, which provides hardware-based encryption on the drive itself. The technology is proprietary, but they use standard algorithms: AES and triple-DES, RSA, and SHA-1. Details on the key management are sketchy, but the system requires a pre-boot password and/or combination of biometrics to access the disk. And Seagate is working on some sort of enterprise-wide key management system to make it easier to deploy the technology company-wide.

The first target market is laptop computers. No computer manufacturer has announced support for DriveTrust yet.

More details in these articles.

Posted on November 7, 2006 at 7:04 AMView Comments

Microsoft's BitLocker

BitLocker Drive Encryption is a new security feature in Windows Vista, designed to work with the Trusted Platform Module (TPM). Basically, it encrypts the C drive with a computer-generated key. In its basic mode, an attacker can still access the data on the drive by guessing the user’s password, but would not be able to get at the drive by booting the disk up using another operating system, or removing the drive and attaching it to another computer.

There are several modes for BitLocker. In the simplest mode, the TPM stores the key and the whole thing happens completely invisibly. The user does nothing differently, and notices nothing different.

The BitLocker key can also be stored on a USB drive. Here, the user has to insert the USB drive into the computer during boot. Then there’s a mode that uses a key stored in the TPM and a key stored on a USB drive. And finally, there’s a mode that uses a key stored in the TPM and a four-digit PIN that the user types into the computer. This happens early in the boot process, when there’s still ASCII text on the screen.

Note that if you configure BitLocker with a USB key or a PIN, password guessing doesn’t work. BitLocker doesn’t even let you get to a password screen to try.

For most people, basic mode is the best. People will keep their USB key in their computer bag with their laptop, so it won’t add much security. But if you can force users to attach it to their keychains — remember that you only need the key to boot the computer, not to operate the computer — and convince them to go through the trouble of sticking it in their computer every time they boot, then you’ll get a higher level of security.

There is a recovery key: optional but strongly encouraged. It is automatically generated by BitLocker, and it can be sent to some administrator or printed out and stored in some secure location. There are ways for an administrator to set group policy settings mandating this key.

There aren’t any back doors for the police, though.

You can get BitLocker to work in systems without a TPM, but it’s kludgy. You can only configure it for a USB key. And it only will work on some hardware: because BItLocker starts running before any device drivers are loaded, the BIOS must recognize USB drives in order for BitLocker to work.

Encryption particulars: The default data encryption algorithm is AES-128-CBC with an additional diffuser. The diffuser is designed to protect against ciphertext-manipulation attacks, and is independently keyed from AES-CBC so that it cannot damage the security you get from AES-CBC. Administrators can select the disk encryption algorithm through group policy. Choices are 128-bit AES-CBC plus the diffuser, 256-bit AES-CBC plus the diffuser, 128-bit AES-CBC, and 256-bit AES-CBC. (My advice: stick with the default.) The key management system uses 256-bit keys wherever possible. The only place where a 128-bit key limit is hard-coded is the recovery key, which is 48 digits (including checksums). It’s shorter because it has to be typed in manually; typing in 96 digits will piss off a lot of people — even if it is only for data recovery.

So, does this destroy dual-boot systems? Not really. If you have Vista running, then set up a dual boot system, Bitlocker will consider this sort of change to be an attack and refuse to run. But then you can use the recovery key to boot into Windows, then tell BitLocker to take the current configuration — with the dual boot code — as correct. After that, your dual boot system will work just fine, or so I’ve been told. You still won’t be able to share any files on your C drive between operating systems, but you will be able to share files on any other drive.

The problem is that it’s impossible to distinguish between a legitimate dual boot system and an attacker trying to use another OS — whether Linux or another instance of Vista — to get at the volume.

BitLocker is not a panacea. But it does mitigate a specific but significant risk: the risk of attackers getting at data on drives directly. It allows people to throw away or sell old drives without worry. It allows people to stop worrying about their drives getting lost or stolen. It stops a particular attack against data.

Right now BitLocker is only in the Ultimate and Enterprise editions of Vista. It’s a feature that is turned off by default. It is also Microsoft’s first TPM application. Presumably it will be enhanced in the future: allowing the encryption of other drives would be a good next step, for example.

EDITED TO ADD (5/3): BitLocker is not a DRM system. However, it is straightforward to turn it into a DRM system. Simply give programs the ability to require that files be stored only on BitLocker-enabled drives, and then only be transferrable to other BitLocker-enabled drives. How easy this would be to implement, and how hard it would be to subvert, depends on the details of the system.

Posted on May 2, 2006 at 6:54 AMView Comments

NIST Hash Workshop Liveblogging (3)

I continue to be impressed by the turnout at this workshop. There are lots of people here whom I haven’t seen in a long time. It’s like a cryptographers’ family reunion.

The afternoon was devoted to cryptanalysis papers. Nothing earth-shattering; a lot of stuff that’s real interesting to me and not very exciting to summarize.

The list of papers is here. NIST promises to put the actual papers online, but they make no promises as to when.

Right now there is a panel discussing how secure SHA-256 is. “How likely is SHA-256 to resist attack for the next ten years?” Some think it will be secure for that long, others think it will fall in five years or so. One person pointed out that if SHA-256 lasts ten years, it will be a world record for a hash function. The consensus is that any new hash function needs to last twenty years, though. It really seems unlikely that any hash function will last that long.

But the real issue is whether there will be any practical attacks. No one knows. Certainly there will be new cryptanalytic techniques developed, especially now that hash functions are a newly hot area for research. But will SHA-256 ever have an attack that’s faster than 280?

Everyone thinks that SHA-1 with 160 rounds is a safer choice than SHA-256 truncated to 160 bits. The devil you know, I guess.

Niels Ferguson, in a comment from the floor, strongly suggested that NIST publish whatever analysis on SHA-256 it has. Since this is most likely by the NSA and classified, it would be a big deal. But I agree that it’s essential for us to fully evaluate the hash function.

Tom Berson, in another comment, suggested that NIST not migrate to a single hash function, but certify multiple alternatives. This has the interesting side effect of forcing the algorithm agility issue. (We had this same debate regarding AES. Negatives are: 1) you’re likely to have a system that is as strong as the weakest choice, and 2) industry will hate it.)

If there’s a moral out of the first day of this workshop, it’s that algorithm agility is an essential feature in any Internet protocol.

Posted on October 31, 2005 at 4:00 PMView Comments

Seagate's Full Disk Encryption

Seagate has introduced a hard drive with full-disk encryption.

The 2.5-inch drive offers full encryption of all data directly on the drive through a software key that resides on a portion of the disk nobody but the user can access. Every piece of data that crosses the interface encrypted without any intervention by the user, said Brian Dexheimer, executive vice president for global sales and marketing at the Scotts Valley, Calif.-based company.

Here’s the press release, and here’s the product spec sheet. Ignore the “TDEA 192” nonsense. It’s a typo; the product uses triple-DES, and the follow-on product will use AES.

Posted on June 27, 2005 at 7:24 AMView Comments

AES Timing Attack

Nice timing attack against AES.

For those of you who don’t know, timing attacks are an example of side-channel cryptanalysis: cryptanalysis using additional information about the inner workings of the cryptographic algorithm. I wrote about them here.

What’s the big idea here?

There are two ways to look at a cryptographic primitive: block cipher, digital signature function, whatever. The first is as a chunk of math. The second is a physical (or software) implementation of that math.

Traditionally, cryptanalysis has been directed solely against the math. Differential and linear cryptanalysis are good examples of this: high-powered mathematical tools that can be used to break different block ciphers.

On the other hand, timing attacks, power analysis, and fault analysis all makes assumptions about implementation, and uses additional information garnered from attacking those implementations. Failure analysis assumes a one-bit feedback from the implementation — was the message successfully decrypted — in order to break the underlying cryptographic primitive. Timing attacks assumes that an attacker knows how long a particular encryption operation takes.

Posted on May 17, 2005 at 10:05 AMView Comments

Letter: Lexar JumpDrives

Recently I talked about a security vulnerability in Lexar’s JumpDrives. I received this e-mail from the company:

From: Diane Carlini

Subject: Lexar’s JumpDrive

@stake’s findings revealed a slight security exposure in scenarios where an experienced hacker could potentially monitor and gain access to the secure area. This was only the case in version 1.0 which included SafeGuard. Lexar’s JumpDrive Secure 2.0 device now includes software based on 256-bit AES Encryption Technology. With this new product, JumpDrive Secure 2.0 offers the highest level of data protection that is commonly available today.

Registered JumpDrive Secure customers will be contacted to inform them of this Security Advisory found in version 1.

I have no technical information, either from Lexar or @Stake, that verifies or refutes this claim.

Posted on November 5, 2004 at 9:53 AMView Comments

Letter: Lexar JumpDrives

Recently I talked about a security vulnerability in Lexar’s JumpDrives. I received this e-mail from the company:

From: Diane Carlini

Subject: Lexar’s JumpDrive

@stake’s findings revealed a slight security exposure in scenarios where an experienced hacker could potentially monitor and gain access to the secure area. This was only the case in version 1.0 which included SafeGuard. Lexar’s JumpDrive Secure 2.0 device now includes software based on 256-bit AES Encryption Technology. With this new product, JumpDrive Secure 2.0 offers the highest level of data protection that is commonly available today.

Registered JumpDrive Secure customers will be contacted to inform them of this Security Advisory found in version 1.

I have no technical information, either from Lexar or @Stake, that verifies or refutes this claim.

Posted on November 5, 2004 at 9:53 AMView Comments

The Doghouse: Lexar JumpDrives

If you read Lexar’s documentation, their JumpDrive Secure product is secure. “If lost or stolen, you can rest assured that what you’ve saved there remains there with 256-bit AES encryption.” Sounds good, but security professionals are an untrusting sort. @Stake decided to check. They found that “the password can be observed in memory or read directly from the device, without evidence of tampering.” Even worse: the password “is stored in an XOR encrypted form and can be read directly from the device without any authentication.”

The moral of the story: don’t trust magic security words like “256-bit AES.” The devil is in the details, and it’s easy to screw up security.

Although screwing it up this badly is impressive.

Lexar’s product

@Stake’s analysis

Posted on October 1, 2004 at 9:45 PM

The Doghouse: Lexar JumpDrives

If you read Lexar’s documentation, their JumpDrive Secure product is secure. “If lost or stolen, you can rest assured that what you’ve saved there remains there with 256-bit AES encryption.” Sounds good, but security professionals are an untrusting sort. @Stake decided to check. They found that “the password can be observed in memory or read directly from the device, without evidence of tampering.” Even worse: the password “is stored in an XOR encrypted form and can be read directly from the device without any authentication.”

The moral of the story: don’t trust magic security words like “256-bit AES.” The devil is in the details, and it’s easy to screw up security.

Although screwing it up this badly is impressive.

Lexar’s product

@Stake’s analysis

Posted on October 1, 2004 at 9:45 PM

Sidebar photo of Bruce Schneier by Joe MacInnis.