Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Robot CA: toward zero-UI crypto

By Kyle in Technology
Tue Nov 19, 2002 at 04:26:55 AM EST
Tags: Security (all tags)
Security

A Robot CA is an automated key signer. Conceived by Phil Zimmermann, the robot's signature indicates only that the user's email address is correct, not that the name on the key correctly identifies the user. Given a key signed by the Robot CA, you can be sure that the email address on it really can read email encrypted with that key. This casual verification can be used as part of a larger scheme to make encryption easier for users who wouldn't otherwise benefit from it.

I'm writing about the Robot CA because I've created one.


The problem with strong verification

Getting a reliably verified signature on a PGP key is difficult, and most people don't do it. Many of the keys I see from people I've "run into" on the net have no signatures on them at all. Since I won't trust such a key, they might as well not have a key. By demanding good trusted signatures, I'm eliminating the possibility of private communication with someone whose identity I can't verify.

If I knew only that the key went with the email address, that would be an improvement. I don't care if the key really belongs to name on it as long as I can communicate privately with the owner of the email address.

A system where weak verification is better than none

Imagine a system where key management is done in the background without user intervention. When you install a mail reader, it generates a key for you with your name and email address on it. It submits this key to a robot CA, and the robot responds with a signature. The mailer takes the signed key and publishes it to a key server for other mailers of its kind to use. The signature on the key means only that the key goes with the email address on it.

When the user tries to send mail to some address, the mailer automatically checks to see if there's a public key for that address. If there is, it checks to see if the key has been verified by a Robot CA. If it has, then it uses the key to encrypt the outgoing email. The users get some benefit of encryption without having to think about it.

Without the robot in this scenario, a malicious user could create a key with the victim's email address on it and send it to the key server. Then users who were auto-encrypting would send the victim messages encrypted for a key the victim doesn't have. With the robot, this simple attack is foiled. The mailer won't use a key that hasn't been verified by a robot. If the attacker submits the fake key for verification, the signed result will go to the victim. The victim's mailer can then ignore it because it knows it doesn't have the private key to go with the attacker's signed public key.

Real verification is still better.

This is no replacement for the traditional web of trust, but it will work nicely with more advanced users who want to use the more traditional methods. If Alice likes trust the way it is, she doesn't have to trust the robot's signatures. She continues to work the way she did before the robot existed. She can still have her key signed by the robot, and she will receive encrypted mail from those who do. Additionally, if Bob has been doing all his crypto in the background without thinking about it, he can still "graduate" to the more advanced methods of key management if he wants to.

Central authority Bad! Decentralization Good!

This minute, there's only one robot CA, so it's a central authority. Ideally there would be many, and no one wold be a central point of failure. ISPs could run them as a service. Given many trusted robots, their public keys could be included on the read-only installation media for mail software and operating systems. This would prevent an attacker from masquerading as an authority.

How it works

The basic design and operation of the Robot CA is simple. It receives a public key block by email (it could use CGI in the future). It looks at the UID(s) on the key, searching for an email address. It aborts if it can't find a valid email address in the UID. Then it signs the key, and emails the signed result to the email address it found. If the mail bounces, it ignores it. If the mail gets through, the user has a copy of their own public key with the robot's signature. The user can then import the new signature and update a keyserver with it.

The one I've written has some limits detailed on the Robot CA's home page. In particular, it can't deal with MIME encoding, and I haven't attempted to support PGP2. Still, I think it's a step in the right direction.

My hope is that this will make encryption more accessible to ordinary users, and ordinary users' email less accessible to snoops.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Robot CA
o Useless! 8%
o A good idea, but no one will use it. 40%
o Just a bad idea. 4%
o Fabulous! 11%
o Phil Zimmermann said it, so it must be good 14%
o It'd be fine if it didn't abbreviate to 'RCA' 19%
o Crypto stinks anyway 1%

Votes: 62
Results | Other Polls

Related Links
o Phil Zimmermann
o a reliably verified signature
o PGP
o web of trust
o Robot CA's home page
o Also by Kyle


Display: Sort:
Robot CA: toward zero-UI crypto | 35 comments (26 topical, 9 editorial, 0 hidden)
question (4.50 / 2) (#7)
by tps12 on Mon Nov 18, 2002 at 03:50:22 PM EST

When you install a mail reader, it generates a key for you with your name and email address on it. It submits this key to a robot CA, and the robot responds with a signature. The mailer takes the signed key and publishes it to a key server for other mailers of its kind to use. The signature on the key means only that the key goes with the email address on it.
What do I do when I get encrypted mail that I want to read from a different computer?

depends (4.00 / 1) (#15)
by nex on Mon Nov 18, 2002 at 05:43:29 PM EST

this problem applies to encryption in general, not just to whet the article describes. if you trust the other computer a lot, you install your crypto software and import your private key (it will still be protected with your passphrase). alternately, if you trust it somewhat, you can connect to your own machine over SSH and just read your mail over the secure shell. if you don't trust the other computer at all (suspect a key logger that would get your passphrase), you obviously can't use it to read secure mail.

[ Parent ]
right (3.00 / 1) (#18)
by tps12 on Mon Nov 18, 2002 at 06:46:21 PM EST

So client-side message encryption doesn't seem to be feasible without losing either the flexibility of unencrypted email systems or the zero-UI aspect of both unencrypted systems and this proposal.

[ Parent ]
more ideas (3.50 / 2) (#21)
by nex on Tue Nov 19, 2002 at 05:41:11 AM EST

While flexibility is technically correct, I think the term is misleading. If you want a snail mail message that only the recipient should read, you will put it in an envelope instead of using a postcard. The letter will be more expensive to send and require more preparation, because you haev to make sure you have an envelope to put it in. However, no one would say, "I lose flexibility when sending letters." Instead, people are used to making sure they have soem envelopes at home and take a few with them when they go on vacation so they won't have to look for them on a Greek island or wherever.

Likewise, you have to make some preparations if you want secure e-mail from any computer, not just your own. For example, you could set up a shell account with e-mail and encryption software and use it like a web mail account -- no need to carry your e-mail around with you, it's all there, no matter from where you open it. SSH should be available on every computer you ever use.

For some (really paraoid) people it might make sense that they put a tiny Linux distribution on a floppy or a bootable CD-ROM, so they can use really untrustworthy computers by booting them into their own OS. They'd just have to check for hardware keyloggers. And put a radiation shield around the CRT, so it doesn't beam the signal, and thus the displayed text, out onto the street :-)

What you also can do when you take a CD-ROM with your crypto softare and your private key (still protected by your passphrase, maybe hidden in an image via steganography) around is access your e-mail as usual, via a web interface or any client. It will arrive as usual, the message will just be scrambled if it is encrypted. So you just drag/copy (via clipboard) the encrypted text to your crypto software, it decypts it and you can read it. Sending works just the other way round. This process involves having you rprivate key in a foreign machine's RAM. I wouldn't have a problem with that if it's the machine of a good friend. Otherwise you can resort to booting it to your own system.

This is all much more work than sending postcards, at least until everything is set up nicely and you're used to it. However, you have to bear in mind that TANSTAAFL, you can't improve your security by orders of magnitudes for free.

[ Parent ]

Smart Cards (5.00 / 1) (#29)
by BlckKnght on Wed Nov 20, 2002 at 01:12:14 AM EST

One solution to this problem is to put your private key onto a smart card.

When you want to decrypt a message from an insecure system you put the card into a smart card reader (after authenticating the card with a PIN or biometric data or something to secure against physical theft). The steps of the encryption algorithm that requre knowledge of the secret key are done on the card itself, not on the untrusted computer.

Of course, this won't prevent a trojaned system from stealing the plaintext of the message you decrypted. However, only that message is lost, since the secret key is remains secure the whole time.

The developers of GNU Privacy Guard are developing software to do exactly this kind of system as part of the Ägypten project. (After looking around that page a bit, it looks like the smart cards won't actually hold the keys, but rather have their own token granting protocol. I think it works out the same, just with an extra layer of indirection.)

-- 
Error: .signature: No such file or directory


[ Parent ]
interesting (none / 0) (#31)
by nex on Wed Nov 20, 2002 at 10:43:26 AM EST

Very interesting link! Considering that an overwhelming majority of e-mail users doesn't think about authentication/encryption at all, I guess it will take quite a while until convenient methods like smart cards (that require a certain ubiquity of smart card readers) will become practical.

[ Parent ]
Smart cards... (none / 0) (#32)
by Znork on Thu Nov 21, 2002 at 07:15:08 AM EST

... are certainly a problem. Frankly I doubt we'll have compatible smart card readers everywhere even in a decade.

Maybe it could be replaced with an USB device instead tho. Or some other form of peripheral connector that actually is readily available.

[ Parent ]

new geek accesory? (none / 0) (#33)
by nex on Thu Nov 21, 2002 at 09:09:00 AM EST

This is an excellent idea! Actually a small USB smart card reader that you can carry along would be a nice compromise. With a clever design (it just has to attach to the card somehow, you don't have to be able to put the card into it), you could surely make on that is as small as those key-chain USB 'drives'.

[ Parent ]
Does this really do anything? (4.50 / 2) (#8)
by Lizard on Mon Nov 18, 2002 at 03:56:15 PM EST

I'm not sure if the way you setup the system you can even verify that the key belongs to the owner of the e-mail address. The robotCA cannot protect against my e-mail address being presented as a PGP key ID by a third party who has the ability to intercept and divert my e-mail before it is delivered to my mailbox. I might not know about this if the third party decrypted the messages and delivered them to my mailbox without signatures or encryption.
________________________
Just Because I Can!
Not news (4.00 / 2) (#10)
by Kyle on Mon Nov 18, 2002 at 04:18:05 PM EST

That's true, but you have the same problem without the robot too. You also have the same problem without encryption. The way to avoid the problem you describe is with good key validation, which is difficult.

If the scenario you describe happens with half of all the users (that would be astonishingly high), you still get half of the users with more privacy than if they hadn't used the system at all. The down side is the other half think they have privacy when they don't. Again, this is not much worse than now.

[ Parent ]

I think that it's a lot worse (4.33 / 3) (#17)
by Lizard on Mon Nov 18, 2002 at 05:52:48 PM EST

I think that it's a lot worse to have broken security than it is to have no security at all. At least with the current system of encrypting nothing in e-mail I know what the risks are and can make an informed decision as to what I am willing to send in e-mail and what I am not willing to send in e-mail. If I were lead to believe that e-mails I send could only be read by the intended recepient I would be likely to send some things I would not otherwise send via e-mail.

This is why key fingerprints should be confirmed via an alternate path. I'm sure that there is a way that this could be accomplished via an automated system, I'll think about it a bit and post again later. The way it stands now, the robotCA signatures should not be trusted at all since the robotCA never verifies key fingerprints with their owner.
________________________
Just Because I Can!
[ Parent ]

Trust is not absolute. (3.33 / 3) (#20)
by Kyle on Mon Nov 18, 2002 at 07:52:38 PM EST

I've talked to email users who were shocked to learn that their sysadmin could read their email. There will always be ignorance about security for those who do not educate themselves. I propose we give those people as much security as we can without requiring education.

[ Parent ]

Without education? (3.00 / 1) (#23)
by AtADeadRun on Tue Nov 19, 2002 at 10:51:37 AM EST

Security doesn't work without education. If the victim doesn't know what can happen, how can he/she take proper precautions to prevent it? I agree with Lizard; broken security, where the user thinks the system is taking care of it, contrary to fact, will worsen the problem, not improve it.

-------
Pain heals. Glory is forever. Keep running.
[ Parent ]
Proper security. (4.00 / 1) (#24)
by Kyle on Tue Nov 19, 2002 at 12:26:47 PM EST

You can try to educate users, and that's certainly the right solution. For educated users, there are already good tools for email privacy. By that standard, there's no more to be done. However, if you look around, there's so much less security than there could be, even though the tools are available.

The problem is that users aren't educated, and most of them don't want to be. They want it to work without them having to think. Given a user who won't ever get an education, which do you choose? Less security, or more?

Using a scheme where encryption is automatic improves the situation for the majority.

[ Parent ]

Two points (2.50 / 2) (#19)
by Sloppy on Mon Nov 18, 2002 at 07:13:55 PM EST

One: The idea is, hopefully you get your key signed before They start redirecting your mail. Do this now, and then piss off the mafia/government/aliens.

Two: Don't assign a very high degree of trust to this robot, since he's obviously a very loose validator. That's perfectly fair. But if I have someone's key that is signed by this dumb robot, I still feel safer about it than having someone's key that isn't signed at all.

A low-trust link is better than no link at all. You just have to remember that it's low-trust.
"RSA, 2048, seeks sexy young entropic lover, for several clock cycles of prime passion..."
[ Parent ]

Well, ok... (4.75 / 8) (#11)
by trhurler on Mon Nov 18, 2002 at 04:57:19 PM EST

But a problem occurs to me. If all you want is privacy with no authentication whatsoever, you don't need key signing. If I send you a public key, regardless of whether it is signed, you can follow a simple procedure to determine my possession of the private key. Take a secret message, encrypt it with the public key, and send it to me. I must decrypt it, encrypt a sensible reply with the public key you gave me, and send that back. If you then successfully reply, then we both know that our keying scheme works. The problem is, we don't know that there are only two of us, or that our messages are arriving unaltered, or that the other end is anyone in particular.

This is a solution to a problem nobody really needs a solution to. If the other party's identity doesn't matter to you, then the secrecy of your communication doesn't matter either, by definition.

If this is just an attempt to keep people from using tools like Carnivore, then why not just do the obvious thing and produce an encrypted mail transport protocol in which intermediate servers cannot reconstruct the original text? This isn't all that hard, and it moves all the work away from users and onto administrators, who will get it done properly much sooner anyway.

--
'God dammit, your posts make me hard.' --LilDebbie

Yes and no. (4.50 / 6) (#12)
by Kyle on Mon Nov 18, 2002 at 05:17:49 PM EST

If I send you a public key, regardless of whether it is signed, you can follow a simple procedure to determine my possession of the private key.

You can do that, and it will work about as well as this does. The thing is, I don't want to go to all that trouble with everyone I communicate with. The robot does the same job just once so that all the users don't have to. In an earlier story I posted, I discussed other systems that work (automatically) in about the way you describe (so it's no pain for me). That's good too, but it's more high bandwidth than the robot solution.

[ Parent ]

The only robots I give a flying shit about (1.19 / 47) (#13)
by Hide The Hamster on Mon Nov 18, 2002 at 05:21:50 PM EST

are Pure Sex Robots which fuck you in your ass until your colon bleeds. -1


Free spirits are a liability.

August 8, 2004: "it certainly is" and I had engaged in a homosexual tryst.

Now a new thing (4.50 / 2) (#22)
by agl on Tue Nov 19, 2002 at 08:47:33 AM EST

I've had one of these running for ages: http://www.imperialviolet.org/keyverify.html

Link for the lazy. (4.00 / 1) (#25)
by Kyle on Tue Nov 19, 2002 at 12:34:24 PM EST

ImperialViolet Email Verifier

I haven't tried it, but from the web page, it uses a longer process.

  1. The user must put the key on a key server.
  2. The user must email the verifier with the key ID.
  3. The user must reply to an email sent by the verifier.
  4. Then the user gets a signed key.

The process with mine is shorter.

  1. The user must email a public key to the verifier.
  2. The user gets a signed key.


[ Parent ]
Does this get around the interception problem? (4.00 / 1) (#26)
by AndyDeck on Tue Nov 19, 2002 at 02:03:45 PM EST

Does the ImperialViolet 4-step process help with the above-mentioned interception problem?

In other words: with RobotCA, an attacker who can intercept your mail generates a fake public key with your email address and submits it to RobotCA via email, and then intercepts the signed response.  If the attacker can truly intercept responses, there is no trace left for you that this has occurred, as RobotCA does not maintain a public log of signed keys.

With the ImperialViolet method, the fake key is submitted to a key server, leaving a broader audit trail.  The user must also generate two emails to the verifier, one as a reply to an email from the verifier.  Yes, that's more steps for the user, but that could be used by the verifier to more fully validate the user.

Hrm.  Given the assumption that an attacker can invisibly intercept a user's mail (i.e. the attacker receives the mail but the user does not), then I don't think that an automated key-signer of this type can protect against that attack.

But I'm not convinced that this is a valid attack against either method.  How likely is such an attack?  It would require a compromise at either an intermediate SMTP host, or at your own ISP if you have hosted POP/IMAP/WebMail.

[ Parent ]

The interception problem is still there. (4.00 / 1) (#27)
by Kyle on Tue Nov 19, 2002 at 02:17:55 PM EST

I think you are correct that if an attacker can intercept the victim's email, both methods will fail the same way. In a sense, if the attacker can intercept the victim's email, the verification is working--the attacker does have access to that email address, and that's all the robot is trying to find out. From the robot's point of view, there's no difference between this and two (or more) people who legitimately and knowingly share an email address.

It's true also the ImperialViolet method requires the user to publish the key to a key server and so leaves a larger trail. However, for the broader scheme of easy crypto to work, an attacker using the robot would have to publish the fake (signed) key anyway.

You mention the robot keeping a public log of signed keys, but I can't tell if you're suggesting it's a good idea. The problem with doing that is that when the robot sends its email, it doesn't know whether a signed key is really valid. It relies on a delivery failure to eliminate invalid signatures.

[ Parent ]

Robot log ~= key server (3.00 / 1) (#28)
by AndyDeck on Tue Nov 19, 2002 at 02:25:10 PM EST

One purpose of a public log on the robot would be as an audit trail, but a better one would be to act as a repository / key server.  It seems to me to be a good fit, as it would specifically isolate these low-validity auto-signed keys, so that users could make their own determination on whether to use them or not.


[ Parent ]
trust (5.00 / 1) (#30)
by F a l c o n on Wed Nov 20, 2002 at 06:05:24 AM EST

Actually, I strongly believe that the whole web-of-trust is a mistake. Not conceptually, but when taken in a real-life environment.

I've yet to see it work somewhere.

Here's what I do instead: When I get a key that I care about, I try to verify it with its owner and using a different channel. For example, you call the guy.
While this does not give you perfect security, as any TLA is surely able to reroute phone calls to a voice impersonator, you must remember the threat model. This is for personal privacy. If I were conspiring against a government, I would surely go to more lengths to verify the key.

In the end, the web-of-trust has one problem: It's overkill for most people, and those who need trust are better of trusting no one but themselves anyway.
--
Back in Beta (too many new features added): BattleMaster

keystory (none / 0) (#34)
by ftobin on Fri Nov 22, 2002 at 11:40:55 AM EST

RobertCA is a good idea, since I feel that more ad-hoc solutions to the WoT need to take place to make it useful. Given similar problems with getting a 'good' pgp WoT, I've implemented keystory, which also provides uses with 'weak' verification of which keys a person with a particular email address uses.

keystory works in two stages. First, you feed it a emails (mbox or individual messages) which have signed messages, and keystory builds up a databaes of which keys 'From' addresses have signed with, and when. Ideally, you feed keystory messages from a public forum (e.g., well-known mailing list) where the number of instances of people posting under others' addresses are going to be low. The second step is querying keystory for what keys an address has used, produces simple reports of what keys and when.

I have a web interface to keystory available, with data gathered from gnupg-users and gnupg-devel.



Interesting (none / 0) (#35)
by Kyle on Fri Nov 22, 2002 at 01:40:11 PM EST

I want to add some web interface to the Robot CA, just to submit keys (without email). Of course, the CGI will probably just do the emailing for you.

Your keystory reminds me of another idea I ran across while looking into the robot. The suggestion there was basically to build up historical data on a key's usage and sign it when it reaches some threshold of usage. That way, a key gets signed automatically when you see it used a lot.

[ Parent ]

Robot CA: toward zero-UI crypto | 35 comments (26 topical, 9 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!