L11a,b_ Principles of Info Security PDF

Principles of Information Security: Key Notes 1. Introduction to Information Security Computer system security is critical in today's connected world. Courses and degrees are dedicated to the topic, such as Georgia Tech’s Master’s in Information Security. Focus of this mod...

Principles of Information Security: Key Notes 1. Introduction to Information Security Computer system security is critical in today's connected world. Courses and degrees are dedicated to the topic, such as Georgia Tech’s Master’s in Information Security. Focus of this module: ○ Understanding key terminologies in computer security. ○ Learning cryptographic techniques for authentication in distributed systems. Saltzer's early insights highlighted foundational issues in information security, many of which remain relevant today (e.g., denial of service, firewalls, sandboxing). 2. Historical Context: Firsts in Computing Visionary Thinking (1963): Concepts like intergalactic computer networks. First Computer Communication (1969): Connection between UCLA and Stanford Research Institute on October 29, 1969, marked the beginning of computer networking. Invention of Email (1971): First email sent by Ray Tomlinson; initially intended as a useful communication tool. Internet Visualization (1977): A chart depicting all computers connected globally in March 1977. Computer Model (1975): ○ Mainframe with CPU, memory, and I/O devices. ○ Time-shared usage via cathode-ray terminals. ○ No network connections at the time. 3. Terminologies Defined by Saltzer (1975) Privacy vs. Security Privacy: ○ Individual-centric. ○ Governs when and how personal information is released. Security: ○ System-centric. ○ Ensures privacy and protects user data, releasing it only with user authorization. ○ Authentication ensures users are who they claim to be. Core Security Concerns  1. Unauthorized Information Release: ○ Prevents information leaks without the owner's consent. 2. Unauthorized Modification: ○ Ensures data is not altered without permission. 3. Unauthorized Denial of Use: ○ Known as Denial of Service (DoS). ○ Prevents disruption of service for authorized users. 4. Goal of a Secure System Negative Goal (Avoid Violations): ○ Preventing all violations (e.g., bugs, breaches) is challenging and often unrealistic. ○ Leads to a false sense of security. Positive Goal (Assurance): ○ Focus on ensuring robust, reliable safeguards without over-promising absolute security. ○ Acknowledge limitations and aim for practical, achievable protections. These principles form the foundation of modern system security and remain a cornerstone of secure operating system design. Four Levels of Protection in Computer Systems (Saltzer, 1975) 1. Unprotected Systems Definition: ○ No meaningful protection mechanisms are in place. Example: ○ Early MS-DOS: Included hooks for preventing user mistakes but lacked real security. Mistake prevention ≠ secure system. 2. Four Levels of Protection Level 1: All-or-Nothing Definition: ○ System provides a binary choice: complete access or no access at all. Example: ○ IBM's VM-370: Created the illusion of personal systems for each user (virtual machines).  Users could only interact via explicit I/O between virtual machines. Usage: ○ Common in 1960s and 1970s time-sharing systems. Level 2: Controlled Sharing Definition: ○ Provides selective sharing of resources based on access lists. Example: ○ Associating access lists with files: A file owner can specify who can access the file (e.g., a list of students). Level 3: User-Programmed Sharing Controls Definition: ○ System allows users to define sharing controls at different levels. Example: ○ UNIX file system: Assigns different access rights to files: Owner: Full access. Group: Restricted access. World: Minimal or no access. Flexible controls based on user-defined permissions. Level 4: User-Defined Strings Definition: ○ Data is tagged with labels to restrict access based on user privileges. Example: ○ Military-style classifications (e.g., "Top Secret"): Only specific users with appropriate clearance can access the data. ○ Digital analogs include tagging files with security levels. Cross-Cutting Issues in Protection Dynamic Adjustments: ○ Permissions and access controls must adapt over time. Challenges: ○ Changing access permissions:  Adding/removing users from access lists. Modifying group permissions for existing files. ○ Adapting to the evolving user base and system requirements. These levels highlight a progression from rudimentary to more sophisticated security mechanisms, emphasizing adaptability and user-defined controls for dynamic environments. Saltzer's Eight Design Principles for Secure Systems Introduction Saltzer identified eight design principles that complement the levels of protection previously discussed. These principles guide the design of secure systems to make them verifiable, robust, and user-friendly. Emphasize positive statements about what systems should do, rather than negative statements about what they should prevent. Principle 1: Economy of Mechanism Definition: ○ Security mechanisms should be simple and minimal. Explanation: ○ Simplicity allows for easier verification and validation. ○ A straightforward mechanism reduces the chance of errors and vulnerabilities. Principle 2: Fail-Safe Defaults Definition: ○ Default to denying access; explicit permission is required for access. Explanation: ○ Ensures that no access is granted unless explicitly allowed. ○ Protects against unintended access due to oversight or errors. Principle 3: Complete Mediation Definition: ○ Every access to a resource must be checked for authorization without exception.  Explanation: ○ Avoid shortcuts like caching authentication data that can lead to security lapses. Example: ○ Always verify user credentials against the most current data to prevent unauthorized access. Principle 4: Open Design Definition: ○ The system's security should not depend on secrecy of its design. Explanation: ○ Publish the design specifications but protect the cryptographic keys. ○ Open designs allow for public scrutiny and improvement. Key Idea: ○ Detection of violations is more practical than trying to prevent all possible attacks. Principle 5: Separation of Privilege Definition: ○ Access should require multiple conditions or credentials. Explanation: ○ Reduces risk by not relying on a single point of failure. Example: ○ Bank vaults requiring two keys from two different individuals to open. Principle 6: Least Privilege Definition: ○ Users and programs should operate using the least set of privileges necessary. Explanation: ○ Minimizes potential damage from accidents or malicious actions. Example: ○ Distinguishing between normal user privileges and administrative privileges. Application: ○ Firewalls enforce need-to-know access controls within organizations. Principle 7: Least Common Mechanism  Definition: ○ Minimize the amount of shared mechanisms used by different users. Explanation: ○ Reduces the risk that a flaw in one mechanism can compromise the entire system. Design Consideration: ○ Decide whether security mechanisms should reside in the kernel or in user-space libraries. ○ Placing mechanisms outside the kernel limits potential damage from malfunctions. Principle 8: Psychological Acceptability Definition: ○ Security mechanisms should be easy for users to understand and use. Explanation: ○ A good user interface ensures users are more likely to follow security protocols. Importance: ○ Complex or cumbersome security measures may lead users to circumvent them, undermining security. Key Takeaways 1. Positive Framing: ○ Design principles are stated positively, focusing on achievable security goals. ○ Avoid negative assertions like claiming the system is impervious to all violations. 2. Timeless Relevance: ○ These principles, formulated in the early 1970s, are still applicable to modern systems. ○ Anticipated security challenges before the advent of widespread computer networking. Two Main Conclusions Computational Infeasibility: ○ Design systems so that breaking security protections is computationally infeasible. ○ Rely on strong cryptographic methods and key protections. Detection Over Prevention:  ○ Focus on detecting security violations rather than attempting to prevent every possible attack. ○ Detection allows for response and mitigation, recognizing that prevention of all attacks is impractical. These principles emphasize building secure systems through simplicity, explicit permissions, thorough checks, openness, layered privileges, minimal sharing, user-friendly interfaces, and practical security goals. They underscore the importance of designing systems that are robust against attacks and adaptable to evolving security needs. 1-3 The Andrew File System (AFS) Case Study Introduction Background: ○ The Andrew File System was an experimental project developed in the Computer Science Department at Carnegie Mellon University (CMU) around 1988. ○ Aimed to enable students to access their personal files securely from any workstation on campus. ○ Assumed that the local area network (LAN) was untrusted, necessitating robust security measures. Objective: ○ Use AFS as a case study to understand how private key cryptographic infrastructure can secure and authenticate a distributed file system. State of Computing Circa 1988 Local Area Networks (LANs): ○ Connected client workstations and servers within the campus. ○ Networks were considered insecure, with potential for data interception. Workstations and Servers: ○ Client Workstations: Equipped with local disks serving as efficient caches for downloaded files. ○ Servers: Centralized storage of user files accessible over the LAN. User Experience: ○ Students could walk up to any workstation, log in, and access their personal files as if they were stored locally.  ○ The system aimed to make personal content "magically" appear upon login, enhancing mobility and accessibility. Legacy: ○ Early precursor to modern cloud computing and mobile device synchronization. ○ Influenced technologies that allow seamless access to personal content across devices today. AFS Architecture Components: ○ Client Workstations (Virtues): Run a variant of the Unix operating system. Host a special process called Venus. ○ Servers (Vice): Secure environment where user files are stored centrally. Servers communicate securely amongst themselves without encryption. ○ Network Links: Insecure links connecting virtues (clients) to vice (servers). Require encryption to secure data transmission. Terminology: ○ Virtue: The client environment (workstations). ○ Vice:  The server environment (central servers). Security Considerations: ○ Data transmitted over the insecure LAN must be encrypted to prevent eavesdropping. ○ Inside the vice (server environment), communication is secure and does not require encryption. Venus Process and Secure Communication Venus Process: ○ Runs on each client workstation (virtue). ○ Responsible for: Authenticating users when they log in to a workstation. Managing the caching of files locally on the workstation. Acting as a surrogate for the user when communicating with servers. Remote Procedure Calls (RPC): ○ Used by Venus to request files from vice servers. ○ Secure RPC: Due to the insecure network links, RPC communications must be encrypted. Ensures that both the parameters sent and results received are secure. Prevents unauthorized access and data interception during transmission. Authentication and Encryption:  ○ Private key cryptography is employed to: Authenticate users securely. Encrypt data transmitted between clients and servers. ○ Ensures that even if the network is compromised, data remains confidential. Functionality and User Experience Seamless Access: ○ Users log in to any workstation and immediately access their personal files. ○ Files are fetched securely from the central servers and cached locally for efficient access. Caching Mechanism: ○ Local caching reduces network load and improves performance. ○ Frequently accessed files are stored on the workstation's local disk. Mobility: ○ The system supports user mobility across campus. ○ Enhances productivity by allowing access from any location without manual file transfers. Impact and Legacy Influence on Modern Computing: ○ AFS demonstrated the feasibility of distributed file systems with secure authentication over insecure networks. ○ Pioneered concepts now fundamental to cloud storage and synchronization services. Successor Systems: ○ Coda File System: Also developed at CMU, building upon the principles of AFS. Further explored reliability and performance in distributed file systems. Technological Advancements: ○ Early adoption of private key cryptography in securing client-server communications. ○ Set the stage for subsequent developments in network security and distributed computing. Key Takeaways Security over Insecure Networks:  ○ Encrypting data transmission is essential when the underlying network cannot be trusted. ○ Private key cryptography provides a robust method for securing communications. User Authentication: ○ Processes like Venus are critical for verifying user identities and managing secure interactions with servers. Distributed File Systems: ○ Efficient caching and secure data retrieval enable seamless user experiences in distributed environments. Legacy of AFS: ○ The principles and architecture of AFS have had lasting impacts on how modern distributed systems are designed. ○ Concepts pioneered by AFS are integral to today's cloud computing infrastructure. This case study illustrates how the Andrew File System addressed the challenges of secure, distributed file access in an environment where the network could not be trusted, using private key cryptography and innovative system architecture. 4. Encryption Primer Overview There are two primary families of encryption systems used to secure data communication: 1. Private Key Cryptosystems (Symmetric Encryption) 2. Public Key Cryptosystems (Asymmetric Encryption) 1. Private Key Cryptosystems Definition: ○ Both the sender and the receiver use the same secret key for encryption and decryption. ○ The key must be kept confidential between the sender and receiver. Common Example: ○ Passwords: When logging into networks (corporate or university), the username and password mechanism relies on private key principles. How It Works: ○ Encryption:  The sender encrypts the data using the shared private key, producing ciphertext. ○ Transmission: The ciphertext is sent over insecure links; it can be intercepted but not understood without the key. ○ Decryption: The receiver uses the same private key to decrypt the ciphertext back into the original data. Security Principle: ○ Based on Saltzer's Principle: "Publish the design, but protect the key." The encryption method can be publicly known. Security relies on the secrecy of the key. Challenges: ○ Key Distribution Problem: Securely sharing and managing keys becomes complex as the number of users increases. Distributing private keys securely to all parties is difficult in large organizations. 2. Public Key Cryptosystems Definition: ○ Utilizes a pair of mathematically linked keys: a public key and a private key. ○ The public key is openly shared, while the private key is kept secret by the owner. How It Works: ○ Public Key: Available to anyone; can be published openly (e.g., like being listed in a directory). ○ Encryption: Sender: Encrypts the data using the receiver's public key. Produces ciphertext that cannot be decrypted with the public key. ○ Transmission: The ciphertext is sent over insecure networks. ○ Decryption: Receiver: Uses their private key to decrypt the ciphertext. Recovers the original data. Mathematical Basis: ○ Relies on One-Way Functions: Functions that are easy to compute in one direction (encryption) but hard to reverse without the private key (decryption). ○ Asymmetric Keys:  The public and private keys are related but not derivable from one another. Advantages: ○ Solves Key Distribution Problem: No need to securely share private keys with every sender. Only the receiver's public key is needed to encrypt messages to them. ○ Enhanced Security: Even if the public key is known, it is computationally infeasible to derive the private key. Key Concepts Ciphertext: 1. The encrypted version of the data, appearing as random or meaningless information to unauthorized parties. One-Way Functions: 1. Mathematical operations that are easy to perform but extremely difficult to reverse without specific knowledge (the private key). Encryption Workflow: Private Key Cryptosystem: 1. Sender: Encrypts data using the shared private key. 2. Transmission: Sends ciphertext over the network. 3. Receiver: Decrypts ciphertext using the same private key. Public Key Cryptosystem: 1. Sender: Encrypts data using the receiver's public key. 2. Transmission: Sends ciphertext over the network. 3. Receiver: Decrypts ciphertext using their private key. Comparison of Private and Public Key Systems Aspect Private Key Cryptosystems Public Key Cryptosystems Key Type Symmetric (same key for Asymmetric (public key for encryption, encryption/decryption) private key for decryption)  Key Complex (secure distribution Simplified (public key openly shared) Distribution needed) Speed Generally faster (less Generally slower (more computational overhead) computationally intensive) Security Secrecy of the private key Secrecy of the private key Dependence Scalability Less scalable due to key More scalable due to ease of public distribution issues key sharing Relevance to Saltzer's Principles Open Design with Protected Keys: ○ Encryption algorithms can be openly published and scrutinized. ○ Security relies on protecting the keys, not hiding the encryption method. Computational Infeasibility: ○ Breaking encryption without the appropriate key is designed to be computationally impractical. Key Takeaways Private Key Cryptosystems: ○ Suitable for environments where secure key exchange is manageable. ○ Key management becomes a challenge as the number of participants grows. Public Key Cryptosystems: ○ Addresses the key distribution problem by separating the encryption and decryption keys. ○ Facilitates secure communication in open networks where secure key exchange is not feasible. Overall Importance: ○ Understanding both systems is crucial for designing secure communication protocols. ○ Encryption is fundamental in protecting data integrity and confidentiality over insecure networks. These notes provide a concise summary of the key points regarding private and public key cryptosystems, highlighting their functions, advantages, challenges, and relation to fundamental security principles. 5. Private Key Encryption System in Action Overview In a private key cryptosystem, the same key is used for both encryption and decryption of messages. Two entities, A and B, must securely exchange keys in advance to communicate. Communication Workflow 1. Message from A to B: ○ A encrypts the message using a shared private key KA. ○ The encrypted message (ciphertext) is sent to B. ○ B decrypts the ciphertext using the same key KA. 2. Message from B to A: ○ B encrypts the message using a shared private key KB. ○ The encrypted message (ciphertext) is sent to A. ○ A decrypts the ciphertext using the same key KB. 3. Key Sharing: ○ KA and KB can be: The same key: A single shared key for both directions. Different keys: Separate keys for messages sent in each direction. Message Format Structure of Message from A to B: ○ Sender Identity (Cleartext): The sender's identity ("A") is sent in cleartext. B uses this information to identify which key to use for decryption (e.g., KA). ○ Ciphertext: The encrypted message. Reason for Cleartext Sender Identity: ○ Without the sender’s identity, the recipient cannot determine which key to use for decryption. ○ The identity allows the recipient to retrieve and use the correct private key. Key Takeaways 1. Symmetric Encryption: ○ The same key is used for both encrypting and decrypting a message. 2. Key Usage: ○ The correct key must be identified based on the sender’s identity. 3. Message Format: ○ The sender's identity is sent in cleartext to ensure the recipient can select the proper decryption key. 4. Key Exchange: ○ A secure mechanism is required to distribute and manage private keys between communicating parties. This workflow highlights the reliance on shared keys and clear sender identification to enable secure communication in private key cryptosystems. 6. Design Challenges and Solutions in the Andrew File System Challenges 1. User Authentication: ○ Verifying that the user logging into the system is indeed who they claim to be (e.g., "I am Kishore"). ○ The system must authenticate the user's identity unambiguously. 2. Server Authentication: ○ Ensuring that the server communicating with a user is the legitimate server.  ○ Preventing scenarios where a malicious entity pretends to be the server (e.g., Trojan horses). 3. Preventing Replay Attacks: ○ Even with encrypted communication, an attacker sniffing the network might capture packets and resend them. ○ The system must detect and prevent such replayed packets from fooling the sender or receiver. 4. User Isolation: ○ Protecting the user community from unintended or malicious interference with one another's data. ○ Ensuring that each user's data and actions are isolated from others. Proposed Solution: Secure RPC with Private Key Cryptosystem 1. Use of Secure RPC: ○ Secure RPC (Remote Procedure Call) is chosen as the basis for communication between clients (workstations) and servers. ○ Encrypts communication to ensure data confidentiality and integrity. 2. Private Key Cryptosystem: ○ Although public key cryptosystems solve the key distribution problem, the private key system was chosen due to: Closed nature of the campus environment. Manageable key distribution challenges in such a setup. ○ Keys are shared between clients and servers for encryption and decryption of messages. Implementation Considerations 1. Identity in Cleartext: ○ In a private key system, the sender's identity must be sent in cleartext. ○ This allows the receiver to determine the correct key to use for decryption. 2. Avoid Overusing Keys: ○ Overuse of a single key or username-password combination can lead to security vulnerabilities: Key Overexposure: Repeated use of the same key increases the chance of it being cracked over time. Protecting keys involves making them computationally hard to break and minimizing exposure. Username-Password Fatigue:  Excessive reliance on username and password for repeated authentication (e.g., in RPC communication) introduces a security hole. Design Dilemma: Key and Identity Management 1. Key Usage: ○ Avoid reusing the same key or identity-key pair for extended periods. ○ This reduces the likelihood of an attacker exploiting the key. 2. Identity Management: ○ Ensure that the identity sent in cleartext during communication does not expose critical information. ○ Balance usability with security by limiting the overuse of sensitive credentials. Key Takeaways Challenges Addressed: ○ Secure authentication of both users and servers. ○ Protection against replay attacks. ○ Isolation of user data and activities. Secure RPC and Private Keys: ○ Provide a strong foundation for secure client-server communication. ○ Chosen due to manageable key distribution in a campus environment. Avoid Overexposure: ○ Keys and sensitive credentials should not be overused to mitigate risks of cracking. ○ Implement strategies to rotate or securely manage keys for long-term security. This solution demonstrates how the Andrew File System tackled critical challenges in designing a secure distributed file system for a campus environment while adhering to Saltzer’s principles. 7. Solution for Client-Server Interactions in the Andrew File System Overview Objective: ○ Limit the use of username and password to the initial login session for authentication.  ○ For all subsequent interactions between Venus (client process) and Vice (server), use ephemeral IDs and keys to secure communication over insecure links. Reasoning: ○ Reduces overexposure of sensitive credentials (username and password). ○ Enhances security by using temporary (ephemeral) credentials for ongoing interactions. Three Classes of Client-Server Interactions 1. Login (Initial Authentication): ○ Action: The user logs in to a workstation using their username and password. ○ Purpose: Authenticate the user to the server. Securely establish the initial connection over an insecure link. ○ Frequency: Happens once per login session. 2. RPC Session Establishment: ○ Action: Venus (the client process) establishes an RPC session with Vice (the file server). ○ Purpose: Facilitate file requests or uploads during the session. Secure communication using ephemeral IDs and keys. ○ Frequency: May happen multiple times during a login session. Example: Fetching files for a course project or uploading completed work to the server. 3. File System Access During an RPC Session: ○ Action: The user requests access to specific files through Venus. Venus fetches the file from Vice and caches it locally on the workstation. Once the user is done, Venus commits changes back to Vice. ○ Purpose: Enable efficient, secure file access and modification. Ensure data integrity during file transfer using ephemeral credentials. ○ Frequency: Happens within established RPC sessions as needed. Key Points in the Workflow  1. Ephemeral IDs and Keys: ○ Used for all client-server interactions after the initial login. ○ Temporary credentials minimize the risk of long-term exposure. 2. Secure RPC: ○ Ensures encrypted communication between Venus and Vice. ○ Protects data integrity and confidentiality over insecure network links. 3. Login and Authentication: ○ Username and password are used only once during the session (login). ○ Prevents overuse, which could lead to security vulnerabilities. 4. Venus' Role: ○ Acts as a surrogate for the user. ○ Handles all file-related operations (fetching, caching, committing) during an RPC session. 5. File Access Flow: ○ User requests a file → Venus fetches the file using RPC → File is cached locally for use → Venus commits changes back to Vice upon closure. Summary of Interactions Interaction Type Action Frequency Authentication Mechanism Login Authenticate with username Once per Username and and password session password RPC Session Initiate RPC session for file Multiple Ephemeral IDs and Establishment requests or uploads times/session keys File System Open, modify, and close Multiple Ephemeral IDs and Access files during an RPC session times/session keys (via RPC) Key Takeaways Username and Password: ○ Used only for initial login to authenticate the user. ○ Prevents overexposure and enhances security. Ephemeral Credentials: ○ Secure communication for RPC sessions and file system access. ○ Limits the potential for long-term credential compromise. Efficient Workflow: ○ Allows secure and seamless file access and modifications within a distributed system. This design balances usability with robust security for a distributed campus file system. 8. Login Process Objective Provide a secure login mechanism and establish ephemeral credentials for future communication between Venus (client process) and Vice (server). Limit the exposure of sensitive credentials (username and password) during a user’s session. Login Process 1. User Action: ○ The user logs into a workstation using their username and password. 2. Communication with Login Server: ○ The login process on the Virtue workstation sends the username and password securely to the login server in Vice. ○ This communication occurs over an insecure link but is encrypted to ensure security. 3. Login Server Response: ○ The login server authenticates the user and generates two tokens: Secret Token: An encrypted bit string used as an ephemeral client ID. Clear Token: A structured data packet containing a Handshake Key (HKC). ○ Both tokens are securely transmitted back to the login process on Virtue. Tokens and Their Roles 1. Clear Token: ○ Content: Contains the Handshake Key (HKC), a key used for secure communication. ○ Encryption: The clear token is encrypted with a key known only to Vice. ○ Usage: The login process extracts the handshake key (HKC) from this token. HKC is used as the private key for future RPC session establishment. 2. Secret Token: ○ Content: An encrypted version of the clear token. ○ Encryption: Encrypted with a key known only to Vice. ○ Usage: Acts as an ephemeral client ID for the login session. Meaningless to anyone intercepting it on the network. How It Works 1. Secret Token as Ephemeral Client ID:  ○ Venus uses the secret token as the client ID in communications with Vice. ○ The secret token is a unique identifier for the session. 2. Vice Decoding the Secret Token: ○ Vice decrypts the secret token using its private key (known only to Vice). ○ From the decrypted secret token, Vice retrieves the corresponding clear token. ○ The clear token contains the handshake key (HKC), enabling Vice to identify and communicate securely with the client. 3. HKC Usage: ○ HKC serves as the private key for secure communication. ○ It is used to establish future RPC sessions between Venus and Vice during the login session. Post-Login Workflow 1. Token Storage: ○ Venus stores the secret and clear tokens for the duration of the login session. ○ These tokens represent the user for all communications during the session. 2. RPC Session Establishment: ○ Venus uses the secret token (client ID) and HKC (private key) to establish secure RPC sessions with Vice. ○ Each RPC session request is authenticated and encrypted using these ephemeral credentials. 3. Session Termination: ○ At the end of the login session: Venus discards the secret and clear tokens. This ensures that the credentials cannot be reused or compromised. Key Takeaways 1. Ephemeral Credentials: ○ The secret token serves as a unique client ID for the login session. ○ HKC is used for secure communication and RPC session establishment. 2. Security of Credentials: ○ Username and password are only used during the initial login. ○ The secret and clear tokens are temporary and discarded after the session, minimizing long-term risk. 3. Secure Communication: ○ All subsequent Venus-Vice communication leverages ephemeral credentials to ensure security over insecure links. 4. Bind Mechanism:  ○ Central to the secure RPC system, this mechanism ensures secure client-server connections by using the tokens and HKC. This token-based mechanism ensures secure, scalable, and efficient communication in the Andrew File System, addressing the challenges of authenticating users and protecting sensitive credentials. 9. Secure RPC Session Establishment in the Andrew File System 1. Overview of the Login Process User Login: ○ The user logs into a workstation using their username and password.  ○ The login process is handled by a special process running on the Virtue workstation. Communication with Login Server: ○ The login process communicates securely with the login server inside Vice (the server environment). ○ Username and password are presented securely over insecure network links. Tokens Received: ○ Upon successful authentication, the login server sends back two tokens: Secret Token Clear Token 2. Tokens and Their Roles Clear Token: ○ A data structure known to the login process. ○ Contains a Handshake Key for Client (HKC). ○ The login process extracts HKC from the clear token. Secret Token: ○ An encrypted version of the clear token. ○ Encrypted with a key known only to Vice (not the same as HKC). ○ Appears as a meaningless bit string to anyone intercepting it. ○ Used as an ephemeral client ID for the login session. Secure Transmission: ○ Both tokens are securely transmitted over insecure links. ○ The login process decrypts the message to obtain the tokens. 3. Using the Tokens for Future Communication Ephemeral Client ID: ○ The Secret Token is used as the client identity in future communications. ○ Prevents frequent exposure of the username and password. Vice's Handling of Secret Token: ○ Upon receiving the Secret Token, Vice decrypts it using its private key. ○ Decryption yields the Clear Token. ○ From the Clear Token, Vice retrieves the HKC. 4. Establishing a Secure RPC Session (Bind Operation) Initiation by Venus:  1. Venus (the client process on Virtue) wants to establish an RPC session with Vice. 2. Venus sends: Client Identity: The Secret Token (in clear text). Encrypted Cipher: A random number Xᵣ, encrypted using HKC. Message Flow: 1. Message from Venus to Vice: Content: Client ID: Secret Token. Encrypted message: Encrypt_HKC(Xᵣ) Purpose: Initiate RPC session establishment. 2. Vice's Processing: Decrypts Secret Token to get the Clear Token. Retrieves HKC from the Clear Token. Decrypts Encrypt_HKC(Xᵣ) to get Xᵣ. 3. Message from Vice to Venus: Content: Encrypted message: Encrypt_HKC(Xᵣ + 1, Yᵣ) Xᵣ + 1: Confirms to Venus that Vice received Xᵣ. Yᵣ: A new random number generated by Vice. Purpose: Authenticate Vice to Venus. Continue the handshake. 4. Venus's Processing: Decrypts the message using HKC. Verifies that the received number is Xᵣ + 1 (expected value). Extracts Yᵣ. 5. Message from Venus to Vice: Content: Encrypted message: Encrypt_HKC(Yᵣ + 1) Purpose: Authenticate Venus to Vice. 6. Vice's Final Processing: Decrypts the message using HKC. Verifies that the received number is Yᵣ + 1 (expected value). 5. Authentication and Prevention of Replay Attacks Authenticating the Server (Vice): ○ Venus expects to receive Xᵣ + 1 in the response. ○ Receipt of Xᵣ + 1 confirms that Vice is genuine (only Vice could produce Xᵣ + 1).  Authenticating the Client (Venus): ○ Vice expects to receive Yᵣ + 1 in the subsequent message. ○ Receipt of Yᵣ + 1 confirms that Venus is genuine (only Venus could produce Yᵣ + 1). Prevention of Replay Attacks: ○ Random numbers Xᵣ and Yᵣ are fresh for each session. ○ Incrementing the random numbers and verifying expected values ensure that replayed messages are detected. ○ An attacker replaying old messages would not have HKC to produce correct increments. 6. Summary of the Bind Operation Purpose: ○ Securely establish an RPC session between Venus and Vice. ○ Mutual authentication of client and server. ○ Protect against replay attacks. Key Components: ○ Secret Token: Acts as an ephemeral client ID; allows Vice to retrieve HKC. ○ Handshake Key (HKC): Used to encrypt and decrypt messages during the bind operation. ○ Random Numbers (Xᵣ and Yᵣ): Provide freshness to prevent replay attacks. Flow of Messages: ○ Venus to Vice: Client ID: Secret Token. Encrypted Xᵣ using HKC. ○ Vice to Venus: Encrypted Xᵣ + 1 and Yᵣ using HKC. ○ Venus to Vice: Encrypted Yᵣ + 1 using HKC. Outcomes: ○ Both parties have authenticated each other. ○ Secure RPC session is established. ○ Replay attacks are mitigated. 7. Key Takeaways Use of Ephemeral Credentials: ○ Reduces the risk of credential exposure. ○ Enhances security over insecure networks. Mutual Authentication:  ○ Both client and server authenticate each other using the shared handshake key and verification of expected values. Protection Against Replay Attacks: ○ Fresh random numbers and their increments prevent attackers from replaying old messages. Secure Session Establishment: ○ Ensures that subsequent communications are secure and authenticated. 8. Diagram of the Message Exchange mathematica Copy code [Venus (Client)] [Vice (Server)] 1. Sends: - Client ID: Secret Token - Encrypted Message: Encrypt_HKC(Xᵣ) ---> 2. Processes: - Decrypt Secret Token to get Clear Token - Retrieve HKC from Clear Token - Decrypt Encrypt_HKC(Xᵣ) to get Xᵣ 3. Sends: - Encrypted Message: Encrypt_HKC(Xᵣ + 1, Yᵣ)  6. Processes: - Decrypt message using HKC - Verify Yᵣ + 1 This detailed process ensures that both the client and the server can trust each other's identity and that the session is secure from potential replay attacks or impersonation attempts. o1 10. Continuing Secure RPC Sessions in the Andrew File System Avoiding Overexposure of Credentials Principle: ○ Do not overexpose any ID or password on insecure links. ○ Username and Password: Used only once during the initial login session. ○ Handshake Key (HKC): Used solely for establishing RPC sessions. Prevents overuse and potential compromise. Establishing Multiple RPC Sessions Within a Login Session: ○ Multiple RPC sessions can be established with the server. ○ Each RPC session requires: Using HKC to authenticate and establish the session. Generating a unique Session Key (SK) for that session. Session Key Generation and Distribution Server Actions: ○ After validating the client's identity, the server generates a new Session Key (SK) for the RPC session. ○ Encryption: The server encrypts SK using the handshake key (HKC). Sends the encrypted SK to the client over the insecure link. Client Actions (Venus): ○ Decrypts the received message using HKC to extract SK.  ○ Uses SK for all subsequent communication within that RPC session. Usage of the Session Key Purpose of SK: ○ Acts as the new handshake key for the duration of the RPC session. ○ Enhances security by limiting the exposure of HKC. File System Operations: ○ All operations (open, close, read, write files) use SK for encryption. ○ SK is unique to the session, reducing the risk if compromised. Sequence Numbers for Replay Attack Prevention Starting Sequence Number (num): ○ Provided by the server along with SK. ○ Venus uses num as the starting point for sequence numbers in RPC calls. Purpose: ○ Safeguards against replay attacks. ○ Ensures messages are processed in order and are unique. Recap of Session Establishment Process 1. Client Initiation: ○ Venus sends a message to the server requesting to establish a new RPC session. 2. Mutual Authentication: ○ Server Authenticates Client: Validates the client's request using HKC. Ensures the client is genuine. ○ Client Authenticates Server: Verifies the server's response. Ensures the server is genuine. 3. Session Key Exchange: ○ Server Generates SK and num: Encrypts them using HKC. Sends them to Venus. ○ Client Receives SK and num: Decrypts the message using HKC. Stores SK and num for the session. 4. Transition to Session Key: ○ Both client and server agree to use SK for all future communications in this RPC session. ○ HKC is no longer used for regular file system operations, minimizing its exposure. Key Points  Minimizing Credential Exposure: ○ Using SK for session-specific communication enhances security. ○ HKC is used only briefly, reducing the window for potential compromise. Enhanced Security Within RPC Sessions: ○ Unique SK per session prevents attackers from exploiting a single compromised key across sessions. ○ Sequence numbers add an additional layer of protection against replay attacks. Efficient Session Management: ○ Allows multiple secure RPC sessions within a single login session. ○ Facilitates secure and efficient file system operations without overburdening the authentication mechanism. This process ensures that each RPC session within a login session is secured with its own unique session key, thereby maintaining robust security while avoiding the overuse of sensitive credentials like the handshake key or the user's password. 12. Login as a Special Case of the General Bind Operation Overview Login Process: ○ The login operation in the Andrew File System is a specific instance of the general bind operation used to establish secure RPC sessions between the client and server. ○ It adapts the general mechanism by using the username and password directly in place of the client ID and handshake key. Key Points 1. Using Username and Password: ○ Username: Used as the client ID during the login process. ○ Password: Used as the initial Handshake Key for Client (HKC). Serves as the encryption key for secure communication during login. 2. Sequence of Operations: ○ Similar to General Bind Operation: The login process follows the same steps as the bind operation for mutual authentication and session establishment. Involves validating both the client to the server and the server to the client. 3. Token Exchange: ○ Server Response: After successful mutual authentication, the server sends back: Secret Token: An encrypted bit string acting as an ephemeral client ID for future sessions. Clear Token: A data structure containing the new handshake key (HKC) for subsequent RPC sessions. ○ Encryption of Tokens: Both tokens are encrypted using the password (initial HKC) to ensure secure transmission over insecure links.  4. Client Processing: ○ Decryption: The login process uses the password to decrypt the received message. Extracts the Secret Token and Clear Token. ○ Storage: Venus (the client process) stores these tokens for the duration of the login session. Tokens are used for future authentication and secure communication without reusing the password. 5. Establishing Future RPC Sessions: ○ Handshake Key from Clear Token: The Clear Token contains a new HKC, which is used for establishing subsequent RPC sessions securely. ○ Avoiding Password Overuse: By transitioning to a new HKC, the system avoids overexposing the user's password in future communications. Process Flow Summary 1. Client Initiates Login: ○ Sends username (client ID) to the server. ○ Uses password as HKC to encrypt any messages sent during this phase. 2. Mutual Authentication: ○ Server Validates Client: Verifies the username and password. ○ Client Validates Server: Through the exchange of encrypted messages, ensures the server is genuine. 3. Token Exchange: ○ Server Sends Encrypted Tokens: Secret Token and Clear Token are encrypted using the password (HKC). ○ Client Decrypts Tokens: Uses the password to decrypt and retrieve the tokens. 4. Post-Login Communication: ○ Use of New HKC: The handshake key from the Clear Token is used for future RPC session establishments. ○ Storage of Tokens: Tokens are retained by Venus for the login session's duration. ○ Enhanced Security: Subsequent communications do not require the password, reducing exposure risk. Benefits of This Approach Security Enhancement: ○ Minimizes the use of the password, protecting it from potential interception or overuse. ○ Ensures secure communication over insecure networks. Efficiency: ○ Simplifies future session establishments by using the stored tokens and new HKC. ○ Reduces the overhead of repeated authentication using the password. Consistency with General Mechanism: ○ Aligns the login process with the established bind operation, maintaining a uniform approach to session management. Key Takeaways The login process is effectively a specialized bind operation where: ○ Username = Client ID ○ Password = Initial HKC After the initial login and mutual authentication: ○ The Secret Token and Clear Token enable secure, efficient future communications. ○ The password is no longer used, enhancing security. This mechanism upholds the principles of: ○ Minimal Credential Exposure: Protects sensitive information by limiting its use. ○ Secure Communication: Employs encryption and tokens to maintain confidentiality and integrity. ○ Operational Efficiency: Facilitates smooth session management without compromising security. By understanding this process, we see how the Andrew File System effectively secures user authentication and subsequent communications, aligning with the overall design principles of minimizing credential exposure and using ephemeral keys for enhanced security. 13. Putting it All Together - The Andrew File System (AFS) Overview  Purpose of AFS: ○ Enable authorized users within a campus community to securely access files stored on central servers. ○ Allow users to log in from any workstation over insecure network links. Key Components: ○ Venus: The client-side process running on the user's workstation (Virtue). ○ Vice: The server-side environment where files are stored securely. Three Classes of Client-Server Interactions 1. Login Process ○ Action: User logs in using their username and password. ○ Communication: Venus communicates with Vice to authenticate the user. Vice returns two tokens: Secret Token: Used as an ephemeral client ID. Clear Token: Contains the Handshake Key for Client (HKC). ○ Security: Username and password are exposed only once per login session. Tokens are securely transmitted over insecure links. 2. RPC Session Establishment ○ Action: Venus establishes an RPC session with Vice using: Secret Token as the client ID. HKC as the encryption key. ○ Process: Mutual authentication occurs between Venus and Vice. Vice generates a unique Session Key (SK) for this RPC session. Vice sends SK to Venus, encrypted with HKC. ○ Security: HKC is used only for establishing new RPC sessions within the login session. Reduces exposure of HKC to potential attacks. 3. Secure RPC Calls for File System Operations ○ Action: User performs file operations (open, read, write, close). ○ Communication: Venus uses Secret Token as the client ID. Uses Session Key (SK) to encrypt messages to Vice. Vice responds using SK for encryption. ○ Security: SK is used for the duration of the specific RPC session.  Enhances security by limiting the lifespan of encryption keys. Key Security Practices in AFS Minimal Credential Exposure: ○ Username and Password: Used only once per login session to authenticate the user. Minimizes the risk of interception over insecure networks. ○ Handshake Key (HKC): Valid only for the duration of the login session. Used solely for establishing RPC sessions. ○ Session Key (SK): Unique per RPC session. Used for all file system operations within that session. Expires at the end of the RPC session. Ephemeral Credentials: ○ Tokens and keys are temporary and have limited validity. ○ Reduces the risk associated with long-term key exposure. Replay Attack Prevention: ○ Use of sequence numbers and random nonces in communication. ○ Ensures messages are fresh and cannot be reused maliciously. Lifecycle of Keys and Tokens 1. Login Session: ○ Secret Token and Clear Token: Stored by Venus for the duration of the login session. Discarded upon logout. ○ HKC: Valid throughout the login session. Used for establishing new RPC sessions as needed. 2. RPC Session: ○ Session Key (SK): Generated uniquely for each RPC session. Used for all secure communications during that session. Expires when the RPC session ends. Summary of the Lesson Module Saltzer's Taxonomies: ○ Explored fundamental principles and terminologies in information security. ○ Emphasized positive security design principles. Practical Application: ○ Demonstrated how AFS applies these principles to secure a distributed file system. ○ Showed the implementation of authentication, authorization, and secure communication. Key Takeaways: ○ AFS effectively balances usability and security for users in a campus environment. ○ Employs strategic use of ephemeral keys and tokens to protect user credentials. ○ Illustrates the importance of limiting credential exposure and using secure protocols. Reflection on AFS's Security Guarantees Strengths: ○ Robust authentication mechanisms prevent unauthorized access. ○ Use of temporary credentials minimizes the risk of key compromise. ○ Secure RPC sessions protect data integrity and confidentiality.  Potential Weaknesses: ○ Reliance on private key cryptography requires secure key distribution and management. ○ Inherent challenges in preventing all possible replay or man-in-the-middle attacks. ○ The need for users to trust the initial login process over insecure networks. Considerations: ○ Assess how AFS's design addresses Saltzer's design principles. ○ Evaluate the system's effectiveness in a modern context with evolving security threats. By understanding the Andrew File System's architecture and security mechanisms, we gain insights into designing secure distributed systems that protect user data while maintaining accessibility and efficiency.