[hw/kmac] Setup kmac for security verification and check for key leakage from keymgr port

[moidx]

Need to ensure there is no way for the keymgr key to logically leak out of kmac.

@tjaychen can provide more context.

[m-temp]

@tjaychen Is this still an issue? Can you provide the context of this issue? Is this related to #6544? cc @eunchan

[tjaychen]

ah i think this is really just a matter of verification, and it is indeed related to that issue (at least part of it).

[m-temp]

@moidx, @tjaychen can we close this, as we move to D2S?

[tjaychen]

@cindychip This is actually more related to the security tool checks where we can check if a signal leaks out in a specific way. Honestly though, I am not sure we have time for this now..

Do you know Cindy?

[cindychip]

@cindychip This is actually more related to the security tool checks where we can check if a signal leaks out in a specific way. Honestly though, I am not sure we have time for this now..

Do you know Cindy?

I agree, it is hard for DV or FPV to track that key leakage. The SPV we explored might be useful, but as for now we do not have any license for that. And I do not think this is a D2S item.

[msfschaffner]

I've relabeled this as a V2S item for now. We can always defer it to a later milestone if needed.

[cindychip]

triaged: methodology enhancement. Icebox.

[ballifatih]

Just tagging @gdessouky and @bilgiday, because we recently discussed a similar idea/issue offline without knowing this issue already exists.

[msfschaffner]

@vogelpi can you PTAL and determine whether to backlog or not? Thanks!

[vogelpi]

In light of recent KMAC changes for M3 (see #22794 ), I think we should take a look at this and do a focused RTL review @andreaskurth, @johannheyszl .

However, I consider anything on top of that (e.g. setting up a new DV environment, new tests etc.) infeasible for M4. I think half a day should be sufficient for the RTL review and I am increasing the priority to P1 because I consider this important.

[johannheyszl]

@ballifatih can we please get your opinion on this?

[ballifatih]

Last year I reviewed Keymgr and KMAC interaction focusing specifically on logical leaks before M2.5 sign-off, with only logical leak being https://github.com/lowRISC/opentitan/issues/17508

Is the scope of this review only the (updated) application interface between keymgr and KMAC? Should we consider all changes since the last year in Keymgr and KMAC?

[andreaskurth]

We should only consider the changes since Earlgrey-ES TO in the review. @ballifatih, would you be able to do that?

[ballifatih]

Sure, I will have a look @andreaskurth.

[vogelpi]

@ballifatih , sorry I haven't been able to provide any support here. Do you think you'll be able to look into this?

[ballifatih]

No problem, I can do the RTL review @vogelpi. I imagine it would be next week, with ongoing HMAC work taking a bit higher priority.

~~Btw, is this issue correctly prioritized? It has P3 label, but you mentioned P1 above.~~ Nevermind, I realized there are two separate priorities one belonging to the issue (P3) and another to the project (P1).

[vogelpi]

Thanks for your feedback @ballifatih . Next week sounds good. I've now removed the P3 label, this was outdated.

[vogelpi]

@vogelpi to ping @ballifatih on the status of this.

[ballifatih]

Hi @vogelpi, I won't be able to do this on M4 deadline, is it possible to push this to M5?

[vogelpi]

Moving this to M5 for risk management.

[johannheyszl]

@m-temp I see you are familiar with the the block. Would you be interested to review the RTL in the next days to gain some additional assurance here? We are tight on resources unfortunately ...

[m-temp]

@johannheyszl I can have a look at the RTL code next week starting on Tuesday. However, I will be out of office the two weeks after, so anything left by the end of next week, someone else must take care of.

[johannheyszl]

Thanks @m-temp! The idea is to review the RTL and prob of findings something should be very low, but educated assurance would help to close it :) Ideally this could take a day max.

[m-temp]

I've traced the key from the keymgr through kmac. In particular, I did this with the diff between master (1df8888a2e0b7c277b67c7dd9f4522560ba7cd73) and Earlgrey-M2.5.2-RC0 (21ce4e9761abdf5c919b46e5ae64a5a8e24992f7) in mind. The only notable change between master and Earl-grey-M2.5.2-RC0 that touched the key/data patch was [kmac] Move DOM multiplier control from keccak_2share to keccak_round However, this only changed the control signals, but not the data flow

To the best of my knowledge, the key from the keymgr only propagates back to the key_mgr via the digest of the app_o port, which is secure due to keccak's properties and not readable by the software. Further the key propagates to the tlram_data, which is -again due to keccak's properties- only a problem for the capacity and this is covered by https://github.com/lowRISC/opentitan/pull/17641/commits/d5ab6b8abdbe34cf253bca4c1aed27f86afda575

[vogelpi]

Thanks @m-temp for doing the analysis and feeding back the results!

I was mostly worried because as of https://github.com/lowRISC/opentitan/pull/22794, KMAC can abort operations if the sideload key becomes invalid during an operation. I believe the key points here are:

• The properties of the Keccak core not allowing to undo the operation (as you mentioned), and
• The conditions / timing of when the digest becomes readable:
  • If the key becomes invalid after the Keccak core started, the core will just complete the hash operation. After finishing, it opens up read access to the internal state. There may be a separate gate outside the Keccak core due to the error condition in the app interface, but it doesn't really matter. We're safe anyway due to the Keccak properties.
  • If the key becomes invalid before the Keccak core is started, we don't start the hash operation and and the Keccak core will never enable read access to the internal state. We're safe, too.

I am now closing this issue. There is nothing more we can do for Earlgrey-PROD here.