On Tuesday, July 30, 2002, at 01:32 , Curt Sampson wrote:
>> Likewise on a mobile, you would protect your private key with a
>> PIN2....
>
> But your private key is on a completely different system! Presumably
> your laptop, where's it's protected with a passphrase. And if you
> can unlock your private key, you could then use that to authenticate
> yourself to the mobile device, and the PIN2 is an unnecessary alternate
> access method.
I would consider both the phone and the notebook to be equivalent to two
people communicating via pgp mail, each have their own private key.
The private key of the notebook is only on the notebook and protected by
the passphrase. The private key of the phone is only on the phone and
protected by PIN2.
If you loose your phone, then that is like getting an email from a
correspondent telling you that they have lost their key and that they
revoked it, so you should not trust that key anymore. Now, if you happen
to get a message encrypted or signed using that key, you can still read
it without compromising the security on your system, but if the content
in the email you are getting tells you to do something (like "sell all
XYZ shares at NN pennies") then you turn deaf and do not carry out those
instructions because you know the authenticity of the email cannot be
trusted anymore.
If the finder/thief of the phone however does not have the PIN2, nor the
associated PUK2, then they would not be able to disable the trust put in
the key of your notebook and thus, you will be able to access that phone
remotely and tell it not to allow outgoing calls, start an alarm to tell
bystanders that the phone is lost or stolen, or whatever else there may
be.
Likewise, if you loose your notebook, you could use PIN2 to tell the
phone that any administrative access to the phone using the notebook's
key is no longer authorised, but the finder/thief would need your
passphrase in order to disable your phone's access to the notebook,
unless they wipe it completely of course.
>> However, you do know that exhaustive search on a PIN will render the
>> phone unusable and you will need a PUK to unlock it (likewise PUK2 for
>> PIN2), don't you ?
>
> Of course. Now try to explain that to the consumer. ("I'm sorry--you
> can't use your video camera until you take it to an authorized service
> center. And that's not Bic Camera, because we sure as heck can't trust
> them with keys to unlock every device we've manufactured.")
Wouldn't happen that way. The camera will have its own private key in
order to be able to let your notebook gain administrative access to it
using the notebook's own key, but I would not expect the camera to be a
device that should or even could have administrative access to the
notebook. Anyway, on your notebook, you will be able to change the trust
for the camera's key and only allow it to upload pictures if you give
your explicit OK for each connection for the time being (while you don't
know where the camera is and who is using it). If the finder/thief of
your camera wants to keep it and disable your notebook's administrative
access to it, then again, you will need a PIN2/PUK2 on the camera in
order to change the trust for various keys which have administrative
access assigned.
In any event, you don't need to contact the manufacturer, unless you
have lost both PIN2 and PUK2.
>> I am not so sure I understand your scenario. First, I would not
>> expect a
>> camera to have any keys that grant administrative access to another
>> device.
>
> It's going to have to have *some* way of authorizing access that lets
> you
> change the keys that can, say, clear the memory of all pictures. Or just
> look at what's coming in through the lens right now, and take snapshots.
But that is inbound not outbound (relative to the camera). I don't think
you would want your camera to be authorised to have root access to your
notebook and invoke "rm -rf /" ?!
As far as inbound admin access to the camera is concerned, you would use
PIN2 of your camera to register (and remove) your notebook's and phone's
keys and assign trust to allow (and disallow) such access.
>> So if you loose the camera then you run the risk that the finder/thief
>> will be able to upload photos into your computer without asking your
>> permission, unless you remove the authorisation for the camera (based
>> on
>> the camera's keys) from your computer. That would seem reasonable to
>> me.
>
> Oh, you're putting a key in the camera that gives it access to your
> laptop?
> And you're going to type a passphrase into the camera every time you
> want
> to upload photos? Well, let me tell you, most people won't go for that.
No, you only need to confirm PIN2 on the camera for key management, not
for uploading photos/movies (jailed to a predefined upload folder on the
receiving device). However, users paranoid about having the camera
stolen, may enable a PIN (not PIN2) to use the camera whenever you
switch it on, perhaps with a timeout of 24 or 48 hours.
Over time it is reasonable to assume that other authentication methods
than PINs will evolve. For example fingerprint readers or voice
analysis. And as a camera already has a lens and a CCD built-in it may
eventually have a feature to recognise you by your face based on the
various unique fix points and plus a heat print of your face (which can
even distinguish identical twins).
>> If you loose your camera and remove the authorisation for it from your
>> computer, then find the camera, you may simply start over and exchange
>> keys between camera and computer again,
>
> Please explain to me in detail how you exchage keys between the computer
> and the camera. Because this is the biggest point I have a problem with.
Similar to the way you exchange pgp public keys for pgp mail today. Both
parties can send a public key over an insecure connection and use a key
fingerprint to identify whether the key received matches the key sent.
The camera would display the fingerprints of sent and received key on
the LCD display while the corresponding device does the same. That way,
when you exchange the keys you can verify on both devices whether the
keys are the ones you expected.
>> Of course, somebody could observe you when you are
>> about to press the button on device A to initiate the request and in
>> that very moment initiate a request from their own device C in the hope
>> that they'll get lucky and you authorise the request of device C in the
>> belief that it is device A that you give your OK to.
>
> Or they could just construct a device that can listen to what's going
> on around it and do this automatically. By current technical standards,
> this is dead easy. People crack stuff harder than this all the time.
Yes, but keep in mind that the above is not making use of any
encryption/certification. It is -if you want- convenience mode. In such
a convenience mode arrangement, I would not expect any device to have
any more access than upload of pictures/music into a predefined folder
while being jailed to that folder.
If you have sensitive fotos that you would want to rule out the
possibility that they fall into anybody else's hands, then you should
use a PKI based mode and you have to exchange keys between devices as
described above.
For most consumer needs it may however be sufficient to use a
convenience mode by which you have to explicitly confirm any 'dangerous'
actions being requested from another device.
It doesn't really matter which device really connected to your camera if
any dangerous action such as 'wipe all fotos' will first pop up a dialog
on the camera 'do you really want to wipe all fotos?'.
>> And I am not going to describe any detailed scheme in public. IPR,
>> prior
>> art and all the rest of it.
>
> Oh, do they?
does who ?
> References, please.
As I said, I won't.
> Ben, I'm suspecting at this point I know a heck of a lot more about
> crypto than you do (though I am far from an expert), so why don't you
> take my word for it instead?
[smiling to myself in silence]
>> What I can tell you is that your phone service provider plays a role in
>> the key management and the trust model need not be as complex as that
>> of
>> PGP because of it. Enough said.
>
> Ha ha! I have only one word (or rather, acronym) for this: PKI.
Sure, that's the base. The wheel which obviously need not be reinvented.
However, wheels can be utilised in various different ways in order to
make other things tick.
> do you know of
> some PKI infrastructure that's actually widely deployed and working well
Stop the rhetoric - cut through the chase ...
You don't want to tell me that PKI based schemes cannot work in a
consumer context.
Let's assume for a moment that PGP had been around before GSM and the
awareness we have today would have been there when GSM was designed,
further that at the same time all the uncertainty around using PKI
legally would have been absent.
The GSM designers may have well chosen PKI instead of a secret
algorithm, at least for authentication. As a result, we would have
widespread PKI use in mobile phones today. And the fact that mobile
phone companies issue SIM cards makes key management seamless. After all
GSM does use keys for authentication and encryption and the fact that we
don't even think about it shows that key management can be made seamless
on devices which depend on a service provider to work. Get a SIM card -
have your key. Have your key revoked - loose function.
I can't see how replacing A3/A5 with PKI would change the seamlessness
of key management.
regards
benjamin
Received on Tue Jul 30 09:33:26 2002