[RFC 1/2] Add support for openssl engine based keys

[James Bottomley]

On Fri, 2017-11-03 at 19:10 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> I hear you (finally).
> 
> Do you know why TCG moved towards what I consider a regress, i.e.,
> reducing the number of on-board keys?

Well, I'm not associated with the TCG, so I can't tell you officially,
but I believe the reason was that they wanted to mandate a standard
size in 2.0, because there were huge inconsistencies in 1.2 over the
number of keys that could be stored, and couldn't agree on it (because
the ram increases the cost of the chip so the OEMs didn't like it).
 Finally they decided that if they couldn't agree a standard size,
they'd specify the minimum required for operation, which is 3 keys, and
make a virtue out of necessity.

James

> As for loading keys onto PKCS#11 tokens – for PIV and such OpenSC
> served me just fine. ;)
> Not that I really used that capability a lot…
> --
> Regards,
> Uri Blumenthal
> 
> On 11/3/17, 14:53, "James Bottomley" <James.Bottomley at HansenPartnersh
> ip.com> wrote:
> 
>     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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev