# How to really detect chassis intrusion? **URL:** \ **Category:** Linux\ **Created:** [January 19, 2023, 12:26am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492 "2023-01-19T00:26:09Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Simon\_BN](https://avatars.discourse-cdn.com/v4/letter/s/c2a13f/32.png) [@Simon\_BN](https://community.frame.work/u/Simon_BN)\ **Post date:** [January 19, 2023, 12:26am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/1 "2023-01-19T00:26:09Z")
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? ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 19, 2023, 4:32am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/2 "2023-01-19T04:32:29Z")
Then put glitter on the screw heads, glitter will be removed when screws are undone. Things like that will help. ---
**Author:** ![Simon\_BN](https://avatars.discourse-cdn.com/v4/letter/s/c2a13f/32.png) [@Simon\_BN](https://community.frame.work/u/Simon_BN)\ **Post date:** [January 19, 2023, 11:25pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/3 "2023-01-19T23:25:48Z")
> [@GhostLegion](#): > > put glitter on the screw heads An attacker can easily reproduce this!? ---
**Author:** ![Mapleleaf](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/mapleleaf/32/10505_2.png) [@Mapleleaf](https://community.frame.work/u/Mapleleaf)\ **Post date:** [January 20, 2023, 1:12am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/4 "2023-01-20T01:12:14Z")
@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… ---
**Author:** ![DHowett](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/dhowett/32/1990_2.png) [@DHowett](https://community.frame.work/u/DHowett)\ **Post date:** [January 20, 2023, 1:50am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/5 "2023-01-20T01:50:12Z")
> [@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. ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 20, 2023, 6:25am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/6 "2023-01-20T06:25:43Z")
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. ---
**Author:** ![Matt\_Hartley](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/matt_hartley/32/13623_2.png) [@Matt\_Hartley](https://community.frame.work/u/Matt_Hartley)\ **Post date:** [January 20, 2023, 6:40pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/7 "2023-01-20T18:40:35Z")
> [@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. ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 20, 2023, 6:45pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/8 "2023-01-20T18:45:01Z")
> [@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 ---
**Author:** ![Mapleleaf](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/mapleleaf/32/10505_2.png) [@Mapleleaf](https://community.frame.work/u/Mapleleaf)\ **Post date:** [January 20, 2023, 11:13pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/9 "2023-01-20T23:13:16Z")
@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. ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 20, 2023, 11:30pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/10 "2023-01-20T23:30:20Z")
@Mapleleaf Fair point, I wasn’t thinking. ---
**Author:** ![Simon\_BN](https://avatars.discourse-cdn.com/v4/letter/s/c2a13f/32.png) [@Simon\_BN](https://community.frame.work/u/Simon_BN)\ **Post date:** [January 21, 2023, 1:28am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/11 "2023-01-21T01:28:01Z")
> [@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). ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 21, 2023, 2:40am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/12 "2023-01-21T02:40:17Z")
@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](https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-let-attackers-bypass-disk-encryption/). Or [this.](https://www.pcmag.com/news/researchers-tpms-send-bitlocker-decryption-keys-in-cleartext) > [@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. ---
**Author:** ![Simon\_BN](https://avatars.discourse-cdn.com/v4/letter/s/c2a13f/32.png) [@Simon\_BN](https://community.frame.work/u/Simon_BN)\ **Post date:** [January 21, 2023, 3:20am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/13 "2023-01-21T03:20:48Z")
> [@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. 🙂 ---
**Author:** ![GhostLegion](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/ghostlegion/32/3356_2.png) [@GhostLegion](https://community.frame.work/u/GhostLegion)\ **Post date:** [January 21, 2023, 3:34am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/14 "2023-01-21T03:34:58Z")
> [@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. ---
**Author:** ![DHowett](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/dhowett/32/1990_2.png) [@DHowett](https://community.frame.work/u/DHowett)\ **Post date:** [January 21, 2023, 4:39am UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/15 "2023-01-21T04:39:55Z")
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]](https://github.com/DHowett/FrameworkHacksPkg/tree/main/Drivers/ChassisIntrusionPCRMeasurementDriver)¹. 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](https://www.howett.net/posts/2021-12-framework-ec/#3e09---historical-chassis-intrusion-data) 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 > > ```diff > --- 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 > > ```diff > --- 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?) > > ```shell-session > 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]. ---
**Author:** ![Simon\_BN](https://avatars.discourse-cdn.com/v4/letter/s/c2a13f/32.png) [@Simon\_BN](https://community.frame.work/u/Simon_BN)\ **Post date:** [January 21, 2023, 7:44pm UTC](https://community.frame.work/t/how-to-really-detect-chassis-intrusion/26492/16 "2023-01-21T19:44:47Z")
> [@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] ](https://github.com/DHowett/FrameworkHacksPkg/tree/main/Drivers/ChassisIntrusionPCRMeasurementDriver)¹. 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](https://man.archlinux.org/man/systemd-cryptenroll.1), PCR10 is used by the [Linux kernel’s Integrity Measurement Architecture](https://www.redhat.com/en/blog/how-use-linux-kernels-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 ! 🙂