Blumenthal, Uri - 0553 - MITLL
2017-Nov-03 16:49 UTC
[RFC 1/2] Add support for openssl engine based keys
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.
TPM, like other hardware tokens, was designed for storing things (keys)
internally. And you can load keys onto PKCS#11 tokens (if you configure them so
? that?s a policy issue rather than a technological limitation).
--
Regards,
Uri Blumenthal
On 11/3/17, 12:33, "James Bottomley" <James.Bottomley at
HansenPartnership.com> wrote:
On Fri, 2017-11-03 at 14:34 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> >> Let me rephrase my question: what does using OpenSSL
> engines enable
> >> that we can't already do via PKCS#11?
> >
> > It allows you to use the TPM2 as a secure key store,
> because there's no
> > current PKCS11 code for it.
> >
> > The essential difference is that Engine files are just
> that: flat files
> > where the key is stored in a form only decodeable by the
> engine.
> > PKCS11 tokens are supposed to be represented by tokens
and
> slots which
> > is an active entity storing the key. So, provided I wrap
> it correctly,
> > I can create a TPM representation on one system (I have
to
> know one of
> > the hierarchy seeds on the target) transfer the file to
> the target
> > system and use it;?
>
> What I don?t get is ? why not transfer those keys to the target
> machine ?somehow?, load them to the TPM there ?somehow?, and then
> treat TPM as a PKCS#11 device?
You can always make a process more complex than necessary. For Engine
files, the somehow already exists (it's the file which you transfer
using existing techniques for transferring files, which are well
understood) for the PKCS11 method, the somehow depends on the token and
for a lot of tokens the assumption is locality is secure, so there's no
secure remote update mechanism.
> If there?s no PKCS#11 ?driver? for TPM ? then that?s what needs to be
> added, IMHO.
OK, let's do a thought experiment: if you advocate for using PKCS11
tokens instead of flat files, you should presumably want this for the
ordinary ssh key files as well (we can easily construct a software
pkcs11 token to handle them ... again, it's what gnome-keyring has
already done, so an exemplar exists). Now in ssh, you only have one
option in ssh-add: the token shared object and you can only specify one
password for each token shared object, so you'd need a way of
constructing one token shared object for each key in the directory
(because they could all have different passwords). We'd need some
build infrastructure to rebuild the token shared objects each time a
key were added or changed. Presumably the shared object would be named
similarly to the existing keys, so you don't get confused, so you'd
do
ssh-add -s /home/jejb/.ssh/id_rsa.so
instead of
ssh-add /home/jejb/.ssh/id_rsa
And by the time I've done all the above, I'm back to what I had
originally (plus a load of complexity): It's pretty much the
engineering equivalent of applying sufficient force to get the round
peg into the square hole.
The reason it's such a pain is that PKCS11 is designed for active
"things" which store keys internally. The file method (either
engine
or PEM) is for passive files that can be decoded by something (either
the internal openssl method or the engine) either can be used for the
other's use case (with sufficient glue) but the result is very messy if
you don't do internally stored keys via PKCS11 and file based keys via
file mechanisms.
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171103/3a516796/attachment.p7s>
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
Blumenthal, Uri - 0553 - MITLL
2017-Nov-03 19:10 UTC
[RFC 1/2] Add support for openssl engine based keys
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?
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
HansenPartnership.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171103/b38adcbb/attachment-0001.p7s>