Confirmed users
632
edits
Loop/Architecture/Context: Difference between revisions
→Information Privacy
No edit summary |
|||
| Line 8: | Line 8: | ||
This section explains the means by which this achieved at the level of information flow. Details are provided in the sections below. See also {{Bug|1132293}}. | This section explains the means by which this achieved at the level of information flow. Details are provided in the sections below. See also {{Bug|1132293}}. | ||
When a Loop client logs into the FxA server, it will obtain a user-specific symmetric key, '''kB''', and an OAuth application identifier. The key '''kB''' is wrapped with the user's account login password. Upon obtaining the key, the FxA client unwraps '''kB''' for use as a master user key. This key is then used to | When a Loop client logs into the FxA server, it will obtain a user-specific symmetric key, '''kB''', and an OAuth application identifier. The key '''kB''' is wrapped with the user's account login password. Upon obtaining the key, the FxA client unwraps '''kB''' for use as a master user key. This key is then used to derive a loop-specific key, kBr. The Loop client then derives a '''kRWrapper''' key via HKDF by mixing in the usage identifier "metadata." | ||
When a client creates a new room, it first generates a new symmetric room key, '''kR'''. The room context information is serialized as a JSON object, and encrypted using '''kR'''. The client uses the | When a client creates a new room, it first generates a new symmetric room key, '''kR'''. The room context information is serialized as a JSON object, and encrypted using '''kR'''. The client uses the KRWrapper key wrap this key via AES-GCM. The encrypted context information and the wrapped room key '''wrap(kR)''' are sent to the Loop server as part of the room creation request; these are stored as part of the room's information. | ||
Upon receipt of the resulting room URL from the server, the client appends the room metadata key '''kR''' to the URL as a URL fragment before storing it locally. | Upon receipt of the resulting room URL from the server, the client appends the room metadata key '''kR''' to the URL as a URL fragment before storing it locally. | ||
| Line 27: | Line 27: | ||
Further information on derivation of '''kB''' can be found at [[Identity/AttachedServices/KeyServerProtocol]]. The proposal for creating application specific keys ('''kBr''') was originally made [https://mail.mozilla.org/pipermail/dev-fxacct/2014-December/001260.html on the fxa-dev mailing list], and this proposal re-uses the terminology outlined in that message. | Further information on derivation of '''kB''' can be found at [[Identity/AttachedServices/KeyServerProtocol]]. The proposal for creating application specific keys ('''kBr''') was originally made [https://mail.mozilla.org/pipermail/dev-fxacct/2014-December/001260.html on the fxa-dev mailing list], and this proposal re-uses the terminology outlined in that message. | ||
'''''Note: The preceding design is predicated on implementing the FxA | '''''Note: The preceding design is predicated on implementing the FxA key API in time for the initial feature landing. This ability is being tracked [https://github.com/mozilla/fxa-content-server/issues/2088 on the FxA github repo]. If this cannot be done in time, we will need to store room-keys client-side, without any mechanism to share them among a user's clients. This is sub-optimal, as it makes it impossible to create a room on one client and view or manipulate information on another.''''' | ||
=== Algorithm Details === | === Algorithm Details === | ||
| Line 42: | Line 42: | ||
Decryption consists of Base64 decoding the "context" field, splitting off the first 12 bytes for use as an IV, and splitting off the final 16 bytes as the validation tag. These are then used as input to the AES-GCM decryption algorithm (along with '''kR'''), the output of which is a JSON object containing fields that correspond to the various room context information fields. | Decryption consists of Base64 decoding the "context" field, splitting off the first 12 bytes for use as an IV, and splitting off the final 16 bytes as the validation tag. These are then used as input to the AES-GCM decryption algorithm (along with '''kR'''), the output of which is a JSON object containing fields that correspond to the various room context information fields. | ||
The "key" field is encrypted and decrypted | The "key" field is encrypted and decrypted using the '''kRWrapper''' key, via AES-GCM. | ||
=== Local Key Storage and Recovery === | === Local Key Storage and Recovery === | ||
One of the consequences of using '''kB''' to encrypt room keys is that we lose the ability to decrypt '''wrap(kR)''' if the user has to reset his FxA password (note: this is only true for password ''resets'', such as in the case of a forgotten password -- it does not apply to password ''changes'', where the user has the old password and is gracefully changing it to a new one). | One of the consequences of using '''kB''' to encrypt room keys is that we lose the ability to decrypt '''wrap(kR)''' if the user has to reset his FxA password (note: this is only true for password ''resets'', such as in the case of a forgotten password -- it does not apply to password ''changes'', where the user has the old password and is gracefully changing it to a new one). | ||
As a mitigation against this loss, clients will cache room keys locally. This applies to both keys created by the client as well as keys learned from the Loop server. This allows users to retrieve encrypted context information as long at they haven't both forgotten their password and lost their Firefox profile. To keep the keys on the Loop server valid in the face of password resets, clients will validate the value of wrapped room keys whenever they receive room information. In the case that | As a mitigation against this loss, clients will cache room keys locally. This applies to both keys created by the client as well as keys learned from the Loop server. This allows users to retrieve encrypted context information as long at they haven't both forgotten their password and lost their Firefox profile. To keep the keys on the Loop server valid in the face of password resets, clients will validate the value of wrapped room keys whenever they receive room information. In the case that decrypting their locally-stored copy of '''kR''' with '''kRWrapper''' yields a different result than the value stored in the Loop server, the client will update the room information with a corrected wrappedKey value. | ||
<center>[[File:Loop-keys-store.png|Local key storage and audit]]</center> | <center>[[File:Loop-keys-store.png|Local key storage and audit]]</center> | ||