|
Hi,
On 14/12/20 21:01, George wrote:
Ok, so I am not actually going to
populate EVP_PKEY with a private key in the callback function:
int
(*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey)?
Instead, I will call
EVP_PKEY
*ENGINE_load_private_key(ENGINE *e, const char *key_id,
UI_METHOD *ui_method, void *callback_data);
to get the EVP_PKEY, which
will be used by OpenSSL to access the Smart Card.
Once I get the
resulting EVP_PKEY
using ENGINE_load_private_key(...),
how do I assign it to pkey in the callback function?
If I had private key I would use something like
EVP_PKEY_assign_RSA(..)
Since I don't actually have a private key, should I use
something else?
like Michael pointed out, my eap-tls code is just an example of how
you could handle a pkcs11 device; it does not us a callback at all,
but my code loads the client cert+key upfront and avoids having to
use a client callback altogether.
I guess you could also use a client callback for this (perhaps in
combination with SSL_CTX_set_client_cert_engine()) . In that case
you would get the (pseudo) key from the engine like this
EVP_PKEY *engine_key = ENGINE_load_private_key(ENGINE
*e, const char *key_id, UI_METHOD *ui_method, void
*callback_data);
and then set
pkey = &engine_key;
and see if that works.
Note that the ENGINE_load_private_key()
function *does* return a EVP_PKEY struct but that does not mean
the entire private key is contained in it; a private key consists
of a modulus and a private part (exponent, prime1, prime2, exponent1,
exponent2 etc). the ENGINE_load_private_key()
call will return a struct containing the modulus but not the rest.
You then use the engine to do the actual encryption and decryption.
HTH,
JJK
Thanks,
George
On 2020-12-14 12:59 p.m., Michael Wojcik wrote:
You can't get the private key from the smartcard. Instead, you have to let the engine do the encryption. I don't know what ENGINE_load_private_key actually does - in my PKCS#11 work I didn't have to get into this - but I suspect it just puts a key identifier into pkey.
Then what ought to happen is that you pass that pkey to OpenSSL where you need an EVP_PKEY, and OpenSSL will call the engine's appropriate method for whatever it needs to do, and the engine will tell the smartcard "do this thing using the key with this identifier".
I suggest you refer to a example such as the PPP code that Jan cited to see how it does this sort of thing.
Or you can take the approach that Paul suggests in his reply of writing your own engine specifically for your hardware, if you don't need generic PKCS#11 support. Basically, PKCS#11 gives you support for more devices, and in principle should do some of the work for you; but as Paul suggests, the PKCS#11 API and its dependence on external drivers and libraries means it's not easy to work with. In some cases where you only need to support one type of device (or a family of devices that all use the same driver / library) it might well be easier to just write a simple engine that only supports the features you need. You can use the source for the existing engines in OpenSSL to get an idea of what that looks like.
A few years back I forked the OpenSSL CAPI engine to make some fixes and enhancements, and that was pretty straightforward.
So if you have a well-documented API for your particular smartcard, with handy functions like "do this to get an RSA signature of a blob of data with this key ID and these parameters", you may want to try Paul's route. Really depends on your requirements and what kind of support you already have for your device.
And all of this changes in 3.0 with the new "provider" architecture, so you'll get to take another crack at it soon.
--
Michael Wojcik
|
