Services/Sync/P2P Key Exchange And Rotation: Difference between revisions

Jump to navigation Jump to search

Services/Sync/P2P Key Exchange And Rotation (view source)

Revision as of 05:03, 4 January 2016

3,345 bytes added ,  4 January 2016
Added additional v2 registration protocol candidate
(Try using automated anchors for headings with same name)
(Added additional v2 registration protocol candidate)
Line 225: Line 225:
Version 2 of the eXfio Peer protocol improves the protection against a man in the middle (MITM) attack, at the expense of a more complex protocol, requiring two round-trips. Importantly the starting assumption is that an adversary has full access to the storage '''and''' knows the password, i.e. a hostile systems administrator. Fortunately an elegant means to mitigate against this threat is to use a [https://www.silentcircle.com/products-and-solutions/technology/scimp/ SCIMP] style hash commitment, which results in the adversary having a single opportunity to guess the authcode with a probability of 1.05 x 10<sup>-6</sup>.
Version 2 of the eXfio Peer protocol improves the protection against a man in the middle (MITM) attack, at the expense of a more complex protocol, requiring two round-trips. Importantly the starting assumption is that an adversary has full access to the storage '''and''' knows the password, i.e. a hostile systems administrator. Fortunately an elegant means to mitigate against this threat is to use a [https://www.silentcircle.com/products-and-solutions/technology/scimp/ SCIMP] style hash commitment, which results in the adversary having a single opportunity to guess the authcode with a probability of 1.05 x 10<sup>-6</sup>.


<span id="Messaging_Protocol_v2"></span>
===Messaging Protocol===
===Messaging Protocol===
<span id="Messaging_Protocol_v2"></span>
By requiring the responding party, Bob, to nominate a key in advance using a hash commitment, a MITM adversary, Eve, is required to select a public key without knowing the either Alice key. Thus making it very difficult to launch a MITM attack without detection. See [[#Registration_Protocol_2]]
By first requiring each party to make a hash commitment an adversary is required to select a public key without knowing the other party’s key. Thus making it very difficult to launch a MITM attack without detection. See [[#Registration Protocol v2]]


'''Protocol Sequence'''
'''Protocol Sequence'''
Line 233: Line 233:
<li>Each client publishes an identity key (AI, BI) and a set of ephemeral key digests (AE{1..n}, BE{1..n}d)</li>
<li>Each client publishes an identity key (AI, BI) and a set of ephemeral key digests (AE{1..n}, BE{1..n}d)</li>
<li>Client A: Generates a new ephemeral key (AEp) and sends a message to Client B nominating one of client B's ephemeral key digests (BEd).</li>
<li>Client A: Generates a new ephemeral key (AEp) and sends a message to Client B nominating one of client B's ephemeral key digests (BEd).</li>
<li>Client B: Using 3DHE and a KDF generates the session key (SK) then sends message including own ephemeral key (BEp) matching digest (BEd). Client A can now also generate the shared secret (SK) and hence the message body can be encrypted immediately.
<li>Client B: Using 3DHE and a KDF generates the shared secret (SK) then sends message including own ephemeral key (BEp) matching digest (BEd). Client A can now also generate the shared secret (SK) and hence the message body can be encrypted immediately.
</ol>
</ol>


Line 239: Line 239:


<pre>
<pre>
           Alice (Client A)                      Eve (Public)     Bob (Client B)
           Alice (Client A)                      Eve (MITM)       Bob (Client B)


t0        AIs                                    AIp, BIp        BIs
t0        AIs                                    AIp, BIp        BIs
Line 325: Line 325:
</pre>
</pre>


=== Registration Protocol ===
<span id="Registration_Protocol_v2"></span>
<span id="Registration_Protocol_v2"></span>
===Registration Protocol===
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 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.
When a user 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.
 
====Candidate Solution A====
Candidate solution A has the benefit that all user input takes place on the new device, Client A, and thus the user experience is similar to second factor authentication (2FA) using software based one time password (OTP) application such as [https://en.wikipedia.org/wiki/Google_Authenticator Google Authenticator]. Out-of-band verification mitigates against the impersonation of Client A and Client B, however because only the registered device, Client B, can determine if verification of Client A has been successful if a user incorrectly enters the authcode additional messages need to be exchanged between clients potentially causing confusion as a result of the delay in notifying the user that verification has failed.
 
'''Note:''' When the new device is mobile a QR code could be used for the out-of-band verification, which would remove the need for user input.


<ol start="0">
<ol start="0">
Line 335: Line 340:
<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 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 (BEp) nominated by Client A</li>
<li>Client B: Send SessionResponseMessage including ephemeral key (BEp) nominated by Client A</li>
<li>Out-of-Band: User sights authcode displayed on Client B, generated from session key and master key, and enters it on Client A</li>
<li>Out-of-Band: User sights authcode displayed on Client B, generated from session key and random value, and enters it on Client A</li>
<li>Client A: If the session key component (VCS) of authcode 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 A: If the session key component (VCS) of authcode is verified then send ClientAuthV2RequestMessage including the random value component of authcode (VCR), 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 registered device then send ClientAuthV2ResponseMessage including the master key</li>
<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 the user is notified of the registration status and if successful client record is updated with status of 'approved'


<pre>
<pre>
Line 354: Line 359:
t2        AIs                                    AIp, BIp        BIs, MK
t2        AIs                                    AIp, BIp        BIs, MK
           AEs                                    AEp, BEp        BEs
           AEs                                    AEp, BEp        BEs
          BT                                    BEd              BT
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))     BEd              SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                     SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           Verified = (BEd == DIGEST(BEp))                       
           Verified = (BEd == DIGEST(BEp))                       


t3        AIs                                    AIp, BIp        BIs, MK
t3        AIs                                    AIp, BIp        BIs, MK
(OoB)      BT                                                      BT
(OoB)      SK                                                      SK
          SK                                                      SK
           VCSui = <user input>                                    VCS = DIGEST(SK)
           VCSui = <user input>                                    VCS = DIGEST(SK, BT)
           VCRui = <user input>                                    VCR = RANDOM()
           VCMui = <user input>                                    VCM = DIGEST(MK, BT)
           Verified = (VCSui == DIGEST(SK))                                         
           Verified = (VCSui == DIGEST(SK, BT))                                         


t4        AIs                                    AIp, BIp        BIs, MK
t4        AIs                                    AIp, BIp        BIs, MK
           SK                                                      SK
           SK                                                      SK
                                                                   VCM
                                                                   VCR
                                                                   VCMui
                                                                   VCRui
                                                                   Verified = (VCMui == VCM)
                                                                   Verified = (VCRui == VCR)


t5        AIs, MK                                AIp, BIp        BIs, MK
t5        AIs, MK                                AIp, BIp        BIs, MK
Line 376: Line 379:


'''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 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.
* The authcode (VCS + VCR) is a digest of the session key and a random value 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 then a man-in-the-middle attack impersonating Client B is highly unlikely. Finally if the VCRui value returned to Client B matches the original VCR random value then a man-in-the-middle attack impersonating Client A is highly unlikely.
* To minimise errors during user input the authcode can be represented using a word list, i.e. [https://en.wikipedia.org/wiki/PGP_word_list PGP], [http://world.std.com/~reinhold/diceware.html Diceware], [https://tools.ietf.org/html/rfc1760 S/KEY] or optionally scanned using a QR code.


'''Alternate Flow'''
====Candidate Solution B====
Candidate solution B has the benefit that user input for out-of-band verification takes place on the registered device, Client B, which can determine if the verification of Client A has been successful without exchanging additional messages between clients. However to detect a MITM adversary impersonating Client B an additional verification check is needed on the new device, Client A. Although this attack would not result in a compromise of the master key it could result in the sharing of confidential data. Thus if a user incorrectly enters the authcode additional messages need to be exchanged between clients, however the out-of-band verification flow and user input flow would be in alignment, thus resulting in improved user experience.
'''Note:''' Similarly to Candidate solution A, when the new device is mobile a QR code could be used for the out-of-band verification, which would remove the need for user input and mitigate against the impersonation of Client A and Client B.


<pre>
<pre>
           Alice (Client A)                      Eve (Public)    Bob (Client B)
           Alice (Client A)                      Eve (MITM)    Bob (Client B)


t0        AIs                                    AIp, BIp        BIs, MK
t0        AIs                                    AIp, BIp        BIs, MK
Line 390: Line 397:
(OoB)      AEs                                    AEd, BEd        BEs
(OoB)      AEs                                    AEd, BEd        BEs
           AEp                                                    BEp
           AEp                                                    BEp
           VC = DIGEST(AIp, AEp)                                   VCui = <user input>
           VCS = DIGEST(AIp, AEp)                                 VCSui = <user input>
          VCR = RANDOM()                                          VCRui = <user input>


t2        AIs                                    AIp, BIp        BIs, MK
t2        AIs                                    AIp, BIp        BIs, MK
           AEs                                    BEp              BEs
           AEs                                    BEp              BEs
           AEp                                    AEd, BEd            
           AEp                                    AEd, BEd         VCSui   
          VCS                                                    VCRui
          VCR                                                   
           Verified = (BEd == DIGEST(BEp))                         
           Verified = (BEd == DIGEST(BEp))                         


t3        AIs                                    AIp, BIp        BIs, MK
t3        AIs                                    AIp, BIp        BIs, MK
           AEs                                    AEp, BEp        BEs
           AEs                                    AEp, BEp        BEs
           SK = KDF(ECDH(AEs, BEp))               AEd, BEd         SK = KDF(ECDH(BEs, AEp)
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))     BEd             SK = KDF(3DHE(BIs, BEs, AIp, AEp)
                                                                   Verified = (VCui == DIGEST(AIp, AEp) + AEd == DIGEST(AEp))
          VCS                                                    VCSui
          VCR                                                    VCRui
                                                                   Verified = (VCSui == DIGEST(AIp, AEp) + AEd == DIGEST(AEp))


t4        AIs, MK                                AIp, BIp        BIs, MK
t4        AIs, MK                                AIp, BIp        BIs, MK
           SK                                                      SK
           SK                                                      SK
          VCR                                                    VCRui
          VCRui                                                 
          Verified = (VCRui == VCR)                             
</pre>
</pre>


'''Notes:'''
'''Notes:'''
* The authcode (VC) is a digest of Client A's identity key and ephemeral key. This code must be entered on a registered device to verify the user is in possession of the device requesting authorisation. If the authcode displayed by Client A matches the VC value generated on Client B and the digest of Client A's public key matches Client A's hash commit then a man-in-the-middle attack is highly unlikely.
* The authcode (VCS + VCR) is a digest of Client A's identity key and ephemeral key and a random value respectively. This code must be entered on a registered device to verify the user is in possession of the device requesting authorisation. If the authcode displayed by Client A matches the VCS value generated on Client B and if Client A's hash commit matches the digest of Client A's public key then a man-in-the-middle attack impersonating Client A is highly unlikely. Finally if the VCRui value returned to Client A matches the original VCR random value then a man-in-the-middle attack impersonating Client B is highly unlikely.
* To minimise errors during user input the authcode can be represented using a word list, i.e. [https://en.wikipedia.org/wiki/PGP_word_list PGP], [http://world.std.com/~reinhold/diceware.html Diceware], [https://tools.ietf.org/html/rfc1760 S/KEY] or optionally scanned using a QR code.


'''ClientAuthV2Verifier JSON'''
'''ClientAuthV2Verifier JSON'''
Line 430: Line 446:
</pre>
</pre>


<span id="Key_Rotation_Protocol_v2"></span>
===Key Rotation Protocol===
===Key Rotation Protocol===
<span id="Key_Rotation_Protocol_v2"></span>
TODO
TODO


Nickel chrome
113

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1111101"

Navigation menu