[HN Gopher] Fixing the TPM: Hardware Security Modules Done Right
___________________________________________________________________
Fixing the TPM: Hardware Security Modules Done Right
Author : todsacerdoti
Score : 20 points
Date : 2023-08-18 19:22 UTC (3 hours ago)
(HTM) web link (loup-vaillant.fr)
(TXT) w3m dump (loup-vaillant.fr)
| motohagiography wrote:
| It's an important topic, but the basic tradeoffs with TPMs and
| HSMs are that either you, a) trust the vendor is generating root
| secrets with sufficient entropy, whether they are a private key
| or a symmetric secret, b) you trust the personalization process
| for replacing the OEM secrets with personalized ones, or c) you
| trust the firmware to not yield the unique secrets you generate
| in it.
|
| There are issues with all of these, but it's a question of in
| which security context you are generating your root secrets and
| keys. e.g. at manufacture, at personalization, or whenever the
| end user wants to. The catastrophic failure mode of TPM's
| depending on shared root secrets may actually be a privacy
| feature, imo, because in all the digital identity work I have
| done, this was where every scheme fell over.
| hsbauauvhabzb wrote:
| Even if flawed, it can still act as a safety in numbers game.
| You have to be able to abuse TPM _and_ be in a position to do
| so, in the context of fde, even a flawed tpm v1 approach stops
| 90% of potential threat actors capable of abusing an
| unencrypted device.
| motohagiography wrote:
| A solution that was rarely implemented was batch keys, where
| your secrets installed by the OEM were diversified somehow so
| when attackers eventually extracted your TPM secrets from one
| device, it would not compromise all devices. It still has a
| terrible and unacceptable failure mode when peoples lives
| depend on it, but for infrastructure, I think the risk is
| more managable.
| Pxtl wrote:
| I'm not an encryption guy so maybe this is a stupid question, but
| doesn't this mean you can't update the firmware without losing
| all your encrypted data?
| loup-vaillant wrote:
| Yes, and no.
|
| If you lose the firmware entirely you would indeed lose the
| derived decryption keys. But if you _keep_ the firmware
| somewhere safe (or even fetch it again from wherever you got it
| first), then loading it again would derive the same keys, and
| you can decrypt your stuff again.
|
| This makes reproducible builds very important by the way: if
| you rely on a source control system to hold on to old versions
| of the firmware (just in case someone needs it to decrypt old
| files), you really really want a way to re-generate the same
| binary blob from the same source code.
| dblitt wrote:
| Related from 11 months ago:
| https://news.ycombinator.com/item?id=32896580
| jerhewet wrote:
| I'm in the minority on this, but I want BIOS to make a comeback.
| I don't want TPM, or any of the rest of this broken garbage. Just
| let me boot my OS, and get the fuck out of my way...
| jeroenhd wrote:
| This reads like "the full TPM spec is too complicated for my use
| case, so I made my own TPM for my personal use case". That's not
| fixing TPM, that's inventing your own, custom TPM, that only
| works for a subset of the intended audience of the thing you're
| replacing.
|
| It's like replacing all private cars by bikes and public transit.
| This solves the pollution problem, the traffic casualties
| program, and would solve transportation for the vast majority of
| people traveling on the road. It doesn't solve some niche use
| cases, like "trucks" or "construction work", but those are just
| bloat almost nobody needs in the first place, right?
|
| From this description, Tillitis sure seems like a good
| alternative for TPMs. However, there's no Tillitis chip in my
| laptop or my desktop, but I do have a TPM. Things like SSH and
| PGP are already implemented. Tillitis isn't very interesting to
| me in its current state as advertised in this article.
| loup-vaillant wrote:
| Author here. Did you miss the part where users can load
| arbitrary programs into the "new custom TPM"? If we can do
| that, solving all use cases for all users is very easy: just
| write the appropriate program whenever a new use case pops up.
| This is not supporting a subset of current users, this is
| supporting _all_ users. Every last one of them.
|
| Believe me, given the current complexity of the TPM 2.0
| interface, writing a custom program for any single use case is
| not any harder than wading through the current TPM
| documentation. Given suitable crypto libraries I'm guessing
| it's quite a bit easier in most cases.
| JohnFen wrote:
| Hmmmm...
|
| I could not care less about Microsoft's problem, but could this
| approach fix the major problem that I have with TPM?
|
| TPM allows software to leverage my machine against me. If DICE
| allows me to revoke keys that have been stored for other
| applications (or, even better, to prevent the HSM from being used
| by anything without my overt permission), that might go a long
| way toward reducing that issue.
| DistractionRect wrote:
| Similar sentiments, I'm already seeing this with Android and
| custom roms.
|
| Right now you get away with spoofing basic integrity checks,
| but custom roms cannot pass hardware attestation. It's not a
| hard requirement right now in order to maintain backwards
| compatibility required to target 90%+ of android devices, but
| give it a few generations and it will be. At that piont I
| expect a majority of apps will simply be unusable on custom
| roms, and we'll have no choice but to embrace planned
| obsolescence.
| jeroenhd wrote:
| A device that can't watch Netflix in HD isn't "unusable". If
| your bank complains about custom ROMs for wireless payments,
| the exact same feature can work perfectly fine with your bank
| card (better even, in some cases).
|
| I'm quite annoyed that I can't watch HD movies on my phone
| but it's not as if I should toss it into the bin now.
| AnthonyMouse wrote:
| > custom roms cannot pass hardware attestation.
|
| So this is going to be the interesting question, because
| obviously they can, they just have to extract the keys from
| something first. Devices are made by all kinds of vendors and
| it only takes one vulnerability before you have a market for
| keys. There are <$200 phones, those cheap phones are _more_
| likely to have a vulnerability, and when one of them gets a
| cracked screen the market value drops to near-zero which
| makes it cheap to buy one to extract the key.
|
| Which is also why remote attestation is totally worthless. An
| attacker can do the same thing, so relying on the attestation
| is completely insecure because in practice anyone with a
| couple bucks will be able to spoof it.
|
| But if extracting a key is mildly inconvenient or legally
| questionable, it will be enough to deter honest casual users
| but not profit-motivated attackers, and you get the worst of
| both worlds.
|
| So we need to do everything to make sure that doesn't happen.
| One way is to make extracting keys as easy as possible, of
| course.
|
| Another is to make sure that everybody understands the
| perversity of this nonsense. It's snake oil the likes of
| export-grade encryption or EV certificates. Anyone caught
| using it should be mocked mercilessly and added to a list of
| disfavored vendors with uninformed security staff. Anything
| in a position to do so should warn if anything attempts to
| use it, or disable it to make it more difficult for anything
| else to rely on its availability. Warnings should emphasize
| that using it is a security risk that can enable hard to
| detect malware and is an indication of malice or
| incompetence.
|
| It needs to go away.
| lostmsu wrote:
| The keys would just be revoked and the cheap phones you got
| the keys from would no longer pass attestation either.
| AnthonyMouse wrote:
| You don't tell them which keys you extracted. If they
| have to revoke every phone of that model then lots of
| normal users have them and vendors can't rely on people
| having phones that support it anymore, so good.
|
| And the attacker doesn't care if the key gets revoked
| _after_ they 've stolen your money.
| JohnFen wrote:
| That issue with Android is what made me decide to give up
| smartphones. I cannot adequately secure a phone without
| installing a custom ROM (and even then, it's iffier than
| ever), and the integrity/attestation checks make custom ROMs
| very problematic.
|
| So, once my smartphone dies, I'll be switching to a
| dumbphone.
| mrd3v0 wrote:
| You should take a look at GNU/Linux mobile operating
| systems every once in a while. They're making great strides
| and both popular GUIs KDE and GNOME have been working on
| making mobile a target in their ecosystems.
|
| Fairphone comes with a five-year guarantee for repairs and
| parts, so none of that early planned obsolescence, and it
| works with all the Linux mobile distributions I have had my
| eyes on.
| euniceee3 wrote:
| Even then you are yellow booting and that is another
| security issue.
|
| What dumbphones you looking at? Everything retail I am
| seeing is a stripped down version of Android.
| jeroenhd wrote:
| > to prevent the HSM from being used by anything without my
| overt permission
|
| That sounds quite doable? Basic sandboxing
| (flatpak/snap/whatever) and not assigning the tss group to
| system daemons will do that for you.
| EMIRELADERO wrote:
| How does that solve the issue, exactly? Apps could simply
| refuse to run, and platforms refuse to provide you with
| service, if you don't accept their keys in your TPM.
| loup-vaillant wrote:
| Sorry, a DICE-enhanced TPM would be just as evil as a regular
| TPM I'm afraid. You can think of DICE as giving you a gazillion
| TPMs for the price of one actual TPM, one per program you care
| to load. What would happen is, your bootloader would just
| inject the standard Treacherous Computing(tm) firmware into the
| TPM, and since its keys is tied to it being what it is, in the
| end you end up with a regular Treacherous Platform Module, same
| as today.
|
| I would _love_ to stop programs from using my TPM against me,
| but I'm afraid DICE isn't it.
___________________________________________________________________
(page generated 2023-08-18 23:00 UTC)