Services/Sync/SyncKey/J-PAKE/NewOrder: Difference between revisions

*PIN: code that is displayed on Device and entered on Desktop made up of the weak secret & the channel id.

== Overview ==

*Device and Desktop complete the two roundtrips of J-PAKE messages to agree upon a strong secret K  

*A 256 bit key is derived from K using HMAC-SHA256 using a fixed extraction key.  

*The encryption and HMAC keys are derived from that 256 bit key using HMAC-SHA256.  

*In third round trip:  

**Device encrypts the known message "0123456789ABCDEF" with the AES key and uploads it.  

**Desktop verifies that against the known message encrypted with its own key, encrypts the credentials with the encryption key and uploads the encrypted credentials in turn, adding a HMAC-SHA256 hash of the ciphertext (using the HMAC key).  

**Device verifies whether Desktop had the right key by checking the ciphertext against the HMAC-SHA256 hash.  

**If that verification is successful, Device decrypts ciphertext and applies credentials, and triggers the first download to Device.

<pre>Device                        Server                        Desktop

retrieve channel &lt;---------------|

upload Device's message 1 ------&gt;|

                                 |----&gt; retrieve Device's message 1

                                 |&lt;----- upload Desktop's message 1

retrieve Desktop's message 1 &lt;---|

upload Device's message 2 ------&gt;|

                                 |----&gt; retrieve Device's message 2

                                 |&lt;----- upload Desktop's message 2

retrieve Desktop's message 2 &lt;---|

encrypt known value ------------&gt;|

                                 |&lt;------------- upload credentials

retrieve credentials &lt;-----------|

decrypt credentials               

Device begins download          |

<li>Device asks server for new channel ID (3 characters a-z0-9)

<li>Device generates PIN from random weak secret (4 characters a-z0-9) and the channel ID, computes and uploads J-PAKE msg 1.To prevent double uploads in case of retries, the If-None-Match: * header is specified. This makes sure that the message is only uploaded if the channel is empty. If it is not then the request will fail with a 412 Precondition Failed which should be considered the same as 200 OK. The 412 will also contain the Etag of the data was the client just uploaded.

<b>New in version 3:</b> Timeouts will need to be increased to accommodate the case where users have to create an account on the Desktop before proceeding.  

<li>Desktop asks user for the PIN, extracts channel ID and weak secret, fetches Devce's msg 1

<li>Desktop computes and uploads msg 1. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200.

<li>Device polls for Desktop's msg 1

<p>Device tries again after 1s</p>

  <p>Device computes and uploads msg 2. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200.

<li>Desktop polls for and eventually retrieves Device's msg 2

<p>Desktop computes key, computes and uploads msg 2. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200.

<li>Device retrieves Desktop's msg 2

<p>Device uploads encrypted known message "0123456789ABCDEF" to prove its knowledge (msg 3).

<b>New in version 3:</b>No longer includes the key, just the known message.

The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200.

<li>Desktop retrieves Device's msg 3 to confirm connection. <b>new in version 3</b> No longer includes encrypted key. That will come in the 4th exchange once account creation has happened if needed and first sync upload has occurred.

Desktop verifies it against its own version. If the hash matches, it acquires (either the existing account or by creating a new one), then encrypts and uploads Sync credentials.

The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200.

This means that Device will receive a 404 when it tries to retrieve the encrypted credentials.

</li>

 

<li>Device retrieves encrypted credentials

C: If-None-Match: "etag-of-receiver4-message"