Secure Hash Functions Secure hash functions are necessary for digital signatures. A hash function can be called secure if: ▼ The function is one-way. In other words, the function creates a checksum from the information but you cannot create the information from the checksum. ▲ It is very difficult to construct two pieces of information that provide the same checksum when run through the function. The second condition is not easy to satisfy. The checksums in question should also be smaller than the information so as to make it easier to sign, store, and transmit. If this is the case, it must also be true that some large number of different pieces of information will map to the same checksum. What makes the functions secure is the way that all the bits in the original information map to all the bits in the checksum. Thus, if a single bit in the information is changed, a large number of bits in the checksum will also change. Secure hash functions should create a checksum of at least 128 bits. The two most common secure hash functions are MD5, which produces a 128-bit checksum, and SHA, which produces a 160-bit checksum. There are many other hash functions but most of them have been proven insecure. MD5 has been identified as having weaknesses that may allow a computational attack. This attack may allow a second piece of information to be created that will result in the same checksum. SHA was developed by the United States government and is currently believed to be secure. Most security software offers both MD5 and SHA as available options. KEY MANAGEMENT The management of keys is the bane of all encryption systems. The keys are the most valuable information. If I can get a key, I can get (decrypt) everything that is encrypted by that key. In some cases, I may also be able to get succeeding keys. The management of keys is not just about protecting them while in use. It is also about creating strong keys, securely distributing keys to remote users, certifying that they are correct, and revoking them when they have been compromised or expired. Keys and the infrastructure necessary to manage them appropriately can significantly impact an organization’s ability to field an encryption system. While we discuss each of the key management issues in detail, keep in mind that the problems identified must be multi - plied many thousand-fold to meet the needs of a true encryption infrastructure. Key Creation Obviously, keys must be created with care. Certain keys have poor security performance with certain algorithms. For example, a key of all 0’s when used with DES does not pro - 226 Network Security: A Beginner’s Guide vide strong security. Likewise, when creating keys for use with RSA, care must be used to choose p and q from the set of prime numbers. Most encryption systems have some method for generating keys. In some cases, users are allowed to choose the key by choosing a password. In this case, it may be wise to in - struct the users on how to choose strong passwords that include numbers and special characters. Otherwise, the total key space is significantly reduced (this allows quicker brute-force key searches). Some keys are chosen from random numbers. Unfortunately, there are very few truly random number generators. Most are pseudo-random. If the generator is not truly ran - dom, it may be possible to predict the next number. If I am basing my keys on the output of the random number generator and you can predict the output, you may be able to pre - dict the key. The length of the key may also need to be chosen. Some algorithms use fixed key lengths (such as DES with a 56-bit key). Others can use variable lengths. Generally speak - ing, the longer the key, the better the security. For example, a 1,024-bit RSA key is stron - ger than a 512-bit RSA key. You cannot, however, compare the strength of the RSA key to a DES key in the same way. Table 12-1 shows the relative strengths of keys for different types of algorithms. To give an idea of how strong the keys are in reality, remember the EFF machine? It cost $250,000 in 1997 and brute-forced a DES 56-bit key in 4.5 days. In other cases a 40-bit RC5 key was brute-forced in 3.5 hours using 250 computers at UC Berkeley. The Swiss Federal Institute of Technology brute-forced a 48-bit RC5 key in 312 hours using 3,500 computers. Good recommendations at this time are to use at least 80-bit keys for private key encryption and at least 1,024-bit keys for RSA and Diffie-Hellman. 160-bit ECC keys are also thought to be secure. Chapter 12: Encryption 227 Private Key Encryption (DES, RC5) Public Key Encryption (RSA, Diffie-Hellman) Elliptic Curve Encryption 40 bits - - 56 bits 400 bits - 64 bits 512 bits - 80 bits 768 bits - 90 bits 1,024 bits 160 bits 120 bits 2,048 bits 210 bits 128 bits 2,304 bits 256 bits Table 12-1. Relative Strengths of Different Key Lengths 228 Network Security: A Beginner’s Guide Key Distribution Keys have been generated and they now must get to various locations and equipment to be used. If the key is unprotected in transit, it may be copied or stolen and the entire en - cryption system is now insecure. Therefore, the distribution channel must itself be secure. Keys could be moved out-of-band. In other words, the keys could be transported by ad - ministrators by hand. This may work if the remote sites are short distances apart. But what if the remote sites are continents away? The problem gets much harder. There is a partial solution to this problem, however. It may be possible to use the Diffie-Hellman Key Exchange in order to create and distribute many session keys (short-term keys used for a single session or a small amount of traffic). This may reduce the need to travel to remote locations. Longer-term keys (RSA keys, for example) require more care. It is not appropriate to use the Diffie-Hellman Key Exchange algorithm to distribute RSA key pairs. In the case of RSA key pairs, one key must be kept secret and one can be published. The key that is pub - lished must be published in such a way as to preclude being tampered with (see key cer - tification below). If the pairs are to be generated by a central authority, the private key must be securely transmitted to the pair owner. If the owner will generate the key pair, the public key may need to be transmitted to the central authority in a secure manner. NOTE: If the key pairs are to be generated by a central authority, the ability for the private key to be used for authentication may be called into question since the central authority will have also seen that key. Care must be taken when creating and distributing private keys. Key Certification If keys are transmitted to a remote destination by some means, they must be checked once they arrive to be sure that they have not been tampered with during transit. This can be a manual process or it can be done via some type of digital signature. Public keys are intended to be published or given out to other users and must also be certified as belonging to the owner of the key pair. This can be done through a central au - thority (normally called a certificate authority, or CA). In this case, the CA provides a dig - ital signature on the public key and this certifies that the CA believes the public key belongs to the owner of the key pair (see Figure 12-12). Without proper certification, an attacker could introduce her own keys into the sys - tem and thus compromise the security of all information transmitted or authenticated. Key Protection The public keys of a public key pair do not require confidentiality protection. They only require the integrity protection provided by their certification. The private key of a public key pair must be protected at all times. If an attacker were to gain a copy of the private key, he could read all confidential traffic addressed to the key pair owner and also digi - tally sign information as if he was the key pair owner. The protection of the private key includes all copies of it. Therefore, the file that holds the key must be protected as does any backup tape that may include the file. Most systems protect the private key with a password. This will protect the key from casual snooping but not from a concerted attack. The password used to protect the key must be well chosen to resist brute-force attacks. However, the best way to protect the key is to prevent an attacker from gaining access to the file in the first place. All keys to a private key system must be protected. If the key is kept in a file, this file must be protected wherever it may reside (including backup tapes). If the key will reside in memory, care must be taken to protect the memory space from examination by a user or process. Likewise, in the case of a core dump, the core file must be protected since it may include the key. Chapter 12: Encryption 229 Figure 12-12. Public keys are certified by certificate authorities Key Revocation Keys do not have infinite lives. Session keys may only exist for a given session. There may not be any need to revoke the key as it is deleted at the end of the session. Some keys may be certified for a given period of time. Generally speaking, public keys pairs are certified for one or two years. The certified public key will identify the expiration date. Systems that read the certificate will not consider it valid after that date so there is little need to revoke an ex - pired certificate. However, keys can also be lost or compromised. When this occurs, the owner of the key must inform other users of the fact that the key is no longer valid and thus it should not be used. In the case of a private key encryption system, if a key is compromised (and if the users of the system know it) they can communicate this information to each other and begin using a new key. The case of public key encryption systems is a little different. If a key pair is compro - mised and revoked, there is no obvious way to inform all of the potential users of the pub - lic key that it is no longer valid. In some cases, public keys are published to key servers. Someone wishing to communicate with the owner of the key may go to the server once to retrieve the certified public key. If the key is compromised and revoked, how does an- other person find out? The answer is that they must periodically visit the key server to see if there is a revocation of the key and the owner of the key must post the revocation to all of the potential key servers. The key servers must also hold this revocation information at least until the original certificate would have expired. TRUST The concept of trust is the underlying concept of all security and encryption in particular. For encryption to work, you must trust that the key is not compromised and that the algo - rithm used is a strong one. For authentication and digital signatures, you must also trust that the public key actually belongs to the person using it. Perhaps the biggest problem with trust is how to establish and maintain it. Two pri - mary models have been used for trust in a public key environment: hierarchy and web. Both have their uses and both have problems. Hierarchy The hierarchy trust model is the easiest to understand. Simply stated, you trust someone be - cause someone else higher up in the chain says that you should. Figure 12-13 shows this model more clearly. As you can see from the figure, User1 and User2 both reside under CA1. Therefore, if CA1 says that a public key certificate belongs to User1, User2 will trust that this is so. In practice, User2 will send User1 his public key certificate that is signed by CA1. User1 will verify the signature of CA1 using CA1’s public key. Since CA1 is above User1, User1 trusts CA1 and thus trusts User2’s certificate. 230 Network Security: A Beginner’s Guide TEAMFLY Team-Fly ® That was a simple case. If User1 wants to verify information from User3, it becomes more difficult. CA1 does not know of User3 but CA2 does. However, User1 does not trust CA2 since it is not directly in the chain from User1. The next level up is CA4. User1 can verify information from User3 by checking with CA4 like this: 1. User1 looks at User3’s certificate. It is signed by CA2. 2. User1 retrieves CA2’s certificate. It is signed by CA4. 3. Since User1 trusts CA4, CA4’s public key can be used to verify CA2’s certificate. 4. Once CA2’s certificate is verified, User1 can verify User3’s certificate. 5. Once User3’s certificate is verified, User1 can use User3’s public key to verify the information. It gets pretty complicated pretty quick. Think about the amount of verification that would be necessary if User1 wanted to verify information that came from User4. The two chains do not intersect until CA9! This was the way the certificates in X.509 were intended to work. A hierarchy was to be established so that a chain of certificates could be created between any two bottom entities. Chapter 12: Encryption 231 Figure 12-13. The hierarchy trust model In theory this looks good. In practice, it has not happened. One reason it does not work is that there are no real root-level CAs. A root-level CA is the highest point in the hi - erarchy. At one time it was thought that each country would have a root-level CA. It was also envisioned that credit card companies would become root-level CAs or that each or - ganization would have its own CA. Few if any of these have appeared. Another question that became a potential problem is how many CAs would certify each end user. If the end user lives in country A, held a credit card from company B, and worked for organization C, would all three provide certificates? Or would all three sign the same certificate? Setting Up a CA Some organizations feel that establishing an internal CA (and associated public key infra - structure) is important for their business model. If this is the case, there are several issues that must be settled before a proper CA can be established: ▼ The CA public key pair must be created. The key must be large enough to be safe for a long period of time (generally longer than two years). ■ The CA public key must be certified by the CA itself and possibly by some other, higher-level CA. If an outside organization is to provide the CA certificate, this will cost money. ■ The CA private key must be protected for the entire life of the key. If it is ever compromised, the entire infrastructure may have to be rebuilt. ■ Appropriate policies and procedures must be created for the authentication and signing of lower-level certificates. ▲ A mechanism must be established to allow lower-level entities to verify each other’s certificates. At the least, this means that the CA’s certificate must be available to each lower-level entity. In some cases, this may mean direct interaction with the CA. This type of design will require the CA to be available all of the time or it becomes a single point of failure for the system. As you can see from this list, the design of the CA provides a number of challenges. If the organization is large or if the number of lower-level entities (users) will be large, the administration of the user certificates will not be a small task. The identity of each user will have to be verified before a certificate is signed. Certificates will expire periodically and new ones will need to be issued. Some certificates will need to be revoked as well. Revocation of Certificates The revocation of certificates may be the hardest part of a big problem for CAs. As was mentioned before, the notice of a key revocation must be made available to each entity that may use a certificate. This notice must also be timely. Since the nature of the public key system does not allow the CA to know everyone who might be using a given certifi - cate, the CA must rely on those who will be using the certificate to verify that it has not been revoked. This will require each entity to check with the CA before using a certificate. 232 Network Security: A Beginner’s Guide If there is only one CA for an organization, this is not a big problem, but it does force the CA to be available all the time. If the CA hierarchy is large (like that in Figure 12-13), the problem is compounded. User1 may tell CA1 that its certificate is revoked and CA1 may post that information, but how does this information get to User4 off CA6? Web A web of trust is an alternative trust model. This concept was first used by PGP. The con - cept is that each user certifies his or her own certificate and passes that certificate off to known associates. These associates may choose to sign the other user’s certificate because they know that other user (see Figure 12-14). In this model, there is no central authority. If User1 needs to verify information from User2, he asks for User2’s certificate. Since User1 knows User2, he trusts the certificate and may even sign it. Now User1 receives information from User3. User3 is unknown to User1 but User3 has a certificate that is signed by User2. User1 trusts User2 and thus trusts the certificate from User3. In this manner, the web reaches out across the network. The only decision that must be made is how many jumps the user is willing to trust. A reasonable number is probably three or four. You may also find that you have two paths to trusting another user. For example, User2 has two trust paths to get to User5: one through User3 and the other through User4. Since both User3 and User4 certify User5, User2 may feel more con- fident about User5’s certificate. Chapter 12: Encryption 233 Figure 12-14. The web of trust model The primary problem with the web is the lack of scalability. Since the web is made up of peer-to-peer relationships, each user must have some number of peer relationships to have any trust in the web. In practice, the issue may not exist because most users do business with a small number of peers and will only occasionally go three or four jumps. A big advantage of the web model is that there is no large investment in infrastruc - ture. Each user is responsible for their own certificate and the verification of others. An organization may choose to provide a central repository for certificates and revocation notices but this may not be necessary. 234 Network Security: A Beginner’s Guide . may work if the remote sites are short distances apart. But what if the remote sites are continents away? The problem gets much harder. There is a partial solution to this problem, however. It may. expired. TRUST The concept of trust is the underlying concept of all security and encryption in particular. For encryption to work, you must trust that the key is not compromised and that the. be revoked as well. Revocation of Certificates The revocation of certificates may be the hardest part of a big problem for CAs. As was mentioned before, the notice of a key revocation must be made