Request for generic engine support

Mccue, Richard Alan
Fri, 09 May 2008 02:36:00 -0000

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