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

251–260 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#251

Post by nyanpasu64 »

cryptonector wrote: post #225

I've not yet read past the abstract, though I've read (and responded to) a lot of the commentary here. 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…

Relying on an TPM to rate-limit an attacker's ability to brute-force a comically short PIN and get the encryption key (Microsoft's promoted way to login to a Windows device), is less secure (once the TPM is exploited) than relying on the attacker to guess a high-entropy password to get the encryption key.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#252

Post by jasonjayr »

halJordan wrote: post #214
cma wrote: post #80

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

Sure they are small little embedded chips, supposedly physically hardened from tampering.

but argon2($string_of_any_length) should produce a fixed-length byte string, no?

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#253

Post by LegionMammal978 »

astrange wrote: post #247
salawat wrote: post #234

Earlier quoted context omitted.

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

An RSA public key is a prime number. How are you going to compress a prime number? Encrypted material should not be compressable because it needs to appear random no matter what the unencrypted contents are, otherwise you have information about those contents. (You can trade off between the security and compressability, but shouldn't.)

> An RSA public key is a prime number. How are you going to compress a prime number?

In principle, given an n-bit prime p, you can store an expected log₂ n − 0.5 additional bits by using the gap between p and the next prime. Though in practice, I'd be surprised if the 19 or so extra bits could be dangerous.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#254

Post by flangola7 »

astrange wrote: post #246
flangola7 wrote: post #226

Earlier quoted context omitted.

Encrypting bus traffic? What kind of mission impossible spy is this supposed to protect from?

That's how console jailbreak mods have worked in the past. The important keyword is authenticated though. If it's not authenticated you can corrupt it.

They're doing all this to prevent... console jailbreaks? I would have expected some kind of national security use case.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#255

Post by flangola7 »

MrStonedOne wrote: post #202
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 should they have that right?

What do you mean? It's their server, their service.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#256

Post by russfink »

yarg wrote: post #204
whynotmaybe wrote: post #86

Earlier quoted context omitted.

I'm a windows user since 3.1 and don't know much about linux except the few trials and my pihole. What's the impact of having systemd (or not) for the everyday layman like me that just uses Visual Studio Code to build flutter apps ?

Very little. It's an idealogical flamewar, that in most cases is without impact. The binary format of the log file still seems to me to be a bad idea - it introduces corruptibility and complexity to a vital service that should be simple and uncorruptible. If a failing system starts to do weird things, plain text append only logging is preferable.

It’s a problem because people do not wish to learn new paradigms. Put me in that camp - took months to debug a 90 second hang and work around it. Of course, fast boot owes to its parallelization.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#257

Post by goolz »

altairprime wrote: post #39
goolz wrote: post #28

Earlier quoted context omitted.

Well, considering I am 008, my threat model is quite high indeed! But ya, I was being hyperbolic. And HN has provided plenty of worthwhile info on the topic of OpSec over the years, do not be quick to discount. I would be a fool to reveal too much about my threat model but the reality is there exist many people who have reason to fear the NSA. Am I one of them? Nice try, NSA!

The popularity of hyperbole in HN discussions makes it easier for people to discount HN, both in drowning out useful information and in weakening discourse. Please reconsider in the future.

Perhaps, a counterpoint, the popularity of patronizing comments on HN make it... well, easy to discount what is actually quite good advice. Reconsider?

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#258

Post by cryptonector »

salawat wrote: post #234
cryptonector wrote: post #190

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…

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

Try it for yourself. Encrypt /dev/zero in some key using AES, then compress it with whatever compressor you like. Try it many times. Let us know how it goes!

And, yes, you can compress specific pseudo-random looking symbols, but only a few. We're talking about arbitrary pseudo-random data, and that will not compress.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#259

Post by cryptonector »

astrange wrote: post #247
salawat wrote: post #234

Earlier quoted context omitted.

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

An RSA public key is a prime number. How are you going to compress a prime number? Encrypted material should not be compressable because it needs to appear random no matter what the unencrypted contents are, otherwise you have information about those contents. (You can trade off between the security and compressability, but shouldn't.)

An RSA public key is a small exponent for encryption and a large composite pq where p and q are large primes. There's more to it, naturally, but I'll stop there. You can have many many RSA keys of any given size, say 2048 bits for now. So something somewhat less than 2^2048 possible keys for 2048 bit RSA keys, let's say 2^2000 keys, which... is a lot! Since one should generate keys randomly we can expect that no one key will be much more frequently used than any other, so Huffman encoding is right out, but even if you try Huffman encoding anyways you'll find that most keys will end up with Huffman codes that are longer than the keys themselves meaning that the keys are not compressible!

Thinking about AES-256 will be easier. Say we have 2^40 computers able to randomly generate 2^64 AES-256 keys every day. Well, it will still take a long time to generate all possible AES-256 keys. So say in the best case scenario we get close to 2^120 keys or so. How would we even measure their frequencies so we could assign Huffman codes to them? Well, we can't, and even if we could most keys would have a frequency between 1 and 3. And still the next key to be generated could be outside that set so we really have to assign a code to each key, and there's... 2^256 possible keys... which means that even if we could assign a code to each key we couldn't write that down because there's not enough atoms on Earth to do it with. But let's say we just define a collation of AES-256 keys and assign then Huffman codes in order... But now we'll soon see that most keys will get codes assigned that are longer than 256 bits. Which means that the average input to this compressor would... yield an expansion, not a compression.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#260

Post by cryptonector »

wkat4242 wrote: post #235
cryptonector wrote: post #222

Earlier quoted context omitted.

> 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 tha…

There isn't that much that I'd do in a TPM 3.0:

- encrypt all command and response parameters instead of up to just one

- add a version of TPM2_Quote() that encrypts and signs so one can have ciphertext that one can demonstrate were made by a TPM encrypting to a restricted, shielded key

- add a small secure enclave facility

- add more EC algorithms, EdDSA, etc.

- add more cipher modes for AES

- increase RAM and NVRAM requirements

All of this can be done incrementally in 2.x, so calling it 3.0 would be just marketing (perhaps pretty good marketing).

Post reply on HN