I learn a bit more about the PSC and security Engine. Could you elaborate on the specific that they do?
For example, the developer Guide shows more on secure boot and key management. It doesnt mention the Security Monitor features.
“continually assessing the security status of the SoC” what kind of status? can user determine what to assess and add ports for PSC to service?
“actively monitor known or potential attack
patterns (for example, such as voltage glitching or thermal attacks)” what does the PSC do next if it monitored a pattern? what pattern does it look for? where is that stored? can user set its reaction?
on the Security Engine side, it claims:
“NIST-compliant asymmetric, symmetric cryptography and hashing” is there a CAVP or CMVP number? is there a FIPS-140 cert or ISO equivalent?
“Side channel countermeasures” since SE is a real HW is it implemented on the hardware? what is the countermeasure?
“Hardware Key Access Controls (KAC)” and the keyslot implementation, arent cryptovalues (inclusive of passphrase, keys, FV, or IV) either in the headers or fuses? the control isnt depended on SE, so what is this key access referring to?
>>Q1, the security status of the SoC
as you can see… Secure Boot, there’re PKC, SBK, KEK…etc.
for instance,
PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.
KEKs for encryption keys: they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file.
>>Q2, potential attack patterns
you may refer to The Threat Model.
>> Q3, NIST-compliant asymmetric, symmetric cryptography and hashing
please refer to OP-TEE section.
there’s no FIPS-140 cert or ISO equivalent, may I know what’s the real use-case?
>> Q4, key access
please check Secure Samples for reference, there’s a pair of TA (hwkey-agent) / CA (hwkey-app) for demonstration.
oh see, i was thrown off by “continually”. I imagine Secure Boot being only one-time at boot after the image is out it is not check again or is it?
Under Threat Model, it talks about disk encryption specifically and what it cannot protect against. is the security monitoring really not detecting and checking but PSC uses existing security elements for their own intended purposes? Yet it points to example of glitching and thermal attacks. i am more confused in this aspect.
The OP-TEE section talks more on the implementation approach such as key use for what data and they are good information. My Q3 is more focus on the administrative side. The intend is to have assurance the module that actualize the approach is credible. One example, when I dove deeper into the rabbit hole i found disk encryption uses dmcrypt and cryptsetup. via the Gitlab links <cryptsetup / cryptsetup · GitLab , DMCrypt · Wiki · cryptsetup / cryptsetup · GitLab> i learned that they are not hard module they are softcore. Though i still havent found traces of a certificate…
thank you for the KAC reference. that does answer my question.
Side channel attack countermeasures though, is that something you can explain?
sorry, I’m not fully understand what’s your following up question.
could you please elaborate your question again, or with some real use-case for checking.
I am not understanding the connection from your answers to my questions or misled by the datasheet on the various claims regarding the functions performed by PSC and SE.
Q1, my question is on the 3rd feature: Security Monitor. Words like “periodic security housekeeping tasks, including continually assessing the security status of the SoC” suggest there are on-going detection and reporting. Your respond reference back to the 1st and 2nd features: Key Management and Protections and Trusted Services on Secure Boot. Hence, my follow-up question: is the Secure Boot using fuses and user provided key files continuous and that I did not miss hidden monitoring features that I could leverage?
Q2, is also about the Security Monitor feature. When words like “actively monitor known or potential attack pattern” is used, I felt like I miss out on an amazing feature that the board provide and I just didn’t enable. Hence, I wanted to know more. The reference to the Threat Model section doesn’t appear to be an active, on-the-go type monitoring as suggested. It reads like a design decision during your product development to incorporate disk encryption. it even talks about what kind of threat disk encryption is not designed for. My follow up question to that is to understand if this is a wrong reference or is there no active monitor as claimed?
Q3 has no follow up question. Though I didnt find the additional reference adds to your response but information suffices. I did want to provide you my intention and where such certification trace is used as you have asked.
Q4 has no follow up question either. With your reference, i understood the KAC is referring to the Trusted / Untrusted world and the respective access for TA / CA. Not as much a hardware control like an airgap segregation but a software logical division.
The SCA follow up question is actually in the original post that didnt gather too much attention so I wanted to ask again. To elaborate it further, side channel countermeasures are supposed to be a supported feature by SE. I wanted to know what is done. Are the algorithm executed by a softcore with embedded masking technique? or a physical hard IP implementation where some type of emission mitigation is done? or other type of countermeasure that you can help explain?
I hope that elaborated somewhat, and thanks in advance,
as you can see in the TRM, for instance, [Figure 1.1 Orin Series SoC Block Diagram].
PSC (Platform Security Controller) is a processor responsible for the security features on SoC.
PSC it needs to do periodic security housekeeping tasks like clear unused keys.
Also it will assess the security status of the SoC like memory setting to ensure memory can not be accessed by invalid users.
PSC also sets up firewall to protect assets, and do audit check after firewall programming to prevent potential glitch attack. If any error is detected, PSC will enter turtle and block all access from any source to protect security-sensitive assets.