Authenticated Boot and Disk Encryption on Linux
141–150 of 214 posts
Re: Authenticated Boot and Disk Encryption on Linux
#142Earlier quoted context omitted.
I believe OP is referring to the fact that a sophisticated attack has access to the hardware and you continue using it afterwards. They could, for example, change the unencrypted /boot partition to log the password you use to decrypt your partition. Or, if you sign the boot partition, they could install a hardware key logger, or do any other kind of hardware modification that defeats the security. Preventing this kin…
Just wanted to add that this is generally referred to as the "Evil Maid" scenario in case someone wants to Google it. It can be mitigated somewhat with secure boot, tpm technologies etc but due to the breadth of possible attacks it's really hard to do against a serious attacker. Even the sound of the keyboard is often enough to give your password away.
(Though to be fair, Libreboot only runs on a very limited number of old devices).
Re: Authenticated Boot and Disk Encryption on Linux
#143> Some corners of the community tried (unfortunately successfully to some degree) to paint TPMs/Trusted Computing/SecureBoot as generally evil technologies that stop us from using our systems the way we want. That idea is rubbish though, I think. It's not as rubbish as the author wants to think. Just look at the current state of Android SafetyNet attestation - a myriad of apps refuse to run entirely (banking apps, ga…
Re: Authenticated Boot and Disk Encryption on Linux
#144If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…
> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. I think with blanket statements like this it's important to define sophisticated. For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? I'm of course not talking about social engine…
You don't really make an argument on where your example should fall on that axis, which is what I would have preferred to see.
Re: Authenticated Boot and Disk Encryption on Linux
#145Earlier quoted context omitted.
> In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get a…
I think btrfs subvolumes can do this? However btrfs doesn't (yet?) support encryption.
And like the post says, I am typing two passwords.
Re: Authenticated Boot and Disk Encryption on Linux
#146Earlier quoted context omitted.
I believe OP is referring to the fact that a sophisticated attack has access to the hardware and you continue using it afterwards. They could, for example, change the unencrypted /boot partition to log the password you use to decrypt your partition. Or, if you sign the boot partition, they could install a hardware key logger, or do any other kind of hardware modification that defeats the security. Preventing this kin…
Just wanted to add that this is generally referred to as the "Evil Maid" scenario in case someone wants to Google it. It can be mitigated somewhat with secure boot, tpm technologies etc but due to the breadth of possible attacks it's really hard to do against a serious attacker. Even the sound of the keyboard is often enough to give your password away.
Re: Authenticated Boot and Disk Encryption on Linux
#147If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…
Well, you can probably annoy at least some attackers by using tamper-proof seals on your PC case and act accordingly if they are broken, because that would likely prevent them from conducting the first physical attack. But that won't help in the long run. Outstanding locks on a reinforced door and a combination of visible and hidden cameras in the hallway are probably more effective.
https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclea...
Re: Authenticated Boot and Disk Encryption on Linux
#148Earlier quoted context omitted.
> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. I think with blanket statements like this it's important to define sophisticated. For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? I'm of course not talking about social engine…
GP already made space for this analysis by admitting a sophisticated/unsophisticated axis, thus the contrary stance of your comment is unnecessary. You don't really make an argument on where your example should fall on that axis, which is what I would have preferred to see.
In this case, I don't know if sophistication could mean an evil maid attack with a breadboard and $15 worth of electronic components (which was required to break the tpm 1), or something better than what the FBI has since they struggled to unlock a terrorist's phone. I can worry about the former, and relax about the later.
I'm not an expert and when someone throws that statement with authority I'd like to know if I'm vulnerable to geek or to the CIA
Re: Authenticated Boot and Disk Encryption on Linux
#149Earlier quoted context omitted.
This or the 'glitter nail-polish' pseudo-holographic identifiers both ignore that if you have a physically identical laptop save cosmetics, you can swap in the motherboard and hard disk from the replacement unit. Externally, it's identical, internally it's all compromised.
We haven’t found a l33t who can swap an macOS motherboard in 15 minutes.
Swapping the SSD and adding a keylogger to the ribbon cable would be a lot faster too, maybe 5 minutes with practice.
Re: Authenticated Boot and Disk Encryption on Linux
#150Earlier quoted context omitted.
Just wanted to add that this is generally referred to as the "Evil Maid" scenario in case someone wants to Google it. It can be mitigated somewhat with secure boot, tpm technologies etc but due to the breadth of possible attacks it's really hard to do against a serious attacker. Even the sound of the keyboard is often enough to give your password away.
Or encrypt the boot partition. Libreboot supports this. (Though to be fair, Libreboot only runs on a very limited number of old devices).