TOPICS IN THE ENGINEERING OF COMPUTER SYSTEMS CHAPTER 6 PROTECTION OF INFORMATION IN COMPUTER SYSTEMS JANUARY 2002 TABLE OF CONTENTS Table of Contents 6–1 Overview 6–5 Glossary 6–7 A. Introduction to secure systems 6–13 1. Attack classification 6–14 2. Protection is a negative goal 6–15 3. Design principles 6–18 4. Protection model 6–21 5. Trusted computing base 6–23 B. Cryptography as a building block for secure systems 6–25 1. Model for ciphers 6–26 2. Cryptography 6–29 3. Unbreakable cipher (one-time pad) and random generators 6–30 4. Pseudo-random number generators 6–32 5. A short-key shared-secret cipher: Data Encryption Standard (DES) 6–32 6. A public-key cipher: Rivest, Shamir, and Adleman (RSA) 6–35 7. Cryptographic hash functions 6–36 C. Authentication 6–39 1. Authentication of claimed identity 6–40 2. Message authentication 6–43 3. Message authentication terminology 6–43 4. Authentication is different from confidentiality 6–44 5. Authentication model 6–45 6. Properties of sign and verify 6–47 7. Computing a MAC 6–48 8. Computing a digital signature 6–49 © 1999–2002 by M. Frans Kaashoek and Jerome H. Saltzer 6–2 Protection of Information in Computer Systems 9. Key distribution 6–49 D. Authorization 6–51 1. Thesimpleguardmodel 6–51 2. Example: dynamics of use in a multi-user time-sharing system 6–54 3. The caretaker model 6–57 4. Non-discretionary access control with the flow-control model 6–58 E. Confidentiality 6–63 1. Using virtual memory to provide confidentiality within a shared system 6–63 2. Sealing primitives: communicating privately over untrusted networks 6–67 3. A shared-secret sealing system 6–69 4. A public-key sealing system 6–70 5. Achieving both confidentiality and authentication 6–71 F. Cryptographic protocols 6–75 1. Example: key distribution 6–75 2. Designing cryptographic protocols 6–79 3. An incorrect key distribution protocol 6–81 4. A key distribution protocol using a public-key system 6–84 5. Example: the secure socket layer (SSL) protocol 6–85 G. Advanced authentication 6–91 1. Reasoning about authentication protocols 6–92 2. Authentication in distributed systems 6–95 3. Authentication across administrative realms 6–97 4. Authenticating public keys 6–99 5. Authenticating certificates 6–100 6. Certificate chains 6–103 7. Example: server authentication with SSL 6–104 Acknowledgements 6–106 Appendix 6–A. War Stories: Protection System Failures 6–107 1. Residues: profitable garbage 6–107 2. A weak design causes two failures 6–110 3. The multiply–buggy password transformation 6–111 4. Controlling the configuration 6–112 5. The kernel trusts the user 6–113 6. An attack on our system would be too expensive 6–114 7. Meremortalsmustbeabletofigureouthowtouseit 6–115 8. The Web can be a dangerous place 6–115 9. The re–used password. 6–116 Draft Version of January 27, 2002 3:27 pm Table of Contents 6–3 10. Signalling with clandestine channels 6–117 11. Itseemstobeworkingjustfine 6–118 12. The incomplete check of parameters 6–121 13. Spoofing the operator 6–121 14. The special case that failed. 6–121 15. A thorough system penetration job. 6–122 16. Framing Enigma 6–122 Index of concepts 6–125 Last page 6–125 Draft Version of January 27, 2002 3:27 pm 6–4 Protection of Information in Computer Systems Draft Version of January 27, 2002 3:27 pm 6–5 CHAPTER 6Protection of Information in Computer Systems Overview Secure computer systems ensure that users’ privacy and possessions are protected. Security is a broad topic, ranging from issues such as not allowing your friend to read your files to protecting to a nation’s infrastructure against terrorist attacks. Defending against an intentionally malicious user is a negative goal. The designer of a computer system has to assure that there is no way in which the attacker can breach the security of the system. The designer must develop good security mechanisms and must ensure that an attacker cannot side step these security mechanism. For example, often the simplest way for an attacker to steal confidential information is to bribe someone on the inside who can provide the information. Because security is a negative goal, it requires a different design approach from the one we have seen in the previous chapters. We will introduce the safety net approach, which has two guidelines: 1. Consider everything that possibly could go wrong. An attacker has to find only one hole in the security of the system to achieve his objective. The designer must therefore consider any attack that has security implications; these attacks include snooping on private conversations, exploiting programming mistakes in the software, breaking locks, guessing passwords, bribing a guard, reconstructing information from the radiation of electronic circuits, abusing the maintenance procedures to change the system, inspecting the trash for useful information, etc. These attacks might be launched either from the outside or from the inside, for example, by an employee who may even have permission to use the system. 2. Assume you will make errors. Because the designer must plan for everything that might go wrong, he must also assume he will make errors. Furthermore, because an attacker has no incentive to report errors, the designer must have a plan for detecting errors quickly, repairing them, and avoiding repeating the same mistake. Such a plan includes designing for feedback to find errors quickly, designing for iteration to repair errors quickly, designing multiple layers of defense so that one error won’t break the security of the system, certifying the system to ensure that the design meets the specification and the implementation meets the design, and designing audits and checklists so that previous mistakes aren’t repeated. The conceptual model for protecting computer systems against attackers is based on the client-server model, in which a client module, on behalf of some user, sends a request to a server. To achieve security, the server has to answer the following three questions before performing the requested operation: 1. Who is the user making the request? Draft Version of January 27, 2002 3:26 pm 6–6 Protection of Information in Computer Systems 2. Is the request actually the one that the user made? 3. Is the user permitted to make such a request? The server should answer all of these questions for every request. To protect against inside attacks (users that have the appropriate permissions, but abuse them) or attackers that successfully break the security mechanisms, the server should also maintain audits of who used the system, what authorization decisions have been made, etc. This information can be used to determine who the attacker was after the attack and bring him to justice. In the end, a primary instrument to deter attackers is detection and punishment. Draft Version of January 27, 2002 3:26 pm Glossary 6–7 Glossary Access-control list (ACL)—A list of principals that are authorized to have access to some object. Active attack—An attack in which the intruder can create, delete, and manipulate messages destined for a principal (including substituting one message for another by replaying a message that was copied earlier). Appropriateness—A property of a message in cryptographic protocol: if the message is appropriate, then it is a member of this instance of this protocol (i.e., it is not copied from another instance of this protocol or from another protocol). Authentication—Verifying the identity of a principal or the authenticity of a message (its origin and integrity). Authentication keys—Cryptographic keys used for signing and verifying messages. Authentication tag—A cryptographically-computed string, associated with a message, that allows a receiver to verify the authenticity of the message. Authorization—Granting a principal permission to perform some operation, such as reading certain information. Block cipher—A class of ciphers in which a message is fragmented into fixed-size blocks, each of which is cryptographically transformed independently. Capability—In a computer system, an unforgeable ticket, which when presented is taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket. Cascading change propagation—A property of a cryptographic transformation: changing a single bit in the cleartext message causes changes in all subsequent cipher blocks of that message. Certificate—A message that certifies the binding of a principal identifier to a key. Certificate authority (CA)—A principal that signs certificates. Certify (v.)—To check the accuracy, correctness, and completeness of a security or protection mechanism. Cipher—A cryptographic transformation that transform their input in such a way that it is difficult to reconstruct the input from the output, unless one knows a secret. Cipher-block chaining (CBC)—In cipher-block chaining, the result of encrypting one block is one of the inputs to the encryption of the next block. CBC encryption exhibits cascading change propagation. Draft Version of January 27, 2002 3:26 pm 6–8 Protection of Information in Computer Systems Ciphertext—A message that has been transformed cryptographically. Compare with plaintext. Cleartext—Synonym for plaintext. Computationally secure—Security based on the hardness of computational problems. Most cryptography for confidentiality and authentication is based on problems that have such a large work factor that they require years of computing time (instead of being impossible to solve). Confidentiality—Limiting information access to authorized principals. Synomym for secrecy. Confidentiality keys—Cryptographic keys used to seal or unseal messages. Confinement—Allowing a (perhaps) untrusted program to have access to data, while ensuring that the program cannot release information. Covert channel—A hidden communication channel in flow-controlled access-control system.