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
