[HN Gopher] Technical Introduction to the Use of Trusted Platfor...
___________________________________________________________________
Technical Introduction to the Use of Trusted Platform Module 2.0
with Linux [pdf]
Author : 0xdeadb00f
Score : 57 points
Date : 2021-07-22 12:58 UTC (10 hours ago)
(HTM) web link (lenovopress.com)
(TXT) w3m dump (lenovopress.com)
| raxxorrax wrote:
| 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.
| gruez wrote:
| >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).
| ajklsdhfniuwehf wrote:
| > 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.
| Sanzig wrote:
| > 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.
| ajklsdhfniuwehf wrote:
| 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.
| JohnFen wrote:
| > 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.
| vinsci wrote:
| 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
| riskable wrote:
| 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.
| duskwuff wrote:
| > 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.
| gruez wrote:
| >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.
| jnwatson wrote:
| 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.
| raxxorrax wrote:
| 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.
| ajklsdhfniuwehf wrote:
| > 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.
| waych wrote:
| 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?
| jnwatson wrote:
| 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.
| a1369209993 wrote:
| > 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 when." as "doubt".)
| michaelmrose wrote:
| 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?
| anonymousDan wrote:
| Does anyone know of a good performance analysis of modern TPMs?
| I'm particularly interested in persistent counter performance and
| durability.
| fsflover wrote:
| 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...
| vinsci wrote:
| 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.
| dane-pgp wrote:
| > 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.
| tasogare wrote:
| 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.
| eliaspro wrote:
| Which seems like a rather reasonable measure to keep people
| from spreading a dangerous disease for which they refuse to
| get vaccinated against.
| [deleted]
| alexseman wrote:
| oh give me a break...
| vetinari wrote:
| 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.
| tasogare wrote:
| 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.
| penultimatebro wrote:
| 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.
| deegles wrote:
| You can argue for anything you believe in, but that
| doesn't make it true.
|
| https://www.cdc.gov/coronavirus/2019-ncov/vaccines/faq.ht
| ml
| loup-vaillant wrote:
| 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 (Comite Consultatif National
| d'Ethique) 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.
| 908B64B197 wrote:
| > 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?
| loup-vaillant wrote:
| 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 -70Cdeg.
| 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.
| gruez wrote:
| 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
| pengaru wrote:
| 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.
|
| [0] https://www.kingston.com/unitedstates/us/usb-flash-
| drives/da...
| pengaru wrote:
| 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.
| vinsci wrote:
| 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_sourc
| e_is_insufficien...
| decodebytes wrote:
| 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.
| ratiolat wrote:
| 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.
| WhyNotHugo wrote:
| 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.
| michaelt wrote:
| 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!
| invokestatic wrote:
| Windows supports TPM+PIN which is what you describe.
| zer0-c00l wrote:
| This exists.
| https://wiki.archlinux.org/title/Trusted_Platform_Module#Dat...
| rythie wrote:
| 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...
| WhyNotHugo wrote:
| > 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.
| chousuke wrote:
| 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.
| raxxorrax wrote:
| There is a key for the TPM chip that authenticates it. It is
| a unique identifier you cannot change. How can this be
| anonymized?
| gruez wrote:
| 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.
| alksjdalkj wrote:
| 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?
___________________________________________________________________
(page generated 2021-07-22 23:02 UTC)