Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-22 Thread james hughes


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?

2007-01-22 Thread james hughes


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?

2007-01-20 Thread Peter Gutmann
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?

2007-01-20 Thread Jonathan Thornburg
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?

2007-01-20 Thread Victor Duchovni
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?

2007-01-19 Thread Victor Duchovni
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?

2007-01-19 Thread Steve Schear

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?

2007-01-19 Thread Bill Stewart


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?

2007-01-18 Thread Allen



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?

2007-01-18 Thread Saqib Ali

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?

2007-01-16 Thread Steven M. Bellovin
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]


Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?

2007-01-16 Thread Jonathan Thornburg
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?

2007-01-16 Thread Jonathan Thornburg
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?

2007-01-16 Thread Steve Schear

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?

2007-01-16 Thread Steven M. Bellovin
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?

2007-01-16 Thread Saqib Ali

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?

2007-01-16 Thread Saqib Ali

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?

2007-01-16 Thread Steven M. Bellovin
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?

2007-01-16 Thread Saqib Ali

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?

2007-01-16 Thread Brian Gladman
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?

2007-01-16 Thread Nicholas Bohm

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]