Why is the private key not directly encrypted by the KEK?

rushedhorizon
rushedhorizon
Community Member
in Families

I'm currenlty reading the security white paper step by step and after a google search about the topic "MUK = KEK" i found this discussion: https://1password.community/discussion/comment/451590#Comment_451590

That's how I've understood it so far:
1. Vault key copy is encrypted by the public key
2. The private key is encrypted by the MUK
3. The MUK is encrypted by the KEK
4. The KEK is derived from the master password + secret key

Why is the private key not directly encrypted by the KEK?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • ag_tommy
    ag_tommy

    @rushedhorizon

    I have passed your questions over to the team members who can best answer them. Please be patient and someone will be with you as soon as possible.

  • rushedhorizon
    rushedhorizon
    Community Member
    edited July 2021

    Thanks @ag_tommy for the quick answer and passing the question. I look forward to hearing more!

  • rickfillion
    rickfillion

    That's how I've understood it so far:
    1. Vault key copy is encrypted by the public key
    2. The private key is encrypted by the MUK
    3. The MUK is encrypted by the KEK
    4. The KEK is derived from the master password + secret key

    Why is the private key not directly encrypted by the KEK?

    Not quite.

    1. Vault key is encrypted by the KEK's public key
    2. The KEK's private key is encrypted by the MUK
    3. The MUK is derived from the Master Password + Secret Key

    I hope this helps.

    Rick

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    When you have a long chain of keys, each encrypting the next in the chain, you can call anything that encrypts keys as a KEK (Key Encryption Key). The convention is to use the term "KEK" for something early in the chain, and so it probably makes for sense to refer to the MUK as a KEK even thought the encryption key pair of the personal key set is also just used to encrypt vault keys. So the terminology here is always a bit rough.

    1. Your password and your secret key are used to derive the MUK
    2. The MUK is used to decrypt a symmetric key that we don't have a name for and so call it the "Symmetric Key" (even though there are lots of other symmetric keys)
    3. That key that we don't have a name for is used to decrypt the private part of your encryption key pair
    4. Your encryption key pair is used to decrypt your vault key
    5. Your vault key is used to decrypt your data.

    So @rushedhorizon may be asking why do we have both the MUK and the unnamed symmetric key. The answer is because the private part of the encryption key pair isn't the only thing that is encrypted with unnamed symmetric key.

    We need to return to the notion of a personal keyset. As a Golang type your encrypted personal keyset has a structure (I've cut out a couple of things so that we can focus on the parts that are needed).

    type EncryptedKeysetV1 struct {
    EncSymKey    *JweB  
    EncPriKey    *JweB   
    PubKey       *jwk.RSAPublicKey
    EncSPriKey   *JweB         
    SPubKey      *jwk.ECDSAPubKey
}

    The EncSymKey is the encrypted unnamed symmetric key. It can be decrypted with the MUK, and once decrypted it can decrypt both the EncPrivKey (which is the private part of the key pair used for encrypting vault keys) and the EncSpriKey (which is the private part of your signing key pair). Having this layer of indirection means that if your MUK changes (due to a change of email address, a change of account (master) password, or a change of secret key) the only thing that we need to change in the stored encrypted keyset is the Encrypted Symmetric Key instead of having to change both the Encrypted Private Key and the Encrypted Private Signing Key. That makes is much easier to ensure that your data is in a consistent state by only having the change one field.

    So really, this is there because we wanted to include a signing key pair as well as the vault key encryption key pair in the personal keyset. We haven't made a great deal of use of signing keys in ways that are visible, but we knew from the outset that we would want multiple keys (or key pairs) in the personal keyset. If we only had the one key pair in the personal keyset, we could encrypt the private part of the one single key directly with the MUK, but adding this additional level of indirection gives us more flexibility.

This discussion has been closed.