Re: Security of Mac Keychain, Filevault

[Jerry Leichter]

On Nov 2, 2009, at 5:36 PM, Jeffrey I. Schiller wrote:


- "Jerry Leichter"  wrote:

for iPhone's and iPod Touches, which are regularly used to hold
passwords (for mail, at the least).


I would not (do not) trust the iPhone (or iPod Touch) to protect a
high value password.
There are two problems with this:  So many of the things you'd really  
like to be able to do with your iPhone/Touch/other smart phone require  
a key whose value is very difficult to calculate (e.g., just what  
would you lose if someone could read all your mail?); and services  
increasing bundle all kinds of things together under one password.   
For example, all your Google services use the same password; and your  
Apple Mobile Me mail password is also the key to such things as you  
contact list (if you sync it) and Back To My Mac (which I now disable,  
useful as it might be, for just this reason) and your iTunes store  
account.  You can dissociate some of these, directly or indirectly,  
but the services assume they are tied together and don't work nearly  
as well if you do that.  The trend is for this to get worse, with  
network-wide shared authentication via OpenID or whatever other  
standard catches on.



Or more to the point I would change any such
password if my iPhone went unaccounted for.

Oh, absolutely.


In the case of the Mac Keychain and Filevault, if implemented
correctly, the security hinges on a secret that you know.
And you know this ... how?  Have you, or anyone you know, vetted the  
design?  Sure, *if* it's all implemented correctly, it maintains  
*some* set of security properties.  Do you even know what those are?   
I know I don't



Pick a good
secret (high entropy) and you are good. Pick a poor one, well...

However the iPhone’s keychain is not encrypted in a password. Instead
it is encrypted in a key derived from the hardware. The iPhone
Dev-Team, the folks who regularly jail break the iPhone, seem to have
little problem deriving keys from the phone! Note: Setting a phone
lock password doesn’t prevent me from accessing the phone using the
various jail breaking tools. Presumably once I have control of the
phone, I have access to any of the keys on it.

That would be my assumption, too.

As the value of the information in smartphones grows daily, their  
vulnerabilities will be more and more of a problem.  Remote wipe -  
assuming it really destroys the data - helps against loss, but does  
nothing against a deliberate, targeted attack, which can probably copy  
all the data within minutes.  We need some new thinking here.  One  
possible approach, based on an idea IBM played with a couple of years  
back but that as far as I know never made it into a product:  Build a  
Bluetooth-connected ring or key fob that must be physically quite  
close to the device to keep it unlocked.  IBM did this for laptops,  
and just locked the screen.  For a smartphone, you'd want the phone  
and the fob to mutually authenticate, and then the fob would transfer  
a key that could be used to unlock critical data on the phone.  When  
the fob goes out of range, the phone wipes the key and all decrypted  
data.  One can certainly come up with attacks on this - even so simple  
as the smart mugger scenario:  Give me your phone and your fob - but  
it raises the bar, with minimal inconvenience in normal use.

-- Jerry

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

Re: Security of Mac Keychain, Filevault

[Jeffrey I. Schiller]

- "Jerry Leichter"  wrote:
> for iPhone's and iPod Touches, which are regularly used to hold  
> passwords (for mail, at the least).

I would not (do not) trust the iPhone (or iPod Touch) to protect a
high value password. Or more to the point I would change any such
password if my iPhone went unaccounted for.

In the case of the Mac Keychain and Filevault, if implemented
correctly, the security hinges on a secret that you know. Pick a good
secret (high entropy) and you are good. Pick a poor one, well...

However the iPhone’s keychain is not encrypted in a password. Instead
it is encrypted in a key derived from the hardware. The iPhone
Dev-Team, the folks who regularly jail break the iPhone, seem to have
little problem deriving keys from the phone! Note: Setting a phone
lock password doesn’t prevent me from accessing the phone using the
various jail breaking tools. Presumably once I have control of the
phone, I have access to any of the keys on it.

-Jeff

-- 

Jeffrey I. Schiller
MIT Network Manager/Security Architect
PCI Compliance Officer
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
j...@mit.edu


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

Re: Security of Mac Keychain, Filevault

[Jerry Leichter]

On Nov 1, 2009, at 10:32 PM, 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.


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?...

A couple of others wrote to me privately with the same general thought.

I see I'm still not managing to make my point.  Suppose the world were  
as in the following diagram:


People who say they've looked   People who claim 
Keychain can be
Keychain and believe it's good  broken easily
-
Apple   
Some unknown guy who sells
Adi Shamir  
products for analyzing Macs
Neils Ferguson
Bruce Schneier
Steven Bellovin
John Gilmore
Perry Metzger

Then I'd agree that there's not much to talk about.  But that doesn't  
happen to be the world we live in.  Instead, the world we live in is  
described by the following diagram:


People who say they've looked   People who claim 
Keychain can be
Keychain and believe it's good  broken easily
-
Apple   
Some unknown guy who sells

products for analyzing Macs

Now, this isn't all that different from the following world:

People who say they've looked   People who claim 
Keychain can be
Keychain and believe it's good  broken easily
-
Apple   

 - though to assert it's *identical* when we have *no* information  
about the person making the claim is a bit much.  Having *no*  
reputation isn't the same as having a reputation for being a shill or  
an incompetent.


But even in *this* last world ... doesn't it bother people that all we  
have is a "trust us" from Apple?  Yes, as I acknowledged, Apple's  
track record is pretty good here - but it's *not* unblemished.


I've actually tried to look at Keychain, but most of the guts are  
built on the Apple crypto provider framework, which is quite a large  
collection of code to digest with no previous knowledge.  So I didn't  
get anywhere interesting in the time I was in a position to invest.


I've been referring specifically to Keychain, about which there  
appears to be nothing at all published.  But the situation is only  
slightly better - a single 2+ year old paper - for encrypted disk  
images in general an Filevault in particular.  And it's also the same  
for iPhone's and iPod Touches, which are regularly used to hold  
passwords (for mail, at the least).


-- Jerry

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

First Test for Election Cryptography

[Ali, Saqib]

http://www.technologyreview.com/web/23836/





saqib
http://replaycall.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

[Nicolas Williams]

On Sun, Nov 01, 2009 at 10:33:34PM -0700, Zooko Wilcox-O'Hearn wrote:
> 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.

[Not speaking for Darren...]  No, the requirement to use a strong hash
remains, but since the hash would be there primarily for protection
against errors, I don't the requirement for a strong hash is really
needed.

> 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).  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 can.

Users won't actually get the data keys, only the data key wrapping keys.
Users who can read the disk and find the wrapped keys and know the
wrapping keys can find the actual data keys, of course, but add in a
host key that the user can't read and now the user cannot recover their
data keys.  One goal is to protect a system against its users, but
another is to protect user data against maliciou modification by anyone
else.  A MAC provides the first kind of protection if the user can't
access the data keys, and a MAC provides the second kind of protection
if the data keys can be kept secret.

> One of the founding ideas of the whole design of ZFS was end-to-end  
> integrity checking.  It does that successfully now, for the case of  
> accidents, using large checksums.  If the checksum is secure then it  
> also does it for the case of malice.  In contrast a MAC doesn't do  
> "end-to-end" integrity checking.  For example, if you've previously  
> allowed someone to read a filesystem (i.e., you've given them access  
> to the key), but you never gave them permission to write to it, but  
> they are able to exploit the isses that you mention at the beginning  
> of [1] such as "Untrusted path to SAN", then the MAC can't stop them  
> from altering the file, nor can the non-secure checksum, but a secure  
> hash can (provided that they can't overwrite all the way up the  
> Merkle Tree of the whole pool and any copies of the Merkle Tree root  
> hash).

I think we have to assume that an attacker can write to any part of the
pool, including the Merkle tree roots.  It'd be odd to assume that the
attacker can write anywhere but there -- there's nothing to make it so!

I.e., we have to at least authenticate the Merkle tree roots.  That
still means depending on collision resistance of the hash function for
security.  If we authenticate every block we don't have that dependence
(I'll come back to this).

The interesting thing here is that we want the hash _and_ the MAC, not
just the MAC.  The reason is that we want block pointers (which include
the {IV, MAC, hash} for the block being pointed to) to be visible to the
layer below the filesystem, so that we can scrub/resilver and evacuate
devices from a pool (meaning: re-write all the block pointers point to
blocks on the evacuated devices so that they point elsewhere) even
without having the data keys at hand (more on this below).

We could MAC the Merkle tree roots alone, thus alleviating the space
situation in the block pointer structure (and also saving precious CPU
cycles).  But interestingly we wouldn't alleviate it that much!  We need
to store a 96-bit IV, and if we don't MAC every block then we'll want
the strongest hash we can use, so we'll need at least another 256 bits,
for a total of 352 bits of the 384 that we have to play with.  Whereas
if we MAC every block we might store a 96-bit IV, a 128-bit
authentication tag and 160-bit hash, using all 384 bits.

You get more collision resistance from an N-bit MAC than from a hash of
the same length.  That's because in the MAC case the forger can't check
the forgery without knowing the key, while in the hash case the attacker
can verify that some contents collides with another's hash.  In the MAC
case an attacker that hasn't broken the M

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

[Matt Ball]

Hi Darren,


On Fri, Oct 30, 2009 at 11:30 AM, Darren J Moffat wrote:

> For the encryption functionality in the ZFS filesystem we use AES in CCM or
> GCM mode at the block level to provide confidentiality and authentication.
>  There is also a SHA256 checksum per block (of the ciphertext) that forms a
> Merkle tree of all the blocks in the pool. Note that I have to store the
> full IV in the block.   A block here is a ZFS block which is any power of
> two from 512 bytes to 128k (the default).
>
> The SHA256 checksums are used even for blocks in the pool that aren't
> encrypted and are used for detecting and repairing (resilvering) block
> corruption.  Each filesystem in the pool has its own wrapping key and data
> encryption keys.
>
> Due to some unchangeable constraints I have only 384 bits of space to fit
> in all of: IV, MAC (CCM or GCM Auth Tag), and the SHA256 checksum, which
> best case would need about 480 bits.
>
> Currently I have Option 1 below but I the truncation of SHA256 down to 128
> bits makes me question if this is safe.  Remember the SHA256 is of the
> ciphertext and is used for resilvering.
>
> Option 1
> 
> IV  96 bits  (the max CCM allows given the other params)
> MAC 128 bits
> ChecksumSHA256 truncated to 128 bits
>
>
I personally like the default option 1.  All the others have various
uglinesses.

SHA-224 has patent issues (see US patent
6829355).
It's really identical to SHA-256 except that it uses a different initial
value and truncates to 224 bits.  I would love to see SHA-224 completely
disappear.

Cryptographers will all have different opinions about how big a MAC (i.e.,
cryptographic integrity check) should be, but my take on it is to ask how
big of a CRC would you need in a non-adversarial environment to meet the
undetectable error rate specified within the system, and then use that for
the minimum size of the MAC.  For tape drives I've worked on, this was
typically somewhere around 1 undetected error in 10^27 bits.  If you protect
1 data bit, then you'd roughly need an 90 bit CRC, which you could round up
to 96-bits.  Anything more than 96 bits in my opinion is somewhat overkill.
I'd pick a CCM mac of either 96 bits or 128.

For hashing, it's a little different since you have to worry about the
birthday paradox.  The size of the hashing output depends on the
undetectable error rate of the system, along with the maximum number of
candidate plaintexts that an adversary could create in finding a hash
collision.  Most cryptographers (not knowing more about the system) would be
conservative and say something like "Use the full 256-bits of SHA-256 to get
a minimum of 128-bits of security", but realistically for this system, that
would be way overkill.  There's already a 128-bit CCM MAC to fall back to,
so here again (given the other safety nets in the system), I think that a
128-bit truncated SHA-256 has would be plenty of assurance for the system.

-- 
Thanks!

Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717

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

[Alexander Klimov]

On Fri, 30 Oct 2009, Darren J Moffat wrote:
> The SHA256 checksums are used even for blocks in the pool that aren't
> encrypted and are used for detecting and repairing (resilvering) block
> corruption.  Each filesystem in the pool has its own wrapping key and
> data encryption keys.
>
> Due to some unchangeable constraints I have only 384 bits of space to
> fit in all of: IV, MAC (CCM or GCM Auth Tag), and the SHA256 checksum,
> which best case would need about 480 bits.
>
> Currently I have Option 1 below but I the truncation of SHA256 down to
> 128 bits makes me question if this is safe.  Remember the SHA256 is of
> the ciphertext and is used for resilvering.

If you use hash only to protect against non-malicious corruptions,
when why you use SHA-2? Would not MD5 or even CRC be enough?

-- 
Regards,
ASK

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

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

[Zooko Wilcox-O'Hearn]

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).  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 can.


One of the founding ideas of the whole design of ZFS was end-to-end  
integrity checking.  It does that successfully now, for the case of  
accidents, using large checksums.  If the checksum is secure then it  
also does it for the case of malice.  In contrast a MAC doesn't do  
"end-to-end" integrity checking.  For example, if you've previously  
allowed someone to read a filesystem (i.e., you've given them access  
to the key), but you never gave them permission to write to it, but  
they are able to exploit the isses that you mention at the beginning  
of [1] such as "Untrusted path to SAN", then the MAC can't stop them  
from altering the file, nor can the non-secure checksum, but a secure  
hash can (provided that they can't overwrite all the way up the  
Merkle Tree of the whole pool and any copies of the Merkle Tree root  
hash).


Likewise, a secure hash can be relied on as a dedupe tag *even* if  
someone with malicious intent may have slipped data into the pool.   
An insecure hash or a MAC tag can't -- a malicious actor could submit  
data which would cause a collision in an insecure hash or a MAC tag,  
causing tag-based dedupe to mistakenly unify two different blocks.


So, since you're tight on space, it would be really nice if you could  
tell your users to use a secure hash for the checksum and then  
allocate more space to the secure hash value and less space to the  
now-unnecessary MAC tag.  :-)


Anyway, if this is the checksum which is used for dedupe then  
remember the birthday so-called paradox -- some people may be  
uncomfortable with the prospect of not being able to safely dedupe  
their 2^64-block storage pool if the hash is only 128 bits, for  
example.  :-)  Maybe you could include the MAC tag in the dedupe  
comparison.


Also, the IVs for GCM don't need to be random, they need only to be  
unique.  Can you use a block number and birth number or other such  
guaranteed-unique data instead of storing an IV?  (Apropos recent  
discussion on the cryptography list [2].)


Regards,

Zooko

[1] http://hub.opensolaris.org/bin/download/Project+zfs%2Dcrypto/ 
files/zfs%2Dcrypto%2Ddesign.pdf

[2] http://www.mail-archive.com/cryptography@metzdowd.com/msg11020.html
---
Your cloud storage provider does not need access to your data.
Tahoe-LAFS -- http://allmydata.org

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

Re: Security of Mac Keychain, Filevault

[Steven Bellovin]

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.


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?


One way to judge is by reputation.  If, say, Adi Shamir says it, I'm  
very inclined to believe it, even without wading through the technical  
details.  If the posting comes from a notorious crank, I'll likely  
discard the message unread because cranks tend to misread technical  
papers.  If it's someone I've never heard of, I have to make the  
decision based on the evidence presented and what I already know.   
What was the evidence here?


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.


Beyond that, we're left with *no* new information.  What basis does  
this article give us to conclude that Filevault is -- or is not --  
insecure?  I have no more reason to trust it or distrust it than I had  
before reading that article.


A proper evaluation of Filevault would, of course, be a good idea.   
But that statement is equally true after the article as before.



--Steve Bellovin, http://www.cs.columbia.edu/~smb





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

Re: deterministic random numbers in crypto protocols -- Re: Possibly questionable security decisions in DNS root management

[Bill Frantz]

zo...@zooko.com (Zooko Wilcox-O'Hearn) on Thursday, October 29, 2009 wrote:

>I'm beginning to think that *in general* when I see a random number  
>required for a crypto protocol then I want to either  
>deterministically generate it from other data which is already  
>present or to have it explicitly provided by the higher-layer  
>protocol.  In other words, I want to constrain the crypto protocol  
>implementation by forbidding it to read the clock or to read from a  
>globally-available RNG, thus making that layer deterministic.

One concern is that if the encryption key is deterministically generated
from the data, then the same plain text will generate the same cypher text,
and a listener will know that the same message has been sent. The same
observation applies to a DSA signature. If this leakage of information is
not a problem, e.g. the signature is encrypted along with the data using a
non-deterministic key, then there doesn't seem to be anything obvious wrong
with the approach. (But remember, I'm far from an expert.)

Cheers - Bill

---
Bill Frantz|"After all, if the conventional wisdom was working, the
408-356-8506   | rate of systems being compromised would be going down,
www.periwinkle.com | wouldn't it?" -- Marcus Ranum

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