[HN Gopher] Linux and TPMs with systemd measured boot [video]
___________________________________________________________________
Linux and TPMs with systemd measured boot [video]
Author : transpute
Score : 111 points
Date : 2023-11-05 08:54 UTC (14 hours ago)
(HTM) web link (media.ccc.de)
(TXT) w3m dump (media.ccc.de)
| pzmarzly wrote:
| I am not a big fan of systemd, but I am impressed in how they put
| this security feature all across the boot process. I also used
| some of the tools shown in presentation and they are pretty well
| made, kudos to the devs. (Also, most of them work fine without
| systemd running, they just happen to be in the systemd
| monorepo???)
| andrewstuart wrote:
| Systemd is packed with impressive things.
|
| The more you research it, the more you find to be impressed
| with.
| keep_reading wrote:
| I'll be impressed when they figure out how to not break bind
| mounts and NFS on boot
| immibis wrote:
| The problem with systemd isn't that it's not packed with
| impressive things, it's how inextricable the things are from
| each other. systemd distros are practically whole new distros
| on the inside, designed by committee. Every part of systemd
| really wants to integrate with every other part, so while you
| can technically compile and run just part of it, it really
| wants you to use the whole thing and throw away all the
| things those parts replace.
|
| In other words the complaints are political, not technical.
| pzmarzly wrote:
| I agree that there are some very cool components of systemd
| (or rather, very cool programs living in systemd repo) -
| networkd, resolved, repart, boot and stub come to my mind
| first, they have no alternatives that come even close to
| them.
|
| Also, systemd made writing service definitions easy, hats off
| to them. With cgroups, namespaces and capabilities support
| out of the box - great.
|
| However, every time I have to debug why some target wasn't
| reached (because some dependency of dependency failed), or
| why systemd mounted something wrongly, or just want to know
| how often and why some service restarted, I feel like the
| core part of systemd (which is, the systemd init and service
| runner) is working against me.
|
| And let's not get started on journald, I declare it my enemy.
| esjeon wrote:
| This thing isn't really complicated, because all the hard-
| lifting is done by the design of TPM, not even TPM chips.
| Measurements and integrity checks are proven to be mundane
| tasks, and, for security, it's a good thing. Even without
| systemd, one can learn and integrate TPM in one or two months.
| But the systemd team has been working on this like 2 years now.
|
| I'm quite curious what they've been doing. Security audits,
| maybe? Preparations for other integrations? I'm not criticizing
| here - I've been away from that scene for an year, and I wonder
| if there have been some new interesting developments or ideas
| that I'm not aware of.
| pzmarzly wrote:
| I wonder which of these tools Ubuntu is using - since they
| enabled TPM-backed encryption (Bitlocker-style) in 23.10.
| https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-c...
|
| I am not a huge fan of relying on this, I cannot recall numer of
| times where I had to recover my files from live USB or by
| plugging my drive into another PC - both of which will get
| difficult to do when my true password sits in TPM on the
| (potentially bricked) motherboard. But I guess that if it can be
| used in addition to regular password (e.g. use regular password
| when TPM is missing, use PIN if it works) then it's fine
| Manfred wrote:
| Do you prefer restoring from the original drive instead of a
| backup because it's faster?
| magicalhippo wrote:
| I use a daily full-disk backup on Windows[1], this has
| allowed me to be back up and running within the hour the few
| cases my disk died.
|
| What's a good alternative for Linux?
|
| [1]: Acronis TrueImage, but there are others.
| jeroenhd wrote:
| With modern file systems like BTRFS you could take a(n
| incremental) snapshot and send that over the network using
| btrfs send.
|
| Filesystems without snapshots can't be disk cloned that
| easily, but tools like Timeshift will try to replicate
| snapshot behaviour using hardlinks, so I assume backups of
| Timeshift snapshots should also suffice.
|
| Timeshift can be configured in various ways, including
| making daily snapshots. I mostly use it for periodic
| snapshots and snapshots taken before the package manager
| runs (as a poor man's System Restore alternative).
|
| I don't think Timeshift supports automatically sending
| snapshots just yet. For that, you'd need to set up a
| cronjob or systemd timer.
| zeta0134 wrote:
| Often I want to collect a very small number of files that I
| was working on which are newer than the last complete backup
| INTPenis wrote:
| Also, correct me if I'm wrong, but TPM shifts the password
| input prompt from traditionally LUKS during boot, to your XDM
| or whatever display manager you're using?
|
| And I seem to recall a recent vulnerability where people were
| able to bypass the display manager login on some graphical
| desktop Linux distro.
|
| I just don't feel comfortable shifting the threat to this part
| of the OS, because desktop Linux has not had the extensive
| testing required yet. It reminds me of when I was in school and
| you could bypass NT4 or Windows 98 logins by mashing the Enter
| key or doing weird user input combinations. Basically manually
| fuzzing.
|
| If TPM only adds convenience then I'd prefer to continue
| entering my LUKS password, and my login password, separately.
| proto_lambda wrote:
| If you rely only on TPM for key storage, yes, the disk is
| unlocked automatically and any sufficiently broken userspace
| application you can get your hands on will let you access it.
| You can still combine TPM+passphrase/PIN though, at the cost
| of having to enter it at boot.
| worksonmine wrote:
| > at the cost of having to enter it at boot
|
| Isn't this the entire point of full disk encryption? You
| mention cost, but what is even the benefit of encryption
| that's unlocked by just booting?
| proto_lambda wrote:
| With properly functioning secure boot and no bugs in the
| entire software stack, it doesn't matter if the disk is
| decrypted automatically, since you can't access the
| system without OS-level authentication. If you tried to
| replace system files to let you get in anyway, the secure
| boot measurements would no longer match up and the
| decryption fails entirely.
| worksonmine wrote:
| I use a very long and inconvenient password for LUKS, and
| a simpler one for login and root. My lock screen is more
| a convenience in a trusted environment and not security.
| The TPM only solution sounds like it would require my
| very long password every time I leave my desk to get
| coffee.
| akaiser wrote:
| Then again, an attacker can read the decryption key from
| RAM (freeze and remove the modules, then dump the memory
| on another system) and decrypt the disk offline.
|
| So, data on a stolen laptop which has an unprotected TPM
| (no PIN to boot) can be considered compromised.
| mratsim wrote:
| So you use soldered RAM. And the OS provides hardened
| memory areas that can't be dumped.
| proto_lambda wrote:
| There are such things are RAM encryption, but yes,
| overall it's more fragile from a security perspective
| than a strong plain passphrase.
| Talinx wrote:
| Relying on no bugs in the entire software stack makes the
| attack surface quite large.
|
| If a laptop is stolen the thief can wait sufficiently
| long for some vulnerability to be discovered somewhere in
| the stack. With LUKS only the LUKS encryption has to be
| good and full disk encryption protects the data.
| yowai wrote:
| > You mention cost, but what is even the benefit of
| encryption that's unlocked by just booting?
|
| Ideally, your login screen is secure and allows no
| bypasses into a shell or similar, so you cannot really
| access any files on the hard drive.
|
| And if you modify some system files or boot another
| operating system to get around this, you are required to
| know the disk encryption password to get to them.
| g_p wrote:
| You could bind your disk unlock to also include a PIN entered
| at boot-time (TPM+PIN).
|
| This gives you the benefit of system integrity verification
| at time of boot, but also requiring your input to release the
| keys (and meaning you can't get to the system lock screen
| without the PIN).
| 542458 wrote:
| Side note, does anybody know why TPM schemes use a
| _numeric_ PIN for pre-boot unlock rather than a full
| alphanumeric password? For a given length (say, 8) a
| password would presumably be more secure than just a PIN.
| It's not like this is a phone where you need users to be
| able to quickly enter the code on a limited input surface.
| Foxboron wrote:
| There is no limit to the password. Usinging a 4 digit
| numeric PIN is just easier to remember, and because of
| the bruteforce resistance it doesn't decrease the
| security.
| alex7734 wrote:
| If you're going to use a long password there is no point
| to using the TPM as the length of the password itself is
| enough brute force resistance.
| SV_BubbleTime wrote:
| Some you know + something you have/are?
| alex7734 wrote:
| I don't think it is that much more secure, given that in
| this case "something you have" is bolted onto the machine
| you're attempting to protect and that a sufficiently long
| password provides enough space to make brute forcing
| impossible anyway.
|
| In my opinion all the TPM achieves in this case is
| ensuring you lose your data if the machine dies (or if
| some OS update fucks up and doesn't properly ensure the
| TPM acknowledges the new version as valid).
|
| That said it does help against the so called evil maid
| attacks, given that it would lock itself out if anyone
| modifies the OS, so if that's part of your threat model
| then it is useful, I guess.
| dist-epoch wrote:
| > rather than a full alphanumeric password
|
| Because there are different kinds of keyboards out there,
| with different layouts, so if you switch keyboard you
| could find yourself unable to input the password. Imagine
| typing a "non-English" letter in the password and then
| switching to a US layout keyboard without that letter.
| Sure, a rare scenario, but with hundreds of millions of
| users you will hit it.
| n_plus_1_acc wrote:
| French keyboards have the numbers and symbols swapped.
| The numbers require shift.
| poettering wrote:
| With systemd you can enroll any string you want as "PIN"
| for tpm. There are no restrictions. Can be long, can be
| alphanumeric, contain weird chars, up to you.
| jeroenhd wrote:
| Ubuntu's implementation will also allow you to export a backup
| passphrase in case the TPM gets zapped (by a firmware update
| for example) after which you can re-enroll.
|
| Annoyingly, this is a random 16 byte value that's translated
| into a numeric string that only Ubuntus's cryptsetup wrapper
| seems to use. You need to convert it into an actual key if you
| want to re-enroll your TPM or add a key file/passphrase to
| another slot.
|
| If you don't back up the recovery key, your data is lost.
| poettering wrote:
| systemd has a similar logic, i.e. a recovery key concept, but
| we made sure you can type it in wherever a LUKS password
| would work too, even on systems where systemd is not
| available but LUKS ist. The recovery key is output in
| yubikey's modhex alphabet which means you can type it in on
| many keyboards even without setting a keymap first, and will
| work. We also output it as qr code, in case you want to scan
| it off. All on all it should be as robust as a recovery key
| could be.
| generalizations wrote:
| Oh cool. Does that mean the TPM key is set up to use one of
| the LUKS key slots?
| poettering wrote:
| Yes, a tpm2 enrollment takes up one slot, the recovery
| key another, a fido2 yet another, a pkcs11 key yet
| another and a password yet another in any
| combination/subset you like.
| immibis wrote:
| That's a highly unusual attitude for systemd. Most of the
| systemd architecture requires you to run systemd for
| everything if you use it at all. What changed?
| poettering wrote:
| Nothing changed. You are just a victim of FUD on the
| Internet, my friend. That's all.
| poettering wrote:
| To my knowledge Ubuntu does not use the TPM2 PCR logic systemd
| provides at all, but their own.
| wolf550e wrote:
| I want a review of this by mjg59.
| harvie wrote:
| TPM chips are not opensource, end user cannot simply check them
| for backdoors. Manufacturers of these chips are under heavy
| scrutiny of intelligence agencies. Governments around the world
| try their best to prevent people from using strong cryptography
| (eg. limiting effective key lengths in various ways).
|
| Why should we trust such chips more than purely software based
| approach?
| isilofi wrote:
| We shouldn't. TPM-based security is only sufficient against
| unsophisticated attackers such as a common thief stealing your
| laptop from your backpack.
| jon-wood wrote:
| This is a massive overstatement of the situation. Sure, a TPM
| might not protect you against the NSA or the Chinese
| government stealing your computer. If configured correctly it
| probably will protect you against anything less than a major
| nation state stealing your computer.
| justaj wrote:
| But wouldn't a properly configured LUKS encryption protect
| against nation-state threats too? If so, then why still use
| TPM?
| lostmsu wrote:
| If machine is not attached to a terminal it is useful if
| it boots on its own.
| immibis wrote:
| Then it still boots on its own if the bad guy has it.
| izacus wrote:
| And that's fine, it'll boot to macOS/Linux/Windows login
| screen and that's it.
| alufers wrote:
| Convenience, faster boot. Or if you have a headless
| server with disk encryption, but you want it to come back
| online without intervention after a reboot or power
| failure.
|
| It's all trade-offs.
| SV_BubbleTime wrote:
| In the scenario of headless, if I'm not missing something
| this only prevents drives from walking off. If the whole
| machine walks off you are in just as much trouble as not
| being encrypted at all if you don't really trust your OS
| permissions systems?
| Nextgrid wrote:
| The whole machine walking off is more detectable though.
| You can use TPM as one factor (among many, such as the
| presence of the machine on the expected network and no
| unexpected downtimes) to obtain storage keys from a
| separate trusted server, using TPM remote attestation to
| assert the machine hasn't been tampered with in-place (by
| merely booting it off a compromised OS).
|
| The separate authentication server can be configured to
| only hand out the storage encryption key on expected
| reboots, so if the machine unexpectedly walks off and
| then powers back on that server would refuse to hand out
| the key, thus the stolen machine is now useless.
| Asmod4n wrote:
| When someone steals your device and try's to guess a user
| password a tpm can just throw away it's keys. (Or
| something similar)
|
| Try it on a secure boot and tpm2 enabled Bitlocker
| encrypted drive, the only way to get in is via the
| recovery key after a configurable number of attempts.
| alufers wrote:
| If you take some basic precautions - disable interrupting
| the boot process, serial console, etc. then bypassing
| that requires significant effort. As an attacker you need
| to know the versions of the software working on the
| server, know some exploit and then have the experise to
| use it.
|
| For example I know that the police in my country use off
| the shelf disk cloning devices and then some basic
| forensics software for analyzing the disk image. This can
| be done by an average computer technician, and such a TPM
| scheme would totally prevent them from extracting data.
| Of course for bigger cases they can invest some more
| effort, but they would have to be sure that there is some
| important data there to justify the cost.
| LtWorf wrote:
| Basically "the client requested it without understanding
| it makes no sense, so we did this thing"
| jon-wood wrote:
| TPM based encryption is hugely useful in embedded
| devices, where you really don't want to have to despatch
| someone to type the passphrase in. By driving it via the
| TPM you're protected against someone removing the storage
| and being able to read the decryption key off it, and
| you're also protected against someone modifying the
| components required to get to a decrypted disk to inject
| code you weren't expecting - if the kernel or bootloader
| is modified then the device simply won't boot.
| pmontra wrote:
| With an embedded device isn't easier to just steal the
| device instead of only the storage and making the device
| useless anyway?
| bmicraft wrote:
| In this scenario protecting the secrets on the device is
| supposedly more important that the monetary value of the
| device itself.
| SV_BubbleTime wrote:
| I sell a device. There are lots of them in hands. You
| still aren't getting my device key off of it. Yes, you
| can use that device all you like, but you aren't going to
| clone it and make more.
| sillystuff wrote:
| You've described DRM; this is exactly why a lot of people
| are wary of TPMs.
| lxgr wrote:
| No, DRM is safeguarding other people's keys on your
| device.
|
| There's more applications of trusted computing and TPMs
| than that; one of them is using it to safeguard your own
| keys.
| sillystuff wrote:
| > DRM is safeguarding other people's keys on your device.
|
| I think you misread the GP. Your definition of DRM is
| exactly what GP described as his use of the TPM.
|
| >>I sell a device. There are lots of them in hands. You
| still aren't getting my device key off of it. Yes, you
| can use that device all you like, but you aren't going to
| clone it and make more.
|
| What the GP describes is not safeguarding the nominal
| owner of the devices' keys. GP is restricting the nominal
| owner of the device on behalf of himself as the
| manufacturer. This is leveraging the TPM for DRM.
|
| Other possible less nefarious uses of the TPM are
| irrelevant to this point.
| lxgr wrote:
| Oh, I indeed read that as "I [re]sell a device". In the
| case of them selling devices with embedded non-
| extractable keys, it could really be DRM.
|
| Or something else! Payment cards work like that - they
| hold keys that nobody is supposed to be able to
| duplicate; certainly not third-parties, but also not the
| legitimate account-/cardholder.
|
| There are plenty of uses for trusted computing other than
| DRM; they're just usually not as disruptive/frustrating
| to legitimate customers as DRM (and as a result are not
| as contentious), so they don't get as much attention.
| jon-wood wrote:
| At least the embedded devices I work on don't expose any
| (reasonable) method to persuade them to do anything other
| than their intended job, so sure, steal the device if you
| like. With enough effort you can probably turn it into a
| general purpose computer, but you're not getting any of
| the secrets off it.
| cyberax wrote:
| Yes, but you'll need to enter a long password on every
| boot.
| goodpoint wrote:
| No, it's worse. It's *making* you vulnerable to those
| actors and possibly more.
| Nextgrid wrote:
| The majority of people don't want to type a long
| passphrase every boot (or would pick a trivially-
| bruteforceable one) and FDE-backed TPM (even if
| vulnerable to state-sponsored attacks) is better than
| what it would otherwise be which is no FDE at all.
| mjg59 wrote:
| Eh no that's not true. If a device uses a discrete TPM and
| isn't using authenticated sessions it's trivial to sniff
| the bus and extract the encryption key. If it _is_ then it
| 's less trivial because you need to interpose the TPM but
| that's still in "Can solder SMT parts" territory, not major
| nation state.
| Bognar wrote:
| You can only extract the encryption key if using the
| unencrypted APIs. You can establish and require an
| encrypted channel with the TPM if you know which TPM you
| are expecting.
| goodpoint wrote:
| Not even that.
| mratsim wrote:
| The real question is
|
| "What's your threat model?"
|
| If it's people stealing your laptop and fear of identity theft,
| use the TPM.
|
| If it's the NSA, -\\_(tsu)_/-
| cobertos wrote:
| LUKS or eCryptfs work perfectly fine for the "stealing your
| laptop" use case, and are purely software implementations.
|
| There's a poster below that provides a more reasonable use
| case for TPM. Headless server where asking for password on
| boot is undesirable (eg after a power failure)
| Nextgrid wrote:
| Only problem of software implementations is that they are
| reliant on the strength of the user-supplied passphrase, so
| there's a inverse correlation between user experience (ease
| of typing the passphrase) and security (easy passphrases
| are also easy to bruteforce).
|
| A TPM provides hardware-backed bruteforce protection which
| means even an easy passphrase can be made secure as the
| number of attempts is rate-limited by the TPM (to a level
| much slower than even the hardest hashes).
| immibis wrote:
| Then you want your own optional TPM that you trust - such
| as a YubiKey.
| mjg59 wrote:
| Why is a Yubikey more trustworthy? You don't have the
| source code, you don't have the hardware design. In
| addition, a Yubikey is given no information about the
| system boot state, so is in no position to identify that
| the system has been tampered with.
| immibis wrote:
| It's just one example. Use a different one if you want.
|
| People tend to trust them more because they belong to
| them, not Microsoft, or Hollywood, or the board
| manufacturer.
| mkopec wrote:
| In what manner specifically does a TPM not belong to the
| user, while a YubiKey does?
| Nextgrid wrote:
| The advantage of a TPM embedded in the platform is that
| it is aware of the platform's state - the hashes of the
| firmware, option ROMs and the bootloader/UEFI binary that
| you're loading. Discrete TPMs are vulnerable to bus
| interception attacks but newer firmware TPMs are embedded
| in the CPU/SoC and are invulnerable to this so it's
| pretty secure.
|
| A YubiKey/external TPM in comparison has no way to know
| whether it's being fed true PCR readings from the host or
| fakes from a malicious attacker, so at this point it will
| be no different (in the context of full-disk-encryption)
| from just having a dumb USB storage device with your LUKS
| keyfile on it.
| LikesPwsh wrote:
| Like most ordinary folks, my threat model is the use of TPM
| for DRM.
|
| Netflix playing at lower resolution for example.
|
| Widespread TPM is actively harmful for most people, and the
| biggest blow to general purpose computing in recent years.
| dist-epoch wrote:
| > Netflix playing at lower resolution for example.
|
| Nobody is forcing you to use Netflix. If you don't like it,
| leave for a better DRM-free service. That's the free market
| at work.
| yjftsjthsd-h wrote:
| The alternatives also use DRM, because licensing means
| that it's not a free market.
| kenjackson wrote:
| Why does licensing mean it's not a free market?
| HideousKojima wrote:
| It's not the licensing, but rather theat copyright is
| literally a government enforced monopoly on intellectual
| property that makes it not a free market.
| kenjackson wrote:
| Thanks. That makes sense.
| yjftsjthsd-h wrote:
| Because the vast majority of content is owned by a tiny
| number of copyright owners (studios, IIRC, but it doesn't
| really matter who, just how many), who then impose
| artificial constraints. Netflix didn't decide to
| implement DRM on its own, it passed through requirements
| that would be imposed on anyone else too.
| ForkMeOnTinder wrote:
| I love how this comment subtly acknowledges piracy is the
| only true unencumbered free-market choice.
| pixl97 wrote:
| Depending on what the definition of unencumbered is.
| Clicking on some link and getting your computer encrypted
| sounds like it's own means of encumbrance.
| dist-epoch wrote:
| Yes, if 90% of the market moves to piracy, the free
| market will indeed work and content producers will stop
| producing stuff.
|
| Or maybe they will all move to TikTok and live from
| advertising and you'll get a chance to complain about how
| you hate ads then.
| alpaca128 wrote:
| > leave for a better DRM-free service
|
| Which one?
|
| Is it a free market if 99.9% of companies copy the single
| most profitable approach to stay afloat (see
| smartphones), or the entire market is dominated by
| content rights holders that would make you pay license
| fees to use the toilet if they could?
| immibis wrote:
| the other commenter pointed out the only good DRM-free
| service is thepiratebay and the like
| cyberax wrote:
| > Like most ordinary folks, my threat model is the use of
| TPM for DRM.
|
| TPM is pretty much useless for DRM.
| dmm wrote:
| TPM/measured boot can provide proof that a DRM stack is
| in place.
| mjg59 wrote:
| In an abstract sense, yes, but were anyone to do that in
| a widely deployed manner there are fairly easy and cheap
| ways to circumvent it.
| immibis wrote:
| Such as?
| mjg59 wrote:
| Such as plugging in a TPM after boot and programming the
| PCRs however you want
| Nextgrid wrote:
| To be fair, firmware-based TPMs which are part of the
| CPU/SoC should be invulnerable to that?
|
| However, TPM-backed DRM on general-purpose OSes is
| impossible in the current world and is fear-mongering.
| The TPM can attest to a remote party that you've booted a
| certain OS, but this OS would need to maintain that chain
| of trust all the way for it to be effective. That's
| impossible due to the number of device drivers (which
| need kernel-level access by design) and various other
| privileged components a general-purpose OS requires
| (security software, etc), not to mention the attack
| surface of all that.
|
| For a hypothetical TPM-backed DRM to work, you'd need
| Netflix to ship you an entire OS image that you can boot
| (which the TPM will prove to them that you've booted),
| and that OS image needs to magically have all the drivers
| for every potential PC their customers might have, and
| you need to convince people to reboot their machine every
| time they want to watch it.
|
| This is all unnecessary considering the current status-
| quo of DRM is good enough, Widewine does not require a
| TPM and relies entirely on security by obscurity and it's
| considered good enough by the industry.
| mjg59 wrote:
| fTPMs are invulnerable to interposing attacks, but if you
| add a second TPM and program it as Windows (eg) would and
| redirect all remote attestation requests to that, the
| remote site has no way to know that this has happened.
| Nextgrid wrote:
| My understanding is that TPMs have vendor-embedded
| certificates/keys, so I guess eventually all discrete
| TPMs' keys will no longer be accepted by remotely-
| attestable services to protect against this attack - fTPM
| will be the only way.
|
| This is all theory though - workable TPM-backed DRM would
| require so much vendor cooperation, secure programming
| and break legitimate use-cases that it won't happen any
| time soon on conventional hardware. It would be cheaper
| for the media industry to just sell streaming boxes or
| exclusively target more locked-down platforms (iOS,
| Android) than try to make it work on generic Windows PCs.
| immibis wrote:
| > However, TPM-backed DRM on general-purpose OSes is
| impossible in the current world and is fear-mongering.
| The TPM can attest to a remote party that you've booted a
| certain OS, but this OS would need to maintain that chain
| of trust all the way for it to be effective
|
| Why don't you think that can work? Windows already limits
| drivers to ones signed by Microsoft - or else you have to
| be in "test mode" where - among other things - DRM-
| protected video playback is disabled!
|
| And Windows already contains a "protected media path"
| component which protects encrypted DRMed video data.
|
| Sure, there will probably be bugs in a drivers sometimes
| allowing for a signing bypass and then a DRM bypass if
| the DRM is done in software. Once they're discovered,
| those drivers will be blacklisted, and yes, that will
| mean you can't use that hardware. And the masses will
| blame the pirates.
| aseipp wrote:
| Using a TPM for remote attestation of device state is
| basically worthless in the generic PC UEFI world because
| there is pretty much unlimited surface area for holes to
| leverage, from motherboards that falsely report secure
| boot states to firmware bypasses to using your own TPM to
| just exploiting a vulnerable kernel driver that has a
| valid windows codesigning signature.
|
| In practice places that want "attestation-like"
| functionality, like Riot do for anti-cheat, just load
| mandatory kernel modules instead and require e.g. Type 1
| hypervisor-based security in Windows to be enabled. Or
| they just obfuscate everything and run blobs. These can
| still be bypassed but it's still difficult and in
| contrast fully controlled by their software stack, which
| is more usable for them for more players. It's good
| enough, in other words.
| immibis wrote:
| The TPM allows Hollywood to verify that you're running an
| Approved(TM) operating system. It's also very useful for
| WEI, which is web DRM - it allows Google to verify that
| you're running an Approved(TM) operating system and
| browser.
|
| Linux will never be approved, unless it's heavily locked
| down, by the way.
| mjg59 wrote:
| If it's that simple, can you point at a single example of
| Hollywood using the TPM for access control?
| immibis wrote:
| I forgot all new technologies spring out of the ground
| full-formed as soon as they are possible. They haven't
| done it _yet_. But look at Google 's WEI.
|
| You can also look at how any other DRM works. It's all
| based on hardware and software locks very similar to what
| TPMs do.
| mjg59 wrote:
| TPMs have been widely deployed for around a decade.
| Widevine doesn't use them - it makes use of the protected
| video path hardware built into the GPU or motherboard
| chipset.
| immibis wrote:
| As far as I know they only became mandatory with Windows
| 11, so give them a few years to become universal.
| aseipp wrote:
| That's a lot of words to say "I don't know."
| zorgmonkey wrote:
| For what it is worth google has fortunately abandonded
| the WEI proposal, a quote from the README of
| https://github.com/RupertBenWiser/Web-Environment-
| Integrity/ NOTE: This proposal is no
| longer pursued. Thank you for all the constructive
| feedback and engagement on the topic. An Android-specific
| API that does not target the open web is being considered
| here.
|
| The android specific proposal is only adding support for
| it to WebView, which developers actually could already by
| combining the WebView and play integrity APIs, so that as
| much as I don't love it that doesn't seem too terrible if
| it is just saving developers from writing some
| boilerplate code to connect the two. Here is the recent
| discussion about the WebView changes
| https://news.ycombinator.com/item?id=38118627
| mjg59 wrote:
| Netflix doesn't make use of the TPM.
| FirmwareBurner wrote:
| Yeah, but that goes to show you how limited in know-how
| people complaining about TPM are, and they keep spreading
| FUD like this and others keep buying it.
|
| And this is a supposedly tech focused platform where the
| tech literacy is at its highest. I wouldn't be surprised
| to read comments that TPM is used by Bill Gates to give
| you Covid.
| aseipp wrote:
| My rule of thumb is that I don't listen to anyone who
| can't write exploits for modern software stacks (OS
| kernels, browsers.) And even then, you can still ignore
| 50% of those people too, as they are cranks. In contrast,
| most of the people here in every one of these threads
| couldn't overflow an integer if you let them write the
| for loop.
|
| > I wouldn't be surprised to read comments that TPM is
| used by Bill Gates to give you Covid.
|
| One time on here, someone linked an academic paper
| describing an HTTP PCIe accelerator. One of the (eight)
| authors was from Tsinghua, and so naturally someone in
| the comments started freaking out about how this was a
| plan by the Chinese Deep State to fund this for mass
| surveillance. When I asked him how this would work and
| what threat he expected, he described an elaborate Tom
| Clancy plotline where these PCIe cards will actually be
| snooping every key exchange, keeping them in memory, and
| they would be secretly equipped and manufactured with
| short wave radio devices that would allow Chinese agents
| to "exfiltrate private keys" (whatever that means) by
| posing as janitors and technicians in the datacenter and
| beaming those radio messages to them.
|
| That was his threat model for "thing you literally plug
| into your fucking server and put on a shared memory bus."
|
| Now, how this is expected to work when most HTTP
| accelerators don't do key exchange (and never ever see
| long term keys), or how these keys would benefit them
| when presumably many encrypted comms do not go through
| cables controlled and spliced by the nefarious, evil-
| loving CCP -- well, that's left as an exercise for you!
| immibis wrote:
| It will when every system has a TPM.
| rnhmjoj wrote:
| It doesn't need to be the NSA; if your chip is vulnerable and
| exploits published online I don't think it's too far fetched
| that a resourceful thief could try to unlock your disk if he
| thinks it has valuable content (bank accounts,
| cryptocurrency, passwords, etc.)
|
| Why take unnecessary risks when you can just use GRUB+LUKS
| and type the passphrase at boot?
| Nextgrid wrote:
| GRUB+LUKS can also have exploits published online? If that
| happens, you upgrade to a newer version.
|
| TPM is the same - any known vulnerabilities would generally
| get patched as part of firmware updates released by your
| vendor.
|
| If the TPM is known vulnerable and a patch doesn't exist
| then fair enough you can stop using it depending on your
| threat model, but the same can be said for software
| implementations.
|
| > when you can just use GRUB+LUKS and type the passphrase
| at boot?
|
| This is a user experience drawback and opens you to other
| avenues of attack like passphrase bruteforce if you don't
| choose a strong (and inconvenient/slow to type) one. It's
| also impossible for servers or embedded devices which you
| want to be able to boot unattended.
| rnhmjoj wrote:
| > TPM is the same
|
| It's not really: LUKS is an open standard and GRUB is a
| free software that implements it. With a TPM you're
| likely to get a chip that is 100% a black box, with the
| exception of a few people who signed NDAs and researches
| that have knowledge and tools to poke into it.
|
| > generally get patched as part of firmware updates
| released by your vendor
|
| If it can even be fixed with a softwar update. Also,
| you're very lucky to get maybe a couple of years of
| firmware updates, then your're on your own.
| Nextgrid wrote:
| > with the exception of a few people who signed NDAs and
| researches that have knowledge and tools to poke into it.
|
| This is good enough for the 90% of people who currently
| operate without full-disk-encryption at all. It would be
| a huge improvement.
|
| Obviously, it's up to each individual user to evaluate
| their threat model and proceed accordingly. Nobody is
| _forcing_ you to use a TPM, you can still use LUKS /etc
| and completely ignore the TPM.
| chlorion wrote:
| That's not really true all of the time, some AMD fTPMs
| have physical vulnerabilities for example, that allow
| compromising the entire thing with some tools and a few
| hours of time. Software can't fix this since it's a flaw
| in the hardware itself, you'd need to buy new hardware to
| fix this.
|
| https://arxiv.org/abs/2304.14717
| SenpaiSilver wrote:
| How is the TPM protecting my if my laptop with the TPM chip
| is stolen?
|
| I understand that I will be protected from removing the
| HDD/SSD and putting it into another machine to read the data,
| but does it really protect me from anything else?
| sokoloff wrote:
| What other protections might you expect it to provide?
|
| Being unable to retrieve the data on protected drives
| (which could include cookies, passwords, ID, photos/videos,
| etc.) _is_ the value.
| mjg59 wrote:
| Preventing your storage from being put in another device is
| what it's meant to be protecting you against. If it's still
| in the original device then an attacker is still blocked by
| your login password.
| huggingmouth wrote:
| No, the true question is why should we switch to tpms, and
| what are we giving up if we do.
|
| In my experience, tpms are worse than worthless since they
| prevent rescuing garddrives from bricked systems. Nontpm luks
| can be unlocked on any system.
| Bognar wrote:
| I'm always curious what threat model that is valid against
| TPMs is not also valid against CPUs and main memory.
| traverseda wrote:
| Or anyone with a pcileach.
| dist-epoch wrote:
| Because the alternative, not using SecureBoot, is strictly
| worse in all scenarios.
|
| Just like HTTP vs HTTPS with LetsEncrypt. Even if an attacker
| can compromise a web-server rendering HTTPS protection useless,
| it's still better to always use HTTPS.
| immibis wrote:
| You're framing this as a choice between SecureBoot and
| InsecureBoot, but it's actually a choice between SecureBoot
| and DRM, or InsecureBoot and no DRM.
|
| Besides, SecureBoot isn't strictly better in all scenarios.
| The most obvious one is the one where you forgot how to log
| in, and want to retrieve your data.
| lxgr wrote:
| > [...] where you forgot how to log in, and want to
| retrieve your data.
|
| That's a use case typically better addressed with good
| backups, since there are indeed more failure modes when
| using effective full disk encryption.
| dist-epoch wrote:
| > choice between SecureBoot and DRM, or InsecureBoot and no
| DRM.
|
| That's just false. I've had SecureBoot enabled for 10 years
| and I didn't have more DRM because of this.
|
| You're talking hypotheticals, slippery slope, etc...
|
| > The most obvious one is the one where you forgot how to
| log in
|
| SecureBoot is separate and does not imply full disk
| encryption. If you choose to use full disk encryption, yes,
| you can be locked out, with SecureBoot or not.
| immibis wrote:
| > I've had SecureBoot enabled for 10 years and I didn't
| have more DRM because of this.
|
| Maybe stop pretending to understand what the parent
| comment is talking about.
|
| > SecureBoot is separate and does not imply full disk
| encryption. If you choose to use full disk encryption,
| yes, you can be locked out, SecureBoot or not.
|
| There's no purpose to Secure Boot if I can just put your
| hard drive in a different computer without Secure Boot.
| dist-epoch wrote:
| > There's no purpose to Secure Boot if I can just put
| your hard drive in a different computer without Secure
| Boot.
|
| There are scenarios where you can't take the hard drive
| out (evil maid attacks, public computers, ...).
|
| But regardless, you are attacking SecureBoot with an
| argument against full disk encryption.
| fsflover wrote:
| > TPM chips are not opensource
|
| I'm using Librem 14 with a TPM chip with exclusively free
| software.
| cedws wrote:
| This feature isn't really for people like you and me. It's for
| big companies like Red Hat and Google to utilise on their
| servers. Google have their own TPMs they can trust. Red Hat
| probably have the paperwork to say their TPMs are safe.
|
| But worrying about your TPM being backdoored is pointless
| anyway. If they can backdoor your TPM, they can backdoor
| anything.
| immibis wrote:
| > If they can backdoor your TPM, they can backdoor anything.
|
| [citation needed]
| cedws wrote:
| There are hundreds of components in a computer and the TPM
| would be one of the hardest to backdoor. Bear in mind where
| this stuff is manufactured. The manufacturer would want
| nothing to do with funny business like this because it
| could harm their sales, so it would have to be done under
| their nose, or they would have to be compelled by the
| government.
|
| US intelligence agencies don't generally go around mass
| backdooring things. It's too risky. They carefully target
| their attacks.
| immibis wrote:
| It's... extremely easy for the government to compel mass
| backdoors in TPMs. Don't you remember Clipper? And the
| backdoor would be completely invisible until they used
| it, since TPMs aren't auditable.
| kenjackson wrote:
| But it's easy for governments to compel backdoors into
| any component. Even open source for non trivial code is
| easy to introduce obscure bugs that are exploitable.
| immibis wrote:
| The backdoor in most components is really complicated.
| Backdooring a TPM is relatively easy, and undetectable.
| sangnoir wrote:
| > [citation needed]
|
| Picture-of-a-Cisco-router-getting-a-hardware-implant-
| installed-after-being-indicted-during-shipping.snowden-
| files.jpg
| mjg59 wrote:
| How would an end user simply check them for backdoors if they
| were open source? Security auditing is a skilled job, and the
| people best capable of identifying security flaws or backdoors
| are generally able to do that given a binary blob as well.
| JohnFen wrote:
| I dislike TPM personally (for a very different reason), but...
|
| They reduce the attack surface. Not only in terms of the actual
| interface, but in terms of who has the ability to subvert the
| security. Using TPM may or may not be effective security
| against governments, manufacturers, and the like, but they are
| effective security against a whole host of other bad actors.
|
| It could be argued that's still a worthwhile improvement. You
| can engage in other layers of security regardless of whether
| TPM is being used to help cover the areas TPM may not.
| immibis wrote:
| They're dangerous because the same effective security can be
| turned against the legitimate owner of the machine. The TPM
| effectively belongs to whoever configured it first.
| JohnFen wrote:
| TPM just stores crypto keys. It does so in a way that the
| user can't get them, which is my objection to the scheme
| (because it lets entities set up encrypted channels that I
| can't monitor).
|
| However, that's the only way it can be turned against the
| user, and the other user security gains are real.
| azzentys wrote:
| I'm curious if open source TPM would mean easier side-channel
| attacks. What's the reason everyone is super hush-hush around
| how their Hardware Security works?
| badrabbit wrote:
| Because it isn't a silver bullet but rather a countermeasure
| against rootkits, bootkits and certain physical tampering by
| regular and insider threat actors.
| chlorion wrote:
| This is very important.
|
| For some reason in these threads nobody seems to bring up or
| realize that modern AMD CPU's fTPM is completely broken and not
| fixable via ucode updates. The AMD TPM exploit is exploitable
| by a "regular" person too, it doesn't have to be a state level
| actor, just some techy person with a few tools and physical
| access to the system.
|
| We can't audit these things at all and I don't think we should
| just trust that they are safe, and we know for a fact that many
| of them _aren 't safe_, even against "regular" threats.
|
| (AMD fTPM exploit source) https://arxiv.org/abs/2304.14717
| mkopec wrote:
| Dropping a link to a project attempting to create a fully open
| source TPM: https://twpm.dasharo.com/
| sweetjuly wrote:
| No ASIC is ever going to satisfy your desire to audit. Even if
| they publish the RTL, you can't verify that this is what they
| synthesized, that this is what the fab actually produced, etc.
| You have to trust hardware because it's your everything. Even
| with relatively obvious attacks like backdooring the bootrom
| (which can be done by modifying just the metal layers!),
| practically speaking no one is going to ever catch it because
| modern processes are simply too fine for all but the fabs
| themselves to physically inspect. This isn't even to mention
| more clever attacks which attack the doping of the silicon [1]
| for individual transistors (which cannot be generically
| detected post fabrication by any publicly known technique).
|
| Embrace the suck :) Sure, you can't truly trust hardware, but
| there's nothing to be done about it anyhow and so you may as
| well reap the benefits of trusting it.
|
| [1] http://sharps.org/wp-content/uploads/BECKER-CHES.pdf
| JohnFen wrote:
| > there's nothing to be done about it anyhow and so you may
| as well reap the benefits of trusting it.
|
| Alternatively, you can avoid relying on any single thing to
| be secure and use layered security approaches instead.
| mongol wrote:
| I think the topic of Lennart's talks usually is very interesting
| but his delivery assumes the audience knows much more about the
| subject than I do, at least. Most other talks I watch I have an
| easier time to follow.
| mqus wrote:
| Do you have an example for stuff that the audience is expected
| to know? Or the other talks that do a better job? What kind of
| background do you have? Assuming an average full stack dev, of
| course he addresses a different audience, since this is a talk
| addressed to Linux OS developers at a conference with the
| description:
|
| "All Systems Go! is a conference focused on foundational user-
| space Linux technologies. Its goal is to provide a gathering
| place for both contributors and users of projects that make up
| the foundation of modern Linux systems."
|
| So, summing up: maybe you are not part of the target audience?
| esjeon wrote:
| I think this one is especially worse, because TPM is a piece of
| _hardware_ and is for _security_. The combination of the two
| alienates a lot of software engineers, like >90%. I've never
| met anyone in real-life who already knew how to use TPM, though
| many do know what it is and what it's for.
|
| So, it's really a bad (or s**ty) topic to talk about in front
| of an unsuspecting audience, but certainly there are people who
| would appreciate the work, especially in embedded/robotics
| fields (which have been rising slowly for a long time).
| Arnavion wrote:
| The vidoes are mostly a condensed form of the blogposts he's
| been writing on these topics (filesystem layout / Boot Loader
| Specification / Secure Boot / Measured Boot / Unified Kernel
| Images) for a couple of years now, so you can read those if you
| prefer.
|
| https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-...
|
| https://0pointer.net/blog/the-wondrous-world-of-discoverable...
|
| https://0pointer.net/blog/authenticated-boot-and-disk-encryp...
|
| https://0pointer.net/blog/fitting-everything-together.html
|
| https://0pointer.net/blog/brave-new-trusted-boot-world.html
|
| https://0pointer.net/blog/linux-boot-partitions.html
| shrubble wrote:
| Not just no, but heck no! TPM will never be auditable, and
| therefore can never be considered trustworthy.
| chlorion wrote:
| Just a heads up for anyone using AMD CPUs fTPM, it is completely
| broken and cannot be used even for "someone stealing your
| laptop".
|
| A few hours time and a few tools can fully compromise the TPM's
| secrets. This can be performed by anyone who has a little
| experience tinkering with electronics, someone who can use a
| soldering iron for example can almost certainly pull this off.
|
| From my understanding all of the "zen" CPUs are effected except
| for maybe the very most recent models.
|
| https://arxiv.org/abs/2304.14717
___________________________________________________________________
(page generated 2023-11-05 23:00 UTC)