huge keyrings (was: id matching)

[Brian Warner]

walterk at dip.de (Walter Koch) writes:
WK> Good idea to keep the secretkey in a box with you. Palm Pilot is
WK> widely spread. And someday the pilot can speak to every computer via
WK> IrDA. 
WK> But i do not want to transmit my secret keys to any computer i work
WK> with. Maybe his OS is tampered with a trojan or sth.
WK> So the solution would be a gnupg for pilot. AFAIK there is a gcc for
WK> pilot. This would be a little slow, but it would be very handy ...
WK> 
WK> comments?

Actually, there's already some form of OpenPGP for the pilot; somebody on the
working group mailing list hacked something together with the SSLeay pilot
library. Haven't played with it at all, though. I think replay.com has it in a
file called "palmopgp12.tgz". Sounded like some good ideas from what I read:
keys were kept in address book records, so you could give your public key to
someone by just "beaming" your own record to them.

I was thinking about some intermediate step between A) doing everything on the
computer and B) doing everything on the Pilot. Let's call the pilot the
encryption agent (since it could be an iButton or a more-secure laptop or any
device capable of doing some math and communicating with the main "computer"
but which is smaller and therefore considered more secure). For signatures,
you send the message hash over to the agent and it sends back the signature
packet. For decryption, you send the encrypted session key packet to the agent
and it sends back the decrypted session key. A tradeoff of convenience (and
speed: the Pilot is not very fast, the iButton even slower) for total
security. Actually the security of doing everything on the agent isn't total:
you then have to worry about being tricked into sending/fetching your document
from something that isn't a agent (send the message to /dev/ttyS0 for
decryption, and something comes back, but your agent was on /dev/ttyS1.. who
sent that message? how do you verify that?).

If only secret key operations take place on the agent: what could be
compromised? (suggestions on this kind of analysis are more than welcome: I'm
just winging it here):

threat: somebody replaces your agent with their fake program (attempt to trick
the computer by spoofing the agent)

compromise: decryption: you send an encrypted session key to them, which they
can't do anything with anyway (it was part of the original message, which
an eavesdropper could get without the agent).

compromise: signature: you send a message hash to them, which doesn't tell
them anything useful about the message. They can sign it with the wrong key,
which would be annoying (so you must verify the signature right away), but
they can't fake a good sig.


threat: somebody steals your agent or subjects your agent to a different
program (attempt to trick the agent by spoofing the computer)

compromise: more serious. You'd need some kind of session verification: the
computer-side GPG sends a request to the agent and also computes a hash of the
request and displays it. The agent (if possible) displays the same hash and
requests verification from the user (out of band) before performing the
requested encryption. This won't help for an iButton: but since they can be
considered "tamperproof" you could probably have the iButton have a
private/public key and a list of public keys that are allowed to make
requests. The request could be encrypted (preventing anyone from faking the
agent) and the request could be signed (preventing anyone from faking the
computer). But then the agent would be doing at least two operations.. starts
to sound ugly.

threat: somebody listens to the communication between your agent and the
computer doing the rest of the encryption/decryption.

compromise: decryption: the eavesdropper gets the decrypted session key. If
they got the original encrypted message too then they can decrypt that one
message. The compromise is limited to that one message.

compromise: signature: they can see the signed message hash, but that is put
into the final message anyway. If the message is then encrypted they might
have a little bit of known-plaintext to work with (encryption occurs after
signatures, right?).

sen_ml at eccosys.com writes
SEN>need to be careful of 'syncing' your palm device as that may end up
SEN>depositing secret key information on a networked computer (or even
SEN>non-networked computer which isn't guarded most/all of the time).
SEN>
SEN>i don't suppose there is any hardware/software support in the palm
SEN>device for 'protecting' data from being synced?  (but then, what if
SEN>the data on your pilot gets wiped? -- there should be a backup on
SEN>some other media in a safe somewhere? -- and, do you trust potential
SEN>syncing protection mechanisms that may end up being non-open-source?)

There is a flag for each database (dmHdrAttrBackup) that says "back me up with
the default conduit [straight dump of the database structure] if no
application-specific conduit is available". I believe that if you leave this
flag off, the standard HotSync program will not back up the database. I think
the common unix backup utility (pilot-xfer) ignores the flag and copies
everything, and a malicious program can use RPC calls to do whatever it wants.
So be careful what you plug into that Pilot when you hit "HotSync"... :)


Anyway, I think this might be a useful thing. It might let me use my real
private key at work instead of having separate work and home keys, in which
anyone with root at work could spoof my work identity.

Thoughts?

 -Brian
  warner at lothar.com