From: "Alexander Kuit" <[EMAIL PROTECTED]>

AKuit> On 13.12.2001 10:49:31 Richard Levitte - VMS Whacker wrote:
AKuit> 
[...]
AKuit> >This is exactly how it's done in crypto/engine/hw_ncipher.c, why don't
AKuit> >you take a look at that file?
AKuit> 
AKuit> Hi Richard,
AKuit> 
AKuit> I had a look at that code, but I just don't like copying things
AKuit> without knowing what I'm doing ;-)

I understand that perfectly well.  However, your question was "how do
I...?", and I answer with "you do it like this" with a reference to
more code that does what you appear to want, modulo the intermediate
library calls.

What you're talking about below is something different than what I
answered above.

AKuit> What do you mean by "you have a RSA that contains the public data" ?
AKuit> I really don't understand why I need a EVP_PKEY with a pointer to a
AKuit> RSA struct. The DER encoded X.509 certificate is read from the card.

Ah.  Well, the very simple answer is that we don't support card-stored
(and card-hidden?) certificates yet.  Also, *you were asking about
private keys*!  Where exactly do you store the private key in the
certificate?

AKuit> I don't have and need access to the private key in the card, I only
AKuit> have to make sure the right key is used during the SSL handshake,
AKuit> but that's easy also without a dummy/proxy/shadow (whatever one
AKuit> could call it) EVP_PKEY.

Let's see, you need the private key to sign certain things with, so I
fail to see in what way you don't need it.  Both the client and the
server sign certain things in the SSL communication.

AKuit> If I have to provide a EVP_PKEY (e.g. by ENGINE_load_private_key),
AKuit> with what information do I fill it? What data do I put into the
AKuit> RSA struct? (I don't have any private data and I guess my own
AKuit> public key is not used during the handshake. Besides, it's
AKuit> already in the certificate)

It's becoming apparent that one or more of the following is true:

1. you don't know jack shit about how SSL works and what is needed for
   it to work properly.
2. you didn't bother looking at the code I suggested that you study.

The handshake in SSL requires both decryption (which requires a
private key or at least a reference to a private key) and signature
verification (which requires a public key) on the server side, at the
very least.

What exactly is the purpose with the engine you're building?  Do you
want it to support RSA operations?  To perform those operations, you
need a public key and at least a reference to a private key.  It's
that simple.

To answer those specific questions:

"If I have to provide a EVP_PKEY with what information do I fill it?"

A pointer to an RSA structure.  See the example code I gave you
earlier.

"What data do I put into the RSA struct?"

The public components of the key, which I'm sure can be extracted from
your card, no?  Of course, nothing stops you from just having a
reference to the on-card key and using the card operations to do the
RSA math.  Basically, you have to fill in the fields n and e or the
RSA structure, and set the flags bit RSA_FLAG_EXT_PKEY.  The values of
n and e have to be pointers to BN structures, so if your card gives
you a different structure (most likely), you have to convert it, which
is rather easy with BN_bin2bn().

If you need, I can probably help you code that engine.  However, I
will request that you pay me for it, and make sure I get appropriate
hardware to test against.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus:             http://www.gemplus.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to