>So good for security, but bad for e-waste and second hand sales

I concur, but it's true for even consumer devices like smartphones. Once the software updates stop, if security is the key then the devices are e-waste. Many times, I wish there was an International law which forces manufacturers to unlock their device when they stop pushing software updates to their device, so that alternate firmware can be installed. Of course this is just a wishful thinking, even those who abandoned their smartphone segment entirely(MS) didn't do this, So why would those who run profitable business out of planned obsolescence do it?

The law doesn’t need to be international, only one large enough market needs to do it. The market has to matter enough that the manufacturers won’t just say “screw them” and pull out of it. Then the mechanics are there and everyone benefits even those who live where there is no such law.

Manufacturers already sell unlockable/non-unlockable devices per-market. Not having this be international means they’ll just lock the device where they can.

It almost seems that a law like that would be something out of a sci-fi or cyberpunk universe.

We live in a cyberpunk universe. The only think it got wrong was aesthetic.

Instead of grunge everything is covered in RGB LEDs. Literally almost everyone my age has RGB LEDs everywhere. All over their rooms and not to mention keyboards.

Bright neon-colored lighting is a big part of the cyberpunk aesthetic.

Marginalised people living among e-waste in every Cyberpunk universe is already true anyways.

The UK is currently taking steps towards this - the plans aren't perfect, but will require "security updates until" dates, no default or symmetrically derived passwords, and a vulnerability disclosure programme to be available.

It doesn't go as far as to force unlocking, but requiring transparent disclosure of a committment to security update longevity (like Chromebooks and pixel phones have) is probably the first step along the road to that.

You can get a pretty good idea of how long security updates will be provided already, so does that help almost ever? Like, great, now Motorola has an official promise to do security updates for for 15 months post-launch. If they decide to release a permanently locked phone, the consumer's still getting screwed just as much.

Basically, "doesn't go as far as" sounds like a massive understatement.

>So good for security

This is entirely debatable. This is essentially bootguard for socketed CPUs similar to how most laptops behave. For one, it makes fixing the crap that Dell and their contractors write impossible. You cannot replace the bios with coreboot.

For all these features that require blessings, I really liked apple's use of the term notarised. Everyone should call these notarisation features rather than security ones. It's as boring and useless as going to a notary, if you have ever done that.

Notarization is good. Intel calls enclave signing “attestation”, which is clear to me.

Why couldn't they have put the key in user-resettable memory which erases the disk encryption key when cleared, like with TPMs for example? It was a poor design to even allow it to be used this way.

Booting from disk is the BIOS's job. The whole point is to guard against a compromised motherboard.

If the CPU prevents the disk from ever being unlocked, there's nothing to compromise by controlling the motherboard

This method prevents the user from trying to recover with a backed up encryption key, or booting live media. Instead it makes it clear that this motherboard is compromised and cannot be safely used.

And in the current model, what prevents the user from assuming the processor is dead and replacing it with an unlocked one (which will then presumably become permanently locked to the compromised motherboard)?

If you care about this specific attack scenario then make sure you check the keys with a management tool or something. It's not necessary to make the chip unusable for almost every aftermarket user just to make it a little bit clearer that a compromise has happened in that rare case.

Fair point. Though in many large environments the number of people with access to the IPMI console is greater than the number of people with physical access who can swap out a CPU.

I'm just trying to speculate what might be driving demand for this type of feature, since TPMs already exist.

> Its not really vendor locking by design. It locks to a signing key.

I see, so it's basically AMD's implementation of Intel Boot Guard, but on servers instead of laptops. On boot, the CPU verifies the BIOS's signature from its OTP memory and refuses to boot if verification fails.

Theoretically, if you move CPUs between different laptops, you'll find the CPUs are locked to its platform as well, but we don't feel it since they are not replaceable, the only visible effect is that the firmware has been locked and you cannot run coreboot.

And now the same thing is coming to servers and it has a bigger visible effect...

It is designed to destroy the secondhand market, the fact it can be hand waved away as "security" is just the smokescreen.

It could be implemented in a way that preserves the ability to reuse CPUs, but it wont be.

What would such an alternative implementation be?

I guess they could provide a key that works with all the fuses blown, and a utility to blow all of them.

In which case you could easily blow all fuses, sign your malicious firmware with the all-fuses key and you're good to go.

No, this won't work if the user is checking the attestation ability of the firmware or system. A similar exploit already exists by just modifying the firmware and expecting the user the just replace the CPU without checking the BIOS.

Wouldn’t it make more sense to blow the motherboard rather than the CPU? A compromised CPU without anything connected is pretty useless at boot. The motherboard is what’s connected to all the good stuff.

The CPU isn't what's compromised - this is protecting against a compromised motherboard

I think that’s the chicken & egg. If the motherboard was responsible for this, you’re trusting the firmware to validate itself. So this moves the validation a level lower.

It’s an interesting problem. The solution is valid, but it’s unfortunately permanent.

You could have a small rom firmware validating a larger ugradable firmware.

However, the root of trust is embedded to the CPU. So, you can't hammer the CPU on another board for keys.

Also, we sometimes lose the CPU rather than the board. As the CPUs become more complex, their probability to fail has risen.

> However, the root of trust is embedded to the CPU. So, you can't hammer the CPU on another board for keys.

I guess that's the key point here.

Would be interesting to know whether Dell will use the signing key to unlock the CPU if you ship it to them, or if it's like old motherboards where there is a physical procedure (it was typically to powercycle with a jumper between two pins that shouldn't normally be joined) to reset it, built into the hardware. Seems strange to be able to "brick" a CPU like that.

The article describes the mechanism as programmable fuses; so there is a near-certain chance these are one-time-programmable and can’t be reset. Ever.

(This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)

Fun trivia. The boot loader signing in the raspberry pi works the same way.

> (This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)

this made me think of the pencil trick from the earliest days of socketed athlons. not exactly the same I know.

I’d never heard of the pencil trick before but it’s quite interesting: http://www.ocmelbourne.com/tutorials/PencilTrick/PencilTrick...

The XBox 360 used the same technique for patches to keep you from downgrading the system.

Same for the Nintendo Switch.

Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.

Note - there is even a fuse that when blown, prevents other fuses from being blown!

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-323...

This is what distinguishes a normal iPhone from one that Apple engineers use, as well. If the fuse is blown, as it is in a production device, you can no longer control the boot chain.

Is there a downside to blowing that anti-blow fuse? Can its state be read?

It’s like an EEPROM that holds major version numbers and debug configurations. If fuse says “major version:20 allow debug: no, allow unsigned: no” and updater is for version 17->18, the user is trying to force a downgrade on a production board. Usually the updater refuses to continue and kernel do the same upon boot. Updater itself is signed and verified so checks are supposed impossible to bypass.

I believe Xbox 360 one was rewritable while Switch one is not. They also require higher voltages than rest of CPU to write. So modders used to modify PCB to block writes or tried to write old values. For Switch they had unrelated nonupdatable boot exploits to bypass signature checks for early batches.

Right, but they weren't asking about those normal fuses, they were asking about the special fuse that disables fuse-blowing.

And the simplest answer is that code could check if the fuses are reading out too early a version and abort. Which you could try to patch around but it won't be easy.

Is it even possible to unlock it with the signing key? Saying it's fused implies it's a one time thing, doesn't it?

I had the same initial reaction though. It seems like something that makes more sense as a jumper or something that can be reset by jumper so physical access becomes the requirement.

The only reason I can think of to do it as described is to kill the secondary market or, even worse, to maintain a lifetime licensing requirement on the system. If the signing keys can expire like signing certificates I expect step 2 will be custom signed firmware via a cloud portal where no license means no signing. I hope I'm wrong, but that's likely the endgame here.

TLDR; If the signature on the BIOS can expire, it's more nefarious than it sounds IMO.

You have to use on-die fuses to get most of the security benefit vs someone in customs who has a few hours alone with your server, as jumpers can be trivially modified to look like they are set/unset when they are not.

The header pins can be varnished (or other techniques) so they do not conduct, but they still look normal. To set a pin, 36GA wire between the plastic of the header and the PCB would do the trick. If the adversary had a particularly high budget, they could fabricate and install a header that would even pass inspection by a multi-meter's continuity check by making the outer part of the pins be electrically isolated from the inner, except where it contacts the PCB, where the attackers choice of conductivity is made.

I don't think anyone has come up with a good way to downgrade the CPU from secure operation to insecure without also creating a way to bypass it for an attacker. The only way I can think of is if there was a revocation of secure mode that put the CPU serial number on a public list, then after a week, the CPU blew a fuse allowing it to boot in insecure mode. It will allow enterprises to be assured that the computers they are sending all over the globe are untampered, but still allow people who don't care to get them second hand and not be stuck with the rest of the computer. The hard part is making sure the CPU can only blow that fuse after it gets an ack that its been a week. Ideally, there would be some way for the CPU to attest which mode its running in so secondary audits of the CPU's state can be performed.

I don't think this is supposed to secure against someone with physical access.

If they have physical access and are replacing the BIOS, they could just replace the CPU at the same time with a fresh unlocked one that will lock itself to the replacement's signing key on first boot.

Can these CPUs sign with its key from software? If they can, then that system can not sign with the original key, and it is trivial to catch it.

The key in question is a public key, it's not a secret. The CPU uses it to verify the BIOS, not the other way around.

That makes a lot of sense. I was really only considering things like persistent malware that flashes the BIOS. I still think it'll get abused eventually to devalue the second hand market, but I can see the appeal security wise.

Is there any guarantee each vendor will only ever use one signing key? Or might we have problems swapping from one Dell to another Dell, for example?

I would imagine they'd have to use new ones every once in a while.

What I am most worried about is vendor's key becoming compromised (whether cracked or stolen), which means that a revocation mechanism is missing.

Even with revocation implemented, such equipment would be rendered useless (I imagine vendor would have to cover for replacements).

Discussed later in the video. But this is possible which adds another layer of complexity if one tries to track pulls.