ARM4FS Designfoo

UserID

Public/private key pair, maybe with additional attributes

User management

• RP has a database with two unrelated tables:
  • UserIDs and accompanying data
  • Realnames/IDs (X.509-DN?) who already have an account.
• User creation, in cooperation with an identity provider:
  1. Identity provider asserts identity
  2. Reputation provider checks whether this identity already has an account, refusing creation if this is the case (counters Sybil attack)
  3. Create a new UserID and enter it into the database; at the same time enter the realname as 'used' into the database.
  After this procedure there is no further correlation between realname and UserID!
• Two possible approaches to account for eventual deletion of UserIDs together with their realname entries (makes it possible to apply for another UserID thereafter):
  • Save a hash of the realname together with the UserID. Bad idea, because a simple scan could correlate the UserID and realname.
  • Give a signed (+ encrypted?) realname/UserID pair to the user on account creation. The user can then either delete this pair if she is positive that she won't need it in the future (or is afraid of the risk that this pair may be found on her computer), or use it in the future to have the reputation provider delete both entries (UserID table and realname table).

Document submission

session = RP.createSession(UserID) ObjectKey = SP.storeTemporary(Content, timeout) AuthorTag = session.createAuthorTag(ObjectKey) SP.storePermanent(AuthorTag) session.destroy()

Reputation query

session = RP.createSession(UserID) session.getReputation(AuthorTag) session.destroy()

Content feedback

session = RP.createSession(UserID) session.submitFeedback(AuthorTag, feedback) session.destroy()

AuthorTag

signed_RP(UserPseudonym, ObjectKey)

Sessions

Authenticated, encrypted channel to the Reputation Provider. Maybe integrate Off-the-Record here? Would that be beneficial? In any case: it's fine to route the channel through TOR or similar.

createAuthorTag()

UserPseudonym_x is a completely random value which will only be used to lookup the UserID in the Reputation Provider's database. Rationale: If anonymity is supposed to be the highest goal of this system then it won't be such a good idea to have any relationship between the public UserPseudonym and the secret UserID. Even encrypting isn't a good idea: If the encryption key is broken or compromised then all anonymity for all users for all past transactions would be void. (Break one, break all.) It might be possible to segment the effects of possible key compromises by using multiple keys (either separated by time or by user group), but that's only mildly effective and has problems of its own (e.g. by correlating on the key that was used it would be possible for an attacker to find out when an AuthorTag has been created, or which group a user belongs to; now that I think about it: this could be countered by randomly using many keys, but still doesn't look very good). The underlying threat model is that an administrator of the system might be 'convinced' into smuggling the key into the hands of the attacker. Certainly it would be a lot harder to transmit a complete database of UserID<->UserPseudonym relations than it would be to transmit a single key (about 4096 bits). On the other hand: It is easier to safeguard a key (e.g. in a security module such as a smart card) than it is to safeguard a complete database. Maybe we should combine both approaches? The public UserPseudonym would then be an encrypted random string. Note: The signature key for AuthorTag signatures is not so much of a problem. If this key is compromised then only the correctness of the system will be endangered and not the anonymity of its users.

ObjectKey

URI, preferably URL with (schema specific) embedded hash of the contents. For starters:

http://SP/get?h=hash

.

Musings On The Server<->Client Protocol

The Reputation Provider acts as a server and listens on port 2323.

Encryption

The server<->client protocol, or the sessions, should provide protection against:

• all passive attacks
• most active attacks

Specifically it seems to only be possible to protect against active attacks (man in the middle) if a trust relationship has already been established, e.g. the client knows the server's public key. (In order to provide confidentiality the server does not need to know the client's public key. This key only becomes important for authenticating clients. The user creation process is possible even for an unauthenticated client.)

To minimize the possibility of protocol design or implementation errors it would be best to use an already existing protocol and implementation, e.g. SSL/TLS and OpenSSL. Problem: SSL uses X.509 certificates and not raw keys. Certificates pose some dangers of introducing accidental side channels, for example through serial numbers, but add next to no additional value. Also: SSL is quite a complex protocol and widely deployed implementation errors (ASN.1!) have not been unheard of.

A homemade protocol would look something like this:

1. diffie-hellmann between client and server
2. server signs own diffie-hellmann parameters with own secret key
3. when the client has verified this signature it knows that it is in fact talking to the right server
4. connection is then in a state in which the client may
   • transmit a user creation request, or
   • authenticate itself by sending a signed version of its own diffie-hellmann parameter

Discussion

	own protocol	SSL/TLS
pro	uses raw keys, limited side channel possibilities	tried and proven design various interoperable implementations may be possible to verify server identity through regular PKI
contra	not thoroughly analysed, may be weak	some degree of bloat (ASN.1, X.509)