Secure communications using Transport Layer protocols.
FORTEZZA & SKIPJACK
Explosion of Internet, decrease of computer prices and introduction of different mobile devices, need to perform financial transactions remotely, increased requirements for use of security and cryptography in distributed systems. A lot of companies work on different technologies. To enable security, when information is transmitted, there are several transport level security protocols developed and are being considered by the IETF (The Internet Engineering Task Force).
Main stream general purpose protocols are SSL (Secure Socket Layer) specifications from Netscape, PCT (Private Communication Technology) protocol developed by Microsoft and Visa International.
IETF has a Transport Layer Security working group which is a focused effort on providing security features at the transport layer. Their work has resulted in release of TLC (Transport Layer Security) protocol. TLC version 1.0 is the open successor to the widely deployed SSL version 3.0 standard. TLC is based on SSL and PCT and currently is replacing both of them.
What is SSL?
The SSL (Secure Socket Layer) was developed by Netscape Communications Corporation to provide security and privacy over the Internet. The protocol supports server and client authentication. The SSL protocol is application independent, allowing protocols like HTTP, FTP, and Telnet to be layered on top of it transparently. The protocol begins with a handshake phase that negotiates an encryption algorithm and (symmetric) session key and that authenticates a server to the client (and, optionally, vice versa) based on certified asymmetric public keys. Once transmission of application protocol data begins, all data is encrypted using the session key negotiated during the handshake. It allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
Protocol does not specify any details about verification of certificates with respect to certification authorities, revocation lists, and so on. Rather, it is assumed that protocol implementations have access to a "black box," which is capable of ruling on the validity of received certificates in a manner satisfactory to the implementation's user. Such a ruling may, for instance, involve remote consultation with a trusted service, or even with the actual user through a text or graphic interface. In addition to encryption and authentication, protocol verifies the integrity of messages using a hash function-based message authentication code (MAC).
The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP), is the SSL Record Protocol. The SSL Record Protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the SSL Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. One advantage of SSL is that it is application protocol independent. A higher level protocol can layer on top of the SSL Protocol transparently. The SSL Handshake Protocol consists of two phases, server authentication and client authentication, with the second phase being optional. In the first phase, the server, in response to a client's request, sends its certificate and its cipher preferences. The client then generates a master key, which it encrypts with the server's public key, and transmits the encrypted master key to the server. The server recovers the master key and authenticates itself to the client by returning a message encrypted with the master key. Subsequent data is encrypted with keys derived from this master key. In the optional second phase, the server sends a challenge to the client. The client authenticates itself to the server by returning the client's digital signature on the challenge, as well as its public-key certificate.
A variety of cryptographic algorithms are supported by SSL. During the "handshaking" process, the RSA public-key cryptosystem is used. After the exchange of keys, a number of ciphers are used. These include RC2, RC4, IDEA, DES, and triple-DES. The MD5 message-digest algorithm is also used. The public-key certificates follow the X.509 syntax
The SSL protocol provides connection security that has three basic properties:
1. The connection is private. Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption (e.g., DES, RC4, etc.)
2. The peer's identity can be authenticated using asymmetric or public key, cryptography (e.g., RSA, DSS, etc.).
3. The connection is reliable. Message transport includes a message integrity check using a keyed MAC (message authentication codes). Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.
SSL creates extensible framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: to prevent the need to create a new protocol (and risking the introduction of possible new weaknesses) and to avoid the need to implement an entire new security library.
The SSL Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size which can be fragmented into blocks into SSLPlaintext records of 16K bytes or less.
All records are compressed using the compression algorithm defined in the current session. Which could be defined as CompressionMethod.null.
All records are protected using the encryption and MAC algorithms which again could be NULL which does not provide any security.
Once the handshake is complete, the two parties have shared secrets which are used to encrypt records and compute keyed message authentication codes (MACs) on their contents. Transmissions also include a sequence number so that missing, altered, or extra messages are detectable.
If stream cipher is used then it encrypts the entire block, including the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet.
For block ciphers (such as RC2 or DES) padding is added to force the length of the plaintext to be a multiple of the block cipher's block length.
How Handshake is performed
When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. These processes are performed in the handshake protocol, which can be summarized as follows:
The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: protocol version, session ID, cipher suite, and compression method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.
Then server will send its certificate. Additionally, a server key exchange message may be sent, if it is required. Server may request a certificate from the client, if that is appropriate to the cipher suite selected.
Now the server will send the server hello done message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response.
If the server has sent a certificate request message, the client must send either the certificate message or a no certificate alert. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.
At this point, a change cipher spec message is sent by the client. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own change cipher spec message and send its Finished message under the new Cipher Spec. At this point, the handshake is complete and the client and server may begin to exchange application layer data.
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Both the client and the server provide part of the random data used to generate the keys for each connection. (The client and server random portions from the connection that initiates a session are also used to generate the master secret associated with that session.) Additionally, each record is protected with a MAC that contains a sequence number for the message.
What is the difference between SSL 2.0 and 3.0?
Security improvements:
1. SSL 2.0 is vulnerable to a "man-in-the-middle" attack. By editing the list of ciphersuite preferences in the hello messages, an active attacker can invisibly edit the list of ciphersuite preferences in the hello messages to invisibly force both client and server to use 40-bit encryption. SSL 3.0 defends against this attack by having the last handshake message include a hash of all the previous handshake messages.
2. SSL 2.0 uses a weak MAC construction, although post-encryption seems to stop attacks. This is fixed in 3.0.
3. SSL 2.0 feeds padding bytes into the MAC in block cipher modes, but leaves the padding-length field unauthenticated, which could allow active attackers to delete bytes from the end of messages. This, too, is fixed in 3.0.
4. In SSL 3.0, the Message Authentication Hash uses a full 128 bits of keying material, even when using an Export cipher. In SSL 2.0, Message Authentication used only 40 bits when using an Export cipher.
1. In SSL 2.0, the client can only initiate a handshake at the beginning of the connection. In 3.0, the client can initiate a handshake routine, even in the middle of an open session. A server can request that the client start a new handshake. Thus, the parties can change the algorithms and keys used whenever they want.
2. SSL 3.0 allows the server and client to send chains of certificates. This allows organizations to use a certificate hierarchy that is more than two certifications deep.
3. SSL 3.0 has a generalized key exchange protocol. It allows Diffie-Hellman and Fortezza key exchanges and non-RSA certificates.
4. SSL 3.0 allows for record compression and decompression.
1. SSL 3.0 can recognize an SSL 2.0 client hello and fall back to SSL 2.0. An SSL 3.0 client can also generate an SSL 2.0 client hello with the version set to SSL 3.0, so SSL 3.0 servers will continue the handshake in SSL 3.0, and SSL 2.0 server will cause the client to fall back to SSL 2.0.
What is PCT and let compare it with SSL?
PCT (Private Communication Technology) a protocol developed by Microsoft and Visa International for secure communication on the Internet. The protocol is quite similar to SSL in many respects, and in fact the message formats are similar enough so that a server can interact with clients supporting SSL as well as client supporting PCT. According to the specification, PCT "corrects or improves on several weaknesses of SSL." The following are the main differences:
PCT involves fewer messages between the client and the server than SSL, and the messages themselves are shorter.
PCT has more choices in the negotiation of algorithm and data formats than SSL, and the negotiation has additional cryptographic protection so that the client and server can verify that their choices have not been modified.
Message authentication and encryption in PCT uses different keys. In SSL, both involve the same keys. This means in particular that in PCT, authentication can involve longer keys than encryption (encryption key length may be limited by export restrictions), and can thus be more secure.
In the PCT authentication protocol, the client's response depends on the negotiated encryption algorithm, where as in SSL it is independent of the algorithm. This provides a kind of "firewall" so that an opponent who recovers the encryption key in a session with one choice of algorithm (e.g., a weak algorithm) cannot subsequently compromise a session with another choice of algorithm (e.g., a strong one). SSL does not have this "firewall."
A security hole in SSL's client authentication has been repaired; the PCT client's authentication challenge response now depends on the type of cipher negotiated for the session. SSL's client authentication is independent of the cipher strength used in the session and is also independent of whether the authentication is being performed for a reconnection of an old session or for a new one. As a result, a man-in-the-middle attacker who has obtained the session key for a session using weak cryptography can use this broken session to authenticate as the client in a session using strong cryptography. If, for example, the server normally restricts certain sensitive functions to high-security sessions, this security hole allows intruders to circumvent the restriction.
A verify-prelude field has been added to the handshake phase to allow the client and server to check that the cipher type (and other) negotiations carried out in the clear have not been tampered with. (SSL version 3 uses a similar mechanism, but its complete version 2 compatibility negates its security function by allowing adversaries simply to alter version numbers as well as cipher types.)
"FORTEZZA" is a registered trademark held by the NSA (National Security Agency). This is a family of security products. This family includes PCMCIA-based cards, compatible serial port devices, combination cards (e.g., FORTEZZA/Modem and FORTEZZA/Ethernet), server boards, and others. "FORTEZZA-enabled" are other hardware and software products that have had FORTEZZA security integrated. Examples include E-Mail, File Encryptors, WWW browsers, databases, digital cellular telephones, and routers.
The initial FORTEZZA development was started to create a user-friendly, low cost security device for the Defense Message System. To be flexible, the card was designed to be a general purpose cryptographic "co-processor" that could be used in numerous applications. FORTEZZA provides convenient, fast, security services such as data integrity (via the Secure Hash Algorithm), Authentication and Non-Repudiation (via the Digital Signature Algorithm), and Confidentiality (via the Key Exchange Algorithm and SKIPJACK Algorithm).
Netscape offers client and server products with FORTEZZA such as Netscape Communicator 4.04 with FORTEZZA, Netscape Enterprise Server 3.5 with FORTEZZA, Nescape Messaging Server 3.5 with FORTEZZA, Netscape Collabra Server 3.5 with FORTEZZA, Netscape Directory Server 3.0 with FORTEZZA, and Netscape Proxy Server 2.0 with FORTEZZA - each of which provides a unique web-based solution by integrating FORTEZZA security features in a commercially available, off-the-shelf package.
Netscape's products work with the FORTEZZA Crypto Card, a hardware-based security token, to provide cryptographic services such as data confidentiality, user authentication, and data integrity. Support for FORTEZZA has been added to the Secure Sockets Layer (SSL) protocol, which provides a straightforward way to add encryption features to existing applications and network infrastructures.
Skipjack Review
On June 23 1998 the Department of Defense announced the decision by the National Security Agency to declassify both the Key Exchange Algorithm and the SKIPJACK encryption algorithm used in the FORTEZZA personal computer card. This is the first time that the NSA has declassified such information and made it commercially available.
SkipJack is the secret key encryption algorithm used by the US government in the Clipper chip and Fortezza PC card. It was implemented in tamper-resistant hardware and its structure had been classified since its introduction in 1993. It uses an 80 bit key, 32*4=128 table lookup operations, and 32*10=320 XOR operations to map a 64 bit plaintext into a 64 bit ciphertext in 32 rounds.
The SKIPJACK algorithm was developed by NSA and is classified SECRET. It is representative of a family of encryption algorithms developed in 1980 as part of the NSA suite of "Type I" algorithms, suitable for protecting all levels of classified data. The specific algorithm, SKIPJACK, is intended to be used with sensitive but unclassified information.
In a brute-force attack a way of looking at the problem is by comparing a brute force attack on SKIPJACK with one on DES, which uses 56-bit keys. Given that no one has demonstrated a capability for breaking DES, DES offers a reasonable benchmark. Since SKIPJACK keys are 24 bits longer than DES keys. Under an assumption that the cost of processing power is halved every eighteen months, it will be 36 years before the cost of breaking SKIPJACK by exhaustive search will be equal to the cost of breaking DES today. Thus, there is no significant risk that SKIPJACK will be broken by exhaustive search in the next 30-40 years.