[doc] Cryptographic Mailbox

[swenson]

This adds sections describing the Cryptographic Mailbox system, its storage system, and related commands.

I cleaned up a little bit of the overview sections for what is new in the 1.1 and 2.0 runtime firmware to help keep things organized.

[swenson]

I believe I have addressed the comments relevant to the cryptographic mailbox commands. I'm creating a separate PR for the manifest-based image auth doc updates, as suggested.

PTAL.

[swenson]

Apologies for merging a little early, but we wanted to have this in before the deadline. I'm happy to do further revisions and have more discussions.

[bluegate010]

How are the coordinates encoded? Big-endian?

[swenson]

Yes, big-endian.

[raghuncstate]

what threat is this intended to solve/mitigate? it is defense in depth mostly?
Asked another way, what happens if you leave it unencrypted? presumably, a runtime attack on FW has access to the key (indirectly?) used to encrypt? or is that not hte case?

[swenson]

The context might have intermediate state that is sensitive. For example, intermediate GHASH computations in AES could be used to reveal the additional authenticated data, which may or may not be sensitive.

The authenticated encryption is more defense in depth.

[raghuncstate]

thx, agree on the intermediate state being sensitive, but was wondering HOW you envision an attacker getting access to it, mostly to try and answer the question: if the attacker can get access to context data, can the attacker also not get access to the key?
What makes getting access to the key (or its handle) more or less difficult than having access to the context data?

Note, not asking for change, trying to better understand thought process behind decision to do so.

[raghuncstate]

i think i may have misread/misunderstood. I thought contexts are stored in the data storage, but i see that you provide it as output in commands below, so the question above may be moot, but would appreciate confirmation that data storage below, is for the KEYS, not contexts :)
Do we care about replay protection of the contexts?

[swenson]

Contexts could be stored insecurely in the SoC, so they are more vulnerable to being intercepted.

In this version, the keys are only accessible through handles, but the keys themselves are stored only in DCCM in Caliptra. (This may change so that the keys are also returned to the SoC in encrypted form to minimize storage requirements in Caliptra.)

Contexts are also encrypted and authenticated. For many of the commands, I don't think we're too worried about replay attacks (e.g., SHA). But, I think you're right that some commands could use replay attack protection. For instance, with AES-GCM, if you have a context and an associated ciphertext block, you could replay the context with a new plaintext and use that to recover the other plaintext.

Theoretically this is all over a trusted channel, so these attacks may not be part of the threat model, but we should be able to apply some internal counters in DCCM to help with this. I've filed an issue to address this: #1761

[raghuncstate]

can you elaborate on why IV reuse is not a problem? if you store the different data twice at the same offset with same size, would you not generate the same key and same IV again to encrypt the new data?

[swenson]

I noticed that after I wrote it. It's definitely true (if the data being stored is the same length).

I'm debating a few different ways to fix this, but all solutions I can think of essentially involve storing the IV or a part of the IV either in DCCM or in the CMID.

[bluegate010]

if you store the different data twice at the same offset with same size, would you not generate the same key and same IV again to encrypt the new data?

I don't think you would, right? Because the CMID does not hold any data related to the key itself, just the offset and size. So if you store two different keys with the same size at the same offset, the same key will encrypt the same CMID.

[raghuncstate]

okay, maybe i misunderstood, what this is encrypting. I thought this is a key, being derived, to encrypt context data. The key being derived, look like a deterministic key HKDF(CDI_RT, "CMID||block offset||size"), and that key would AES GCM the context data (which can be different data bits).
I did not think this is the key used to encrypt the CMID itself, given to the user.

[swenson]

The scheme here was K = HKDF(CDI_RT, block offset || size), which would then be used to encrypt that portion of DCCM that holds the key associated with the CMID.

But I think we're going to move away from storing keys in DCCM shortly, so this shouldn't matter. Though we will still have to be very careful about IV reuse.

[raghuncstate]

do we care that data size field may become an unaligned access depending on context size?

[bluegate010]

I think we could define a fixed-size context struct, sized to hold the largest context data possible, and make sure it's aligned properly.

[swenson]

I worry about a fixed-size struct, as it means that if we define a new command or want to redefine the context for one command, we break compatibility with all commands that use contexts. With the variable-sized contexts, we wouldn't need to break compatibility if we needed to add a field to any context.

But we can stipulate that all contexts have sizes that are multiples of 32 bits.