[PM-5693] Migrate SDK to CryptoService #1117
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dani-garcia
force-pushed
the
ps/secure-crypto-service-impl
branch
from
0dc0aa8 to
9a9a3ca
Compare
|
No New Or Fixed Issues Found |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## ps/secure-crypto-service #1117 +/- ##
===========================================================
Coverage ? 59.88%
===========================================================
Files ? 201
Lines ? 14803
Branches ? 0
===========================================================
Hits ? 8865
Misses ? 5938
Partials ? 0 ☔ View full report in Codecov by Sentry. |
dani-garcia
force-pushed
the
ps/secure-crypto-service-impl
branch
2 times, most recently
from
16774b6 to
a77c69e
Compare
# Conflicts: # crates/bitwarden-crypto/src/error.rs # crates/bitwarden-crypto/src/service/context.rs
dani-garcia
force-pushed
the
ps/secure-crypto-service-impl
branch
from
a77c69e to
0c74d80
Compare
dani-garcia
changed the title
This was referenced Oct 22, 2024
dani-garcia
added a commit
to bitwarden/sdk-internal
that referenced
this pull request
Feb 3, 2025
## 🎟️ Tracking https://bitwarden.atlassian.net/browse/PM-5693 ## 📔 Objective Migrated from bitwarden/sdk-sm#979 I've been looking into using `memfd_secret` to protect keys in memory on Linux. The `memfd_secret` API is similar to malloc in that we get some memory range allocated for us, but this memory is only visible to the process that has access to the file descriptor, which should protect us from any memory dumping from anything other than a kernel driver. https://man.archlinux.org/man/memfd_secret.2.en Using this requires changing how we store keys, so this is the perfect moment to go through removing the raw keys from the API surface. ## Changes - Added a `KeyRef` trait and `SymmetricKeyRef`/`AsymmetricKeyRef` subtraits to represent the key types. Also a small macro to quickly implement them. `KeyRef` implementations are user defined types that implements `Eq+Hash+Copy`, and don't contain any key material - `KeyEncryptable/KeyDecryptable` are now `Decryptable/Encryptable`, and instead of taking the key as parameter, they take a `CryptoServiceContext` and a `KeyRef`. This way keys are never exposed to the clients. - `KeyLocator` trait is replaced by `UsesKey`. This trait only returns the `KeyRef` of the key required to decrypt it, instead of fetching the key itself. - Created a `KeyStore` trait, with some simple CRUD methods. We have two implementations, one based on `memfd_secret` for Linux, and another one based on a Rust boxed slice, that also applies `mlock` if possible. - Because both `mlock` and `memfd_secret` apply their protection over a specified memory area, we need a Rust data structure that is laid out linearly and also doesn't reallocate by itself. Also because `memfd_secret` allocates the memory for us, we can't use a std type like Vec (reason is the Vec must be allocated by the Rust allocator [[ref](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.from_raw_parts)]). This basically only leaves us with a Rust slice, on top of which we'd need to implement insert/get/delete. To allow for reuse and easier testing I've created `SliceKeyStore`, which implements the CRUD methods from the `KeyStore` trait on top of a plain slice. Then the actual `mlock` and `memfd_secret` implementations just need to implement a trait casting their data to a slice. The data is stored as a slice of `Option<(KeyRef, KeyMaterial)>`, and the keys are unique and sorted in the slice for easier lookups. - Created `CryptoService`, which contains the `KeyStore`s and some encrypt/decrypt utility functions. From a `CryptoService` you can also initialize a `CryptoServiceContext` - A `CryptoServiceContext` contains a read only view of the keys inside the `CryptoService`, plus a read-write ephemeral key store, for use by `Decryptable/Encryptable` implementations when they need to temporarily store some keys (Cipher keys, attachment keys, send keys...). Migrated the codebase to use these changes in a separate PR: bitwarden/sdk-sm#1117 ## 📸 Screenshots <!-- Required for any UI changes; delete if not applicable. Use fixed width images for better display. --> ## ⏰ 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
dani-garcia
added a commit
to bitwarden/sdk-internal
that referenced
this pull request
Feb 7, 2025
## 🎟️ Tracking https://bitwarden.atlassian.net/browse/PM-5693 ## 📔 Objective Migrated from bitwarden/sdk-sm#1117 Migrate the codebase to the new KeyStore introduced in #7. EncryptionSettings was removed from Client, though it is still used to initialize the KeyStore. Ideally we'd move that initialization code over directly into the crypto crate but this PR is big enough as it is. There are still some things using keys directly and KeyEncryptable/KeyDecryptable, like MasterKey, PinKey, DeviceKey, private key fingerprint. Those would need to be migrated over on a separate PR. We need to remove the rest of the uses of SymmetricCryptoKey from the client crates, then we can remove the internal boxing they are doing, as the keys would be protected by the KeyStore instead. Secrets Manager code should be moved to using the Encryptable/Decryptable interface, as it's encrypting fields one by one, I'll look into doing that on a separate PR. ## ⏰ 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-5693
📔 Objective
Migrate the codebase to the new CryptoService introduced in #979.
EncryptedSettings was removed from Client, though it is still used to initialize the CryptoService. Ideally we'd move that initialization code over directly into the service but this PR is big enough as it is.
There are still some things using keys directly and KeyEncryptable/KeyDecryptable, like MasterKey, PinKey, DeviceKey, private key fingerprint. Those would need to be migrated over on a separate PR.
We need to remove the rest of the uses of SymmetricCryptoKey from the client crates, then we can remove the internal boxing they are doing, as the keys would be protected by the KeyStore instead.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+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 confirmedissue 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