[openssl-users] Storing private key on tokens

[Jakob Bohm]

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