Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Jan 18, 2007, at 6:57 PM, Saqib Ali wrote: When is the last time you checked the code for the open source app that you "use", to make sure that it is written properly? 30 seconds ago. What mode is it using? How much information is encrypted under a single key. Was the implementation FIPS certified. And the list goes on. These are important issues. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Jan 19, 2007, at 4:06 AM, Bill Stewart wrote: [...] if you're trying to protect against KGB-skilled attacks [...] On the other hand, if you're trying to protect against lower-skilled attackers, [...] I always find these arguments particularly frustrating. By slowly raising the bar for the lower-skilled criminals, you get the effect in Steven's firewall book cover (I forget the version, where you must be a certain height to attack the castle.) For me, the bottom line is that if you protect against the former, then you get the latter, and it is only a small matter of time when the lower-skilled people will get a script to do the higher quality attacks. Remember WEP? I really have to question continuing a snail's pace information protection arms war when we have all the tools we need to properly defend ourselves. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote: > Victor Duchovni <[EMAIL PROTECTED]> writes: > > >It took reading the code to determine the following: > > > >- ASN.1 Strings extracted from X.509v3 certs are not validated for > >conformance with the declared character syntax. Strings of type > >PrintableString or IA5String may hold non-printable or non-ASCII > >data. > > Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning > behind this. I don't think any ASN.1-using security toolkit since TIPEM has > done character-set checking, it would fail to verify a large chunk of the > certs out there (I once had a TIPEM user complain to me that they had to stop > using it specifically because it would reject invalid character strings, which > encompassed a nontrivial portion of their user base). I understand the motivation, and agree that this is the right thing to do, indeed in the application (Postfix) I just map the content to UTF8 (using the identity mapping where appropriate) and then decide what characters are acceptable, I don't need the original ASN.1 string type after the string is in canonical form. My point was that not all the fine details are always documented (even in closed source libraries with funded documentation teams), and having the source allows me to move beyond cargo-cult programming and to understand how to use the library correctly. I guess this is RTFS to extract the semantics out of the syntax documentation. In addition, I think that the library should-provide idiot-friendly interfaces for handling ASN.1 string data holding security sensitive information (CommonName, subjectAltName, ...), because the code one finds and copies from other projects is not sufficiently careful. RFC 3820 suggests that it is OK to consider strings of different ASN.1 types as different content for comparison and then, by implication, just compare the raw content when the types match, but what one finds is that applications mostly IGNORE the ASN.1 string type and use the raw octets for comparison, display, ... and they do that at their peril. It is also almost universal practice (in C code anyway) to not check for embedded NUL in the ASN.1 strings, and I wonder how may CAs would issue "eve.biz" a cert for "alice.com\0..eve.biz"? (If the CA's code handles NUL in octet strings as just another byte, this could happen. But we digress again, the source is useful in any case, and not just for full code reviews, used with care it is the ultimate documentation. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Fri, 19 Jan 2007, Bill Stewart wrote: > Obviously if you're trying to protect against KGB-skilled attacks > on stolen/confiscated hardware, you'd like to have the swap partition > encrypted as well as any user data partitions, though you may not care > whether your read-only utility software was protected > (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) [[...]] > > On the other hand, if you're trying to protect against > lower-skilled attackers, e.g. laptop thieves who are reselling > disks to the Nigerians and other hardware on eBay, > you want to protect your file systems, > but probably don't need to protect your swap. > It's certainly nice to do that, of course, and might be a Good Thing > for Linux and ***BSD to include in their standard swap drivers, OpenBSD has had swap-space encryption for some years, and recent versions turn it on in the default install. I don't know what the other BSDs or various Linuxen do by default. OpenBSD's swap encryption uses Rajndael/AES implemented in software. The performance hit is small on modern hardware, and still acceptable even on slow hardware (I haven't seen any problems on an old 486/33 laptop I'm using as a home firewall/router). For laptops (where physical theft is major concern), I think the combination of an encrypting file system and swap encryption gives a pretty good -- and readily configurable -- security/performance tradeoff. ciao, -- -- "Jonathan Thornburg -- remove -animal to reply" <[EMAIL PROTECTED]> Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Victor Duchovni <[EMAIL PROTECTED]> writes: >It took reading the code to determine the following: > >- ASN.1 Strings extracted from X.509v3 certs are not validated for >conformance with the declared character syntax. Strings of type >PrintableString or IA5String may hold non-printable or non-ASCII >data. Just a word in OpenSSL's defence, see the X.509 Style Guide for the reasoning behind this. I don't think any ASN.1-using security toolkit since TIPEM has done character-set checking, it would fail to verify a large chunk of the certs out there (I once had a TIPEM user complain to me that they had to stop using it specifically because it would reject invalid character strings, which encompassed a nontrivial portion of their user base). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
As far as "Full Disk Encryption"'s usefulness as a term goes, I'd distinguish between several different kinds of applications for encrypting the contents of a disk 1 - The disk drive or maybe disk controller card (RAID, SCSI, etc.) encrypts all the bits written to the drive and decrypts all the bits read from the drive, usually with some keying input from the OS. 2 - The operating system's driver software encrypts/decrypts all bits written to/from the drive 3 - The operating system's file system driver software encrypts/decrypts all bits written to/from a file system (which might or might not occupy a drive partition.) 4 - Utility software encrypts/decrypts bits written to/from directories. 5 - Application software encrypts/decrypts contents of files. Obviously if you're trying to protect against KGB-skilled attacks on stolen/confiscated hardware, you'd like to have the swap partition encrypted as well as any user data partitions, though you may not care whether your read-only utility software was protected (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) Whether you implement that in the disk controller or OS is really a matter of convenience and user support economics - if you're a small conspiracy you may want to roll your own, but if you're a corporate IT shop, you've probably got economic issues that affect whether you customize the OS (more) or the disks or both and it's the operational processes that will trip you up. On the other hand, if you're trying to protect against lower-skilled attackers, e.g. laptop thieves who are reselling disks to the Nigerians and other hardware on eBay, you want to protect your file systems, but probably don't need to protect your swap. It's certainly nice to do that, of course, and might be a Good Thing for Linux and ***BSD to include in their standard swap drivers, but hopefully your file system drivers would keep their keys in non-swappable memory, and most other things get overwritten often enough that attackers not using electron microscopes probably won't bother with them much. In most OS's, swap isn't persistent across system reboots, so you can actually generate a new key on the fly every time and not bother the user about entering it, unlike regular filesystems or full-disk-encryption systems. Of course, if the KGB *is* after you, they may black-bag your PC before they confiscate it - if there's a key-logger chip added to your keyboard or a camera mounted in your ceiling light, it may not matter how cool your FDE is. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
At 03:57 PM 1/18/2007, Saqib Ali wrote: When is the last time you checked the code for the open source app that you "use", to make sure that it is written properly? When is the last time you carefully checked the code for a closed source app that you use? (Besides the one you mentioned to start this thread) Steve - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Thu, Jan 18, 2007 at 03:57:46PM -0800, Saqib Ali wrote: > When is the last time you checked the code for the open source app > that you "use", to make sure that it is written properly? > Yesterday, in the case of OpenSSL, though I was only looking at how ASN.1 strings that store the subject CN and subjectAltName deal with the various possible supported encodings, embedded NUL octets, ... It took reading the code to determine the following: - ASN.1 Strings extracted from X.509v3 certs are not validated for conformance with the declared character syntax. Strings of type PrintableString or IA5String may hold non-printable or non-ASCII data. - Rather in OpenSSL all the ASN.1 string types are opaque TLV byte arrays, with a manifest type and arbitrary content that may or not be consisten with the type, and may hold embedded NUL bytes which require some care in C applications, but at least it *is* possible if is careful, to check that: ASN_STRING_length(s) == strlen(ASN1_STRING_DATA(s)) - Conversion to UTF8 is implemented correctly, without prematurely stopping on internal NUL octets. This also checks that BMPString and UniversalStrings have encoded lengths that are even or divisible by 4 respectively, and that UTF8 input is valid and "minimal". This means that as a user of the library, I must (and fortunately can): - Convert the raw ASN.1 encoded data if BMPString or UniversalString to UTF8. - Check CommonNames and DNS subjectAltNames for internal NULs, because I can't rely on no CA to ever mess up and sign a cert for "alice.com\0.eve.com". This check is not found in most sample applications that (cargo-cult programming rampant in other problem spaces is also common with SSL). - Check CommonNames and DNS subjectAltNames for unexpected non-printable or non-printable characters as appropriate. This is not the same as a full code review, but having access to the source means that I can make sure that my code is a correct use of the interface, that I am not making unfounded assumptions, and there are no obvious bugs in the part of the library that I am reviewing. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Algorithms can be perfect and implementation sloppy. If you can review the code you might find the problem, but with proprietary code, fergetit. I think you guys are missing the point. The term "Snake-Oil Crypto" refers to the algorithm and NOT the actual implementation. This is a "important" distinction. I am copying Matt Curtain (who maintains Snake-Oil Crypto FAQ) and Bruce Schneier so that they can correct me if I am wrong. We all know that many open crypto algorithms (like kerberos, AES) have been implemented in sloppy manner in both open-source and close-source world. Being open source doesn't necessarily mean that the implementation is secure. When is the last time you checked the code for the open source app that you "use", to make sure that it is written properly? saqib http://www.full-disk-encryption.net On 1/18/07, Allen <[EMAIL PROTECTED]> wrote: Saqib Ali wrote: > Since when did AES-128 become "snake-oil crypto"? How come I missed > that? Compusec uses AES-128 . And as far as I know AES is NOT > "snake-oil crypto" Saqib, I believe you are correct as to the algorithm, but the snake-oil is in the implementation, As I have often said, "A misplaced comma in an English sentence will merely get you a bad reputation as a writer, however, a misplaced comma in a nuclear weapons project may leave an enduring mark on the world." > > Closed-source doesn't mean that it is "snake-oil". If that was the > case, the Microsoft's EFS, and Kerberos implementation would be "snake > oil" too. As I recall there have been a few problems with Kerberos in the past. Best, Allen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Saqib Ali wrote: Since when did AES-128 become "snake-oil crypto"? How come I missed that? Compusec uses AES-128 . And as far as I know AES is NOT "snake-oil crypto" Saqib, I believe you are correct as to the algorithm, but the snake-oil is in the implementation, As I have often said, "A misplaced comma in an English sentence will merely get you a bad reputation as a writer, however, a misplaced comma in a nuclear weapons project may leave an enduring mark on the world." Algorithms can be perfect and implementation sloppy. If you can review the code you might find the problem, but with proprietary code, fergetit. Closed-source doesn't mean that it is "snake-oil". If that was the case, the Microsoft's EFS, and Kerberos implementation would be "snake oil" too. As I recall there have been a few problems with Kerberos in the past. Best, Allen - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Thu, 18 Jan 2007, Saqib Ali wrote: > Since when did AES-128 become "snake-oil crypto"? How come I missed > that? Compusec uses AES-128 . And as far as I know AES is NOT > "snake-oil crypto" It is even easier to use a good cryptographic transform in a way that is utterly insecure then it is to come up with a secure-looking-but-broken transform. How does this company apply AES-128 to the task of encrypting disk sectors? There are lots of ways to do it, many of them wrong. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On 1/18/07, Saqib Ali <[EMAIL PROTECTED]> wrote: Since when did AES-128 become "snake-oil crypto"? How come I missed that? Compusec uses AES-128 . And as far as I know AES is NOT "snake-oil crypto" He didn't say that AES is snake oil. He says he wants assurance that the tool operates correctly. Using AES to generate an XOR key is still using AES, but it's using it poorly. Closed-source doesn't mean that it is "snake-oil". If that was the case, the Microsoft's EFS, and Kerberos implementation would be "snake oil" too. He didn't say that closed source is snake oil. He says he wants assurance that the tool operates correctly. The kind of assurance you get from having a completely open design and implementation. This is right up there with Seagate's encrypting disk which Dave Korn (rightfully) expressed dismay over... "And the reason is that software vendors, particularity software vendors in the security world need to have some place to hide their secrets. And we provide the perfect place to hide secrets, because we can cryptographically handle things in a way that makes very difficult to snoop or sniff the secrets. We have hidden operation in the drive as well as hidden storage place that normally can't be accessed via ATA commands. So in a way we have a bit of a black box, in terms of a security device, that no one knows what is going on in there, and it is a perfect place to hide stuff." That's just wrong on so many levels. I want to know exactly how my data is being transformed and stored. I want to be absolutely sure that the on-disk representation of my data is critically dependent on my key, and not on some vendor-derived key based on my disk serial number. I want to know for sure that reading sector -42 won't hand you back my key. I want to know that my encryption software isn't somehow leaking my key. etc. Hand me a crypto tool so well designed, so carefully audited and so rigourously proven that it's approved for storing the government secrets until the end of time... I'll still say "that's nice, where's my copy of the source code". CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Since when did AES-128 become "snake-oil crypto"? How come I missed that? Compusec uses AES-128 . And as far as I know AES is NOT "snake-oil crypto" Closed-source doesn't mean that it is "snake-oil". If that was the case, the Microsoft's EFS, and Kerberos implementation would be "snake oil" too. I think you are mistaken on the definition of "snake-oil crypto". Snake-oil crypto refers to "New mathematics", "Proprietary cryptography", and "Pseudo-mathematical gobbledygook" Please see the following URL for more into on snake-oil crypto: http://www.schneier.com/crypto-gram-9902.html#snakeoil saqib http://www.full-disk-encryption.net If I have data that's valuable enough to need encryption, I'm going to be nervous trusting it to closed-source software. How do I know that Compusec's cryto is done properly? As Bruce Schneier has famously said, to the user snake-oil crypto looks just like good crypto -- both scramble the bits enough to look "random" to the eye. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Wed, 17 Jan 2007, Saqib Ali wrote:
[[addressed to Steven Bellovin, but copied to the whole list]]
> I would like to invite you to try out a Free FDE product called
> Compusec < http://www.ce-infosys.com/ >
If I have data that's valuable enough to need encryption, I'm going
to be nervous trusting it to closed-source software. How do I know
that Compusec's cryto is done properly? As Bruce Schneier has
famously said, to the user snake-oil crypto looks just like good
crypto -- both scramble the bits enough to look "random" to the eye.
In contrast, even though I haven't personally read the {linux,bsd}
crypto source code, lots of serious crypto geeks have, so I can be
a lot more confident that it's of at least reasonable quality.
Another issue is that closed-source crypto hardware/software has had
back doors planted in it in the past, either for "key recovery when
customers loose their keys", or after pressure by assorted government
agencies. I'm sure the NSA could bribe someone to backdoor the Linux
kernel, but it would be really hard to keep this a secret when many
"uncontrolled" people get to browse the source code.
> After trying, please let me know if the distinction between "disk
> encryption" (e.g. TrueCrypt) and "full disk encryption" (e.g.
> Compusec) is insufficient.
For the above reasons, I wouldn't trust either of these.
I keep _my_ confidential files under Matt Blaze's CFS; any of the
other open-source {linux,bsd} cryptographic file systems would be
reasonable alternatives.
--
-- "Jonathan Thornburg -- remove -animal to reply" <[EMAIL PROTECTED]>
Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Steven M. Bellovin wrote: Not necessarily -- many of my systems have multiple disk drives and file systems, some of which are on removable media. Apart from that, though, this is reinforcing my point -- what is the threat model? PC/RT had external scsi disk drive housing ... with scsi disk drive "bricks" that could be removed from the housing and locked in safes (when the owner wasn't physical present). This was later part of the '80s ... twenty some years ago. nearly 35 yrs ago ... there was this enormous corporate project and all the information on the project was kept strictly confidential. a whole bunch of security features were added to prevent leakage of any of the information. they even went so far as to claim that even I couldn't access the information ... even if I was physical present in the room. It was one of the few times that I actually took the bait ... I claimed it would only take me a few minutes ... I found the location in memory of the authentication routine and patched one byte so all returns from the routine indicated valid authentication (most of the time was spent disabling all access to the machine from outside the room since i didn't want a real compromise). This is similar ... but different to more recent "yes card" vulnerability ... where the card is asked if the correct PIN has been entered ... and a "yes card" always responds "YES". Would appear to work not only for skimming scenario and counterfeit card but also as a MITM-attack with valid card. misc. past posts mentioning "yes card" http://www.garlic.com/~lynn/subintegrity.html#yescard In any case, my claim way back then (nearly 35yrs ago) was that the only countermeasure to such physical access was encrypting the data. Later, I even did prototype filesystem as example ... but at the time ... the processor load was excessive (would typically only be justified for small subset of extremely sensitive information). The project back then was called Future System http://www.garlic.com/~lynn/subtopic.html#futuresys and was canceled w/o ever being announced. However there were some comments that the amount spent on the failed future system project would have bankrupted any other computer company. misc. past posts admitted to haven once risen to the bait in my brash youth. http://www.garlic.com/~lynn/96.html#24 old manuals http://www.garlic.com/~lynn/2004g.html#45 command line switches http://www.garlic.com/~lynn/2006.html#11 Some credible documented evidence that a MVS or later op sys has ever been hacked The scenario was that if I had physical access ... there were a whole variety of compromises that wouldn't have been possible otherwise at least for these class of systems ... small footnote about some deployments ... which i didn't find out until sometime later http://www.nsa.gov/selinux/list-archive/0409/8362.cfm Note that when it started becoming common for people taking portable terminals and later PCs on the road ... for off-site access (reading email, etc) in the very early 80s ... there was vulnerability study done ... and one conclusion was that one of the most weakest points is a hotel PBX closet ... which resulted in design, build and deployment of custom encrypting 2400baud modems for all off-site dial-in access. I'm periodically quite dismayed by the cavalier way that many corporations have treated off-site access over the past 20 years. For other comparison, the corporate network, which was larger than arpanet/internet from just about the beginning until possibly sometime mid-85. http://www.garlic.com/~lynn/subnetwork.html#internalnet required link encryptors on all lines that left a corporate facility ... and sometime in the mid-80s there were comments that the internal corporate network had over half of all the link encryptors in the world (these are things like leased lines ... separate from the encrypting dial-up modems). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Wed, 17 Jan 2007 09:33:54 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > On 1/16/07, Steven M. Bellovin <[EMAIL PROTECTED]> wrote: > > I don't think that that distinction is either necessary or > > sufficient. > > Dr. Bellovin, Please -- "Steve". > > I would like to invite you to try out a Free FDE product called > Compusec < http://www.ce-infosys.com/ > Does it run on NetBSD? I don't use Windows > > After trying, please let me know if the distinction between "disk > encryption" (e.g. TrueCrypt) and "full disk encryption" (e.g. > Compusec) is insufficient. > My point is that I have some fairly complex operational environments. The distinction between the "operating system" and everything else isn't that clear. What is part of the OS? The kernel? The boot loader? (It has several parts.) Dynamically-loaded modules? /sbin/init? The shell? My virtual machines? The Xen hypervisor? (I don't yet run Xen on my laptop. I will as soon as it supports power management.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On 1/16/07, Steven M. Bellovin <[EMAIL PROTECTED]> wrote: I don't think that that distinction is either necessary or sufficient. Dr. Bellovin, I would like to invite you to try out a Free FDE product called Compusec < http://www.ce-infosys.com/ > After trying, please let me know if the distinction between "disk encryption" (e.g. TrueCrypt) and "full disk encryption" (e.g. Compusec) is insufficient. Note: I am not affiliated with Compusec in any manner. Thanks saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, Jan 16, 2007 at 11:33:46AM -0500, Steven M. Bellovin wrote: > On Tue, 16 Jan 2007 08:19:41 -0800 > "Saqib Ali" <[EMAIL PROTECTED]> wrote: > > > Dr. Bellovin, > > > > > In most situations, disk encryption is useless and probably harmful. > > > It's useless because you're still relying on the OS to prevent > > > access to the cleartext through the file system, and if the OS can > > > do that it can do that with an unencrypted disk. > > > > I am not sure I understand this. With FDE, the HDD is unlocked by a > > pre-boot kernel (linux). It is not the function of the resident OS to > > unlock the drive. > > Not necessarily -- many of my systems have multiple disk drives and > file systems, some of which are on removable media. Apart from that, > though, this is reinforcing my point -- what is the threat model? Seems to me the threat model is real and obvious - physical access to the disk hardware - either by theft or (worse) by stealth (eg black bag jobs, or insider access at night or on weekends). Think of someone either image copying or stealing a drive that contains valuable data... most of the time this necessarily involves either powering it down or disconnecting it in a way that can be readily detected by drive and host interface firmware. If this results in zeroization of the working key in the drive requiring some kind of re-authentication of host to drive and drive to host and then reload of key before the data can be read it at least becomes significantly harder to steal data by just unplugging the drive and either walking out the door with it in your briefcase or plugging it into another system for an image copy before returning it to its normal home. Needless to say if the drive and its contained file systems aren't encrypted this is pretty low hanging fruit. Relatively unskilled attackers can easily capture very valuable material if they can gain physical access for only a few minutes. And further, unusual events - disasters such as floods, fires, tornadoes, building collapses and the like - can result in massive exposure of confidential data amidst the ruins whereas if the disks in desktops and servers were encrypted capture of - or covert access to - the drives in the chaos surrounded a crisis is much less useful to an adversary. Obviously it may be possible for really sophisticated attackers to somehow unplug drives from live machines without the key zeroization happening and presumably without the host noticing and raising an alarm and logging the event, but given the mechanical design of modern high end desktop and server boxes with a common connector for power and signals for the current generation of SATA drives this is at the very least significantly more challenging to do without getting noticed or caught than just causing a fake power fail and removing the disks. And it can be made harder by appropriate modest hardware, firmware and system tweaks too. Obviously too, a disk whose surface is encrypted with a key it forgets when the power is off can be quite safely shipped or stored or even decommissioned and destroyed without much danger of disclosure of confidential data contained therein. This is far more useful in practice than it might in first seem as it reduces costs and risks a lot in many common situations where drives and even entire machines need to be moved, stored, sold, scrapped and shipped around in untrusted hands. And a server or desktop that is depowered (if it is truly depowered, not always the case with modern hardware) can be assumed to be in a fairly secure state (presuming the key reload on power up requires some external intervention) whereas a traditional in-the-clear disks server or desktop that contains highly sensitive information is in face MORE vulnerable when powered down in that its disks can be removed, image copied, and returned to the system without much of anything being the wiser. A powered up machine is much more likely to at least log anomalous events that can be detected if not suspiciously crash altogether when its disks are removed or disconnected. This paradoxically makes the systems in a typical office more vulnerable exactly when they are least well monitored and protected - nights and weekends and other off hours. So I do think the classic FDE with AES in the drive ASICs does gain something meaningful against this kind of threat, though obviously the most sophisticated and careful attacks can defeat it. But defeating the less elaborate attacks at least removes an AWFUL lot of low hanging fruit and in doing so materially increases overall security. There are far fewer really sophisticated attackers than common (and often pretty stupid) petty criminals near computers, after all. Back under my rock... -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weathe
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
At 08:08 AM 1/16/2007, Steven M. Bellovin wrote: On Tue, 16 Jan 2007 07:56:22 -0800 Steve Schear <[EMAIL PROTECTED]> wrote: > At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. And of course, there's always rubber hose cryptanalysis in jurisdictions where that's acceptable. That assumes the police or other agencies know who operated the server. In practice, some TOR servers are rented by hosting sites to parties they don't know or think they know but really don't. Steve - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007 08:58:27 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > > Yes, encrypted disks aren't much good unless the OS also encrypts > > (at least) swap space. I note that OpenBSD ships with swap-space > > I think you are confusing "Disk Encryption" with "Full Disk Encryption > (FDE)". They are two different beast. > > FDE encrypts the "entire" boot drive, including the OS, kernel and the > swap space. > > Disk Encryption, on the other hand, only encrypts the non-OS portion. > > saqib > http://www.full-disk-encryption.net > I don't think that that distinction is either necessary or sufficient. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Steven M. Bellovin wrote: ... Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. And of course, there's always rubber hose cryptanalysis in jurisdictions where that's acceptable. In the UK Part III of the Regulation of Investigatory Powers Act 2000 - see http://www.opsi.gov.uk/Acts/acts2000/2023.htm - includes powers for certain classes of officials to require encrypted materials to be decrypted or to require a key to be provided. There are some safeguards, regarded by some as insufficient. The powers have not yet been brought into force, but the Government intends to bring them into force in the near future. The powers are of course wholly ineffectual where perfect forward secrecy obtains, are of limited value in relation to ephemeral encrypted communications where keys are (or may plausibly be claimed to be) changed frequently or lost, but may be of some real value in relation to encrypted storage media where key preservation, with or without key recovery mechanisms, will obviously be important to most users. Nicholas Bohm -- Salkyns, Great Canfield, Takeley, Bishop's Stortford CM22 6SX, UK Phone 01279 870285(+44 1279 870285) Mobile 07715 419728(+44 7715 419728) PGP public key ID: 0x899DD7FF. Fingerprint: 5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Steven M. Bellovin wrote: > On Tue, 16 Jan 2007 07:56:22 -0800 > Steve Schear <[EMAIL PROTECTED]> wrote: > >> At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: >>> Disk encryption, in general, is useful when the enemy has physical >>> access to the disk. Laptops -- the case you describe on your page -- >>> do fit that category; I have no quarrel with disk encryption for >>> them. It's more dubious for desktops and *much* more dubious for >>> servers. >> As governments widen their definitions of just who is a potential >> threat it makes increasing sense for citizens engaged in previous >> innocuous activities (especially political and financial privacy) to >> protect their data from being useful if seized. This goes double for >> those operating privacy-oriented services and their servers. As an >> example, when TOR servers were recently seized in German raids (with >> the implication that they were being used as conduits for child porn) >> the police knew enough to only take the hot-swap drives (which were >> encrypted and therefore paper weights after removal) if only for >> show. The main loss to the operators was repair to the cage locks. >> > Legal access is a special case -- what is the law (and practice) in any > given country on forced access to keys? If memory serves, Mike Godwin > -- a lawyer who strongly supports crypto, etc. -- has opined that under > US law, a subpoena for keys would probably be upheld by the courts. I > believe that British law explicitly mandates key disclosure. The situation here in the UK is that Parliament has passed a law (RIPA) that allows the UK government to introduce key disclosure powers if it wishes to do so. So far these powers have not been bought into operation but the UK government initiated a consultation last year on whether it should take this step. We are still awaiting a decision on this. Brian Gladman - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Yes, encrypted disks aren't much good unless the OS also encrypts (at least) swap space. I note that OpenBSD ships with swap-space I think you are confusing "Disk Encryption" with "Full Disk Encryption (FDE)". They are two different beast. FDE encrypts the "entire" boot drive, including the OS, kernel and the swap space. Disk Encryption, on the other hand, only encrypts the non-OS portion. saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007 08:19:41 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > Dr. Bellovin, > > > In most situations, disk encryption is useless and probably harmful. > > It's useless because you're still relying on the OS to prevent > > access to the cleartext through the file system, and if the OS can > > do that it can do that with an unencrypted disk. > > I am not sure I understand this. With FDE, the HDD is unlocked by a > pre-boot kernel (linux). It is not the function of the resident OS to > unlock the drive. Not necessarily -- many of my systems have multiple disk drives and file systems, some of which are on removable media. Apart from that, though, this is reinforcing my point -- what is the threat model? > > > It's harmful because you can > > lose a key. (Your web page does address that, but I'm perplexed -- > > what is challenge/response authentication for key recovery?) > > Challenge/Response password recovery, as I understand, is a very > simplified implementation of Secret Sharing. It allows for 2 parties, > in this case the IT HelpDesk and the User, to collaborate and recover > a Secret. > 1) Upon forgetting the password, the user calls the Help Desk. > 2) The IT Help Desk authenticates the user in the usual ways (e.g. > check office voice mail etc), as the policy dictates. > 3) Once authenticated the user give the partial secret to the > HelpDesk. 4) The HelpDesk then combine it with the secret they have > to produce a temporary password. > 5) The temporary password is then used to unlock the HDD "once", and > new credentials are created. > I wouldn't call that "challenge/response", I'd call that key escrow. Key escrow isn't a bad idea for storage encryption, but you need *really* good authentication mechanisms for the backup channel. Visualize this phone call to the help desk: "Hi, I'm Pat, the CFO. I'm in New York for the Board meeting, and my laptop blue-screened and won't reboot -- it's not accepting my passphrase. Help!" Of course, more or less by definition, Pat isn't online at that point, so the help desk can't manipulate anything remotely. (I should add that most secondary authentication mechanisms I've seen are garbage, especially when it comes to people on the road. Since we're talking about laptops here, that's a very serious threat.) I don't dispute the need for FDE for (many) laptops. But remember that security is a systems property; it's not something you can get by bolting on crypto. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin Yup. Disk Crypto has a ugly side as well, as highlighted by the recent incident where FBI was unable to crack the encryption used by a pedophile and murderer. There was a long discussion on this topic on the Security-Basics mailing list: http://www.xml-dev.com/lurker/thread/20061020.173753.ee4c6a0c.en.html#20061020.173753.ee4c6a0c saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Dr. Bellovin, In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. I am not sure I understand this. With FDE, the HDD is unlocked by a pre-boot kernel (linux). It is not the function of the resident OS to unlock the drive. It's harmful because you can lose a key. (Your web page does address that, but I'm perplexed -- what is challenge/response authentication for key recovery?) Challenge/Response password recovery, as I understand, is a very simplified implementation of Secret Sharing. It allows for 2 parties, in this case the IT HelpDesk and the User, to collaborate and recover a Secret. 1) Upon forgetting the password, the user calls the Help Desk. 2) The IT Help Desk authenticates the user in the usual ways (e.g. check office voice mail etc), as the policy dictates. 3) Once authenticated the user give the partial secret to the HelpDesk. 4) The HelpDesk then combine it with the secret they have to produce a temporary password. 5) The temporary password is then used to unlock the HDD "once", and new credentials are created. -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007 07:56:22 -0800 Steve Schear <[EMAIL PROTECTED]> wrote: > At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: > >Disk encryption, in general, is useful when the enemy has physical > >access to the disk. Laptops -- the case you describe on your page -- > >do fit that category; I have no quarrel with disk encryption for > >them. It's more dubious for desktops and *much* more dubious for > >servers. > > As governments widen their definitions of just who is a potential > threat it makes increasing sense for citizens engaged in previous > innocuous activities (especially political and financial privacy) to > protect their data from being useful if seized. This goes double for > those operating privacy-oriented services and their servers. As an > example, when TOR servers were recently seized in German raids (with > the implication that they were being used as conduits for child porn) > the police knew enough to only take the hot-swap drives (which were > encrypted and therefore paper weights after removal) if only for > show. The main loss to the operators was repair to the cage locks. > Legal access is a special case -- what is the law (and practice) in any given country on forced access to keys? If memory serves, Mike Godwin -- a lawyer who strongly supports crypto, etc. -- has opined that under US law, a subpoena for keys would probably be upheld by the courts. I believe that British law explicitly mandates key disclosure. And of course, there's always rubber hose cryptanalysis in jurisdictions where that's acceptable. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
At 06:32 AM 1/16/2007, Steven M. Bellovin wrote: Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. As governments widen their definitions of just who is a potential threat it makes increasing sense for citizens engaged in previous innocuous activities (especially political and financial privacy) to protect their data from being useful if seized. This goes double for those operating privacy-oriented services and their servers. As an example, when TOR servers were recently seized in German raids (with the implication that they were being used as conduits for child porn) the police knew enough to only take the hot-swap drives (which were encrypted and therefore paper weights after removal) if only for show. The main loss to the operators was repair to the cage locks. Steve - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007, Steven M. Bellovin wrote: [[about full-disk encryption]] > In most situations, disk encryption is useless and probably harmful. > It's useless because you're still relying on the OS to prevent access > to the cleartext through the file system, and if the OS can do that it > can do that with an unencrypted disk. Yes, encrypted disks aren't much good unless the OS also encrypts (at least) swap space. I note that OpenBSD ships with swap-space encryption turned on by default. The encryption is done in software using Rijndael. On modern hardware the performance hit is minimal (compared to the cost of the disk access). See http://www.openbsd.org/papers/swapencrypt.ps for a discussion of the security model. ciao, -- -- "Jonathan Thornburg -- remove -animal to reply" <[EMAIL PROTECTED]> Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Mon, 15 Jan 2007 08:39:18 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > An article on how to use freely available Full Disk Encryption (FDE) > products to protect the secrecy of the data on your laptops. FDE > solutions helps to prevent data leaks in case the laptop is stolen or > goes missing. The article includes a brief intro, benefits, drawbacks, > some tips, and a complete list of FDE solutions in the market. > > http://www.full-disk-encryption.net/intro.php On Tue, 16 Jan 2007, Steven M. Bellovin wrote: > I'll turn it around -- why should you use it? > > In most situations, disk encryption is useless and probably harmful. [[cogent arguments snipped]] A further point: Do you really want the granularity of your encryption to be "one key per disk"? I much prefer a cryptographic file system which lets me have separate keys for separate categories of information (eg one key for my tax forms, a different key for company-confidential project stuff, a different key for old love letters, still another one for My Secret Plan For World Domination, etc etc). These might all live on the same laptop, but they probably need quite different key policies. ciao, -- -- "Jonathan Thornburg -- remove -animal to reply" <[EMAIL PROTECTED]> Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Mon, 15 Jan 2007 08:39:18 -0800 "Saqib Ali" <[EMAIL PROTECTED]> wrote: > An article on how to use freely available Full Disk Encryption (FDE) > products to protect the secrecy of the data on your laptops. FDE > solutions helps to prevent data leaks in case the laptop is stolen or > goes missing. The article includes a brief intro, benefits, drawbacks, > some tips, and a complete list of FDE solutions in the market. > > http://www.full-disk-encryption.net/intro.php > I'll turn it around -- why should you use it? In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. It's harmful because you can lose a key. (Your web page does address that, but I'm perplexed -- what is challenge/response authentication for key recovery?) Disk encryption, in general, is useful when the enemy has physical access to the disk. Laptops -- the case you describe on your page -- do fit that category; I have no quarrel with disk encryption for them. It's more dubious for desktops and *much* more dubious for servers. (Caveat: I'm assuming that when you dispose of systems, you run DBAN or some such on the drives -- if not, we're back to the physical access threat.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
