The pervasiveness of secure boot has genuinely made things difficult for attackers - there'd have been no reason for the Black Lotus bootkit to jump through all the hoops it did if it weren't for secure boot, and the implementation of UEFI secure boot does make it possible to remediate in a way that wouldn't be the case without it.
But secure boot at the OS level (in the PC world, at least) is basically guaranteed to give users the ability to enable or disable it, change the policy to something that uses their own keys, and ensure that the system runs the software they want. When applied to firmware, that's not the case - if Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled, you don't get to replace your firmware with code you control. There's still a threat here (we've seen firmware-level attacks for pre-Boot Guard systems), but the question is whether the security benefit is worth the loss of freedom. I wrote about this a while back (https://mjg59.dreamwidth.org/58424.html) but I lean towards thinking that in most cases the defaults are bad, and if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.
Would it be sensible to make that choice using a good old fashioned jumper? For example, when the jumper is connected to pins 1 and 2, the firmware must be signed by a list of vendor-controlled keys; when the jumper is connected to pins 2 and 3, the firmware must be signed by a list of user-managed keys. That way, I can choose what kind of freedom makes sense for me. Most people value the freedom of not having to worry about firmware, while others value the freedom to use or create their own firmware.
No, because the entire point of this is to be resilient against physical attack - anyone re-flashing your firmware already has your case open and can just move the jumper while they're at it.
Then netflix wont serve you HD content unless you run your OS with pin 1-2 setup as those are the only keys they "trust" :) This is what "trusted platform" is all about.
This would have such a niche market, but also be so wonderful. I would love to have a physical switch that toggles between, essentially, secure boot and a user-programmable boot.
>if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.
But even this is a potential risk all by itself if you aren't making sure this can only be done by someone with physical access to the hardware. Case in point is Dell and AMD EPYC CPUs that were locked to Dell firmware if they had been booted on a Dell motherboard in the past. It's bad enough that processors were being locked to Dell only without the user making the choice but that also allows for the possibility of some pretty potent ransomware. Not just holding data for ransom but holding hardware as well and with the same durable cryptographic guarantees.
Absolutely agree on here as Benjamin Franklin once said: "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
It's funny how blatantly the NSA doesn't care. They feign ignorance when asked or FOIA requested about it, but then also ask for a backdoor to opt-out of the Intel Management Engine[0]. It's like there's no coordinated effort to deny that it's an extreme vulnerability.
You're going to have to explain how, grounded in a reality where politicians fundamentally do not understand the idea of security and have to make decisions based on who sounded the most confident when they argued complete nonsense.
politicians know this can be abused, just like nsa, fbi or even local sheriff's... but they are glad because they're ones in position to abuse it.
my tinfoil hatted guess? china this past week had talks with FR, RU, BR and others. they probably got 3+ favors in exchange of this leak.
Or, someone wanted to blacklist someone else's key without a public name and included it in this leak. i wouldn't doubt MSI, intel and safe-pc-for-criminals-r-us keys happen to be present there.
Kind of/almost a good thing. More and more security processors seem to have irrevocable keys or other non-user setups. It's. Just. Not. OK.
And more and more governments are making demands about decrypting users data on demand, about blowing up security for their own greedy needs. They have no idea the awful horrific mess, the buggy by design systems we get when we forgoe security for their paranoid snooping. This is such a textbook lesson. Alas that we need another blow to the face to remind ourselves.
> It was a genius idea - you cannot install Windows 11 on an old computer. So you need to buy a new one.
> Monopoly practice hidden as security.
Actually you can, it's only checked by installer, if you modify it there is nothing stopping you from installing it. I have installed one on my parents computer. CPU wasn't supported but after installation everything worked ok.
On the other hand, never underestimate the ability of the "security" establishment to spin this as a bad thing and instill more fear and paranoia.
All these user-hostile in the name of "security" features do is take control away from and put it in the hands of some centralised entity whose interests certainly do not align completely with yours.
Isn't it good? Does leaked key mean that now owners of hardware will be able to read and modify the firmware, including IME, and check it for backdoors?
Such keys should be in the hands of users, not Intel.
Is everything that is gong to fail eventually just useless theater? Like new cars Re just transport theater because they will have to be junked eventually?
I agree that master private keys are bad security design, and we can and should do better. I'm just not willing to say that all past security value is retroactively nullified. That feels polemic more than realistic.
I've read a lot of anti cheat RE in the past, seems like the cheater/modder people have found their way to the infosec community, can you elaborate on how this would accelerate Valorant cheating.
Is their watchguard thing using some Intel feature?
Is there any tutorial that I can learn to do it? Should I Google "dump Intel firmware" or some other more specific ones? I'm going to do some research after going through my training this afternoon.
Nothing's prevented you from reading the firmware - this is a signing key, not an encryption key. Multiple people have spent time reverse engineering the ME firmware, people have found bugs but no evidence of a backdoor.
There was this recent article (here in HN) about these "evil public charging ports that can hack your smartphone" and how there is an entire ecosystem of devices to protect against them.... when in practice no one has heard about any one single example of such evil charging port, and that in practice carrying out such attack is so target-specific and leaves so many warnings signs that the entire thing sounds implausible to say the least.
These evil maids are even more implausible than that. Has to be ridiculously targeted. If you are really targeted by such a powerful state-like entity, wouldn't it make much more sense for them to just send a NSA letter to Intel (or whatever the weakest link in your chain is, and there are plenty of extremely weak chains here, like the BIOS manufacturer) and/or backdoor the hell out of it?
Secure Boot was never about security for normal users nor security for the majority of us. This is like https://xkcd.com/1200/ all over again. At the point the attacker can write arbitrary bytes to your hard disk, its way past the point where the majority of users care.
I agree that this is the reason, but having Intel as the guard only makes it so that it could have already been hacked/leaked/bypassed and you never know.
At least if it was user controlled we can ensure that other people's leaked keys don't bypass our security.
The most alarming part of the article is that we are only really getting a revocation of these keys because they didn't pay a ransom and the ransomers were apparently too stupid to sell them secretly instead of releasing them to the public.
As far as we know, if MSI had paid no one would know that Intel shipped shared private keys to multiple vendors who could then lose them like drunken monkeys.
People ask why these weren't on HSMs.. The article seems to claim that they weren't even able to generate the most important ones in the correct locations, let alone on HSMs with non-extractable settings.
My concern is that MSI not announcing they were comprised implies they were going to act like they believe that. The keys were permanently compromised as soon as they were exfiltrated but there's no longer a market for buying them.
knowing the ramson is important for the window on how incompetent intel was... but paying a ransom for a secret is extra dumb. glad they didn't and announced.
AFAIK MSI didn't announce, the hackers leaked the keys themselves as a public service. For all we know MSI was still hoping to reach a lower ransom amount and then never disclose that the keys were most likely sold in the exploit market.
I think we have to assume Intel was willing to put together a broken system with total incompetents. I think the US is better off with foreign chips watched closely than Intel watched poorly.
Readit News
But secure boot at the OS level (in the PC world, at least) is basically guaranteed to give users the ability to enable or disable it, change the policy to something that uses their own keys, and ensure that the system runs the software they want. When applied to firmware, that's not the case - if Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled, you don't get to replace your firmware with code you control. There's still a threat here (we've seen firmware-level attacks for pre-Boot Guard systems), but the question is whether the security benefit is worth the loss of freedom. I wrote about this a while back (https://mjg59.dreamwidth.org/58424.html) but I lean towards thinking that in most cases the defaults are bad, and if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.
But even this is a potential risk all by itself if you aren't making sure this can only be done by someone with physical access to the hardware. Case in point is Dell and AMD EPYC CPUs that were locked to Dell firmware if they had been booted on a Dell motherboard in the past. It's bad enough that processors were being locked to Dell only without the user making the choice but that also allows for the possibility of some pretty potent ransomware. Not just holding data for ransom but holding hardware as well and with the same durable cryptographic guarantees.
At least as far as Benjamin Franklin would tell you: No.
Dead Comment
[1] https://www.fbi.gov/about/mission/lawful-access
[0] https://en.wikipedia.org/wiki/Intel_Management_Engine#%22Hig...
There is no scheme that only gives good people access. We can and must hammer this home.
Yes. That's the simple message to keep pushing. Especially when some attack demonstrates that it's true.
my tinfoil hatted guess? china this past week had talks with FR, RU, BR and others. they probably got 3+ favors in exchange of this leak.
Or, someone wanted to blacklist someone else's key without a public name and included it in this leak. i wouldn't doubt MSI, intel and safe-pc-for-criminals-r-us keys happen to be present there.
And more and more governments are making demands about decrypting users data on demand, about blowing up security for their own greedy needs. They have no idea the awful horrific mess, the buggy by design systems we get when we forgoe security for their paranoid snooping. This is such a textbook lesson. Alas that we need another blow to the face to remind ourselves.
Monopoly practice hidden as security.
Secure Boot is part of UEFI. TPM2.0 is used only by bitlocker (at least for the average person, enterprises do store other keys in it).
> Monopoly practice hidden as security.
Actually you can, it's only checked by installer, if you modify it there is nothing stopping you from installing it. I have installed one on my parents computer. CPU wasn't supported but after installation everything worked ok.
Dead Comment
It was dumb because they thought the key would remain secret only to them, and thus provide an elegant balance of security and safety.
On the other hand, never underestimate the ability of the "security" establishment to spin this as a bad thing and instill more fear and paranoia.
All these user-hostile in the name of "security" features do is take control away from and put it in the hands of some centralised entity whose interests certainly do not align completely with yours.
Such keys should be in the hands of users, not Intel.
I agree that master private keys are bad security design, and we can and should do better. I'm just not willing to say that all past security value is retroactively nullified. That feels polemic more than realistic.
I like it, going to hang on to this one
These evil maids are even more implausible than that. Has to be ridiculously targeted. If you are really targeted by such a powerful state-like entity, wouldn't it make much more sense for them to just send a NSA letter to Intel (or whatever the weakest link in your chain is, and there are plenty of extremely weak chains here, like the BIOS manufacturer) and/or backdoor the hell out of it?
Secure Boot was never about security for normal users nor security for the majority of us. This is like https://xkcd.com/1200/ all over again. At the point the attacker can write arbitrary bytes to your hard disk, its way past the point where the majority of users care.
At least if it was user controlled we can ensure that other people's leaked keys don't bypass our security.
As far as we know, if MSI had paid no one would know that Intel shipped shared private keys to multiple vendors who could then lose them like drunken monkeys.
People ask why these weren't on HSMs.. The article seems to claim that they weren't even able to generate the most important ones in the correct locations, let alone on HSMs with non-extractable settings.
Deleted Comment
I think we have to assume Intel was willing to put together a broken system with total incompetents. I think the US is better off with foreign chips watched closely than Intel watched poorly.
Announcement: http://blogvl7tjyjvsfthobttze52w36wwiz34hrfcmorgvdzb6hikucb7... (link likely to be invalid over time, since the number seems to change)
Link with the actual data: http://vkge4tbgo3kfc6n5lgjyvb7abjxp7wdnaumkh6xscyj4dceifieun...
(Links found via https://www.ransomlook.io/group/money%20message)
https://github.com/binarly-io/SupplyChainAttacks/blob/main/M...