Re: Security of Mac Keychain, Filevault

[David-Sarah Hopwood]

Steven Bellovin wrote:
> On Oct 29, 2009, at 11:25 PM, Jerry Leichter wrote:
> 
>> A couple of days ago, I pointed to an article claiming that these were
>> easy to break, and asked if anyone knew of security analyses of these
>> facilities.

See below.

>> I must say, I'm very disappointed with the responses.  Almost everyone
>> attacked the person quoted in the article.  The attacks they assumed
>> he had in mind were unproven or unimportant or insignificant.  Gee ...
>> sounds *exactly* like the response you get from companies when someone
>> finds a vulnerability in their products:  It's not proven; who is this
>> person anyway; even if there is an attack, it isn't of any practical
>> importance.
> 
> Unfortunately, there's no better response here.
> 
> At time T, someone will assert that "X is insecure", and that products
> exist -- commercial and freeware -- to crack it.  This person supplies
> no evidence except for an incomplete list of products to support the
> assertion.  What do I now know that I didn't know before?
[...]

I agree, there was no useful evidence about the security of Filevault
or Keychain in the article.

> The article made no verifiable or falsifiable technical statements, so
> there's nothing to evaluate in that respect.  I've never heard of any
> freeeware to crack Filevault; given the familiarity of the readership of
> this list in the aggregate with the free software world, it seems
> unlikely that such software exists.  He did point to some commercial
> software to attack Filevault, but it works by password guessing.  For
> his business -- forensic analysis -- I suspect that that technique is
> extremely useful; I doubt that anyone on this list would disagree.  But
> that's not the same as a flaw in MacOS.

However, there are huge differences in the relative cost of password
guessing between different disk encryption protocols. There are also
significant differences in the help that crypto software gives users to
encourage them to use a high-entropy password/passphrase. For instance,
if some product just used a simple hash to generate a key from a password,
rather than using a technique like key strengthening or key stretching and a
random salt, then I would consider that a serious flaw, even if everything
else about the product's crypto usage were well-designed.

OTOH, according to ,
Filevault uses PBKDF2, which does employ key strengthening. However it
only uses 1000 hash iterations, which is a little on the low side.
The video of that talk is at
 (the
actual talk doesn't appear to start until a few minutes in).

Note that according to the slides,
"Cryptographic security depends on more than just AES-128, it's rather
3DES effective 112bit || AES-128 || RSA-1024".

Also, only the user's home directory is encrypted, "passwords are not
properly scrubbed", and swap file encryption is not enabled by default.

Worse, "If encrypted swap is on: contents of the sleep image will be
encrypted, but key will be written out in the header". Oops.

--
David-Sarah Hopwood http://davidsarah.livejournal.com
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[David-Sarah Hopwood]

Zooko Wilcox-O'Hearn wrote:
> Dear Darren J Moffat:
> 
> I don't understand why you need a MAC when you already have the hash of
> the ciphertext.  Does it have something to do with the fact that the
> checksum is non-cryptographic by default
> (http://docs.sun.com/app/docs/doc/819-5461/ftyue?a=view ), and is that
> still true?  Your original design document [1] said you needed a way to
> force the checksum to be SHA-256 if encryption was turned on.  But back
> then you were planning to support non-authenticating modes like CBC.  I
> guess once you dropped non-authenticating modes then you could relax
> that requirement to force the checksum to be secure.
> 
> Too bad, though!  Not only are you now tight on space in part because
> you have two integrity values where one ought to do, but also a secure
> hash of the ciphertext is actually stronger than a MAC!  A secure hash
> of the ciphertext tells whether the ciphertext is right (assuming the
> hash function is secure and implemented correctly).  Given that the
> ciphertext is right, then the plaintext is right (given that the
> encryption is implemented correctly and you use the right decryption
> key).

Hmm. That may be too many "given"s.

Tahoe (see www.allmydata.org) has an open bug to add a plaintext hash,
precisely because the encryption might not be implemented correctly or
the encryption key might not be correct:


It seems as though ZFS (and many other protocols) is in the same position
as Tahoe, in wanting some way to validate that the ciphertext is correct
without needing the decryption key, but also wanting to minimize the risk
of some implementation error, and/or use of the wrong decryption key,
resulting in undetected errors in the plaintext.

I had something similar to the following in mind for the next update to
my proposal for Tahoe's new crypto protocol (simplified here to avoid
Tahoe-specific details and terminology):

 - a "plaintext verifier" is Hash1(index, salt, plaintext).

 - a "ciphertext verifier" is Hash2(index, ciphertext).

 - at a location determined by 'index', store:
   ciphertext = Encrypt[K](salt, plaintext)


This has the following advantages:

 - For integrity of the plaintext, you only need to assume that the
   implementation of the hash is correct. Moreover, if the hash
   implementation is not correct, that is very likely to cause it to
   fail to verify good data, which is noticeable as an error in normal
   operation. To get bad data to pass verification, the attacker would
   need to have some control over the output value of the incorrect
   hash; an error that effectively randomizes the value does not help
   them.

 - The verification also ensures integrity of the index. So, if a
   ciphertext ends up being stored in the wrong place, that will be
   detected.

 - Verification of the plaintext does not require the decryption key;
   it can be done using just the known plaintext verifier, and the
   purported values of 'salt' and 'plaintext' obtained from decryption.

   This is very important "if it must be possible to have all
   cryptographic key material stored and/or created entirely in a
   hardware device", as [1] states as a requirement for ZFS. If the
   verification can be done safely in software and if the encryption
   uses a standard mode, then it is more likely that existing crypto
   hardware, or at least hardware that has no specific dependency on
   ZFS, can be used.

 - Knowledge of the plaintext verifier by itself leaks no information
   about the plaintext, under the assumptions that the hash is oneway,
   and that there is no repetition of an (index, salt, plaintext) triple.

 - A non-malicious corruption of any of the plaintext verifier, the
   ciphertext, or the decryption key will cause the plaintext to fail
   to verify.

 - A malicious change to the ciphertext or any induced error in the
   decryption will cause the plaintext to fail to verify as long as
   the correct plaintext verifier is used.

Contrast with the case where we only use a ciphertext checksum, where
either an error in the decryption, or corruption of the decryption key,
will result in an undetected error in the plaintext.

Of course we also need to consider the space constraints. 384 bits
would fit two 192-bit hashes for the plaintext and ciphertext
verifiers; but then we would have no space to accomodate the
ciphertext expansion that results from encrypting the salt together
with the plaintext.

I'm not familiar enough with ZFS's on-disk format to tell whether there
is a way around this. Note that the encrypted salt does not need to
be stored in the same place as either the verifiers or the rest of
the ciphertext.

> A MAC on the plaintext tells you only that the plaintext was
> chosen by someone who knew the key.  See what I mean?  A MAC can't be
> used to give someone the ability to read some data while withholding
> from them the ability to alter that data.  A secure hash 

Re: Security of Mac Keychain, Filevault

[Taral]

On Mon, Nov 2, 2009 at 5:41 PM, Jerry Leichter  wrote:
> The trend is for this to get worse, with
> network-wide shared authentication via OpenID or whatever other standard
> catches on.

Not to derail this, but OpenID is flexible enough to permit
fine-grained authentication as well as non-password-based
authentication (e.g. smart card) and multi-factor authentication.

-- 
Taral 
"Please let me know if there's any further trouble I can give you."
-- Unknown

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com