221–230 of 273 posts
Earlier quoted context omitted.
I wish there was a linux distro made by people who love windows, not linux.
I've always felt that $BIG_BRAND_DISTRO+KDE got pretty close. It's still Linux, so not quite the same, but as far as look and feel, it's pretty close I think.
Earlier quoted context omitted.
Yes, if you want to recover keys from a dTPM you have two options: - decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip - force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it A few nation states…
They have some weaknesses. A dTPM uses an unencrypted protocol to communicate with the CPU (simple i2c or SPI) and it's pretty easy to sniff it if you manage to get legit access. But you do need a legit user to log in to the machine once. This is a bit of an achilles heel. Example: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole... In this sense an integrated solution is better because there is no simple…
While that is strictly speaking true, the TPM command set allows you to set up an encrypted session to the TPM using an ECDH or RSA key for key exchange that authenticates the TPM.
The problem is that the BMCs and BIOSes out there don't record a public key for a primary key on the TPM and then don't bother using encrypted sessions (not even opportunistically getting that public key from the TPM, which would defeat passive attacks).
That's a software problem, not a TPM problem!
I know that TPM 2.0 is a huge topic, so it's quite forgivable that people don't know these things. I've written a tutorial that might help: https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Int...
Earlier quoted context omitted.
Yes, if you want to recover keys from a dTPM you have two options: - decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip - force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it A few nation states…
They have some weaknesses. A dTPM uses an unencrypted protocol to communicate with the CPU (simple i2c or SPI) and it's pretty easy to sniff it if you manage to get legit access. But you do need a legit user to log in to the machine once. This is a bit of an achilles heel. Example: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole... In this sense an integrated solution is better because there is no simple…
The seeds are an essential part of the TPM story as for generation (derivation) of primary keys, and being able to "take ownership" of a TPM by changing those seeds.
The seeds are not an essential part of the TPM story for its RNG. A TPM absolutely can and should have a solid HW RNG. Though, were I designing a TPM, I'd combine the output of a HW RNG w/ a PRNG seeded internally.
Earlier quoted context omitted.
The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're…
Thanks for debunking this unfounded conspiracy theory. There are many things to worry about when it comes to firmware backdoors, the TPM ain't one of them.
QUESTION FOR THE AUTHORS: Is there any way in which a voltage fault injection vulnerability in the SP can affect only the fTPM and not actually be a full host compromise but for the fTPM compromise?
I believe the answer to that has to be no. If you can compromise the SP you can compromise the whole system. Therefore this isn't really about fTPM. But you'll notice that many commenters are running away with this and saying that TPMs make systems less secure, which is not really correct.
Yes, TPMs are not used correctly by most BMC/BIOS implementations, or even by OSes, and there are vulnerabilities that arise from that misuse. But TPM 2.0 does provide what is needed to solve those issues.
The wholesale attacks on TPM 2.0 itself here are not warranted, especially if the SP vulnerabilities are more general rather than being specifically limited to fTPMs.
Earlier quoted context omitted.
Mine and I want a TPM, it's a device essential for modern laptop security. _Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_ through potential a different implementation and not some of the features build on top of it like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the…
TPM 2.0 is a fantastic spec. There's little that's wrong with it. Even the bus sniffing vulnerabilities w/ dTPMs aren't TPM's fault but the BMC's and BIOS', as there is absolutely a way to encrypt and authenticate secrets to/from the TPM. Reinventing this wheel will probably lose a lot of good things. People who reinvent wheels often fail to understand what came before.
Earlier quoted context omitted.
Why do they do this, Samsung does the same tiny length limit for Secure Folder. Is it law enforcement requested?
It's because tpms are small and have small storage. The outrageous "its a secret cabal" voices are a prime example of what people cook up when faced with something they cant explain due to ignorance but feel the need to have an answer. Its as outrageous as a Republican saying "Q did it."
Don't/can't? Then you're a fool trusting someone else to do something you yourself cannot inspect. Then again, most people seem to be oddly fine with that. I am not of that number.
Earlier quoted context omitted.
Please note, though, that's imperative to then go for a BitLocker TPM+PIN configuration at least. A standalone (discrete) TPM with TPM-only protectors can be attacked by bus sniffing, a hardware attack much simpler than ours. [1] The beauty of a discrete TPM is its anti-hammering protection, making a numerical PIN a very effective security measure (akin to a SIM/SmartCard). [1] https://www.sciencedirect.com/science/a…
Bus sniffing can be mitigated by encrypting communications using the TPM's in-built parameter encryption capabilities.
There's still other active attacks resulting from the BMC and BIOS and parts of the OS not also doing the encrypted session thing.
To anyone with a bit more breadth on this topic: is this as terrible as it sounds or more just in the realm of academia and nation-states?
Earlier quoted context omitted.
Issue here is that I trust the Chinese even less to not have something like this hidden in the hardware.
Interesting it is the Chinese processors (e.g. Allwinner, T-Head, Rockchip) that happen to be free of this secure boot garbage by default. If you want to you can blow an efuse (with power applied to the VPP pin) and enable secure boot. But otherwise it's off. I am waiting for a high performance ARM or RISC-V chip that's on par with AMD and Intel performance. One without secure boot. The moment that comes out, my Ryze…