userbinator a year ago

The bad news is, there’s an entire set of features for state attestation we haven’t covered in this post.

The worst news is, the horrible dystopia of remote attestation which is coming unless there's a strong opposition, much stronger than what Intel faced with putting serial numbers in processors back in 1999.

  • cryptonector a year ago

    Yes. This is great for enterprise, but for consumers it's a mixed bag (see elsewhere in this thread).

cryptonector a year ago

> For privacy, keys generated from seeds such as the EK and SRK can only decrypt, they can’t sign.

Hmm, well, maybe it's for privacy, but there is no privacy benefit to that since one can always do a two round trip proof-of-possesion protocol. (One can also do it in one round trip given a platform and/or EK certificate that proves authenticity of the TPM, if one trusts that proof.)

There is a key hygiene reason to have keys that are decrypt-only or sign-only, but not both.

In any case, it's accurate that primary keys are decrypt only, and the EK is not just decrypt-only but also restricted. Also, it's decrypt-only, but they can be ECC keys (i.e., RSA is not the only supported algorithm for primary keys), in which case encryption to an ECC public key is just generating an ephemeral key, deriving the shared secret, deriving symmetric encryption keys, encrypting, and sending the ephemeral public key and the ciphertext (decryption is similarly straightforward).

kurnoolion a year ago

This may be dumb question, but is the parent/child key relationship defined such that parent key wraps the child key?

  • cryptonector a year ago

    Not a dumb question!

    The "TPM 2.0 Library part 1: Architecture" spec[0], section 23.2, describes the hierarchical relationships between objects.

    A child of a derivation parent is derived from the parent, and can be re-derived as needed, therefore it doesn't need to be wrapped. A child of a storage key is wrapped in [a symmetric key derived from a seed associated with] that key.

    There are also two cryptographic names for each object, one that includes the parent's cryptographic name in the child's name, and one that does not.

      [0] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf
    • cryptonector a year ago

      I should add that the main reason for this distinction between derivation and storage parents is that for keys generated on the TPM where you find them you just don't have to wrap those keys when you generate them as derived from [ultimately the hierarchy's seed] and a template, but that option is not available when importing keys generated elsewhere. The latter is called 'key duplication'. An entity can create a TPM2_Duplicate() [0] output payload encrypted to a TPM's key that the TPM can then TPM2_Import() then TPM2_Load(), and then that key at that target TPM cannot have a derivation parent since it isn't derived from any key on that TPM, therefore the only way to keep it around is to wrap it in some other key on that TPM, and that's where the storage keys come in.

        [0] In software, or on another TPM where the
            key being duplicated is not fixedTPM and
            fixedParent.  Yes, one can generate keys
            on a TPM that can be extracted or sent to
            specific other TPMs, or not at all, at
            the user's choice.  Which means that one
            can set up a ring of TPMs to hold a given
            key, for example.  I.e., TPMs can
            function as HSMs.
cryptonector a year ago

I've written a tutorial on TPMs. One thing I really recommend is thinking of "credential activation" as something rather more general: encryption to a public key but with an arbitrary authorization policy that will be enforced by the holder of the private key (the TPM).

The credential activation primitive was intended for sending things like certificates to targets such that they could recover them IFF they could satisfy some policy, and thus the name "credential activation". But the "credential" needn't be a "credential" -- it can be anything at all.

TPM2_MakeCredential() takes a public key, a cryptographic name of an "activation object", and a plaintext payload, and produces a ciphertext that will be decrypted by TPM2_ActivateCredential() IFF the caller of TPM2_ActivateCredential() has access to the private key object matching the public key argument to MakeCredential and access to a key object that has the same cryptographic name as was used as the activation object by the caller of MakeCredential. The key is that the cryptographic name of the activation object binds its attributes including any authorization policy. Note that the private part of the activation object is not used at all in the process, only its cryptographic name. And TPM authorization policies are extremely flexible.

To recap: to decrypt the ciphertext, the caller of TPM2_ActivateCredential() has to satisfy whatever authorization policy was specified by the sender or otherwise agreed upon ahead of time.

Trammell Hudson figured out that TPM2_Duplicate()/TPM2_Import() can be used to produce much the same asymmetric encryption with TPM-enforced policy for decryption.

The fact that a device as resource-constrained as a TPM can enforce incredibly complex authorization policies is astounding and fascinating, and ultimately comes down the fact that TPM 2.0 extended access policies are Merkle hash trees, so that at any point in policy evaluation a TPM need only have a fixed amount of state + enough memory to evaluate one node of the policy.

TPM is a very large topic. When explaining TPMs to people I like to first cover substance[0] at a very high level, then form[1], then really dive into substance: PCRs and event logs, how all keys created on a TPM are created deterministically from the key's hierarchy's seed and a caller-supplied template (which can include entropy), then cryptographic names of keys, then authorization policies, then finally TPM2_MakeCredential()/TPM2_ActivateCredential(), then TPM2_Quote(), and finally how to put together cryptographic protocols using a TPM.

  [0] Some of what all you can do with a TPM.
  [1] That it's all request/response commands,
      that it has a micro-TLS protocol embodied
      in one of those commands, that it is a
      mostly-stateless protocol with encrypted
      state cookies.
  • amluto a year ago

    > I've written a tutorial on TPMs.

    Is it available? Do you have a link?

    • cryptonector a year ago

      https://github.com/tpm2dev/tpm.dev.tutorials/tree/master/Int...

      I have learned a fair bit since I wrote it, so I should probably edit it. If you read it and have feedback, feel free to open issues against it or comment here.

      BTW, I highly recommend https://tpm.dev/! It's a fantastic community of TPM users and developers, and a great resource for newcomers.

      • amluto a year ago

        Nice!

        I spent some time a few years ago working with TPM 1.2, but I haven’t caught up on the massive changes in 2.0.

        (I was not impressed by the state of the 1.2 ecosystem. I may have had some choice words for the TSPI APIs and the trousers stack. The C APIs were trying to give gets a run for its money.)

        • cryptonector a year ago

          Thanks for taking a look!

          TPM 1.2 is not very good. TPM 2.0 is pretty impressive.

          I'm also not impressed with the tpm2-tools project. But there's a fair bit of code out there.

          The neatest thing about TPM 2.0 is its extended access policies, and how blockchains (before they were called that), and encrypted state cookies (and key derivation templates) all adds up to letting one make do with the very limited memory resources that a TPM has.

          I'd really like a high-performance, HSM-like, TPM. Or a high-performance HSM with a TPM 2.0 interface.

cryptonector a year ago

> For reasons, creating keys under the Endorsement hierarchy can be fidgety

There are four key hierarchies:

- the platform hierarchy, which exists mainly so that OEMs can create keys under it that they certify

- the endorsement hierarchy, which exists mainly for the EK, which is certified by the TPM manufacturer

- the storage hierarchy, which is meant for the owner of the system

- and the null hierarchy, which is meant for really ephemeral keys as the null hierarchy's primary seed is randomly generated each time the TPM starts (rendering all primary keys created on the null hierarchy useless after each reboot)

The keys certified by the platform and TPM manufacturers can be used to identify the system, so they are considered privacy-sensitive, which is why then the storage hierarchy exists: the user can change its primary seed at any time and create keys for the user's use.

A typical use of the storage hierarchy is to enroll a host using its platform and/or EK certificates, proving possession of their private keys and proving the platform's and/or TPM's legitimacy, then certifying (or whatever) public keys in the storage hierarchy. Once you have done this you can in principle lock the platform and endorsement hierarchies out so that applications cannot identify the user through them.

An operating system is free to do just that: set controls on the PH/EH that make it impossible to use them post early boot.

This attempt at privacy protection may or may not work for consumers though. Pressure to have attestable systems will mean that the OS vendor will want to enroll consumer devices so as to be able to provide apps with keys they can use. OS vendors will be able to control how much privacy the consumer gets, and maybe they will provide the user with decent privacy protection, and maybe not. Basically, I can see an OS certifying a different key per-{device, app} (under the storage hierarchy) so that apps may use _a_ key for attestation, but that key can be used for identification too, even if it's different for each application, as long as it is reused. So OS vendors will really have to certify new keys for apps frequently.

Anyways, the "fidgety" reason that you might want to create keys under the SH rather than the EH is precisely that the OS might not let you have any access to the EH. You might only get to use the SH. You could leave the choice of hierarchy up to the user, but chances are they won't have a clue how to make that choice. Or you could try the EH then the SH if the EH is not available. Depending on what you're up to, it may not matter much. For enterprise systems you can make sure that you have access to the EH, so you might use the EH (though if you ever want to send a system back to a vendor, or sell it, you might want to be able to change the chosen hierarchy's seed, but if you change the EH's seed, then you render the EK certificate useless, which would render that TPM useless to anyone else, but then, you might not ever resell your used equipment).

Another reason is that changing the primary seed of the PH or EH should only be done when one has first created useful keys under the SH, otherwise one can never again be able to establish the authenticity of the TPM after changing the EH seed, or the platform after changing the PH seed. But one can change those seeds, and some might in an attempt to add some privacy protection, but then any keys under those hierarchies will no longer be accessible. This mostly shouldn't happen, so it's not much of a reason.

  • cryptonector a year ago

    As usual, consumers will have to fight for their privacy. It's not like they can't have it. It's possible to have device state attestation and privacy relative to the 3rd parties that device state is attested to, but only via a mediator that the user and those 3rd parties trust. Who would be that mediator? An attestation service like that will cost some money to provide and run. Consumers will have to pay for it somehow, either in the price of their devices or, more likely, with data, but paying with data == no privacy. Meanwhile those 3rd parties will get a say regarding small platforms (and most likely they'll say "no"), so only the big players might get to play.

cryptonector a year ago

I really like TPM 2.0, so I love seeing good blogs about TPMs!