I think both Kurt and Rogan covered a part of the answer so I'll only try to consolidate and summarise:
The encryption and signing keys in SSL/TLS vary according to the stage of the protocol and the algorithms selected for the various operations. For the sake of simplicity and clarity I'll concentrate in cases when RSA is used for key exchange/authentication. After the initial exchange of messages between client and server (ClientHello and ServerHello) the server sends its public key certificate to the client (and optionally requires the client to subsequently authenticate using a public key certificate). The client has to verify the certificate and, if valid, to encrypt the preMasterSecret under the server's public key and send it to the server. The server uses the information contained in the preMasterSecret to derive information (the MasterSecret) which will be subsequently used in confidentiality/integrity transformations. By correctly decrypting the information contained in the encrypted preMasterSecret the server demonstrates knowledge of the private key, proving therefore its identity to the client. After the handshake phase concludes the client and server use a symmetric key to encrypt traffic. Even if encryption has not been selected, the traffic is still protected from modification because of the use of integrity mechanism (i.e. the MAC which also relies on the MasterSecret) and can only be computed by the client and server. In cases where the server RSA certificate can only be used for signing, the server creates a new RSA keypair (called ephemeral) and signs the new public key which is then used by the client for encryption. In the cases of the server requesting client authentication this is performed by the client signing a message with its private key, which the server then verifies. In general, the same keypair is not used for both signing and encryption, since this is considered bad practice. As far as references are concerned, your best bet would be RFC 2246 (the TLS protocol) and the WAP-TLS specification (http://www.wapforum.org) which explains the TLS implementation for use on mobile phones. Hope this helps, ----------------------- Dimitrios Petropoulos MSc InfoSec, CISSP Director, Security Research & Development ENCODE S.A. 3, R.Melodou Str 151 25 Marousi Athens, Greece Tel: +3010-6178410 Fax: +3010-6109579 Mob: +30944-506334 web: www.encode-sec.com ------------------------ > -----Original Message----- > From: Kurt Seifried [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 14, 2002 8:26 PM > To: Dawes, Rogan (ZA - Johannesburg); 'Niall O Malley (LMI)'; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: SSL Question > > > > To the best of my knowledge, the encryption keys and > signing keys are > > the same. > > Huh. No. You have private keys and public keys. Public keys > are distributed and can be used to encrypt data that only the > private key can decrypt. Private keys can be used to sign > data (actually it encrypts a hash value of the data such as > MD5 or SHA1) and this signature can be verified (decrypted) > by the public key. This is essentially true of all "public > key" cryptography. > > > i.e. You would negotiate a session key that would be used to > > symmetrically encrypt the data sent. The fact that the > recipient can > > decrypt it implies that the data is authentic, since only the two > > parties would be privy to > the > > session key. > > > > It is possible to use a "null" algorithm, I think, that > simply does no > > encryption. This allows the client to be sure that they are > talking to > > the server, and potentially allows the server to know that it is > > talking to > the > > client (if you are using client certs), but reduces the overhead of > actually > > encrypting the data. > > >From Apache: > > #SSLCipherSuite > ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL > > notice the last one. > > > I'm not sure if this has any guarantees about the integrity of the > > data anymore, though. > > Nope, none, it's cleartext, which make's man in the middle or > injection possible. > > > I'm really not sure what you are asking though. SSL is inherently > asymmetric > > in the key negotiation phase, and symmetric in the encryption phase > > > > Hope this helped. > > > > Rogan > > > > > Just a quick question > > > > > > say I wish to setup an SSL link between a client and a server > > > - but I just want to perform digital signing from the > client to the > > > server, are these two functions (i.e. the setting up of the SSL > > > tunnel, and the signing mechanism) considered totally separate > > > -i.e. is the tunnel setup completely separately and using > > > different key/certificate systems than the digital signing keys > > > and certs? > > SSL is an encryption method that uses X.509 certificates. > X.509 certificates can be signed, typically this is done by a > "certificate authority". Your browser has the public keys of > the certificate authority, thus allowing it to verify the > certificate authority's signature on the X.509 certificate > presented to you from the webserver, thus allowing you to > decide on some level of trust (usually complete). > > > > What I am considering is to use a phone to link to an SSL enabled > > > server - will the phone download the cert of just a > hashed algorithm > > > from the server. The Netscape site is next to useless - which is > > > strange since they have developed the protocol. > > > > > > Does anyone know a useful place to find such information on > > > Symmetric SSL etc. > > Symetric encryption requires some sort of preshared secret, a > password, a long string of text, etc. Hence it isn't terribly > useful outside of password authentication where you have a > preshared secret of sorts (the password). > > > > Any ideas ??? > > Kurt Seifried, [EMAIL PROTECTED] > A15B BEE5 B391 B9AD B0EF > AEB0 AD63 0B4E AD56 E574 > http://seifried.org/security/ http://www.idefense.com/digest.html > > > >
