Although authentication and access control provide adequate protection with regard to legitimate users, security is also concerned with unidentified, illegitimate, and usually unseen attempts to penetrate a system. These attempts pose two major threats. The first threat involves attacking data that is in transit across a network (or perhaps stored in an intermediary location, such as a mail server). The attack may involve eavesdropping on your data, modifying it, or attempting to impersonate you on the network. The only solution to this type of threat is cryptography.
The second threat seeks to introduce a malicious program (for example, a Trojan horse or virus) into your system, and is particularly virulent in the Internet environment. Microsoft Internet Explorer contains special cryptographic technology (Authenticode) and security zones that screen certain kinds of downloaded programs and scripts against common networking threats, and the system integrity of Windows NT make it inherently less prone to viruses than its predecessors.
Encryption ensures that network elements cannot eavesdrop on your communications by “scrambling” the data. Microsoft currently uses the RC4 algorithm from RSA, Inc., and the U.S. Government standard DES algorithm for most of its encryption (the cryptographic infrastructure is open so that alternative algorithms are easily added). RC4 is a “symmetric” algorithm that requires both sender and receiver to have the same shared secret, or encryption “key.” The standard key lengths, which determine the degree of protection, are 40- and 128-bits (the latter is subject to U.S. export control). Although 40-bit keys can be compromised by known, determined attacks, compromising 128-bit keys by means other than flaws in the RC4 algorithm would be extremely difficult. RC4 and DES are long-standing algorithms and have no publicly known flaws.
Key management is the process of distributing keys between sender and receiver, and there are many common key management protocols. Sometimes both parties already know a secret user password that can be used as the seed for an encryption key. Other protocols use previously established keys to transmit the encryption key. Public key algorithms are particularly well suited for this purpose. Like referees at a sporting event, the best key management is unseen by its users.
Integrity is protection against malicious modification of data. Integrity techniques attach a cryptographic signature to the message that both identifies the sender and ensures that the message has not been modified in transit. Microsoft technology currently uses the RSA public key and MD5 hash algorithms, a technique that dominates the Internet community. In a public key cryptosystem, each user has a matched pair of keys: a private key they keep secret, and a public key they publish freely. The public key is presented in a certificate signed by a Certification Authority (CA) that attests to the key’s authenticity.
The unique property of public key ciphers is deceptively simple: Data encrypted by the private key can be decrypted only by the public key, and data encrypted by the public key can be decrypted only by the private key. For example, if you encrypt a message for a colleague with her public key, only she can decrypt it.
A hashing algorithm produces a small value (usually 16 bytes) from an arbitrarily long stream of data. We call this value a “hash” or, more formally, a “message digest.” Its unique property is that it is computationally infeasible for someone to construct a data stream that reproduces a specific hash value. For example, if you compute a hash from a document you send to a colleague and then transmit the hash value securely, your colleague could determine if the document had been tampered with by recomputing its hash and comparing it with your original. Although a nefarious intermediary (traditionally named “Mallet”) might modify the document in transit, the intermediary simply cannot produce a fake document that has the same hash value.
The only question left is how to securely transmit the hash, but that is easy: You encrypt it with your private key and send the result as a signature that accompanies the document. Your colleague uses your public key to decipher the transmitted hash and checks the document as before. Although it may not be obvious, there is no way Mallet can modify the document or its signature that your colleague’s software will not detect.
Microsoft uses this common, basic integrity algorithm in many situations. Perhaps the most visible is the Authenticode technology that ensures that Microsoft ActiveX, Java, and other active components downloaded from the Web come from identifiable sources and have not been tampered with. Public keys and hash algorithms are also used for symmetric key management and to ensure that a communicant is genuine and not a masquerader.
Secure Sockets Layer (SSL) is a popular protocol that incorporates both encryption and integrity. While SSL is predominantly used for Web traffic, Microsoft’s cryptographic enabling technologies, called Secure Channel and Security Support Provider Interface (S-Channel and SSPI), make it available to all applications. Microsoft also supports Private Communication Technology (PCT), an improved version of SSL and Transport Layer Security (TLS), an upcoming Internet standard that merges SSL and the ideas in PCT. Throughout the rest of this chapter, this entire collection of protocols is referred to as SSL.
The distribution and management of certificates are central to the successful deployment of public key technology. In the example, how does your colleague reliably obtain your public key? If you send it unprotected, Mallet can change it and compromise your communication without your knowledge (or your colleague’s). A certificate holds your name, your public key, and other information, all of which are signed by a Certification Authority (CA) using a private key and the integrity algorithm. If your colleague reliably knows the public key of that CA, she can verify that the certificate you send her has not been tampered with. For example, most mail systems simply package the sender’s certificate with the mail message. The recipient software first verifies the certificate, and then uses its public key to check the integrity of the message.
It may seem that the issue has been deferred: How do you reliably obtain from the CA the certificate that holds the public key? The answer is that you have to use a previously established, secure communication path. There are many techniques for doing this, for example, Microsoft delivers many commercial CA certificates preinstalled in Internet Explorer. You only have to obtain a small number of CA certificates. Your software automatically uses these to verify the user certificates signed by those CAs. You can even have CAs that verify and sign the certificates of other CAs.
You also need confidence that the CA uses a degree of diligence when signing a user’s key. It is poor practice for a CA to sign a certificate with an intentionally supplied false name. However, there are limits to what CAs can ensure, and certificates often contain a value that denotes the degree of diligence. It is also important for the CA to be able to revoke certificates. The usual technique is for the CA to regularly publish Certificate Revocation Lists that are downloaded by various CA validation agents.
You can think of a firewall as a filter that restricts the direction and type of requests that can pass between your LAN and an external network such as the Internet. The more effective firewalls serve as a “proxy” for specific services; that is, a program on the firewall serves as intermediary between the LAN and entities on the external network for a specific service like Web browsing. Proxy programs understand the details of the communication and can apply sophisticated restrictions on the data. Firewalls also can hide your internal network addresses from the external network and reject packets from specified external network addresses.
The Windows NT security environment provides pervasive cryptographic support for these ideas. For example, Personal Store securely groups a user’s keys and certificates together for storage, Certificate Server lets you issue and manage your company’s own certificates, and CryptoAPI fully supports Certificate Management.