You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## 🎟️ Tracking
<!-- Paste the link to the Jira or GitHub issue or otherwise describe /
point to where this change is coming from. -->
https://bitwarden.atlassian.net/browse/PM-26459https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2052653095/Draft+Tech+Breakdown+-+DataEnvelope
## 📔 Objective
> [!IMPORTANT]
> The confluence document has a more detailed breakdown. This is a
shortened version.
Consumers want to protect complex structs such as:
- Vault exports
- Ciphers (vault items)
- Organization reports
Currently, they serialize these themselves (organization reports are
serialized as json), and encrypt fields individually. This is slow to
handle during encrypt/decrypt, and complex to maintain. The server now
has to know the same representation as clients. At the same time, this
can be abused by the server omitting certain fields, or swapping
encrypted fields encrypted under the same key.
EncStrings are not the correct abstraction layer. A new abstraction /
API that is safe and easier to use (an impossible to misuse) is needed.
### Security Definition
**Attacker model:** The relevant attacker model here is a fully
compromised server. That’s what E2E encryption / zero knowledge protect
against.
**Security Goals:**
**SG1:** The structure should not be modifiable (malleable)
- Reason: This can be abused by the attacker by tampering with the
encrypted item in (to the developer) unexpected ways
**SG2:** The attacker should not be able to infer anything about the
contents of the structure aside from length
- Reason: We have a “Zero knowledge” product and customers expect their
data to not be readable by anyone but them.
**SG3:** The structure should only be encryptable in the specific
section of code that the developer intends
- I.e it should not be possible to swap an encrypted vault item into an
encrypted “user settings” “slot”, since the behavior here is undefined.
- Reason: Same as SG1
This PR implements a "DataEnvelope". The DataEnvelope solves the problem
of encrypting entire structs. The caller just provides a struct that is
Serializable/Deserializable, and gets back an encrypted blob. The caller
does not decide serialization.
Further, we force the creation of a "content encryption key" by the
interface. This ensures that teams do not create a coupling to keys.
When implementing key-rotation we do not want to re-upload data, but
only re-upload re-encrypted keys, and the content-encryption-key
enforces this key being present.
An example is provided to show usage.
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or
informed the documentation
team
## 🦮 Reviewer guidelines
<!-- Suggested interactions but feel free to use (or not) as you desire!
-->
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry
that's not quite a confirmed
issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or
concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or
indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
---------
Co-authored-by: Daniel García <dani-garcia@users.noreply.github.com>
Co-authored-by: Thomas Avery <43214426+Thomas-Avery@users.noreply.github.com>
0 commit comments