Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security
securityonline.info
securityonline.info
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.
A switch that can’t be controlled via software is at least more secure than the alternatives. If you check the jumper before booting up you can still be 100% sure even if someone previously flashed stuff onto it. Remember, it is called secure boot, not secure flash, so fw get verified again during boot up.
Not really. Secure Boot also guards access to tamper-resistant security modules like the TPM. Replacing the whole machine would never give you access to the old TPM. And if, for example, the disk is encrypted using using keys stored in the TPM, replacing the board won't work. Same even for OS-level keychains and credential stores even if the entire disk isn't encrypted.
if i have access to the tpm and the system, i can MitM it.
safeboot is perfect in a theoritical ideal vacum. something that bored reaearchers look and nod.
but keys leaking, hardware hacks, etc... are not even considered to not disturb the safety blanket everyone wrapped themselves with. yeah it makes it inconvenient for boot kits, bit that's it. if you can install os updates, i can install a boot kit
This is if you unlock your machine after an attacker has had physical access to it. "Evil maid" attacks are well-known (that is what these are called, someone installing MitM hardware on your computer). Whether contemporary machines are actually resistant to it in practice I am not sure.
So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?
PS: thanks for all the blog posts you share on the matter! they are really golden
I saw this "but it only prevent persistence" several times and I wonder...
Isn't preventing rootkit from getting persistence already a big win? Preventing a rootkit from getting persistence also means that should a new signed kernel contain a security fix fixing the hole the rootkit was exploiting be installed, the rootkit won't work at all anymore. The attacker now needs not only to root the machine at each boot, he also needs to cross fingers that a kernel patch closing the hole he's exploiting doesn't get installed (or he needs to both prevent the new kernel from being installed while, at the same time, managing to make believe it's been installed).
Which also raises the probability the exploit he's using at every boot gets detected at some point.
How is this a win for attackers?
Are black hat hackers really thinking "Great, BootGuard and SecureBoot are getting ubiquitous, everything up to the kernel loading is signed and enforced, so now things are easier for me!"?
At least as far as Benjamin Franklin would tell you: No.
The ones who write the code make the rules. The ones who make the rules, wield power. Those that are attracted to the exercise of power, inevitably abuse it.
Trying to handwave that "computer says no" couldn't possibly be abused to political ends is literally shoving your head in the sand. DRM would not be a thing if computing was fundamentally apolitical.
Any code I didn’t write myself, from the ground up using no third party components, in a language I developed, ‘could’ possibly be abused in this way. Even then, do I have to also write the microcode in the chip as well, and supervise the fab? This extreme absolutist stance is completely non viable. I certainly don’t see how I could live life taking that level of extreme paranoid seriously, or how anyone could in an advanced technological society.
The whole point of laws and government is to outsource such concerns. That’s why free speech, the rule of law and democracy matter so much. Those are the essential freedoms he was talking about. Everything else is based on those, because with those you don’t need to trust the vendor, because your legal rights will be protected.
So sure, essential freedoms are exactly that, essential, but extending that to absurd lengths is fuzzy thinking that obscures what’s actually important by confusing it with things that aren’t practically attainable generally anyway.
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.
https://apnews.com/article/congress-data-breach-hack-identit...
It's to maintain the status quo no matter how corrupt or abhorrent it is. The word enforcement says it all.
The way the system is supposed to work is that engaged citizenry actively overhaul unjust laws and apparatuses, and the police then enforce those new laws.
Unfortunately we have abysmally low civic engagement in most of the western world which leads to the mess we are currently in.
I like to make fun of the French as much as anyone else but I really respect and admire the French people's propensity for protest and to stand up for what they believe. That's advanced citizenship in action.
I'll agree that the citizens of France feel empowered while Americans feel disempowered. And empowerment is a natural consequence of identification with control of larger structures.
Most Americans don't feel like they have any control over larger structures in their countries.
This is called "working the refs" or "talking their book".
Americans' main interest in local government is blocking new housing project to pump their property values. So no matter what happens they just say there weren't enough meetings about it and the project needs to be cancelled because it didn't get community input.
You don't have to believe them on larger political topics for the same reason you don't have to believe them here.
Ironic considering the gun narrativr
It's also completely ineffective, because the government can just ignore them when they get bored, and they don't actually get voted out or anything.
Sometimes they do, sometimes they don't. Democratic systems of government are messy, and that's okay. It's not for you or me to decide what's a "good" thing to protest.
It's not part of the process, nobody has to listen to you.
If you want a rep to know your opinion on something you can call them.
The point of a protest is for when they're not listening to you, which is why they feature more in not-officially-democratic politics like dictatorships. But for that to work, it has to be so large they can't ignore you. (Otherwise, if they're small and still work through being annoying it's minority rule, which isn't democratic. But like I said that doesn't happen because you can just ignore them.)
All politics depends on popular support because your subjects can either leave the country or have you killed if they really don't like you. Democratic politics means there's official channels for exercising this by voting instead of having to do this.
Actually, I think there is one - government media. CBC/BBC/etc should cover these instead of covering them up. If they represented the citizens voices honestly, they might not feel they have to blockade parliament to get their point across.
> Democratic politics means there's official channels for exercising this by voting instead of having to do this.
That breaks down a bit when your media only presents one side of certain issues.
There's no requirement for corporate media to be honest, but for state media paid for by the citizens that's basically its only purpose.
> If you want a rep to know your opinion on something you can call them.
You can contact them, but if you can't do it in public others won't know and they can basically kill issues by just ignoring them.
We need to steelman the views of our countrymen, not mock them.
Think of what they'd say about your side if the tables were turned.
You'll be disappointed then. The French are protesting for benefits and not for social change. Aka, they are not better than the police they are engaging with.
What's wrong with that?
Source: observing last 25 years of US politics.
As for facts even without the recent "alternate facts" the truth is you can easily come to radically different conclusions even based on the same facts.
Facts aren't facts basically :)
> Just because people are "good and decent" doesn't mean that the outcomes they support are thus.
That's exactly what many on the right think of leftist policies. That the bulk of sustainable and healthy solutions should come from the grassroots, and that many government interventions are unsustainable and have profound unintended negative consequences that aren't fully appreciated by the calculus of the left.
I'm sure that's true, but those people aren't being voted for. Those people aren't in power and as long as people are voting for literal Nazis there is no discussion to be had. Can't have a rational discussion with people who don't believe you should even exist.
The most recent research suggests partisanship, esp negative partisanship, is rooted in identity. Which is to say facts, beliefs, positions are besides the point.
There have been many more recent follow ups, but the two books I read were Democracy for Realists by Achen and Bartels, and Why We're Polarized by Ezra Klein.
As a recovering activist, this has been very hard for me to accept and adjust to. What hope is there if discourse and persuasion don't, can't work? I have no clue.
So I just focus on the work.
YMMV.
And I don't recall anyone calling the Clinton emails a Russian anything, unless you think that the people building the case against her were compromised.
I do recall that someone ran on a campaign of prosecuting her for it, but somehow, that was forgotten right as soon as the words left his mouth...
A half dozen people testifying that our last president was a serial rapist?
The head of the Supreme Court whining that when congress appoints a probable rapist to the court, the double standard is that the court should be above politics, and not comment on such things, but the press covers it anyway?
At least two of those things actually made the news yesterday.
I’m really not able to think of anything sufficiently salacious to get any more shit on the fan.
Also if you need another recent example you could reference Dianne Feinstein.
[1] https://www.pbs.org/newshour/nation/old-school-pharmacy-hand...
[2] https://nypost.com/2017/10/11/pharmacist-hints-some-congress...
Have we lived in the same past few years? At this point, if one of them turns out to be an actual baby-eating reptilian, he'll still get keep his fucking seat next election, as long as he has the right letter next to his name, while the party that professes to hate baby-eaters will keep voting for him.
If you have no shame, scandal slides off you like water off a duck's back.
https://amp.theguardian.com/world/2022/nov/11/medical-data-h...
By the time millennials and gen z are running the place, we’ll have moved on to misunderstanding AI or something like that.
https://www.nytimes.com/2014/08/01/world/senate-intelligence...
I'm pretty sure a lot of lawmakers still take this shit seriously.
The weak link is the campaigns.
We continue to elect charismatic fools (and sometimes charismatic criminals) because we're charmed, or scared, or bewildered, or just too damned tired to care.
Until that stops, there's really no justification for expecting anything rational to come from our leadership.
Especially the unethical and downright criminals, who put all their effort into putting on a fake legitimate facade.
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.
[0] https://en.wikipedia.org/wiki/Intel_Management_Engine#%22Hig...
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).
The fact that Windows 11 won't work without a TPM is a bonus.
This isn't true at all, Windows Hello uses it as a secure credentials store.
> 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.
Not a huge loss in my eyes, I see Win 11 as a strictly worse OS than Win 10. Haven't yet seen any feature whatsoever that strikes me as an improvement.
They stopped doing OEM licenses?
This theft happens, that's the cut-and-dry of it.
Stealing luggage is so rare it’s meaningless. If you are really worried about your luggage, the easiest way to steal someone’s luggage is at baggage claim and just knock the lock off after they leave the airport.
There isn’t a ring of thieves at the airport stealing your clothes.
Lost luggage and delayed luggage is a bigger concern.
I still miss it...
The rest of the story is that my wife and I literally have everything we own - aside from our former home that’s now a rental and our “winter home” thats rented out 7 months a year - in 4 suitcases and two carryon book bags.
If we lost all four of our suitcases, it would be a nuisance. But we could rebuy everything for less than $1000.
The only time that our stuff was mishandled was when I made a mistake and put her portable mixer (Amazon - not an affiliate link https://a.co/d/iBQivv5) in my checked bag. I could see why X-rays thought it looked suspicious. They broke the power cord.
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.
Security is about tradeoffs, most notably security vs convenience, but also many others.
Anyone who suggests that their personal preferences in tradeoffs are not just universally correct but also the only reasonable position to hold is just silly.
I really hope no one would ever think this non sarcastically.
Oh no! That will never happen. Because it runs on Apple M1 kryptonite chip that even Superman can't touch. /s
For most people there are, in fact, no legitimate reasons to run "their own" software on "general purpose" (read: household appliance) computing hardware. Almost nobody runs custom software on their washing machine or toaster.
But then we still also have things like Crypto AG.
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.
Real but temporary security -> This 2048 bit key you generated will be commercial grade protection until at least 2030. Sometime after that computers will be strong enough to brute force it. Do not store anything with this key that will still be highly sensitive in 7 years. It's possible the underlying algorithm is cracked, or a leap in quantum computers happen that will make the key obsolete sooner.
Security theater -> All software running on this chip must be signed with our master key. Please trust all software we sign with this key, and no malicious party will have access to it. You are not allowed to run arbitrary software on your hardware because it is not signed with our key.
In the first case, the security is real. You own the lock, you own the key, and you control the entire security process. In the second case, you neither own the lock, the key, and basically have limited access to your own hardware.
IT admins are thrilled to have limited access to their own hardware, as long as adversaries do too.
In corporate IT, the greatest fear is insider attacks, either knowing or because statistically some users will inevitably make mistakes. Secure boot is fantastic in this context, even if it feels like an unreasonably impingement to gamers / tech enthusiasts.
Part of the blame, imo, lies with how clunky tools are at the lower levels. I've seen plenty of hardware based signing protocols that don't allow for key hierarchies.
Higher level tools push this along as well. Hashicorp Vault also, last I checked, doesn't allow for being a front end to an HSM. You can store the master unlock key for a Vault in an HSM, but all of the keys Vault works with will still be in Vault, in memory.
As for games, lots of people play games and want good anticheat. If you don't like that you don't have to play those games but no need to act like the way you are because other people want decent anticheat.
Because it’s social pressure to compromise your computer to a gaming company to get to play a game.
People don’t care about the anticheat on their computer, they want it foisted on everyone else who plays, which is a sucky proposition for privacy and security minded people.
It’s like advocating for the TSA to be controlling access to the grocery store because you want to feel safe there and don’t mind the privacy violation.
What do you mean by this? As the user you are intending to have the game and its anticheat run. Having to download and run a game on your computer isn't compromising your computer either. Maybe the only thing which doesn't give the game company power to run potentially malicious code on your machine is cloud gaming. That also solves the cheating problem at least.
The isolation still exists for normal programs when the anticheat is present.
Would you also support a full cavity search each time you decide to fly a plane?
The kernel module has full access to your hardware, you don't know what it does exactly. You don't even know if it does something more than anticheat.
People got so complacent in recent years, and this is on a technology forum no less. I guess today the Sony rootkit[1] would be totally acceptable.
[1] https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
You don't know what the game will do either. It requires trusting Riot even if there isn't an anticheat.
Also most users will never know what the other kernel level drivers do.
>Would you also support a full cavity search each time you decide to fly a plane?
I don't see how this is related?
>The kernel module has full access to your hardware, you don't know what it does exactly.
The same can be said about any other kernel level driver and even about Windows itself.
>People got so complacent in recent years, and this is on a technology forum no less.
What Riot wants to do is not possible with a user level anticheat. Once Windows eventually gets its security improved such that apps can query the integrity of the system Riot would likely be able to get away with a less privileged anticheat.
>I guess today the Sony rootkit[1] would be totally acceptable.
If it didn't try and hide itself I would agree with you.
No they want games without hackers. Which kernel based anticheats helps with. Can it also impact privacy and security? Yes no doubt but so can any program running on the computer even in userspace. Remember we are talking about kernel anticheats on windows lol.
If you are really worried about it you could dual boot like many people. Either way this whole argument seems silly to me.
Hackers are mainly only problem for anonymous ranked matchmaking. That's not to say cheaters don't exist without it but they are a) much less disruptive b) have much smaller reach and therefore c) are less motivated.
Like most ills being used to push anti-user technology, cheating is primarily a problem created by the industry itself.
Great, let's install a backdoor in every computer so that some people can play games and watch movies. No. Computer is a thing for computing numbers not a replacement for a TV.
I understand this is the internet and being super dramatic is part of it but can we please be for real for one moment?
https://www.reddit.com/r/riotgames/comments/12wr2hz/kernelmo...
https://www.reddit.com/r/ValorantTechSupport/comments/kfxy9a...
2. All it actually does is keep users trapped in Windows. God forbid anyone actually use Linux, or even a VM!
The only actually effective anti-cheat is the original: moderation.
Now that users aren't able to host their own servers, they can't do moderation. Game studios don't want to do moderation themselves, so they keep trying (and failing) to replace it with automated anticheat systems.
Good anticheat? Just play with people you know instead of random strangers. Thats your anticheat right there.
I'm not sure it's a good thing at its core. The intent seems legit on the surface, but digging into the implementation you'll always end up having an adversarial relation with your user's security and device ownership.
On games, I kinda see this as an argument for preserving a special status for consoles, where the maker keep a right to secure everything to insane levels. Doing the same on general purpose computing platform isn't acceptable. Banking and digital currencies are morr of a blurry line, but games definitely shouldn't be accessing the utter most secure system of the platform.
If anything, opening the door to a whole community to hack the base security of your computing life when litteral life and death applications also rely on those shouldn't be allowed.
Better than having keys which I cannot control on my computer. And I don't play games anyway.
https://en.wikipedia.org/wiki/Evil_maid_attack
"The name refers to the scenario where a maid could subvert a device left unattended in a hotel room – but the concept itself also applies to situations such as a device being intercepted while in transit, or taken away temporarily by airport or law enforcement personnel. "
And law enforcement will have a device to bypass most devices security
What makes you say that and how is that an excuse to do nothing?
In case of a malfunction, you risk loosing all your data
Threat actors and law enforcement can bypass it
UEFI threats moving to the ESP: Introducing ESPecter bootkit https://www.welivesecurity.com/2021/10/05/uefi-threats-movin...
That said, "Evil Maid" fits here because of that - they are no someone that you expect to need technical protections from but theoretically they could be a genious adversary or just hired by one.
At least if it was user controlled we can ensure that other people's leaked keys don't bypass our security.
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.
it'd just be a matter of replacing a binary with a iffy'd version that runs before any decryption happens, e.g. replacing plymouth.
This isn't hard to do in the slightest? I think even you or I could do it.
But with secureboot, replacing a binary in the loading chain isn't an option.
I don't think I could convince intel to install a bug for me.
https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.h... is a good descriptor of how it all comes together
> it'd just be a matter of replacing a binary with a iffy'd version that runs before any decryption happens, e.g. replacing plymouth.
You'd at least need to imitate the UI your target is using for unlocking the disk (e.g. plymouth theme). Then, after the user types something, either virtualize the rest of the boot process (which is already extremely implausible), or otherwise reboot in a way that does not immediately cause the user to be suspicious. All of this is as targeted as it gets. A generic version would get as far as your average phishing email.
But... how do you plan to replace my bootloader in the first place? You'd need root access for that. At that point, it is already game over for the target! Why would you need to tamper with the bootloader at that point?
Or are you thinking about breaking into my house and do that in my offline computers ? How is that not a "targeted attack" ?
> You'd need root access for that. At that point, it is already game over for the target! Why would you need to tamper with the bootloader at that point?
Yes that is the crux of the Evil Maid attack, a drive-by install of software. e.g. at a coffeeshop while one is on the toilet, at an office, at a hotel by an evil maid, etc etc. AEM is about detecting changes in trust: if the loading sequence is changed, then the verifier (another device like a usb dongle) can't verify (since the TPM can no longer unlock the prior secret due to the chain changing).
You might want to look into the article I linked in my earlier comment to get the full idea of what is meant by evil maid
If the laptop was left online and unlocked: What do you expect to gain by installing a patched plymouth versus installing a traditional remote control software and/or keylogger ? You don't even need root for the latter!
If the laptop was left locked: do you plan to open the laptop, remove the disk, transfer some files to it (matching the same distro & version of all components your target was using, otherwise the entire thing may just crash or look different and reveal the attack), hope the target doesn't notice his laptop was literally taken apart (most laptops just can't be opened at all, for the ones which can, even mine has a simple open-circuit tamper detector...), then come back in the future _and do the same_ again to recover the captured password? And how is this not a ridiculously targeted attack?
Besides, at that point, you could simply install a wiretap on they keyboard, an attack which unlike the evil maid crap I have seen _millions_ of times in the wild (e.g. at public pinpads, card readers at gas stations, etc. ).
But yes if the OS also let’s you change the boot ROM then you can make your root access semi-permanent.
I like it, going to hang on to this one
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.
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...
Hasn't intel heard about locking keys in hardware, e.g. like with hardware security key modules similar but faster/flexibler then a TPM. Surly one of the main developers of TPM does understand that concept.... right? /s
there are more then just one or two ways to not have that risk and still have HSK
best many of this solutions scale pretty much to any arbitrary company size
>The leaked private keys affect Intel’s 11th, 12th, and 13th generation processors and were distributed to various OEMs, including Intel itself, Lenovo, and Supermicro.
Why distribute the keys themselves instead of having some way for the motherboard manufacturers to upload an unsigned firmware and then download a signed one? That is probably laziness.
Like what https://erfur.github.io/2019/03/28/down_the_rabbit_hole_pt3.... could do before BootGuard?
I ask because this would enable a lot more security: I could mod my bios, and add a extras EFI module signed with my key that wouldn't trigger bootguard: then later during the boot, an encrypted grub or whatever could check them, say with a TPM enrolled key having their hashes: this could make the computer refuse to boot further if say the MAC address of the network card (or the CPU serial, or the NVME serial) doesn't match what I added.
Yes, an evil maid attack could do the same to me (by removing these checks I've added and replacing them say by nops), but that would alter their hash.
And if the secure boot payloads signed with my own key first check the existence of these modules, and then verifies that their signature (kept inside my signed payloads matches) my versions (and not the evil maid or the manufacturer original) I'd still get the benefits of secureboot - just with my own keys all the way down.
The it'd be super interesting to have!!
So even if they push an update, people can pretty easily downgrade to a vulnerable version if they want to.
Why is a project like, say, Debian, even bothering signing kernels:
https://wiki.debian.org/SecureBoot
What's their rationale for supporting SecureBoot?
As a sidenote for having installed Debian with SecureBoot on on several systems, I'd say I still had to muck around quite some in the BIOS/UEFI. Latest one I scratched my hair for a bit was an AMD 3700X on an Asrock mobo where I somehow had to turn "CSM" (Compatibility Support Module) off otherwise Debian would stubbornly start the non-UEFI (and hence no SecureBoot) installer. On my Asus / AMD 7700X things were a bit easier but I still had to toggle some SecureBoot setting (from "custom" to "default" or the contrary, don't remember). All this to say: it's still not totally streamlined and users still need to muck around anyway.
> Other Linux distros (Red Hat, Fedora, SUSE, Ubuntu, etc.) have had SB working for a while, but Debian was slow in getting this working. This meant that on many new computer systems, users had to first disable SB to be able to install and use Debian. The methods for doing this vary massively from one system to another, making this potentially quite difficult for users.
> Starting with Debian version 10 ("Buster"), Debian included working UEFI Secure Boot to make things easier.
Sounds plausible, but I don't know how seriously to take it, when that wiki page also includes very generous and regurgitated-sounding bits like:
> UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.
I normally look to Debian to be relatively savvy about detecting and pushing back against questionable corporate maneuvers, but it's not perfectly on top of everything that goes on.
I've also seen Debian very responsive when I pointed out that a particular package was phoning home before consent given.
And one of the notable annoying parts of the Debian installer forever is when you think it's started a long unattended period of installing packages, but it soon pauses to ask you for opt-in to some package usage telemetry (so at least they're asking before doing it).
I definitely get the understaffed vibe from Debian, but I'm also still pleasantly surprised how well they execute in general.
Contrast with a certain commercial derivative -- which snoops, installs closed software without the user understanding that's that they're doing, pushes an IMHO horrible different package manager, is sloppier about regressions in security updates, etc.
I wish I had time to volunteer right now to scratch some of the itches I have with Debian, and very much appreciate all the work that others have done and are doing on it.
People might not like who holds the commonly preinstalled keys (Microsoft and motherboard OEMs) but even then you can add your own keys and sign your own images if you want (there was just a post yesterday about doing this for raspberry pis),
That's just creating more ewaste, nobody can ever use that device normally again and it cannot be resold.
Of course if you lose your keys you can't sign anything else and that would make it basically ewaste, but most things end up as waste when you take actions that are reckless and can't be reversed (which is what losing the keys would be). Plus tech tends to ends up as ewaste after less than a decade anyways. Like sure you could still be using an AMD steamroller CPU but realistically after 10 years you'd be better off using a cheaper more power efficient chip anyways.
I'm not sure what you are trying to argue but people routinely buy used computers on market place. Rasperry pies with locked keys are essentially paper weights once the owner doesn't want to use them anymore.
And realistically, the biggest ewaste generators are especially smartphones nowadays which are too locked to be reused well.
Why can't the owner who wants to sell their locked Pi give the buyer the key?
I like SecureBoot, and I like that I can select my keys to sign things the UEFI will run, but I don't like that I can't replace the UEFI itself since it's protected by bootguard.
Now if I can edit the UEFI, that's a gamechanger: I could have my signed UEFI payloads check the UEFI firmware has the parts I want (or don't want) and refuse to keep booting if it doesn't
Using something leaked always carries some inherent risk.
I don't think "it's just characters" is a one-simple-trick.
"Your honor, I wasn't copying that movie. You see, I applied a mathematical formula to the .zip file, and it just happened to produce the movie as output. Coincidence!"
(That's not to say the key is copyrightable, it's not. I think the relevant law would be the DMCA anti-circumvention provision.)
Technical people tend to see the law as a technical thing, where technical arguments will win. Courts are generally unamused, since every judge has years of experience with defendants who think that they've discovered one simple trick.
Depends of the legislation.
That's questionable in the US since the keys are 100% machine generated and thus not copyrightable.
In most of the EU, it's clear though, there's interobability exceptions and those keys can be shared freely.
I just want to specify the root of trust.
Even if you were to completely replace all of the signatures with your own, you are going to have to trust some of the MS/manufacturer ones (unless you replace all the manufacturer-signed firmware modules with your own).
... of which there might not be any. Eg none of my half-dozen SB-using systems (desktops and laptops) have anything in the ESP other than the booloader and UKIs I put there, and boot with my own keys just fine.
Afaiu, this key is specific to certain generations of Intel CPUs.
How can you test the leaked key say to edit your bios, resign it, then reflash it?
According to the Twitter thread above, you would upload the original OEM firmware for your device to Binarly's web portal at https://fwhunt.run. The firmware file matching your device could be obtained from the OEM's website, rather than the running system. I haven't tried this myself, don't know if it requires unpacking or pre-processing the OEM firmware file format.
It seems safe, but I'd rather do that locally.
Hopefully Intel and OEMs will make official statements soon.
If you're copying a firmware file from the OEM's website to Binarly's website, then receiving a text report, they would have an IP address, browser fingerprint and device model number, but little else.
Obviously it isn't in everyone's skillset, but if you have the means there is nothing preventing you from generating and using your own key.
Honestly it seems like a good basic security precaution, not only to prevent against leaks like this, but also to counteract any backdoors (although kind of a moot point with chipmakers).
1. some EFIs are broken in ways that make using private platform keys hard or impossible
2. there are PCIe cards which need option ROMs to be executed (most commonly that dedicated GPUs), this ROMs are not always but often signed by one of the Microsoft Keys and removing it from the trust db will prevent the ROMs from running and lead to all kinds of problems, e.g. not having any video and in turn not being able to undo to EFI setting/disable secure boot. You can make sure the specific ROMs are whitelisted, but then you need to be very very careful about e.g. graphics drivers updating the GPU firmware and similar. And putting the right data in the trust db isn't easy either.
If you're using a TPM for Secure Boot, you can use the commands in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.
Because of this validating option ROMs is _very_ important to a point some would argue it's more important then validating that e.g. your Linux kernel has not been modified
Honestly option ROMs IMHO should not exist in the way they do (for security reasons), but they outdate secure boot by quite a bit and like many of this "old legacy features a lot of things depend on" are just really hard to get right of.
Through without question the design this ended up with has a terrible UX.
But most laptops with a reasonable EFI implementation and no dedicated graphics card do luckily not have option ROMs (through their firmware update tool might have something similar, but you can just not use it).
Most option ROMs are signed by the same set of Microsoft keys, You can make sure to enroll this keys alongside your custom platform key (e.g. the tool sbctl can do so for you). While this does tend to work it has one drawback which is if someone has that key they can break your secure boot chain, i.e. it weakens the benefits custom platform keys give you.
Option ROMs signed by vendor keys are somewhat rare, but sometimes (parts of) firmware update tools are signed by vendor keys, in which case you can choose between not updating your firmware, disabling secure boot while doing so or hoping you can find the (pub)keys for the keys they used somewhere on the internet.
In the end you probably want to see if someone already tried it and had success.
In many BIOSes were you can apparently remove all keys and the firmware still loads its own builtin components, that's because the manufacturer has put a backdoor so that their own components can always be loaded irregardless of Secure Boot state. (Otherwise users would be able to brick their own machines). MSI, for example, does this. And guess what: with these leaked keys, now anyone can claim to be a "manufacturer's own component". Secure Boot is useless.
You are going to tweak them again, and check down the line (ex: grub) that they match the hash you've stored, say inside you secureboot, or in your TPM
This should get you MORE security: before, you had to accept whatever the board manufacturer though it was ok (ex: any WWAN or WLAN cared with just these Ids). Now you can add more checks (just this serial or mac address) and refuse to boot.
Someone could do the same, but if you verify at the next level (ex: grub, etc) that you tweaks are present, you can refuse to boot if they aren't.
Give me a break.
For the sake of convenience we ended up with an inversion of control. There can still be a chain of trust. However the owner of the machine should be the root of the chain, not the vendor/manufacturer. the vendor should sign their firmware and the owner should authorize that sig on the machine.
>>In April, MSI fell victim to a cyberattack perpetrated by the ransomware group Money Message, who successfully infiltrated MSI’s internal systems and exfiltrated a staggering 1.5TB of data, predominantly comprising source code.<<
https://securityonline.info/intel-oem-private-key-leak-a-blo...
that's a lot of source code it makes my typing fingers tired just thinking of it
It's possible they could have written it if all 2,672 MSI employees typed this source code constantly in 8-hour shifts seven days a week for five years with no lunch break no restroom break and not allowed to think before typing.
If Intel Boot Guard works by including a public key in a fuse in all CPUs from a set of series and now the corresponding private key is leaked, why isn't this a global problem? The same CPU with the same public key must be in every machine with an Intel CPU from these generations. What am I missing here?
> The boot chain uses an RSA public key (its hash is hard-coded inside the CPU) and an OEM private key. The OEM sets the final configuration and writes it to one-time-programmable Intel chipset fuses during the manufacturing process, thus making it almost impossible for an attacker to modify the BIOS without knowing the private part of the OEM Root Key. However, because some OEMs might fail to properly configure Intel Boot Guard, attackers could end up injecting code and permanently modifying BIOS.
> At Black Hat 2017, security researcher Alex Matrosov presented some vulnerabilities in poor BIOS implementations, explaining that not all vendors enable the protections offered by modern hardware. Because of that, attackers could elevate privileges, bypass protections, and install rootkits, he explained.
Some HP business devices don't use Intel BootGuard, because HP has their own proprietary solution for firmware integrity verification, https://news.ycombinator.com/item?id=35845073
> The TPM's measurement can be subverted by an attacker who can re-flash the computer's firmware .. the attack .. can be defeated by having the initialization microcode hash the computer's firmware (specifically, the PEI code in UEFI) and communicate the hash to the TPM module. This is marketed as the Measured Boot feature of Intel's Boot Guard.
> Sadly, most computer manufacturers use Verified Boot (also known as "secure boot") instead of Measured Boot (also known as "trusted boot"). Verified Boot means that the processor's microcode only boots into PEI firmware that contains a signature produced by a key burned into the processor's e-fuses. Verified Boot does not impact the measurements stored on the TPM, so it does not improve the security.
On a related note, some HP devices have a dedicated security co-processor (SureStart) to verify and/or fix system firmware, instead of relying on a CPU vendor root-of-trust like Intel BootGuard. Since HP's proprietary security co-processor can be disabled by a device owner, those HP devices may be amenable to OSS firmware like coreboot.
2017 HP Labs research paper, https://ronny.chevalier.io/files/coprocessor-based-behavior-...
> We apply this approach to detect attacks targeting the System Management Mode (SMM), a highly privileged x86 execution mode executing firmware code at runtime .. We instrument two open-source firmware implementations: EDKII and coreboot. We evaluate the ability of our approach to detect state-of-the-art attacks and its runtime execution overhead by simulating an x86 system coupled with an ARM Cortex A5 co-processor.
2021 HP marketing whitepaper, https://www8.hp.com/h20195/v2/GetPDF.aspx/4AA7-6645ENW.pdf
> Every time the PC powers on, HP Sure Start automatically validates the integrity of the firmware to help ensure that the PC is safeguarded from malicious attacks. Once the PC is operational, runtime intrusion detection constantly monitors memory. In the case of an attack, the PC can self-heal using an isolated “golden copy” of the firmware in minutes.
For OS-specific measured boot of coreboot open-source firmware with a reproducible build, there would be a 1:1 mapping between the measured firmware hash and the coreboot source code revision used to generate the firmware.
Separately, the issue of firmware blobs (Intel FSP, AMD AGESA) would remain, although AMD OpenSIL is promising to reduce those binary blobs by 2026.
"To boot windows 69, you are now required to have a CPU with the newest Microsoft Chip, full of backdoors btw, but shhh" :p
Always self-sign the secure boot keys, do not use any third-party keys.
Unfortunately, this complicates the kernel & boot loader upgrade process as one shouldn’t keep private keys in the same machine.
Either you implement it with security features hidden from the device holder, in which case it will always be broken eventually, or you guarantee the capabilities with mathematics - in which case a security break cannot happen even if the physical machine's description is completely public.
There are certainly layers to this that I'm missing, but I think homomorphic compute is the only unbreakable answer to secure compute in general.
The issue here, of the key holder leaking the key, also seems impossible to work around in general, since the requirements are: 1) there exists someone who can sign code. 2) that person cannot screw up (e.g. leak the key) and allow the wrong code to be signed. These are pretty contradictory requirements, that no amount of crypto can fix. Ultimately it is a social problem not a technical one; there is no full technical definition of misusing a key. There are things that can help - like HSMs, splitting the key between multiple parties, having better methods of revoking and replacing compromised keys (hard without network access and an unwillingness to brick old devices). Not the same domain, but AACS is an interesting example of a system somewhat resiliant to key compromise.
I'm not sure if it's possible (given that there's overlap with public key/private key encryption it may be), but I think that if you could produce a homomorphic computer capable of plain text export, this would be a resolvable problem.
Holomorphic encryption allows someone's interests to be secured. But I'm dubious that I'm the one who will actually benefit here.
This also has major implications for cloud compute.
Do you have any idea how much software is on the average consumer device, and how poorly equipped the average consumer is to determine its provenance let alone decide what is trustworthy?
Not to mention that there are economic reasons to run untrusted software. For example no matter how little I trust Zoom and Slack, I don't have a job if I am not willing to run them.
If my kids want to play a game wirh me, I'll install the game. A pristine device that I can't use to further my values is worthless to me.
Maybe it might in theory make it much harder to audit, but its not like you are auditing all that code right now.
Microsoft solved this problem on the latest Xbox. Many years after it was launched, it's still not jail-broken.
They are now working on bringing that technology to regular Windows/PCs - Pluton.
I've got an MS-7E07 which is in theory not affected, but who knows...
So, you need to do a manual BIOS update to fix it.