update Caliptra.md #253
update Caliptra.md #253
Conversation
The committers listed above are authorized under a signed CLA. |
coach-bin
force-pushed
the
insecure-state
branch
from
c5b6dfd to
9e6d576
Compare
|
@Bryankel, @andreslagarcavilla |
|
On the question you asked on point number 1, if debug path to SoC is open, our stance is that no production secrets (assets) should exist. Even though everyone intends to do right thing, side channel paths have exposed secrets before. So if SoC is in debug state, Caliptra should also have that debug mode information to clear the secrets. Also we don't want to change the architectural nomenclatures in the spec without prior discussions as it will have confusion for underlying development work since all of us have been aligned on what these names mean. We understand that each company has a different naming convention but we request you to adhere to the existing nomenclature. |
Thanks for your feedback. I agree with the concerns raised in point number 1. However, I’d like to better understand the specific paths that could lead to a secret being exposed. Is the concern focused on scenarios where the protection mechanisms for Caliptra assets are not properly implemented? Or are there potential paths for exposure even when the protection is functioning as intended? For example, even if the SoC’s JTAG is open in the Caliptra DebugLocked state, it’s hard to imagine how an attacker could gain a meaningful advantage. (even though I do understand the intention behind the concern, I didn't fully understand the path we're concerning) And how should the scope of the SoC debug state be defined? Since debug capabilities differ across vendors, it may be difficult to define this in a generic way. However, this opens the door for subjective interpretations as well. Would it be sufficient to recognize the debug state simply as the SoC JTAG being enabled? If we can clearly identify the paths through which secrets might be exposed, it could help define the scope of what should be included in the debug state. Regarding on point number 2, it's not a big deal, but the spec has definitions of 'insecure' and all the statements are using 'insecure', but only one statement is using 'unsecured'. |
Changing SoC 'debug state' to 'insecure state'
I'm not entirely sure if Caliptra and the SoC really need to be synchronized regarding the debug state across all lifecycle stages. For example, if we're in a product manufacturing stage and if there is an environment that ensures secure manufacturing (though defining this itself is also challenging), wouldn't it still be possible to consider the SoC to be in a secure state even if it's in a debug state (e.g., JTAG opened)? Additionally, during manufacturing, the SoC state could transition from debug state to non-debug state. However, should the state of Caliptra and the SoC be synchronized at every moment throughout this process? I feel 'insecure state' might be more appropriate than 'debug state.' Is there a specific reason why it must be the debug state? I'd like to hear your thoughts on this.
Changing Caliptra 'unsecured state' to 'insecure state'
In the Caliptra.md, states are defined as Secure/Insecure. Except for this one statement, the term 'insecure' is used consistently throughout
#252