Schneier on A5/1 crack
Bruce Schneier has a good blog post on the latest A5/1 attack. http://www.schneier.com/blog/archives/2008/02/cryptanalysis_o_1.html -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
| Their key recovery technique gets a lot of mileage from using the | computed key schedule for each round of AES or DES to provide | redundant copies of the bits of the key. If the computer cleared | the key schedule storage, while keeping the key itself when the | system is in sleep mode, or when the screen-saver password mode | kicks in, this attack would be less possible. We've viewed "screen locked" and "sleep mode" (with forced screen lock on wake) as equivalent to "off". Clearly that's no longer a tenable position. Sensitive data in memory must be cleared or encrypted, with decryption requiring externally-entered information, whenever the screen is locked or sleep mode initiated. This would actually make them *safer* than the "off" state, since at least you know your software can gain control while entering those states! | If, in addition, the key was kept XORed with the secure hash of a | large block of random memory, as suggested in their countermeasures | section, their attacks would be considerably more difficult. | | These seem to be simple, low overhead countermeasures that provide | value for machines like laptops in transit. I suspect GPS chip sets will become a standard part of laptops in the future. One can imagine some interesting techniques based on them. Even now, most laptops have motion sensors (used to "safe" the disks), which could be used. I seem to recall some (IBM?) research in which you wore a ring with an RFID-like chip in it. Move away from your machine for more than some preset time and it locks. I'm sure we'll see many similar ideas come into use. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
| ...I imagine this will eventually have a big impact on the way organizations | respond to stolen mobile device incidents. With the current technology, if a | laptop or mobile device is on when it's stolen, companies will need to assume | that the data is gone, regardless of whether or not encryption products have | been deployed. | | Anyone familar with the laws in the arena? Are there regulations which require | reporting only if data on a stolen device is not encrypted? I believe something like this has been written into law. The reporting laws are all state laws, so of course vary. The Federal laws often have "safe harbor" provisions for encrypted data. Regardless of the law, the broad public perception is that "encrypted" means "safe". After one too many embarrasments, corporations (and governments) have learned that "Oh, yes, 150,000 credit card numbers were stolen but there's no evidence anyone is using them" no longer works as damage control; but "Oh, yes, 150,000 credit card numbers were stolen but that's OK - they were encrypted" works fine. (Note that these announcements don't even bother to discuss what the encryption mechanism might be - ROT13, anyone?) Unfortunately, the technical nature of these results - combined with the "We told you to encrypt everything to make it safe; now we tell you encryption isn't safe" nature of the debate, is unlikely to produce anything positive in the general public sphere. People will probably just shrug their shoulders, figure nothing can be done, and move on. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
So, is anyone else as amused as I am that Apple can release an EFI firmware update to zeroize MacBook Air memory at boot-time, turning the heretofore widely-decried inability to upgrade that laptop's RAM -- due to the chips being soldered to the motherboard -- into an advantage, and making the Air the laptop of choice for discriminating, fashion-aware, security-conscious professionals the world over? No. Apple (or anyone doing EFI boot, for example, someone doing WDE for OS X) can easily modify the EFI boot to zero memory. It isn't just the Air, it's any Intel Mac, but remember those are just Intel EFI systems. Note, however, that this does not completely solve the attack. If someone hits the reset button or yanks power, then you don't get to erase. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
On Feb 21, 2008, at 6:40 PM, Ali, Saqib wrote: i think in most cases tamper-resistant is sufficient Er, what do TPMs have to do with this at all? TPMs are not tamper- proof hardware FDE devices. They're somewhat tamper-proof (in practice, I wouldn't depend on it) non-volatile storage for small amounts of sensitive data, such as encryption keys. But as long as it's software that's driving your FD encryption, you need to have your keys in RAM. So, either: * The TPM is used in 'basic' mode, where its only purpose is to provide a measure of tamper-resistance to the boot path, and as long as no boot-time tampering is detected, the FDE key will be loaded into RAM automatically, or, * The TPM requires explicit authentication (e.g. by password or smart card) before releasing the key, in which case a successful authentication will load the FDE key in RAM. If the machine is running and the FDE in use -- which is the entire premise behind this attack -- both TPM use cases are just as vulnerable. TPMs are a red herring in this discussion, unless the FDE was actually offloading the crypto operations to it. This is not a supported mode of operation for any widely-deployed FDE system that I'm familiar with. So, is anyone else as amused as I am that Apple can release an EFI firmware update to zeroize MacBook Air memory at boot-time, turning the heretofore widely-decried inability to upgrade that laptop's RAM -- due to the chips being soldered to the motherboard -- into an advantage, and making the Air the laptop of choice for discriminating, fashion-aware, security-conscious professionals the world over? -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cold boot attacks on disk encryption
Jon Callas wrote: > > On Feb 21, 2008, at 12:14 PM, Ali, Saqib wrote: > >> However, the hardware based encryption solutions like (Seagate FDE) >> would easily deter this type of attacks, because in a Seagate FDE >> drive the decryption key never gets to the DRAM. The keys always >> remain in the Trusted ASIC on the drive. > > Umm, pardon my bluntness, but what do you think the FDE stores the key > in, if not DRAM? The encrypting device controller is a computer system > with a CPU and memory. I can easily imagine what you'd need to build to > do this to a disk drive. This attack works on anything that has RAM. > Actually, I hear that some companies store the keys on the platters of the disk. Again this is if they're actually using crypto and not just selling XOR'ed blocks of data. To project the keys, they limit standard read commands to not enter those areas of the disk. Of course the vendor provides a method to read those areas of disk, it's just a matter of finding them. Regards, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: USB drive manufacturer encrypts data with XOR
Rui Paulo <[EMAIL PROTECTED]> writes: >"The specifications of the 2.5in. Easy Nova Data Box PRO-25UE RFID hard drive >case by German vendor Drecom sound promising: hardware data encryption with >128-bit AES, access control via an RFID chip compact enough to carry around >on your key ring and optional 160GB or 250GB hard disk capacity. Swiping the >RFID chip along the case causes the integrated Innmax IM7206 crypto >controller to reveal the drive as a USB 2.0 mass storage compatible device to >the attached computer. This works under Linux and Mac OS X as well as Windows. The fault here isn't with Nova (or any of the other vendors that use the Innmax device), it's squarely with Innmax, whose advertising and data sheets imply that the disk is encrypted with AES without ever mentioning that it's only ever used in conjunction with the RFID portion. (By "imply" I mean the specs state "Uses AES encryption", technically you could argue that since they never specifically say "All disk data is encrypted using AES encryption" they'd be justified in storing it in plaintext, but that's not what someone looking at the spec will interpret it as). To make it even more confusing, "Easy Nova" is a near-namespace collision with eNova, who do AES-encrypt the disk contents (well, as far as anyone knows... anyone here have a eNova X-Wall drive controller and feel like seeing what's on the disk?). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Thierry Moreau <[EMAIL PROTECTED]> writes: >At first, it seems neat. But then, looking at how it works in practice: the >client receives an e-mail notification soliciting him to click on a HTML link >and then enroll for a security certificate, the client is solicited exactly >like a phishing criminal would do, Correction, "exactly like phishing criminals are actively doing right now" (hat tip to Don Jackson of SecureWorks who's investigated and documented this practice). Given the almost complete failure of client certs in the marketplace, I found it most amusing that the current active users of "client certs" are phishers. It reminded me of spammers and SPF. > Title: Sender driven certification enrollment system > Document Type and Number: United States Patent 6651166 > Link to this page: http://www.freepatentsonline.com/6651166.html > > Filing Date: 04/09/1998 > Publication Date: 11/18/2003 Thus postdating Microsoft's CertEnroll/Certenr3/Xenroll ActiveX control by several years. The only difference here is that the user generates the cert directly rather than involving a CA. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
