Six Degrees of Paranoia

1. The server does not know who is on the other end of the connection. The user thinks it is connected to the real (as opposed to fake or impersonator) server he asked for but may not be so.

   For all the server knows, it may be sending sensitive information (such as some other user's bank account balance) to the wrong user ("impersonation"). Same problem is faced by the real user.

   This is the routine mode. The user has not authenticated himself to the server by entering a username and a password. Nor is the HTTP connection established through the SSL.

   Additional problems include "eavesdropping" (someone can learn your credit card number) and "tampering" (someone can replace your ship-to address with his address). Such concerns are also called "the-man-in-the-middle" type concerns. All Internet data passes through so many servers on the way that any of them could be an evil server.

   Use this type of communication for exchanging public data only. You should not care if someone else sees it or modifies it.

2. Both the server and the user think they know who is on the other end of the server.

   Here, the user has requested a server URL. Before supplying the requested URL, the server asks the user to enter his username and password on a form and send it to the server. The user complies. The information reaches the server where it (usually) makes a "one-way hash" of the password supplied by the user and compares the resulting value to the one-way hash of the password supplied by the user during registration. If they match, the user is authenticated and the server sends the requested URL.

   The problem is that user's browser has sent the password as clear text, or, at best, encoded with base-64 encoding. The-man-in-the-middle can very easily read it, save it for future impersonations to the server or change the included data. In addition, the user still does not know if he is talking to the real server or some impersonator in the middle.

   People usually use it log into their Yahoo, MSN, AOL or such accounts where they are not actually spending any money.

3. Enter SSL. Usually you, a user, initiate a secure transaction. So you need to first convince yourself that the server you are talking to is the right server. Only then you want to log on to that server by providing your username and password.

   SSL makes sure that the user is talking to the real server, encrypts the user's data before sending it to the server (effectively wrapping the data in an (really, really secure) envelope, and decrypts server's data upon receipt. Each modern browser such as Netscape and Internet Explorer now-a-days comes with embedded Secure Socket Layer software.

   With SSL, the user KNOWS that he is talking to the real server and "the-man-in-the-middle" CANNOT view or change the data being communicated over the SSL connection. If he tries to view it, he will see scrambled data. If he tries to break the code to unscramble the data, it will take him a few MILLION years to do that given the current capabilities of such hardware and software. In frustration, if he tries to change the scrambled data by replacing it with some other scrambled data, the message digest will not match. And he can't really change the message digest because it has been encrypted also!

   The server still does not know that it is talking to the real user. As far as the server knows, somebody sitting on a computer entered the correct username and password and now, the server is supposed to be sending sensitive data to that computer.

   A user can be authenticated in two ways:

   1. By supplying a password already known to the server. This is the usual way. However, the first time the user registers, the server will have to go to some (extreme) lengths to really make sure that the user who is registering is the user he claims to be. Since most users have accounts at multiple servers, they will need a different password for each server or risk compromising the password by sharing it across servers.
   2. By supplying a server-provided random phrase encrypted with the user's private key, and a valid public digital certificate issued by a well known, responsible authority. Here, the issuing company takes care of authenticating the user (just as a Social Security or a Passport Office does before providing the Social Security Number or Passport). The digital certificate contains the user's public key which the server can use to decrypt the data sent by the user and see if the resulting phrase matches the phrase sent by the server.

      The down side is that each user will have to jump through some hoops in getting a valid certificate from a well recognized authority, or one from each well-known authority (VeriSign, Thawte etc.) just in case a server is picky about the brand of certificates it trusts.

4. Sometimes, the server may want to know for sure that it is talking to the correct user i.e. the user who registered with the server in the first place. Such a need can arise for a bank when sending large sums of money to the user or for voting in elections.

   The server, being a machine, cannot really look at the user and match his photo to the one on his driver's license or passport. May be in future we will have iris scanners mounted on each computer by default and each server will have access to the iris print database to compare. Not yet!

   The solution is to have the user get a (digital) certificate from a trusted issuer who certifies that:

   1. The user is called "Jane Doe" (Actually, the user's real name)
   2. This certificate of the user's identity is valid till such-and-such date.
   3. You can encrypt/decrypt data to/from the user using this public key

   The certificate issuer "signs" the certificate and sends the digital file to the user. The user can then send it along with his request to the server over the SSL connection (so that "the-man-in-the-middle" can't mess with it). If it is really the user who gets the certificate and if the user keeps tight control of his private key, then the server is sure for all intent and purposes that it is the real user with whom the server is communicating.

   Additional Details: The browser encrypts some data known to the server with the user's private key, and sends both the encrypted data and the user's public certificate to the server. The server checks the "message digest" to make sure that the encrypted data was not tampered en-route, decrypts the data using the public key contained in the user's public certificate, and matches it against the one known to the server. Since only an authentic private key could have encrypted the data decryptable with the public key contained in the user's certificate, the server is quite sure that it is dealing with the real user.

   In addition, the server is supposed to check at the certificate issuer's central location if the certificate has been revoked before it expired.

   It is the user's responsibility to renew his digital certificate before it expires so that he may continue using it.

5. With SSL, the data is protected from the world only during communication over the Internet. It is still available as an open book on the user's computer or on the server. Why can't you keep your sensitive data in an encrypted form on your computer or on the server? Certainly, you keep your important papers under lock and key, may be in a safe even!

   Well, you can use some encryption software (e.g. PGP) and your own personal encryption/decryption keys (symmetric or asymmetric, it doesn't matter), encrypt sensitive data (such as your Money or Quicken file or your entire hard disk, for that matter) with it, and save the encryption key at a safe location (such as save it on a floppy disk, CD-ROM or smart card, and store that media under lock and key, may be in a safe even!).

6. Now both the user and the server know for sure who is on the other end of the connection. Nobody in the middle can mess with their data without them knowing about it automatically. And the user has protected his sensitive data even on his computer.

   But the user's data is not protected on the server. Yes, the server may encrypt and decrypt it using the server's own keys, but that's beyond the user's control. For all the user knows, the server may keep all of user's data as an open book. You will have to just trust the server's word that the server keeps all your sensitive data encrypted, and only decrypts it for you or other authorized entities. Good luck with that!

Getting Started

Some Term Definitions

• A "hash" is an algorithm to produce a (mostly) unique fixed-length data block from raw data of any size.
• A message digest is a one-way hash of the data to be encrypted (the "message"). It is produced by a mathematical function (hash algorithm such as MD5 or SHA1). No matter what the size of the raw data is, the hash algorithm always produces a fixed-length (128 or 160 bit long now-a-days) data block (message digest). The number of combinations of the resulting "hash" is vastly larger than the number of different messages likely to ever be exchanged in the world.
• The message digest is unique in the sense that no two raw data will produce the same hashed data block but the same raw data will always produce the same hashed data block using the same hash algorithm. Any change in the data, even deleting or altering a single character or byte, results in a different hashed value. Moreover, the content of the hashed data cannot, for all practical purposes, be deduced from the hash - which is why it is called "one-way".
• A message digest can be produced from any data, encrypted or not. It provide assurance that the data was not altered even by a single bit (otherwise a one-way hash on that data will produce a totally different message digest!). Therefore, it is used for message authentication.
• A "cipher" is an algorithm (function) to encrypt and decrypt data.
• A Bulk Cipher is a high-performance cipher (encryption/decryption algorithm) which is used to encrypt/decrypt large quantities of data in a timely manner. Examples include RC2, RC4, and IDEA. RC2 is block cipher (requires padding) and RC4 is a stream cipher (encrypts each bit as it comes through).

  Symmetric Key Encryption

• Symmetric (or secret-key) ciphers (algorithms, functions) use the same key for encryption and decryption (or the decryption key is easily derived from the encryption key). Well-known symmetric functions include DES and IDEA.
• Symmetric algorithms can be divided into stream ciphers and block ciphers. Stream ciphers can encrypt a single bit of plain text at a time, whereas block ciphers (not bulk cipher) take a number of bits (typically 64 bits in modern ciphers), and encrypt them as a single unit.
• DES (1970) is a US government standard and is widely used, especially in the financial industry. It is a block cipher with 64-bit block size. It uses 56-bit keys. This makes it fairly easy to break with modern computers.

  Triple DES or 3DES cipher encrypts data with a 168-bit symmetric-key. It is generally used with SHA-1 message digest of the encrypted data to make sure that the encrypted bits received are the same as the ones sent. Triple-DES is based on using DES three times (normally in an encrypt-decrypt-encrypt sequence with three different, unrelated keys). Triple DES is the strongest cipher supported by SSL, but it is not as fast as RC4.

• RC4 cipher encrypts data with a 128-bit symmetric-key. It is generally used with MD5 message digest of the encrypted data. RC4 ciphers are the fastest of the supported ciphers. It used to be a trade secret, until someone posted source code for an algorithm in Usenet News, claiming it to be equivalent to RC4. There is very strong evidence that the posted algorithm is indeed equivalent to RC4.
• IDEA (International Data Encryption Algorithm) uses a 128 bit key, and it is generally considered to be very secure. It is currently one of the best publicly known algorithms.
• Blowfish is a block cipher with 64-bit block size and variable length keys (up to 448 bits). It is used in Nautilus and PGPfone.
• Others symmetric ciphers are SAFER, ciphers based on a hash function, Enigma (used by the unix crypt(1) program, easily breakable) and Vigenere (historical, easily solvable).

  Asymmetric Key Encryption

• Asymmetric (or public-key) ciphers use a different key for encryption and decryption, and the decryption key cannot be derived from the encryption key. RSA is probably the best known asymmetric algorithm (others are Diffie-Hellman , DSS, ElGamal and LUC).
• Asymmetric ciphers permit the encryption key to be public (it can even be published in a newspaper, e-mail or web site), allowing anyone to encrypt with the key, whereas only the proper recipient (who knows the decryption key) can decrypt the message. The encryption key is also called the public key and the decryption key the private key or secret key. The private key is never distributed; it is always kept a secret at a safe location.
• Asymmetric keys mean that data encrypted with the public key can be decrypted only with the private key. Conversely, data encrypted with the private key can be decrypted only with the public key. In other words, if you encrypt some data with one of the keys, you cannot decrypt it with the same key.
• Because of implementation details, to achieve the same strength encryption as a 128-bit symmetric key, asymmetric keys have to be at least 1024-bit long.

  Digital Signature

• A digital signature of an arbitrary document is typically created by computing a message digest (hash value) from the document, and concatenating it with information about the signer, a time stamp, etc. The resulting string is then encrypted using the private key of the signer using a suitable algorithm. The resulting encrypted block of bits is the signature. It is often distributed together with information about the public key that was used to sign it.

  To verify a signature, the recipient first determines whether it trusts that the key belongs to the person it is supposed to belong to (using the web of trust or a prior knowledge), and then decrypts the signature using the public key of the person. If the signature decrypts properly and the information matches that of the message (proper message digest etc.), the signature is accepted as valid. The most widely known algorithm is RSA.

• A digital signature not only authenticates the sender, but also makes it impossible for the sender to deny ever producing the message, e-mail or file ("non-repudiation").

  SSL

• SSL "scrambles" your data while it is still on your computer and then send it over the Internet. It ensures that the server is authentic, the connection is private, and the messages arrive unaltered.
• Server authentication is required for an encrypted SSL session where as client authentication is not.
• SSL 2.0 authenticates a server only. SSL 3.0 can authenticate the client also.
• A URL accessed through SSL uses HTTPS ("https://host.domain.com/....") protocol. The standard HTTPS port is 443 (just like the standard HTTP port is 80). If the secure link calls a CGI script, you must also reference that script securely (e.g. <FORM METHOD="POST" ACTION="https://www.your-domain.com/cgi-local/order.cgi">)
• Because HTTPS and HTTP communicate on different ports, the same system can run both secure and insecure HTTP servers simultaneously. This means you can provide public information to all users using no security and private information to some users with security.

  SSL Uses Both Symmetric and Asymmetric Key Encryption

• SSL communications start with asymmetric-key (slower) encryption and switch over to symmetric-key (much faster) encryption. To achieve this, a master secret is sent by the browser encrypted with the server's (asymmetric) public-key. To continue conversing securely and efficiently, both the browser and the server (after decrypting the master secret) need to run the same symmetric-key generation algorithm on the same master secret to get the same symmetric-key at each end. Some well-known symmetric-key generation algorithms are KEA and RSA-key-exchange (most used).
• All SSL data sent is encapsulated in a record which has a header and some non-zero amount of data.

  The "length" header tells how much data is in the record. The "PADDING" header specifies how many bytes of data were appended to the original record by the server to make the record length a multiple of the block cipher's block size (when a block cipher is used for encryption).

• The data portion of an SSL record is composed of three components:
  1. Message Authentication Code (i.e. message digest)
  2. Actual Data
  3. Padding Data
• Maximum record length is 32767 bytes for a 2-byte header and 16383 bytes for a 3-byte header. The SSL handshake messages must fit in a single record. After the handshake, data messages may span multiple records.
• While the process may seem lengthy and complicated, it is completely transparent to the user and is established immediately at the initial client/server connection.

SSL - Step-by-Step

                 .---.
.-.              |B  |
|U|  .--------.  |R  |  .---------.
|S|  |Plain   |  |O S|  |  HOLD   |
|E|->|Text    |->|W S|->| REQUEST |
|R|  |Request |  |S L|  |         |
`-'  `--------'  |E  |  `---------'
                 |R  |
                 `---'

                   <--------Plain Text Communications-------->
                 .---.  .---------.  .---.  .-----------.  .---.  .-----------.
                 |B  |  |Client   |  |S  |  |Server     |  |B  |  |Verify     |
                 |R  |  |Hello w/ |  |E  |  |Hello w/   |  |R  |  |Server     |
                 |O S|  |Random   |  |R S|  |Certificate|  |O S|  |Certificate|
                 |W S|->|Challenge|->|V S|->|& Random   |->|W S|->|& Domain   |
                 |S L|  |Data     |  |E L|  |Connection |  |S L|  |Name       |
                 |E  |  |(Plain   |  |R  |  |ID (Plain  |  |E  |  |(Checks OK)|
                 |R  |  |Text)    |  |   |  |Text)      |  |R  |  |           |
                 `---'  `---------'  `---'  `-----------'  `---'  `-----------'

                   <--Asymmetric Key Encryption--->
                 .---.  .---------.  .-------.  .---.  .-------.  .---------.
                 |B  |  |Generate |  |       |  |S  |  |       |  |Generate |
                 |R  |  |Master   |  |Encrypt|  |E  |  |Decrypt|  |Symmetric|
                 |O S|  |Secret   |  |w/     |  |R S|  |w/     |  |Key Pair |
                 |W S|->|to be    |->|Server |->|V S|->|Server |->|for Read |
                 |S L|  |Shared   |  |Public |  |E L|  |Private|  |& Write  |
                 |E  |  |w/       |  |Key    |  |R  |  |Key    |  |(Session |
                 |R  |  |Server   |  |       |  |   |  |       |  |Keys)    |
                 `---'  `---------'  `-------'  `---'  `-------'  `---------'
                             |
Symmetric----------          V         -------------------------------Symmetric
Key                     .---------.  .---------.  .---.  .-------.          Key
Encryption              |Generate |  |Encrypt  |  |S  |  |Decrypt|   Encryption
 |  |  |                |Symmetric|  |Server   |  |E  |  |w/     |     |  |  |
 |  |  |                |Key Pair |  |Conn. ID |  |R S|  |Server |     |  |  |
 |  |  |                |for Read |->|w/ Client|->|V S|->|Read   |     |  |  |
 V  V  V                |Write    |  |Write Key|  |E L|  |Key    |     V  V  V
                        |(Session |  |- Client |  |R  |  |(Checks|
                        |Keys)    |  |Finish   |  |   |  |OK)    |
                        `---------'  `---------'  `---'  `-------'

                                    .---.  .---------.  .---.  .-------.
                                    |S  |  |Encrypt  |  |B  |  |Decrypt|
                                    |E  |  |Client   |  |R  |  |w/     |
                                    |R S|  |Challenge|  |O S|  |Client |
                                    |V S|->|Data w/  |->|W S|->|Read   |
                                    |E L|  |Server   |  |S L|  |Key    |
                                    |R  |  |Write    |  |E  |  |(Checks|
                                    |   |  |Key      |  |R  |  |OK)    |
                                    `---'  `---------'  `---'  `-------'

                                    .---.  .---------.  .---.  .-------.
                                    |S  |  |Server   |  |B  |  |Decrypt|
                                    |E  |  |Finish - |  |R  |  |w/     |
                                    |R S|  |Encrypted|  |O S|  |Client |
                                    |V S|->|New      |->|W S|->|Read   |
                                    |E L|  |Session  |  |S L|  |Key,   |
                                    |R  |  |ID       |  |E  |  |use in |
                                    |   |  |         |  |R  |  |session|
                                    `---'  `---------'  `---'  `-------'

                 .---.  .--------.  .---.  .---------.  .---.
                 |B  |  |ENCRYPT |  |S  |  |Decrypt  |  |B  |             .-.
                 |R  |  |HELD    |  |E  |  |& get    |  |R  |  .-------.  |U|
                 |O S|  |USER    |  |R S|  |resource |  |O S|  |Decrypt|  |S|
                 |W S|->|REQUEST,|->|V S|->|---------|->|W S|->|& Give |->|E|
                 |S L|  |Session |  |E L|  |Encrypt  |  |S L|  |to User|  |R|
                 |E  |  |ID      |  |R  |  |Response |  |E  |  `-------'  `-'
                 |R  |  `--------'  |   |  `---------'  |R  |
                 `---'              `---'               `---'

                 .---.              .---.  .---------.  .---.
.-.  .--------.  |B  |  .--------.  |S  |  |Decrypt  |  |B  |             .-.
|U|  |More    |  |R  |  |Encrypt |  |E  |  |& get    |  |R  |  .-------.  |U|
|S|  |Plain   |  |O S|  |User    |  |R S|  |resource |  |O S|  |Decrypt|  |S|
|E|->|Text    |->|W S|->|Request,|->|V S|->|---------|->|W S|->|& Give |->|E|
|R|  |Request |  |S L|  |Session |  |E L|  |Encrypt  |  |S L|  |to User|  |R|
`-'  `--------'  |E  |  |ID      |  |R  |  |Response |  |E  |  `-------'  `-'
                 |R  |  `--------'  |   |  `---------'  |R  |
                 `---'              `---'               `---'

1. The browser sends the server some randomly generated "challenge" data (if a new connection) or a "Session ID" (if a pre-existing connection), and asymmetric and symmetric ciphers (encryption/decryption algorithms) installed in the browser as plain text.

   A Session ID identifies the pre-established browser session to a server. Think of it as a handle that both parties use to access a recorded secret key (Session Key). If both parties remember the Session ID, then the secret key is already known and need not be regenerated.

   The browser must choose at least one server-authentication and session-key-exchange algorithm (such as RSA or Triple DES), one symmetric key encryption algorithm (such as RC2 or RC4), and one message integrity (hashing) algorithm (such as MD5 or SHA). For example, the browser's CIPHER-CHOICE may be:

   SSL_CK_RC4_128_WITH_MD5
   SSL_CK_RC4_128_EXPORT40_WITH_MD5
   SSL_CK_RC2_128_CBC_WITH_MD5
   SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
   SSL_CK_IDEA_128_CBC_WITH_MD5 

2. The server sets aside the browser's "challenge" data for the time being. It picks a cipher supported by the browser which is usually the strongest allowable depending on whether you are communicating within the USA or across US borders.

   For example, server CIPHER-KIND may be one of:

   SSL_CK_RC4_128_WITH_MD5
   SSL_CK_RC4_128_EXPORT40_WITH_MD5
   SSL_CK_RC2_128_CBC_WITH_MD5
   SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
   SSL_CK_IDEA_128_CBC_WITH_MD5
   SSL_CK_DES_64_CBC_WITH_MD5
   SSL_CK_DES_192_EDE3_CBC_WITH_MD5  

   The server then sends back the picked cipher, some randomly generated data of its own (call it "connection ID"), server's digital certificate, and the server's SSL version number as plain text.

   A Nonce is a randomly generated value used to defeat "playback" attacks. One party (usually server) randomly generates a nonce ("connection ID) and sends it to the other party. The receiver encrypts it using the agreed upon secret key and returns it to the sender. Because the nonce was randomly generated by the sender this defeats playback attacks because the replayer can't know in advance the nonce the sender will generate. The receiver denies connections that do not have the correctly encrypted nonce.

3. The browser sets aside the "connection ID" data for the time being. It first checks the server's certificate for validity:
   1. Has the certificate expired? Warn user if yes.
   2. Does the "Distinguished Name" (DN) of the certficate issuer match one of the trusted DN's listed in the browser? (Browser recursively checks the chain of issuers until the answer is yes or no.) Warn user if no.
   3. Is the certificate still the same as issued by the issuer? (Create a message digest - a one-way hash - of the server's certificate and compare it with the value received by decrypting the issuer's signature with the issuer's public key.) Warn user if no.
   4. Does the DN of the server listed on its certificate match the domain name of the server that the browser requested? (Just in case the "man-in-the-middle" is intercepting the server's certificate and sending its own certificate to you.) Warn user if no.

   If the browser reaches this far, the server's certificate is authentic and still valid. So, the server's certificate (not the server itself) can be trusted.

   (If the user is warned, an encrypted and authenticated connection cannot be established with the requested server. The user decides whether to continue or not.)

4. The browser generates a new master secret data just for this session with the server, encrypts it with the server's public key (obtained from the server's certificate), and sends the encrypted master secret to the server. Since only the real server can have its private key, if the server can decrypt the "master secret", it is the real server itself.

   This "master secret" will be used by both the browser and the server as a seed to create the same "symmetric" keys so that communications can be encrypted at both ends. Remember, any data the server encrypts with its private key can be decrypted by anyone using the server's public key, by definition. So, the server needs an encryption key that only the browser can "decrypt". SSL uses "symmetric" keys for this key exchange because they are much faster (128 to 168 bit long) than using "asymmetric" keys (1024 to 2048 bit long).

5. The server uses its private key to decrypt the "master secret" data. Now both the browser and the server (and no body else) have the same "master secret" data.
6. Both the browser and the server use the "master secret" to generate exactly "same" symmetric keys (called "session" keys) for "writing" (encrypting) and "reading" (decrypting) any further communications with each other.

   Each session uses a different session key, so even the theft of one key (however remote) does not result in multiple session eavesdropping or tampering.

   Actually, in SSL, there are four keys that are called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY, and SERVER-WRITE-KEY. These are all generated from the "master secret".

7. The browser sends a message to the server, informing it that any future messages from the browser will be encrypted with the "session" key. It does not send the "session" key also with the message.
8. The browser then encrypts the "connection ID" originally sent by the server, and a "client-finish" header with the "session" key. It then sends the encrypted data to the server.

   The browser is now done with the "handshake" protocol, and has started the actual SSL session.

   The server decrypts the connection ID with its session key (which is an exact copy of the browser's session key) and compares it with the connection ID it originally sent. If they match, the client has the correct session key.

9. The server also sends a message to the browser, informing it that any future messages from the server will be encrypted with the "session" key. It does not send the "session" key also with the message.
10. The server then encrypts the "challenge" data originally sent by the browser, and a "server-finish" header with the "session" key. It then sends the encrypted data to the browser.

    The server is now also done with the "handshake" protocol, and has started the actual SSL session.

    The browser decrypts the "challenge" data with its session key (which is an exact copy of the server's session key) and compares it with the "challenge" data it originally sent. If they match, the server has the correct session key.

11. SSL session has begun.

    From this point on, if message encryption is active (the default state), SSL encrypts and decrypts the byte stream of the application protocol being used (HTTP etc.) before passing it on to the underlying TCP/IP protocol. This means that all the information in both the HTTP request and the HTTP response is fully encrypted, including the URL the client is requesting, any submitted form contents, any HTTP access authorization information, and all the data returned from the server to the client.

    The browser and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

A Digital Certificate?

• A digital certificate is like a driver's license for the Internet. Unlike passwords, which could be different on every site that you visit, the same certificate can be used everywhere that identification is required. Certificates also allow users to establish confidential communications and detect message tampering.
• Each SSL enabled server must have a digital certificate. During the initial "asymmetric" (secure yet slow) communications between the server and the browser, the server sends its certificate to the browser to authenticate the server's identity. The browser checks to see if the issuing company is a trusted issuer and matches the name on the certificate with the server's name to make sure that the certificate really belongs to the server. The browser then sends some data (the "master secret") to the server encrypted with the server's public key to make sure that the server on the other end possesses the corresponding key and can decrypt the data. Then, the browser and the server use temporary "symmetric keys" (secure and fast) generated for that particular session only to encrypt all the information they exchange for the remainder of the session and to detect any tampering that may have occurred.
• Any client or server software that supports certificates maintains a collection of trusted CA certificates.
• Since 1988, an X.509 v3 certificate is the recommended format for a digital certificate. Among other things, most important information it contains is the user/server's "distinguished name" (DN), his public key, issuer's DN, and the certificate validity dates. A distinguished name looks like: uid=doe,e=doe@netscape.com,cn=John Doe,o=Netscape Communications Corp.,c=US.
• Every X.509 certificate has two sections:
  1. Data Section:
     • Serial Number of the certificate (unique among the certificates issued by the signing issuer)
     • Distinguished name of the user (subject name)
     • User's public key
     • Algorithm used to create the user's public key
     • Distinguished name of the issuing authority (issuer)
     • Validity dates of the certificate
     • Version number of the X.509 standard supported by the certificate
  2. Signature Section:
     • The issuer's digital signature, obtained by hashing all of the data in the certificate together and encrypting it with the issuer's private key
     • The cryptographic algorithm, or cipher, used by the issuing authority to create its own digital signature
• An Example Certificate (View any secure server's Digital Certificate!)

  Certificate:
  Data:
     Version: v3 (0x2)
     Serial Number: 3 (0x3)
     Signature Algorithm: PKCS #1 MD5 With RSA Encryption
     Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US
     Validity:
        Not Before: Fri Oct 17 18:36:25 1997
        Not  After: Sun Oct 17 18:36:25 1999
     Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US
     Subject Public Key Info:
        Algorithm: PKCS #1 RSA Encryption
        Public Key:
           Modulus:
           00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
           ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
           43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
           98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
           73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
           9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
           7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
           91:f4:15
           Public Exponent: 65537 (0x10001)
     Extensions:
        Identifier: Certificate Type
        Critical: no
        Certified Usage:                    SSL Client
  
        Identifier: Authority Key Identifier
        Critical: no
  
        Key Identifier:
        f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
        26:c9
  
  Signature:
     Algorithm: PKCS #1 MD5 With RSA Encryption
     Signature:
     6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
     30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
     f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
     2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
     b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
     4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
     dd:c4

• The same certificate in the 64-byte-encoded format (for interpretation by the reading software):

  -----BEGIN CERTIFICATE-----
  MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzERMA8GA1UEChMITmV0
  c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVa
  MEgxCzAJBgNVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMO
  U3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
  7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7LiQZBcrXpc0k4du+2
  Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZNMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0
  MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNVHSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG
  9w0BAQQFAAOBgQBtI6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
  UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84hW3WWehBUqVK5SY4
  /zJ4oTjx7dwNMdGwbWfpRqjd1A==
  -----END CERTIFICATE----- 

• Different issuers have different procedures for issuing different kinds of certificates. In some cases, the only requirement may be your email address. In other cases, your Unix or NT login and password may be sufficient. At the other end of the scale, for certificates that identify people who can authorize large expenditures or make other sensitive decisions, the issuing process may require notarized documents, a background check, and a personal interview.
• Before a certificate can be issued, the public key it contains and the corresponding private key must be generated. Sometimes, it may be useful to issue a single person one certificate-and-key-pair for signing operations, and another certificate-and-key-pair for encryption operations. Separate signing and encryption certificates make it possible to keep the private signing key on the local machine only, thus providing maximum non-repudiation; and to back up the private encryption key in some central location where it can be retrieved in case the user loses the original key or leaves the company.
• The process for obtaining a digital certificate is:
  1. Generate your key pair (public and private keys) using some software. The private key is usually stored on your computer's hard drive or a floppy disk, but see smart cards.
  2. The public portion of the key pair is sent across the network to the CA (Certificate Authority).
  3. The CA verifies the user's identity the traditional way (asking for his driver's license, passport etc.).
  4. The information about the user and the public key are signed by the CA and the user is notified that the digital certificate is ready to "fetch".
  5. The user accesses a secure (SSL) server over the interne and clicks "fetch". The digital certificate is either displayed in the user's browser as text, or directly installed in the user's browser software. If the user chooses to, he can directly download, export or otherwise save the digital certificate into a file on the hard disk.
  6. The encryption software or browser usually stores your encryption/decryption key on the hard disk and makes you enter a "pass phrase" (some sentence longer than an easily-crackable 6 to 8 letter password) to access it.
  7. To use the key and certificate to digitally sign a document or a file, the user types in his password and enables his browser to use the credentials when signing an email or document. The certificate, being public, is usually available without restriction to the browser or other encryption software.
• A private key usually works only with the software that generated it, whether it be your browser (Netscape, Internet Explorer) or some other encryption software (PGP, GNU Privacy Guard)
• It is the user's responsibility to keep his private key private (secure). If anybody ever gains access to it, he can pose as the user and the remote server will not know the difference (just as if the user's password has been given out to that "anybody").
• The browser keeps all the private keys for all the users that use that computer under their respective passwords. In a browser, the first time the need arises to use a user's private key (e.g. a server requested by the user wants to authenticate the user, the user needs to sign a file or a piece of data before sending it to the server), the browser asks the user for a password. Based on the password supplied by the user, the browser only unlocks that user's private keys. At no time is the private key or the user's password is sent over the Internet (as is the case if a user logs on to a server by supplying a password to the server).
• It does, however, makes the user's private keys vulnerable to theft from the user's computer. An evil hacker can crack the user's password required by the browser and gain access to all his private keys, and use them to pose as the user to the server(s).

  The upcoming Smart cards promise to solve this problem. Your smart card generates and stores your key-pair on a chip (Integrated Circuit or IC) which also has encryption/decryption instructions on it. The key-pair is never sent to or stored on the computer. You insert the smart card into a device which itself is connected to the computer through a cable. When you want to decrypt some data, your computer passes the scrambled data through the smart card's chip by sending it over the cable. The smart card's chip asks you for your PIN (pass phrase). You enter the correct PIN. (If you enter it incorrectly a few times, smart cards and tokens are disabled automatically.) The chip decrypts the data and sends it back over the cable to the computer.

  This way you can carry your smart card around like a credit card and use it on any compliant computer/device, ATM etc.

  ActivCard, Bull Computers, Chrysalis-ITS, SafeNet, Fischer International, Gemplus, Litronic, Schlumberger, Security Dynamics, and VASCO Data Security provide smart cards, smart keys, PCMCIA cards, and hardware tokens to users.

• If the user's company requires the user to backup his keys (in case the user loses a key), retrieval of the backup keys usually involve an m of n mechanism. For example, m of n managers will have to contribute a special code or key of their own before somebody's encryption key can be recovered.

Other Secure Communication Procedures

• S-HTTP is an alternative to SSL but is not as popular. It does not rely on a particular key certification scheme. It includes support for RSA, in-band, out-of-band and kerberos key exchange. Key certifications can be provided in a message, or obtained elsewhere. Like SSL, client public keys are not required.
• Secure Shell (SSH) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. It is intended as a replacement for telnet, rlogin, rsh, and rcp. In case of SSH2, there is a replacement for FTP: sftp.

References

• How SSL Works
• iPlanet's Introduction to SSL
• Verisign's Introductory Material
• Introduction to Public Key Encryption