openssh unix dev - Nov 2017 - [RFC 1/2] Add support for openssl engine based keys

>>  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?

If there?s no PKCS#11 ?driver? for TPM ? then that?s what needs to be added,
IMHO.
 
-------------- 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/323ceb30/attachment.p7s>

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

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>