Request for generic engine support

[Mccue, Richard Alan]

Hello Peter,

>> One use in particular would be to support TCP forwarding for secure
>> mail server connections and similar applications.

> Sorry, can you please clarify this a bit?

> I already use OpenSSH to secure TCP connections through -L and -R.

An OpenSSL engine provides replacement routines to modify OpenSSL functions. For instance, RSA_private_decrypt() can be modified with a replacement function that channels execution to a hardware device. This is useful if the hardware device provides some additional security beyond that of the default SSLeay routines. The engine I use employs a device that is exclusively able to encrypt/decrypt with private RSA keys that it encrypts in stored files. The keys can't be extracted in unencrypted form from the device.

If I configure sshd to load the engine at startup then the engine replaces rsa_priv_dec(). Then sshd on my mail server will always decrypt signatures with a private key loaded into the device. A client uses "ssh -L ......." to request the connection as it would without the engine, and need not be aware ofthe engine on the server side. The same holds true on the server side - if ssh were modified to load an engine, the server side would not be able to tell. Form or use of the public keys is not affected by the device encrypting the private keys.

For a process to use an engine, only its initialization code is modified. Using the engine after it is loaded, like for a server that repeatedly establishes RSA sessions, is entirely transparent since the RSA functions have been modified by the engine. Since the configuration keywords for the engine are all optional, ssh or sshd are not affected by the engine enablement code.

For comparison, Stunnel has an implementation that uses directives in a config file to identify and load an engine:
-----------
engine=dynamic
engineCtrl=SO_PATH:/usr/lib/openssl/libxyz.so
engineCtrl=ID:xyz
engineCtrl=LIST_ADD:2
engineCtrl=LOAD
engineCtrl=INIT
----------
Stunnel seems to be similar to OpenSSH in its capacity to act as an encryption proxy for applications that cannot establish RSA-based sessions on there own. So it might be useful for OpenSSH to have this capability also. I have no idea as to what the current level of interest would be.

>> Another approach would be to take advantage of the OpenSSL
>> config(5) configuration file mechanism.

> How do you feel about PKCS#11 ?

I'm not sure the device I'm working with fits well with the PKCS#11 token interface. The device is a little more complicated than a smartcard. It can handle multiple private keys. If a dozen apps all have different private RSA keys, each app can load its key separately and have the device encrypt/decrypt with it. PKCS#11 is on my list of things to investigate more deeply. Maybe later this year I'll understand PKCS#11 a little better.

Thanks for your consideration.

regards, Rich