ARM4FS Identity Provider Integration: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
Line 10: Line 10:


[[Image:Identity Provider Interaction Schema.png]]
[[Image:Identity Provider Interaction Schema.png]]

[[Media:Identity Provider Interaction Schema.fig]]


Step 1: The user sends his authentication information along with a new public key
Step 1: The user sends his authentication information along with a new public key

Revision as of 12:00, 31 October 2006


Problem

Anonymous Reputation Provider (ARP) needs proof of identity in order to prohibit sybil attacks. On the other hand, user identities should not be stored on the ARP, because in case of, e.g. a raid this would compromise the users' anonymity.

Proposal

Identity Provider Interaction Schema.png

Media:Identity Provider Interaction Schema.fig

Step 1: The user sends his authentication information along with a new public key

       PK1 to an identity provider. The identity provider must know either by
       convention or by negotiation about the set of ID features required by the
       system. The secret key that corresponds to PK1 will be termed SK1.

Step 2: After verifying the user's authentication information the identity provider

       hashes the previously defined set of ID features and issues an x.509 
       certificate containing this hash, the features used for hashing and the
       key PK1. This certificate is signed with the identity providers secret
       key IPSK. We'll call the corresponding public key IPPK. The hash certificate
       is sent back to the user.

Step 3: The user takes the hashed ID certificate and sends it to a third instance,

       termed the identity anonymizer. We need this instance, because the hashed
       ID, in conjunction with knowledge about the set of ID features allows a
       potential attacker to check known user identities against hash values. The
       user also sends a signature on this certificate using key SK1. A second
       public key PK2 is generated by the user and transmitted to the identity
       anonymizer. We could also use PK1 again, but this could possibly allow an
       attacker to identify the user. 
       

Step 4: After verifying the hashed certificate and checking the user's signature

       against PK1 the identity anonymizer issues a new x.509 certificate containing 
       a unique but random user ID along with key PK2. This certificate is sent back 
       to the user.

Step 5: The user sends this certificate to the ARP, which checks the identity

       anonymizer's signature and uses public key PK2 for securing the connection.
       We do not need a signature with SK2 on the certificate, because the user
       proves his knowledge of it by being able to decrypt messages from the ARP.