Slashdot Mirror
PGP Universal - Usable Email Security?
An anonymous reader writes "For years, noted cypherpunks such as Brad Templeton, Ian Goldberg (PDF link), Bram
Cohen, and Len
Sassaman (PDF link) have been calling for easy to use email encryption solutions
which involve little crypto comprehension on the part of the user. Now, it seems like someone has listened: PGP
Corporation has announced its PGP Universal, which says it 'shifts the burden of securing email
messages and attachments from the desktop to the network in a way that is
automatic and entirely transparent to users'." The Register has more information on these newly announced proxy servers.
I assuse it will still use the standard PGP format for email, so that the other end (without pgp) will see what we normally see today with an encrypted email. Those users will have to manually decrypt / encrypt messages, but the users with the universal box will have seamless integration.
PGP is a fascinating tool. Most see PGP as a way of sharing files, but the creator of PGP, Phil Zimmerman, really want to make a *privacy* tool. I did not realize this and other things until reading this book.
O'Reilly's PGP book can be divided into two sections. The first section is really a history of cryptography and how PGP fits in this context. I found this section surprisingly enjoyable as you learn about the long and tortuous struggle between the NSA and people who want to promote freedom and privacy. On a more concrete level though, you do learn quite a bit about different encryption algorithms and key algorithms, such as the RSA and Diffie-Hellman as well as other concepts important to cryptography. Admittedly, the history itself makes for pretty interesting reading.
The second section is about PGP usage, and it is very thorough in its coverage. You will learn just about every possible feature in PGP, and how to apply them to a number of possible situations. I like reading this book over the PGP manuals just for the time and care put into it, if not the amusing examples.
One thing other reviewers have rightly touched on is the age of the book. TIme has passed. The RSA algorithm is now free and open, and PGP clone called GPG is now in wide use. I am definitely excited to see a 2nd edition of this book in hopes that it will cover such things.
However, regardless of the age, this book is an excellent primer into PGP and cryptography culture, and newbies like me will certain enjoy reading it.
Quoted from Amazon
Did you read the article? It says: "Transmissions between a client machine and PGP can themselves be encrypted using SSL."
So transport between client and proxy can (and should) be secured. Of course you'll need appropriate authentication mechanisms at the client end to make sure the client is trusted, but as long as you trust SSL the actual data transmission itself shouldn't present a problem.
If this thing sits on each side and seamlessly encrypts/decrypts the mail without user intervention than what is the benefit of using this as opposed to using TLS? TLS provides seamless server-to-server encryption also, but its free if you are using an open source mail server that supports it, and TLS is already around and widely (albeit not widely enough) supported.
This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.
It does. The classic problem with STARTTLS is that it isn't end-to-end encryption - there is no guarantee that your mail server will use STARTTLS for the next hop, or that the recipient will use (SIMAP, POP+STARTTLS, whatever) to download it from their mail server.
With this solution, the first hop is encrypted with SSL (just like STARTTLS) and after that the message itself is encrypted/signed, and any MTA hops beyond that don't need to be encrypted if the message is.
There is a Client Key Mode that doesn't store the Private key on the PGP server. In this mode the admin can't view your key. Read through all the FAQ's.
Pine/GnuPG ask me for a passphrase each time I encrypt and/or sign a message.
Actually, you're only prompted for a passphrase when signing an e-mail/file, not when you encrypt. If you're getting prompted for both, then you're most likely doing a sign/encrypt rather than just an encrypt.
Encrypting uses the public portion of the recipients key, which isn't passphrase protected.
Sounds a lot like what Zixmail (zixcorp.com) and several other companies provide. It would be nice to see some kind of standard emerge that most ISPs offer as a free service -- StartTLS/SSL to an SMTP server, which then looks at a special header or whatnot and contacts a global database of IDs/Keys (e.g.: like DNS for domain names). Problem is that it requires a lot of people to all make up their mind a certain way and it's going to take some time.
Many of the standards of today (DNS/SMTP/etc.) came about while the Internet was a comparatively homogenous collection of universities, government and military sites mostly in English-speaking countries, with little or no commercial interest.
Nowadays I'm less confident in the RFC process -- clearly it is still there and still works, but as the Internet has grown, so has the time for a convergence on new and important standards. Case in point: IPv6 -- it's been around for years, but few sites have actually made the leap.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Doesn't Anubis do this already? Why would anybody implement something like this, when a free alternative exists.
http://www.gnu.org/software/anubis/
Not to mention it has many more features than this, and no NSA Backdoors =)
-miah
As much of a POS that GroupWise is, it can be set up to generate keypairs for users and be automatically inserted into their clients. You could then make default the option to sign every message and leave it up to them to use encryption. Of course, I doubt most corporate users use passwords that are strong enough to deny someone access to the system, which would then give you access to the private key[s] of the compromised user. Still, it's there.
Linux: The world's best text-adventure game.
The FAQ has a good amount of information.
Got this e-mail this morning...
Dear PGP Customer:
We are pleased to announce the shipment of PGP(r)Universal.
Thank you for purchasing products from PGP Corporation. Over the last year, we have met with customers around the world to help us design a new generation of security products. Our goal was to take trusted PGP technology and deploy it in a way that would allow customers to finally secure all their electronic assets.
The result is PGP Universal, a new architecture and product family deploying proven PGP technology at the network level, making email security both automatic and requiring no user intervention. By combining a
self-managing security architecture with the proxying of standard email protocols, PGP Uiversal enables customers to achieve measurable email security.
In customer meetings it became clear PGP Uiversal must meet the needs of five groups:
- Executives that want to comply with rgulations and minimize risk
- Business units that must communicate privately and securely with customers and partners
- Security groups that must enforce and measure email security
- IT organizations that don't want to change their processes or integrate new technologies
- Users who just want to do their jobs
PGP Universal was built with these needs in mind. It offers:
- Automatic key generation and life cycle management
- Central and uniform security policy control
- Policy enforcement on both inbound and outbound email messages
- Automatic and transparent operation to users
- Automatic and transparent operation to the network
- Easy and incremental deployment
- Practical and cost-effective to secure everything?
- Full compatibility with existing PGP Desktop products
PGP Universal is available immediately for purchase or customer evaluation. An FAQ and white paper with detailed information are available at www.pgp.com/universal.
Information is also available at www.pgp.com, from your PGP sales representative, or a PGP Certified Solution Provider.
Thank you for your interest in PGP products.
Sincerely,
Andrew Krcik
Vice President, Marketing and Products
PGP Corporation
Hushmail has patent (US6154543) on any kind of scheme with server based private key management.
No, the security here is by running SSL between the client and the PGP Universal server. RTFA
Don't most organizations do this sort of thing with LDAP already?
Conformity is the jailer of freedom and enemy of growth. -JFK
"i don't have any of that. it's too confusing".
"I don't have any of that. We broke it ten years ago and have our own in-house algos. But if I told you that, I'd have to kill you."
I hereby place the above post in the public domain.
What about SMTP w/ STARTTLS & require authentication?
l /u niversalfeatures.html#messenger
That has the same issues unless you're only sending mail to other users within the same server. Consider the following:
Alice, of alice.com wants to send a sensitive message to Bob, of bob.org. She composes the message in her MUA and goes to send it.
1) Her MUA contacts smtp.alice.com (perhaps using STARTTLS, perhaps requiring authentication) and the message travels (perhaps securely) to smtp.alice.com.
2) smtp.alice.com contacts smtp.bob.org and sends the message (perhaps with STARTTLS if both it and smtp.bob.org are configured with it). There is no way to verify if the message went from alice.com to bob.org in a secure fashion unless you can be assured that -all- smtp servers in the world both support STARTTLS and have well-known certificates to authenticate against.
3) smtp.bob.org delivers the email within bob.org, perhaps securely.
4) Bob downloads the email from his mailspool, popserver, or imapserver, perhaps securely.
There's a lot of 'perhaps' in there, especially once the message leaves alice.com. There's also little assurance to Bob that the message is truly from Alice.
The answer is that Alice should ude PGP/GPG to encrypt and sign her sensitive email, which will keep the contents secure until Bob uses his favorite PGP/GPG tool to decrypt/verify it.
The PGP product is meant for large enterprises full of Alices, where Alice can't be counted on to be fully encryption-saavy or consistant in her use of it. It handles creating keys for everyone who doesn't have one and making sure that all appropriate emails are signed and/or encrypted. It also offers a web-based mail drop for people who don't have an available public key to receive secure messages.
http://www.pgp.com/products/enterprise/universa
Of course this is all a rather general overview, but the point is that STARTTLS is not sufficient to ensure end-to-end message security.
A simple, yet very secure solution allready exists:
http://www.hushmail.com/
Can't say enough about this free service. It simply rocks.
why my opinion matters: i have actually used this software as an end user. i have no affiliation with pgp corp. i just got a beta download and a manual, and sorted it out on my own.
let me try to describe how it works. i'm no expert, but i think that might be a good thing in this context.
say you and i are on the same mail server, using the pgpu proxy. i send you a mail. the server says "hey, me@domain.com has no keypair". "me" has authenticated to the smtp server to send the mail, so we're going to trust "me" and generate a key pair. another will be generated for "you". when "you" check mail, it trusts you based on the imap authentication, and decrypts the mail. ultimately, the "passphrase" on the keys is the imap/smtp authentication.
this gets you encryption that took 0 effort on the users' parts, no effort on the part of the administrators beyond the initial server setup.
the user can't forget to encrypt.
you are no less secure than before, as you are still trusting based on imap/smtp authentication. but now the messages are stored encrypted on your normal mail server.
should your server get rooted, the messages aren't readable.
or if an it person with root on the mail server decides to poke at the ceo's mail, it won't be as easy (especially if that person isn't an admin on the pgpu machine).
since this is just a proxy, it can be dropped in seamlessly with a simple dns change, so you don't need to change your clients. assuming they are all using SSL already, you're done. if they aren't on ssl, there is a windows client that can be installed via active directory that will secure the desktop -> server connection. or you can just tick the "use ssl" box in any decent mailer. since it is a standard protocol, the client app doesn't matter, leaving you free to use mac/windows/linux/whatever. in my testing, the clients were macs running apple's mail.app.
it took me about 20 minutes to get it set up and working in the lab for internal mail encryption/signing. that includes installing the software.
the installer is an appliance type thing: boot off the cd, install, reboot, you're done.
regarding the keys all in one basket, there is a backup facility built in to the software to make sure you have your keys in the event of a failure.
i haven't done anything with sending mail to external users (outside of your company), so i can't say anything for/against it).
all in all, i think it's a pretty neat product. i actually don't know a thing about the pricing, but it brings value for a low admin overhead.
I did read it, but will admit that I didn't fully understand the scope of your suggestions.
Basically it comes down to somehow requiring that every "perhaps" in my example is SSL'd.
The problem is that it is extremely difficult to do so. Alice has no control over what POP or IMAP software gets used within bob.org, nor should she.
Even if a mailserver requires TLS when accepting mail, you have no assurance that it will require TLS when sending the message on it's next hop. Unless some global agency forced all public mailservers to run a particular set of software configured in a specific way, and had some DRM-like way to ensure that they haven't been changed, this really is impossible to implement or enforce.
It's more implementable, and more in the general Internet spirit, to use something like PGP to handle your security and authentication on the client end, because then you don't have to rely on every sever between you and your destination (most of which will be outside of your control) to do the right thing encryption-wise.
That said, I'd certainly like to see some way to get back to a world where you could trust a mailserver to be who it said it was. Certainly, if everyone had a proper server certificate, and if every server required incoming connections to be from a server with a valid certificate or an authenticated user, we'd be there. I just don't see an easy way to get there from here...
Philip R.Zimmerman is currently both on the technical advisory board of PGP corp (http://www.pgp.com/company/tab.html) and a reseller of the product. The current (desktop) version does have published source code. Mr Zimmermann's comments (which do not support your statements above) can be found on his website here http://www.philzimmermann.com/findpgp.shtml
Paul
Smart cards won't make PGP that much easier to use. Read "Why Johnny Can't Encrypt" for some sobering facts about how hard it is to just get PGP set up right.
.... David P Kirchner?