December 26, 2004
Nyms sighted in authentication software
The use of the nym is seeing a little bit of a revival, driven by the onslaught of chat as the future means of communication for anyone under 30. Over on Adam's more prolific blog there is word of a company called WikID that is pushing nyms from phones.
A short explanation of the cryptographic nym as a rights technique. A public/private key pair is created, and the public key is registered with a server. The private key is kept private! Now that arrangement can be used for the private key holder to authentice, or sign for, any action so permitted in the software. (You can also simulate the thing with a name and a password, which is good enough as long as there is no serious value involved.)
Nyms are identities. They are not like IDentities, the ones that politicians assure us we'd be better off if we had more of. Nyms are instead short lived, light weight identities that allow one action to relate to another. That is, if you used a nym to chat with some dude today, and also tomorrow, he would be no trouble relating the two as the same person. Bob recognises Alice from a couple of days ago, by the light touch of her nym.
Cryptographically, these are real strong. But they are also creatable on demand; making one of these things takes ... oh, seconds of otherwise wasted CPU time. Good nymous software makes them on demand and lets the users dictate what to do with them. Nyms are very very powerful, and can be used for chat, payments, trades and the like, as long as the designer recognises their asset characteristics. It is only the accident of the less powerful but more IDentifying Certificate Authority model that secures only a tiny part of the security needs of ecommerce that has overshadowed nyms in popular software.
Nyms can also be dumbed down and turned into singular authentication tokens, like certs in the CA model, and this seems what the WikID company has done. They have a client that downloads and installs on a phone or PDA, and creates a nym for purposes of gaining entry to a web site or other server asset.
Any exposure for the concept would be good, so I wish them well. It's been a hard lonely road for us nym developers for the last decade or so.
Posted by iang at December 26, 2004 04:39 PM
Ian, do you know anyone who's working on OpenPGP software that uses the nym model (instead of the web of trust)?
When I download a new version of a program that is signed using OpenPGP, I don't really care if the signer's user ID has been certified, as this doesn't tell me if the signer is authorized to release new copies (my favorite example: Would you install a new Apache release that is signed by "Rodent of Unusual Size"?). However, if my OpenPGP software could tell me that the signer is the same as the last time I downloaded the software, I would be quite confident that the new release is as genuine as the old one, too.
To answer your first question: webfunds (click on my name below) is uses a nymous protocol called SOX. Whether this quite matches what you are asking for, you can judge:
SOX version 1 was purely PGP, but the old 2.6. Each account was a PGP key that was registered as above, and formed the basis for payments and trades, as well as retail purchasing (the "SOX shop" :). I chose and insisted on PGP because I thought conformance to a standard would help market acceptance. I was wrong!
In SOX version 2 we dropped the requirement to use PGP. SOX 2.0 used x.509 certs as its basic nym; but after a year we discovered that x.509 cannot do financially oriented transactions because it lacks WoT so we switched over to OpenPGP.
However, the nyms that are in the underlying SOX2.2 (and thereafter) are not OpenPGP keys. They are just keys, and I can't recall the precise format. They *could* be OpenPGP keys, but in practice, the notion of "being compatible with some standard" was a complete woftam for the nymous application; what was more important by several orders of magnitude was that the system worked and no money was lost. After that, nobody cares what format the keys are in.
Having said that, there is the question of WoT. For the WoT elements we use OpenPGP, but these are not used as nymous keys! Our plan (a project that is being worked on) is to layer WoT OpenPGP keys over the top of the nyms, so I'd have to say that we are not seeing any desire to use OpenPGP keys as nymous keys, directly.
I think it's horses for courses. The stuff that OpenPGP concentrates on is mostly about additional information related to a key; which is the antithesis of what a nym is. A nym is a key with no information, and its value is its relationship to all the different uses of the key, not to any "statement" tacked on.
To answer your second question: in order to track a nym's activities, the application has to understand what a nym is doing. That is, your download application probably needs to relate the nym to the downloads; and an OpenPGP application won't really understand that.
But you raise an interesting point. If I were to create a key with a name of "Rodent of Unusual Size" and shove it on a key server, then I would be able to happily send out downloads; it is only until some human comes along and realises that there are two keys with the same name that the game would be figured out.
This of course just leads us down to the gulf between reality and security systems. Most security systems, OpenPGP included, relate people to identities to keys and assume that covers it. But most reality deals with assets and actions on those assets, not with people or identity.
All verifying consistency of the signer will do is to make sure that the guy who gave you a backdoored copy can extend and elaborate the deception at will.
Thanks for the post, Ian!
I intend to do some more research about nyms in time (right now, I'm actually on vacation and will get in trouble soon for being on line). Perhaps Adam will give me a tutorial if I buy him a beer.
What's interesting to me is the way nyms relate or can relate to our method of initial validation (http://www.wikidsystems.com/selfservice.shtml) which is 'marketed' toward corporate validation but is actually extremely flexible and extensible and could be used in a WoT way or with PGP. Essentially the public keys are exchanged between our client and the server. After a successful exchange the server sends a registration code (which is then hashed on the client with the public key of the server). Only after the registration code has been returned to the server via a separate trusted channel is the account activated. Typically this process is done on the trusted LAN with trusted credentials, but it could easily be done via PGP or some other mechansim.