2. Introduction to Secure Sockets Layer/Private Key Infrastructure
PKI is an asymmetric key system which consists of a public key (which is sent to clients) and a private key (stays local on the server). PKI differs from a symmetric key system in which both the client and server use the same key for encryption/decryption.
2.1 Responsibilities of SSL/PKI
SSL sets out to fulfill requirements that make it acceptable for use in the transmission of even the most sensitive of transactions, such as credit card information, medical records, legal documents, and e-commerce applications. Each application can choose to utilize some or all of the following criteria depending on the sensitivity and value of the transactions it will be processing.
- Privacy
Let's say that a message is to be coded for transmission from A to B. A uses B's public key to encrypt the message. In this way B will be the only person who can decode and read this message using his private key. We cannot however be sure that A is the person who he claims to be.
- Authenticity
In order to be sure that A is the person who he claims to be, we want guaranteed authenticity. This requires a slightly more complex coding process. In this case, A's message to B is first encrypted with A's private key and then with B's public key. B now has to decrypt it first with his private key and then with A's public key. Now B can be sure that A is who he claims to be as nobody else could create a message encrypted with his private key. SSL achieves this with the use of certificates (PKI). A certificate is issued by a neutral third party - such as a certificate authority (CA) - and includes a digital signature and/or a time stamp in addition to the public key of the certified party. A self-signed digital certificate can be created by anyone with the correct SSL tools, but self-signed certificates lack the weight of validation performed by a mutually respected neutral third party.
- integrity
In SSL, integrity is guaranteed by using a MAC (Message Authentication Code) with the necessary hash table functions. Upon generation of a message, the MAC is obtained by applying a hash function and the result is then added to the message. After the message has been received, validity is then checked by comparing the message's embedded MAC with a new MAC computed from the received message. This would immediately reveal messages that have been altered by a third party.
- Non-Repudiation
Non-repudiation protects both parties from each other during online transactions. It prevents one or the other from saying that they did not send a particular piece of information. Non-repudiation does not allow either party to alter the transaction after it has been made. Digital non-repudiation is the equivalent of signing a contract, in the traditional sense.
2.2 How SSL Works
The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client when they first establish an SSL connection. This exchange of messages is designed to facilitate the following actions:
- Authenticate the server to the client. The server certificate is signed by a Certificate Authority to insure that it is not corrupted and establishes a chain of trust.
- Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support.
- Optionally authenticate the client to the server.
- Use public-key encryption techniques to generate shared secrets.
- Establish an encrypted SSL connection.
SSL Handshake Protocol
The Handshake Protocol is used to co-ordinate the state of the client and the server. During the handshake, the following events take place:
- Certificates are exchanged between the client and server (asymmetric keys). The server sends its public key to the client. If the server is set to verify client authentication via a certificate, the client sends its public key to the server. The validity dates on the certificates are verified and they are checked for the digital signature of a trusted certificate authority. If the validity date and/or digital signature are not correct, the browser will issue a warning to the user. The user is then given the option to trust the certificate holder.
- The client then generates a random key (symmetric key). These will be used
for encryption and for calculating MACs. They are encrypted using the
server's public key and sent to the server. Only the server has the ability
to decrypt the new random key. The new symmetric key is used for encrypting
the data that is sent between client and server.
Note: The use of a symmetric key after server-browser authentication greatly enhances subsequent throughput performance.
- A message encryption algorithm and a hash function for integrity are negotiated. This negotiation process could be carried out such that the client presents a list of supported algorithms to the server, which, in turn, selects the strongest cipher available to both of them. Identifiers for the chosen encryption algorithm and hash function are stored in the cipher spec field of the current state for use by the record protocol.
- All of the following fields are set during handshaking: Protocol Version, Session ID, Cipher Suite, Compression Method and two random values ClientHello.random and ServerHello.random.
Note: An IP address is required for each SSL connection. Name based virtual hosts are resolved during the application layer. Remember Secure Sockets Layer resides below the application layer.
Session Key(Symmetric Code)
- 40-bit, originally used only for export purposes
- 56-bit, used by DES
- 64-bit key - used by CAST, 256 times stronger than 56-bit
- 80-bit key - used by CAST, 16 million times stronger than 56-bit (infeasible to break with current technology)
- 128-bit key - used by CAST or RC2, exhaustive key search impossible now and for the foreseeable future
Public/Private Key Pair(Asymmetric Code)
- 512-bit
- 768-bit
- 1024-bit
- 2048-bit
2.3 How PKI Works
The client and the server each have a public key and a private key (the client's browser randomly creates a key pair for the SSL session, unless, a client certificate is held by the client and requested by the server).
The sender uses their private key to encrypt a message. This act authenticates the source of the message. The resulting cipher is encrypted once more with the receiving party's public key. This action provides confidentiality because only the receiving party is able to do the initial decryption of the message using their private key. The receiver uses the sender's public key to further decrypt the encrypted message. Because only the sender has access to their private key, the receiver is assured that the encrypted message originated from the sender.
A message digest is used to verify that neither party or a third party has tampered with or changed the message in any way. A message digest is obtained by applying a hash function (part of the private key known as the fingerprint) to the message. The digest (which is now known as the signature) is attached or appended to the message. The signature's length is constant (no matter how large the file is) and depends on what type of message digest the private key contains (md5 - 128 bit, sha1 - 160 bit, etc). Changing even one bit in the message will change the length of the signature and thus prove that the message has been tampered with.
2.4 Certificates(x509 Standard)
Digital certificates make it possible to trust an entity on the Internet. A digital certificate contains the user's credentials, which have been verified by a neutral third-party certificate authority.
A mathematical algorithm and a value (key) are used to encrypt data into an unreadable form. A second key is used to decrypt the data, using a complementary algorithm and a related value. The two keys must contain a related value and are known as a key pair.
Note: ITU-T Recommendation X.509 [CCI88c] specifies the authentication service for X.500 directories, as well as the X.509 certificate syntax. The certificate is signed by the issuer to authenticate the binding between the subject (user's) name and the user's public key. SSLv3 was adopted in 1994. The major difference between versions 2 and 3 is the addition of the extensions field. This field grants more flexibility as it can convey additional information beyond just the key and name binding. Standard extensions include subject and issuer attributes, certification policy information, and key usage restrictions.
An X.509 certificate consists of the following fields:
- Version
- serial number
- signature algorithm ID
- issuer name
- validity period
- subject (user) name
- subject public key information
- issuer unique identifier (version 2 and 3 only)
- subject unique identifier (version 2 and 3 only)
- extensions (version 3 only)
- signature on the above fields
2.5 Digital Certificate Private Key
The private key is not embedded within a digital certificate. The private key does not include any server information. It contains encryption information and a fingerprint. It is generated locally on your system and should remain in a secure environment. If the private key is compromised, a perpetrator essentially has the code to your security system. The transmissions between client and server can be intercepted and decrypted. This type of vulnerability is why it is recommended to create a private key that is encrypted using triple DES technology. The file is then encrypted and password protected making it all but impossible to use without the correct pass phrase.
The security of a transaction is dependent on its private key. Should this key fall into the wrong hands then anyone can easily duplicate it and use it to compromise security. A compromised key could lead to messages meant for the server to be intercepted and manipulated by unscrupulous hackers. A fully secure system must be able to detect impostors and prevent the duplication of keys.
2.6 Digital Certificate Public Key
The public key is embedded in a digital certificate, which is sent by the server to a client when a secure connection is requested. This process identifies the server using the certificate. The public key validates the integrity, authenticity, and is also used to encrypt data to create a private data transmission.
2.7 Certificate Signing Request(CSR)
A CSR contains the information required by a certificate authority to create the certificate. The CSR contains an encrypted version of the private key's complimentary algorithm, common value, and information that identifies the server. This information includes, but is not limited to, country, state, organization, common name (domain name), and contact information.
Next Previous Contents