FR: PCR-like functionality

[tomoveu]

Hello everyone,

I am really excited to see the project come to fruition! One year just flew by.

What is the likelihood of adding registers with special reset condition?

Or simply put, register that reset only on power-on.

If we add such registers, then we could have the logic to allow only a single operation during normal mode for these registers, exactly like a "PCR Extend" in the Trusted Platform Module(TPM).

Reasoning - There are many applications that need TPMs, but do not really need the physical tamper protection that makes them difficult to manufacture (and require NDAs). OpenTitan with PCRs would fill in a big gap and help make IoT/IIoT systems trustworthy. It does not have to be a TPM, but the PCR functionality is vital for system integrity.

[tjaychen]

could you elaborate a bit more on the specifics of 'power on'? In general we will have a few classes of storage elements that respond differently to reset conditions.

For example, do you consider power on literally when someone powers up the main IO rails to the device? Or would it be some kind of main reset to the system?

Naively speaking, we will likely have registers that survive low power, system watchdogs and possibly other triggers. I'm assuming right now that nothing will survive a true power on since that will wipe out the power source in the system. It sounds like as long as we have registers that behave like so, it would satisfy your requirements?

[tomoveu]

@tjaychen thanky you for responding, really good question.

To formulate PCR-like register as requirements:

Set of 16-24 registers (typically, but we can start with less) Each register no less than 3 octets Registers can survive low power mode Register can be reset only by the boot sequence of the chip Reset values of the registers can be all zeros or all ones, typically zeroes for 0-15 are preferred and ones for 16-23

I suppose there will be a way for the user to invoke a reboot without actually power cycling the chip? How likely it is to squeeze 24 registers * 24 bytes?

Having PCR-like registers that can be reset to zeroes only on power-on will definitely have applications, but not sure if this is needed to reproduce PCR-like functionality.

Details: PCRs in TPM are cleared during TPM_Reset or TPM_Restart. In essence, a TPM_Startup command is issued during the TPM boot process and the PCRs are cleared. This command can latter be issued to the TPM, but it is essentially invoking a reboot of the whole chip without the actual power-on-off sequence.

Let me know if I can provide more information. I will try to set-up the project on one of my FPGA dev boards in the mean time. Thank you for looking into this :)

PS: Just remembered that yesterday I published this article on the topic. Essentially, why do we need Trusted Computing. Having PCR-like registers in OpenTitan would make it useful for the scenarios here as well - https://www.linkedin.com/pulse/exploiting-iot-devices-secure-boot-why-products-do-have-dimitar-tomov/

[cdgori]

Just some more detail about how PCRs are used in TPM, in case this is helpful: https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/s https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/switch-pcr-banks-on-tpm-2-0-devices witch-pcr-banks-on-tpm-2-0-devices https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/switch-pcr-banks-on-tpm-2-0-devices

https://security.stackexchange.com/questions/39329/how-does-the-tpm-perform-integrity-measurements-on-a-system

On Thu, Dec 12, 2019 at 4:48 PM Dimitar Tomov notifications@github.com wrote:

@tjaychen https://github.com/tjaychen thanky you for responding, really good question.

To formulate PCR-like register as requirements:

Set of 16-24 registers (typically, but we can start with less) Each register no less than 3 octets Registers can survive low power mode Register can be reset only by the boot sequence of the chip Reset values of the registers can be all zeros or all ones, typically zeroes for 0-15 are preferred and ones for 16-23

I suppose there will be a way for the user to invoke a reboot without actually power cycling the chip? How likely it is to squeeze 24 registers * 24 bytes?

Having PCR-like registers that can be reset to zeroes only on power-on will definitely have applications, but not sure if this is needed to reproduce PCR-like functionality.

Details: PCRs in TPM are cleared during TPM_Reset or TPM_Restart. In essence, a TPM_Startup command is issued during the TPM boot process and the PCRs are cleared. This command can latter be issued to the TPM, but it is essentially invoking a reboot of the whole chip without the actual power-on-off sequence.

Let me know if I can provide more information. I will try to set-up the project on one of my FPGA dev boards in the mean time. Thank you for looking into this :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/opentitan/issues/1112?email_source=notifications&email_token=AJBZS7EVY5SAT27BC2UUIBDQYLLWNA5CNFSM4JTRYWC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGYRGFY#issuecomment-565252887, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJBZS7GZ5GZQ7F2TOHQ4MQ3QYLLWNANCNFSM4JTRYWCQ .

[tomoveu]

I am really happy that there is more interest to this FR. Let me briefly explain what PCRs are used for.

Low level:

• PCRs enable us to store a hash of arbitrary input data.

Sounds pretty standard, so why are PCRs so useful?

• Because PCRs allow only one single operation - PCR_Extend, name of cryptographic operation
• PCRs are (almost) impossible to tamper with

Why PCRs are difficult to tamper with?

• Every PCR_Extend operation is based on new input data and the previous hash(PCR_Extend result)
• The cryptographic operation is done by the HSM/TPM, not the host. So, the host software can not tamper the output, it only feeds the HSM the binary data. We trust the HSM, in our case this would be OpenTitan.
• For an attacker to try to get an exact hash value in a PCR, he would need to now the number of PCR_Extend operations and know the binary data used in these operations in order to repeat the exact sequence. One step or one bit deviation, we would get a mismatch, when checking the hash result with what we expect.

Sounds too good to be true?

• Of course there is a certain way to read PCRs data out in a secure way. It is called TPM_Quote, but let's go one step at a time. Because the core of everything is to have PCR-like registers. From there, we could enable the different possibilities in software, hardware or some mixed approach.

Applications:

• Measured boot - Make sure the sequence of events during boot is the expected one. Remember, one deviation and we would know.
• System integrity - Make sure the system is running with the expected configuration. This is one of the use cases I am trying to bring with our TPM Developers community*

To be exact, measured boot is part of creating system integrity, but is often used standalone.

Please let me know if you have other questions or comments.

*We are having a poll to add OpenTitan section for discussions in our community forums and the result is overwhelmingly positive :)

[sjgitty]

@tjaychen let's at least track this as we're looking at our future storage requirements.

[tjaychen]

@tomoveu

thanks for the feedback! Let me just describe what I think OT will have long term. I believe the PCR functionality can be satisfied.

In OT, we will have registers that survive everything except for power on reset. We may also have retention memories that behave approximately the same (with the difference being if you pull the power on these, the initial state won't be all 0's).

My thinking is that the retention memories could also be used to implement PCRs, since we could just have a piece of early OT software initialize the memory contents to all 0's if it detects a power on reset event. What do you think?

Another question is whether you feel an OpenTitan watchdog (ie, the OpenTitan software itself has hung) should also wipe out the contents of the PCR.

[tomoveu]

@tjaychen wow, you are asking the though questions! :)

A. I am loading the OpenTitan with operations, so the Watchdog is hit, my PCRs are cleared and my System integrity check fails = Denial of Service?

B. I am risking the OpenTitan to hang, so the PCRs retain their last values until power-on reset/reboot. What is the danger here? Someone coudl read the PCR values? Not an issue. They are intentionally a hash, but ... hmmm , have to think about this one.

Maybe, someone could hang the OpenTitan on purpose, but then again, that's DoS. On other hand, if someone hangs the OpenTitan, even if we have the latest PCR value, it can not be used. Because the OpenTitan can not perform OT/PCR read, so I wonder what could be the attack in that scenario.

I definitely like the idea to use watchdog to prevent some undesirable action and/or protect data. Have to think about it more.

@sjgitty thank you for the chance to contribute to OpenTitan :)

[tjaychen]

@tjaychen wow, you are asking the though questions! :)

A. I am loading the OpenTitan with operations, so the Watchdog is hit, my PCRs are cleared and my System integrity check fails = Denial of Service?

B. I am risking the OpenTitan to hang, so the PCRs retain their last values until power-on reset/reboot. What is the danger here? Someone coudl read the PCR values? Not an issue. They are intentionally a hash, but ... hmmm , have to think about this one.

yeah so the question really boils down to if you consider a watchdog a possible security attack. For example if someone is trying to mess with the system in some unexpected way. In general, I think watchdog should happen very rarely in a normal functional world... that's why my question on whether it should wipe out the PCRs. I guess this also relates to the question on what kind of effect OpenTitan should have on the system should it watchdog..that's probably a very application specific question?

Maybe, someone could hang the OpenTitan on purpose, but then again, that's DoS. On other hand, if someone hangs the OpenTitan, even if we have the latest PCR value, it can not be used. Because the OpenTitan can not perform OT/PCR read, so I wonder what could be the attack in that scenario.

I definitely like the idea to use watchdog to prevent some undesirable action and/or protect data. Have to think about it more.

@sjgitty thank you for the chance to contribute to OpenTitan :)

[tomoveu]

@tjaychen I come from industrial background, where if something could go wrong we assume it eventually always will. Therefore, we always enabled the Watchdog as final measure, in case the system fails it can reset/reboot fast enough to start (re)acting. Extremely important in (some) industrial environments, where once you lose control of some processes, there is no going back.

Now, on a HSM such as OpenTitan.... how does that translate, well I need bit more information. Please tell me what are the current values to these blitz questions:

1. What is the typical boot time OpenTitan has?
2. Could I set/define the Watchdog period?
3. What is the minimal Watchdog time (I could set)?

To me, a best case scenario - Watchdog time is < 1 ms, Boot time is < 20 ms. I would have the Watchdog enabled by default, because whatever happens, I can recover my system.

Of course, application context matters. There are certain applications where a hanged OpenTitan would not be critical at all, while for one of our use cases - network access solution, it could create a DoS, someone who has the rights to access a resource is locked out, and so on. In this scenario having the Watchdog would prevent ~DoS.

In case OpenTitan is used for storing the private key for VPN/SSH..... well it will be an annoyance, but a manual reboot, command issued on SPI would not be a problem.

Hope my industrial-specific feedback helps, I welcome comments and criticism =)

[tjaychen]

thanks for the feedback! To your questions...those aren't things we've completely finalized yet for a final product. but ...

1. assuming a boot time < 20mS (assuming this means jumping out of boot rom and into mutable software) i think is very reasonable.

2. the watchdog period will definitely be programmable, while 1mS seems small to me (I've worked mostly on consumer products, so that bar is very different), should definitely be doable

3. the minimal watchdog time will most likely be a few cycles of its native running clock. So it will likely range from uS range all the way to hundreds of mS if needed. This should be very flexible.

I should mention also that perhaps the behavior of the PCR during a watchdog need not be something we have to decide here. If the software recovery is fast (and really it should be), couldn't the first stage software make the decision to wipe the PCRs or not based on reset information? Whether our power plug has been pulled or it was actually a watchdog reset should be information that we expose to the software world.

[tomoveu]

Indeed @tjaychen This is how the TPM does it. I myself would vote for that option too.

During the boot process, there is a check on the power flags and if they indicate PoR, TPM_Startup/PCR_Clear procedure is issued. We could totally write that ourselves in our firmware, since we will have the Power Status register exposed to us, as you mentioned.

With the difference that most TPMs are really, quite, slow. For personal computers this is not really an issue, because during POST/UEFI initialization so many things are happening that there is plenty of time to boot. In our use cases, to name a few: Industrial IoT , Gateway(Networking); probably we would not have that luxury. So, I really like the guidelines in (3.). Letting the user to chose from uS to mS is perfect flexibility.

[tjaychen]

sounds great!

[tomoveu]

I will set up OpenTitan on one of my Artix-7 dev board. If there is anything you need me to test let me know. Especially, if related to this FR. I will also be looking to contribute once I get comfortable with the current design.

Is there a mailing list / irc for the opentitan community, way of communication between members if I hit setup issues for example?

By the way, we added "OpenTitan" section in our TPM Developer community - https://developers.tpm.dev/topics/1731622 Feel free to use it, there is live chat, as well and posts, polls and question options. That's it from me for now.

[sjgitty]

I will set up OpenTitan on one of my Artix-7 dev board. If there is anything you need me to test let me know. Especially, if related to this FR. I will also be looking to contribute once I get comfortable with the current design.

@tomoveu thank you for the offer. Feel free to poke around the issues for areas to contribute. That captures the majority of the low hanging fruit. More will be coming of course.

Is there a mailing list / irc for the opentitan community, way of communication between members if I hit setup issues for example?

Standard GH issues under OpenTitan project are the best means at this point for getting help on particular setup problems. Be sure to use [subject brackets] to target the issue area for fastest response, such as [UART] question about interrupts.

Thanks!

[moidx]

Closing this as TPM functionality is something that can be implemented as an application in OpenTitan.

As a side note, there is now SPI TPM mode support available. Feedback is always welcomed. Please take a look at lowrisc/opentitan#7848.

https://docs.opentitan.org/hw/ip/spi_device/doc/#tpm-over-spi-1 https://docs.opentitan.org/hw/ip/spi_device/doc/#tpm-over-spi-2