Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

faulTPM: Exposing AMD fTPMs' Deepest Secrets

arxiv.org

Post reply on HN
Print view View original

231–240 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#231

Post by intelVISA »

salawat wrote: post #227
halJordan wrote: post #214

Earlier quoted context omitted.

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."

If you'd like to provide schemata, open standards and source code for them, then don't keep the class waiting. 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.

as a 1337 pwn3r the TPMs are fine

source: just trust me bro

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#232

Post by jeroenhd »

ridgered4 wrote: post #110
jeroenhd wrote: post #47

Earlier quoted context omitted.

It'll work fine, Microsoft even explains how to upgrade: https://support.microsoft.com/en-us/windows/installing-windo... They chose an arbitrary cut-off date for hardware support for their new OS. They decided not to support old stuff anymore and they had to pick a date/technology platform. It was always going to be arbitrary. In my opinion they should've picked a clearer distinction (i.e. require a certain level of…

That link does not say it will work fine. It says it is not recommended or supported and if it blows up it is your problem. Additionally it says you might not get any updates. Certainly, it sounds like it might just be some ass covering on their part but they were also testing a nag watermark for unsupported installs like this so maybe not. Either way it doesn't sound like a really solid path forward.

It's certainly not a path forward that Microsoft will recommend. It'll work fine, though.

If not, there are other operating systems that do work. Microsoft isn't the exclusive owner of the PC space, that's one of the major points of all of the antitrust fines and lawsuits.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#233

Post by wkat4242 »

cryptonector wrote: post #223
wkat4242 wrote: post #207

Earlier quoted context omitted.

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…

> By the way a dTPM should have a real entropy RNG so technically it shouldn't have any (usable) seed. It's basically a smartcard soldered onto the mainboard. Of course smartcards can also have key generation flaws like the Infineon flaw a while back. https://www.schneier.com/blog/archives/2017/10/security_flaw ... The seeds are an essential part of the TPM story as for generation (derivation) of primary keys, and be…

But the seed itself should still be fully random though? And generated on-device during initialisation. Derived keys are a thing of course, and I understand the benefit thereof.

But a manufacturer-installed seed that they have control over sounds like a very bad idea.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#234

Post by salawat »

cryptonector wrote: post #190
taraharris wrote: post #31

Earlier quoted context omitted.

TPM's true owner is the NSA, not you or I. https://www.stat.rice.edu/~dobelman/kstorm.txt https://news.ycombinator.com/item?id=6337282 https://www.militaryaerospace.com/computers/article/16711478... https://www.businessinsider.com/leaked-german-government-war... https://supplychaindigital.com/technology/nsa-trusted-comput... https://redmondmag.com/articles/2013/08/22/windows-8-securit... https://blogs.ncl.ac.uk/secur…

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…

>Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately.

Excuse me, but wtf. That's BS. Cryptographic material is nothing but data. A Huffman encode will work on a number that happens to be a public key just as happily as it will a anything else.

Cryptographic material doesn't have a magic "immune to compression" characteristic.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#235

Post by wkat4242 »

cryptonector wrote: post #222
wkat4242 wrote: post #207

Earlier quoted context omitted.

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…

> A dTPM uses an unencrypted protocol to communicate with the CPU 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 opportunist…

Thanks, I didn't know that, I thought indeed that it was simply not possible with TPM 2.0.

I do think it's time for a TPM 3.0 though. What apple does with their T2 security chip, and later with the M1/M2, is having the secure element not only handle the key material but the actual encryption as well. They have hardware acceleration that can handle encryption at full disk speeds. This is still a much better option than a TPM especially with symmetric encryption where the key would inevitably end up in the main CPU. In Apple's scenario this no longer happens.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#236

Post by salawat »

shitter wrote: post #132
anthk wrote: post #81

And now I remember people telling me Windows is more secure than Unix because of TPM, foo... bar... No, thanks, bioctl(4) works well under OpenBSD for disk encryption and so will do under HyperbolaBSD.

Windows, Linux, OpenBSD - it doesn't matter. Without a TPM you're vulnerable to trivial attacks (Evil Maid), far easier than the one in this article.

So.... Take your laptop with you everywhere?

When did we start creating nightmarish system complexity to guard against attacks that are generally exceedingly rare....oh wait. Forgot where I was.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#237

Post by rasz »

Spooky23 wrote: post #130
copper-float wrote: post #107

Earlier quoted context omitted.

Source? That would be very shocking.

Why? The FBI pitched a fit over access to a shooter’s phone in the press a few years ago, then stopped. Now, you have a multiple products on the market that can crack passcodes by utilizing flaws that allow you to brute force PINs, which are by default 6 digit numbers. (Despite most guidance demanding 8)

Cellebrite UFED Cellphone Forensic Extraction Device Teardown https://www.youtube.com/watch?v=7LLGGCXH9MQ

UFED, get it? its right in the name :] Video has little demonstration with older phones, one click bypass for all passcodes.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#238

Post by flangola7 »

gkbrk wrote: post #128
flangola7 wrote: post #90

Earlier quoted context omitted.

Without a TPM servers can't verify that their genuine app is being used. https://developer.apple.com/documentation/devicecheck/valida...

Why would users want a server to know they're using their official crapware or an alternative/modded client that serves users better? Surely the device should serve the interests of the user that pays for it, and not some random developer.

1 is anti cheat.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#239

Post by rasz »

copper-float wrote: post #107
bflesch wrote: post #91

Earlier quoted context omitted.

yes

Source? That would be very shocking.

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

>Later provision was added to allow export of 56-bit encryption if the exporter promised to add "key recovery" backdoors by the end of 1998.

First SSL crippled to 40-bit RC2/RC4

First 802.11 wireless protocol WEP "64" key length shortened to 40 bits

https://en.wikipedia.org/wiki/A5/1 vs https://en.wikipedia.org/wiki/A5/2

>to allow the British secret service to eavesdrop more easily. The British proposed a key length of 48 bits, while the West Germans wanted stronger encryption to protect against East German spying, so the compromise became a key length of 54 bits

>Documents leaked by Edward Snowden in 2013 state that the NSA "can process encrypted A5/1"

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#240

Post by rasz »

taraharris wrote: post #13

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporations? Whose computer is this, anyway?

Obviously computer belongs to Microsoft. They are the ones paying for AMD SOC development and millions of units per year under multi year contracts.
Post reply on HN