> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of George > Sent: Monday, 14 December, 2020 09:36
> I see what you mean. So once I have everything setup, i use the following > to get the private key: > EVP_PKEY *pkey = ENGINE_load_private_key(...); > > Will pkey actually contain the private key from the smart card? It had better not. > I thought it was not possible to get a private key from a smart card? That's the point of the smartcard (or other HSM), yes. > Once I have pkey, do I simply use it within the client_cert_cb callback > function? 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
