If you roll your own keys (preferably in a local HSM and use PKCS#11 for signing, with some kind of local auth) then it’s actually quite a good security feature. Obviously not for Windows, but trivial on Linux. It’s very easy to set up a hook for apt (or whatever package manager) to re-sign your kernel/init/modules on updates (requiring whatever your auth source is, password probably good enough for most people) and then as long as you’re booted with secure boot enabled, it’s a lot harder for someone with root to escalate further. Which you can then go down the rabbit hole of hardening the system to prevent becoming root, etc.
Pretty useless if you use Microsoft’s keys. But with your own, depending on the attack surfaces you care about, can be pretty helpful
That should be up to my phone then. Unlockable phones display a mandatory warning screen on power on if they've been unlocked - isn't that sufficient? Why should Facebook also be allowed to care?
We know users blow past any warnings, even if it is in big, bold, red letters stating that they were hacked and should not continue.
Plus why should I be inconvenienced by not being able to watch my TikToks if my phone was hacked? On the other hand, I expect my important apps to apply a higher level of validation before they accept random inputs.
That's why my car doesn't run on unapproved fuels. No way to know the liquid in the fuel tank isn't concentrated sulfuric acid, which would severely corrode the engine, so better not to let it run without a vehicle-manufacturer-authorised fuel. It can't just be a warning because I might skip the warning and then corrode my engine if the fuel tank is full of concentrated sulfuric acid - so it has to be a hard lockout. The vehicle manufacturer charges a 300% mark-up on the fuel, but such is the price for safety!
the reality is that evil maid attacks, and more broadly (and realistically) physical access attacks are exceedingly rare. The vast majority of stolen credentials are phished or some other social-engineering trick, not James Bond sneaking in with his badusb.
It was inconceivable to crypto bro’s that kidnapping people for their keys was a possibility…
If banks make it a requirement you use certain pre approved devices, you better believe badusb/physical theft will take place more commonly and it will definitely not be someone as polite as James.
Then you just entered your unlock code / password into the compromised device which immediately transmits it to the attacker who has your real device.
On top of that, secure boot doesn't require remote attestation. If your device doesn't like the new configuration then it doesn't release the key. The site has nothing to do with that except insofar as you need the key to sign into it. Your device manufacturer's key doesn't have to sign anything, all your device has to do is not give up your key unless the device is in the configuration you specified. And if it will do that then it would also sign an attestation to the same effect, so remote attestation still provides you with no advantage whatsoever.
Maybe I'm misreading, but that was my point - an app roots your phone but doesn't reboot yet, resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
> resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
There are two types of compromise for the local device. The first is that they get root on the application processor (but not the secure processor), the second is that they get root on the secure processor.
If you have the first type of compromise then you don't need remote attestation because you can have the secure processor do any verification the remote server would have done and not release keys/signatures that allow you to sign into the service when the device isn't in the expected state. The secure processor won't accept a different device state for use of the existing key unless you compromise it.
If you have the second type of compromise then remote attestation can't save you because the attacker can forge attestations.
In neither case does it do you any good. The only thing it does in the first case is lock you out of using a device or OS you want to use because the service is demanding a signature from a specific OEM rather than one from the key you yourself generated and registered with the service and can keep in any kind of device you choose.
You can’t change secure boot settings from the OS, even with root. You need the signing keys or to be in BIOS (if it’s configured correctly), which shouldn’t be on the device.
Now if the right kernel exploit and a secure boot exploit are chained together then it’s possible. But at the point, you’re gonna be hosed no matter what you do.
> In a 2009 blog post, security analyst Joanna Rutkowska coined the term "Evil Maid Attack" due to hotel rooms being a common place where devices are left unattended.[1][2] Rutkowska then published a practical method for bypassing TrueCrypt disk encryption on victim devices, requiring merely an external USB flash drive.[3]
I hope the situation with disk encryption has improved. Otherwise, what is even the point of it? Any local malware you get is going to get an unencrypted view of the disk anyway (just like your legitimate programs) and there is already something seriously wrong if someone manages a remote login on a random home desktop that wasn't specifically configured for it.
never, ever in my life I've seen SecureBoot doing anything ever remotely advantageous for me.
If you roll your own keys (preferably in a local HSM and use PKCS#11 for signing, with some kind of local auth) then it’s actually quite a good security feature. Obviously not for Windows, but trivial on Linux. It’s very easy to set up a hook for apt (or whatever package manager) to re-sign your kernel/init/modules on updates (requiring whatever your auth source is, password probably good enough for most people) and then as long as you’re booted with secure boot enabled, it’s a lot harder for someone with root to escalate further. Which you can then go down the rabbit hole of hardening the system to prevent becoming root, etc.
Pretty useless if you use Microsoft’s keys. But with your own, depending on the attack surfaces you care about, can be pretty helpful
That should be up to my phone then. Unlockable phones display a mandatory warning screen on power on if they've been unlocked - isn't that sufficient? Why should Facebook also be allowed to care?
We know users blow past any warnings, even if it is in big, bold, red letters stating that they were hacked and should not continue.
Plus why should I be inconvenienced by not being able to watch my TikToks if my phone was hacked? On the other hand, I expect my important apps to apply a higher level of validation before they accept random inputs.
That's why my car doesn't run on unapproved fuels. No way to know the liquid in the fuel tank isn't concentrated sulfuric acid, which would severely corrode the engine, so better not to let it run without a vehicle-manufacturer-authorised fuel. It can't just be a warning because I might skip the warning and then corrode my engine if the fuel tank is full of concentrated sulfuric acid - so it has to be a hard lockout. The vehicle manufacturer charges a 300% mark-up on the fuel, but such is the price for safety!
the reality is that evil maid attacks, and more broadly (and realistically) physical access attacks are exceedingly rare. The vast majority of stolen credentials are phished or some other social-engineering trick, not James Bond sneaking in with his badusb.
It was inconceivable to crypto bro’s that kidnapping people for their keys was a possibility…
If banks make it a requirement you use certain pre approved devices, you better believe badusb/physical theft will take place more commonly and it will definitely not be someone as polite as James.
Then you just entered your unlock code / password into the compromised device which immediately transmits it to the attacker who has your real device.
On top of that, secure boot doesn't require remote attestation. If your device doesn't like the new configuration then it doesn't release the key. The site has nothing to do with that except insofar as you need the key to sign into it. Your device manufacturer's key doesn't have to sign anything, all your device has to do is not give up your key unless the device is in the configuration you specified. And if it will do that then it would also sign an attestation to the same effect, so remote attestation still provides you with no advantage whatsoever.
Maybe I'm misreading, but that was my point - an app roots your phone but doesn't reboot yet, resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
> resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.
There are two types of compromise for the local device. The first is that they get root on the application processor (but not the secure processor), the second is that they get root on the secure processor.
If you have the first type of compromise then you don't need remote attestation because you can have the secure processor do any verification the remote server would have done and not release keys/signatures that allow you to sign into the service when the device isn't in the expected state. The secure processor won't accept a different device state for use of the existing key unless you compromise it.
If you have the second type of compromise then remote attestation can't save you because the attacker can forge attestations.
In neither case does it do you any good. The only thing it does in the first case is lock you out of using a device or OS you want to use because the service is demanding a signature from a specific OEM rather than one from the key you yourself generated and registered with the service and can keep in any kind of device you choose.
You can’t change secure boot settings from the OS, even with root. You need the signing keys or to be in BIOS (if it’s configured correctly), which shouldn’t be on the device.
Now if the right kernel exploit and a secure boot exploit are chained together then it’s possible. But at the point, you’re gonna be hosed no matter what you do.
> In a 2009 blog post, security analyst Joanna Rutkowska coined the term "Evil Maid Attack" due to hotel rooms being a common place where devices are left unattended.[1][2] Rutkowska then published a practical method for bypassing TrueCrypt disk encryption on victim devices, requiring merely an external USB flash drive.[3]
I hope the situation with disk encryption has improved. Otherwise, what is even the point of it? Any local malware you get is going to get an unencrypted view of the disk anyway (just like your legitimate programs) and there is already something seriously wrong if someone manages a remote login on a random home desktop that wasn't specifically configured for it.