> My question is, does the token's PKI engine just do step 5, or does it do the crypto parts of both 4 and 5? any additional parts of this sequence .?
I worked with a similar context recently, using a custom hardware pkcs11 token & a custom engine, the only operation handled by the hardware token was the signature operation (C_Sign), which is used only on step 5. In your case you have to check engine_pkcs11 to see if other crypto operations are performed by the token or not. For the data flow i'd add in steps 8 & 9 that the handshake's integrity check is performed at these point respectively for the client and the server. These steps are already encrypted using the session keys too. 2010/2/15 John R Pierce <pie...@hogranch.com> > Using engine_pkcs11 with openssl and a hardware token like the Aladdin > eToken (using Aladdin's pkcs11 driver), I want to make sure I'm describing > the data flow correctly. In my scenario, the etoken contains a client > certificate. The SSL connection is being opened by a m2crypto client. > > My question is, does the token's PKI engine just do step 5, or does it do > the crypto parts of both 4 and 5? any additional parts of this sequence .? > > I cribbed this description of the SSL handshake from Sun's SSL docs as it > was easier for me to follow than the RFC stuff. > > > 1. The client sends the server the client’s SSL version number, > cipher settings, randomly generated data, and other information > the server needs to communicate with the client using SSL. > > 2. The server sends the client the server’s SSL version number, > cipher settings, randomly generated data, and other information > the client needs to communicate with the server over SSL. The > server also sends its own certificate and, if the client is > requesting a server resource that requires client authentication, > requests the client’s certificate. > > 3. The client uses some of the information sent by the server to > authenticate the server. If the server cannot be authenticated, the > user is warned of the problem and informed that an encrypted and > authenticated connection cannot be established. If the server can be > successfully authenticated, the client goes on to Step 4. > > 4. Using all data generated in the handshake so far, the client, with > the cooperation of the server, depending on the cipher being used, > creates the pre-master secret for the session, encrypts it with > the server’s public key, obtained from the server’s certificate, > sent in Step 2. > > 5. If the server has requested client authentication (an optional > step in the handshake), the client also signs another piece of > data that is unique to this handshake and known by both the client > and server. The client sends both the signed data and the client’s > own certificate to the server along with the encrypted pre-master > secret. > > 6. If the server has requested client authentication, the server > attempts to authenticate the client. If the client cannot be > authenticated, the session is terminated. If the client can be > successfully authenticated, the server uses its private key to decrypt > the pre-master secret, then performs a series of steps (which the client > also performs, starting from the same pre-master secret) to generate the > master secret. > > 7. Both the client and the server use the master secret to generate > the session keys, which are symmetric keys used to encrypt and > decrypt information exchanged during the SSL session and to verify > its integrity—that is, to detect changes in the data between the > time it was sent and the time it is received over the SSL connection. > > 8. The client sends a message to the server informing it that future > messages from the client are encrypted with the session key. It > then sends a separate (encrypted) message indicating that the > client portion of the handshake is finished. > > 9. The server sends a message to the client informing it that future > messages from the server are encrypted with the session key. It > then sends a separate (encrypted) message indicating that the > server portion of the handshake is finished. > > 10. The SSL handshake is now complete, and the SSL session has begun. > The client and the server use the session keys to encrypt and > decrypt the data they send to each other and to validate its > integrity. > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
