Technical Introduction to the Use of Trusted Platform Module 2.0 with Linux [pdf](lenovopress.com)
lenovopress.com
Technical Introduction to the Use of Trusted Platform Module 2.0 with Linux [pdf]
https://lenovopress.com/lp0599.pdf
65 comments
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.
Ah, paranoia is a good motivator to learn more. You might want to see this[1], for example. I think his solution is likely to be a trap, ie. not actually safe, but the presentation is at least a good example of how complicated it is to get security right.
[1] Open Source is Insufficient to Solve Trust Problems in Hardware [video] https://media.ccc.de/v/36c3-10690-open_source_is_insufficien...
[1] Open Source is Insufficient to Solve Trust Problems in Hardware [video] https://media.ccc.de/v/36c3-10690-open_source_is_insufficien...
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.
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.
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.
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.
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.
Approximately 0 companies have used a TPM for DRM even though they have been put in PCs for 15 years now.
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.
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.
Normally full disk encryption and booting security is the province of your OS. To my recollection both Bitlocker and LUKS can optionally use the TPM which means it can be used for 100% of the use cases which would improve computer security.
What are we missing out on exactly?
What are we missing out on exactly?
TPM isn't active on many private devices, so the ability to abuse its capability was more or less impossible. That would come after it is firmly established.
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.
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.
> even though they have been put in PCs for 15 years now.
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.
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.
TPM is typically implemented in firmware for consumer boards. Having the option to upgrade to a hardware TPM module is nice, but probably not necessary for the vast majority of users. Hardware TPMs also come with their own sustainability questions regarding bugs/upgrades and how/if that process works. This is hard to do without compromising the benefits of using a physically separate TPM unless the end-user takes some form of responsibility in the custodianship themselves (which is not likely at the consumer level).
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?
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?
Why is that? It is because the TPM failed in the consumer market. Why is that?
One reason is the constant stream of FUD from the anti-DRM folks.
One reason is the constant stream of FUD from the anti-DRM folks.
> FUD
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.
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.
> 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".)
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".)
> 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).
This is completely false, and is in fact contradicted by the Lenovo PDF that we're discussing.
This is completely false, and is in fact contradicted by the Lenovo PDF that we're discussing.
>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.
But they are. It's just that the vast majority of the market are indifferent so it gets accepted.
That's not conforming to the market, that's doing what you want because people are indifferent.
Conforming to the market would be to not add something that nobody wants.
Conforming to the market would be to not add something that nobody wants.
>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).
>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).
> 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.
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.
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.
> 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.
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.
for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.
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.
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.
> for this to be true, the password to key transformation have to be extremely broken for you to be able to infer what is a valid key from what looks like fixed size random noise.
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.
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.
put down the intel certification pamphlets and go find a single key encryption where those two things are true.
> 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.
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.
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.
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.
[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
[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
Which apps refuse to run in the absence of a TPM, please?
Windows 11 maybe?
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.
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.
Ok I walked into that one. ;)
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.
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.
See also: Purism's laptop with TPM designed for Linux, where you are always in control of your keys: https://news.softpedia.com/news/purism-now-sells-the-most-se...
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.
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.
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.
Just keying in the password at boot is indeed more secure than using a TPM, when it comes to the threat of someone snatching your powered-off laptop.
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!
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!
> 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 …
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
Also great for personal NAS for example. But its bloody hard to implement on Linux/BSD at the moment
> So TPMs are great if you're a big corporation!
Quite true. They're pretty bad if you're just a person.
Quite true. They're pretty bad if you're just a person.
Windows supports TPM+PIN which is what you describe.
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.
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.
You so that with clevis: https://kowalski7cc.xyz/blog/luks2-tpm2-clevis-fedora31
You can also unlock using a tang server: https://www.networkshinobi.com/clevis-and-tang-network-bound...
You can also unlock using a tang server: https://www.networkshinobi.com/clevis-and-tang-network-bound...
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.
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.
Also sounds like it makes a TPM2 for VMs a no-go.
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.
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.
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.
There is a key for the TPM chip that authenticates it. It is a unique identifier you cannot change. How can this be anonymized?
AFAIK it's accomplished by having two keys in the TPM. One is unique to the TPM, and the other is unique to the manufacturer/batch of TPMs.
True, I found it in the manual. There is the ECC-based Direct Anonymous Attestation, but the paper is behind a paywall right now.
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.
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.
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?
> AFAIK none of that DRM makes use of my TPM
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.
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.
My point is that's already happening now, so I don't understand the fear that TPMs will enable some sort of draconian DRM. They don't enable anything that isn't already possible with respect to DRM and locking down machines.
Remote attestation of machine parameters, which is arguably even worse than the DRM aspect is not yet possible on PCs to my knowledge.
Does anyone know of a good performance analysis of modern TPMs? I'm particularly interested in persistent counter performance and durability.
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.
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.
This doesn't reassure me at all. Linux can be just as oppressive as windows if configured accordingly.
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.
Which seems like a rather reasonable measure to keep people from spreading a dangerous disease for which they refuse to get vaccinated against.
It is not at all clear that we French were actually refusing to get vaccinated.
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.
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.
> 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.
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?
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?
If you want to be efficient, you want a level of centralisation so you're make sure they can work with maximum efficiency (and therefore at maximum capacity, which you can scale up as there is more demand or more doses).
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.
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.
Given that experience has shown that vaccinated people can spread the same disease as well AND they are more reckless because they think that they are immune now, I would not consider that a reasonable measure. Now it seems more like punishment for not obeying the government, and less like health concern.
The vaccinated people can spread the disease like you can still get herpes when you use a condom. FYI, condoms grant you a 30% reduction of infection rate for the relevant type.
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...
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...
Yes, and the biggest proof of this is hospitals will soon impose the sanitary pass (from 1st August). If the pass was really about public health of the population, hospitals would be the last place to be restricted.
Now just solve for people that have had the dangerous disease, have recovered from it, and now are arguably better protected from variants than the vaccinated.
You can argue for anything you believe in, but that doesn't make it true.
https://www.cdc.gov/coronavirus/2019-ncov/vaccines/faq.html
https://www.cdc.gov/coronavirus/2019-ncov/vaccines/faq.html
That's why you have to use one of the operating systems on the NSA Certified Secured Operating Systems list, which contain antivirus software[1]. It's a rather reasonable measure, because it keeps computers from spreading dangerous worms/viruses/ransomware for which they refuse to get to protection against.
[1] https://news.ycombinator.com/item?id=27917105
[1] https://news.ycombinator.com/item?id=27917105
[deleted]
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...