!FDRbtNYiWrrJOvqKdW:matrix.org

Security-Discuss

585 Members
5 Servers

Load older messages


SenderMessageTime
31 Aug 2022
@_slack_osfw_U03TERZA1RN:matrix.orgAlbus J.B. And therefore strongly connected to philosophy. 09:07:06
@_slack_osfw_UJE6F6WDS:matrix.orgmxshift Depends on which firmware in the system you are talking about. BMC firmware itself often isn't attested in any way and the only way to access it is through the BMC so a compromised BMC can lie to you. For x86 firmware, TPM PCRs are one piece of the puzzle but it gets complicated depending on whether the system supports and has enabled things like BootGuard. At a minimum, you need to figure out who is the root of trust in your platform and start from there. 15:38:01
@_slack_osfw_UDG35CU8P:matrix.orgjoelrebel In this case it’s firmware for a mix of x86 system components, along with the BMC. There isn’t any consistency among them, I know that Dells have firmware measurements added to the TPM, but I’m not too sure about what I can compare that data with 15:50:29
@_slack_osfw_UJE6F6WDS:matrix.orgmxshift ayup. This is a challenge that chipsec and various vendors like Eclypsium have been chipping away at. 21:28:46
5 Sep 2022
@_slack_osfw_U0413AS57C2:matrix.orgJuan Antonio Osorio joined the room.14:34:26
6 Sep 2022
@_slack_osfw_U020AP3PZEW:matrix.orgRoss Philipson changed their profile picture.14:43:32
@_slack_osfw_UA5N0296G:matrix.orgakoshy pretty cool https://go.dev/blog/vuln 20:06:40
13 Sep 2022
@_slack_osfw_U042JRSCVMX:matrix.orgMarcin Skarbek joined the room.13:40:46
15 Sep 2022
@_slack_osfw_U02D33069C6:matrix.orgJiming Sun changed their profile picture.16:32:20
16 Sep 2022
@_slack_osfw_U042VP7C1KN:matrix.orgBrian Milliron joined the room.21:46:23
19 Sep 2022
@_slack_osfw_U7ECCDESH:matrix.orgChris Koch Bumping this Caliptra talk to the top since Caliptra was just mentioned at #osfc 12:08:12
@_slack_osfw_U8M1BCXDG:matrix.orghudson I like DICE... although I'm not following the flow 100% for combining it with the TPM policies. I think the plan is that the TPM policy use the signed something from the iRoT, although I'm also confused as to why you would use an external TPM if you have a built in RoT. 12:15:40
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt That is exactly what I wanted to talked Jordan to about. So there is the need for some crypto operations in the RoT, and the TPM may serve as a secondary thing, e.g., enclave, for distinct purposes. But why? I see a certain separation there, yet a bit unsure what to make of that. 14:03:38
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis He had a slide about bridging the 2 identities, but it was also a bit unclear to me. 14:18:06
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt From a chat we just had: The TPM is upgradable, while the internal RoT is fixed. So storing keys in the dedicated TPM has the benefit of being able to fix bugs in the security module. 14:54:00
@_slack_osfw_UCY52U39C:matrix.orgKrystian Hebel Does it have to be fixed? POWER9 has its first parts of firmware (https://wiki.raptorcs.com/wiki/OpenPOWER_Firmware, SBE and HBBL) located in SEEPROM (Secure EEPROM), which is upgradable, but in theory requires physical access (jumper). HBBL ends with a hash of key that is used to verify next stages, and there are instructions on how to change that key: https://wiki.raptorcs.com/wiki/Secure_Boot_with_your_own_keys 18:08:06
20 Sep 2022
@_slack_osfw_UHGHE3L65:matrix.orgFredrik changed their profile picture.14:55:31
@_slack_osfw_UHGHE3L65:matrix.orgFredrikRedacted or Malformed Event14:55:31
21 Sep 2022
@_slack_osfw_U7ECCDESH:matrix.orgChris Koch There are generally speaking two reasons. 1. With the TPM, you can write slightly more extensive, iterative policies. You have a test machine where you want to skip kernel verification in the sealed credentials? Don't seal to that PCR. If all that was in one long DICE chain, you don't have those options.. 2. A TPM can have persistent flash storage, iRoTs packaged in CPUs generally cannot. This is useful in order to "forget". We'd like the ability to include some sort of "epoch" in the sealed policy (counter in the TPM world?) such that if you do a TPM Clear, no previously sealed credentials are accessible anymore. This is useful for e.g. internal ownership transfer of a machine and you don't want any creds that were previously sealed to that thing to be accessible anymore. Apologies for me butchering this because I don't know TPM concepts. 14:58:32
@_slack_osfw_U7ECCDESH:matrix.orgChris Koch As for the bridging of the two identities - I'll ask Jordan to come clarify, I'm not sure if he's in the slack 15:00:33
@_slack_osfw_U7ECCDESH:matrix.orgChris Koch Daniel is also correct, although the iRoT isn't precluded from having some firmware stored in persistent flash and having that measured in the DICE chain... But that's more complicated than necessary 15:10:22
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen joined the room.15:17:45
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen Regarding why multiple RoTs: TPM is a good root-of-trust for storage, with a powerful policy engine to conditionally release secrets based on various conditions. TPM is not a good root-of-trust for measurement, because interposers. So that's one reason why we're interested in leveraging both. And yeah as Chris said, while one could move the TPM implementation into the SoC itself, such implementations generally don't have sufficiently secure entropy that we can rotate when we want to invalidate secrets. Solutions which require pairing with some external flash and blowing fuses for anti-rollback aren't as attractive because our machine automation flows can require us to invalidate secrets fairly often. 15:23:49
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen changed their profile picture.15:27:15
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen Regarding combining identities: this need arises from the fact that the host will be sending some measurements into TPM PCRs, and we want to detect attacks where an interposer redirects those extensions to a TPM of their choosing. So the first thing the CPU does is obtain the TPM's identity, measure that identity into its DICE hierarchy, and then cache the TPM identity locally so later software can be sure that it always communicates with that same TPM, to mitigate TPM swap attacks. Later, a remote verifier can decide whether it's satisfied with the TPM identity that the CPU communicated with. 15:27:15
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen This dance is needed because this flow does not aim to prevent interposers from communicating with the legitimate TPM. Anyone who can send commands on the bus can extend data into that TPM's PCRs, because we are explicitly avoiding requiring any kind of persistent pairing between the TPM and CPU. Therefore, an attacker that can fool the CPU into sending some of its measurements into a fake TPM under their control, can then turn around and send falsified PCR measurements into the legitimate TPM. No bueno. So we want the CPU to detect these swap attacks, and soft-revoke its DICE key until next reset if it finds that an interposer may be playing games. That leaves an attacker only able to extend extra data into PCRs, not drop or redirect any legitimate measurements. So as long as the verifier is careful when walking the event log, the worst the attacker can do is DoS. 15:38:55
@_slack_osfw_U02668R1DGV:matrix.orgJordan Hand Basically what Chris and Jeff said. Small clarification on the entropy in flash thing, TPM has two primitives that are nice to leverage here: 1. SPS. If the device changes hands, you can rotate the SPS via TPM2_Clear. That way any secrets bound to keys in the storage hierarchy cannot be accessed. 2. NV counters. If you get new secrets, to can revoke the ability to unseal the old ones by incrementing a counter. Both of these are very hard to do without flash. Flash is hard in iRoTs because of physics/manufacturing limitations at that process size. As Jeff said, you could do counters in OTP, but you would run out too fast. Apologies for not getting into the full protocol. We're working on publishing that, I'll post here when we have something more to share. 16:12:33
22 Sep 2022
@_slack_osfw_U8M1BCXDG:matrix.orghudson I've seen proposals for DICE anti-rollback without counters by using signed version numbers and upgrading the keys (with a KDF that computes N-V HMAC so that version V+1 can re-compute keys for V and older versions). this doesn't work for all cases where TPM NV counters are used, although I've had problems using TPM counters in practice since they can't be synchronized across a fleet. 18:30:56
23 Sep 2022
@_slack_osfw_U042WR5AQJ3:matrix.orgJeff Andersen Yes, we do something similar on Titan, which is groovy for attestation but doesn't quite solve the revocation model we need (situations where we're about to release hardware to a less-trusted entity and need to wipe all secrets on it before doing so - without relying on revving major versions in signed fw, which is a more global operation). Agreed that fleet-synchronized counters would be a pain. 09:00:33
24 Sep 2022
@_slack_osfw_UL2JL9T54:matrix.orgShawn C https://hackaday.com/2022/09/21/trojans-can-lurk-inside-avr-bootloaders/ 03:35:35

There are no newer messages yet.


Back to Room List