30 Minute Guide to e-Commerce Security
Yaacov Apelbaum is the Principal Software Architect in WU's eCommerce Technology and Solutions Group. In this capacity he is responsible for the development of payment systems, BI, platform integration technologies, transactional security, B2B, eCommerce, and web based decision-support systems.
2
Applicable Technology: Operating Systems: Web Servers: Web Browsers:
Windows Server 2000-2003, .NET IIS 5.0 and 6.0 None specific
Introduction While not a security access control mechanism per se, encryption is the process of encoding a message using some form of key also known as chipper. Cryptography permits us to transmit data securely over any type of a communication channel (digital or hand written). If you are planning an exchange gateway on the Internet, you will need to assure your users and partners that the information transmitted is not being intercepted and used by unauthorized parties for nefarious purposes. Contrary to what the name may suggest; encryption is not an act of putting someone into a crypt. But rather, it is the process of converting plain text into text that is ― encoded‖ via a special algorithm. In order to read an encrypted message, the ―e ncoded‖ text must be decrypted back into plain text. This is done via the use of an algorithm. Cryptography is as old a human writing; some of the documented instances of its use go back almost 4000 years.1 Traditionally, this ancient science was primarily used for a variety of purposes, but it found a special utilization in military and diplomatic communications. The majority of the currant cryptographical methods originate from the following two concepts: Substitution and Transposition.
Substitution
Refers to plainly substituting letters, words or parts of words with other symbols. The Bible contains several example of this technique. In one example, the writer used a substitution cipher in which the first letter of the word is replaced the last, the second by the next to last, etc. Thus, Babylon comes out Sheshach or Sheshech. The following is an example for the implementation of the Atbash algorithm: Original Text: Encrypted Text:
ABCDEFGHIJKLMNOPQRSTUVWXYZ ZYXWVUTSRQPONMLKJIHGFEDCBA
Another example of this Substitution is a Caesar Shift. In this algorithm each letter is replaced with another letter X steps from it. Where X in the case the English alphabet is a number between 1 and 25. According to Suetonius (Caius Suetonius Tranquillus c. A.D. 69–c. A.D. 140, Roman biographer), Julius Caesar used to write all confidential communications it in cipher, ― that is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these, and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A‖2 Below is an example of another substitution cipher. Each letter is replaced by a letter 2 steps further in the alphabet: 1
You can find excellent information on the basics of cryptography in: Applied Cryptography Second Edition By Bruce Schneier John Wiley & Sons, 1996 2 De Vita Caesarum, Divus Iulius (The Lives of the Caesars, The Deified Julius) 3
Original Text: Encrypted Text:
ABCDEFGHIJKLMNOPQRSTUVWXYZ YZABCDEFGHIJKLMNOPQRSTUVWX
Transposition Refers to the process of systematically mixing the letters of the original message by shifting individual words predefined number of spaces. This process creates, a message that appears to be made-up of series of random letters. By placing this encrypted text over a special viewer (cylinder) it is possible to recover the original message. One famous example of this technique is attributed to Lysander of Sparta (404 B.C.E). According to the story, a messenger gave him his belt that had a series of random letters written on it. By winding the belt around a wooden staff Lysander was (see Figure 1) able to read the original message.3
Figure 1: Text encryption and decryption via transposition
Both above-mentioned encryption methods, Substitution and Transposition involve the usage of a symmetric key. Regardless of the algorithm you use to encrypt the message, you need to utilize the same algorithm to reverse and decrypt the original message. In some utilization, the distribution of these keys can be a problem. For example, If two parties, Jill and Jack want to communicate secretly they must either first meet so they can agree on a key, or they must have a third party deliver the key to them. If the key then gets into the wrong hands they will no longer be unable to communicate secretly.
Modern Cryptography In recent years, developments in cryptography have added additional functionality to simply making text unreadable (or encoded) to third parties, some of these new additions include support for authenticating users on networks, ensuring the integrity of transmitted information, and support certified message delivery and repudiation (the cure to the ―I t wasn’t me‖ argument). In a world of booming electronic commerce and the proliferation of the ― insecure‖ Internet, the need for secure communications is obvious. Cryptographic technology provides the enterprise with additional layers of security to protect their critical information from prying eyes. Cryptography-based security technologies are implemented by using various security protocols. For example, a secure mail systems solution can be achieved by implementing the SMIME protocol, or secure network communications can be implemented by using the IPSec suite of protocols (Cerberus is one example). The same approach can be used to enable secure Web communications by implementing the TLS protocol (SSL is one example). A simplified encryption process typically follows the steps seen in 3
Plutarch Life of Lysander translated by John Dryden
4
Figure 9. Once the message is encrypted, the only way to reproduce the original message is through the reuse of the appropriate key.
Figure 2: Steps involved in typical encryption process
Symmetric Key Cryptography – Private Keys The Symmetric key family of algorithms is by far the quickest and most commonly used. These algorithms require that receiver and sender of a message share a secret key. Each of the parties must know the secret key in order for this scheme to work. In symmetric key cryptography, the algorithm used to encode a message does not have to be kept secret. It is the decoding function (the secret key) that has to be safeguarded. Some of the main examples of symmetric key algorithms used today are: RC2, IDEA, Data Encryption Standard (DES), RC4, and SkipJack.
Figure 3: The symmetric key encryption process In symmetric cryptography (see Figure 3), the encryption algorithm requires the same secret key to be used for both encryption and decryption. Because of the type of key, this is sometimes called secret key encryption. The advantage of these algorithms is that they are fast and efficient. However, the problem is that of key exchange - it is, the mechanism for safely ensuring both parties, the sender and the receiver, have the secret key. This is one of the weakest areas of symmetric cryptography. How do you send the key to your partners? You cannot just send it in an email message, because it could then be intercepted and compromise your security. Furthermore, how can you be sure that your partners will keep your key secure and not share it with the rest of the world?
Asymmetric Cryptography – Public and Private Keys In public key category of cryptography, we do not use the shared secret key. Instead, dual keys, called Key-Pairs, are created at the same time (see Figure 4). These keys have a mathematical relationship and are created by using large prime numbers. Obtaining one side of the pair does not realistically permit you to determine the other number in the key pair. By design the Key-Pair contains a public key and a private key. The public key is the key that you hand out; the private key is the key you keep for yourself, usually 5
this key is kept on the same machine that generated it. If a private key is used to encrypt a message, only the public key can be used to decrypt it. On the other hand, if a public key is used to encrypt a message, only the private key can be use to decrypt it. Due to its nature, public key cryptography is slower than symmetric key cryptography because of the additional processing overhead it requires, because of this it is rarely used for bulk encryption.
Figure 4: Asymmetric key encryption process Because of the complexity and the relationship between the public key and the private key it also means that, provided the keys are long enough, it is practically impossible to determine one from the other. One of the problems with asymmetric cryptography is that the processing required is very hardware intensive roughly 1,000 times slower than symmetric algorithms. It is impractical to use them to encrypt large amounts of data unless special encryption hardware is implemented. Many current cryptography schemes use a combination of both symmetric key and public key cryptography. In practice, public-key algorithms commonly are used to encrypt-decrypt session keys and symmetric algorithms are used to encrypt-decrypt the message. Some of the main examples of asymmetric key algorithms used today are: Diffie-Hellman, RSA, and Pretty Good Privacy (PGP).
Digest and Hash: Sounds Like Breakfast Much like the culinary breakfast hash (pastrami, eggs and potatoes), a cryptographic hash function in similar way. It allows us to input data (such as a document and signature) and then ―M oosh‖ that data into a more condensed form (i.e., really big number), called a Digest. In cryptography, a one-way hash is 6
used to determine whether data was modified or if it changed. This mechanism allows us to ensure that someone is not maliciously tampering with a message containing our credit card and social security numbers. In many ways, a one-way hash is much like the cyclical redundancy check (CRC) mechanism used in data transmission certification. CRC is used in a computer programs to ensure that the bits in the executable file or in a data stream have not been corrupted. For example, when downloading a large file from the Internet to our computer, the download routine will check the CRC to determine whether the bits are in the same condition when you complete the download as they were before the download. In an implementation of a one-way hash, 128 bit or 160 bit digests are typically created and compared. Since these digests are so large, it is virtually impossible to produce the original document matching the digest manually.
The Ever Changing Security Standards Even though encryption appears to provide robust answer to our privacy and security needs, standards for encryption protocols often contain weaknesses and limitations that attacker can exploit. Even the best implementations of a protocol standard contain weaknesses and limitations. Currently, no one claims that there is a silver bullet to solve all security requirements through on single implementation of one encryption protocol. Furthermore, by design, many protocol standards usually enable support for weaker cryptography so as to make them usable in mutli-configuration environments. For example, the TLS protocol enables confidential communications to default to weak encryption to support department of commerce imposed export restrictions on cryptography. In general, you can reduce the risk of weaknesses in your choice of protocol by following these steps:
Discourage the use of older and weaker versions of protocols when you want to protect valuable information. For example, require Transport Layer Security (TLS) version 1.0, Secure Sockets Layer (SSL) version 3, or Private Communications Technology (PCT) version 1.0 for secure Web communications, and prohibit less secure version communications (this may be difficult depending on your specific browser and operating system version) Implement the most current version of the protocol, which typically will offer stronger security or fix identified weaknesses in previous versions. Protocols are revised periodically to improve the overall security as well as add new features. Utilize protocols that have been thoroughly tested over time and subjected to wide range of attacks. Also, make sure that before implanting a protocol you understood its limitations and associated security risks. Employ the strongest security options that are available with the protocol to protect sensitive information. When it is feasible, require strong cryptography and do not allow systems to default to lower strength settings unless the value of the information to be protected is negligible.
7
The Cost of Encryption While providing secure transmissions, most encryption schemes require the server and client machines to pay a considerable performance penalty; SSL is no exception to this rule. The penalty comes from the added overhead of encryption before transmission and decryption upon receipt of each securely transmitted packet. In an effort to avoid reducing the performance on the entire Web site, encryption mechanisms such as SSL should only be applied to those virtual folders that deal with highly sensitive information such as credit card and personal information. The strength of the encryption is dependent on two basic items: the nature of the mathematical algorithm and the size of the keys involved. Under US arms regulations, the length of the key that can be used in exported software is limited. However, there is no limitation on the level of encryption used within the US, or sold in Canada. Unfortunately the 40-bit encryption limit, which has been in force up until recently, has been proven to provide little security from attack. Today's powerful processors, costing just a few hundred dollars, can crack such a message in a few hours by using brute force—that is, by trying every possible key until the decrypted message has been found. More expensive supercomputers can crack such messages in subsecond times! Each extra bit in the key doubles the time needed for the brute force attack, and most experts now claim that 128-bit keys are required to ensure complete confidence, and are vital for markets such as electronic commerce. Many non-US companies have now developed add-on cryptographic products, using 128-bit key technology, to fill the vacuum left by the US software industry's inability to compete in this market. Naturally, there is a lot of discussion between concerned parties, and the future of these export restrictions is unclear.
Signing Digital Signature Encryption A piece of data encrypted with a private key is called a digital signature.4 Common practice is to use a message digest as the item of data to be encrypted. An additional use for asymmetric key encryption is in the implementation of digital signatures. Signatures, in essence involve swapping the role of the private and public keys. If a sender encrypts a message using his or her private key, everyone can decrypt the message using the sender's public key. A successful decryption operation then implies that the sender, which was the only person in possession of their private key, must have sent the message. This mechanism also helps reduce claims of repudiation, that is, the sender cannot claim that they did not send the message.
Using a Message Digest A message digest is a digital fingerprint of a message, derived by applying a variety of mathematical algorithms to a variable-length message. There are a number of suitable algorithms to achieve this functionality, they are globally referred to as hash functions, each hash function will typically have the following properties:
The original message (the input) is of variable-length.
4
Note that a document that is signed (its integrity and origin are certified) is not the same as encrypted (anyone could look at the original document included with the signed digest and read its contents).
8
The message digest (the output) is of a fixed-length. It is practically impossible to determine the original message (the input) from just the message digest (the output). This is known as being a one-way hash function. It is practically impossible to find two different messages (the inputs) that derive to the same message digest (the output)—this is known as being a collision-free hash function. The algorithm is relatively simple, so when computerized it is not CPU-intensive. The calculated digest is (often considerably) smaller than the item it represents.
You can use message digests to guarantee that no one has tampered with a message during its transit over a network. Any changes to the message will mean that the message and digest will not match. Also, message digests can also be used to supply a proof that an item of information, such as a password, is known without actually sending the password or information in the clear. This process is commonly known as password hashing The most common message digest algorithms associated with 32bit computers are MD4, MD5 and Secure Hash Algorithm (SHA).
Digital Certificates and the Certificate Authorities A digital certificate is an item of information that binds the details of an individual or organization to their public key. The most widely accepted format for digital certificates is the X.509 5 standard, and is relevant to both clients and servers. If we can obtain access to someone's certificate we have their public key, and can therefore get involved in the secure communications already discussed. But what is there to stop anybody just creating a false certificate, and pretending that they are someone else? The solution is Certificate Authority (CA), who is responsible for the issuing of digital certificates. A CA is a commonly known trusted third party, responsible for verifying both the contents and ownership of a certificate. There is an ever-increasing number of CA. Different CA will employ different amounts of effort in their verification processes, and they must publicly divulge what checks they perform. Then users can apply the appropriate levels of trust for each CA they encounter. Also, different classes of certificates are available, which reflect the level of assurance given by the CA, a certificate for users who just surf the web requires less verification than a certificate for a business server. If two entities trust the same CA, they can swap digital certificates to obtain access to each other's public key, and from then onwards they can undertake secure transmissions between themselves. Digital certificates include the CA digital signature (i.e. information encrypted with the CA private key). This means that no one can create a false certificate. The public keys of trusted CA are stored for use by applications like Internet Explorer, as we will see in a while.
Are Certificates Similar to a Gift Certificates? Not Exactly
5
An internationally recognized standard for certificates that defines their required parts. 9
Certificates are digital identification cards that allow both servers and clients to authenticate each other. 6 They can be used on both the server and the client to set up an SSL connection over which encrypted information can be sent. The certificate-based SSL features in IIS 7 consist of a server certificate, a client certificate, and various digital keys. You can create these certificates with Microsoft Certificate Services or obtain them from a mutually trusted, third party organization called a certification authority (CA) like VeriSign. A digital certificate is a piece of digital ID for the users accessing your site or for your site accessing users. It can contain information about the server and the client and is "signed" with a digital signature form the certification authority (CA) that issued the certificate. A digital signature is basically a hash of a message, in this case the certificate that is encrypted with the sender's private key. The sender in this case is the CA. As we previously stated, IIS is capable of supporting 2 types of certificates, client and server. The server side certificate provides the connecting client with the assurances that the URL is indeed operated by correct party. The Client side certificate indicates that the client is who he climes to be. Before trusting any certificates, W2K Server performs an elaborate corroboration checks to ensure that certificates are valid and that they have a valid certification path. Figure 9 shows the basic validation process certificate.
Server Side Certificates
Server certificates provide a way for users to confirm the identity of our Web site. A server certificate contains detailed identification information, such as the name of the organization affiliated with the server content, the name of the server, the name of the organization that issued the certificate, and a public key used in establishing an encrypted connection. This information helps to assure users of the authenticity of Web server content and the integrity of the secure HTTPS connection.
Client Certificates With SSL, your Web server also has the option of authenticating users by checking the contents of their client certificates. A typical client certificate contains detailed identification information about a user and the organization that issued the certificate and a public key. You can use client certificate authentication, along with SSL encryption, to implement a highly secure method for verifying the identity of your users. So when a user logs in to the Gateway in order to access the files in his dedicated directory, you can be certain that he is who you expect. IIS can be configured to ignore, accept, or require client certificates. It's important to understand how each setting changes how IIS responds to client certificates:
6
A certificate is a special text file that contains two sections: a clear text (readable by humans) section containing the information about the owner, issuer, and so on, and an encrypted (not readable by humans) section that contains the digital signature and public key of the certification authority. The text file is given the .cer extension so that when you open it the operating system uses whatever certificate utility it has to view the file. If you open one of these files in Notepad it will look like this: -----BEGIN CERTIFICATE----CBHcm91cCBDQS5jcmwwRqBEoEKGQGZpbGU6Ly9cXENFUlRTUlZcQ2VydFNydlxDZXJ0RW5yb2xsXE1TIENl cnRTcnYgVGVzdCBHcm91cCBDQS5jcmwwCQYDVR0TBAIwADBiBggrBgEFBQcBAQRWMFQwUgYIKwYBBQUHMAK GRmh0dHA6Ly9DRVJUU1JWL0NlcnRTcnYvQ2VydEVucm9sbC9DRVJUU1JWX01TIENlcnRTcnYgVGVzdCBHcm 91cCBDQS5jcnQwDQYJKoZIhvcNAQEEBQADQQAhq70nRlse0ulPstU+IWdjeNj5p -----END CERTIFICATE----7
IIS supports using X.509 certificates for access control. A certificate verifies a user's identity in much the same way as a driver's license or corporate identification card does. They are issued by a trusted certificate authority, either within an organization or a public company like VeriSign. 10
Ignore certificates: IIS doesn't care if a user sends their certificate with a request; IIS will simply authenticate the user using another method, such as Challenge/Response. Accept certificates: if a client certificate is sent, IIS will use this certificate information to authenticate them. If no certificate is sent, IIS will use another method. Require certificates: IIS will only fulfill requests from users with valid certificates.
IIS client certificate mapping associates, or maps, client certificate information with Windows NT user accounts. This form of authentication can be very secure and flexible, and most new browsers support the use of client certificates.
Figure 5: Certificate validation path
Custom Authentication Modes If you have an existing database of user information and you want to use it for authentication, you should consider creating a custom application. Custom authentication applications can be Active Server Pages (ASP) applications, ISAPI DLL filters, Java applet, ActiveX control, or COM DLL objects. You can create a custom application to perform many security-related functions, such as validation, authentication, IP address restriction, or access control with or without the utilization of certificates. For example, it can authenticate a user by using client certificates, prompting the user for their user name and password, or authenticating the user against a user information database. 11
TCP Ports and the Security Support Provider W2K Server implements Internet secure services via the Security Support Provider (SSP) umbrella. This is the implementation of all of the authentication protocols discussed previously (SSL 2.0, PCT 1.0, SSL 3.0, and TLS 1.0.). The Internet Assigned Numbers Authority (IANA) has reserved port 443 for HTTP over SSL, although, different flavors of SSL, including PCT and TLS also use this port.8 HTTPS is the name of the URL scheme used with this port. Thus a URL such as http://www.FirstData.com implies the use of the plain vanilla HTTP to port 80, and https://www.FirstData.com implies the use of HTTP over SSL to port 443. By default, IIS knows to use port 443 as the SSL port. You can, however, change this port assignment to any other available port you want.9 You can have many sites, each with a non-SSL port number and an SSL port number. For example, you might have a site called GatewaySite. It might have port 90 as the non-SSL port and port 443 as the SSL-port. Users would enter http://www.Gateway.com to access the non-secure and non-SSL version. To access the secure and SSL version, they would use https://www. Gateway.com. They could also use the IP:Port number directly such as in: https://www. Gateway.com:443. Also, regarding the format of the HTTP word, the "s" in https:// is more than just a cosmetic addition, this marker is important because it tells the client’s browser to use the SSL port. If you were to use http://www. Gateway.com:443, instead nothing would happen and the browser would keep crunching away but never establish a connection to the server. A similar behavior would occur if you tried to use https with a non-SSL assigned port, such as https://www. SecureGateway.com:90.
Securing the Parameter In most Internet communications, the channel between the client's Web browser and the Web server is not secure. A secure channel means that data is encrypted on both the client and server before being transmitted across the Internet in either direction. Currently, IIS offers native support for Secure Sockets Layer (SSL) as well as other compatible protocol such as the Microsoft implementation of Private Communication Technology (PCT).10
8
Ports are used in TCP to name the ends of logical connections that carry long-term conversations and for the purpose of providing services to unknown callers. The contact port is also sometimes referred to as a "well known port." A TCP port provides a specific location for delivery of TCP segments. Port numbers below 1024 are well-known ports and are assigned by the Internet Assigned Numbers Authority (IANA). For a complete list of assigned TCP ports, see RFC 1700. Also keep mind that the registered ports are not controlled by the IANA and on most systems can be used by user processes or programs. Registered ports between 1024 and 5000 are also known as the ephemeral ports. Although the IANA cannot control uses of these ports, it does register or list uses of these ports as a convenience to the TCP/IP community. To the extent possible, these same port assignments are used with UDP. The registered ports are in the range 1024 – 65535. 10 In 1994, Netscape Communications developed and popularized a network authentication protocol known as the Secure Sockets Layer (SSL) 2.0. In 1995, Microsoft countered with a protocol known as Private Communications Technology (PCT) 1.0, which was an improvement on SSL 2.0. Around the same time Netscape released an independent suite of improvements via the SSL 3.0 protocol, which currently the de facto standard for the Web. SSL 3.0 was 9
12
SSL provides a security handshake that initiates the TCP/IP connection. The client and server agree on the level of security they will use, and that will fulfill any authentication requirements for the current connection. Thereafter, the only role SSL plays in the entire connection is to encrypt and decrypt the byte stream of the HTTP protocol. This means all of the information in both the HTTP request and the HTTP response are fully encrypted, including the URL the client is requesting, any submitted form contents, any HTTP authentication information such as names and passwords, and all the data returned from the server to the client. The use of secure communications channels requires that the client Web browser and the server both support the particular encryption being used to secure the channel. In the case of IIS support for SSL, this means that clients must use an SSL enabled browser such as IE 3.0 or higher (version 5.0 or higher is recommended) to access data in SSL enabled browsing mode.
The Secure Sockets Layer (SSL) Under the Microscope By now you have probably noticed that the Security Support Provider (SSP) implementation in W2K Server plays a pivotal rule in the assembly of any secure Web presence including a gateway. Although most designers don’t need to get to such a low-level implementation details of Internet security, some might want to take the plunge and jump in to learn more. So in the next section we will look little closer at the inner workings of SSL and how it interacts with the SSP. You do not need to read this section to understand how to assemble our exchange gateway, but if you do, you will be rewarded with a solid understanding of the weaknesses and strengths of the overall process. At the heart of W2K Server implementation of SSL is the record protocol, which provides the following elements:
Message framing and windowing Typing and fragmentation Compression and optimization Cryptographic Services including Encryption Message Authentication Code (MAC) generation and verification.
MAC 11 authentication is used to authenticate the message itself, which demonstrates cryptographically two properties: whether the message was tampered with in transit, and whether the message came from the person with whom we are having the secure conversation. The sender typically creates a MAC by encrypting a one-way hash of the message with a conventional session key shared by the two parties on either end of the wire, and then appends the MAC to the message. The receiver verifies the MAC by performing the same calculation. SSL assumes a connection-oriented transport is in use, most commonly TCP, and unless the message fragments are received in the correct order from the underlying communication protocol, the receiver won't be able to decrypt the stream (each fragment isn't guaranteed to be independently decryptable). In order to encrypt or verify MACs, both endpoints need to share a secret key, also known as a session key. 12 On top of the record protocol SSL uses a higher-level protocol known as the handshake protocol to 11
The CryptoAPI algorithm name for the Message Authentication Code algorithm. CryptoAPI also references this algorithm by its algorithm identifier (CALG_MAC) and class (ALG_CLASS_HASH). 12 A randomly-generated key that is used one time, then discarded. Session keys are symmetric (used for both encryption and decryption). They are sent with the message, protected by encryption with a public key from the intended recipient. A session key consists of a random number of approximately 40 to 2000 bits. Session keys can be derived from hash values by calling the CryptDeriveKey function. 13
exchange this key and authenticate the client and server to one another. Authentication is technically optional, and there are three modes in which SSL can be used: 1. Mutual authentication – Both the caller and responded get validated and certified 2. Server-only authentication – Only the server certifies who he is, the client can be anonymous. 3. No authentication – Neither the Sever or the client certify themselves. The third option, if you think about it for a second, is practically useless. Exchanging sensitive information over an encrypted but unauthenticated connection is analogous to two secret agents sitting alone in a dark corner of a grubby restaurant, whispering secrets to each other, without either of them knowing who the other one is.
Jack Jill and the Hill of Trust The vast majority of commercial HTTPS traffic over the Web today uses a variant of SSL with serveronly authentication. In this connection scenario, as far as SSL is concerned the client is anonymous and the server is authenticated. SSL uses a four-way handshake in all three cases (see Figure 10). Our discussion of the handshake components will focus on only the steps and connection elements necessary for the authentication and key exchanges. In our example two non-fictitious individuals named Jack and Jill wish to run-up-the-hill, but are afraid to do so without first certifying each other’s identity over a secure connection (many more steps may be necessary in exchanges requiring ongoing validation). Some of the problems they need to overcome are: 1. Insure that the person responding to their communication is the other trusted party 2. Insure that the communication is not being interpreted and modified 3. Certify that the response comes from the sender and eliminate claims of repudiation (or the ―c at ate it‖ argument) The first step in this process is client (will call her Jill) sends a ―Cl ientHello‖ message to the server (will call him Jack) to indicate that she wants to establish a new SSL session. This message contains a random number generated by Jill’s application (most likely a Browser), as well as a list of preferred cipher suites. 13 Each chipper suite indicates a key exchange algorithm 14, a bulk encryption algorithm 15, and a MAC 16 algorithm .
13
A cipher suite is a set of cryptographic algorithms. Schannel protocols use algorithms from a cipher suite to create keys and encrypt information. A cipher suite specifies one algorithm for each of the following tasks: Key exchange, Bulk encryption, and Message authentication. For more information on the algorithms available in the suite see: Windows 2000 Platform SDK-Security 14 An algorithm used to encrypt and decrypt exchange keys (symmetric session keys). Some common key exchange algorithms include DH and KEA. Each provider type can specify only one key exchange algorithm. 15 A session key derived from a master key. Bulk encryption keys are used in Schannel encryption. 16 The CryptoAPI algorithm name for the Message Authentication Code algorithm. CryptoAPI also references this algorithm by its algorithm identifier (CALG_MAC) and class (ALG_CLASS_HASH). 14
Figure 6: The flow of an SSL session Jack examines the incoming request; he then selects a cipher from Jill's proposed suite list (This is assuming that one is acceptable), and sends back a ―Ser verHello‖ message to Jill. This message includes a random number generated independently by Jack’s application (likely a Browser), along with the cipher suite that Jack chose from Jill's list. If Jack chooses a cipher suite whose key exchange algorithm requires him to prove his identity (only the third option on our list does not required authentication), he will then send his X.509 compliant certificate back to Jill as well. 17 Depending on the key exchange algorithm, Jack might also need to include extra information to allow key exchange or satisfy U.S. department of commerce export restrictions. 18 But to keep the illustration simple, we will assume that the certificate Jack sends to Jill can also be used directly for key exchange. Finally, after Jack has successfully sent his certificate, he is allowed to include a request for Jill's certificate. When Jill receives the information from Jack, she can chose to verify Jack's certificate. This includes checking the signature of the root authority with her copy of the authority's well-known public key (we will look at certificate verification in the next section on certificate revocation). At this point, Jill knows that she's got a public key for Jack, but she still can’t say with certainty that it's actually Jack and not his evil twin Jackamo on the other side of the connection. No session key has been exchanged yet, but Jill is now going to address that. Jill sends Jack her certificate (if it was requested as seen in our options 1 and 2), and another random number known as the Premaster Secret 19 that has been encrypted with Jack's public key. If Jack requested a certificate from Jill, she will include her 17
An internationally recognized standard for certificates that defines their required parts. The current export laws allow full 128-bit products to be released in any country that is not the target of an embargo. The U.S. government has determined several categories of merchants that can implement 128-bit security outside the United States from their servers, these are: banks, financial institutions, insurance companies, health and medical organizations, online merchants, and U.S. subsidiaries of foreign companies. For more information on the current status of export restrictions, see VeriSign FAQ at http://digitalid.verisign.com/server/global/help/globalFAQ.htm. The official U.S. Department of Commerce site dealing with encryption regulations can be found at http://www.bxa.doc.gov/Encryption. 19 This is typically a client generated a 48-byte secret, it is encrypted from the public key taken from the server's certificate or temporary key from a server key exchange message. It is then used to send the result in an encrypted premaster secret message. 18
15
signature on all the data she has sent to, or received from the record layer during the handshake process. Up to this point, the SSL record layer has been streaming data using the NULL bulk data encryption algorithm; 20 so far nothing has been encrypted yet. Jill now streams out a change cipher spec message, which essentially says, "Until I say otherwise, I'm going to instruct my record layer to use the cipher suite we just negotiated and agreed on for all future communications". This means that Jill needs to calculate keys for bulk data encryption and MAC generation-verification, both of which are functions of the Premaster Secret created earlier, and the two random numbers generated independently by the client and server during the first two ―Cl ientHello‖ and ―Ser verHello‖ messages. Next, Jill streams out a finished message, which is encrypted by the record layer. This message includes a MAC of all of the data she's received from or sent to the record layer during the current handshake. When Jack receives Jill's transmission, he verifies her certificate (assuming that he did ask for one), contains the Premaster Secret created earlier. This is done by physically decrypting it using his private key, and verifying Jill's signature on the handshake messages he has seen so far using the certificate she sent. At this point in their communications, their plan for a rendezvous on the hill is moving into higher gear, because jack has to a large degree verified that he is been talking to Jill. Jack now receives Jill's change cipher spec message, calculates the keys for bulk data encryption and MAC generation-verification, and instructs his record layer to start using the new cipher suite to decrypt the incoming transmission. This allows Jack to read the finished message, which is at the tail end of Jill's transmission. After verifying the MAC in the finished message, Jack finally develops the trust that the entire handshake and cipher suite negotiation was not tampered with by a man-in-themiddle, as this MAC protects the entire set of handshake messages exchanged at this point. Finally, Jack sends a change cipher spec message back to Jill, instructing his record layer to use the new cipher suite to encrypt all outgoing messages. This is followed by a finished message, which once again includes a MAC of all messages exchanged at this point. Jill receives the change cipher spec message, instructs her record layer to decrypt incoming messages using the new negotiated cipher suite, and reads the finished message from Jack. If the message decrypts successfully and she can verify the MAC Jack sends to her, she develops trust in Jack's identity. Only Jack could have decrypted the premaster secret she sent, which was required for him to be able to generate the MAC. At this point, Jill and Jack have negotiated a cipher suite, exchanged shared keys for bulk data encryption and message authentication, and Jill knows that she's talking to Jack. Jack may also know Jill's identity (if he asked for a client certificate) and other then non-withstanding logistic considerations; they are free to transmit the agreed location of the hill and the time for their rendezvous.
20
A session key derived from a master key. 16
Purchasing and Installing Certificates Now that we have gone through the process of SSL authentication, you will be happy that all the complexity is encapsulated and it us merely and administrative task to enable it in IIS. Recall that for SSL to be effective, the server must have a certificate so that at least one of the parties can be authenticated (option 2 on our list) If you look at the properties for a Web site in IIS, you'll notice on the Web Site tab that the option for SSL Port is disabled by default. IIS is designed not to support SSL without a server-side certificate. Obtaining and installing a Web server certificate for an established company is simple and straightforward; in our gateway example we will be using a wizard that comes with IIS to makes it even easier. IIS allows us to expose multiple Web sites from a single Web server, and assign a dedicated certificate to each of these Web sites if you chose to. The important thing to remember is that they will have to set individually for each site. To install a dedicated certificate, choose the Web site for which you want to obtain a certificate, bring up its property sheet and choose the Directory Security tab. Press the Server Certificate button to invoke the wizard. The wizard allows you to create certificate requests, install new certificates, remove an existing certificate, and so forth. Each of these activities requires answering a few simple questions. Unless you are planning to use your own enterprise certificate authority to issue a certificate directly (highly unadvisable), obtaining and installing a certificate will be a four-step process. The first step is to create the request. To do this, you need to choose the strength for the key in the certificate (you should use 1024 bits or stronger), along with some strings that will end up in the certificate exactly as you type them. These fields are:
Name - This is some friendly name that you can use to distinguish this certificate from any others you might obtain. This isn't important for authentication, but will be included as an extra property in the certificate. Organization Name - This is the name of your company. Organizational Unit - Typically this is your department. Common Name - The name that will be used to authenticate the URL being used to access the Web server, so it should match the DNS name that you expect clients to use. For instance, the common name for First Data’s Web site is http://www.firstdata.com/ Country/Region - This one is self-explanatory. State/Province – Name of state has to be fully spelled out City/Locality - No surprises here.
After this, the wizard will ask you to choose the name of a text file where it will write the certificate request. In the process of creating this file, the wizard will make several calls to the W2K Server CryptoAPI in order to generate a public-private key pair for the certificate and for storing the private key on the local machine. This public key will be included along with the other information you've entered in the text request file, which you can send to your certificate authority (for instance, VeriSign). The resulting file contains a base-64 encoded ASCII rendering of all the information in the request. The second step is to send the request to the authority. You'll typically paste this into the authority's Web-based certificate application form, along with contact information, proof of domain ownership, and proof of your right to do business under the specified organization name (you can supply your http://www.dnb.com information, or tax ID). Third-party certificate authorities will typically charge 17
you a fee for this service. Fees can range depending on the level of service and security requested. You can expect to pay anywhere between $200 to $800 for a one year certificate. The third step is the decision of the authority (who either issues or denies your request). Assuming the authority can determine that you are who you claim to be (by checking submitted documentation), you'll receive e-mail within a few days indicating that your certificate request has been granted and you can download your certificate. You will be provided with a URL for the download site and then proceed to fetch the file. If you examine the contents of the file, you will discover that it looks similar to the certificate request. The fourth and final step is to install the downloaded certificate. If you now revisit the certificate wizard, it will allow you to process the response. Give it the path to the file you downloaded from the authority, and that should be it. Note that during this request-response phase, the private key remains on the computer where you generated the request. Be aware that if you delete the pending request using the wizard (before you install the certificate), the private key will be erased, and you'll have to start the process all over again. If you have already paid money to a third-party authority to sign your public key, this means that you have just smoked that payment, ouch! So watch out. Once the certificate has been installed, you can export the certificate along with its corresponding private key to a file that you can drop on a floppy and put offline for safe keeping in case the Web server melts down or the private key becomes corrupted. After installing a certificate, you'll notice that the SSL Port field on the Web Site tab of the Web site's property sheet is now checkable, and defaults to the standard port number for HTTPS, which is port 443. You should now be able to access your Web site from a browser using the https protocol.
Requiring the Use HTTPS In IIS, once you installed a server certificate, any virtual directory associated with that certificate may be accessed via HTTP or HTTPS. If you want to require HTTPS for a particular directory or resource, you can use the metabase to apply global and inheritable privileges to do so. 21
Certificate Revocation One of the biggest potential traps of using certificates is the tendency for people to assume that a certificate is valid simply because its signature can be verified and it has not yet expired. In a password-based authentication system, if a users password is compromised, he can simply change his password. In NTLM the authority immediately enforces this change for all new authentication requests (replication latency between domain controllers may delay this process by several hours) because the authority is involved in every single network authentication exchange. So what happens in a certificate-based system if Jack’s private key is compromised? Well, for starts, Jack most 21
If you're not already familiar with the metabase, it's simply a hierarchical data structure that mimics the layout of your Web site. The metabase tree is what you're looking at when you manage the Web site using the IIS MMC snap-in. The metabase uses an attribute inheritance scheme somewhat similar to the DACL inheritance scheme used in Windows 2000. When you change an attribute on a node, it propagates to all children of that node, except for those children that have provided their own definition of the attribute. 18
notifies his authority and obtains a new certificate, and the authority revokes the old certificate. But what does this mean for Jill, who contacts a server that she presumes is run by Jack but really has been hijacked by Jackamo, who has an illegitimate copy of Jack's old private key? Jackamo can simply send Jack's old certificate, which won't expire for a year or so, back to Jill and then attempt to rendezvous with her on a hill, Yikes’. After all, he can now prove the ownership of the certificate because he holds the associated private key. Unless Jill specifically checks for revocation, she'll never know that she's really talking to Jackamo. Once again, public key cryptography is not a silver bullet. Jill still needs to contact an authority to verify that Jack's certificate hasn't been revoked. Jack's authority publishes a certificate revocation list (CRL) that Jill can obtain occasionally, perhaps every day or once a week, and she can use her current copy of the list to validate Jack's certificate. As an example, Internet Explorer 5.0 has a security setting entitled "Check for server certificate revocation" that forces the browser to download a CRL (or retrieve a freshly cached one) and verify that each server-side certificate hasn't been revoked. If you think about it, the real reason that certificates have expiration dates is to keep CRLs from growing infinitely long. Most implementations of the HTTPS protocol involve online purchasing or the exchange of private information. Accessing a secure server often requires some sort of registration, login, or purchase. The successful use of the HTTPS protocol requires a secure server to handle the request. HTTPS is used to provide strong authentication when using HTTP to gain access to content on the Web sites. The most common use of HTTPS is to provide an encrypted connection to an authenticated Web server. When clients attempt to establish an HTTPS connection, typically triggered by browsing to a URL beginning with https://, the client and server jointly negotiate a security protocol to use and then exchange authenticating information. Both Netscape and IE 5 support common secure communication protocols for HTTP transactions, including the following:
Transport Layer Security (TLS version 1.0) Secure Sockets Layer (SSL versions 2 and 3) Private Communications Technology (PCT version 1.0).
Each protocol provides both encryption services (for confidentiality of exchanged data) and authentication services (for mutual identification between clients and servers). SSL support, which is provided through the built-in HTTPS transport service, adds server-to-server authentication and transport layer encryption to an interchange. When you select "Any unassigned" as the IP allocation, the certificate is bound to all Web sites that have not previously had a server certificate bound to them even sites with assigned ports, such as the Default Web site and Administration Web site that are installed by IIS. If none of your sites have certificates assigned to them, then the certificate effectively binds to the WWW service. This completes our examination of the basic web security technologies. We have covered a lot of ground regarding the constituents components required for the implementation of a secure connection to and from a Web server over the Internet. We learned about, authentication, certificates, SSL, and more.
19
Further Reading To learn more about this subject in greater details, check out the following Bruce Schneier publications: Beyond Fear Secrets and Lies Practical Cryptography Applied Cryptography The Twofish Encryption Algorithm The Electronic Privacy Papers E-Mail Security Schneier on Security
20
