On 28/07/2024 19:46, Spalls Hurgenson wrote:
On Sun, 28 Jul 2024 09:14:55 +0100, JAB <[email protected]> wrote:
On 28/07/2024 05:39, Spalls Hurgenson wrote:
Not really a computer game issue, but it /is/ computer related so I'll
post this here anyway. ;-)
"Secure Boot", first released a decade ago, was supposed to hearken a
new age of security for users. It was supposed to create an
unbreakable foundation on which all other security methods would be
built. With SecureBoot, you could be sure that there was no way for a
rootkit to bypass the OS, because OS and BIOS would create an
unbreakable handshake. Thanks to secure hardware keys, so long as
SecureBoot was enabled, nothing could subvert the core OS functions.
But, as with a lot of security, it depends heavily on using strong
cryptographic keys through which the communications between operating
system and hardware could be safely transmitted. Unfortunately, for a
lot of devices, a secure cryptographic key is /not/ what was used.
Instead, a short (4 character) key was used instead. A key so insecure
a 386 probably could break it in seconds. Modern malware, using modern
processors, could subvert it so fast it isn't even worth timing it.
The key itself was provided to hardware manufacturers as a test key.
Despite including the word "AMI Test PK" (public key) and "DO NOT
TRUST", it was embedded into the BIOS of at /least/ 300 device models,
from manufacturers include Acer, Intel, Gigabyte, Aopen, Lenove, HP
and Dell. This means that any security that relies on SecureBoot
(which pretty much includes any Windows machine since 2012) isn't very
secure at all. Everything from HTTPS to Bitlocker is vulnerable now.
How much more vulnerable this makes the average end-user is debatable.
There are a lot of ways to get access to the average computer that
don't require subverting SecureBoot, after all (easiest is just to act
as if you're trustworthy person and tell them to download some malware
;-). But there are institutions which rely on secure hardware - banks,
for instance, or vital infrastructure- and these have just become a
lot more hackable.
If you're interested in seeing if your machine is vulnerable, open a
Powershell command prompt (using administrator access) and enter the
following command (all one line):
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes)
-match "DO NOT TRUST|DO NOT SHIP"
If it returns false, your PC isn't using the vulnerable key. If true,
then you'll want to check for a BIOS update. Assuming there is one;
most manufacturers have washed their hands of the issue, claiming that
since the affected boards are no longer being sold, it's not their
problem.
(depending on your BIOS, there may also be ways to reset the key
yourself. Figuring out how to do that is an exercise left to the
reader ;-)
Again, this isn't a reason for the average user to panic; most
day-to-day hackers aren't going to be using this method to crack into
your PCs. But if you were thinking that you needn't worry about
somebody accessing your files if you lost your laptop, well... you may
not be as protected as you think.
Read more here:
https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/
Not good but having worked in software security for a long time it
doesn't really surprise me which is why you'll supposed to have people
who understand things to make sure it's done right. I think a lot of
this comes down to this peculiar trait of software development in that
unlike most software/hardware security doesn't provide direct
functionality to the user but instead acts as a gate keeper to it. To
put it simply, I worked on a system which from a users point of view
would work perfectly. When I looked properly at the encryption function,
not good.
It isn't surprising, no. That's the sad part. Putting all your trust
in a single key -which in many cases is not revokable- is asking for
trouble. Eventually that key /will/ key leaked, and all the security
that depends on it will be broken. We've seen it happen repeatedly in
the past (the most famous being the DVD encryption key*, but there
have been numerous other instances).
This very vulnerability was warned against when SecureBoot was first introduced.
It should also be a reminder why "backdoor access for governments" to encryption methods are a /bad/ idea. Aside from the privacy issues,
this backdoor access is enabled by giving the authorities a
non-revokable encryption key that ideally only they have access to.
But inevitably that key would leak, and all of a sudden every bit of encryption is useless.
The problem is that at some point you will end up with a single root key
under which other keys sit so it's how you protect that key that's
important. So our product had two variants, a commercial one (we held
the key) and a government one (our national security authority held the
key) and for ours the signing of releasable software had a dedicated
hardware module.
Can it get leaked yes, is that easy, certainly no.
The government backdoor part, I very much agree with as all you're doing
is giving another avenue for attack (especially by other state actors)
and if it's known that it has a backdoor then the people you really want
to catch will just use something else.
That's probably why the NSA got a bit more creative a put a trapdoor in
DUAL ECDRBG without telling anyone. There was already suspicions in the community about the possibility of it and a the leaking of certain
infamous files confirmed it.
As for the banks part, I'd hope that banks still use dedicated hardware,
and have a team to basically certify that it is secure, for key security
functions.
You'd hope. But several things work against that.
In the UK it's basically mandatory that banks/credit card companies use dedicated hardware modules for the important cryptographic functions
that secure someone's account. The idea being that even employees can't
access the information required that gives you access to an account.
That doesn't mean information can't be leaked but instead the really
important stuff is hard to get at.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)