update identity server-side registration management

[mwfarb]

Until now, we've tried to provide the most usable experience we can without storing user identify online. It's becoming increasingly difficult to do so since push registration IDs need to change more frequently than they have in the past, and need to be allowed to change more frequently that they have in the past. We warn users that they must sling keys when the registration has changed from past slings, but that is far less usable that it could be.

If all push registrations expired and devices were issues now ones at the same time, no devices would have the new address so they could receive messages and that is not acceptable. We'll need to store a table with at least:

• registration update timestamp
• key id
• push registration id
• push registration service type

We'll also need to add a new script for devices to register their new registration ids when they get them. However, this script should be constructed in such a way with the new table that it would not be trivial to to submit false redirection to another device, even though such a message would be useless without the private key.

Finally we need to modify the postMessage script to check for updated recipient registration ids before sending the push message. This could be rolled out separately in phases when each client has time to submit the proper changes. First Android could modify postMessage for types 1 and 3, and later iOS could modify postMessage for type 2.

Client-side relevant issues:
SafeSlingerProject/SafeSlinger-Android#38
SafeSlingerProject/SafeSlinger-iOS#45

[mwfarb]

One way to do this is to use the push messaging system itself to deliver a submission nonce for authentication. We could do a 3-way handshake that could ensure the nonce came only by way of the requesting device using the push service as well.

• client sends to server key id, registration id.
• server returns a random nonce in a push message to the registration id.
• client receives push message and sends nonce as an authentication token.

[mwfarb]

Another way to do this is to make a TOFU model where the first time a key id is added, each time an update to that key id is added it must survive a challenge the original entry made. Maybe the submission nonce could be a hash of the private key, which would help make sure it couldn’t be easily erased.

Sequence:

• Client: submissionToken = H(private_key).
• Client: post to server -> add_idenity_script(key_id, reg_id1, submissionToken).
• Server: checks if key_id is in identity table, find 0 matches.
• Server: inserts key_id, reg_id1, submissionToken into identity table.
• Client: reg id changes.
• Client: post to server -> add_idenity_script(key_id, reg_id2, submissionToken).
• Server: checks if key_id is in identity table, find 1 match.
• Server: checks if submissionToken sent == submissionToken in table.
• Server: inserts key_id, reg_id2, submissionToken into identity table.

[mwfarb]

Server side uploaded, Android client in progress.

[tenmalin]

Modified TOFU registration model. The sequence is listed as follows:

Sequence (for new registration):
Client: submissionToken = H(sign_pub).
Client: generate signature sig by signing (key_id, reg_id, submissionToken, nonce, sign_pub) with private key sign_pri and 32 bytes nonce.
Client: post to server -> add_idenity_script(key_id, reg_id1, submissionToken, nonce, sign_pub, sig).
Server: checks if key_id is in identity table, find 0 matches.
Server: verify (key_id, reg_id, submissionToken, nonce, sign_pub) through retrieve sign_pub and sig from packet.
Server: inserts key_id, reg_id1, submissionToken into identity table.

Client: reg id changes.
Client: post to server -> add_idenity_script(key_id, reg_id2, submissionToken, nonce, sign_pub, sig).
Server: checks if key_id is in identity table, find 1 match.
Server: checks if submissionToken sent == submissionToken in table.
Server: verify (key_id, reg_id, submissionToken, nonce, sign_pub) for sure.
Server: inserts key_id, reg_id2, submissionToken into identity table.

[mwfarb]

I'll add the server side handling to manage migration from scheme 1 to scheme 2.