Encryption

Beyond securing files and directories against unauthorized access, developers need to effectively protect sensitive information transmitted over a network from all forms of interception and tampering. This is particularly important with information transmitted over the Internet. Today, users visiting commercial Web sites are sometimes reluctant to supply sensitive information, such as a credit card or bank account number, for fear that computer vandals will intercept this information. To address this type of security concern, we'll take a look at several methods developers can use to encrypt sensitive information.

Security-Related Protocols

Security-related protocols contain built-in authentication and encryption mechanisms. All applications need to do to utilize these mechanisms is incorporate the protocol.

Developers may find it helpful to understand in which Open Systems Interconnection (OSI) layer the protocol is functioning to understand the scope of security the protocol provides. Where the protocol function determines the scope of data that it protects, ranging from a single application to a complete network. For example, protocols functioning at the application layer implement security on a per-application basis. Hypertext Transfer Protocol Secure (HTTPS) and NTLM are examples of protocols that operate in the OSI application layer. Some protocols create tunnels, or virtual connections, that allow network communication to occur between network devices. Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP) are examples of protocols used to create virtual connections for virtual private networks. PPTP and L2TP operate at the OSI datalink and network layers.

Another important issue to keep in mind is that security-related protocols are effective only because of the way they encrypt authentication information and data. Table 11.1 shows the security-related protocols we'll be discussing throughout this chapter, including their relation to the OSI layers and the methods they use to encrypt information.

Table 11.1 Security-related protocols

Protocol	OSI Layer	Authentication	Encryption	Transport
L2TP	Datalink	CHAP, PAP, MS-CHAP	RC4, DES	IP, IPX, NetBEUI
PPTP	Datalink	CHAP, PAP, MS-CHAP	RC4	IP, IPX, NetBEUI
HTTP/SSL	Application	X.509	RC2, RC4, DES	IP
IPSEC	Network	HMAC-MD5, HMAC-SHA, DH	DES	IP
SMB/NTLM	Application	Challenge/response	DES, MD4	IP, IPX,NetBEUI

Secure Sockets Layer (SSL)

IIS 4.0 provides privacy, integrity, and authentication in point-to-point communications through Microsoft's Secure Channel technology. In particular, the SSL 3.0 protocol, implemented as a Web server security feature, provides a secure and virtually impervious way of establishing an encrypted communication link with users. SSL guarantees the authenticity of Web content, while reliably verifying the identity of users accessing restricted Web sites.

NOTE

---

IIS 4.0 also supports the Private Communication Technology (PCT) 1.0 protocol. Similar to SSL, PCT 1.0 includes hardy and efficient encryption features for securing communications.

With SSL, the server and the user's Web browser engage in a negotiating exchange that involves the certificate and the key pair to determine the level of encryption required for securing communications. The server and the browser set up an encrypted session that only they can understand. This exchange requires that both the server and the browser be equipped with compatible encryption and decryption capabilities. The end result of the exchange involves the creation (usually by the browser) of an encryption key, or session key. Both the server and the browser use the session key to encrypt and decrypt transmitted information. The session key's degree of encryption, or strength, is measured in bits. The greater the number of bits comprising the session key, the greater the level of encryption and security. The server's session key is typically 40-bits to 128-bits.

Keys are created in pairs consisting of a public key and a private key. The public key is given to anyone (and is often made available though a public agency, such as a certificate authority). The private key is kept and safeguarded by the key requestor. Both keys are required for any exchange of information. To configure SSL on the Web server, a key must be generated and configured to work with the Web server. The IIS Key Manager is used to generate the key pair request and to activate the generated key. A secure server key can be created from the key request file using Microsoft Certificate Server or by using the key request file to obtain a key from a third-party provider such as VeriSign or Entrust.

Theoretically SSL can transparently secure any TCP/IP-based protocol running on any port if either the browser client or Web server know the other is using SSL. However, in practice, separate port numbers have been reserved for each protocol commonly secured by SSL so that packet-filtering firewalls can allow secured traffic through.

Internet Explorer encrypts data—such as HTML forms containing private information—by using the server's public key. The encrypted data is sent to the server, which decrypts the data using its private key. (The data can be decrypted only with this private key.)

Encrypting only communication that contains private data, such as credit card numbers, addresses, or company records, is the most effective use of SSL. Because SSL uses a computer's processor to encrypt data, it takes much longer to retrieve and send data from SSL-enabled directories. In an SSL-enabled directory, place only those pages that have or will receive sensitive information. Also, keep the content of pages in an SSL-enabled directory free from unnecessary elements because every item on the page will be encrypted, including simple graphics. Every element on the page increases the time it takes to transmit the data.

SSL, IIS 4.0, and Microsoft Proxy Server

SSL was designed to eliminate "man-in-the-middle" attacks, where an entity might try to step between the client and the server. As a result, SSL does not work directly with proxy servers, and to incorporate the SSL protocol with proxy servers, such as Microsoft Proxy Server, developers must allow direct access through an unrestricted proxy server port. Then, the client can communicate directly with the server using SSL. Of course, SSL must be set up properly on the hosting server, and allowing direct access does create additional security concerns. For example, if Microsoft Proxy Server 2.0 is installed on the IIS 4.0 computer, Web Publishing must be enabled. In addition, if Packet Filtering is being used, a packet filter for TCP Port 443 must be added. Enabling Web Publishing allows Web clients to directly communicate with the Web server. Additionally, creating a filter for port 443 on the proxy server allows SSL traffic to be sent directly to the Web server so that it can communicate directly and securely with the client.

Server Gated Cryptography

Server Gated Cryptography (SGC) is an extension to the SSL security protocol that allows financial institutions to provide secure Web services for their customers, no matter where they might be, without the need to change Web browser or server software. SGC allows international banks to build computer infrastructures based on the Microsoft BackOffice family that interoperate with a range of popular client software, including Internet Explorer versions 3.02, 4.0, and 5.0, Microsoft Money 98, and Netscape Navigator 4.0. SGC is included in all of Microsoft's current Web client and server software, and previous versions of these products can be upgraded by downloading a file from the Microsoft SGC Web page at www.microsoft.com/security/tech/sgc/. Microsoft's SGC product is fully compatible with Netscape's SGC product.

For online banking to be secure, both the bank and the customer must be able to verify that each is who they say they are. For example, a bank wants to protect John Smith's banking information from anyone except for John Smith. Likewise, John Smith wants proof that he is genuinely communicating with his bank, and not with a software criminal or other individual wishing to violate his account.

SGC leaves it to the bank to determine how to verify users' identities, but most choose to require that the customer provide a user ID and a password at the start of each online banking session. SGC requires that the bank prove its identity to the customer's software using a digital certificate. Like any other digital certificate, the bank's certificate is a collection of data that uniquely identifies its owner. The certificate is generated by a trusted third-party organization that is in the business of issuing certificates. By using public key cryptography, this certificate authority ensures that, although anyone can read the certificates that it issues, only it can create them after carefully checking the recipient's identity. Certificates are cryptographically protected against counterfeiting, forgery, or modification.

Until now, strong encryption products have been unavailable to the worldwide banking industry. U.S. export laws regarding cryptographic software have prevented banks and other financial institutions from providing security to their World Wide Web services using the high-security products available in North America. Unlike SSL, which must be produced in both an exportable version that uses a 40-bit cryptographic key and a North American version that uses a 128-bit key, a single version of SGC that uses a 128-bit key worldwide can be produced. This development is a result of a U.S. Department of Commerce decision to license the export of strong cryptographic products in cases where it is possible to restrict them to financial institutions.

To obtain an SGC digital certificate, a bank must prove that it is a bona fide financial institution. This is usually done by providing a Dun & Bradstreet DUNS number or an American Banking Association number, but also can be done by submitting documents from a state, provincial, or national government verifying that the institution has been chartered as a bank. This level of proof is necessary to ensure compliance with the U.S. Department of Commerce provision that only financial institutions be granted license to export SGC. A full listing of the certificate authorities that provide digital certificates for use with SGC is available on the Microsoft SGC Web page.

Once issued, the certificate is installed in exactly the same way as an SSL certificate in the bank's Web server software. Each time an SGC customer starts a session with the bank's server, the bank's server automatically sends its certificate to the customer. The exchange happens behind the scenes, and neither party has to take any action. When the bank provides its digital certificate to the customer's software, the software checks that the certificate is valid and that it vouches for the bank's identity. Once this has been done, the banking session can begin.

SGC enables Web client and server software to dynamically determine the encryption level of an SSL session. It is implemented as an extension to the SSL protocol and its successor, the Transport Layer Security (TLS) protocol. To use SGC, both the client and server must be running software that implements SGC. When a customer connects to an SGC-secured Web site, the browser software and the Web server software initiate a normal SSL connection. During the "handshake" portion of the session, the client checks the server's digital certificate and looks for special data in the certificate that indicates the server can participate in an SGC session. If the special data is not in the certificate, the client negotiates a normal SSL session using a 40-bit key. However, if the special data is in the certificate, the client resets the handshake and negotiates a session using one of the following crypto algorithms and a corresponding key:

• 128-bit RC4
• 128-bit RC2
• 56-bit DES
• 3Key 3DES (pending final approval by the U.S. Department of Commerce)

CryptoAPI

CryptoAPI, which ships as part of Windows NT 4.0 and Internet Explorer 3.0 and later, was designed to take the task of cryptography off the shoulders of developers. It includes the Cryptographic Service Provider (CSP) interface, which makes accessing cryptography easier by allowing developers to change the strength and type of their cryptography without modifying application code.

CryptoAPI frees applications from having to do their own encryption. It provides extensible, exportable, system-level access to common cryptographic functions such as encryption, hashing, and digital signatures. Any application written with CryptoAPI can use certificates that support the X.509 standard. This standard enables any standards-compliant application or system to access the Web server from any platform, including the UNIX and Macintosh platforms.