113
edits
(Added clarifying text) |
(Clarified registration protocol) |
||
Line 333: | Line 333: | ||
The objective of the registration protocol is for a user, i.e. Alice, to authorise a new device and transfer to it the master key (sync key) thus allowing it to read and write encrypted data to and from the storage. To maintain the security of the master key the protocol must defend against a man-in-the-middle (MITM) attack from an adversary. Importantly for version 2 of the eXfio Peer protocol the starting assumption is that an adversary has full access to the storage '''and''' knows the password, i.e. a hostile systems administrator. | The objective of the registration protocol is for a user, i.e. Alice, to authorise a new device and transfer to it the master key (sync key) thus allowing it to read and write encrypted data to and from the storage. To maintain the security of the master key the protocol must defend against a man-in-the-middle (MITM) attack from an adversary. Importantly for version 2 of the eXfio Peer protocol the starting assumption is that an adversary has full access to the storage '''and''' knows the password, i.e. a hostile systems administrator. | ||
When Alice registers a new device with the Weave Sync server the client first checks if | When Alice registers a new device with the Weave Sync server the client first checks if any devices have already been registered. If there are no registered devices it generates a master key (MK) and initialises the storage. If there are existing registered devices it requests authorisation by following the procedure below. | ||
<ol start="0"> | <ol start="0"> | ||
<li>Client A: Authenticate to sync server and create client record with status of 'pending'</li> | <li>Client A: Authenticate to sync server and create client record with status of 'pending'</li> | ||
<li>Client A: Send SessionRequestMessage to | <li>Client A: Send SessionRequestMessage to registered devices, providing an ephemeral key (AEp) and nominating an ephemeral key digest (BEd) of other device, i.e. Client B</li> | ||
<li>Client B: Send SessionResponseMessage including ephemeral key nominated by Client A. Display authcode generated from session key and master key</li> | <li>Client B: Send SessionResponseMessage including ephemeral key (BEp) nominated by Client A. Display authcode generated from session key and master key</li> | ||
<li>Client A: User enters authcode. If session key | <li>Client A: User enters authcode. If the session key component (VCS) is verified then send ClientAuthV2RequestMessage including the master key component of authcode (VCM), thus proving the user is in possession of a registered device, i.e. Client B</li> | ||
<li>Client B: If Client A responds with proof of possessing | <li>Client B: If Client A responds with proof of possessing registered device then send ClientAuthV2ResponseMessage including the master key</li> | ||
</ol> | </ol> | ||
Finally Alice is notified of registration status and if successful client record is updated with status of 'approved' | Finally Alice is notified of registration status and if successful client record is updated with status of 'approved' | ||
Line 378: | Line 378: | ||
'''Notes:''' | '''Notes:''' | ||
* The authcode (VCS + VCM) is a digest of the session key and the master key respectively. This code needs to be entered on the device requesting authorisation to verify the user is in possession of | * The authcode (VCS + VCM) is a digest of the session key and the master key respectively. This code needs to be entered on the device requesting authorisation to verify the user is in possession of registered device. If the authcode displayed by Client B matches the VCS value generated on Client A and the VCM value returned to Client B then a man-in-the-middle attack is highly unlikely. | ||
'''ClientAuthV2Verifier JSON''' | '''ClientAuthV2Verifier JSON''' |
edits