© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use.

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.