Public Key Cryptography (by alaric)
GnuPG, as an open source package, can be supplied with OS X. It shouldn't need much, if any, modification, so the modifications can be published in source code form as per the GPL without causing Apple any trouble. Mainly, I foresee the ability to store your private key passphrase(s) in the Keychain. I don't think it's worth integrating it so seamlessly as to store the private keys directly in the Keychain rather than in the GPG standard keyring, but it might be.
Where the work needs to be done - and it's not a lot of work - is in Address Book, Mail, and a Finder extension to support signatures.
Firstly, Address Book should offer key management. Keys can still live in the GPG keyring, as usual, but Address Book should be able to store key fingerprints alongside a contact and thus link it to a public key in your ring, and display this fact. The names and email addresses and photos in the public key can be displayed read-only alongside the editable ones in the address book (and made available via the API to applications that read address book data). The details of the keys (expiry, etc) should be listed somewhere, probably in a separate details window since they're not very interesting, along with lists of who's signed the key and all that stuff. Web of trust information should be displayed, with the option to sign a key, which takes you to a dialog where you state the trust level and optionally select only certain UIDs to sign; it then implements the functionality of caff, splitting out the signature on each UID and emailling it (encrypted) to the email address in that UID only, to authenticate ownership of the claimed email addresses conveniently.
And Address Book should let you create keypairs against your own identities within it, upload it to keyservers, fetch a key for a contact from a keyserver given a key ID, export/import keys from .asc files, and all that stuff. Any public keys in your keyring that don't have associated Address Book cards should have one silently autocreated, so the entire keyring is visible.
A fair amount of things to do, but none of them rocket science.
The support in Mail is mainly already done by the MacGPG folks, although they've had to do it via some nasty hacks rather than it being seamlessly integrated. Signing outgoing messages either by default or when you ask it to, encrypting when all the recipients of an email are known to have trusted keys, that sort of thing.
Then the Finder extension would again be fairly simple, from the existing work done by the MacGPG folks. Right click to encrypt/decrypt files. Detached signature files, if they are alongside the file they correspond to and check out, show a happy green tick icon. Perhaps hook the filesystem change notifications so that if a signed document is modified, then any signatures on it are removed automatically. That sort of thing.
Oh, and when setting up your Mac for the first time, it should ask you if you have a keypair already, and guide you through creating one if not.
People would be able to use public key encryption; in fact, they would use it by automatic default. Then there'd be a secondary round of development on top of it - developers of other software could integrate, too, encouraged by the presence of a deployed user base.
This is almost entirely user interface code, which is pretty quick and easy to do with Cocoa; if Apple spent a couple of man-months on it, they'd be able to proudly advertise the amazing new security features of the next release of OS X.
And why do I choose Apple to do this? Purely because I think it's the kind of thing they might find worthwhile and actually do. Microsoft doing it in Windows and Outlook would have far greater reach, but I think they're far less likely to actually do it (they'd rather we used some proprietary solution, or just X.509 with its centralised trust-big-brother key management model). So better, I think, to make it ubiquitous by getting Macs to do it, then gmail (they could have a Web interface to generate a keypair on their servers or upload an existing one, and have to accept less security by having key storage and signing/decryption all done on Google's servers, but at least it'd be widely usable) and friends could join in the fun. Once a few different systems are all handling PGP-encrypted email nicely by default, Microsoft will hopefully tag along with the de facto standard rather than making their own.
Pages: 1 2
Crypto / security | alaric | 
Tue 3rd Jun 2008 2:48 pm
Subscribe
By Ben, Tue 3rd Jun 2008 @ 4:21 pm
Did you know Mail.app supports the X.509 stuff? Search for "certificates" in Mail.app's help for info. It's not exactly advertised, though.
By alaric, Wed 4th Jun 2008 @ 12:18 am
Yeah. Sadly, I don't think X.509 is the way to go...
By alaric, Mon 7th Jul 2008 @ 9:53 am
I have an additional feature I think a MacOS/GPG integration should have, actually, purely to foster better adoption in commercial environments.
The X.509 model is actually fairly appropriate for corporate use - a central corporate CA can issue certificates for their employees. Such centralised operation is entirely correct in such an environment.
However, the neat thing about the web-of-trust model is that it's more general than hierarchial trust; a hierarchy is, in fact, a restricted form of a web.
So there should be a simple tool built into the directory services stuff used to maintain a centralised organisational user database (I must confess I've never come across Macs configured to operate in this way; I suspect most organisations will really be running Windows with Active Directory in the core; but a Mac can talk to that, which is sufficient for this purpose). It would simply manage an X.509-esque certificate hierarchy. Users who are connected to a directory service would be given the option, when they have created a private key, to submit it to The Directory for signing. In which case, the key management system (actually alongside the directory) would check the details on the key strictly match those on the user account that's submitting the key, and if so, sign it with a master key (to publish the fact that it's done the check), then slip the signed public key into the directory - and into public keyservers so that other organisations can then see that the new employee is, in fact, a certified employee of BigCorp when they start sending emails from their BigCorp address.
Oh, and when an account is deleted from the directory, the key management system would notice this and immediately publish a revocation of the organisation's signature of the key.
The next version of the thing could also support role/group keys. Administrators could grant a keypair to a user group, then a proxy system could ensure that outgoing email from members of that group (as long as the signature matches a real group member!) is also signed automatically by the group's key, optionally removing the original author's signature. This would enable digital identities to be assigned to roles or teams within an organisation, even as members come and go. Exactly how to implement the proxying is an intereting question; for emails, how do you know if an email is semantically from its author, or from a role the author holds? If you use a mail client that supports multiple sending accounts it becomes easy. But what about signing files and the like?
Incoming encrypted emails to the role/group are easy to handle - the mail system can decrypt them, then re-encrypt them for the members of the group and distribute it to them.