[HN Gopher] Secure Boot is broken on 200 models from 5 big devic...
___________________________________________________________________
Secure Boot is broken on 200 models from 5 big device makers
Author : verifex
Score : 108 points
Date : 2024-07-25 18:21 UTC (4 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| rebolek wrote:
| It's a bit of surprise that most of the things work most of the
| time, given on how shaky basis are they build.
| sadhorse wrote:
| If you dig deep enough all our land is on a floating basis.
| jmclnx wrote:
| >In 2012, an industry-wide coalition of hardware and software
| makers adopted Secure Boot to protect against a long-looming
| security threat
|
| This joke never gets stale, wait it is not a joke ?
|
| I still believe the only reason for this to exist is to
| eventually turn general computing devices into a locked down Cell
| Phone Spying Device.
| hex4def6 wrote:
| This has been my theory since Windows 11 required TPM. It's not
| to protect the consumer, it's to protect the IP-holder.
|
| The PC is the lone outlier in the locked-down, walled-garden
| world of consoles, cell phones, tablets, smart TVs, EVs, etc. I
| think there's a concerted effort to change that.
| stonogo wrote:
| Indeed, I share this outlook, as do others:
| https://boingboing.net/2012/01/10/lockdown.html
| kps wrote:
| Better late than never. "The actual user of the PC --
| someone who can do anything they want -- is the enemy."
| (Intel, 1999)1
|
| 1 https://www.zdnet.com/article/the-biggest-security-
| threat-yo...
| jandrese wrote:
| Absolutely. Look at all of the changes to the media stack
| Microsoft made for Vista and none of them are to directly
| benefit the person who bought the OS license. If you have
| ever wondered how a 486 could play MP3s and still run X but
| your modern laptop gets hot and spins the fan when you are
| playing those same MP3s it is because the media companies
| demanded it.
| tedunangst wrote:
| If they're literally the same MP3s, it's because modern
| software sucks. You can still play them with mpg123 with an
| immeasurably low cpu load.
| leeter wrote:
| The pedant in me wants to point out that most 486s couldn't
| play MP3s (they just don't have the horsepower, an AM-586
| or a DX4 maybe) and you'd need a Pentium. /pedant
|
| OK now to my real point. Vista is actually a really good
| call out of MS being inconsistent about this. The major
| changes in Vista (Moving graphics drivers largely out of
| the kernel, simplifying what sound drivers could do) were
| all predicated on the fact that hardware vendors are
| notoriously bad at software. This cannot be understated
| just how bad they are, NTKernel was originally intended
| such that vendors would make their own HAL.. one tried and
| it was so bad MS just NOPE.jpg'd that and did it
| themselves. So for MS to double down on a system that
| _relies on the same known to be horrible at software
| vendors_ is just hilarious to me.
| Scoundreller wrote:
| A 486 DX4-100 could play mp3s in stereo (or in mono at
| 66mhz), but do absolutely nothing else at the same time.
| I used a DOS mp3 player (mpxplay) and it could be done.
|
| Docs suggest stereo is possible at DX2-80mhz if you
| disabled screen output and heavy mp3 file pre-buffering.
|
| Top level comment here claims the issue was the on-screen
| animations and they were able to build a highly optimized
| mp3 player on a 286 (dunno through what speaker):
| https://m.youtube.com/watch?v=b0zZpzxHSeM
|
| Even on a later pentium, I had to minimize throttle
| priority on my web browser because smooth scrolling
| requires a ton of juice. Still does to this day looking
| at power consumption on an iPhone.
| leeter wrote:
| > Even on a later pentium
|
| MMX helped a lot here, I remember my Pentium MMX 233 had
| no trouble playing games and playing music. To give you
| an idea of how crapy that machine was otherwise... it was
| a Packard Bell with an onboard ATI chip that barely
| qualified for 3D acceleration. The Pentium 166 (non-MMX)
| we had would chug on things that the MMX just didn't care
| about.
|
| > I had to minimize throttle priority on my web browser
| because smooth scrolling requires a ton of juice. Still
| does to this day looking at power consumption on an
| iPhone.
|
| This still to this day amuses me. Metal and DX12 both
| have calls designed to support this natively on the GPU
| by allowing the application to shift the rendered area of
| a very specific box (without rerendering the entire
| screen) and then render behind in the blank. As far as I
| know only Safari on iOS does this even close to properly
| and even then it has other iOS Safari related quirks
| around that that Apple refuses to fix.
| out-of-ideas wrote:
| fear and planned obsolescence; "all these old things are
| bad... never mind it's only a day old. throw it away already,
| and buy the new one. no discounts!"
| tedunangst wrote:
| It's only a F12, tab, enter, down, tab, enter away to disable
| if you really don't like it that much.
| jmclnx wrote:
| Yes right now, what about 5 to 10 years from now ?
|
| Or maybe for that option in the future, the device will cost
| thousands of USD more.
|
| Or you need a special professional license to get a non-
| locked down device, and the license will cost more than a
| house in a rich suburb.
| tedunangst wrote:
| People have been asking "what about five years from now"
| for twenty years, so extrapolating from the current rate of
| change, I'd say things will be fine.
| josephcsible wrote:
| You can disable Secure Boot on x86 PCs, but nowhere else.
| tedunangst wrote:
| So how do people install openbsd on the thinkpad x13s?
| jauntywundrkind wrote:
| It feels utterly absurd that devices typically have certain keys
| are baked in, cannot be removed. I believe there are still
| Microsoft keys on nearly every device?
|
| It's unconscionable to tell users this is here to keep you safe,
| but that you have no control over it & if something goes wrong
| well then too bad, at best we might provide an update.
|
| (Also that governments can probably force these root-of-trust
| companies to sign payloads to circumvent security is also pretty
| icky to me.)
| sillywalk wrote:
| As I understand it, that's both the whole point of, and
| limitation to, the hardware root of trust - it can't be changed
| even with a firmware update.
|
| Of course, if the key used to sign the firmware is compromised,
| the root of trust is still technically what it is supposed to
| do - verifying signatures, it's just that that it becomes
| irrelevant in terms of security / integrity.
| hollerith wrote:
| >As I understand it, that's both the whole point of, and
| limitation to, the hardware root of trust - it can't be
| changed even with a firmware update.
|
| The OP states that the vendors could have revoked the
| compromised platform key with a firmware update. They just
| didn't bother.
| jauntywundrkind wrote:
| They'd also need to know every user has upgraded the boot
| loader such that the system doesn't depend on those
| compromised keys!
|
| That does make it quite difficult to pull off any kind of
| key rotation. I'm not sure, but I think (well known Secure
| Boot tool) sbctl is saying that you can sign a bootloader
| with multiple keys, which would permit creating a
| bootloader that would work with the compromised & the new
| root-of-trust, which at least opens some window of
| possibility. https://github.com/Foxboron/sbctl/blob/master/
| docs/sbctl.8.t...
| commercialnix wrote:
| It's like buying a house with locks that can not be changed.
| drhagen wrote:
| > To this day, key players in security--among them Microsoft and
| the US National Security Agency--regard Secure Boot as an
| important, if not essential, foundation of trust in securing
| devices in some of the most critical environments, including in
| industrial control and enterprise networks.
|
| Am I correct that Secure Boot purely exists to prevent this
| attack vector: malware gets root on the OS, hardware allows
| updating firmware via OS now owned by malware, but Secure Boot
| means you have to wipe only the hard drive instead of the
| firmware to eliminate the malware.
|
| It seems like it would be a lot simpler and more reliable to add
| a button to motherboards that resets the firmware to the factory
| version (on memory that can't be written by a malicious OS).
| Terr_ wrote:
| I'm having strange nostalgic flashbacks the '90s where I kept
| wondering why nobody offered a hard drive with a physical read-
| only toggle button. (Mounted to the front of the 5.25 inch bay
| in a tower chassis, as was the style of the time.)
|
| Obviously you need some read+write storage elsewhere on the
| same computer, but you could reliably freeze large chunks of
| stuff in a way that would be impervious to viruses or hackers.
| drhagen wrote:
| I remember USB drives in the '00s that had a read-only
| toggle. They were useful for rescuing machines that had a
| virus.
|
| Edit: A quick search reveals that, of course, you can still
| buy them today. I have not felt a need for one in ages.
| Terr_ wrote:
| Hmmm, I would absolutely buy one of those if it also had a
| hardened case and a firm connection point for my real-world
| keychain. The use-case is a "my house burned down what
| next" backup, password-manager stuff and other details I
| might need before/without accessing any cloud-backup
| services.
|
| I may need to read some of its files on a not-very trusted
| device, and I don't want to risk that device also
| tampering/trojan'ing other files, like backup copies of the
| software needed to decrypt the data files.
|
| A simpler scenario might be a USB stick that I use for
| carrying files to be printed at the local library.
| Hizonner wrote:
| I strongly suspect that most or all of the modern
| "hardware" write-protect switches are actually just
| suggestions to the drive firmware. Which may very well
| itself be modifiable.
| Gormo wrote:
| I can't imagine how it would be possible to do it any
| other way for a flash storage device.
|
| A mechanical hard drive could at least theoretically have
| a physical lock attached to the drive head which prevents
| it from approaching the platters if it is engaged.
| Hizonner wrote:
| Erm. The read head and the write head in a magnetic drive
| are the _same head_. You can 't keep the head away from
| the surface if you want to read the disk. But you _can_
| disable power to the driver that puts write current into
| the head.
|
| ... and you could absolutely build similar functionality
| into a flash chip. But most likely you can 't actually
| buy such chips, at least not with any real capacity.
| mypalmike wrote:
| There are multi-actuator hard drives out there. I don't
| know if any of them separate read heads from write heads,
| but it would certainly seem possible for such a drive to
| exist.
| schmidtleonard wrote:
| Writing flash takes (relatively) high voltage and the
| voltage boosting circuitry could be routed through a
| switch. It generally isn't, and the voltage converter is
| often an on-chip charge pump so this wouldn't be an easy
| retrofit, but the current state of affairs is due
| entirely to lack of interest rather than lack of
| possibility.
| upwardbound wrote:
| Do those charge pumps use external capacitors? If so, you
| could disconnect/float those capacitors, or if that would
| damage or glitch the chip, you could replace the real
| capacitors with some circuit like a voltage regulator +
| diode that would be designed to provide the charge pump
| output rail with a voltage that's high enough not to
| glitch the chip but low enough to be unsuccessful in
| writing to the flash. Would one of those ideas work, and
| allow the retrofit you envision to be designed with
| existing flash memory silicon + a few additional
| components?
| Scoundreller wrote:
| I believe they're on-die capacitors for the charge pumps
| these days. The external ones are just for smoothening.
|
| Probably a method to retrofit write/erase protection
| would be to just do power analysis and cap the current
| the flash chip can receive. Or shut it down if that works
| for you.
|
| Not sure if they're intelligent enough to run their
| charge pumps slower under compromised electrical
| conditions. Or if they'll go haywire if they can't do
| idle-time wear levelling/block erases.
| Scoundreller wrote:
| Isn't it really only the erase that requires high
| voltage? So with a blank flash chip, without higher
| voltages, you could write to it to your heart's content
| until you need to free up deleted content?
|
| Edit: I think I'm wrong here and high voltage is needed
| for both.
| Scoundreller wrote:
| Flash storage requires high voltage to do an erase (which
| needs to precede a write operation).
|
| Back in the EPROM days, that was easy, just don't supply
| 25V or whatever.
|
| Modern flash still needs those high voltages but
| generates it on-chip via charge pumps. If your read-only
| switch physically disconnected the charge pumps, you
| would have read-only flash.
| edwcross wrote:
| For years, Dell laptops came with a USB key containing
| drivers, a sort of "rescue boot disk". I once tried using
| them as a normal pen drive, but then realized they were
| read-only.
|
| If there is a way to make them writable via software,
| that would be very interesting (and dangerous).
| commercialnix wrote:
| This is the way a smart person looks at write-protect
| switches.
| GuB-42 wrote:
| I have one of these as a boot disk (Medicat) for this exact
| reason.
|
| Also because some of the software included in Medicat is
| flagged by some anti-virus software and I don't want them
| removed.
| judge2020 wrote:
| That sounds correct, but even the savviest of users might not
| be aware they have malware installed when they decide to re-
| install windows. If cleaning malware requires pressing a button
| on the MOBO then I can imagine only a single-digit percentage
| of users will actually click it.
| Dylan16807 wrote:
| If they're not worried about malware, and there is some, then
| they'd probably get reinfected by their data anyway.
| bitwize wrote:
| Secure Boot is the first component in a verified boot chain
| from initial power-on to application level code. Signed,
| verified firmware boots signed, verified kernel with strict
| authenticity and integrity guarantees. The goal is, presumably,
| to attest to the authenticity and integrity of everything the
| system runs, but when it comes to kernel modules and device
| drivers, userland OS components, and applications, those are
| the kernel's responsibility. But Secure Boot is an essential
| link in this chain.
| acdha wrote:
| Also things around physical access: if you steal my laptop, FDE
| prevents you from getting my data immediately but if you
| install malware which takes over the boot process, you get that
| data as soon as I type in my password.
|
| If the process changes so the hardware only loads signed
| firmware, which only loads a signed boot loader, which only
| loads a signed kernel, etc. that avenue of attack is closed. It
| also makes it possible to trust a used computer.
|
| The problem is that other than Apple nobody has really been
| committed to doing it well - it's begrudging lowest-bidder
| compliance and clearly not something many vendors are taking
| pride in.
| out-of-ideas wrote:
| do folks in the business really simply steal a laptop and try
| to pull all data? or do they steal the laptop and wipe it and
| flip it... if they wanted your data wouldnt they steal you,
| the human, too ?
|
| the signing method only offers buying more time before the
| innevitable data is "breached" by a theat actor - its the
| same buying-time for any and all encryption. the system can
| get too complex, and the underlying problems of humans will
| always exist (and amplified by more points of failure)..
| (accidents, data breaches, exploits, ect). the system needs
| to be immutable, but also mutable at the same time (for
| updates, ect) - and thats not exactly something easy to
| accomplish.
|
| and with apple.. they try yes, but it is forever a walled
| garden. we've already seen their secure enclave bloatloader
| shinanigans get exploited on phones- and it was not fun for
| those people where their phones were compromised. apple
| suffer from us humans, too (we will never be perfect, nor
| will our software)
| acdha wrote:
| > do folks in the business really simply steal a laptop and
| try to pull all data? or do they steal the laptop and wipe
| it and flip it... if they wanted your data wouldnt they
| steal you, the human, too ?
|
| Governments definitely worry about it, and I'd be shocked
| if e.g. banks didn't also put it into requirements. Access
| can be temporary, too: imagine if you get 15 minute alone
| in someone's office or they have a kiosk in the lobby, etc.
| - not enough time to open the case up but plenty to toss a
| USB drive in and reboot. Repeat for lost devices or
| scenarios like the KnowBe4 attack disclosed yesterday where
| some dude might not be able to explain cracking the case
| open.
|
| > the signing method only offers buying more time before
| the innevitable data is "breached" by a theat actor - its
| the same buying-time for any and all encryption.
|
| You have to think about cost, too. It appears to be safe to
| buy a used Mac because Apple employs competent
| cryptographic engineers and very few targets are worth
| involving a lab with truly serious hardware. This could be
| the case on the PC side too, but it's undercut by vendors
| skimping on execution and until Secure Boot is pervasive
| and robust, nobody can easily tell whether hardware they've
| lost control of can be trusted. People have been getting
| malware on used computers for years and a trusted boot
| process makes it easier both to tell if that's happened and
| to be confident that you've fully wiped a system.
| out-of-ideas wrote:
| i only chose those questions as to pick on the concept of
| "stealing a laptop" - its more the hypothecial use case
| where majority of users, given the "my laptop got stolen"
| will never see their system again. folks in the business
| of stealing a laptop will resell it if they can - a
| laptop in a random car in SF.. sounds real profitiable to
| try to decrypt some aes 2tb data for a cat pic); secure
| boot has not guarnteed a password to access the bios in
| my experiences - and not all bios are created equal. just
| makes it harder for data on the drive to be accessed (and
| certainly prevents my neighbor from putting a rootkit in
| my bootloader)
|
| of course govts worry about data loss - and implanted
| root-kits; yes we want to prevent those but my point is
| there are many steps along the path where the complexity
| can get out hand, and every added step to a system is
| another step of potential failure - and anything we
| invent will be vurnerable to human mistakes/errors/ect
| (like we've literally seen). the problem is the firmware
| is mutable, the os is mutable, ect ect. the signed stages
| are a bandaide (not that im smart enough to solve the
| problem) and it's a matter of time before something like
| a cert leak happens (again). its funny too because we
| worry about 1000's of folks computers having a rootkit
| (that needs physical access when things like my-pc-looks-
| tampered-with are not considered), and then we let
| location data be gathered by literally every company,
| hmmm
|
| the scenario where 15 min alone in somebodys office,
| (this made me laugh actually - theres a countless amount
| of what-ifs): a company with any kind of compliance
| should never let an untrusted person be alone (especially
| with access to a computer); a smaller company, surly we'd
| assume would be less of a target, but not a guarntee -
| but thats also why all companies should not leave their
| vaults with raw cash open for any to access.
|
| as far as used systems going; folks will always fall
| victim for that which they do not know. for a newly owned
| computer a user should be fresh installing the firmware
| and OS. but convience has folks trained to plug-and-play
| with 0 downtime, 0 setup, 0 knowledge of options. apple,
| of course, that cannot be done on the same level as my
| non-apple system is done. and from what i remember, apple
| folks need to have proof of reciept for a used-sale, and
| even then can still get trolled on a used-sale with the
| find-my-mac lockout - maybe its improved nowaday; i'll
| simply pass and rather buy new (not that im supporting
| apple)
| A4ET8a8uTh0 wrote:
| << if they wanted your data wouldnt they steal you, the
| human, too ?
|
| As chilling as it may be to explore this line of thought, I
| think there are real, pragmatic considerations that make
| 'stealing' humans along with laptops less than ideal.
| Laptops get damaged, lost and so on all the time. Missing
| laptop raises some, but minimal suspicion and attention.
| Now, with a human missing, whoever did the deed, will
| likely have a difficult time moving around assuming LEOs in
| the area are competent.
| sillywalk wrote:
| > other than Apple nobody has really been committed to doing
| it well
|
| I believe Chromebooks also do this fairly well.
| acdha wrote:
| Good point. I was thinking "PC" as opposed to phones but
| those totally count.
| from-nibly wrote:
| Chromebooks aren't phones.
| tedunangst wrote:
| How do you determine when to push the button?
| jtbayly wrote:
| Once a day ought to do...
| Dylan16807 wrote:
| Any time you're reinstalling the OS and suspect the old OS
| had malware.
|
| Or if you want to make it simpler, any time you're
| reinstalling the OS.
| bluescrn wrote:
| Instead, write-protect the firmware by default, and require
| the user to press a physical button on the back of the PC to
| write-enable it (for a limited duration/until the next
| reboot)
| tripflag wrote:
| The case you're outlining (an uefi rootkit) is pretty much the
| worst case; assuming you get infected by some malware which
| decides to install a malicious firmware (BIOS update), then
| pretty much nothing is getting in the way of that.
|
| What secureboot is designed to prevent is malicious changes to
| the OS bootloader (a conventional rootkit), which is usually
| shimx64.efi or grubx64.efi on linux/dualboot machines, or
| bootmgfw.efi on windows. Secureboot checks the signature of
| .efi files before they're allowed to run during boot, ensuring
| they were signed by one of the trusted keys. And unless you've
| made changes to your secureboot config, that means microsoft
| and/or the hardware vendor.
| gizmo686 wrote:
| It is possible to use Secure Boot as part of a fully verified
| bootchain. The firmware verified the bootloader. The bootloader
| verifies the kernel (and kernel arguments, and ramdisk...), the
| kernel verified all executables. Userspace programs verify
| critical data files.
|
| There are systems out there that do this, and having something
| like Secure Boot is essential to their design (as is measured
| boot, which is the main mechanism TPMs leverage).
|
| However, this solution is utterly unworkable for the personal
| computer market. Instead, we have a bunch of general purpose
| kernels signed to run on any computer, but which are willing to
| run any userspace you through at them.
| jokoon wrote:
| Isn't that a vulnerability that still requires physical access to
| hardware?
|
| Or is that just a protection against rootkits?
|
| I still fail to understand what secure boot is protecting
| against: if a machine is compromised remotely, does secure boot
| prevents installing a rootkit that's invisible from virus
| scanners?
| bitwize wrote:
| Secure Boot protects against booting a kernel image that's been
| tampered with. If the running kernel is vulnerable to root-
| level exploits, it can't help you, but it can prevent a
| malicious attacker from switching a trusted kernel for a
| malicious, modified copy.
| asveikau wrote:
| > it can prevent ... switching a trusted kernel for a
| malicious, modified copy.
|
| Or a free OS.
| Terr_ wrote:
| It sounds like the biggest contributory problems here are:
|
| 1. Allowing unattended/automatic BIOS updates from a running OS
| at all
|
| 2. Being so paranoid about attacks by a spy with physical access
| to the computer that the keys cannot be replaced or revoked
|
| I'm not a security researcher, but to just shoot the breeze a
| bit, imagine:
|
| 1. The OS can only _enqueue_ data for a proposed BIOS update,
| actually applying it requires probable-human intervention. For
| example, reboot into the currently-trusted BIOS, and wait for the
| user to type some random text shown on the screen to confirm.
| That loop prevents auto-typing by a malicious USB stick
| pretending to be a keyboard, etc.
|
| 2. Allow physical access to change crypto keys etc, but instead
| focus on making it easy to _audit and detect_ when it has
| happened. For example, if you are worried Russian agents will
| intercept a laptop being repaired and deep-rootkit it, press a
| motherboard button and record a values from a little LED display,
| values that are guaranteed to change if someone alters the key
| set and /or puts on a new signed BIOS. If you're worried, they'll
| simply replace the chipwork itself, then you'd need a way to
| issue a challenge and see a signed verifiable response.
| Hizonner wrote:
| Platform keys _can_ be replaced given physical access to the
| computer. In fact they can generally be replaced by regular
| UEFI updates.
|
| The problem here is in trusting, nay expecting, your average
| motherboard maker to either know anything about key management
| or give a shit about key management.
| commercialnix wrote:
| Not any less reasonable than expecting a mechanic to be
| competent and knowledgeable with brakes.
| Hizonner wrote:
| ... except that in my experience most mechanics _are_
| competent with brakes, and most motherboard makers _are
| not_ competent with cryptography, or indeed with anything
| having to do with software.
|
| The auto repair industry has certain standards, and the
| computer industry... doesn't. In fact, the computer
| industry does everything it can to insulate itself from any
| kind of responsibility.
| commercialnix wrote:
| > most mechanics are competent with brakes
|
| Because if they aren't and something happens the mechanic
| is the one who ends up rotting in a cell. Put the same
| penalties in place for ODMs and OEMs, mandating that
| machine owners absolutely always can change the locks to
| their own property, and mysteriously every single problem
| we have ever seen with secure boot is no longer some
| obscure inevitable unavoidable technology issue.
| nucleardog wrote:
| > Allow physical access to change crypto keys etc, but instead
| focus on making it easy to audit and detect when it has
| happened.
|
| Shooting the breeze as well...
|
| Have some (non-modifiable, non-updatable) portion of the
| firmware that, on boot, calculates a checksum or hash of the
| important bits at the beginning of the chain of trust (efi
| vars, bios).
|
| Then have it generate some sort of visualization of the hash
| (thinking something like gravatar/robohash) and draw it in the
| corner of the screen. Would need some way to prevent anything
| else from drawing that section of the screen until you're past
| that stage of boot.
|
| That way every time you boot your computer you're gonna see,
| say, a smiling blue kitten with a red bow on its head. Until
| someone changes your platform key / key exchanges or installs a
| modified bios, and now suddenly you turn the computer on and
| it's a pink kitten with gray polka dots.
|
| That way you don't have to actively _try_ and check the
| validity. It'd be very obvious and noticeable when something
| was different.
| zzo38computer wrote:
| This fails to consider the possibility that the display
| hardware will be tampered with. It also does not consider if
| a copy of the picture is made and is then displayed by a
| separate program that pretends that the booting is slower
| than it actually is.
|
| > Would need some way to prevent anything else from drawing
| that section of the screen until you're past that stage of
| boot.
|
| It might need to prevent drawing anything on the entire
| screen. Otherwise a program might be able to modify the
| resolution, refresh rate, etc, to try to hide the picture or
| to display a different one.
| zzo38computer wrote:
| I think that this is part of the way to do it, but not all of
| it. I might consider:
|
| 0. All of the BIOS code and other hardware code should be FOSS.
| This should be printed in the manual as well. A simple assembly
| language might be preferable, and if the hex codes are also
| printed next to it, they can also be entered manually if
| necessary.
|
| 1. The operating system cannot update the BIOS at all. To do so
| requires to set a physical switch inside of the computer which
| disables the write protection of the BIOS memory, and also
| disallows the operating system from automatically starting.
|
| 2. Require keyboards, etc to be connected to dedicated ports,
| not to arbitrary USB ports. (This is possible with USB but is a
| bit difficult; PS/2 would be better.)
|
| 3. You can program it manually (whether or not the BIOS memory
| is write protected) without starting the operating system (this
| makes the computer useful even if no operating system is
| installed); perhaps with an implementation of Forth. When BIOS
| memory is write enabled, then such a program may be used to
| copy data from the hard drive to the BIOS memory.
|
| 4. Like you mention, it should make it easy to audit and detect
| when keys have been changed. An included display might normally
| display other stuff (e.g. boot state, temperature measurement,
| etc), but a switch can be used to display a cryptographic hash.
| If you always fill all of the memory (even if part of it would
| not otherwise be used) then it can be difficult to tamper with
| in the case of an unknown vulnerability.
|
| 5. I had seen suggestion to add glitter and take a picture of
| it, to detect physical tampering. This can help in order to
| avoid alterations of the verifications themself. If it is
| desirable, you can have multiple compartments which can be
| sealed separately, each one with the glitter. If some of these
| compartments are internal, a transparent case around some of
| them might help in some ways (as well as to detect other
| problems with the computer that are not related to security).
|
| However, even the above stuff will need to be done correctly to
| avoid some problems, since you will have to consider what is
| being tampered with. (You might also consider the use of power
| analysis to detect the addition of extra hardware, and the
| external power can then be isolated (and a surge protector
| added) to mitigate others attacking your system with power
| analysis and to sometimes mitigate problems with the power
| causing the computer to malfunction.)
| jandrese wrote:
| I know never to trust software written by hardware folks, but
| seriously, how do you ship a key where the CN is literally "DO
| NOT TRUST -- AMI Test PK" as the root security. That is outright
| malicious incompetence.
| londons_explore wrote:
| Because nobody ever looked at the text of the certificate. It
| was probably a binary file checked into the source control
| system and, since it seemed to work, nobody ever looked at it.
|
| Probably came as part of the dev kit from AMI.
| kevin_thibedeau wrote:
| The only winning move is not to play. AMI should never have
| distributed test certs to begin with. Give your customers
| instructions on how to generate self-signed certificates
| (assuming they are accepted) or setup a dev CA that will sign
| test certificates. Then the damage from a key leak is limited
| to one vendor.
| tedunangst wrote:
| "It's EOL so no fix" is pretty shitty. It was defective for its
| entire unsupported life as well.
| nightowl_games wrote:
| Seems apparent we need a Professional Engineering Certification
| process and our own disciplinary board similar to other
| engineering disciplines.
|
| High time.
| Hizonner wrote:
| You could probably get away with just forbidding software
| license agreements that disclaim liability for any and every
| kind of negligent stupidity.
| manofmanysmiles wrote:
| Unless I'm missing something, Secure Boot as designed is
| fundamentally broken.
|
| Its root of trust is the BIOS/Firmware, which can be updated from
| a running OS. There is no hardware root of trust.
|
| How Secure Boot Works
|
| Secure Boot ensures that a device boots using only software
| trusted by the Original Equipment Manufacturer (OEM). Here's a
| high-level overview:
|
| 1. _Power On and Initialization_ : The CPU initializes and runs
| the BIOS/UEFI firmware, which prepares the system for booting.
|
| 2. _Platform Key (PK) Verification_ : The firmware verifies the
| Platform Key (PK), which is used to validate Key Exchange Keys
| (KEKs).
|
| 3. _Key Exchange Keys (KEK) Verification_ : The KEKs validate the
| allowed (whitelist) and disallowed (blacklist) signature
| databases.
|
| 4. _Signature Database Verification_ : The firmware checks the
| allowed (db) and disallowed (dbx) signature databases for trusted
| software signatures.
|
| 5. _Bootloader Verification_ : The firmware verifies the
| bootloader's signature against the db. If trusted, the process
| continues.
|
| 6. _Kernel and Driver Verification_ : The bootloader verifies the
| OS kernel and critical drivers' signatures.
|
| 7. _Operating System Boot_ : Once all components are verified,
| the OS loads.
|
| _Apple Secure Boot Process_
|
| Apple adds hardware-based security with the Secure Enclave:
|
| 1. _Secure Enclave Initialization_ : Separate initialization
| handles cryptographic operations securely.
|
| 2. _Root of Trust Establishment_ : Starts with Apple's immutable
| hardware Root CA.
|
| 3. _Immutable Boot ROM Verification_ : The boot ROM verifies the
| Low-Level Bootloader (LLB).
|
| 4. _LLB Verification_ : The LLB verifies iBoot, Apple's
| bootloader.
|
| 5. _iBoot Verification_ : iBoot verifies the kernel and its
| extensions. The Secure Enclave ensures cryptographic operations
| remain protected even if the main processor is compromised.
|
| For more details, check out:
|
| -
| <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8...>
|
| -
| <https://www.apple.com/business/docs/site/Security_Overview.p...>
|
| I would really love to have a hardware root of trust on a Linux
| or other open system, with a hardware security module of sorts
| that is programmable, so I decide what the root keys are, and is
| able to measure the firmware boot process, establishing a proper
| audit trail or chain of trust.
|
| I can't remember the HN formatting rules, so expect an edit
| shortly to make this look better.
|
| Edit: I did a little more poking. It's not quite as bad as I
| thought, because at least in theory, the BIOS will verify a
| digital signature of a BIOS update before flashing it.
| StillBored wrote:
| The firmware updates from a protected capsule so it can't be
| updated without a signature verification effectively closing
| the loop. Its possible to add a 3rd party root of trust
| (TPM/etc) to this, its just vendor defined whether a platform
| uses an additional component to validate the PK/firmware/etc
| earlier in the process.
| commercialnix wrote:
| > Secure Boot ensures that a device boots using only software
| trusted by the Original Equipment Manufacturer (OEM)
|
| "We sold you this house with a front door designed where our
| key will always let us in". Why do we put up with this shit?
| _trampeltier wrote:
| A bit oftopic but when last week came out, Cellebrite could open
| the Trump shooters phone, there was a PDF, they can brute force
| all android phones since from Android 7 or newer. What changed
| there? Why can they brute force all newer versions?
|
| https://www.documentcloud.org/documents/24833831-cellebrite-...
| Hizonner wrote:
| Android 7 is when Google switched from dead simple full-"disk"
| encryption to per-file hackery with complicated key management.
| Basically the whole data encryption scheme changed.
| snailmailman wrote:
| I've had so many issues with secure boot on my machines causing
| issues that if I ever saw a secure boot error message I would
| _never_ think "oh I must have a rootkit"
|
| Instead I would assume, in order
|
| - my config broke it
|
| - OS update broke it
|
| - the bios doesn't properly handle any case that isn't
| "preinstalled OEM windows"
|
| I had a laptop that as far as I could tell, could _only_ boot
| into windows' default bootmgr.efi. I could turn off secure boot,
| and tamper with that efi to boot Linux, but it _refused_ to
| acknowledge other boot loaders from within the bios. It wouldn't
| surprise me _in the slightest_ if secure boot isn't properly
| handled. I've had too many issues with cheap computers having
| janky bioses.
| rurban wrote:
| Previously in 2023 Intel lost it's private UEFI key on the MSI
| hack. https://news.ycombinator.com/item?id=35843566
|
| This time it's AMI. Cannot get bigger.
| Hizonner wrote:
| I'm not sure it's reasonable to just treat it as an AMI
| problem, given that AMI literally _named_ the key "DO NOT
| TRUST - AMI Test PK". Obviously AMI was stupid to trust the
| OEMs to, you know, have a clue what they were doing and replace
| a wired-in test key in their production builds... but it's also
| true that, even if AMI should have known that the OEMs are
| idiots, the OEMs are still idiots.
|
| I suppose you could also break it down and say that the
| particular idiot who hardwired a test key in an SDK or whatever
| should have known that both the rest of AMI _and_ everybody at
| the OEMs would be idiots, and found a way to make it relatively
| hard for them to stay with that key. But however far you dig,
| it 's idiots all the way down.
| StillBored wrote:
| This big mistake though was back when all this was being enabled
| on PC's, the linux vendors out of fear that the rest of the
| industry would lock them out, standardized on shim and the MS
| certificates in the firmware. Thus requiring MS to sign the first
| stage of every linux install/boot rather than both doing that, as
| well as defaulting to an environment where the distros would boot
| in UEFI 'setup mode' enroll their own cert/key chains during the
| first provision/boot, and then permanently switch to user mode.
| Had they done that, this entire article would have been just
| about meaningless as all those test keys would have been replaced
| the moment the machine was installed.
|
| So today a decade+ later there still isn't a standard way to
| automatically enroll a linux distribution's keys during initial
| install in any of the distributions (AFAIK).
| dathinab wrote:
| I just wanted to check if I'm affected.
|
| ...
|
| then remembered I'm using custom platform keys
|
| tbh. I don't understand why secure boot is build around global
| root of trusts instead of ad-hoc per device trust (i.e. like
| custom platform keys but with better support), at most supported
| by some global PKI to make bootstraping on initial setup easier
|
| this would not eliminate but massively reduce how much "private
| key" got leaked vulnerabilities can affect secure boot chains
| (also move most complexity from efi into a user changeable chain
| loaders, including e.g. net boot, etc.)
|
| PS:
|
| To be clear " I don't understand why" is rhetorical, I do
| understand why and find it a terrible bad idea.
___________________________________________________________________
(page generated 2024-07-25 23:10 UTC)