VS Login Protocol

System Login

It was a principal design goal that no operator of a system entity involved with the login process (the OFS and SDS) would ever need to be trusted with sufficient information to log into a user's safe. While it's true that online banks, first generation DGC systems, and numerous other online payment businesses typically operate with full customer login details stored in their databases, this struck us as a singularly poor way to design a P2P digital bearer certificate system. Therefore, the login system works as described below.

1. The client connects to a plugin-enabled OFS, via a Jabber login used for chat but completely unrelated to any voucher safe.
2. The client prompts the user for her VS# and PIN. It computes the hash of these and sends them to the OFS, i.e. hash(VS#+PIN).
3. The OFS uses the hash as the index to look up the long-phrase blob for that hash, along with its global read cap for the long-phrase blob folder. If the user has entered incorrect data, the index hash will not be found, and the login is nacked. On success, the OFS decrypts the long-phrase blob (with the hash of the hash key), and finds inside the long-phrase, together with the read cap necessary to access the login secrets folder which contains the safe's login data.
4. The OFS does not send the long-phrase to the client. Instead, it sends the length of the long-phrase and the indices of three randomly selected characters within it. For example, if the long-phrase were foobar1234 it might return 10 and indexes 3, 5, and 8.
5. The client prompts the user to select the requested long-phrase characters, displaying Xs for the remainder. In this example, the characters to pick from the drop-down lists would be 'o', 'a', and '2'. The client sends the characters picked to the OFS, and reiterates the hash key so the OFS can associate them with the outstanding login attempt.
6. The OFS validates the supplied characters against the long-phrase. If incorrect, the user must retry. If correct, the OFS computes hash(hashkey+long-phrase), which is the index at which the safe's login secret details are stored. It then attempts to look these up on the SDS, using the read cap it found in the long-phrase blob.
7. On successful lookup (which should be the case) the OFS returns the secret details blob to the client.
8. The client prompts the user for her pass-phrase, and decrypts the secrets with it. If the pass-phrase is specified correctly, it finds:
   • The id of the VP with which this VS is associated
   • The VS's public key certificate
   • Its private key
   • The folder index hashes for its voucher/token and payment/receipt folders
   • The read-write cap for the payment/receipt folder
   • The read cap for the voucher/token folder
   • The read-write cap for the voucher/token folder (opaque because it's encrypted with the VP's public key)
9. As a final step, the client then asks the OFS for network discovery. The OFS replies by supplying the inet addresses of all PKSen, DHTs, and the SDS.

Some things to note about this mechanism:

• The OFS has absolutely no idea as to which VS# is logging in, since it sees only a hash of the VS# plus their PIN. This makes it impossible to associate Jabber usernames with voucher safes.
• The OFS never sees the pass-phrase or any portion thereof, hence it cannot obtain the VS's secrets. In fact the pass-phrase never leaves the client.
• The SDS never sees anything except lookups of encrypted blobs based on hash indexes and read caps. It has even less idea what is going on.
• The user's complete long-phrase is never transmitted in either direction, nor are the selected characters entered via the keyboard. Because of this, even a keystroke logger or Trojan on the client should fail to capture the long-phrase.
• The client is incapable of going directly to the SDS in an attempt to perform any of these steps solo. First of all, due to XML namespace restrictions the SDS will not accept these kinds of queries from a c2s connection, only a s2s connection with the OFS. Secondly, while a client might guess at hashes, it lacks the required read cap which the SDS needs to access a record, even if a hash were actually matched.
• The VP is completely uninvolved with this process, and unless the client performs subsequent voucher operations using its secrets, will have no idea what safes are logged in.
• Network discovery allows a VP to potentially reconfigure its network, if for example a server needed to be switched to a backup or replacement, due to hardware failure, DDoS, intervention by HOC, etc.

Lost Safe Recovery Protocol

This is relatively straight-forward. The steps are as follows:

1. The client asks the OFS for the text of the five recovery questions for the given VP.
2. The OFS replies with the question text. The client prompts the user for their answers, along with the VS# they are trying to recover.
3. The client constructs hash( hash(VS#+concatenated answers) ) and sends it to the OFS. Note that this hash will be unique, due to the uniqueness of VS numbers in the namespace of a given VP, even if other users answered the questions identically, or the same user answered identically for different safes.
4. The OFS looks up the hash in the global recovery table (for which there is no special read cap required). If not found, the user obviously entered something incorrectly. If found, the recovery blob is returned to the client.
5. The client decrypts the blob using hash(VS#+concatenated answers). If successful (which it should be, if the record was found at hash(key) in the first place), the safe's VS#, VPid, PIN, long-phrase, and pass-phrase are revealed.

Things to note about this algorithm:

• The OFS and SDS never see the decryption key of the recovery blob, only its hash.
• The client cannot ask the SDS directly to look up this information.
• The user enters only their VS# and answers to the five questions.

---