[PM-20361] Signature keys #207
Conversation
|
Great job, no security vulnerabilities found in this Pull Request |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #207 +/- ##
==========================================
+ Coverage 70.46% 71.40% +0.93%
==========================================
Files 215 224 +9
Lines 17084 18081 +997
==========================================
+ Hits 12038 12910 +872
- Misses 5046 5171 +125 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
quexten
force-pushed
the
km/cose-signatures
branch
from
f8044bd to
c9b80df
Compare
|
Since there is no consumer I've only looked at the code from an idiomatic rust perspective. I would prefer if we have a working implementation done before merging this since we otherwise won't get a full perspective review. |
|
Brought up-to-date with the wasm client + mobile client merging changes. |
Co-authored-by: Daniel García <[email protected]>
…l into km/cose-signatures
|
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-20361
📔 Objective
Signing operations
This PR adds signing/verifying operations, and keys, including serialization to COSE for both the keys, and for the signatures. We enforce strong domain separation by adding a namespace. This ensures not having to worry about cross-protocol attacks / swapping messages between contexts.
Two signing operations are provided; sign and sign detached. The former signs an object and returns a signedobject, containing the payload. To get the payload, the signature must be verified (guaranteed by the interface). The latter returns signature and serialized message. This is useful when multiple signatures are needed for one message; in this case a countersignature can be created, so that we can have multiple signatures for the same object, in case a trust relationship needs to be proven in multiple directions.
Signing is implemented in 3 layers documented at the top of
sign.rs.The high level layer accepts a struct that is serializable and namespace, and returns a signature and the serialized representation, or the signedobject. The serialization may not be canonical, so the consumer should store the serialized representation instead of their input struct. The reverse operation - verify / getverifiedpayload - returns the deserialized struct.
The middle layer accepts byte array plus namespace.
The low layer is the direct implementation of the signature, and accepts byte array (no namespace). This ensures that implementing a new signature scheme only requires implementing this low level operation.
The one implemented algorithm type is ed25519.
Keys are represented as enums such that it is easy to add other signing key types (ML-DSA for post-quantum crypto, PoC here: #216) later on.
The signature is represented as a Cose Sign1 message (https://www.rfc-editor.org/rfc/rfc9052.html#name-signing-with-one-signer).
The namespace is separated by setting the protected header. Since this is included in the signed data, and since this is validated on verifying the signature, and since the values are unique, domain separation is enforced. We only ever want to expose the safe function outside of the crate (if we even expose it out of the crate).
SignedPublicKey
Public encryption keys should have their owner identity verified. Thus, a new SignedPublicKey that is a signed object containing the public key is created. Consumers must verify the signature before being able to access the public encryption key.
Public key changes
Public keys are hardcoded at the moment to expect DER encoding and RSA-OAEP encryption. This is not the case long-term, and the signature format above makes this clear by including format types.
This PR also includes some prep-work, applying the same per-encryption-time enum variant split in the asymmetric encryption keys. Follow-up work can further clean this up, and clean up the folder structure / file split.
⏰ 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