E-Mail Clients That Support X.509 Digital IDs?
"I have already checked a previous Ask Slashdot on this, as the title would suggest being close, but it seems to be more about sending anonymous e-mail through a secure POP/SMTP connection for an ISP which is a tad different and a tad more complicated than my needs.
In my particular case, I have this Digital ID that confirms that any mail a recipient gets is actually sent from me. The way it works, every time I send mail, it pops up a dialog and asks for my password. After confirmation, it encrypts the contents and attaches a security certificate that the recipient can view to confirm authenticity. In this way, even someone on my machine can't send mail as me. The certificate allows me to encrypt mail also, so only people that have my specific key can read it. It has several other useful features as well. (Here's a quick FAQ link)
I have to do this because, at work, I deal with about 100 developers that live in an unnamed former Soviet bloc country, and are QUITE security concious. The Verisign DigitalID allows them to be sure that the mail they are getting comes from me. It's quite cool, and I would LOVE to have this capability in Linux. Unfortunately, there seem to be no solutions to this problem, at least none that are obvious."
$HOME/bin/smime_verify:
clear
openssl smime -verify -CAfile my-bundle.crt 2>&1 >/dev/null
$HOME/.muttrc:
macro compose S |smime_sign
$HOME/bin/smime_sign would be something like:
Tovris has a product which would let you send X.509 messages from any mail client that supports SSL. Platform independant.
The product is called the Mithril Secure Server and it acts as a proxy which sits in front of a mail server performing X.509 encryption/decryption on incomming and outgoing mail. A lot of ISPs are installing this in order to upsell managed security.
SSL authentication for IMAP/POP/SMTP is required to maintain security from the proxy box to the desktop. This is a very elegant solution which is packaged as a network appliance. Pretty much plug and play for any standards based email servers.
Check it out: http://www.tovaris.com.
Email sales@tovaris.com for more information on pricing, etc.
Yeah, but if they've got system-level control (ie BackOrifice or root), then even biometrics won't help, as you can override the reporting functions....
With X.509 it is allways crucial to have the root keys installed. And the Verisign ones are in the programs mentioned above. This minimizes the effort for the uninitiated.
It should not be so difficult to includet the PSE from Mozilla in s/w like Balsa, if they offer a generic way to manipulate the network connection before it is made.
But I allways had the impression that most coders in the free software arena prefer PGP, thus never took the time to write the code to support S/MIME and SSL.
The neccesary backend libraries are there (here for instance), but the integration and the GUI needed to make it happen in end-user software where never done. The good thing about the mozilla PSE is the fact that it has some concept of doing the GUI itself, only the integration has still to be done. If I only had more hours to the day B-)
Beside being more supported for email (ie: usable with more user agents on more platforms) I think that PGP should not have been a bad move for this particular case. Since there seems to be a limited number of identified recipients you can always generate your key, send the public key to the recipient by email and check the finger print by telephone.
S/MIME is more suitable to do secure email with the world since it does not require you to check the public keys (certificates) you receive with their owners. That's right but it does not really solve the problem, it only moves it somewhere else: instead of asking yourself I'm I sure that the key belong to whom it claims you'll have to ask can I trust the certification authority.
Look at the certification authorities in Netscape or Mozilla, there are dozens of them. Well I think I can trust Verisign, Thawte (ok it's the same) but can I trust the other ones? Can I be sure that they properly check the identity before issuing certificates? Sincerly I cannot tell.
In my opinion the biggest advantage of x509 over PGP is the possibility to use your personnal certificate not only to sign or crypt email but also to authenticate yourself on access controled web sites with the same key.
Check out Bruce Schneier's Crypto-Gram of a few months back for examples of how faith in biometrics is misplaced faith, at best.
PGP has a much simpler format and a default trust model which is much more secure. Unfortunately, the default PGP trust model generally requires a user to manually set up a trust relationship with every other individual. As a result the average person finds S/MIME much easier to use and that's what companies deploy. PGP seems to be relegated to techno-geeks, the paranoid, and people who really need strong security and got good advice.
Because PGP is not what the people he is communicating with have. It would appear that they want some of the features that Verisign provides as a part of this service (in particular the level 2 serivce looks interesting) I could easily see how using this to sign and PGP to encrypt would be a very usefull combo. In particular if it made your PHB fell better if someone was offering him money if it did not work.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Hate to say it, but that's not true. If you've got something like Back Orifice (or a keystroke sniffer, or even a shoulder surfer) on your machine, then the jig is up. You need to use something which incorporates biometrics in order to be really sure your communications are secure and identifiable. Heck, even a SecuurID is better than a plain password dialog.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
And get your terminology right: It attaches a digital signature( not a "security certificate") then it encrypts your message. only people that have my private ( not "specific" ) key can read it. Where did you get those term from anyway?
Bzzt! Sorry, no prize, but thanks for playing.
PKCS 7 does, indeed, attach a copy of the certificate to the message. It also attaches a copy of the MD5 hash of the body of the message, encrypted with the sender's private key. The receiver can then recompute the hash of the message he or she received and compare it to the value he or she obtains by decrypting the encrypted hash paylod with the sender's public key. They must match, or the message has been tampered with.
Finally - and here's why people use X.509 certs, - the MUA can resolve the certificate chain corresponding to the cert in the message. If each certificate in the chain was issued by its putative issuer, and if the root of the chain is trusted, then either the sender's key has been compromised, or the message is both authentic and valid.
PKCS 7 can, but is not required to, encrypt the message body itself. That is a somewhat more complicated process. In order to encrypt a message, it needs the public key of the known recipient. It then generates a cryptographically secure random number, and encrypts it with the receipient's public key. It then use that random number to conceal the contents of the message (using a standard symmetric algorithm). That body is then signed as per the unencrypted form, and the resulting envelope is sent.
It is left as an exercise to the reader to figure out why (a) the message is securely encrypted, (b) the resulting message is repudiable, (c) this all works without either party needing to know the other party's private key and (d) why the keys in each leaf (non-issuer) certificate can be, and are, thrown away after the cert is generated, so that the only copy left in existence is in the cert itself.
S/MIME is the way to do email with X509 certificates, and Netscape Communicator is one mail app which uses S/MIME.
You can manipulate S/MIME messages (encrypt, decrypt, sign, verify) using OpenSSL at the command line. I'd love to see mutt hacked to front-end OpenSSL smime the way it can with PGP.
There are those who would argue that X509 is evil, thanks to its strict hierarchical structure (where Verisign's root CA is the big daddy of everything), and that only PGP gives the power to the people -- but from a pragmatic point of view, X509 is everywhere thanks to SSL etc. and if you want to be able to do secure email with the world, S/MIME is the way to go. PGP is attempting to converge with the S/MIME standard in any case.
--
x.509 is typically used with a message format called S/MIME. Recent versions of Netscape Communicator have a facility for sending, receiving, encrypting, and decrypting S/MIME messages using x.509 certificates.
If you use a flexible mail program such as mutt, you can pipe your message through the openssl smime command. By canning openssl smime with the options -encrypt, -decrypt, -sign, and -verify, you can perform all the same operations you could with a client that supported S/MIME natively.