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.