Lately I've been experimenting with storing my kernel+initrd in an encrypted usb thumbdrive w/integrated keypad [0].
My laptop now has no bootable disks and simply enters the BIOS boot menu when powered on without something bootable on usb, everything internal is just a dmcrypt volume.
This is just a way for me to help ensure my boot bits haven't been replaced or otherwise tampered with, while still letting me still trivially build/modify kernels and initrds just by unlocking the thumbdrive and inserting it.
It also has the nice side effect of not leaving the boot storage attached continuously, I have to explicitly make it available when I intend to update those components. When booting, I generally yank it the moment I see systemd's version print on the console.
It's also trivial to use a keyfile on the encrypted usb drive, so once the usb is unlocked and inserted, the laptop just boots to login. But then you're really relying on the black box thumbdrive for protecting secrets, vs. uninteresting boot bits you're just trying to prevent from getting replaced.
Another kind of interesting UX with the DT2000 is since it has a battery, you can unlock the drive anywhere (perhaps with more privacy, or just less visibility of doing something interesting), then bring it to the laptop.
I'm not saying this is a super secure solution or anything, it's just a somewhat interesting way to boot (and unlock if using a keyfile) a FDE machine which has proven to at least not be super annoying.
Too late to edit, but forgot to mention the DT2000 also supports a read-only mode. So if desired, in regular usage for boot purposes, it's not writable. It then needs to explicitly be switched to read-write via the keypad when performing kernel/initrd updates, if configured as such.
I don't really think TPM can offer me reasonable security. The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices. We see the same strategy on mobile phones.
So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.
The TPM provides a number of useful functions but the use case upon which it was created was to act as a tamper-evident seal. We have such seals on all sorts of things in our lives: Food containers, shipping containers, etc.
The big difference between the TPM and something like a food seal is that the end user is the one that opens the food and knows that yes, "I did that myself; this is intended." Whereas with the TPM the only "user" with the right to break the seal is a 3rd party that has completely different--and often conflicting--interests to the end user (and owner of the device). If the end user/owner breaks the seal they're treated as an attacker. This is the big problem and the big bad thing that must not be allowed.
The entertainment/music industry (the only ones that actually want this) are looking for a guarantee that the end user has not modified the device that they own in order to play back their content. It's ridiculous.
It's not just ridiculous that they are seeking what is essentially a veto right over everyone's systems it's also ridiculous in that it assumes it'll actually be effective in any way, shape, or form.
There's a million and one ways to work around this kind of "protection" many of which are trivial (e.g. point a camera at the device). The industry knows this!
So then the question becomes: Why do it? The answer is simple: So they can be the gatekeepers for all devices sold and therefore be able to veto in essence any devices the don't like. They may even be able to extract a tidy profit from those who require certification.
The whole notion is anti-consumer and just generally a really bad idea from the perspective of technological progress and innovation. Content owners should not have any say whatsoever in how general purpose devices are made or used. They should conform to the market; not the other way around.
>I don't really think TPM can offer me reasonable security
>So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.
The main security benefits to me are for full-disk encryption:
1. it ensures the bootloader isn't compromised so I know I'm not giving my FDE encryption keys to a bootkit
2. I can use a simpler/more memorable password because entry attempts have to go through the TPM, rather than being able to be bruteforced with a GPU cluster.
I'm not sure how what the "other methods" for accomplishing these are.
>The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices. We see the same strategy on mobile phones.
>This WILL be used as a DRM component.
Resisting TPM isn't really going to change much. All the major CPUs produced today (intel, amd, most ARM vendors) all have trusted execution environments, which does everything a TPM can do and more. They're also already required for many DRM schemes (eg. intel SGX for watching netflix 4k, arm trustzone for widevine L1).
Also, a TPM does not protect you from rubberhose key extraction. There is, however, a file system that can give you some modicum of protection against that, the Rubberhose File System[1][2], created by Julian Assange in the 1990s. It comes with a description that is worth looking up and read.
I'd be cautious with that, as the Purism security guy is not necessarily a free man to do what is best for the customers of Purism. He needs assistance, support and protection from abusive people, and small popes.
I'm really interested in instructions which would enable storage encryption key to be stored in the TPM so Linux could have the similar user friendly flow as MacOS and Windows with Bitlocker has - boot up computer, storage is decrypted automatically so user only needs to know username and password. If storage is removed from computer or booted from "untrusted source", storage stays "locked".
Backup key, for recovery purposes, needs to be stored in a password vault/physical safe/some external system. The same as it is with MacOS Filevault/Microsoft Windows Bitlocker.
Honestly, I think providing the disk decryption password during early boot is a lot safer.
If the TPM yields the decryption key, then the disk is mounted without the user being present, so any RUNTIME security hole can be exploited by the attacker (e.g.: USB exploits, etc).
The Mac/Windows model just seems less-safe (though more friendly for shared devices).
I would like a shared system though: where I provide half the key, and the TPM has the other half, so BOTH are necessary to decrypt the disk.
A useful flow for the overwhelmingly single user computers is to make FDE password and user account password the same and enable auto login. Basically at boot up the user is prompted for their password and when boot up completes they are automatically logged into their user account without further prompting.
For multi user systems one can tie login to mounting an encrypted home but of course you are still required to enter a password twice although in theory it seems like the information entered first could be retained and could be used to log in a user and complete the next step.
Anyone interested in leveraging a TPM, it's worth a look at the open source project https://keylime.dev
In regards to dane-pgp highlighting Intel TXT / tboot, Keylime does not use this. It measures via grub and a uefi shim (for measure boot) for run time file monitoring, it uses the Linux Kernels IMA.
> The EK is a 2048-bit RSA key pair used as a cryptographic identity to distinguish and authenticate an individual TPM.
This seems risky. Aside from not being very privacy-friendly, I can image all sort of shady scenarios, like apps only running if you're using hardware from a certain vendor.
There are ways to generate an anonymous proof that a TPM module is certified genuine by its manufacturer, without leaking the actual identity of the individual device.
Using TPM2 in VMs means you either pass through the hardware to the VM or use a software TPM module that's managed by the hypervisor.
I've had to dig in to TPM2 somewhat lately, and honestly the biggest problem with it is that it's too damn flexible, so it's really difficult to tell how to use one properly. There are a dozen concepts that you need to understand before you can even begin to make sense of any documentation.
I always see people claim that TPMs will enable DRM, but aren't we already subject to plenty of DRM? There's a lot of content that I'm blocked from accessing because I use Firefox on Linux, and AFAIK none of that DRM makes use of my TPM. What kind of DRM are people worried the TPM will enable, that we aren't already subject to?
Right, because plenty of modern machines do not have a TPM or do not have it enabled. There's little sense in using a TPM for some users when many others can bypass the TPM restrictions by using hardware without.
> What kind of DRM are people worried the TPM will enable, that we aren't already subject to?
Over protective applications which refuse to run when a machine is deemed "insecure". I don't have an example of this on PC, but there are plenty of Android apps which refuse running on rooted devices.
Physical TPMs are crazy slow (though fTPMs might be reasonable). Is that a performance analysis? Not really, but if you are looking for performance look elsewhere.
> tboot (Trusted Boot) is one of the applications related to TPM 2.0 that uses Intel TXT to create an MLE (Measured Launch Environment) to verify a kernel or a hypervisor
For people worried that governments will one day start mandating the use of "approved" operating systems, this will no doubt be reassuring, as it means Linux distros will be able to apply for inclusion on the whitelist.
The fact you can install Linux doesn't mean a government won't force you to use another OS by other mean. Looking at the current news in France which is nominally a democracy, that could include forcing one to take unpaid work leave, denying access to vital (supermarkets) and social places (restaurants, any entertainment facility) and even hospital.
[+] [-] pengaru|4 years ago|reply
My laptop now has no bootable disks and simply enters the BIOS boot menu when powered on without something bootable on usb, everything internal is just a dmcrypt volume.
This is just a way for me to help ensure my boot bits haven't been replaced or otherwise tampered with, while still letting me still trivially build/modify kernels and initrds just by unlocking the thumbdrive and inserting it.
It also has the nice side effect of not leaving the boot storage attached continuously, I have to explicitly make it available when I intend to update those components. When booting, I generally yank it the moment I see systemd's version print on the console.
It's also trivial to use a keyfile on the encrypted usb drive, so once the usb is unlocked and inserted, the laptop just boots to login. But then you're really relying on the black box thumbdrive for protecting secrets, vs. uninteresting boot bits you're just trying to prevent from getting replaced.
Another kind of interesting UX with the DT2000 is since it has a battery, you can unlock the drive anywhere (perhaps with more privacy, or just less visibility of doing something interesting), then bring it to the laptop.
I'm not saying this is a super secure solution or anything, it's just a somewhat interesting way to boot (and unlock if using a keyfile) a FDE machine which has proven to at least not be super annoying.
[0] https://www.kingston.com/unitedstates/us/usb-flash-drives/da...
[+] [-] pengaru|4 years ago|reply
[+] [-] raxxorrax|4 years ago|reply
So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.
https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_l...
We need tools to fake it, like we do in our jobs.
There are other ways, but also your device gets a unique identifier that you cannot change.
This is "security" done wrong as described in the textbook. This WILL be used as a DRM component.
[+] [-] riskable|4 years ago|reply
The big difference between the TPM and something like a food seal is that the end user is the one that opens the food and knows that yes, "I did that myself; this is intended." Whereas with the TPM the only "user" with the right to break the seal is a 3rd party that has completely different--and often conflicting--interests to the end user (and owner of the device). If the end user/owner breaks the seal they're treated as an attacker. This is the big problem and the big bad thing that must not be allowed.
The entertainment/music industry (the only ones that actually want this) are looking for a guarantee that the end user has not modified the device that they own in order to play back their content. It's ridiculous.
It's not just ridiculous that they are seeking what is essentially a veto right over everyone's systems it's also ridiculous in that it assumes it'll actually be effective in any way, shape, or form.
There's a million and one ways to work around this kind of "protection" many of which are trivial (e.g. point a camera at the device). The industry knows this!
So then the question becomes: Why do it? The answer is simple: So they can be the gatekeepers for all devices sold and therefore be able to veto in essence any devices the don't like. They may even be able to extract a tidy profit from those who require certification.
The whole notion is anti-consumer and just generally a really bad idea from the perspective of technological progress and innovation. Content owners should not have any say whatsoever in how general purpose devices are made or used. They should conform to the market; not the other way around.
[+] [-] gruez|4 years ago|reply
>So sorry, the "security advantage" isn't worth it as I could achieve the same with other methods. And I need to expect severe disadvantages.
The main security benefits to me are for full-disk encryption:
1. it ensures the bootloader isn't compromised so I know I'm not giving my FDE encryption keys to a bootkit
2. I can use a simpler/more memorable password because entry attempts have to go through the TPM, rather than being able to be bruteforced with a GPU cluster.
I'm not sure how what the "other methods" for accomplishing these are.
>The result is clear already, some apps refuse to run if you don't have TPM because they need to make sure you cannot freely modify your own devices. We see the same strategy on mobile phones.
>This WILL be used as a DRM component.
Resisting TPM isn't really going to change much. All the major CPUs produced today (intel, amd, most ARM vendors) all have trusted execution environments, which does everything a TPM can do and more. They're also already required for many DRM schemes (eg. intel SGX for watching netflix 4k, arm trustzone for widevine L1).
[+] [-] JohnFen|4 years ago|reply
This sort of thing is why I consider TPM harmful and avoid machines that include it to the best of my ability.
Since avoiding it becomes less tenable as time goes by, I'm starting to consider methods that could block access to it instead.
[+] [-] vinsci|4 years ago|reply
[1] This appears to be a copy https://github.com/sporkexec/rubberhose [2] A partial archive.org copy https://web.archive.org/web/20010819035021/http://www.marutu...
Edit: add URLs
[+] [-] yrro|4 years ago|reply
[+] [-] fsflover|4 years ago|reply
[+] [-] vinsci|4 years ago|reply
[+] [-] ratiolat|4 years ago|reply
Backup key, for recovery purposes, needs to be stored in a password vault/physical safe/some external system. The same as it is with MacOS Filevault/Microsoft Windows Bitlocker.
[+] [-] WhyNotHugo|4 years ago|reply
If the TPM yields the decryption key, then the disk is mounted without the user being present, so any RUNTIME security hole can be exploited by the attacker (e.g.: USB exploits, etc).
The Mac/Windows model just seems less-safe (though more friendly for shared devices).
I would like a shared system though: where I provide half the key, and the TPM has the other half, so BOTH are necessary to decrypt the disk.
[+] [-] zer0-c00l|4 years ago|reply
[+] [-] michaelmrose|4 years ago|reply
For multi user systems one can tie login to mounting an encrypted home but of course you are still required to enter a password twice although in theory it seems like the information entered first could be retained and could be used to log in a user and complete the next step.
[+] [-] rythie|4 years ago|reply
You can also unlock using a tang server: https://www.networkshinobi.com/clevis-and-tang-network-bound...
[+] [-] decodebytes|4 years ago|reply
In regards to dane-pgp highlighting Intel TXT / tboot, Keylime does not use this. It measures via grub and a uefi shim (for measure boot) for run time file monitoring, it uses the Linux Kernels IMA.
[+] [-] WhyNotHugo|4 years ago|reply
This seems risky. Aside from not being very privacy-friendly, I can image all sort of shady scenarios, like apps only running if you're using hardware from a certain vendor.
Also sounds like it makes a TPM2 for VMs a no-go.
[+] [-] chousuke|4 years ago|reply
Using TPM2 in VMs means you either pass through the hardware to the VM or use a software TPM module that's managed by the hypervisor.
I've had to dig in to TPM2 somewhat lately, and honestly the biggest problem with it is that it's too damn flexible, so it's really difficult to tell how to use one properly. There are a dozen concepts that you need to understand before you can even begin to make sense of any documentation.
[+] [-] alksjdalkj|4 years ago|reply
[+] [-] nvllsvm|4 years ago|reply
Right, because plenty of modern machines do not have a TPM or do not have it enabled. There's little sense in using a TPM for some users when many others can bypass the TPM restrictions by using hardware without.
> What kind of DRM are people worried the TPM will enable, that we aren't already subject to?
Over protective applications which refuse to run when a machine is deemed "insecure". I don't have an example of this on PC, but there are plenty of Android apps which refuse running on rooted devices.
[+] [-] anonymousDan|4 years ago|reply
[+] [-] strstr|4 years ago|reply
[+] [-] dane-pgp|4 years ago|reply
For people worried that governments will one day start mandating the use of "approved" operating systems, this will no doubt be reassuring, as it means Linux distros will be able to apply for inclusion on the whitelist.
[+] [-] no_time|4 years ago|reply
[+] [-] tasogare|4 years ago|reply