kukrimate

7 ms·

1.
by kukrimate 2y ago
Why does the initrd have to keep the PCRs the same after handing off to the root filesystem anyhow? Capping off the PCRs with any arbitrary value before execing into root would stop this.
2.
by kukrimate 2y ago
It is a hardware feature, but it does basically nothing without its software in flash.... The only code that is inside the silicon is a 128K bootrom that literally just sets thing up for the real firmware to run.
3.
by kukrimate 2y ago
I have the ME11's boot ROM in a disassembler as I write this :)
4.
by kukrimate 2y ago
Absolutely is, one of those exact attacks is being used here to bypass BootGaurd. However all pre-boot attacks I am aware of rely on writing a malicious payload to the system's SPI flash and involve physical access. While they are genu
5.
by kukrimate 2y ago
Depends on how you define "booting". While its true that the microkernel always boots, and there is one userspace process running, it's a bit more subtle than that imo. The bringup module always boot which configures the cloc
6.
by kukrimate 2y ago
I wrote the deguard utility that made this possible. (The vulnerability being used was found by PT Research in 2017 however.) While yes you cannot strictly disable the ME, what remains of its firmware in this configuration is a bringup modu
7.
by kukrimate 2y ago
> eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples. To clarify, I was
8.
by kukrimate 2y ago
Except that was never the purpose of TPMs unlike HDCP
9.
by kukrimate 2y ago
Is anyone here talking about survaillance?? That "attestation" in the full disk encryption case means your disk encryption key only being available to the operating system you chose to install. And disallowing the ability of a l
10.
by kukrimate 2y ago
TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of
11.
by kukrimate 2y ago
Because where do you store the CPU side private key after the exchange for future sessions? The secure storage is the TPM , but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem. Thus your secret co
12.
by kukrimate 2y ago
What you are saying is sound, and I agree it could be done. But there are multiple caveats: - How do you hide the secret so that only "legitimate" operating systems can use it for establishing their sessions and not "Mate&#x2
13.
by kukrimate 2y ago
Well yes, but there is a difference between a signal being accessible on a PCB trace I can see with my eyes, vs it being accessible only on the inside of a 7nm silicon die. There is a reason why a lot of system integrate the security proce
14.
by kukrimate 2y ago
> What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators? I am not familiar enough of the technical details of Pluton or OpenTitan to make a meaningful statement on their security. > Should
15.
by kukrimate 2y ago
No. But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please. Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore vi
16.
by kukrimate 2y ago
Unfortunately encrypted sessions without an interactively provided secret like a PIN are no defence against attacker with physical access. You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure
17.
by kukrimate 2y ago
The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them a
18.
Show HN: Self Hosting C Compiler(github.com)
5 points by kukrimate 4y ago|0 comments