Trusted computing was never about security, it’s a way to take ownership of computers away from users and give it to computer manufacturers and Microsoft. It’s also not a good security model.
- The spec allows changing keys by the user as far as I know
- I’m unaware of a proposal of a better concept that stops attacks at this layer
For #2, Full Disk Encryption (including bootloader)
These protections work at different layers and hence, you use both.
First off, you can’t really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.
My disk and bootloader are both encrypted but I can get to my UEFI menu without decrypting. I’ve been meaning to password protect that but I get nervous about changing anything in UEFI.
I didn’t know much about secure boot or TPM or PAM so I was planning on setting those up, but I’ll skip it if it’s just about corporate capture. Not that my hardware is from some big name corpo or anything, it came with linux by default. But still.
Also I’m worried about locking myself out of booting from live USBs, especially if I ever need to use a recovery drive. But I think if I understand correctly then most official ISOs should still work, but I’m not 100% certain.
Clearly, I still have a lot to learn…
Aw heck I thought that spec said “insecurity coprocessor.” My bad.
It should have, but Microsoft managed to change it at the last minute.
Yeah, this has actually been a known thing for a while. The government has been sneakily getting their hand into NIST standards and trying to ensure they have back doors in the commonly used “best practices”.
So as a result for instance, encryption based on pseudo random numbers generated with hashing algorithms are actually safer that these theoretically “actually random” numbers generated in dedicated security modules in hardware.
I’ve never fully understood the issue with pseudo-random numbers… but I do know there’s an issue. I know, for example, bad random number generators have been the surface area of attack for recovering HDD crypto wallets with old bitcoin balances on them.
Would you care to help me understand something, though?
I think a fair framing here is that pseudo-random numbers generators need a random “seed” (starting value) to produce the resulting random number. So if someone knows the initial seed, they can rerun the algorithm to reproduce the original “random” number.
I think what follows is that good pseudo-random number generators introduce complexity and obfuscation in how the seed is created. Perhaps they use current time, speaker input, mouse input, and some other seemingly “random” data source.
Given enough dimensions (sources) in the source material for the seed, surly it would create an intractable number of permutations such that the seed can not be reliably reproduced — right?
Like, let’s say you know a 10 minute interval where the seed was created — and the tool uses millisecond granularity. That’s 1000 (mili) * 60 (sec) * 10 (min) total possible values. If it’s also collecting mouse movement in a screen, that’s a huge number of possibilities with each given interval of movement. Adding more sources (dimensions) increases the number of possibilities exponentially.
So how are people reverse engineering seeds? This seems secure to me, for the same reason cryptographic keys using giant prime numbers is secure… there are just too many possibilities, and it would take eons to brute force the right one.
How are they doing it faster with seeds? Shitty algorithms not using enough data sources?
The issue is not usually with the seed (although being able to determine the seed used for a PRNG completely defeat its purpose). The biggest issue (aside from deterministic seed) is that not all (P)RNG are created equal. Some have seemingly infinitely long, non repeating sequences, that varies greatly for a minuscule change in the seed (the good ones). Some have relatively short, repeating sequences. Some are so badly implemented that actually seeing a few numbers of the sequence allows reverse-engineering their internal state, so you can get the next numbers for free afterward. If you don’t use a big function with an impossible to probe initial state (like any good cryptographic hash function), you could even go backward in the sequence, finding previously generated secrets.
There’s plenty of attack surface on bad implementation of a (P)RNG. And the hardware ones combines “nuh-uh, we won’t tell you the seed” with “nuh-uh, you’ll have to trust our implementation”. That’s why, as far as I know, hardware RNG is usually used as one of the source for the seed of a PRNG.
For example, although it was deemed a bug, some AMD processor, for a while, failed to generate actual randomness under some circumstances. That’s a problem if you only rely on them. That’s why dumping that in a tumbler of other sources is a good idea. (sorry for the reddit link: https://old.reddit.com/r/AMDHelp/comments/itfgf4/cpu_random_generator_seem_to_be_failing/ )
The way you get your seed also matter. Time-based seed, if you have a vague idea of when it was acquired, is easy to check. Sure, there might be a window of a few hundred of thousands of milliseconds, but that’s nothing too hard to check if you’re sure this would yield you a secure key you really need. Multiplying the source, from sources that seemingly can’t be under the control of an attacker is important, but you have to be careful. An anecdote I was told at a conference was about using the system’s delay on read. Since reading happened at seemingly random (with a busy system), on a HDD, where the head have to actually move and the platters have to spin, it might be a good idea. When people moved to SSD, the reading delay became almost constant. Not such a good source now.
An example of failure on properly seeding your PRNG would be the random SSH keys generated by Debian (a long time ago). The random generation of keys moved from almost the full space of possibility to around 32.000 keys. That’s low enough that those keys are actually listed and banned from being used by some systems. More info about that here: https://www.hezmatt.org/~mpalmer/blog/2024/04/09/how-i-tripped-over-the-debian-weak-keys-vuln.html
If your PRNG is implemented correctly, with proper impossible (well, extremely hard) to reverse functions, and a really good seed that can’t be exfiltrated, periodically augmented (and not replaced!) with many source of seemingly out of control randomness, there’s little to do against that beyond just dumping memory beforehand and taking it out the hard way. Unfortunately, a lot of people think “outside the box” and wants to reimplement their own. Or rely on faulty hardware. Or rely on tampered hardware. And so on.
Pretty sure we’ve known that for a while now, although I assume the article is about a new and different exploit rather than one of the ones already documented.
Requires local access with administrative rights.
I’ll sleep soundly.
Tell me you use Windows without telling me.
I’m proficient and comfortable enough on any OS. I own no systems currently running Windows. And I don’t really care for Apple. And I’m not currently running BSD or Unix.
Would you like to guess again?
It’s been a while since I’ve encountered a TempleOS user
TempleOS?
Beat me to it 🤣
you’re obviously using novell netware.
c’mon, give us a hard one next time.
That brings back a memory. I got banned from the computers in highschool because I sent a message to everyone on the network using netware. They called me a hacker. It’s literally just clicking the system tray icon and go into like send message… The message? “Hello World!”
“Hack the planet!”
I swear I’ve seen either Zero Cool or Acid Burn around here somewhere.
“Said hello to 1,507 systems at once… front page of the New York Times!”
Well at least you didn’t hack a Gibson
OS/2, surely. Or maybe BeOS?
BeOS? Oh dear, no.
I could see running Haiku.
Just kidding, no way!
Didn’t say “I’m not currently running Apple”, just said “I don’t really care for Apple”, therefore you may be using Apple, without caring for it.
Phone runs Android. I used to work as an Applecare Advisor supporting iOS and OS X.
Guix! … does guix count as a unix derivative?
I do suppose Linux is a Unix derivative. So you’re closest. But no cigar.
Linux is like Unix but not derivate
Heavily inspired by? I understand that Linux is not derived from Unix source code. But the system architecture… Is extremely similar and in many ways functionally the same.
In art, music, literature, architecture, and ideas, something can be derivative because it inherits a form, vocabulary, conventions, conceptual framework, or design tradition from something earlier.
Plan 9?
Redox OS?
Good lord, man
Well that’s OK; we recently discovered that things like passkeys usually aren’t using the TPM anymore anyway. Most stuff stored in there can be routed around via tokens stored on main storage.
I’m honestly amazed by this. Passkeys were the touted solution to all our human password problems. How is it that something so critical went unnoticed until recently?
You’d think this would be something that gets caught before release. What went wrong?
IIRC, the Passkey spec did not specify the use of specialized hardware for key storage. So if this a case where people chose convenience over security without realizing they were making the tradeoff?
That would still be phenomenal. Who leads these sort of things and why is such a blatant issue unnoticed until most of us are affected?
It doesn’t matter how good a plan is if we can’t follow it. So what stops this issue from continuing to plague the next “great” solution to password management?
deleted by creator
