I’m trying to think of some new ways to do secure “identification” and “authentication” transactions that seem “harder” to do in the digital world than in the real-world if we wish to maintain all the characteristic benefits. The problem is that all ID & Auth transations tend to boil down to either 2 methods, each with problems:

1. Shared Secret
   1. Problems: key distribution - must find a ‘trusted’ channel to transfer the key originally (chicken and egg problem)
2. Public Key Infrastructure (PKI)
   1. Problems: key management - maintain a revoked key list, possibly maintain directory server
   2. PGP/GPG hasn’t caught on to the mainstream much

• Along the lines of the e-cash holy grail (anonymous payment online), this globally accepted e-id of some sorts would be useful in similar ways.

See examples below:

These seem more ideal... how can we do something like this digitally?

Two complete strangers wish to maintain their anonymity yet still make a secure transaction of some information in confidence. When they meet again, still need assurance that it is the same person.

• ?? Not even sure if this is done in the real world.
• Typically have a drop box location, a 1-way transaction but not “secure”
• Properties: Ideally the 2 agents don’t need to give away their “main” identity, so this is a psuedonym identitiy assurance.
• Method: ?

Ones shows their photo ID or drivers license (”certificate?”) and presents as proof of who they are.

• Properties: The transaction only involves the 2 people as the issuer of the certificate is not contacted.
• Digital Example: Certificate authority (CA) issues/signs the certificate for the person, 3rd parties verify by use of CA’s public key.
• Method: PKI?

When in a group of people are having a conversation with each other and doing well, the all enjoy each others company. Then a new person comes into the public space who is very annoying, so the original crowd wishes to migrate and not be disturbed. Dropping subtle hints, they all ignore the jerk and meetup at another time/location and are able to negotiate this change in presence of the jerk.

Digital equivalent is broadcast ARP traffic on a LAN, when a new node comes on and is malicious or doing inappropriate things... it can disrupt others as well. Perhaps the new node cannot be silenced, but the disturbance can be limited to prevent DoS effects.

• Properties: information shared privately in presence of the jerk, assume cannot kill the jerk so party mutually migrates elsewhere
• Method: preshared secret? earned trust?

These seem to be the problems, are there real-world equivalent solutions?

A new node comes on the network (wireless ad-hoc or LAN bcast domain) and wants communicate with others securely.

• Possiblity: Starts in ‘insecure’ mode then provides some credentials? to join secure network with others?

What other methods/channels are usable for ID & Auth? Is a secret key or PKI always required?

A secret is know beforehand by all parties.

A public and private key are owned by all parties.

• ex: RSA token
• means: both parties synchronize through an out-of-bounds channel, so since 2 parties are synchronized on some “knowledge” that only they share - they are approved, or approve each other.
• challenge: some central server required for scalability? must remain synchronized at all times?

Identity credential is not in the possession of the party, yet all the party’s trusted friends provide a safe store for fragments of the identity file.

• properties: private key cannot be lost as it can be rebuilt from friend’s fragments
• challenges: initial infrastructure, need to be present with friends

Web of trust ?

• ex: Reputation or popular opinion
• means: new party to group gains a % level of trust to accept other party members through interaction and but mainly via trust levels others have on the party. “My brother Larry trusts him, so I trust him 70%” Some PKI and signing keys may be the best route.
• challenge: building infrastructure ‘initial trust pool’

• ex: He is “Tom Cruise” because everyone thinks “he” is Tom Cruise
• means: not sure yet …

back to my main argument for why PKI Public Keys do NOT need to be secured/etc (in a common environment, DoD may be different) is that if I include my “public key fingerprint” on every email I send (to all the mailing lists, etc) and post it on my website so that when you google my name all of these distributed information sources come up referencing my 1 public key… then you have high assurance that that is “my key” and not an imposters. The hash/fingerprint of my pub key ensures that we have the right key.

• this seems very similar to “reputation”
• challenge: someone may want to keep their privacy, changing keys

• Identity 2.0 OSCON 2005 presentation