The Secure Socket Layer (SSL)
The Secure Socket Layer (SSL) was designed for secure communications. Secure communications have three properties: confidentiality , message integrity , and end-point authentication . Confidentiality means that your message is kept secret from unintended listeners - usually called eavesdroppers . Message integrity means that you can identify whether your message has been tampered with - you want to be sure you receive the same message you were sent. End-point authentication means that you can be confident of the person who sent you the message. Two important goals of SSL are to provide confidentiality between client and server and to ensure that only the correct end-points can transfer data. The API goals of SSL are to mimic the Socket API as closely as possible to provide an easy way to move code from Sockets to SSL. This section first explores some of the history behind SSL and TLS. It then describes digital signatures and message digests , which along with symmetric ciphers and public key ciphers are the four fundamental types of algorithms used in SSL. HistoryIn the early 90s, using BSD Sockets, the Socket Application Program Interface was used to develop network protocols in the C language on UNIX; later it was the basis for the NT operating system using WinSock. At the time, there were no standards, just Cipher libraries. Therefore, there was not a standard way for clients and servers to exchange keys, and there was no way to ensure other client vendors used the same package. This made the support for network protocol cumbersome at best. In 1994, Netscape created the Secure Socket Layer (SSL v1.0) as a wrapper for the Socket API; version 2 was released initially in November 1994 and deployed in Netscape 1.1 in March 1995. Also in 1995, Microsoft released Private Communications Technology (PCT), which (among other things) improved performance and included a non-encrypted mode. In late 1995, SSL v3 was released. SSL v3 is a complete rewrite of SSL; it added ciphers, such as Digital Signature Standard (DSS) and Diffie-Hellman (DH), and added support for a closure handshake.
SSL is a layered protocol that sits on top of TCP, as Figure 22-1 shows.  Figure 22-1: SSL layering In 1996, the Internet Engineering Task Force (IETF) initiated the Transport Layer Security (TLS) working group to create a standard SSL-like protocol (that is, merge/standardize PCT and SSL v3). Because of some obstacles and complexity, it was not until January 1999 that TLS was published as RFC 2246. Digital signaturesDigital signatures are based on the same concept as a person signing a document. For example, assume a bank sends a person a document to be signed and requires the document to be returned. Once the bank receives the document back, how does it know it has a valid signature? The bank may have the person's signature on file and compare it to the document, and if the signatures appear the same, the bank accepts the document. However, there are people who can forge signatures very easily. Another solution is to require the person to present identification verified from a trusted third party; but sometimes more than this type of authentication is needed, such as when it is possible to forge the document and/or identification. Direct digital signaturesThere are two types of digital signatures: direct digital signatures and arbitrated digital signatures . The direct digital signature is just between the sender and receiver; it uses a key to decrypt the message. If there are only two people in the group that share the key, trusting that it came from the other person who has the secret key can be somewhat valid. Once the group grows beyond two people, copies could start to appear and managing the digital signature becomes an issue. One method of ensuring who encrypted a message is by applying the key pair algorithm. Consider the following example: A person receives a message from Jane, and if the message decrypts with Jane's public key using the key pair algorithm, the receiver can somewhat trust that Jane used her private key to encrypt the message and that, therefore, the message is valid. However, the integrity of the message can be compromised if the secret key or the private key is stolen. Arbitrated digital signaturesAn arbitrated digital signature involves a sender, a trusted third party, and a receiver. The trusted third party, such as a Certificate Authority (CA) in the Authentication Principle, ensures authenticity and acts as an arbitrator. The idea is that every signed message between the sender and receiver goes through an arbitrator, which all parties must trust. The arbitrator receives the message from the sender, validates that the message came from the sender, signs it saying that it was verified, and forwards it to the receiver. Since the receiver trusts the arbitrator, the message is accepted. One way the message verification may work is to establish a secret key between the arbitrator and the sender and another secret key between the arbitrator and the client. The arbitrator decrypts the sender's message using his secret key, then encrypts the message using the other key, and sends the newly encrypted message to the receiver.
Message digestA message digest is simply a function that takes as input an arbitrary-length message and outputs a fixed-length string. Two important properties of a message digest are irreversibility and collision resistance. Irreversibility means that it should be extremely hard to compute a message given its digest. Collision resistance means that it should be difficult for the same digest to be produced from two distinct messages. Message digests are used for the computation of digital signatures and message authentication codes (MACs). A MAC is similar to a digest algorithm that incorporates a key into the computation. This makes the MAC dependent on both the key being used and the message being MACed. The MAC is an authentication code added to the message to validate that the message is reliable; it is typically a one-way hash and is rehashed to ensure that the hashes compare. Usually, the MAC consists of the packet's sequence number, type of packet, and data.
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
