Technical Introduction to the Use of Trusted Platform Module 2.0 with Linux [pdf]
lenovopress.com
lenovopress.com
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...
[1] Open Source is Insufficient to Solve Trust Problems in Hardware [video] https://media.ccc.de/v/36c3-10690-open_source_is_insufficien...
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.
>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).
this is already the case with every single open source encryption model out there. You have a simple password which then encodes the true key.
Nothing will save you from GPU cluster brute forcing it, if the adversary have your harddrive.
Not really true.
In the case where a password is used to derive the encryption key, the password is passed to a key derivation function which deterministically generates the key of the appropriate length. Ideally, the KDF should be computationally difficult to slow down brute force attempts, but you can still parallelize the attack with a big GPU/FPGA cluster. If the password is sufficiently weak, you can often get a break this way.
In the case of using a TPM for full disk encryption, the key is generated by the module itself and requires a password to unlock. This is rate-limited by hardware, and typically the TPM will lock itself out if you have entered the incorrect password too many times. If you steal the hard drive, you can't decrypt it even if you know the password (the password unlocks the TPM and has nothing to do with key generation). Likewise, if you steal the whole machine but don't have the password, you'll be hard-pressed to brute force it since the rate-limiting / lockout features mean you can't make lots of parallel tries. Your GPU cluster is an expensive paperweight in this case.
In theory, the only reliable way to decrypt a device using full-disk encryption and a TPM without the password is to try extracting the secrets from the TPM itself. This isn't impossible, but they are specifically built to resist key-extraction attacks. You're pretty much talking about an attacker with state-level resources in that case, or at the very least a very determined group of private sector professionals.
well, this might be true if you use some NIST or RSA certified process :) but who cares about that other than bureaucrats who run entire cities with one set of master keys anyway.
> This is rate-limited by hardware
See this is the kinda of thing those bureaucrats would say. If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.
You're not bruteforcing the derived key (ie. the value from the KDF), you're running a wordlist against the KDF and seeing which values work.
>If your hdd is out of your device and i am brute forcing the key, who cares about the password to key transformation? that is already behind me.
The difference is that with a TPM, you can't run a wordlist attack, since password attempts have to go through the TPM, and it throttles your guessing attempts. Without a TPM you can run the KDF as fast as you want, across as many machines as you want.
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.
But they are. It's just that the vast majority of the market are indifferent so it gets accepted.
Conforming to the market would be to not add something that nobody wants.
At the same time, boot sector attacks have become prevalent, which TPMs can protect from.
The net effect is the paranoid "never use anything that might possibly one day might be used for DRM" folks have made practical computer security worse by threatening anyone that adds TPM functionality into their product.
Good job.
What are we missing out on exactly?
What we do know thought is the software landscape of devices that are indeed locked down mostly to the benefit of the manufacturers. Turns out the uniformity of that software landscape didn't stop NSO from silently taking over phones. Different threat scenario, but I think the pattern is clear.
I think we need a closer examination on how often private devices are affected by firmware attacks or messing with boot. As far as I know they have become quite rare. Perhaps I need to shift my paranoia there, but I am not convinced.
But these questions are irrelevant if TPM stays optional. A lot of IT security comes down to trust problems, so I fail to see why possible disadvantages shouldn't be examined.
As far as I know I could activate TPM right now, so I also fail to see how "folks" hold practical security back. Weighting security mechanisms is also an essential step. I am just not convinced it does improve my practical security, while maybe it proves detrimental to general computing.
i have never seen a consumer motherboard with a TPM device in the last 15 years. In fact, the last batch of enthusiast AM4 ones ("pro" model), the TPM doesn't even have the Header populated, only the holes for one that you can solder a header.
And non-workstation office machines from hp and dell ship weird ones that probably won't even pass the win11 test.
One reason is the constant stream of FUD from the anti-DRM folks.
Yes? Fear, uncertainty and doubt is the correct attitude toward TPMs. (Assuming you count "We know it's going to hurt us, just not how long it will take to happen." as "doubt".)
https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
You think all those FIDO members don't care about DRM. That is beyond naive in my opinion. Security is a trust problem, so much should be clear before even starting to discuss it.
Also FUD is employed by presenting advantages of TPM as it often invokes ransomware.
Nice, but probably 99% of ransomware is just executed in user space and starts encrypting typical network drives in typical corporations. Some are more sophisticated, but I haven't seen any bios attacks recently. And why would they? Ransomware is quite profitable.
Considering that the vast majority of boards aren't going to need the header, the board manufacturers can scale cost reduced versions for the masses and spin versions with a couple more headers for a couple more dollars for the fringe users that want them (pre-)populated. Seems like a rational business decision?
This is completely false, and is in fact contradicted by the Lenovo PDF that we're discussing.
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.
[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
Of course you would see the effects once it is established. Since it was rejected for the most part, this mechanism cannot work.
You can deny these fears all you want, but TPM is not for you, the security benefits are negligible. Perhaps put it on your server, but I don't see the necessity either.
https://secret.club/2021/06/28/windows11-tpms.html
I don't think anyone can make reasonable argument against the problems put on the table here.
You can also look up the FIDO group. While they are important to strengthen and develop encryption, there is a reason for its corporate sponsors aside user security. The user is a hostile entity in TPM security schemes.
I was thinking more in terms of user applications. Bit having read your link I confess I had no idea about the seldom talked about endorsement keys.
On the one hand this will allow my IT department to completelyoxk down all out end user devices such that they cannot access any of our services if the device has been compromised. But the price well pay is that Disney will refuse to let me play video on my own device, and I expect sooner or later PunkBuster and so on wont even let me join a game server on such a device...
The future looks pretty bleak.
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.
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.
But if you want full disk encryption for a server without the need to attend it in person to enter the password every time it restarts, you might feel the middling security a TPM provides is an improvement over not encrypting the disk at all.
Or if you issue a big fleet of laptops to forgetful users, and remote password reset is a must-have feature, the TPM is more secure than the user writing the password on a post-it note stuck to the laptop.
Or if you're making something like a TiVo where you want it to work without a password - while also locking down the device, even against the owner.
So TPMs are great if you're a big corporation!
Also great for personal NAS for example. But its bloody hard to implement on Linux/BSD at the moment
Quite true. They're pretty bad if you're just a person.
You can also unlock using a tang server: https://www.networkshinobi.com/clevis-and-tang-network-bound...
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.
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.
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.
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.
My country (GER) currently wants to force OS developers to block sites not intended for children by default. TPM is a mechanism that could facilitate such restrictions. Imagine all content on the net would check that the boot loader of your device is locked and that you use a state approved OS. See the dangers here?
Even if the chance of success is low, boot sector attacks by ransomware, currently the most prominent threat, are extreme rare, I don't know of any case to be honest. This infrastructure decreases security for free and general computing to such a degree, that the threat from boot sector or bios attacks is laughable at best.
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.
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.
We should definitely be vaccinated, and in in doing so, using the power and strengths of modern society to reap the benefits we are supposedly living in it for the purpose of creating for ourselves in the first place.
Vaccinated people can spread the virus, but the rates are much[0] less[4] because the immune system is actively controlling[1] the outbreak. Viral load correlates strongly with ones ability to transmit Sars-CoV-2[5]
This beats my herpes example like electricity beats wood gas for lighting.
Vaccinated people get and transmit the Sars-CoV-2 virus at much lower rates[3, page 10][4], and essentially never become very ill. Death is not the only effect of Sars-CoV-2, it has a variety of negative effects from the mild, to the bad, onward to the extremely taxing COVID, and critical hospitalization. This is aside from other secondary social, psychological and economic impacts.
If you rate the risk of death as fine and think we should just take a chance, everybody in the world feeling very ill for a few weeks is not nothing. Those people are air traffic controllers, doctors, mechanics, chefs, pilots, nuclear safety officers, police, etc and their normal operation matters for the operation of society.
[0] - https://www.medrxiv.org/content/10.1101/2021.07.12.21260377v...
[1] - https://www.nature.com/articles/s41591-021-01316-7
[3] - March 2021 representing early evidence: https://www.ecdc.europa.eu/sites/default/files/documents/Ris...
[4] - https://www.medrxiv.org/content/10.1101/2021.03.11.21253275v...
[5] - https://www.sciencedirect.com/science/article/pii/S147330992...
First, it would seem the least vaccinated people were generally the poorest as well. The vaccine is free, but we generally need to get an appointment through some web site, on our own initiative. Our appointed family doctor did not call us to even ask whether we'd like to be vaccinated. This hints towards an accessibility problem.
Second, when you look at the charts https://covidtracker.fr/vaccintracker/ (Click the "Injections Quotidiennes" tab on the second figure.), you can see that the daily injection didn't fall. It merely plateaued. Sure, first injections did fall, but they did so at the same time second injections were soaring, so they compensated each other. This plateau suggests our vaccination centres were simply functioning at (or close to) full capacity.
Third, on July the 12th, at the time our President made his speech about restricting everyone's freedom (including the vaccinated, since you'd have to present your digital pass basically everywhere to basically anyone), they were justifying our "Reluctance" by quoting vaccination rate across the whole population, which was around 52%. What they didn't say is that this stats includes children under 12, for which vaccination is simply not available, and teenagers, for which our CCNE (Comité Consultatif National d'Éthique) said on June the 9th that it was not clear teenage vaccination was safe enough https://www.ccne-ethique.fr/fr/actualites/enjeux-ethiques-re... It's only reasonable under these circumstances to exclude all underage people from the statistics. I found that the vaccination rate among adults was almost reaching 70%, and climbing.
My conclusion: what our president is attempting is utterly disproportionate and unjustified. Don't get me wrong, we are facing a fourth wave right now. Maybe something does indeed need to be done. But a digital pass? https://www.youtube.com/watch?v=fCUTX1jurJ4 No thanks.
Just put walk-in vaccination stands in super-markets/subway stations.
Why exactly is there a need for an appointment to get a 30 second jab + 15 minute observation period?
The biggest problem though is the temperature at which the doses must be stored. Pfeizer's is like -70C°. That's cold, and one does not simply carry a portable freezer to the super-market or subway station. Other vaccines are easier to manage, though.