Well the government would have to trust your key.... I said there would be details. How about this: You generate your key pair, and like with a Drivers License or Passport, you go to a Secretary of State, prove your identity, then they sign your public key with their signature key, without seeing the private one on your usb stick. Your signed and verified public key would be then put on the national id server(maybe along with a passport photo). If ssh works as it's supposed to, it would be tantamount to a big key-signing party, run by the government at it's offices.
If anybody wanted to see if you are who you say you are, they get your verified public key, and send you a message to see if you can decode it. Or put that key in some db, that thru the use of a browser-builtin or helper app, would verify you automatically when you go to a site, like ssh does with keys auth. The reason I like the key method, over some browser hash, is that this could work as an id system anywhere...at airline boarding, hospitals, etc. Instead of a USB keystick, they could even put it on a credit card type of thing, with your laser embedded photo on it. But on the planet I come from, they will give you subcutaneous implants with your private key on it. :-) When I use my computer, it says please put your left ziffer on the screen.
| [reply] |
Then the gov't can do a handy man-in-the-middle(MITM) attack. They can distribute a different public key for you, and intercept messages, decrypt them, alter them if desired and reencrypt them with your proper public key.
Of course if the whole cyphertext is signed by its sender, then the signature would be invalidated. But the same sort of MITM stuff to the signature.
If you are willing to compromise one key to spy, compromising two is no big step to take.
This problem exists anytime you have one big repository of public keys. The only defense I know of is to have multiple, independent key repositories.
| [reply] |
Isn't that problem addressed by you signing the government signed key, after they sign it? If they started floating fake public keys for you, you would be able to detect it, by randomly testing the public keys they send out. I'm sure a watchdog group could/would be setup to randomly test keys and investigate government shenanigans and public complaints.
Also the idea here is ID verification, NOT secure communication. If the government wants to forge the id of it's citizens, there is no stopping them. What's to stop them from issuing false passports and driver's licenses now? It boils down to someone has to be in a position of trust, and generally we assign that to the government. I trust Driver's licenses now as ID, and would trust them even more, if there was a DriverID Verification website, where I could see a photocopy of the valid license. I would prefer that website be run by the government so that it is under public scrutiny.... instead of fighting the lawyers at privately run sites, who may be corrupt or mob-related.
| [reply] |
Firefox and Opera both support client keys for SSL and TLS. I'm sure they are not the only browsers to do so, but I don't want to check all 9 other browsers on my desktops right now.
For email, Thunderbird and mutt support client keys. There's also built-in support for PGP/GPG in mutt to encrypt the email itself. I'm sure there are plugins for Thunderbird to do that if it doesn't already. Many servers can be configured to use TLS-encrypted sessions for MTA to MTA communications when available at the other endpoint.
It's typically considered the MTA's job to deliver the mail first and to concern itself with security second, which is an attitude that needs to change before any of this improves. It does little good to have SSL or TLS sending and receiving if the mail routing in the middle is in plaintext. Encrypting and signing the message at the endpoints with PGP/GPG and sending it through clear channels should offer whole-path protection up to the point where they are easily borken. AFAIK, it still takes quite some time to break a 2048-bit key for GPG.
| [reply] |
Here is a nice article on setting up an htaccess based client ssl certificate system. client ssl certs Now I have something to play with this afternoon. :-)It appears to be in line with your desire for different keys for each site, and is generated by the site and the access key is given to the client. I guess the weakness here is how you get the key to the client? It would have to be delivered personally to them, but in an office setting that would be easy. My envisioned model is slightly different, with a common public key that you use for all sites, that the server admin would retreive from a public server. Anyways, this look cool, I hope I can get it working.
| [reply] |