Chapter 3

Cryptography: Is it Enough?

Never mind personal use! Encryption will be widely adopted to protect transactions over the electronic commerce industry, despite what the government concerns are with regards to national security.

The increasing growth of the electronic commerce are pushing the issue of data encryption to the main courts, as more and more there is a need for companies and netizens to protect their privacy on the Internet, as well as their commercial and financial transactions. But the government is a bit nervous about it as, for the first time, encryption can block the watchful eyes of the law enforcement agencies over individuals, which in fact, is a double-edged sword, as if powerful encryption schemes is to fall into the wrong hands it can represent freedom for crimes to be committed and go undetected.

Cryptography’s main tool, the computer, is now available everywhere! Since the World War II (WWII) governments worldwide have been trying to control the use of data encryption (ask Phil Zimmermann about it!!). No longer we need Colossus, the computer built during WWII to crack the German military’s secret code! My 14 years old son already uses a Pentium at home, access the Internet and encrypts his files with CodeDrag!

Since 1979, the National Security Agency (NSA) had classified any form of encryption as weapons, compared to fighter jets and nuclear missiles. However, people like Zimmermann, concerned with privacy and civil rights, have been fighting against exclusive government control of encryption. During the 70, Whitfield Diffie, of Stanford Research Institute, developed what is today known as public key cryptography, which is discussed in more details later on this chapter.

Diffie’s innovation actually created a revolution in the encryption world back there, especially among the government. The problems was that, while the government’s secret agencies were still using single key schemes, which would rely upon both the sender and the receiver of an encoded message having access to the key, he proposed a dual-key approach which made it much simpler to encrypt data.

Not long time later, in 1977, a company found by three scientists from the Massachusetts Institute of Technology (MIT), RSA Data Security, introduced the first public key cryptography software and obtained US patents for the scheme.

It was in 1991 that Zimmermann, then a computer programmer, launched his "Pretty Good Privacy" (PGP) encryption software and distributed it freely on the Internet, making it internationally available. Not only his action got the governments attention to him, which lead to his persecution, but even RSA Data Security also condemn PGP, classifying it as a threat to its commercial interests.

Nowadays, even commercial software companies are developing their own encryption products. Take Netscape, for example, which developed and freely distributed their security scheme all over the Internet as well. Netscape’s Secure Sockets Layer (SSL) encryption scheme uses 56 character key to increase data security. Microsoft also come up with an encryption tool, know as Private Communications Technology (PCT) protocol.

As discussed in the past two chapters, computer network security is becoming increasingly important as the number of networks increase and network size expands. Besides, the Internet has also become an extension of the protected networks of a corporation. Until last year, Intranets were something new, but only a little more than an year later we are already talking and investing into Extranets. As the sharing of resources and information worldwide (Cyberspace included!) becomes easier, the ability to protect information and resources against unauthorized use becomes critical.

By now you already realized that it is not possible to have a 100% secure network. At the same time, information needs to be accessible to be useful. Balancing accessibility and security is always a tradeoff and is a policy decision made by management.

Good security involves careful planning of a security policy, which should include access control and authentication mechanisms. These security strategies and procedures can range from a very simple password policy to complex encryption schemes. Assuming that you have already implemented at least a password policy at your organization (you did it right?!), this chapter will be discussing about the many levels and types of encryption schemes and when it is enough. Is it?

Introduction

Encrypting the information of your company can be an important security method and provides one of the most basic security services in a network: authentication exchange. Other methods, such as Digital Signatures and data confidentiality, also use encryption.

Symmetric Key Encryption (Private Keys)

There are several encryption techniques available on the market, using several kinds of algorithms, but the two main ones are the ones using keys and those not relying on keys at all.

Encryption techniques not using any keys are very simple and they work by transforming, scrambling, the information being encrypted. For instance, you could encrypt a message written in English text by just adding a number to the ASCII value of each letter, which could give a result as shown on figure 3.2. Although apparently secure, this sort of algorithm is not so secure. Actually, they are very easy to decipher. Once you learn the algorithm you will be able to decipher the encrypted information.

There are more secure algorithms that use a sort of key along with the data. Two major types of encryption algorithms are private key encryption and public key encryption, to be discussed in more details later. A private key is also called a single key, secrete key, or symmetric key. A public key is also called an asymmetric key.

With private key encryption algorithms, only one key exists. The same key value is used for both encryption and decryption. In order to ensure security, you must protect this key and only you should know it. Kerberos, for example, which is discussed in more details later on this chapter, is an authentication protocol that uses private key algorithms.

Another characteristic of private key encryption is that the keys used are usually small, making its algorithms computation relatively fast and easier then asynchronous ones.

One of the main limitations of using private key encryption is when distributing it to everyone who needs it, especially because the distribution itself must be secure. Otherwise you could expose and compromise the key and therefore, all the information encrypted with it. Thus, it becomes necessary for you to change your private key encryption every so often.

If you only have private key schemes available to you, I recommend you to use it with digital signatures, as they are much more versatile and secure.

Data Encryption Standard (DES)

The Data Encryption Standard (DES) is one of the most commonly used private key algorithm. DES was developed by IBM and became a U.S. Government standard in 1976. This is a well known algorithm, with a large implementation base in commercial and government applications. As mentioned earlier, Kerberos uses the DES algorithm to encrypt messages and create the private keys used during various transactions.

DES is very fast. According to RSA Labs, when DES is implemented entirely in software, it is at least 100 times faster than the RSA algorithm. But if implemented in hardware, DES can outperform the RSA algorithm by 1000 or even 10000 times since DES uses S-boxes, which have very simple table-lookup functions, while RSA depends on very-large-integer arithmetic.

DES uses the same algorithm for encryption and decryption. The key can be just about any 64-bit number. Because of the way the algorithm works, the effective length is 56 bits. NIST certified DES for use as an official US Government encryption standard but only for "less-than-top-secret secret material." Although DES is considered very secure, there are actually two known ways to break it:

• Through an exhaustive search of the keyspace, providing a total of 2^56 (about 7.2*10^16) possible keys, which would take about 2,000 years if you were to test one million keys every second, and
• Good luck!

Until recently, DES was never been broken and was believed to be secure. But a group of Internet users, working together in a coordinated effort to solve the RSA DES challenge, see figure 3.3, for over four months finally broke the algorithm. The group checked nearly 18 quadrillion keys, finding the one correct key to reveal the encrypted message:

The group used a technique called "brute-force", where the computers participating in the challenge began trying every possible decryption key. There are over 72 quadrillion keys (72,057,594,037,927,936). At the time the winning key was reported to RSA Data Security, Inc, in June of 97, the group, known as DESCHALL (DES Challenge), had already searched almost 25% of the total possibilities. During the pick time of the group’s efforts 7 billion keys were being tested per second. Figure 3.4. is a screenshot of the DESCHALL site, located at URL http://www.frii.com/~rcv/deschall.htm

Although DES was cracked, it has remained a secure algorithm for over 20 years. The brute-force attack used against DES is very common when trying to decipher an algorithm. Although you must try all the possible 2^56 keys of DES on a plaintext and match the result against the known corresponding ciphertext, by using differential cryptanalysis you could reduce the amount of tryouts to 2^47, which is still a big project to undertake. If DES were to use a key longer than 56-bit key, the possibilities of cracking it would be nearly to impossible.

International Data Encryption Algorithm (IDEA)

International Data Encryption Algorithm (IDEA) is one of the best and most secure algorithms available. Developed by Xuejia Lai and James Massey of the Swiss Federal Institute of Technology, IDEA uses a block size of 64 bits, sufficiently strong against cryptanalysis. IDEA also uses a cipher feedback operation that strengthens the algorithm even further. In this mode, ciphertext is used as input into the encryption algorithm.

Another important feature of IDEA is its key length of 128 bits. As you saw with DES, the longer the key, the better. Also, IDEA gives no clues to the contents of the plain-text when you try to decipher it, it spreads out a single plain-text bit over many ciphertext bits, hiding the statistical structure of the plain-text completely.

Nevertheless, IDEA does have minimum requirements, and it will need a 64 bits of message text in a single coding block in order to ensure a strong ciphertext. If you’re encrypting large amount of data, it shouldn’t be a problem, but not indicated for situations where 1 byte keystrokes are exchanged. Clearly, IDEA is ideal for FTP, when large amount of data are transmitted. However, as you might guess, it would work very poorly with Telnet.

Fauzan Mirza developed a secure file encryption program called Tiny IDEA (http://www.dcs.rhbnc.ac.uk/~fauzan/tinyidea.html). Figure 3.5 shows a screenshot of Tiny IDEA’s site, where the program can be downloaded and instructions and additional information about the program is available.

CAST

Developed by Carlisle Adams and Stafford Tavares, CAST algorithm uses a 64-bit block size and a 64-bit key. The algorithm uses a six S-boxes with an 8-bit input and a 32-bit output. Don’t even ask me about the constitution of these S-boxes, as it is very complicated and out of the scope of this book. For that I strongly recommend Bruce Schneier’s book "Applied Cryptography," by John Wiley (ISBN 0-471-11709-9), which is a great book for those wanting to dig into cryptography.

CAST encryption is done by dividing the plaintext block into two smaller blocks, left and right blocks. The algorithm has eight rounds and in each round one half of the plaintext block is combined with some key material using a function "f" and then XORed with the other block, the left one to form a new right block. The old right hand becomes the new left hand. After doing this eight times the two halves now will be concatenated as a ciphertext. Table 3.1 shows the "f" function, according to the example of Schneier in the above mentioned book, page 335, which is very simple.

Figure 3.6 is a screenshot of a DES S-boxes site at the College of William and Mary, courtesy of Serge Hallyn at URL http://www.cs.wm.edu/~hallyn/des/sbox.html, which is worthwhile for you to check. Also, for your convenience, figures 3.7 through 3.14 are screenshots of DES S-box 1 through 8 respectively.

Skipjack

Skipjack is an encryption algorithm developed by the National Security Agency (NSA) for the Clipper chips. Unfortunately, not much is known about the algorithm, as it is classified as secret by the US government. It is known that this is a symmetric algorithm, which uses a 80-bit key and has 32 rounds of processing per each encrypt or decrypt operation.

The Clipper-chip is a commercial chip made by NSA for encryption, using the Skipjack algorithm. AT&T does have plans to be using the Clipper for encrypted voice phone lines.

But is Skipjack Secure?

As far as I know, NSA has been using Skipjack to encrypt it’s own messaging system, so that leads to think the algorithm itself is secure. Skipjack uses 80-bit keys, which means there are 2^80 (approximately 10^24) or more than 1 trillion trillion possible keys to be used!! This means that (ready for this?!) it would take more than 400 billion years for every key of the algorithm to tried!

To give you a better perspective, if we were to assume the use of 100,000 RISC computers, each with the capability of cranking about 100,000 encryptions per second, it would still take about 4 million years for a code to be broken.

The developers of Skipjack estimated that the cost of processing power to break the algorithm is halved every eighteen months, and based on that that it would take at least 36 years before the cost of breaking Skipjack by brute-force to be equal to the cost of breaking DES today. Thus, they believe that there is no risk for Skipjack to be broken within the next 30-40 years. Besides, it is also known that the strength of Skipjack against a cryptanalytic attack does not depend on the secrecy of the algorithm, so even if the algorithm were to be known, Skipjack would still believed to be very secure.

Clipper uses Skipjack with two keys, and whoever knows the chip’s "master key" should be able to decrypt all messages encrypted with it. Thus, NSA could, at least in thesis, decrypt Clipper-encrypted messages with this "master-key" if necessary. This method of tampering with the algorithms is what is so called and know as the key escrow.

There are many resistance from concerned citizens and the business sector against the Clipper-chip as they perceive it as an invasion of their privacy. If you check the URL http://www.austinlinks.com/Crypto/non-tech.html you will find detailed information about the Clipper wiretap chip.

RC2/RC4

RC4, which used to be a trade secret until the source code was posted in the USENET, is a very fast algorithm, designed by RSA Data Security, Inc. RC4 is considered a strong cipher, but the exportable version of Netscape’s Secure Socket Layer (SSL), which uses RC4-40, was recently broken by at least two independent groups which took them about eight days.

Table 3.2 gives you an idea of how the different symmetric cryptosystems compare to each other.

Asymmetric Key Encryption/Public Key Encryption:

In this cryptosystem model, two keys, used together, are needed. One of the keys always remains secret while the other one becomes public. You can use each key for both encryption and decryption. Public key encryption helps solve the problem of distributing the key to users.

Some examples of public key encryption usage includes:

• Certificates to ensure that the correct public and private keys are being used in the transaction.
• Digital Signatures to provide a way for the receiver to confirm that the message came from the stated sender. In this case, only the user knows the private key and keeps it secret. The user’s public key is then publicly exposed so that anyone communicating with the user can use it.
• Plaintext encrypted with a private key can be deciphered with the corresponding public key or even the same private key.

One of the main public key encryption algorithm is RSA, which was named after its inventors, Rivest, Shamir, and Adleman. These public key algorithms always have advantages and disadvantages. Usually, the encryption and decryption of the algorithms use large keys, often with 100 or more digits. That’s why the industry has the tendency to resolve key management and computing overhead problems by using smart cards such as SecureID and so on.

Zimmermann’s Pretty Good Privacy (PGP), is an example of a public-key system, which is actually becoming very popular for transmitting information via the Internet. These keys are simple to use and offer a great level of security. The only inconvenient is to know the recipients’ public key, and as its usage increases, there are a lot of public keys out there, without a central place to be stored. But there is a "global registry of public keys" effort at works, as one of the promises of the new LDAP technology.

RSA

RSA, developed invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman (RSA), is a public-key cryptosystem for both encryption and authentication. RSA has become a sort of standard as it is the most widely used public-key cryptosystem.

RSA works as follows: take two large primes, p and q, and find their product n = pq. Choose a number, e, less than n and relatively prime to (p-1)(q-1), and find its inverse, d, mod (p-1)(q-1), which means that ed = 1 mod (p-1)(q-1); e and d are called the public and private exponents, respectively. The public key is the pair (n,e); the private key is d. The factors p and q must be kept secret, or destroyed.

It is difficult (presumably) to obtain the private key d from the public key (n,e). If one could factor n into p and q, however, then one could obtain the private key d. Thus the entire security of RSA is predicated on the assumption that factoring is difficult; an easy factoring method would break RSA.

RSA is fast, but not as DES. The fastest current RSA chip has a throughput greater than 600 Kbits per second with a 512-bit modulus, implying that it performs over 1000 RSA private-key operations per second.

Is RSA Algorithm Secure?

The security of RSA will depend on the length of the keys used. A 384 bits key can be broken much easier then a 512 bits, which is still probably insecure and breakable. But if use a 768 bits key, then the amount of possible combinations grow substantially. According to RSA’s FAQ (http://www.rsa.com/rsalabs/newfaq/secprserv.htm), as seen on figure 3.15, a 1024 bits key should be secure for decades.

But this doesn’t mean that RSA is unbreakable. You you can compute e-th roots mod n you can break the code. Since c = m^e, the e-th root of c is the message m. This attack would allow someone to recover encrypted messages and forge signatures even without knowing the private key.

Also, according to RSA’s FAQ at the URL above, the cryptosystem is very vulnerable to chosen-plaintext attacks, and a good guess can reveal the used key. Thus, it is advisable to include some random data (at least 64 bits) to the encrypted plaintext.

Digital Signature Standard (DSS)

Digital Signature Standard (DSS) is a US government standard for digital signaturing. DSS has some problems being the leakage of secret data one of them. Also, if you use the same random number twice when generating the signature, the secret key will be revealed. Further, with Diffie-Hellman and RSA cryptosystem methods being available, which are much better then DSS, I see no reason for using DSS.

Table 3.3 shows a comparison table of the asymmetric cryptosystems available.

Figure 3.16 shows a summary overview of how public/private keys are generated.

Message Digest Algorithms

Message Digest (MD) algorithm are developed to take any message as input and produce an output of 128-bit "message digest," also called "fingerprint." Two messages can never have the same message digest. There are three versions of message digest available, the MD2, MD4 and MD5, which is discussed in more details next.

MD2, MD4 and MD5

The Message Digest Algorithm 5 (MD5) is the latest version of the MDs, a secure hash algorithm, which was developed by RSA Data Security, Inc. MD5 can be used to hash an arbitrary length byte string into a 128 bit value, as its earlier versions. However, MD5 is considered a more secure hash algorithm and it is widely in use.

MD5 processes the input text in 512-bit blocks, divided into 16 32-bit sub-blocks. The output is a set of 4 32-bit blocks, which are concatenated to a single 128-bit hash value.

Although very secure, MD5 was recently reported having some potential weaknesses in it, which are breakable in some cases. It is also said that one could build a special-purpose machine costing a few million dollars to find a plaintext matching a given hash value in a few weeks, but it can be easier than that.

For instance, Microsoft Windows NT uses MD4, which is discussed on the next section, to encrypt the password entries that are stored in its Security Account Manager (SAM) database. Earlier this year, around the Spring of 1997, a weakness on the security of Windows NT was exploited, which involved the security of the MD4 as well.

Couple utilities widely available on the Internet, called PWDUMP (you can download it from http://www.masteringcomputers.com/util/nt/pwdump.htm) and NTCRACK (also downloadable from http://www.masteringcomputers.com/util/nt/ntcrack.htm), were used to crack users passwords on NT. The SAM database, target of PWDUMP, is the one responsible for storing the passwords on NT. But SAM doesn’t really store the passwords in plaintext, but a hash value of it, as shown on figure 3.17.

If you carefully check figure 3.17 you will find out that the hash of my password on my computer is exposed, but the password is still UNKOWN. When a password is entered for the first time on NT, the system uses MD4 to generate a hash of that password, which is exposed by PWDUMP, as shown in the fourth line, in front of the field "NTHASH." This hash is then encrypted before it is stored in the SAM database.

The problem here is that PWDUMP is capable of finding out the function used to encrypt the values of this hash created by MD4. Since the encrypting process of MD4 is know (remember that earlier in this chapter we mentioned that the source code of MD4 was posted on the USENET?), the password can be found by a reverse engineering process. You can then use NTCRACK, as well as many other tools derived from it, to feed MD4’s encryption system with a list of words (from a dictionary, for example) and compare the value of the hashes of each word until you find the one that matches the password, which is easier on NT since it doesn’t use a randomic elements (SALT) during the encryption process—this doesn’t mean that UNIX systems are more secure, as they use SALT, it just would delay the decryption process a little longer!

In order to exploit NT’s password encryption system and MD4 is not a big deal here. The major challenge is that you will need to connect to the machine you want to exploit as an administrator. Once done that, here it is what you’ll need to do:

1. Create a temporary directory where you will run the tools and make sure both, PWDUMP and NTCRACK reside there.
2. Type PWDUMP > LIST.TXT (or any other suggestive name you want. This file will store all the password hashes PWDUMP will find).
3. Now it is time to use NTCRACK! Type NTCRACK PASSWORDS LIST.TXT > CRACKED.TXT. (PASSWORDS is the name of the file containing words, preferably a whole dictionary, in ASCII format. NTCRACK comes with a basic dictionary file, you should add more words to it. Ask your secretary to enter the whole Webster there! Once the process is finished you just need to open the file named CRACKED.TXT with any text editor and check which passwords were cracked.

The NTCRACK version listed earlier is one of the most updated one at the time this chapter is written, mid-June of 1997. This version not only checks the passwords against its basic dictionary, but also checks for passwords that are identical to the username, which I used as an example for a cracked password on figure 3.18. Note that only passwords part of the dictionary file are cracked. That’s why it’s so important to use long passwords, eight characters or more and not found in any dictionary.

If you want to try this cracking tool on yourself, you can try it out on the Web. All you will need is to be running Internet Explorer, which also exposes its security flaws, and access the URL http://www.efsl.com/security/ntie/. There, click on the hyperlink "TRY IT." The system should provide an output with your password exposed, as shown on figure 3.18, if your password was part of its dictionary file!

As you can see on figure 3.8, whereas on the previous figure the password was unknown, now it lists my last name, GONCALVES, as it checked for passwords identical to account name.

You should know that MD5 is considered to be relatively more secure then MD4 and good enough for most purposes.

Secure Hash Standard/Secure Hash Algorithm (SHS/SHA)

Secure Hash Algorithm (SHA), also known as Secure Hash Standard (SHS) was developed by the US Government and has the ability to produces an 160-bit hash value from an arbitrary length string.

SHS is structurally similar to MD4 and MD5, only about 25% slower than MD5 but as a trade-off much more secure, because it produces message digests that are 25% longer than those produced by the MD functions, which makes it much more secure to brute force attacks than MD5.

Certificates

To guarantee the authenticity of users and their keys, the Public key system requires a third party who is trusted by, and independent of, all the other parties communicating with each other.

This third party is called the Certification Authority (CA), because it is their job to certify that the owner of a Public key really is who they claim to be. To certify a Public key, the CA (such as VeriSign) creates a certificate that consists of some of the user’s identification details and the user’s Public key. The CA then digitally signs this certificate with their own Private key to create a Public Key Certificate.

Users can check the authenticity of another user’s Public key by verifying the CA signature on the certificate using the CA’s Public key, which is made widely available to the public.

After decrypting the message, the receiver verifies the sender’s digital signature. To do this, a digest of the document is created using the same hash algorithm that created the original signature. At the same time, the digital signature that was attached to the document is decrypted using the sender’s Public key. This creates a digest of the digital signature.

The digests of the document and the digital signature are then compared. If there is even the slightest difference between the two, the signature is rejected. If the digests match exactly, the receiver knows that the document was not changed in transit, and can be sure of the identity of the sender.

Since the sender is the only person who has access to the Private key used to sign the message, they can’t deny having sent it. Figure 3.19 shows a process where a digital signature is verified.

Certificate Servers

Certificate Servers are applications developed for creating, signing, and managing standard-based, public-key certificates. Organizations use Certificate Servers, such as Netscape’s certificate server (http://home.netscape.com/comprod/server_central/support/faq/certificate_faq.html#1) to manage their own public-key certificate infrastructure rather than relying on an external Certificate Authority service such as VeriSign, as discussed in the previous section.

Another vendor, OpenSoft (http://www.opensoft.com/products/expressmail/overview/certserver/) also provides Certificate Server technology for Windows NT and Windows 95 platforms. OpenSoft, uses an architecture based on the new Distributed Certificate System (DCS), which makes it a reliable public key distribution system. Figure 3.20 is a screenshot of OpenSoft’s Certificate Server page.

DCS: What is Under the Hood?

As briefly discussed in the previous section, the Distributed Certificate System (DCS) server is a speed-optimized certificate server, based upon the DNS model. The server initially only supports four resource record types:

• certificate records (CRT),
• certificate revocation lists (CRL),
• certificate server records by distinguished name (CS), and
• certificate server records by mail domain (CSM).

As the DCS is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. As in DNS, the DCS server uses a delimited, text-based file format named the DCS master files. The DCS server allows multiple master-files to be used in conjunction, as well as a ‘root’ file, where authoritative root server information is stored.

The Certificate Server

A certificate server allows a user agent or other certificate servers to query for certificate information. The following is a brief overview of the characteristics of a certificate server:

1. A certificate server maintains the following records:

• A CRT record has three fields:
• distinguished name,
• record type (CRT),
• the certificate
• A CRL record has three fields:
• CA’s distinguished name,
• record type (CRL),
• the signed CRL
• A CS record has three fields:
• distinguished name segment,
• record type (CS),
• server address
• A CSM record has three fields:
• domain name,
• record type (CSM),
• server address

• if a CRT or CRL record is not present, the server searches for a CS record to see where the certificate may be found, otherwise the server asks a DCS root server where to look for this certificate or CRL
• if the CRT or CRL record is present, the certificate or CRL is returned

• Refer to RFC 1779 ("A String Representation of Distinguished Names") to obtain the necessary format for distinguished names in CS(M) queries.
• At the user agent, marking an attribute or set of attributes in the distinguished name allows the server to decide how to look for the corresponding certificate on another server via a CS query
• Only the marked attribute or set of attributes is used in a CS query, this marked set is the common element in distinguished names of certificates located at the server with the correct key, but not all certificates at this location have this common element
• This query method is similar to how DNS uses the NS record to find the address of servers with a common domain
• By default, a user agent uses the e-mail attribute as the marked attribute, if no other attribute or set of attributes is marked. From the e-mail address, the domain name is extracted and then used in a CSM query. If there is no email attribute and no other marked attribute, then the first attribute in the first set is used as the marked attribute.
• A user agent may also request CRLs from the DCS in the above manner.

DCS Topology

A common topology of multiple DCS hosts and their role in the Internet is represented on figure 3.21.

On figure 3.21, note that:

1. Edit DCS master files . Records used: CRT, CRL, CS, CSM
2. Request to the Certificate Authority for CRL(s). Records used: CRL
3. Request to the certificate server for certificates and CRLs. Record used: CRT, CRL
4. DCS inter-server communication. Records used: CS, CSM

The DCS topology illustrates the high-speed nature of this system. A user agent may query a local certificate server and in milliseconds receive a transmission of the desired certificate or CRL from that certificate server or perhaps another server located anywhere on the Internet.

DCS Protocol

Refer to RFCs 1032-1035 on the DNS protocol for the exact syntax on DCS queries. The DCS query protocol will have the same format as the DNS query protocol. The syntax of distinguished names within DCS queries will conform to RFC 1779 ("A String Representation of Distinguished Names").

All communication inside of the DCS protocols are carried in a single format called a DCS message (DCSM). The top level format of message is divided into 5 sections, just like with DNS, some of which are empty in certain cases, as shown on figure 3.22.

Looking at figure 3.22, the header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query or a response, a standard query or some other opcode, etc.

The names of the sections after the header are derived from their use in standard queries. The question section contains fields that describe a question to a name server. These fields are a query type (as the QTYPE in DNS), a query class (as the QCLASS in DNS). The last three sections have the same format: a possibly empty list of concatenated DCS records. The answer section contains RRs that answer the question; the authority section contains RRs that point toward an authoritative name server; the additional records section is not used in the DCS.

Header Section Format

The header contains the following fields, as shown on figure 3.23:

• ID - A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied the corresponding reply and can be used by the requester to match up replies to outstanding queries.
• QR - A one bit field that specifies whether this message is a query (0), or a response (1).
• OPCODE - A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are:
• 0 - a standard query (QUERY)
• 1 - an inverse query (IQUERY) (the DCS does not support it)
• 2 - a server status request (STATUS)
• 3 - a simple query. The certificate server makes a search of an information until finds a first required DCS record (SMQUERY).
• 4 - an update query. A CA sets this type when sending to a certificate server new certificates or a CRL(UQUERY).
• 5-15 - reserved for future use (in DCS)
• AA - Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the distinguished name in question section. Note that the contents of the answer section may have multiple owner names because of aliases. The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section.
• TC - Truncation - specifies that this message was truncated due to length greater than that permitted on the transmission channel.
• RD - Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional.
• RA - Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server.
• Z - Reserved for future use. Must be zero in all queries and responses.
• RCODE - Response code - this 4 bit field is set as part of responses. The values have the following interpretation:
• 0 - No error condition
• 1 - Format error - The certificate server was unable to interpret the query.
• 2 - Server failure - The DCS server was unable to process this query due to a problem with the certificate server.
• 3 - Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the distinguished name referenced in the query does not exist.
• 4 - Not Implemented - The certificate server does not support the requested kind of query.
• 5 - Refused - The certificate server refuses to perform the specified operation for policy reasons. For example, a certificate server may not wish to provide the information to the particular requester, or a certificate server may not wish to perform a particular operation, such as zone transfer, for particular data.
• 6-15 - Reserved for future use.
• QDCOUNT - an unsigned 16 bit integer specifying the number of entries in the question section.
• ANCOUNT - an unsigned 16 bit integer specifying the number of RRs in the answer section.
• NSCOUNT - an unsigned 16 bit integer specifying the number of RRs in the authority records section.
• ARCOUNT - an unsigned 16 bit integer specifying the number of resource records in the additional records section. In the DCS protocol this value must be 0.

Question Section Format

The question section is used to carry the "question" in most queries, such as the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format, as showing on figure 3.24:

where:

• QNAME - a DER encoded distinguished name.
• QTYPE - a two octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field.
• QCLASS - a two octet code that specifies the class of the query. This field is used for compatibility with the DNS only. For DCS it must equal the IN (the Internet).

The DCS Record

The answer and authority all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header.

Each resource record has the following format, as shown on figure 3.25:

where:

• NAME - A DER encoded distinguished name. If its first attribute is the e-mail address, the server finds an information by e-mail address. In another case it finds by whole distinguished name. Maybe in the query a distinguished name attribute may contain a star symbol (‘*’) as wildcard instead a value. Then any value of this attribute will satisfy that template. In fact, if value equals an star symbol, then the server checks only an existence of this attribute and ignores its value.
• TYPE - Two octets containing one of the DCS record types. This field specifies the meaning of the data in the RDATA field.

• AXFR - 252 A request for a transfer of entry zone (it is identical to the DNS query). This value is same the DNS AFXR.
• CLASS - two octets which specify the class of the data in the RDATA field. For the DCS this value must be equal the IN.
• TTL - a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. The each DCS record contains a time value. This field may not be necessary.
• RDLENGTH - an unsigned 16 bit integer that specifies the length in octets of the RDATA field. In DCS the DATA is the DER encoded value. Thus the RDATA contains its length. Therefore this filed is not used.
• RDATA - A DER encoded ASN.1 type. The format of this information varies according to the TYPE of the RR.

If you would like to have more information about DCS message compression and transport, as well as server algorithm, please check OpenSoft URL at URL http://www.opensoft.com/dcs/, as I feel that this kind of information already goes beyond the scope of this book.

Key Management

The only reasonable ways to protect the integrity and privacy of information is to rely upon the use of secret information in the form of private keys for signing and/or encryption, as discussed earlier in this chapter. The management and handling of these pieces of secret information is generally referred to as "key management." This includes the process of selection, exchange, storage, certification, expiration, revocation, changing, and transmission of keys. Thus, most of the work in managing information security systems lies in the key management.

The use key management within public key cryptography, as seeing earlier, is appealing because it simplifies some of the problems involved in the distribution of secret keys. When a person sends a message, only the receiver can read it. This without having any need for the receiver to know the original key used by the sender or agree on a common key, as the key used for encryption is different from the key used for decryption.

Key management not only provides convenience for encrypted message exchange, but also provides the means to implement digital signatures. The separation of public and private keys is exactly what is required to allow users to sign their data, allow others to verify their signatures with the public key, but not have to disclose their secret key in the process.

Kerberos

The Kerberos protocol provides network security by regulating user access to networking services. In a Kerberos environment, at least one system runs the Kerberos Server. This system must be kept secure. The Kerberos Server, referred to as a trusted server, provides authentication services to prove that the requesting user is genuine. Another name for the Kerberos Server is the Key Distribution Center (KDC).

Other servers on the network, and all clients, are assumed by the system administrator to be untrustworthy. For the Kerberos protocol to work, all systems relying on the protocol must trust only the Kerberos server itself.

In addition to providing authentication, Kerberos can supply other security services such as:

• Data integrity
• Data confidentiality

Kerberos uses private key encryption based on the Data Encryption Standard (DES). Each client and server has a private DES key. The Kerberos protocol refers to these clients and servers as principals. The client’s password maps to the client’s private key.

The Kerberos Server maintains a secure database list of the names and private keys of all clients and servers that are allowed to use the Kerberos Server’s services. Kerberos assumes that all users (clients and servers) keep their passwords secure.

The Kerberos protocol solves the problem of how a server can be sure of a client’s identity. Kerberos does this by having both the client and server trust a third party, in this case, the Kerberos Server. The Kerberos Server verifies the client’s identity.

Getting to Know Kerberos Terms

Some of the terms commonly associated with Kerberos include:

• Principal - Kerberos refers to clients and servers as principals and assigns each one a name. An example of the general naming format is name.instance@realm.

• name — For clients, this is the user’s login name; for servers, it is the name of the service provided, usually rcmd.
• instance — This is usually omitted and unnecessary for clients; for Kerberos administrators, the value is admin; for servers, it identifies the machine name of the application server that has Kerberos authentication support. For example, if the rlogin server on hostX has Kerberos authentication support, the principal would have the following format: rcmd.hostX@your_realm
• realm — Is associated with all principals in a Kerberos database and is the name of a group of machines, such as those on a LAN; it identifies the Kerberos domain.

• Ticket–granting ticket - A ticket–granting ticket contains an encrypted form of the user’s Kerberos password. Use it to obtain application service tickets from the Kerberos server. You cannot use Kerberos authentication without first having this ticket–granting ticket.

• Service ticket - Kerberos uses service tickets to verify a client’s identity to an application server. The Kerberos server encrypts the service ticket with the application server’s private key. Only that application server can decrypt the service ticket.
• Authenticator - The Kerberos protocol uses authenticators to prevent eavesdroppers from stealing a ticket. The client sends a new authenticator with each service request. An authenticator consists of the client’s name and IP address, and a timestamp showing the current time.

What is in a Kerberos Session

The Kerberos protocol is an authentication system for open systems and networks. Kerberos uses a set of encrypted keys and tickets for authentication, making authentication between two systems secure.

Standard authentication methods, on the other hand, are not secure because the username and password are generally sent across the network in clear, readable text.

A Typical Kerberos Session

The following describes the general sequence of a Kerberos session, as shown on figure 3.2 6):

1. The Client submits a request to the Kerberos Server to obtain a ticket–granting ticket (TGT). The Kerberos Server consults the Kerberos database (KDB) to get the user’s Kerberos password, and then encrypts it.
2. The Kerberos Server sends the encrypted password in the TGT to the Client. When the Client receives the TGT, it requests the user’s Kerberos password, then encrypts the password and compares it to the password in the TGT. A user is authenticated this way by the Kerberos Server.
3. The Client uses the TGT to apply for application service tickets so that users can access specific applications. Each service ticket proves the Client’s identity to an application server.
4. The Client presents the service ticket to the application server for authentication. The application server decrypts part of this ticket to check its authenticity.
5. If the application server finds that the service ticket is authentic, it applies the access control it previously defined for that client. If the application server cannot decrypt the service ticket, or if the service ticket has expired or is not authentic, the client is not authenticated.

The following sections describe a Kerberos session in more detail.

Getting a Ticket-Granting Ticket From the Kerberos Server

The Kerberos Server has a secure database on its machine. A Client must get a ticket-granting ticket (TGT), which cannot be read by the Client, from the Kerberos Server.

The TGT lets a Client submit specific requests to the Kerberos Server for application service tickets that grant access to application servers. A Client must have an application service ticket when it requests a service from an application server.

The following process, as shown on figure 3.27, describes getting a TGT:

1. The Client user sends a request to the Kerberos Server. The request packet contains the client’s user name.
2. The Kerberos Server looks for the user name in its secure database and extracts the private key for it.
3. The Kerberos Server:

1. Creates a randomly generated key to be used between the Client and the Kerberos Server. This is called the ticket-granting ticket’s session key.
2. Creates a TGT that lets the Client obtain application service tickets from the Kerberos Server. The Kerberos Server encrypts this TGT using the private key obtained from the Kerberos database.

Forms a packet containing the session key and the encrypted TGT, and encrypts the message from the Client’s private key obtained from the secure database.

Sends the packet containing the user’s encrypted Kerberos password to the Client.

Getting Application Service Tickets for Network Services from the Kerberos Server

Once a Client has a ticket-granting ticket, it can ask application servers for access to network applications.

Every request of this kind requires first obtaining an application service ticket for the particular application server from the Ticket–Granting Service (TGS).

Figure 3.28 and 3.29 outlined in the following process describe getting an application service ticket to use to access an application server.

1. Creates an authenticator to be used between the Client and the Kerberos Server. The Client encrypts the authenticator using the session key that it received previously. The authenticator contains three parts:

• user name,
• client Internet address,
• current time

2. Creates the message to send to the Kerberos Server. The packet contains three parts:

• ticket–granting ticket,
• encrypted authenticator,
• application server name

3. Sends the packet to the Kerberos Server. The Kerberos Server receives the packet from the Client.

4. Decrypts the ticket–granting ticket using its private key to obtain the session key. (The ticket–granting ticket was originally encrypted with this same key.)

• Decrypts the authenticator using the session key, which compares the:
• User name in the ticket and authenticator
• Kerberos Server name in the ticket and its own name
• Internet address in the ticket, authenticator, and received packet
• Current time in the authenticator with its own current time to make sure the message is authentic and recent.

After the Kerberos Server verifies the information in the ticket, the Server creates an application service ticket packet for the Client. The Server:

7. Uses the application server name in the message and obtains the application server’s private key from the Kerberos database.
8. Creates a new session key and then an application service ticket based on the application server name and the new session key. The Kerberos Server encrypts this ticket with the application server’s private key. This ticket is called the application ticket. This ticket has the same fields as the ticket–granting ticket:

• user-name,
• Application server name,
• client Internet address,
• new session key

2. Forms a packet containing the new session key and the encrypted application service ticket; encrypts the message with the session key, which the Client already knows:

• new session key,
• Application ticket

3. Sends the packet to the Client.

The Client decrypts the packet using the session key it received previously. From this message it receives the application service ticket that it cannot decrypt and the new session key to use to communicate with the application server.

Once a Client receives a ticket for an application service, the Client can request that service. The Client includes the application service ticket with the request for authentication that it sends to the application server. Figure 3.30 shows the process for requesting a service from an application server.

Summary Of Kerberos Authentication

There are three main steps in the Kerberos process. The Client:

1. Requests a ticket-granting ticket (TGT).
2. Presents the TGT and an authenticator to the Kerberos Server when it request access to an application server. The Kerberos Server grants the Client an application service ticket to access the application server.
3. Presents the application ticket and an authenticator to the application server when it requests access to the server. The server’s access control policy either grants or denies access to services.

The Kerberos process uses tickets, authenticators, and messages. These elements provide specific encrypted information about clients and servers. Keys are used to encrypt and decrypt tickets, authenticators, and messages.

Some things to remember about tickets and authenticators:

• A Client must have a ticket–granting ticket and a service ticket to access any application server. The Client gets all tickets from the Kerberos Server.
• The Client cannot read tickets because the Kerberos Server encrypts them with the private key of the application server. Every ticket is associated with a session key.
• Every ticket–granting ticket has a lifetime (usually eight hours) and is reusable during that lifetime.
• Kerberos requires a new authenticator from the Client each time the Client starts a new connection with an application. Authenticators have a short lifetime (generally five minutes).
• The encrypted ticket and authenticator contain the Client’s network address. Another user cannot use stolen copies without first changing his system to impersonate the Client’s network address.

To hack Kerberos is very hard! In case of an attack, before the authenticator expires, a hacker would need to:

• steal the original ticket,
• Steal the authenticator,
• prevent the original copies of the ticket and authenticator from arriving at the destination server, and
• modify its network address to match the client’s address.

Cygnus’ KerbNet

KerbNet security software is Cygnus’ commercial implementation of MIT’s Kerberos v5.

This is a great product to use when securing your network, as it provides the security of Kerberos, with its single trusted authentication server architecture, which provides the basis for a single sign-on interface for your users. Also, once you install and configure the KerbNet Authentication Server, client and server applications can be ‘Kerberized’ to work with KerbNet, which is very simple in a multi-user application environment. Basically, all you do is to replace your E-mail, ftp, or telnet, with Cygnus’ off-the-shelf Kerberized versions.

The KerbNet libraries allows in-house developers to add KerbNet authentication and encryption directly to their existing client-server applications. KerbNet Authentication Server is the first Kerberos server for both UNIX and Windows NT with encrypted tickets for requesting services, which keeps passwords off the network, prevents password spoofing attacks, and allows for encrypted communications between a client and server.

Key-Exchange Algorithms (KEA)

Diffie-Hellman was the first one to invent a public-key algorithm in 1976. Instead of the calculating the exponentiation of a field, this public-key security scheme is very secure because it calculates the discrete logarithms in a finite field, which is very hard to do. Thus, Diffie-Hellman is ideal, and can be used, for key distribution. You can use this algorithm to generate your secret key. But don’t get confused! You can’t use it for encrypting or decrypting a message!

Lets take a look at how it works.

Diffie-Hellman Public-Key Algorithm

Diffie-Hellman’s system requires the dynamic exchange of keys for every sender-receiver pair. This two-way key negotiation is very good for enhancing the security of your messages. After you encrypt a message you can then use this scheme to further complicate the decryption of your message, as the hacker would have to decrypt the key, then the message. However, as you might imagine, this will require additional communications overhead.

In the RSA system, for example, communications overhead are reduced, as the ability to have static, unchanging keys for each receiver that are ‘announced’ by a formal ‘trusted authority,’ in this case the hierarchical model, or distributed in an informal network of trust.

Diffie-Hellman’s method for key agreement actually has a simple math, which is aimed to allow two hosts to create and share a secret key. Assuming that you want to generate a secret key with your significant other (SO), here it is how this process works:

1. First, you and your partner must follow the "Diffie-Hellman parameters," which requires you to find a prime number "p," which should be larger then 2 and "base", "g," which should be an integer that is smaller than your prime number ("p"). You can either hard code them or fetch them from your server.
2. Both of you will have to each and secretly generate a private number that we will call "x," which should be less than (p-1).
3. At this point, both of you will generate the public keys, which we will call "y." You guys will create them using the function:

y = g^x % p

z = y^x % p

"z" now can be used as the key for whatever encryption method used to transfer information between the two of you. Mathematically speaking, you two should have generated the same value for "z," whereas

z = (g^x % p)^x’ % p = (g^x’ % p)^x % p

All of these numbers are positive integers, whereas

x^y     means: x is raised to the y power

x%y     means: x is divided by y and the remainder is returned

Cryptanalysis and Attacks

Cryptanalysis is the art of deciphering encrypted communications without knowing the proper keys, or if you prefer, it is the art of breaking the code! There are many cryptanalytic techniques, as well as cryptanalysts. Although it is true to say that every hacker trying to crack a code is a cryptanalyst, to say that cryptanalysis is threatening to security is not true. It is through cryptanalysis that one may find a weakness in the cryptosystem that could had eventually endangered the secrecy of a message being exchange. So, crypto, in its many forms and shapes is indeed a double-edged sword.

An encrypted key can be compromised, if the key is exposed through a non-cryptanalytic way, such as if you were to write your public-key somewhere, so you will not forget it! If anyone finds it out, key would had just being compromised! But a key can be also attacked, if someone tries to apply cryptanalysis to it.

The next sections discusses some of the most typical cryptanalysis attacks.

Ciphertext-only Attack

In this type of attack, the hacker, or cryptanalyst, does not know anything about the contents of the message, and must work from ciphertext only.

In practice it is quite often possible to make guesses about the plaintext, as many types of messages have fixed format headers. Even ordinary letters and documents begin in a very predictable way. It may also be possible to guess that some ciphertext block contains a common word.

The goal of the cryptanalyst here is then to try to deduce the key used to encrypt the message, which would also allow him/her to decrypt other messages encrypted with the same key.

Known-plaintext Attack

In this case, the hacker knows or can guess the plaintext for some parts of the ciphertext. The task is to decrypt the rest of the ciphertext blocks using this information. One way he will probably try is to determine the key used to encrypt the data.

Chosen-plaintext Attack

The hacker here is able to have any text he likes encrypted with the unknown key, he is able choose the plaintext that gets encrypted, which can lead him to ones that might yield more information about the key. Therefore, his task is to determine the key used for encryption. Some encryption methods, particularly RSA, are extremely vulnerable to chosen-plaintext attacks.

Adaptive-chosen-plaintext Attack

This is actually a variation of the chosen-plaintext attack. But in this case the hacker is able to exercise the option of modifying his choice of the encrypted plaintext based on the results of previous encryption, which allows him to choose a smaller text block of plaintext to be encrypted.

Man-in-the-middle Attack

This is a relevant attack for cryptographic communication and key exchange protocols. It’s a sort of key spoofing, where a hacker would intercept the communication between two parties exchanging keys for secure communication, such as Diffie-Hellman’s, corrupting the key by performing a separate key exchange with each party and forcing each one of them to use different keys, each of which is known by the hacker. The hacker will then decrypt any communications with a now valid key, and encrypt them with the other key for sending to the other party. Worse, the parties will still think that they are communicating securely, as this whole process is totally transparent to both parties, they would never know what has happened until it is too late!

One way to prevent man-in-the-middle attacks is that both sides compute a cryptographic hash function of the key exchange, use a digital signature algorithm, and send the signature to the other side. The recipient then verifies the authentication of the signature as being from the desired other party, and that the hash in the signature matches that computed locally.

Chosen-ciphertext Attack

In this case, the hacker, or cryptanalyst, not only is able to choose which ciphertext he will try to decrypt but also he/she has access to the decrypted plaintext.

Usually this type of attack is applied to public-key algorithms, which very often works well against symmetric algorithms too.

Chosen-key Attack

Although the name suggests that the attacker is able to choose the key, this is not true. As a matter of fact, this is a very weird form of attack where the hacker only has some knowledge about the relationship between the two keys. Bruce Schneier brilliantly discusses this form of attack in his book Applied Cryptography, in the section "Differential and Linear Cryptanalysis."

Rubber-hose Cryptanalysis

This is the "dirty" way, where the hacker will harass, threaten, bribe and torture someone until they get the key!

Timing Attack

This is somewhat a new form of attack discovered by Paul Kocher that looks at the fact that different modular exponentiation operations in RSA takes discretely different amounts of time to process. In this process, the cryptanalyst repeatedly measures the exact execution times of modular exponentiation operations, which is very relevant for RSA, Diffie-Hellman, and Elliptic Curve methods.

Usually, RSA computations are done with what is called Chinese Remainder theorem (see figure 3.31). But if it doesn’t, a hacker could exploit slight timing differences in RSA computations in order to try to recover it.

Figure 3.31 shows a description of the Chinese Remainder Theorem at SouthWest Texas State University Web site.

The attacker passively observes "k" operations measuring the time "t" it takes to compute each modular exponentiation operation: m=c^d mod n. The attacker also knows "c" and "n." The pseudo code of the attack is:

Algorithm to compute m=c^d mod n:

             Let m0 = 1.
             Let c0 = x.
             For i=0 upto (bits in d-1):
                     If (bit i of d) is 1 then
                             Let mi+1 = (mi * ci) mod n.
                     Else
                             Let mi+1 = mi.
                     Let di+1 = di^2 mod n.
             End.

According to Ron Rivest (rivest@theory.lcs.mit.edu), at MIT, the simplest way to defeat this timing attack would be to "ensure that the cryptographic computations take an amount of time that does not depend on the data being operated on. For example, for RSA it suffices to ensure that a modular multiplication always takes the same amount of time, independent of the operands."

He also suggest a second alternative, using "blinding techniques. According to him, you could "blind the data beforehand, perform the cryptographic computation, and then unblind it afterwards. For RSA, this is quite simple to do. (The blinding and unblinding operations still need to take a fixed amount of time.) This doesn’t give a fixed overall computation time, but the computation time is then a random variable that is independent of the operands."

     m = c^d mod n 

     becomes: 

     m = r^-1(cr^e)^d mod n 

     r is the random value, and r^-1 is it’s inverse.

The University of British Columbia (http://www.ubc.ca/) has a Web site at URL http://axion.physics.ubc.ca/pgp-attack.html with vast documentation of symmetric and asymmetric crypto attacks, which are well worth checking out.

Cryptography Applications and Application Programming Interfaces (APIs)

If you really want to understand what is going on in the crypto world you will need to grasp the ever-increasing progress and development of new applications applied to the flow of information on electronic highways, the need for secure and private communication and... control.

Of course, the government shares the concern when electronic transfer of money and the transmission of commercial information is taking place on the Internet more and more often. Although the government does care, its controversial proposal to address the security of electronic transactions over the Internet, known as the "Clipper chip" proposal, is also a double-edged sword, as it does offer secure transactions, but in a government controlled tappable way.

The result of this frenzy is the increased development of many cryptographic applications and application programming interfaces (APIs). Data privacy and secure communication channels, which includes but are not limited to authentication mechanisms and secure standards begins to be developed and proposed.

The George Washington University (http://www.seas.gwu.edu/), through the Cyberspace Policy Institute (http://www.cpi.seas.gwu.edu/) has a great selection of information policy bibliography that offers a solid foundation for the need for data protection, secure communications and its implications in the whole information processing. This section discusses some of these efforts and their impact in the security of the Internet, the hole of cryptography and firewalls.

Data Privacy and Secure communications channel

Internet users, as well as protected network users should always be responsible for data privacy within the organization and data exchanges. But it is the responsibility of the Internet manager to make sure an Internet security policy, outlining the privacy of information exists so that users can be held accountable for following it.

It should be also his/her responsibility to protect the personal privacy of users, as clearly stated in the policy, which should identify the elements of the company’s structure, such as the different levels of data confidentiality (some data may need to be encrypted, while other my need some sort of access control) and practice.

Data security policy should be applies throughout the company, regardless of the nature of the data, the storage form or location. Users must understand that the protection of individual privacy and information will only occur if all users are committed, by knowing and respecting the security policy in place. Thus, recipients of confidential data and files downloaded directly to their computers should preserve the confidentiality of data.

Also, application developing groups must take in consideration the security policy in place, and at least, if no policy is in vogue, that the applications developed do take in consideration security aspects, both at the Intranet and the Internet level.

More about security and firewall policies will be discussed later on chapter 9, "Setting up a Firewall Security Policy." For now, lets look into the authentication processes and security API and how they impact the secure communication channels.

Some Data Privacy Prime and Tools

There are several applications already available on the market to work as a standalone or in association with other applications or devices, such as firewalls, proxies and routers, to protect your personal and financial private data. Pretty Good Privacy (PGP) and Privacy Enhancement Mail(PEM) are few examples, but first things first!

You first need to understand your system. A logical or physical map can be essential to understanding the vulnerable points to data security of your system. A map also will help you in planning future changes to a system. Planning these future changes will ensure a tight grip on the reigns of security and will increase your awareness of the questions that need answering. Such control becomes critical when implementing a new addition to a system, such as a new network service like anonymous FTP (if the site does not offer it already).

Have a Password Policy

The easiest and, believe me or not, most secure way to protect an user is through a good password policy, which will force everyone on a Intranet/Internet environment to be authenticated. Nevertheless, if good passwords are vital for data security, passwords are also the first target of attack! This because many users and network systems make it easier to attack a password than attack other possible security holes in the system.

Anyone has the potential to obtain information that leads to the discovery of your password, as there are many tools, such as Crack, NTCrack and many others developed to help on cracking passwords. But many times, password information is giving away too casually. It easily can be one friend giving another the use of their account or someone watching over a shoulder while a password is entered. The best way to combat this is to choose a unique password containing a combination of letters and numbers, preferably not found in a dictionary, for example, and to be very conscious of who can observe it.

Therefore, the following is a list of tips on creating unique and safe password:

• Use numbers in the password, preferably not at the beginning or ending.
• Use non-basic words in the password. Basic words in foreign languages are just as easy to guess.
• Try keyboard tricks like shifting fingers to the left or right one key when typing the password.
• If someone is standing over your shoulder, you could always politely ask him to turn his head.
• Use non-alphanumeric characters in the password. Symbols such as $, %, ^, and & are often valid characters to use in passwords.
• Administrators can use control characters, on certain systems, in the middle of the password. You can determine which control characters can be used by trial and error.
• Use a mixture of uppercase and lowercase letters.

Authentication

As discussed above, a good password policy is very important to safeguard the integrity, confidentiality and security of your users, specially if you are involved with electronic commerce, which becomes a requirement. Therefore, authentication must become a daily user’s process, rather than a special procedure, for users to logon at their computers, the Internet and departmental Intranets.

When applying authentication methods, it is important to take into consideration the spoofing risks. Cryptography methods, as discussed earlier will help you to implement a security policy not so easy to be spoofed by hacker, but it may not be enough to protect corporate resources and other non-individual related data or resource.

Therefore, you must incorporate other strategies and technologies to enhance the level of security of your corporate network. Firewalls are definitely a requirement and will be discussed in more details throughout this book.

Authenticode

Authenticode appeared as one of Microsoft’s earliest commercial implementations of code signing. The Authenticode signature is based on currently prevailing industry standards - X509v3 certificates and PKCS#7 signature blocks.

That has being a lot of commentary in the USENET and trade magazines about ActiveX and Authenticode, but most of them focusing on how an ActiveX control operates and what Microsoft should or should not have included with the tool. So I don’t intend to reproduce the same line of thoughts here as if you want to know more about the hows, dos and don’ts of Authenticode probably a search on AltaVista would be enough. Rather, I would like us to focus on the infrastructure of what Microsoft proposes with Authenticode and its impact as a data security cryptographic-based application.

Brent Laminack (brent@ecweb.com) posted the following considerations about Authenticode on the USENET, which clearly illustrates a basic infra-structure issue with it. You judge for yourself if you would be wiiling to base your data security tasks to it.

Laminack suggests us to consider two ActiveX controls. One providing a control similar to the Win95 "Start" button with all the commands on the user’s computer presented in a list to choose from. Suppose it keeps these command names in a preferences file such as C:\windows\mycommands. The file may contain a list such as: Word, Excel, format c:, IE3, etc.

He also suggests us to consider a second ActiveX control that provides a "cron" facility, which would automatically wake up at a specified time and execute a list of commands for housekeeping such as backup, defrag, etc. Suppose it keeps its list of commands in, say, for instance C:\windows\mycommands. In his own words, "you see it coming," don’t you? What could happen is that the second control could find the file written by the first one and dutifully fire up Word, Excel, and then… format the C drive. Commands after this one are of diminishing consequence.

What now? You’re stuck! You now have a wiped hard drive and, as Laminack puts it, you have no fingerprints for Authenticode. Even if you do get them, who are you going to sic the law enforcement people on? Both controls did exactly what they were designed to do, exactly what they advertised to do. Who are you going to sue?

Worse, neither of the codes "misbehaved." What did in your disk was an unforeseen interaction between the two. Laminack suggests that with a bit of thought work it would be possible to come up with a co-operating gang of ActiveX controls to do deliberate theft via collusion where each program is only doing what it’s "supposed" to, yet the total of their activity is much greater than the sum of the parts. Yes, non-linearity is clearly at work here in the interaction of the components.

The only way to avoid this would be to strictly decouple them, by not allowing any to share information with the other, such as giving each its own private file-space to write in. This, alas is not the case.

As Microsoft puts it, the way Authenticode is implemented, both contractually and technically, at least in its present release (March of 1997), when you sign a code you are actually taking explicit responsibility as the code’s publisher, an action not to be taken lightly from a legal point of view.

But it is just to easy to say that by signing a code gives you accountability. After all, would you have an audit trail to use as supporting evidence? Also, in the software industry, history shows that usually a piece of software is not liable for damages it may causes to a system!

Although Authenticode is still the only deployed code-signing application, Netscape Navigator 4.0 already has code signing, and JavaSoft’s JDK1.1 as well. The bottom line? You’ll need much more then Authenticode, and Microsoft response is SSPI

NT Security Support Provider Interface (SSPI)

Figure 3.32 shows where the SSPI security services fit into the overall distributed application architecture.

SSPI provides a common interface between transport-level applications, such as Microsoft RPC or a file system redirector, and security providers, such as Windows NT Distributed Security. SSPI provides a mechanism by which a distributed application can call one of several security providers to obtain an authenticated connection without knowledge of the details of the security protocol.

SSPI consists of following APIs:

• Credential Management APIs — which provides access to credentials (password data, tickets, and so on) of a principal or free such access. The APIs are:
• AcquireCredentialsHandle — Acquires a handle to the reference credentials.
• FreeCredentialsHandle — Releases a credential handle and associated resources.
• QueryCredentialAttributes — Allows queries on various credential attributes like associated name, domain name, and so forth.
• Context Management APIs — Context management APIs provide methods for creating and using security contexts. The contexts are created on both the client and the server side of a communication link. These contexts can then be used later with the message support APIs. The APIs are:
• InitializeSecurityContext — Initiates a security context by generating an security token that can be passed to the server.
• AcceptSecurityContext — Creates a security context using the opaque message received from the client.
• DeleteSecurityContext — Frees a security context and associated resources.
• QueryContextAttributes — Allows queries on various context attributes.
• ApplyControlToken — Applies a supplemental security message to an existing security context.
• CompleteAuthToken — Completes an authentication token, since some protocols, like DCE RPC, need to revise the security information once the transport has updated some message fields.
• ImpersonateSecurityContext — Attaches the client’s security context as an impersonation token to the calling thread.
• RevertSecurityContext — Ceases impersonation and defaults the calling thread to its primary token.
• Message Support APIs — Message support APIs provide communication integrity and privacy services based on a security context. The APIs are:
• MakeSignature — Generates a secure signature based on a message and a security context.
• VerifySignature — Verifies that the signature matches a received message.
• Package Management APIs — Package Managment APIs provide services for different security packages that the security provider supports. The APIs are:
• EnumerateSecurityPackages — Lists available security packages and their capabilities.
• QuerySecurityPackageInfo — Queries an individual security package for its capabilities.

SSPI does not currently provide any public interfaces for encryption/decryption functionality. A security provider is a dynamic-link library that implements the Security Support Provider Interface and makes one or more security packages available to applications. A security package maps the SSPI functions to an implementation of the security protocol specific to that package, such as NTLM, Kerberos, or SSL. Security packages are sometimes referred to as "SSPs," such as the "NTLM SSP." The name of the security package is used in the initialization step to identify a specific package.

The Security Support Provider Interface allows an application to use any of the available security packages on a system without changing the interface to use security services. SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system.

An application can use the package management functions to list the security packages available and select one to support its needs. The application then uses the credential management functions to obtain a handle to the credentials of the user on whose behalf they are executing. With this handle, the application can use the context management functions to create a security context to a service. A security context is an opaque data structure that contains the security data relevant to a connection, such as a session key, the duration of the session, and so on. Finally, the application uses the security context with the message support functions to ensure message integrity and privacy during the connection.

Microsoft Cryptographic API (CryptoAPI)

The Microsoft Cryptographic API (CryptoAPI) provides services that enable application developers to add cryptography to their Win32 applications. Applications can use the functions in CryptoAPI without knowing anything about the underlying implementation, in much the same way that an application can use a graphics library without knowing anything about the particular graphics hardware configuration.

CryptoAPI is a set of functions that allow applications to encrypt or digitally sign data in a flexible manner, while providing protection for the user’s sensitive private key data.

All cryptographic operations are performed by independent modules known as cryptographic service providers (CSPs). One CSP, the Microsoft RSA Base Provider, is bundled with the operating system.

Each CSP provides a different implementation of the CryptoAPI. Some provide stronger cryptographic algorithms while others contain hardware components such as smartcards. In addition, some CSPs may occasionally communicate with users directly, such as when digital signatures are performed using the user’s signature private key.

Cryptography and Firewalling: The Dynamic Dual

No doubt, companies want, and need, a piece of the Internet. For some of you, Internet Managers, this may involve implementing an Intranet--a private IP network created with Web servers and browsers that runs over your protected network. But most likely, it will involve setting up the meaning for transferring data, including sensitive one, over the Internet.

Firewalls play a major role in protecting corporate sites from the Internet, but the old firewall concept, based on routers and few deny/allow statements are no longer enough to keep the hackers and crackers out. The statistics are not encouraging, as according to the Computer Security Institute, 1/5 of all companies on the Internet have been or are going to be hacked. Worse, at least 1/3 of them will be hacked after a firewall has being in place!

Chapter 7, "What is an Internet/Intranet Firewall After All" provides in depth details of the various types of firewalls available on the market, its features and, mostly important, the technology behind it. However, data can be stolen on the Internet, despite the presence of a firewall, as they can be intercepted outside the firewall, while still on the Internet. Besides, as data can be stolen on the Internet, it can also be modified. Anyone could, for example, insert an malicious applet as an attachment to an intercepted e-mail message, that once activated it could disable the firewall or even compromise the security of your protected network.

Consider this scenario: you contract me to develop some applications using ActiveX. I develop some applications as plug-ins for you Internet Explorer and you get all happy. However, once your users agree to use this plug-in I become registered with Explorer as a trusted publisher. What it means is that from now on all the requisitions to download the plug-in I developed won’t trigger the permission dialog box! Is it a bug or a feature?! Remember the ActiveX discussion earlier?

Far from being a fiction, unfortunately it is real. If you check C|net’s URL at http://www.news.com/News/Item/0,4,3707,00.html, you see that earlier this year, around February of 1997, the same thing happened to InfoSpace. Fortunately, InfoSpace folks saw this "resource" as a bug and did an update on their plug-in. But here it is the question: can we assume that all the plug-in editors for the Internet Explorer are as responsible as InfoSpace?

When a download of an executable component is done, this component shouldn’t be able to silently manipulate the security policy of a system, especially since the firewall, if any present, could not stop the corrupted message from accessing the protected network. However, it is almost impossible to prevent such a behavior from happening when we consider the active content model of Microsoft.

It is not new that the Java model is more robust then ActiveX when addressing this problem. But as a side effect, Java lacks such a feature, well, if we consider it a feature!

A feature or a bug, what I am most concerned is the fact that a shrewd developer could generate an ActiveX control that would do nothing more than open the doors of the system and let all the other programs come in without even passing through the Authenticode. This ActiveX control could even let another version of itself access the system, accordingly signed, but without malicious codes, which would cover up any trace of it in the system.

Unfortunately, with ActiveX, when an user allows the code to run on the system, there are many "distressing" situations that could happen. In a way, this is not a problem affecting only ActiveX. It extends through all the platforms and type of codes. If the Web made it easy for an editor to distribute his codes, it also made it easy to identify a malicious code and to alert and communicate the endangered parties.

Without a doubt, the Authenticode helps a lot in the quality control and authenticity of the code. The fact that we can rapidly identify the author of a code and demand from him a fix for a bug is an example of it. If the author refuses to fix the code, there are several avenues one could take to force him to fix it, both in the commercial level, refusing to use the code, as well as legally, bringing him to court. This feature alone already grants Authenticode some merit.

Even though, Java’s robustness and the existence of other security applets for Java, such as Java Blocking, for instance, is enough for one to argue on rather develop on ActiveX or Java.

One alternative to prevent such a vulnerability is to run a filter in combination to the firewalls, so that these applets (Java, JavaScript or ActiveX objects) can be filtered. A major example of such a tool is the so called Java Blocking, which have created a lot of confusion as far as how to run it in the most effective way, as opinions are many.

My recommendation is to run the Java Blocking as a service at the firewall. This way, it will extend the level of protection against Java applets throughout the whole network. Some browsers, such as Netscape Navigator, provide security against Java applets at the client level, allowing the user to disable Java applets at the browser. However, it becomes very difficult to administer all the clients centrally.

Carl V Claunch, from Hitachi Data Systems, developed a patch for the TIS firewall toolkit that converts the TIS http-gw proxy onto a proxy filter. This filter can be implemented as an uniform or differentiated security policy at the level of IP/domain addresses. This filter can block, permit or combine both instances based on the browser version. The security policies are created separately for Java, JavaScript, VBScript, ActiveX, SSL e SHTTP

According to Claunch, as far as blocking JavaScript, this process involves the scanning of various constructs:

1  - <SCRIPT language=javascript> ... </SCRIPT>
2 - <SCRIPT language=livescript> . . . </SCRIPT>
3 - Attribute in other tags on form onXXXX= where XXXX indicates the browser’s actions, such as click, mouse movements, etc.
4 - URLs at HREFs and SRCs with javascript: protocol
5 - URLs at HREFs and SRCs with a livescript: protocol
The Java Blocking consists in disactivating both tags <APPLET ...> and  </APPLET>,
while allowing characters to pass, which usually are alternatively HTML.

AS for the VBScript blocking it involves:

1 -  The scanning and filtering sequence of <SCRIPT language=VBScript> ....
</SCRIPT>
2 - Scanning and filtering sequence <SCRIPT language=vbs>...</SCRIPT>
3 - Removal of attributes on form onXXXXX= and many tags, just like with JavaScript
The blocking of ActiveX involves the removal sequence of <OBJECT...>...</OBJECT>.

However, the dialogs of SSL and SHTTP turns HTML blurry to the proxy. Consequently, these shttp and https HTML pages can’t be effective filtered!

But don’t you think that I’m hammering ActiveX and promoting Java! Anyone could develop a malicious plug-in for Netscape if they wanted to. As a matter of fact, the impact would have been even greater then with any ActiveX object when we consider the browsers. After all, a plug-in has as much control over Windows as an ActiveX object.

Don’t even tell me that the advantage is in having to install a plug-in versus automatically receiving an ActiveX object. There are so many implementations of Netscape out there that for sure there would had been so many users installing such a malicious plug-in as ActiveX users facing a malicious ActiveX on their pages. Furthermore, you have no way to better control the installation of a plug-in on Netscape better them you would control the installation of an ActiveX object.

As professionals involved with network and site security, lets be realistic. Many experts have been pointing out the security flaws existent on Java implementations, as well as fundamental problems with the Java security model. As an example, I could cite attacks that confuses Java’s system, resulting in applets executing arbitrary codes with total permission from the user invoking the applet.

So far, users and systems developers have been content in considering these Java problems... "temporary." They have been confident that bugs will be fixed quickly, limiting the margin of damages. Netscape has been incredible quick in fixing serious problems!

However, with the huge base of browsers capable of running Java, each one inviting a hostile applet to determine the actions of this browser, gives as the suspicion of a security flaw on Java at the implementation structure level.

There is another paper, available at Boston University’s URL at http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z, that describes attacks to firewalls that can be launched from legitimate Java applets. The document describes a situation where in some firewall environments, a Java applet running on a browser inside the firewall can force the firewall to accept connections such as TELNET, or any other TCP ones, directed to the host! In some cases, the applet can even use the firewall to arbitrarily access other hosts supposedly protected by a firewall.

Let me explain that the weaknesses exploited in these attacks are not caused by Java implementations themselves, nor by the firewall itself, but from the combination of both elements together, and on the security model resulted from the browsers access to hosts supposedly protected.

For those skeptical about the security of Java applets running on the Web, especially on browsers, here it is a "St. Thomas" test: for those running Netscape 3.0, check the URL at http://www.geocities.com/CapeCanaveral/4016/. Once there, check the Java-Jive page and watch the "little Java devils" working!

If you didn’t realize what happened, try again and pay attention: every time you enter the page, a message is sent to the author of that page, Francesco Iannuzzelli (ianosh@mv.itline.it), this without even asking your permission! The message he receives will contain your address (both user and SMTP server!) as you specified on your Netscape "preferences." According to Iannuzzelli, there is no way for you to be alerted about this bug!

The only way you would have noticed something different was going on would had been the button you see on the page, which can be hidden, and the status bar showing a connection to your mail server, which can be hidden as well!

What to do then? Encryption is the obvious alternative. The great news is that firewall vendors are realizing that an offering encryption features with their firewall products. Many are even including applet filters. Vendors like Border Network Technologies Inc., Check Point Inc. and Trusted Information Systems Inc. are some of them.

Router vendors are also working hard on increasing the level of protection they can offer to corporate networks through their products. Cisco Systems Inc. and Network Systems Corp. are some examples.

According to Lee Bruno, in an article for Data Communications on the Web, back on April of 1996, mentioned few companies already offering standalone encryption devices. As Bruno suggests, "choosing the right gear means grappling with some complex issues. Start with the basics: Where is the data being encrypted? Some vendors do it at the application level; others, in the IP stack. The former lets net managers pick and choose what they want to encrypt. The latter forces them to encrypt everything on a given link."

The underlying truth here is that encryption and firewalling becomes a dynamic dual. You should review the information and recommendations on the whole Part II of this book, "Firewall Implementations and Limitations," consider what we discussed in this chapter about cryptography and its applications and build your own security policy. Keep in mind that you will need both, encryption and firewalls, to soundly protect your corporate network. Don’t forget to read the Part III of this book, "Firewall Resource Guide," which will help you to run a "firewall attack drill" and provide you with abundant information on firewall vendors, utilities and complementary information.