Storing private key on tokens

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Storing private key on tokens

Dmitry Belyavsky-3
Hello,

What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism.

I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that. 

Thank you!

--
SY, Dmitry Belyavsky

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Blumenthal, Uri - 0553 - MITLL
AFAIK, at this point pkcs11 engine doesn't support key generation. 

The only viable options AFAIK are OpenSC (pkcs11-tool) and vendor-specific applications like yubico-piv-tool.

Regards,
Uri

Sent from my iPhone

On Sep 27, 2017, at 08:23, Dmitry Belyavsky <[hidden email]> wrote:

Hello,

What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism.

I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that. 

Thank you!

--
SY, Dmitry Belyavsky
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Dirk-Willem van Gulik
In reply to this post by Dmitry Belyavsky-3
On 27 Sep 2017, at 14:22, Dmitry Belyavsky <[hidden email]> wrote:

> What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens? Reading/writing is implemented via engine mechanism.
>
> I suppose that it should be added support of -outform ENGINE to the genpkey command, but do not understatnd how to deal with it after that.

The OpenSC tools integrate nicely (and the yubico toools too with a bit more fiddling).

You typically end up with constructs like:

        ${OPENSSL} << EOM || exit 1
        engine dynamic -pre SO_PATH:/Library/OpenSC/lib/engines/engine_pkcs11.so \
                        -pre ID:pkcs11 \
                        -pre LIST_ADD:1 -pre LOAD \
                        -pre MODULE_PATH:opensc-pkcs11.so \
                        \
                        XXX -engine pkcs11 -key slot_$SLOT-id_$KID -keyform engine YYYYYY
        EOM

where ‘XX’ and ‘YYY’ are the openssl command and arguments. The slot information of existing keys does usually need OpenSC or similar; as there is no easy syntaxtic sugar to get access for the engine (AFAIK):

        set `pkcs11-tool --module /Library/OpenSC/lib/opensc-pkcs11.so --list-slots | grep Slot | grep SCM`
        SLOT=$2
        set `pkcs15-tool --list-keys | grep ID`
        AID=$4
        KID=$7

Dw.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Michael Wojcik
In reply to this post by Dmitry Belyavsky-3
> From: openssl-users [mailto:[hidden email]] On Behalf Of Dmitry Belyavsky
> Sent: Wednesday, September 27, 2017 06:22
> To: [hidden email]
> Subject: [openssl-users] Storing private key on tokens

> What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens?
> Reading/writing is implemented via engine mechanism.

The tokens / HSMs I've used don't let you generate a key somewhere else and install it on the token. They insist on doing the key generation locally. That is, after all, part of the point of using a token - the key never leaves it.

Some tokens and HSMs support key backup and restore, e.g. Nitrokey HSM's DKEK share mechanism, but that's deliberately not open to "restoring" some arbitrary private key onto the device.

So this wouldn't make much sense for the pkcs11 engine, even if PKCS#11 provided an API for it.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Dirk-Willem van Gulik

> On 27 Sep 2017, at 20:02, Michael Wojcik <[hidden email]> wrote:
>
>> What is the most natural way to generate private keys using openssl but store them on a specific hardware tokens?
>> Reading/writing is implemented via engine mechanism.
>
> The tokens / HSMs I've used don't let you generate a key somewhere else and install it on the token. They insist on doing the key generation locally. That is, after all, part of the point of using a token - the key never leaves it.

I've found that the Feitian ePass2000's and the Yubico keys allow for importing of the private key. They do usually want the 'extra' flags to specify use:

        pkcs15-init --store-private-key .ssh/id_rsa-foo --auth-id 01 --key-usage sign,decrypt --label "ssh key of [hidden email]"

and some fail silently when you do not provide these.

Dw.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Ken Goldman-2
On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote:

>
>> On 27 Sep 2017, at 20:02, Michael Wojcik
>>
>> The tokens / HSMs I've used don't let you generate a key somewhere
>> else and install it on the token. They insist on doing the key
>> generation locally. That is, after all, part of the point of using
>> a token - the key never leaves it.
>
> I've found that the Feitian ePass2000's and the Yubico keys allow for
> importing of the private key. They do usually want the 'extra' flags
> to specify use:

FWIW, the TPM hardware also permits key import.  It does validate
attributes, so users will know that the key was not generated on chip.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

lists-161
On 09/27/2017 11:13 PM, Ken Goldman wrote:

> On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote:
>>
>>> On 27 Sep 2017, at 20:02, Michael Wojcik
>>>
>>> The tokens / HSMs I've used don't let you generate a key somewhere
>>> else and install it on the token. They insist on doing the key
>>> generation locally. That is, after all, part of the point of using
>>> a token - the key never leaves it.
>>
>> I've found that the Feitian ePass2000's and the Yubico keys allow for
>> importing of the private key. They do usually want the 'extra' flags
>> to specify use:
>
> FWIW, the TPM hardware also permits key import.  It does validate
> attributes, so users will know that the key was not generated on chip.
>

Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for
external generation of RSA keys and import into the token.
Currently I mostly use InCard cards sold in Italy, I can't tell if the
other brands are still easily purchaseable.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Jan Just Keijser-2
Hi,

On 04/10/17 10:17, lists wrote:

> On 09/27/2017 11:13 PM, Ken Goldman wrote:
>> On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote:
>>>
>>>> On 27 Sep 2017, at 20:02, Michael Wojcik
>>>>
>>>> The tokens / HSMs I've used don't let you generate a key somewhere
>>>> else and install it on the token. They insist on doing the key
>>>> generation locally. That is, after all, part of the point of using
>>>> a token - the key never leaves it.
>>>
>>> I've found that the Feitian ePass2000's and the Yubico keys allow for
>>> importing of the private key. They do usually want the 'extra' flags
>>> to specify use:
>>
>> FWIW, the TPM hardware also permits key import.  It does validate attributes, so users will know that the key was not
>> generated on chip.
>>
>
> Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for external generation of RSA keys and import into the token.
> Currently I mostly use InCard cards sold in Italy, I can't tell if the other brands are still easily purchaseable.
>
>
FWIW:  I've used mostly Aladdin/Safenet/Gemalto eTokens (32K, 64K, 72K) and they all support the import of RSA keys (as well as
generation of keys, of course).

Furthermore, if you look at the libp11 library then you will find that it does just that:  generate a key in memory and then
store it on the etoken. The source code even has a comment about this:

110 /*
111  * Generate and store a private key on the token
112  * FIXME: We should check first whether the token supports
113  * on-board key generation, and if it does, use its own algorithm
114  */
115 int
116 PKCS11_generate_key(PKCS11_TOKEN * token,
117             int algorithm, unsigned int bits, char *label, unsigned char* id, size_t id_len)
118 {
119     PKCS11_KEY *key_obj;
120     EVP_PKEY *pk;
121     RSA *rsa;
122     BIO *err;
123     int rc;
124
125     if (algorithm != EVP_PKEY_RSA) {
126         PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_NOT_SUPPORTED);
127         return -1;
128     }
129
130     err = BIO_new_fp(stderr, BIO_NOCLOSE);
131     rsa = RSA_generate_key(bits, 0x10001, NULL, err);
132     BIO_free(err);
133     if (rsa == NULL) {
134         PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY, PKCS11_KEYGEN_FAILED);
135         return -1;
136     }
137
138     pk = EVP_PKEY_new();
139     EVP_PKEY_assign_RSA(pk, rsa);
140     rc = pkcs11_store_private_key(token, pk, label, id, id_len, &key_obj);



JM2CW,

JJK

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Storing private key on tokens

Jakob Bohm-7
On 04/10/2017 10:44, Jan Just Keijser wrote:

> Hi,
>
> On 04/10/17 10:17, lists wrote:
>> On 09/27/2017 11:13 PM, Ken Goldman wrote:
>>> On 9/27/2017 2:19 PM, Dirk-Willem van Gulik wrote:
>>>>
>>>>> On 27 Sep 2017, at 20:02, Michael Wojcik
>>>>>
>>>>> The tokens / HSMs I've used don't let you generate a key somewhere
>>>>> else and install it on the token. They insist on doing the key
>>>>> generation locally. That is, after all, part of the point of using
>>>>> a token - the key never leaves it.
>>>>
>>>> I've found that the Feitian ePass2000's and the Yubico keys allow for
>>>> importing of the private key. They do usually want the 'extra' flags
>>>> to specify use:
>>>
>>> FWIW, the TPM hardware also permits key import.  It does validate
>>> attributes, so users will know that the key was not generated on chip.
>>>
>>
>> Most smart cards (G&D, Oberthur and InCard) I've dealt with allow for
>> external generation of RSA keys and import into the token.
>> Currently I mostly use InCard cards sold in Italy, I can't tell if
>> the other brands are still easily purchaseable.
>>
>>
> FWIW:  I've used mostly Aladdin/Safenet/Gemalto eTokens (32K, 64K,
> 72K) and they all support the import of RSA keys (as well as
> generation of keys, of course).
>
> Furthermore, if you look at the libp11 library then you will find that
> it does just that:  generate a key in memory and then store it on the
> etoken. The source code even has a comment about this:
>
> 110 /*
> 111  * Generate and store a private key on the token
> 112  * FIXME: We should check first whether the token supports
> 113  * on-board key generation, and if it does, use its own algorithm
> 114  */
> 115 int
> 116 PKCS11_generate_key(PKCS11_TOKEN * token,
> 117             int algorithm, unsigned int bits, char *label,
> unsigned char* id, size_t id_len)
> 118 {
> 119     PKCS11_KEY *key_obj;
> 120     EVP_PKEY *pk;
> 121     RSA *rsa;
> 122     BIO *err;
> 123     int rc;
> 124
> 125     if (algorithm != EVP_PKEY_RSA) {
> 126         PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY,
> PKCS11_NOT_SUPPORTED);
> 127         return -1;
> 128     }
> 129
> 130     err = BIO_new_fp(stderr, BIO_NOCLOSE);
> 131     rsa = RSA_generate_key(bits, 0x10001, NULL, err);
> 132     BIO_free(err);
> 133     if (rsa == NULL) {
> 134         PKCS11err(PKCS11_F_PKCS11_GENERATE_KEY,
> PKCS11_KEYGEN_FAILED);
> 135         return -1;
> 136     }
> 137
> 138     pk = EVP_PKEY_new();
> 139     EVP_PKEY_assign_RSA(pk, rsa);
> 140     rc = pkcs11_store_private_key(token, pk, label, id, id_len,
> &key_obj);
>
>
That's a shitty place to hide such a glaring security hole. Hopefully
it is also an open, non-hidden bug and a warning in the README, manpage
etc.

Because most users of PKCS#11 hardware would presume that software using
their hardware doesn't silently nullify a key hardware security feature.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users