Security of Mac Keychain, Filevault

[Jerry Leichter]

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

> ----- "Jerry Leichter" <leichter at lrw.com> 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 majordomo at metzdowd.com