"Kenneth R. Robinette" wrote:
>
> With the assistance of the SSL users group, I was able to complete
> our project to link OpenSSH/OpenSSL to the use of Smart Cards for
> both SSH-1 and SSH-2 rsa_private_decrypt and rsa_private encrypt
> processing. The use of the RSA method within the OpenSSL RSA
> key structure, combined with the CRYPTO_EX_DATA field provided
> everything necessary to allow our Microsoft windows based SSH
> Key Agent to utilize a Smart Card (iButton) to process the SSH
> challenge.
>
Glad to hear it.
> >From what I can determine, most if not all, Smart Cards contains the
> very low level bn_mod_exp function within hardware. In our case,
> we used all the code within OpenSSL to do the padding, etc. and
> only had a need to intercept the bn_mod_exp call.
>
Well they might intercept rsa_mod_exp() and leave bn_mod_exp() alone
(i.e. pointing to the internal bn_mod_exp()).
> Currently, both rsa_private_decrypt and rsa_private encrypt expects
> the rsa key to contain more elements of the key then would be
> available under normal Smart Card use. In fact, only rsa->n would
> be known outside the card itself, which of course is required to be
> present on the SSH host in the form of a SSH-1 or SSH-2 public
> key file.
>
Typically both rsa->n and rsa->e (i.e. the public key) will be known
outside the card. If the key is to be used for some purposes (for
example certificate request or self signed certificate generation) it is
essential that rsa->n and rsa->e are populated.
Smartcards may not support public key operations or indeed may have
fairly poor performance in this regard. Therefore one solution is to
populate rsa->n, rsa->e and leave bn_mod_exp() as the OpenSSL internal
version. Doing this means that public key operations can be performed in
software which may be quicker that the smart card.
By redirecting rsa_mod_exp() and setting RSA_FLAG_EXT_PKEY only the
private key operations are diverted to the card.
> I would recommend the addition of one additional flag within the
> rsa->flags field to allow for the specification of a special external
> bn_mod_exp processing function. Furthermore, I would recommend
> that the call to the "special" bn_mod_exp only contain the binary
> input data (just prior to the bin2bn call and the pointers to the output
> data buffer and the output data buffer length, and perhaps the rsa-
> >n field. I say perhaps for the rsa->n field because the Smart Card
> already has this, all that is really needed is a keyid field (which we
> place in the ex_data field) to identify what Smart Card key pair to
> use.
>
> This would elimate some code necessary to force the RSA private
> encrypt function to call bn_mod_exp, and the bin2bn and bn2bin
> processing. The end result is all that would be required to use the
> Smard Card is to change the rsa method pointer for bn_mod_exp,
> set a bit in the rsa->flags field and place a key id in the ex_data
> field. In addition, and most important, this would allow for Smart
> Card support without changing anything within OpenSSL (after the
> modification) and only two minor intercepts within the SSH key
> agent code (dealing only with the rsa key structure itself).
>
> Any thoughts?
>
I agree that adding an additional function to RSA_METHOD which avoids
the extra bin2bn and bn2bin conversions and extra code complexity is a
good idea.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
