Криптография 2е издание Протоколы, алгоритмы и исходные тексты на языке С
 Скачать 3.25 Mb.
|
|
End-to-End Encryption Another approach is to put encryption equipment between the network layer and the transport layer. The encryption device must understand the data according to the protocols up to layer three and encrypt only the transport data units, which are then r e- combined with the unencrypted routing information and sent to lower layers for transmission. This approach avoids the encryption/decryption problem at the physical layer. By providing end-to-end encryption, the data remains encrypted until it reaches its final destination (see Figure 10.2). The primary problem with end-to-end encryption is that the routing information for the data is not encrypted; a good cryptanalyst can learn much from who is talking to whom, at what times and for how long, without ever knowing the contents of those conversations. Key management is also more difficult, since individual users must make sure they have common keys. Building end-to-end encryption equipment is difficult. Each particular communications system has its own protocols. Som e- times the interfaces between the levels are not well-defined, making the task even more difficult. If encryption takes place at a high layer of the communications architecture, like the applications layer or the presentation layer, then it can be independent of the type of communication network used. It is still end-to-end encryption, but the encryption implementation does not have to bother about line codes, synchronization between modems, physical interfaces, and so forth. In the early days of electro- mechanical cryptography, encryption and decryption took place entirely offline; this is only one step r e- moved from that. Encryption at these high layers interacts with the user software. This software is different for different computer archite c- tures, and so the encryption must be optimized for different computer systems. Encryption can occur in the software itself or in specialized hardware. In the latter case, the computer will send the data to the specialized hardware for encryption before sending it to lower layers of the communication architecture for transmission. This process requires some intelligence and is not suitable for dumb terminals. Additionally, there may be compatibility problems with different types of computers. The major disadvantage of end-to-end encryption is that it allows traffic analysis. Traffic analysis is the analysis of encrypted messages: where they come from, where they go to, how long they are, when they are sent, how frequent or infrequent they are, whether they coincide with outside events like meetings, and more. A lot of good information is buried in that data, and a cryptanalyst will want to get his hands on it. Table 10.3 presents the positive and negative aspects of end-to-end encryption. Combining the Two Table 10.4, primarily from [1244], compares link-by-link and end-to-end encryption. Combining the two, while most expe n- sive, is the most effective way of securing a network. Encryption of each physical link makes any analysis of the routing inform a- tion impossible, while end-to-end encryption reduces the threat of unencrypted data at the various nodes in the network. Key ma n- agement for the two schemes can be completely separate: The network managers can take care of encryption at the physical level, while the individual users have responsibility for end-to-end encryption. 10.4 ENCRYPTING DATA FOR STORAGE Encrypting data for storage and later retrieval can also be thought of in the Alice and Bob model. Alice is still sending a me s- sage to Bob, but in this case "Bob" is Alice at some future time. However, the problem is fundamentally different. In communic a- tions channels, messages in transit have no intrinsic value. If Bob doesn't receive a particular message, Alice can always resend it. This is not true for data encrypted for storage. If Alice can't decrypt her message, she can't go back in time and re-encrypt it. She has lost it forever. This means that encryption applications for data storage should have some mechanisms to prevent unrecove r- able errors from creeping into the ciphertext. The encryption key has the same value as the message, only it is smaller. In effect, cryptography converts large secrets into smaller ones. Being smaller, they can be easily lost. Key management procedures should assume that the same keys will be used again and again, and that data may sit on a disk for years before being decrypted. Fu r- thermore, the keys will be around for a long time. A key used on a communications link should, ideally, exist only for the length of the communication. A key used for data storage might be needed for years, and hence must be stored securely for years. Other problems particular to encrypting computer data for storage were listed in [357]: - The data may also exist in plaintext form, either on another disk, in another computer, or on paper. There is much more opportunity for a cryptanalyst to perform a known-plaintext attack. - In database applications, pieces of data may be smaller than the block size of most algorithms. This will cause the ciphe r- text to be considerably larger than the plaintext. - The speed of I/O devices demands fast encryption and decryption, and will probably require encryption hardware. In some applications, special high-speed algorithms may be required. - Safe, long-term storage for keys is required. - Key management is much more complicated, since different people need access to different files, different portions of the same file, and so forth. If the encrypted files are not structured as records and fields, such as text files, retrieval is easier: The entire file is decrypted before use. If the encrypted files are database files, this solution is problematic. Decrypting the entire dat a- base to access a single record is inefficient, but encrypting records independently might be susceptible to a block-replay kind of attack. In addition, you must make sure the unencrypted file is erased after encryption (see Section 10.9). For further details and insights, consult [425,569]. Dereferencing Keys When encrypting a large hard drive, you have two options. You can encrypt all the data using a single key. This gives a cryptanalyst a large amount of ciphertext to analyze and makes it impossible to allow multiple users to see only parts of the drive. Or, you can encrypt each file with a different key, forcing users to memorize a different key for each file. The solution is to encrypt each file with a separate key, and to encrypt the keys with another key known by the users. Each user only has to remember that one key. Different users can have different subsets of the file-encryption keys encrypted with their key. And there can even be a master key under which every file-encryption key is encrypted. This is even more secure because the file-encryption keys are random and less susceptible to a dictionary attack. Driver-Level vs. File-Level Encryption There are two ways to encrypt a hard drive: at the file level and at the driver level. Encryption at the file level means that every file is encrypted separately. To use a file that's been encrypted, you must first decrypt the file, then use it, and then re- e n- crypt it. Driver-level encryption maintains a logical drive on the user's machine that has all data on it encrypted. If done well, this can provide security that, beyond choosing good passwords, requires little worry on the part of the user. The driver must be consider a- bly more complex than a simple file-encryption program, however, because it must deal with the issues of being an installed d e- vice driver, allocation of new sectors to files, recycling of old sectors from files, random-access read and update requests for any data on the logical disk, and so on. Typically, the driver prompts the user for a password before starting up. This is used to generate the master decryption key, which may then be used to decrypt actual decryption keys used on different data. Providing Random Access to an Encrypted Drive Most systems expect to be able to access individual disk sectors randomly. This adds some complication for using many stream ciphers and block ciphers in any chaining mode. Several solutions are possible. Use the sector address to generate a unique IV for each sector being encrypted or decrypted. The drawback is that each se c- tor will always be encrypted with the same IV. Make sure this is not a security problem. For the master key, generate a pseudo-random block as large as one sector. You can do this by running an algorithm in OFB mode, for example.) To encrypt any sec- tor, first XOR in this pseudo-random block, then encrypt normally with a block cipher in ECB mode. This is called ECB+OFB (see Section 15.4). Since CBC and CFB are error-recovering modes, you can use all but the first block or two in the sector to generate the IV for that sector. For example, the IV for sector 3001 may be the hash of the all but the first 128 bits of the sector's data. After genera t- ing the IV, encrypt normally in CBC mode. To decrypt the sector, you use the second 64-bit block of the sector as an IV, and d e- crypt the remainder of the sector. Then, using the decrypted data, you regenerate the IV and decrypt the first 128 bits. You can use a block cipher with a large enough block size that it can encrypt the whole sector at once. Crab See Section 14.6) is an example. 10.5 HARDWARE ENCRYPTION VERSUS SOFTWARE ENCRYPTION Hardware Until very recently, all encryption products were in the form of specialized hardware. These encryption/decryption boxes plugged into a communications line and encrypted all the data going across that line. Although software encryption is becoming more prevalent today, hardware is still the embodiment of choice for military and serious commercial applications. The NSA, for example, only authorizes encryption in hardware. There are several reasons why this is so. The first is speed. As we will see in Part III, encryption algorithms consist of many complicated operations on plaintext bits. These are not the sorts of operations that are built into your run-of-the-mill computer. The two most common encryption alg o- rithms, DES and RSA, run inefficiently on general-purpose processors. While some cryptographers have tried to make their alg o- rithms more suitable for software implementation, specialized hardware will always win a speed race. Additionally, encryption is often a computation-intensive task. Tying up the computer's primary processor for this is ineff i- cient. Moving encryption to another chip, even if that chip is just another processor, makes the whole system faster. The second reason is security. An encryption algorithm running on a generalized computer has no physical protection. Mallory can go in with various debugging tools and surreptitiously modify the algorithm without anyone ever realizing it. Hardware encryption devices can be securely encapsulated to prevent this. Tamper- proof boxes can prevent someone from modifying a hardware encryption device. Special-purpose VLSI chips can be coated with a chemical such that any attempt to access their interior will result in the destruction of the chip's logic. The U.S. government's Clipper and Capstone chips See Sections 24.16 and 24.171 are designed to be tamperproof. The chips can be designed so that it is impossible for Mallory to read the unencrypted key. IBM developed a cryptographic system for encrypting data and communications on mainframe computers [515,1027]. It i n- cludes tamper-resistant modules to hold keys. This system is discussed in Section 24.1. Electromagnetic radiation can sometimes reveal what is going on inside a piece of electronic equipment. Dedicated encry p- tion boxes can be shielded, so that they leak no compromising information. General-purpose computers can be shielded as well, but it is a far more complex problem. The U.S. military calls this TEMPEST; it's a subject well beyond the scope of this book. The final reason for the prevalence of hardware is the ease of installation. Most encryption applications don't involve ge n- eral-purpose computers. People may wish to encrypt their telephone conversations, facsimile transmissions, or data links. It is cheaper to put special-purpose encryption hardware in the telephones, facsimile machines, and modems than it is to put in a m i- croprocessor and software. Even when the encrypted data comes from a computer, it is easier to install a dedicated hardware encryption device than it is to modify the computer's system software. Encryption should be invisible; it should not hamper the user. The only way to do this in software is to write encryption deep into the operating system. This isn't easy. On the other hand, even a computer neophyte can plug an encryption box between his computer and his external modem. The three basic kinds of encryption hardware on the market today are: self-contained encryption modules (that perform functions such as password verification and key management for banks), dedicated encryption boxes for communications links, and boards that plug into personal computers. Some encryption boxes are designed for certain types of communications links, such as T-1 encryption boxes that are d e- signed not to encrypt synchronization bits. There are different boxes for synchronous and asynchronous communications lines. Newer boxes tend to accept higher bit rates and are more versatile. Even so, many of these devices have some incompatibilities. Buyers should be aware of this and be well-versed in their pa r- ticular needs, lest they find themselves the owners of encryption equipment unable to perform the task at hand. Pay attention to restrictions in hardware type, operating system, applications software, net- work, and so forth. PC-board encryptors usually e n- crypt everything written to the hard disk and can be configured to encrypt everything sent to the floppy disk and serial port as well. These boards are not shielded against electromagnetic radiation or physical interference, since there would be no benefit in pr o- tecting the boards if the computer remained unaffected. More companies are starting to put encryption hardware into their co m- munications equipment. Secure telephones, facsimile machines, and modems are all available. Internal key management for these devices is generally secure, although there are as many different schemes as there are equipment vendors. Some schemes are more suited for one situation than another, and buyers should know what kind of key management is incorporated into the encryption box and what they are expected to provide themselves. Software Any encryption algorithm can be implemented in software. The disadvantages are in speed, cost, and ease of modification (or manipulation). The advantages are in flexibility and portability, ease of use, and ease of upgrade. The algorithms written in C at the end of this book can be implemented, with little modification, on any computer. They can be inexpensively copied and i n- stalled on many machines. They can be incorporated into larger applications, such as communications programs or word proce s- sors. Software encryption programs are popular and are available for all major operating systems. These are meant to protect i n- dividual files; the user generally has to manually encrypt and decrypt specific files. It is important that the key management scheme be secure: The keys should not be stored on disk anywhere (or even written to a place in memory from where the processor swaps out to disk). Keys and unencrypted files should be erased after encryption. Many programs are sloppy in this regard, and a user has to choose carefully. Of course, Mallory can always replace the software encryption algorithm with something lousy. But for most users, that isn't a problem. If Mallory can break into our office and modify our encryption program, he can also put a hidden camera on the wall, a wiretap on the telephone, and a TEMPEST detector down the street. If Mallory is that much more powerful than the user, the user has lost the game before it starts. 10.6 COMPRESSION, ENCODING, AND ENCRYPTION Using a data compression algorithm together with an encryption algorithm makes sense for two reasons: Cryptanalysis relies on exploiting redundancies in the plaintext; com- pressing a file before encryption reduces these redu n- dancies. Encryption is time-consuming; compressing a file before encryption speeds up the entire process. The important thing to remember is to compress before encryption. If the encryption algorithm is any good, the ciphertext will not be compressible; it will look like random data. (This makes a reasonable test of an encryption algorithm; if the cipher- text can be compressed, then the algorithm probably isn't very good.) If you are going to add any type of transmission encoding or error detection and recovery, remember to add that after encry p- tion. If there is noise in the communications path, decryption's error-extension properties will only make that noise worse. Figure 10.3 summarizes these steps. 10.7 DETECTING ENCRYPTION How does Eve detect an encrypted file? Eve is in the spy business, so this is an important question. Imagine that she's eave s- dropping on a network where messages are flying in all directions at high speeds; she has to pick out the interesting ones. E n- crypted files are certainly interesting, but how does she know they are encrypted? Generally, she relies on the fact that most popular encryption programs have well-defined headers. Electronic-mail messages encrypted with either PEM or POP (see Sections 24.10 and 24.12) are easy to identify for that reason. Other file encryptors just produce a ciphertext file of seemingly random bits. How can she distinguish it from any other file of seemingly random bits? There is no sure way, but Eve can try a number of things: - Examine the file. ASCII text is easy to spot. Other file formats, such as TIFF, TeX, C, Postscript, G3 facsimile, or Micr o- soft Excel, have standard identifying characteristics. Executable code is detectable, as well. UNIX files often have "magic nu m- bers" that can be detected. |