On Fri, 2017-11-03 at 16:49 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > What I’m saying is that TPM should be able to behave like a PKCS#11 > token. Loading TPM keys is similar to provisioning a PKCS#11 token > (and hopefully needs to be done as rarely). The normal use of a TPM > seems to be operating on the keys already installed – rather than > loading keys in every time you need to do something. I believe I've said several times now: TPM 1.2 can because it can store keys internally, so can act like a token if you load it up. TPM 2 cannot because its internal key space is very limited so the key has to be loaded used and immediately unloaded then reloaded on the next use. Thus for TPM2 you *always* require the file representation. Even for TPM1.2, the file use case is better because it allows infinite scaling of the engine and allows use by many users. Even for TPM 1.2 there are a finite number of keys you can load and once it's full, no- one else can use it in the PKCS11 model, so it doesn't scale to cloud use cases. It's probably helpful if you think of TPM as an engine. TPM 1.2, thanks to a reasonable amount of RAM, is an engine that can behave like a token, but TPM 2 can only behave like and engine. > TPM, like other hardware tokens, was designed for storing things > (keys) internally. No, it definitely wasn't: that's actually partly why the TCG deliberately reduced the key capacity to render this impossible in TPM 2. > And you can load keys onto PKCS#11 tokens (if you configure them so > – that’s a policy issue rather than a technological limitation). It's a technological limitation because there are no general tools for doing so: The API covers it but in a very piecemeal way which is why no-one can write a general tool. James _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
