Reduce skew in local sealing

[cjen1-msft]

One issue with the current implementation of local sealing is that the sealed secrets are written in the commit hook for updated ledger secrets.
This ensured uniformity between the replicas and the primary, however if there is a delay between writing the ledger entry with a new secret, also subsequent chunks, and writing the sealed secret, then that is a period of vulnerability for the node where if it fails it will be unable to recover the ledger.

The optimal option would be to tie the sealed secrets directly to the ledger, with the obvious action being to store the sealing key alongside the node data, and the primary uses that to seal the secret into the ledger for that node.
However this would require an asymmetric key, and the key derivation on SNP gives us a symmetric key.

One possible option here is to store the sealed secret in the transaction header of the ledger secret rekey transaction, for just that node's on-disk copy.
This would then keep the sealed ledger secret directly in sync with the ledger, preventing skew from occurring.
Additionally this would make rollback work fully with the sealed secrets.

[cjen1-msft]

Some analysis of our current ledger entry management later:

• An entry is a <header, public, private> and header has a flags field which could extend this to <header,public,private,secret> where only the header public and private are digested.
• However, although there is a header.size, and header.public_domain_size, there is no header.private_domain_size.
• This means that current parsing code assumes that the remainder of the entry must be the private domain.
• Hence there is no real way to pack the secret into the current ledger entry format.
• And there is no way to get the current parsers to ignore an entry, so no magic secret entry that is ignored by most code, and a flag to say that the next entry is the secret.

This means that unless we rev up the ledger format, I don't see any backwards compatible way to store the sealed secrets within the tx context.

[cjen1-msft]

Cédric Fournet suggested an alternative which is very promising!

To run through the chain of keys

• VCEK derived from TCB and chip local secrets provisioned by AMD
• DerivedKey: SNP derived key from VCEK + TCB Version + Measurement + Host Data
• SealingKey: KDF on Derived Key, including label
• RecoveryKey (public), PrivRecoveryKey (private): New random asymmetric key
• SealedRecoveryKey: encrypt PrivRecoveryKey using SealingKey

In the ledger (node info) store the RecoveryKey and the SealedRecoveryKey ciphertext.

The primary maintains a ledger secret wrapping key which is encrypted by the public RecoveryKey.

A recovering node derives the SealingKey, decrypts the SealedRecoveryKey using SealingKey yielding PrivRecoveryKey which can then be used to decrypt the ledger wrapping key recover the ledger.

This approach has the benefit of ensuring that no private information needs to be sent over the network or stored in the ledger.
Additionally only the ledger secrets sealed on a given CPU can be unsealed on that CPU.

[cjen1-msft]

This is the proposed flow, where only the Storage in ledger box is persisted in the ledger.

flowchart TD
    subgraph SNP["SNP Platform"]
        VCEK["VCEK<br/>(Versioned Chip Endorsement Key)"]
        TCB["TCB version"]
        Measurement["Measurement"]
        HostData["Host Data"]
        DerivedKey["Derived Key<br/>(SNP MSG_KEY_REQ)"]
    end

    subgraph KeyDerivation["Key Derivation"]
        Label["Label:<br/>'CCF AMD Local Sealing Key'"]
        SealingKey["Sealing Key<br/>(HKDF-SHA256)"]
    end


    subgraph Sealing[" "]
        RecoveryKeyPair["Generate Random EC Key Pair"]
        SealedPrivateKey["Sealed Recovery Key<br/>(AES-GCM encrypted)"]
        PublicKey["Public key<br/>(plain text)"]
    end

    subgraph Ledger["Storage in ledger"]
        LPubKey["SealedRecoveryKey::<br/>pubkey"]
        LSPrivKey["SealedRecoveryKey::<br/>ciphertext"]
    end

    %% Derived Key from SNP
    VCEK --> DerivedKey
    TCB --> DerivedKey
    Measurement --> DerivedKey
    HostData --> DerivedKey

    %% Sealing Key from KDF
    DerivedKey -->|"ikm"| SealingKey
    Label -->|"info"| SealingKey

    %% Sealing
    RecoveryKeyPair --> PublicKey
    
    SealingKey -->|"key"| SealedPrivateKey
    RecoveryKeyPair -->|"plaintext"| SealedPrivateKey
    PublicKey -->|"aad"| SealedPrivateKey

    PublicKey --> LPubKey
    SealedPrivateKey --> LSPrivKey

Loading