MozillaWiki

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

Page Discussion

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

Revision as of 03:48, 17 January 2016

4,428 bytes added ,  17 January 2016
Revised eXfio Peer v2 to reflect candidate B solution
(Added out of band indicator)
(Revised eXfio Peer v2 to reflect candidate B solution)
 
(26 intermediate revisions by the same user not shown)
Line 92: Line 92:
'''Protocol Sequence'''
'''Protocol Sequence'''
<ol start="0">
<ol start="0">
<li>Each client publishes an identity key (AI, BI) and a set of ephemeral keys (AE{1..n}, BE{1..n})</li>
<li>Each client publishes an identity key (AIp, BIp) and a set of ephemeral keys (AE{1..n}p, BE{1..n}p)</li>
<li>Client A generates a new ephemeral key (AE) and randomly selects one of client B's ephemeral keys (BE). Using 3DHE and a KDF, client A generates the shared secret (S) then sends message including own ephemeral key (AE) and identifier for client B's ephemeral key (X). Body can be encrypted with shared secret.</li>
<li>Client A generates a new ephemeral key (AEp) and randomly selects one of Client B's ephemeral keys (BEp). Using 3DHE and a KDF, client A generates the shared secret (SK) then sends message including own ephemeral key (AE) and an identifier for Client B's ephemeral key (BEp). Client B can now also generate the shared secret (SK) and hence the message body can be encrypted immediately.</li>
<li>Client B receives client A's ephemeral key (AE) and identifier for own ephemeral key (BE). Using 3DHE and a KDF, client B generates the shared secret (S) and can then decrypt the message body.</li>
<li>Both client A and client B can now continue to communicate using the shared secret (S) as a session key</li>
</ol>
</ol>
Both Client A and Client B can now continue to communicate using the shared secret (SK) as a session key.


<pre>
<pre>
Line 104: Line 104:
                                                   BE{1..n}p        BE{1..n}s
                                                   BE{1..n}p        BE{1..n}s


t1        AIs                                    AIp, BIp                    
t1        AIs                                    AIp, BIp         BIs
           AEs                                    AEp, BEp        
           AEs                                    AEp, BEp         BEs
          BIp                                                       
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                     SK = KDF(3DHE(BIs, BEs, AIp, AEp))
          BEp = BE[X]p, X ∈ {1..n}                                           
          PT = <message>                                          CT
           S = KDF(3DHE(AIs, AEs, BIp, BEp))  
          CT = ENCRYPT(PT, SK)                                    PT = DECRYPT(CT, SK)
 
                                                                 
t2                                                                BIs
                                                                  BEs ∈ BE[X]s, X ∈ {1..n}
                                                                  AIp
                                                                  AEp
                                                                  S = KDF(3DHE(BIs, BEs, AIp, AEp))
</pre>
</pre>


Line 161: Line 156:
When Alice registers a new device with the Weave Sync server the client first checks if there are other authorised clients, if not it initialises the storage, if so it requests authorisation by following the procedure below.
When Alice registers a new device with the Weave Sync server the client first checks if there are other authorised clients, if not it initialises the storage, if so it requests authorisation by following the procedure below.


# Client A: Create client record with status of 'pending'
<ol start="0">
# Client A: Send ClientAuthRequestMessage to existing authorised clients, i.e. Client B, including authcode digest (ClientAuthVerifier)
<li>Client A: Authenticate to sync server and create client record with status of 'pending'</li>
# Client A: Display authcode to user
<li>Client A: Send ClientAuthRequestMessage to existing authorised clients, i.e. Client B, including authcode digest (AD)</li>
# Client B: User enters authcode when prompted to approve and verify request. Alternatively reject request.
<li>Out-of-Band: Client A displays authcode (AC) and user enters it on Client B
# Client B: On authorisation approved send ClientAuthResponseMessage with sync key
<li>Client B: If authcode (AC) is verified send ClientAuthResponseMessage with sync key</li>
# Client B: On authorisation declined send ClientAuthResponseMessage with auth fail code
</ol>
# Client A: Poll for authorisation response
 
# Client A: On authorisation approved notify user, verify HMAC of Client B record and update client record status to 'approved'
Finally Alice is notified of registration status and if successful client record is updated with status of 'approved'.
# Client A: On authorisation declined no action taken
 


<pre>
<pre>
Line 175: Line 170:


t0        AIs                                    AIp, BIp        BIs, MK
t0        AIs                                    AIp, BIp        BIs, MK
                                                   BE{1..n}p        BE{1..n}s
                                                   BEp              BEs


t1        AIs                                    AIp, BIp        BIs, MK
t1        AIs                                    AIp, BIp        BIs, MK
           AEs                                    AEp, BEp        BEs
           AEs                                    AEp, BEp        BEs
          BEp = BE[X]p, X ∈ {1..n}                                VD
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                     SK = KDF(3DHE(BIs, BEs, AIp, AEp))
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))  
           VC = RANDOM()                                           VD
           VC = RANDOM()
           VD = DIGEST(VC + DIGEST(password))
           VD = DIGEST(VC + DIGEST(password))


t2        AIs, MK                                AIp, BIp        BIs, MK
t2        AIs                                   AIp, BIp        BIs, MK
          AEs                                    AEp, BEp        BEs
(OoB)     VC                                                     VCui = <user input>
          SK                                                      SK = KDF(3DHE(BIs, BEs, AIp, AEp))
          VD                                                      VD
                                                                  VD
                                                                   Verified = (VD == DIGEST(VCui + DIGEST(password)))
                                                                  VC = <user input>
 
                                                                   Verified = (VD == DIGEST(VC + DIGEST(password)))
t3        AIs, MK                                AIp, BIp        BIs, MK
 
</pre>
</pre>


Line 228: Line 223:


== eXfio Peer v2 ==
== eXfio Peer v2 ==
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 an adversary, Eve, having to select a public key without knowing the public key of either Alice or Bob, giving Eve a single opportunity to guess a 4 character base32 authcode with a probability of 1.05 x 10<sup>-6</sup>. Thus making it very difficult to launch a MITM attack without detection.


===Messaging Protocol v2===
<span id="Messaging_Protocol_v2"></span>
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]]
===Messaging Protocol===
Although version 2 of the eXfio Peer protocol requires two round trips it has been designed such that the 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 Client A must assume the session is compromised or exchange additional messages between clients to give the user additional opportunities to enter the correct authcode.


'''Protocol Sequence'''
'''Protocol Sequence'''
<ol start="0">
<ol start="0">
<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 (AIp, BIp)</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 to initiate a verified session sends a message to Client B including a digest of the key (AEd), thereby committing to a specific ephemeral key without revealing it</li>
<li>Client B receives client A's ephemeral key (AEp) and digest for own ephemeral key (BEd). Using 3DHE and a KDF Client B generates the session key (SK) then sends message including own ephemeral key (BEp) matching digest (BEd). Client B can now encrypt/decrypt the message body with session key.</li>
<li>Client B: Generates a new ephemeral key (BEp) and sends a message to Client A including the key (not a digest). Both parties have now committed to a specific ephemeral key without first knowing the key of the other party</li>
<li>Client A receives client B's ephemeral key (BEp). Using 3DHE and a KDF, client A generates the session key (SK). Client A can now encrypt/decrypt the message body with the session key.</li>
<li>Client A: Sends a message to Client B including the ephemeral key (AEp)</li>
<li>Out-of-Band: Client B can now verify the session by confirming that Client A's ephemeral key (AEp) matches the digest (AEd), provided earlier, and using user input to avoid interception, i.e. out-of-band, that an authcode (VCS) derived from Client A's ephemeral key (AEp) and identity key (AIp) has the same value on Client A and Client B.</li>
<li>Client B: Derives a shared secret (SK) using 3DHE and sends an encrypted message to Client A including the status of the verification, i.e. okay|fail, and a random component of the authcode (VCRui) thus proving the response is from the registered device, i.e. Client B. If verification is successful the message can optionally include additional information such as account keys</li>
</ol>
</ol>
Assuming verification is successful Client A and Client B can now communicate using the shared secret (SK) as a session key.


<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                                                
                                                  BE{1..n}d        BE{1..n}s
                                                                  BE{1..n}p


t1        AIs                                    AIp, BIp        BIs
t1        AIs                                    AIp, BIp        BIs
          AEs                                    AEp             BEs
Key        AEs                                    AEd              
          BEd = BE[X]d, X ∈ {1..n}              BEd              BEp
Commit    AEp                                   


t2        AIs                                    AIp, BIp        BIs
t2        AIs                                    AIp, BIp        BIs
           AEs                                    AEp, BEp         BEs
           AEs                                    BEp             BEs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))    BEd             SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           AEp                                    AEd              


t3        AIs                                    AIp, BIp        BIs
t3        AIs                                    AIp, BIp        BIs
           SK                                                      SK
Key        AEs                                    AEp, BEp        BEs
           PT = <message>                                          CT
Verify
           CT = ENCRYPT(PT, SK)                                   PT = DECRYPT(PT)
 
t4        AIs                                    AIp, BIp        BIs
(OoB)      AEs                                    AEd              BEs
           AEp                                                    BEp
           VCS = DIGEST(AIp, AEp)                                  VCSui = <user input>
          VCR = RANDOM()                                         VCRui = <user input>
                                                                  Verified = (VCSui == DIGEST(AIp, AEp) + AEd == DIGEST(AEp))
 
t5        AIs                                    AIp, BIp        BIs
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                      SK = KDF(3DHE(BIs, BEs, AIp, AEp))
          VCR                                                    VCRui
          VCRui                                                 
          Verified = (VCRui == VCR)                              
</pre>
</pre>


'''EphemeralKey JSON'''
<pre>
{
  keyid:    "id of ephemeral key",
  keydigest: "digest of ephemeral public key"
}
</pre>


'''Client JSON'''
'''Notes:'''
* 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.
* By including Client A's identity key in the authcode provides the additional benefit of verifying both keys
 
 
'''Client JSON (compatible with v1 protocol)'''
<pre>
<pre>
{
{
Line 285: Line 294:
</pre>
</pre>


'''Message JSON'''
 
'''Message JSON (compatible with v1 protocol)'''
<pre>
<pre>
{
{
   version:      "version of message record",
   version:      "version of message record, i.e. 1|v1",
   srcclientid:  "id of sender",
   srcclientid:  "id of sender",
   srckeyid:    "id of sender's ephemeral key",
   srckeyid:    "id of sender's ephemeral key",
  srckey:      "sender's ephemeral key (optional after first message, i.e. sequence > 1)",
   dstclientid:  "id of receiver",
   dstclientid:  "id of receiver",
   dstkeyid:    "id of receiver's ephemeral key",
   dstkeyid:    "id of receiver's ephemeral key",
Line 300: Line 311:
</pre>
</pre>


'''SessionRequestMessage JSON'''
'''Verified Session Message JSON'''
<pre>
{
  version:      "version of message record, i.e. v2verified",
  srcclientid:  "id of sender",
  dstclientid:  "id of receiver",
  sessionid:    "id of session",
  sequence:    "sequence of this message in session",
  cipher:      "encryption type, i.e. none|3dhe"
  type:        "message type",
  content:      "message content"
  hmac:        "HMAC of all other message fields"
}
</pre>
 
'''SessionKeyCommitRequestMessage'''
<pre>
<pre>
{
{
   clientid:    "id of client",
   clientid:    "id of client",
   name:        "name of client"
   name:        "name of client",
   srckey:       "sender's ephemeral key",
   keydigest:   "digest of sender's ephemeral key",
   dstkeydigest: "digest of receiever's ephemeral key"
   getkeys:      "when true and session verified account keys will be included in SessionKeyVerifyResponseMessage, optional. See Registration protocol"
}
</pre>
 
 
'''SessionKeyCommitResponseMessage JSON'''
<pre>
{
  clientid:  "id of client",
  name:     "name of client",
  key:      "receivers ephemeral key",
}
}
</pre>
</pre>
Line 313: Line 349:
<pre>
<pre>
{
{
   timestamp:  "time used as input in to verification"
   authcode:  "Random component of authcode entered by user, i.e. VCRui"
  salt:      "salt used as input in to verification"
}
}
</pre>
</pre>


'''SessionResponseMessage JSON'''
'''SessionKeyVerifyRequestMessage JSON'''
<pre>
<pre>
{
{
   clientid:  "id of client",
   clientid:  "id of client",
   name:      "name of client",
   name:      "name of client",
   status:   "okay|fail",
  key:      "senders ephemeral key",
   message:   "ephemeral key okay|ephemeral key mismatch",
}
   dstkey:   "ephemeral key matching dstkeydigest (if status okay)",
</pre>
   auth:      SessionVerifier (if status okay)
 
'''SessionKeyVerifyResponseMessage JSON'''
<pre>
{
  clientid:    "id of client",
  name:        "name of client",
   status:     "okay|fail",
   message:     "ephemeral key okay|ephemeral key mismatch",
   auth:       SessionVerifier (if status okay),
  payload:    Optional. See Registration protocol,
}
</pre>
 
'''SessionCloseRequestMessage JSON'''
<pre>
{
  clientid:  "id of client",
   name:      "name of client”,
  status:    "verified|failed",
  message:  "session verification okay|session verification failed",
}
</pre>
 
'''SessionCloseResponseMessage JSON'''
<pre>
{
  clientid:  "id of client",
  name:      "name of client”,
  status:    "verified|failed",
  message:  "session verification okay|session verification failed",
}
}
</pre>
</pre>


=== Registration Protocol v2 ===
<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. A key difference from the messaging protocol is that to improve user experience we want to avoid the user having to wait for messages to be exchanged, thus the out-of-band step is brought forward as early as possible and is able to take place immediately after Client A has sent the SesssionKeyCommitRequestMessage although it cannot be completed until Client B has received the message, hence good connectivity is required on both Client A and Client B, but not necessarily simultaneously.
'''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 and mitigate against the impersonation of Client A and Client B.


<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 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 SessionKeyCommitRequestMessage to existing device, Client B, including digest of ephemeral key (AEd) and with a getkeys value of 'true'</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>Out-of-Band: User sights authcode displayed on Client A, generated from identity and key ephemeral key and random value, and enters it on Client B</li>
<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: Send SessionKeyCommitResponseMessage to new device, Client A, providing an ephemeral key (BEp)</li>
<li>Client B: If Client A responds with proof of possessing registered device then send ClientAuthV2ResponseMessage including the master key</li>
<li>Client A: Send SessionKeyVerifyRequestMessage to Client B including ephemeral key (AEp)</li>
<li>Client B: Send SessionKeyVerifyResponseMessage to Client A encrypted with a session key derived from the shared secret (SK) and including a status indicating if the identity and ephemeral key component (VCS) of authcode have been verified. If verification is successful include the AccountKeys payload, i.e. master key (MK)</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>
           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                                                  
                                                  BEd              BEs
                                                                  BEp


t1        AIs                                    AIp, BIp        BIs, MK
t1        AIs                                    AIp, BIp        BIs, MK
          AEs                                    AEp             BEs
Key        AEs                                    AEd              
                                                  BEd              BEp
Commit    AEp                                   


t2        AIs                                    AIp, BIp        BIs, MK
t2        AIs                                    AIp, BIp        BIs, MK
          AEs                                    AEp, BEp        BEs
(OoB)      AEs                                    AEd              BEs
           BT                                    BEd              BT
           AEp                                                    BEp
           SK = KDF(3DHE(AIs, AEs, BIp, BEp))                      SK = KDF(3DHE(BIs, BEs, AIp, AEp)
           VCS = DIGEST(AIp, AEp)                                 VCSui = <user input>
                                                                  VCS = DIGEST(SK, BT)
          VCR = RANDOM()                                         VCRui = <user input>
                                                                  VCM = DIGEST(MK, BT)


t3        AIs                                    AIp, BIp        BIs, MK
t3        AIs                                    AIp, BIp        BIs, MK
           AEs                                    AEp, BEp         BEs
           AEs                                    BEp             BEs
           BT                                    BEd             BT
           AEp                                    AEd             VCSui   
          SK                                                      SK
           VCS                                                     VCRui                   
           VCS = <user input>                                      VCS
          VCM = <user input>                                      VCM
          Verified = (VCS == DIGEST(SK, BT))                      VCP
                      + (BEd == DIGEST(BEp))                     
          VCP = VCM                                             


t4        AIs, MK                                AIp, BIp        BIs, MK
t4        AIs                                   AIp, BIp        BIs, MK
                                                                   Verified = (VCP == VCM)
Key        AEs                                    AEp, BEp        BEs
Verify    VCS                                                    VCSui
          VCR                                                    VCRui
                                                                   Verified = (VCSui == DIGEST(AIp, AEp) + AEd == DIGEST(AEp))


t5        AIs, MK                                AIp, BIp        BIs, MK
          SK = KDF(3DHE(AIs, AEs, BIp, BEp))                      SK = KDF(3DHE(BIs, BEs, AIp, AEp))
          VCR                                                    VCRui
          VCRui                                                 
          Verified = (VCRui == VCR)                             
</pre>
</pre>


'''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.
* A QR code including Client A's entire key (AEp) would allow step 2, 3 and 4 to be collapsed into a single step. See [[#Signal (TextSecure) Registration Protocol|Signal (TextSecure) Registration Protocol]] below.


'''ClientAuthV2Verifier JSON'''
'''AccountKeys JSON'''
<pre>
<pre>
{
{
   proof:  "Proof of receiving authcode through out of band channel"
   masterkey:  "time used as input in to verification"
}
}
</pre>
</pre>


'''ClientAuthV2RequestMessage JSON'''
<span id="Key_Rotation_Protocol_v2"></span>
<pre>
{
  clientid:  "id of client",
  name:      "name of client",
  auth:      ClientAuthV2Verifier
}
</pre>


'''ClientAuthV2ResponseMessage JSON'''
===Key Rotation Protocol===
<pre>
No change from V1
</pre>
 
===Key Rotation Protocol v2===
TODO
TODO


Line 434: Line 492:


t3        AEs                                    AEd              BEs
t3        AEs                                    AEd              BEs
                                                   AEp, BEp        Verified = (DIGEST(AEp) == AEd)
                                                   AEp, BEp        Verified = (AEd = DIGEST(AEp))


t4        AEs                                    AEd              BEs
t4        AEs                                    AEd              BEs
Line 440: Line 498:


t5        SK                                                      SK
t5        SK                                                      SK
(OoB)      AVC = DIGEST(SK)                                       BVC = DIGEST(SK)
(OoB)      VC = DIGEST(SK)                                         VC = DIGEST(SK)
           Verified = (AVC == BVC)                                Verified = (AVC == BVC)  
          VCui = <user input>                                    VCui = <user input>
           Verified = (VCui == VC)                                Verified = (VCui == VC)  


</pre>
</pre>
Line 453: Line 512:


t1        AIs                                    AUID, BUID      BIs, MK
t1        AIs                                    AUID, BUID      BIs, MK
(OoB)      AIp                                    BIp              AIp
(OoB)      AIp                                    BIp              AIp = <user input>


t2        AIs, MK                                AUID, BUID      AIp, MK
t2        AIs, MK                                AUID, BUID      BIs, MK
                                                   AIp, BIp           
                                                   AIp, BIp           


</pre>
</pre>
Nickel chrome
113

edits

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