261–270 of 273 posts
Earlier quoted context omitted.
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.
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.
This is not addressing my question. It's not the TPM that's exploited but the SP. If the SP is compromised then the whole host is compromised.
Earlier quoted context omitted.
Yes, you can get compromised through firmware updates. But then, not using a TPM also leaves you vulnerable to firmware and software updates. If NSA has compromised all TPM vendors, then you can expect that they've compromised much more still, and so you've basically lost the fight against them. Key management is always a weak link in the chain. I.e., I'm objecting to this focus on TPM in TFA and this discussion beca…
> Yes, you can get compromised through firmware updates. It's not just about updates through regular channels but about evil maid attacks with signed malicious firmware. This vector would be avoidable if you could sever the trust relationship. Another wrinkle is that some of the blobs are encrypted (e.g. ME), so they can't even be audited. Currently too much of the trust chain relies on untrustworthy components. So y…
This will always be true unless you build all the components yourself. And you don't have time to build all the components yourself. Therefore this will always be true.
With root of trust measurement you get to see that you're running code you've arbitrarily decided to trust. Everything else you could do would be mitigations (e.g., look for access patterns that imply compromise) or attempts to suss out vulnerable and/or backdoored components (e.g., reverse engineering and analysis). Not that one should not do those other things, but that root of trust measurement is still both, essential and insufficient.
Remember: perfection is the enemy because it's unattainable. We can tilt at windmills, but that won't get us anywhere.
Earlier quoted context omitted.
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.
Encrypting bus traffic? What kind of mission impossible spy is this supposed to protect from?
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."
Wondering if something was requested by law enforcement isn't implying a cabal, chill. Also a couple kilobytes of flash costs basically nothing. And you could hash keys over a certain length, which is much better than having such a short limit on a human-typed string.
Does this affect OPAL 2.0 in any way? I tried to search through the spec [1] but didn't find immediate clues. [1]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_Sto...
Thanks for the pointer, we haven't checked out OPAL yet. It seems to be the most popular standard when it comes to "Self Encrypting Drives" (SED). Looking into it shortly, I've found a paper from 2019 from Meijer et al. ([1]) finding several flaws with OPAL-compliant drives. They further find that BitLocker entirely depends on SSD-based encryption if the hardware advertises it. This finding's nature is very similar t…
Earlier quoted context omitted.
Don't reward them for that. The only solution is to move to another OS, that's the only thing they will ultimately understand - no matter how inconvenient it might be.
That's not an option if you use your machine for work and your Dev tools only work on windows. PS5/Xbox toolchains only work on windows, as a gamedev I don't really have a choice.
Earlier quoted context omitted.
That's not an option if you use your machine for work and your Dev tools only work on windows. PS5/Xbox toolchains only work on windows, as a gamedev I don't really have a choice.
You can always target other platforms and still make money as a gamedev.
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."
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?
Timing attack on the character of the pw which failed?