[145012] in cryptography@c2.net mail archive
Re: Security of Mac Keychain, Filevault
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Mon Nov 2 22:02:47 2009
Cc: Cryptography List <cryptography@metzdowd.com>,
Steven Bellovin <smb@cs.columbia.edu>
From: Jerry Leichter <leichter@lrw.com>
To: "Jeffrey I. Schiller" <jis@mit.edu>
In-Reply-To: <3012355.1111257201367638.JavaMail.root@dune1>
Date: Mon, 2 Nov 2009 20:41:04 -0500
On Nov 2, 2009, at 5:36 PM, Jeffrey I. Schiller wrote:
> ----- "Jerry Leichter" <leichter@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 =20=
like to be able to do with your iPhone/Touch/other smart phone require =20=
a key whose value is very difficult to calculate (e.g., just what =20
would you lose if someone could read all your mail?); and services =20
increasing bundle all kinds of things together under one password. =20
For example, all your Google services use the same password; and your =20=
Apple Mobile Me mail password is also the key to such things as you =20
contact list (if you sync it) and Back To My Mac (which I now disable, =20=
useful as it might be, for just this reason) and your iTunes store =20
account. You can dissociate some of these, directly or indirectly, =20
but the services assume they are tied together and don't work nearly =20
as well if you do that. The trend is for this to get worse, with =20
network-wide shared authentication via OpenID or whatever other =20
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 =20
design? Sure, *if* it's all implemented correctly, it maintains =20
*some* set of security properties. Do you even know what those are? =20=
I know I don't....
> Pick a good
> secret (high entropy) and you are good. Pick a poor one, well...
>
> However the iPhone=92s 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=92t 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 =20
vulnerabilities will be more and more of a problem. Remote wipe - =20
assuming it really destroys the data - helps against loss, but does =20
nothing against a deliberate, targeted attack, which can probably copy =20=
all the data within minutes. We need some new thinking here. One =20
possible approach, based on an idea IBM played with a couple of years =20=
back but that as far as I know never made it into a product: Build a =20=
Bluetooth-connected ring or key fob that must be physically quite =20
close to the device to keep it unlocked. IBM did this for laptops, =20
and just locked the screen. For a smartphone, you'd want the phone =20
and the fob to mutually authenticate, and then the fob would transfer =20=
a key that could be used to unlock critical data on the phone. When =20
the fob goes out of range, the phone wipes the key and all decrypted =20
data. One can certainly come up with attacks on this - even so simple =20=
as the smart mugger scenario: Give me your phone and your fob - but =20
it raises the bar, with minimal inconvenience in normal use.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
