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 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.