Make Sure Your System Is Securely Fastened While Traffic Is Flowing

Mark Gambino, IBM TPF Development

This article presents a history of security concerns involving TCP/IP networks, solutions, and support that have recently been added to the TPF 4.1 system.

Back in the Stone Age . . .

In the 20th century, private networks were common and the threat of attack from outsiders was minimal. However, things have changed dramatically in recent years. As communications technologies evolved, network bandwidth has increased by orders of magnitude and price has dropped substantially. This has resulted in network commoditization where many businesses now outsource the network rather than own large private networks. The other driving force for doing this is to offload the network management responsibilities to a third-party vendor rather than trying to manage larger and complex networks yourself. This all sounds too good to be true, so what's the catch?

The catch is that more of your data is flowing across public networks, which increases the security risks by leaps and bounds. Even if you buck the trends and keep your own large private network, you still have to communicate with a variety of business partners and consumers, which brings public networks back into play. Fighting against the public network environment is a losing battle; therefore, you should accept the fact that more and more of your network traffic is going to flow across networks that are out of your control. The challenge becomes how to communicate in a secure manner across public networks.

TCP/IP, It's None of Your Business . . . or Is It?

TCP/IP has become the predominant networking protocol for business applications. Early attempts at security for public networks used a simple user ID and password approach. While this deterred some attackers, all data, including the user ID and password, flowed as clear text across the network. This meant that anyone in the middle of the network could see the data. (Author's note: This is purely hypothetical---the author has no first-hand knowledge of such devious activities.)

The next approach was to exchange a key offline by some mechanism with a specific business partner (or consumer) and then use that key to encrypt or decrypt messages using that key. If you do not know in advance all the remote users with whom you will communicate, this approach does not work. In addition, the solution relies on "roll your own" support for key exchange and data encryption that varies from platform to platform. A standard method for secure communication across TCP/IP was needed that is robust enough to allow new users to be added "on the fly." Say hello to the Secure Sockets Layer (SSL) protocol.

From Static to Electricity

Early Internet communication was designed for browsing static information like airline or train schedules, meaning that servers served up static Web pages to anyone who wanted them. Because this information is not confidential, there were no security concerns regarding access to this information. As the Internet evolved and the desire to do business transactions across the Web grew, the need for secure Internet communication became more important. In the mid-1990s, Netscape developed SSL version 2 (SSLv2) to enable secure Web communications (note that SSL version 1 was never deployed, which is why we start with SSLv2 in our discussion).

Protecting Your Privacy, Private

After a TCP socket is started (that is, the TCP handshake process is completed), an SSL session is started on top of that socket. The SSL handshake process uses public key cryptography to exchange a secret key between the client and server nodes. Afterwards, all user (application) data that is sent across the SSL session is encrypted using symmetric key cryptography with the key that was created during the SSL handshake process. Public key cryptography is computationally very expensive, meaning that it requires millions of CPU cycles to encrypt data and even more to decrypt that data at the remote end. Symmetric cryptography is much more efficient than public key cryptography and, therefore, a better choice for encrypting large amounts of data. Public key cryptography is very powerful because it allows you to exchange data in such a way that only the client and server nodes can understand the data. Even though anyone along the session path can see the data, they cannot understand the data because it is encrypted using a key that is known only to the client and server nodes. This is called data privacy.

Lack of Integrity Still Exists

Even though people in the middle of the network along the session path cannot understand the data, what prevents them from altering the data? Nothing prevents them, but the remote node needs to be able to detect if the data has been tampered with in flight. This is called data integrity. For example, suppose the data flowing across the SSL session was a financial transaction donating money to a worthy cause like the "M. Gambino Vacation Fund" and a hacker in the network altered a random part of the data that just happened to contain the money transfer amount and, by chance, changed the value from $100 to $100,000. While the charity would thank you for your generosity and enjoy a first-class, 6-month vacation on a tropical island, you would not be very happy when your bank statement indicates that you are broke. SSL ensures data integrity by appending a message digest to each message that is sent. A message digest is a one-way hash function that takes a variable amount of input data and produces a unique fixed-length value. Think of a digest as a fingerprint of the message. The most important aspect of a digest algorithm is that even a small change to the data causes many and unpredictable changes to the corresponding digest. The SSL layer in origin node (client or server) creates the digest and appends it to the message before sending it to the network. The SSL layer in the destination node recalculates the digest and compares that value to the digest value appended to the message. If the values do not match, the data has been altered and the SSL session is ended.

You Don't Look 21 . . . Is That a Fake ID?

So far we have shown that SSL provides data privacy and data integrity, but how can I guarantee that the remote partner is who it claims to be? SSL (optionally) uses digital certificates to verify the identity of the remote partner. This is called authentication. For example, before transferring money to the "M. Gambino Vacation Fund," you want to make sure that the remote SSL node is in fact who it claims to be. A digital certificate identifies who the user is. The certificate is created and signed by a trusted third-party known as a certificate authority (CA). Each node maintains a list of CAs that it trusts. When node X wants to validate the identity of remote node Y when an SSL session is starting, node Y sends its certificate to node X. Node X makes sure that the signature on the certificate is valid (using a technique known as digital signatures) and that the certificate was issued by a CA that node X trusts. The authentication process is more involved than this because it uses public key cryptography to verify that you are really the owner of the certificate in question and not pretending to be someone else sending that user's certificate instead of your own. Many people think of a certificate as a passport, but others have a hard time accepting the analogy that considers the issuer of a passport (the government) to be a "trusted" party. In many ways a certificate is like a credit card because it has an expiration date and is your ticket to secure transactions.

A Protocol by Any Other Name Would Smell As Sweet

SSLv2 supported Rivest-Shamir-Adleman (RSA) public key cryptography and the MD5 digest algorithm. Soon after SSLv2 was deployed, Netscape created SSL version 3 (SSLv3) to fix known problems in SSLv2 and to support more public key cryptography and message digest algorithms. SSLv3 has been widely deployed in the industry. Other companies, including one we will call Macrohard (not their real name), created their own SSL-like spinoff protocols. Because of the popularity and capabilities of SSL that encompass more than just Web serving, the Internet Engineering Task Force (IETF) recognized the need for a security standard and created the Transport Layer Security (TLS) working group to define a standard. The result was something almost identical to SSLv3. They needed a name for this standard protocol and, seeing that there was obviously no one from marketing on the TLS working group, they named the protocol Transport Layer Security (TLS). TLS version1 (TLSv1) is defined by RFC 2246.

The Glass Is Half Empty and Half Full

TLS defines the protocol flows between client and server nodes, but that is only half the battle. An application programming interface (API) for SSL (or TLS) was never standardized. This led to platform- and product-specific SSL APIs. Porting SSL applications and interaction between certain platforms became troublesome. This led to the creation of OpenSSL, which is open source code that provides SSL support for many different platforms. OpenSSL contains a rich set of SSL APIs, an extensive cryptography library written by Eric Young, and is available for free at http://www.openssl.org.

Will Someone Please Call Security!

TPF ported and tested OpenSSL version 0.9.6 and then shipped the support as APAR PJ27863. Slight modifications were necessary, mainly to enable time slicing in the CPU-intensive routines. Therefore, you must use the code shipped with APAR PJ27863 rather than downloading and installing the code directly from the OpenSSL Web site. APAR PJ27863 provides support for the following:

• SSL version 2, SSL version 3, and TLS version 1
• RSA public key cryptography
• RC2, RC4, Data Encryption Standard (DES), and Triple-DES ciphers
• MD5 and SHA digest algorithms
• Client and server authentication using digital certificates
• A single x509 certificate or a chain of x509 certificates
• Certificate revocation lists (CRLs)
• Use of any SSL toolkit to create public and private keys and certificates for use on TPF.

Return to the Newsletter table of contents