How to really detect chassis intrusion?

[Simon_BN]

Hello,

is there a way to really detect chassis intrusion on the framework?
I enabled the chassis intrusion detection in the firmware, but if someone opens up the chassis, this person could simply remove the coin cell (and on gen12 the battery) to reset the firmware settings (+ supervisor password). So at boot there would be no warning, because he can simply change firmware settings. So I thought I could possible measure this with the TPM2, but it is only measured, that the supervisor password is set, not what the password actually is (what could be easily reproduced by an attacker). I use the TPM2 already to authenticate the device, the only piece missing, is, that nobody tampered with e.g. the keyboard.

I have a Gen11 system, is Gen12 any different in this regard?

[GhostLegion]

Then put glitter on the screw heads, glitter will be removed when screws are undone. Things like that will help.

[Simon_BN]

@GhostLegion

put glitter on the screw heads

An attacker can easily reproduce this!?

[Mapleleaf]

@Simon_BN If you had set a BIOS password and it is gone, doesn’t that make it obvious the laptop has been tampered with? No need to look very far…

[DHowett]

@Simon_BN

An attacker can easily reproduce this!?

The theory behind glitter seals is that glitter embedded in epoxy produces a completely unique pattern that can’t be reproduced. You’d need to photograph your glitter seal and compare the seal against the photograph to ensure your device was not tampered with.

[GhostLegion]

Besides, are you really that paranoid? Is your threat model so high as to merit physical attacks? What are you really trying to protect from? If an attacker gets so much preparation that they are able to seize your laptop, then they will just clone the drive and try and crack that. Alphabet letter agencies aren’t going to just hand it back to you and let you go on your merry way. And even if they did, why on earth would you trust the laptop at that point? Security is a complete rabbithole, don’t bother trying to “completely secure” the laptop unless you are willing to dissassemble it and bury it in concrete because that is the only way.

[Matt_Hartley]

@Mapleleaf

If you had set a BIOS password and it is gone, doesn’t that make it obvious the laptop has been tampered with?

This is pretty good advice as this would be a solid indication.

[GhostLegion]

@Mapleleaf

If you had set a BIOS password and it is gone, doesn’t that make it obvious the laptop has been tampered with? No need to look very far…

except cloning a drive wouldn’t require tampering with BIOS, just physical access

[Mapleleaf]

@GhostLegion This is what the physical tampering detection feature is for! And unless you reset the BIOS (which would erase the BIOS password), you would know that the laptop has been opened, e.g. in order to clone the harddrive.

[GhostLegion]

@Mapleleaf Fair point, I wasn’t thinking.

[Simon_BN]

@Mapleleaf

If you had set a BIOS password and it is gone

Thank you very much, an attacker could set a new one, so I would need to check if my password still works. It is a bit annoying, but doable.

@DHowett

You’d need to photograph your glitter seal and compare the seal

Thank you very much, it seams to be a bit of an overkill to me. E.g. on other platforms it is enough, to check the state of the TPM2 (because it won’t sign anything, until the correct supervisor password had been entered again after chassis intrusion detection).

@GhostLegion

except cloning a drive

With the framework laptop (and a drive which supports it), you can set an ATA password (not sure how to call it on a nvme). Without it, an attacker couldn’t even read unencrypted data from the disk.

@Mapleleaf

This is what the physical tampering detection feature is for!

For me personally, I don’t mind, if an attacker gets the data from my disk. The only unencrypted files are signed GKIs and a signed bootloader. I want protection against modification of the device, e.g. the keyboard.

@GhostLegion

are you really that paranoid?

Is this a rhetorical question? Obviously … I am!

@GhostLegion

Security is a complete rabbithole

To be more precise, a convenient detection of physical modification is the last thing missing in my threat model with the framework (and even solved with my old laptop).

[GhostLegion]

@Simon_BN

@Simon_BN

For me personally, I don’t mind, if an attacker gets the data from my disk. The only unencrypted files are signed GKIs and a signed bootloader. I want protection against modification of the device, e.g. the keyboard.

Then you want Bitlocker or the Linux equivalent. That will check known PCR values and only decrypt the drive if they check out. The question you need to ask is, is there a PCR for the keyboard and my guess would be no.

@Simon_BN

So at boot there would be no warning, because he can simply change firmware settings. So I thought I could possible measure this with the TPM2, but it is only measured, that the supervisor password is set, not what the password actually is (what could be easily reproduced by an attacker).

Pretty sure the TPM measures firmware state and if it is reset then the PCR measure will fail.

@Simon_BN

With the framework laptop (and a drive which supports it), you can set an ATA password (not sure how to call it on a nvme). Without it, an attacker couldn’t even read unencrypted data from the disk.

Assuming there isn’t a flaw within the drive’s manufacturer’s firmware that makes it easily crackable. Or this.

@Simon_BN

Thank you very much, it seams to be a bit of an overkill to me. E.g. on other platforms it is enough, to check the state of the TPM2 (because it won’t sign anything, until the correct supervisor password had been entered again after chassis intrusion detection).

This is overkill for you but yet you state how paranoid you are. Either you care enough to go the last mile which really isn’t that difficult to implement nor check or you aren’t really that concerned about it. Which is fine. Because I’m not. I set the TPM and Clevis and call it a day.

[Simon_BN]

@GhostLegion

Linux equivalent

systemd-cryptenroll

@GhostLegion

Pretty sure the TPM measures firmware state

As stated in my first post, it measures only things in PCR1, that are easily reproducible, I tested it already.

@GhostLegion

Assuming there isn’t a flaw within

Exactly, that’s why I use software and hardware encryption.

@GhostLegion

Either you care enough to go the last mile

Exactly, I care, but if convenience and my personal wanted security is not possible with framework, framework is probably not the right choice for me.

[GhostLegion]

@Simon_BN

systemd-cryptenroll

Or Clevis. I was being general.

@Simon_BN

As stated in my first post, it measures only things in PCR1, that are easily reproducible, I tested it already.

Or any other PCR if you tell it to do so. Besides, if someone wiped your settings and then changed them, then it shouldn’t hash the same. That sounds like an obvious flaw.

@Simon_BN

Exactly, I care, but if convenience and my personal wanted security is not possible with framework, framework is probably not the right choice for me.

Which is it? Because the two are literally incompatible with one another. Doing one reduces the other. Again, either you really do care that much about security in which case inconvenience is the price you pay or you are willing to tolerate some insecurity for convenience.

You act nonchalant about your drive being stolen because it is encrypted but you care about physical security this much??? I’m beyond confused on what on earth you are after. I simply do not understand.

[DHowett]

So, @Simon_BN, you inspired me to check off one of my to-do list items.

In honor of this thread, I wrote up a DXE driver that measures the chassis intrusion state into PCR[6]¹.

Just over a year ago, while reverse-engineering the embedded controller firmware (before it was open-source), I stumbled upon a host command that reports the entire chassis intrusion state and speculated that it could be used as part of a PCR measurement. Framework’s lead firmware engineer and all-around good guy Kieran let me know that it wasn’t being used like that.

Anyway, the nitty gritty. The value reported by this embedded controller feature:

• changes every time the chassis is opened
  • … even if the machine was powered fully off when it was opened
• resets when the RTC battery is removed

Because it increments unless reset and otherwise simply tracks the raw count of times the chassis was opened, it’s somewhat more tamper-evident than the password appearing or disappearing.

Now, given your threat model I am not providing binaries. You probably would not trust them, and your secure boot configuration would certainly not trust them. All you need is to build it with EDK2 and use a bootloader that will load external drivers before loading your OS. Sign with whichever key your firmware has been configured to trust.

Notes from running with this enabled

I’ve captured PCR measurements from four boots:

1. Before installing the driver (baseline)
2. After installing the driver
3. After opening the chassis once
4. After removing the driver

The differences are below:

1 to 2

--- pcrs.0.before       2023-01-20 22:16:58.000000000 -0600
+++ pcrs.1.with_driver  2023-01-20 22:16:58.000000000 -0600
@@ -1,15 +1,15 @@
   sha1:
     0 : 0x759BAEDB49070E3FB333B71CD3E599E3E0727349
     1 : 0x0ED7903FD6A72EBE1263E23C3B067024FE9C8110
-    2 : 0x58DB64F49A155C69FD060A1E2EDDCE4B983F4A9C
+    2 : 0x0C39F6A598C90597DD900C03A74976DD82FA424F
     3 : 0xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236
     4 : 0xB6B4F407929851EE335F340C2C02DA1406FD2C97
     5 : 0x873F1331A9BE77F875F330ABD491B697E7C64937
-    6 : 0xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236
+    6 : 0x240A31A2F2D558EA9B61C2F60B10650CE5D3713A
     7 : 0xDE581970A4C0AFAD9EF6BC21A4E4858AE5158436
     8 : 0x0000000000000000000000000000000000000000
     9 : 0x1227F6297C90F87731031BE47192D461006B22F8
-    10: 0x6CD74CCC5A98099603801F3B80CD88FF10B02B79
+    10: 0x7D4506E4BC356F72125E73F7CC0F5861B33F11B7
     11: 0x0000000000000000000000000000000000000000
     12: 0x63E7FCEDCC66A85AD1A7C1B4AF468AF458A773BD
     13: 0x0000000000000000000000000000000000000000

We observe a difference in PCR 2 due to the loading of a new driver. I cannot explain the difference in PCR 10, though I presume it is likely from systemd-boot (my bootloader).

2 to 3

--- pcrs.1.with_driver  2023-01-20 22:16:58.000000000 -0600
+++ pcrs.2.after_first_intrusion        2023-01-20 22:16:58.000000000 -0600
@@ -5,11 +5,11 @@
     3 : 0xB2A83B0EBF2F8374299A5B2BDFC31EA955AD7236
     4 : 0xB6B4F407929851EE335F340C2C02DA1406FD2C97
     5 : 0x873F1331A9BE77F875F330ABD491B697E7C64937
-    6 : 0x240A31A2F2D558EA9B61C2F60B10650CE5D3713A
+    6 : 0x763050510BA63DDC284AA7CE324A64BDEA460865
     7 : 0xDE581970A4C0AFAD9EF6BC21A4E4858AE5158436
     8 : 0x0000000000000000000000000000000000000000
     9 : 0x1227F6297C90F87731031BE47192D461006B22F8
-    10: 0x7D4506E4BC356F72125E73F7CC0F5861B33F11B7
+    10: 0xFA6F552F00B546B7D8A3B7CC5859A811D412AB7F
     11: 0x0000000000000000000000000000000000000000
     12: 0x63E7FCEDCC66A85AD1A7C1B4AF468AF458A773BD
     13: 0x0000000000000000000000000000000000000000

PCR 6 shows a change after chassis intrusion.

1 vs 4 (does removing the driver revert the PCRs?)

dustin@rigel:/mnt/c/Users/Dustin$ diff -u pcrs.0.before  pcrs.3.after_removal
dustin@rigel:/mnt/c/Users/Dustin$

Yes.

¹ I chose PCR[6] because it is the closest PCR in the specification to being OEM-controlled, and if this were to become an official extension then that might be the right place for it. I do not know what else is measured into PCR[6].

[Simon_BN]

@GhostLegion

Because the two are literally incompatible with one another.

As noted above, it works that way on my old laptop, so I don’t have to sacrifice one of them.

@DHowett

In honor of this thread, I wrote up a DXE driver that measures the chassis intrusion state into PCR[6] ¹.

Wao! Thank you so so much for sharing this, your work/time and being such a genius!
I tested it and it works great on my Gen11. (I just had to research the location of the driver: /EFI/systemd/drivers/name.x64.efi).

@DHowett

I cannot explain the difference in PCR 10, though I presume it is likely from systemd-boot

On my archlinux testing machine with systemd-boot, PCR 10 is uninitialized and adding your driver does not change that. According to the systemd-cryptenroll manpage, PCR10 is used by the Linux kernel’s Integrity Measurement Architecture. It measures a boot_aggregate and all executed binaries.

I haven’t had time to play around with fw-ectool and look at the raw values, but I definitely will, great research and great article!
If somebody is also interested in using this, the attacker should not have the ability to test the correct counter value (e.g. through automated unlocking at boot), since the value is only 8bit and probably close to zero.

Great day, again, thank you sooo much, @DHowett !