CS 337 Project 2 Human-To-Host Simulator Instructor: Plaxton Judah - PDF document

CS 337 Project 2 Human-To-Host Simulator Instructor: Plaxton Judah De Paula Greg Plaxton Due March 8 (Monday) at 8:00pm 1 Overview Your task is to simulate a system in which a dynamic collection of humans access a dynamic collection of hosts. Initially, there are no humans or hosts in the system. The simulation processes a sequence of commands, including commands to create and destroy humans and hosts. Two of the commands (create-host and h2h-keygen) involve simulating the creation of an RSA key pair, consisting of a public key and a private key. We assume that the public key is encoded as a human-readable string (i.e., no control characters), followed by a newline. The significance of this assumption is that we can build up a set of public keys in a single file, one per line, by simply appending together various public keys. The simulation should assume that whenever a new RSA key pair is generated, it is different from any previously generated pair. Remark: This assignment is loosely based on ssh and its associated tools such as scp and ssh-agent. However, our h2h protocol attempts to model only a fragment of the capabilities of ssh, and even within this fragment, there are discrepancies between the behavior of ssh and h2h. Accordingly, the student should not rely on ssh documentation to clarify any of the project details. 2 Commands Before proceeding to define all of the commands to be processed by the simulator, we mention a few notational conventions. First, when we define a command, we indicate required arguments in square brackets and optional arguments in parentheses. Lowercase letters and the the colon and @ symbols simply represent the corresponding characters. An argument of the form “ { foo | bar } ” denotes either “foo” or “bar”. Throughout this section, the symbols A through H denote arbitrary nonempty strings of digits and lowercase letters. Such strings are used as labels for some of the simulated entities. Each command has an associated precondition. If this precondition is not satisfied, the com- mand is a no-op. In the case of a command such as h2h-connect that returns success or failure, the command is considered to fail whenever the precondition is not satisfied. The command create-host [A] { forwarding | noforwarding } precondition: host A is undefined 1

creates a new host A with “forwarding” enabled or disabled as indicated by the second argument. We will see the significance of the forwarding attribute later on. When a host is created it is assigned a new RSA key pair. Each host can have an arbitrary number of user accounts. When a host is created, it does not have any accounts. The command create-account [A @ B] [C] { forwarding | noforwarding } precondition: host B is defined and account A @ B is undefined creates account A @ B with password C and with forwarding configured as indicated. The simulation also models a set of humans who access various accounts. Initially, the set of humans is empty. The command create-human [A] precondition: human A is undefined creates human A. Initially, a human does not have any information regarding the passwords of any accounts or the passphrases of any private key files. The command password-belief [A] [B @ C] [D] precondition: human A is defined updates human A to believe that if account B @ C exists, then it has password D. The command password-prompt [A] [B @ C] precondition: human A and account B @ C are defined determines whether human A has a correct belief as to the current password for account B @ C. If so, the command succeeds. Otherwise, the command fails. Each user account can have an arbitrary number of associated shells. As we will see, each shell runs within a specific account under the control of a specific human. The command login [A] [B @ C] [D] precondition: human A and account B @ C are defined, and shell D is undefined executes the command “password-prompt A B @ C”. If the latter command succeeds, a new shell D is created that is running in account B @ C under the control of human A. Since it is a login shell, shell D has no parent shell. Later we will see another way to create a shell, via the h2h-shell command, which creates a new shell as a child of an existing shell. The command password [A] [B] precondition: shell A is defined sets the password of the account C @ D in which A is running to B, and then executes the command “password-belief E C @ D B”, where E denotes the human controlling shell A. The command passphrase-belief [A] [B @ C:D] [E] precondition: shell A is defined 2

updates the human controlling shell A to believe that if private key file B @ C:D exists and is encrypted, then it has passphrase E. The command passphrase-prompt [A] [B] precondition: shell A is defined and is running in an account containing an encrypted private key file B is used to determine whether the human C controlling shell A has a correct belief as to the current passphrase for private key file B. If so, the command succeeds. Otherwise, the command fails. The command h2h-keygen [A] (B) precondition: shell A is defined generates an RSA key pair. Letting C @ D denote the account in which shell A is running, the public and private keys are stored in files C @ D:public and C @ D:private, respectively. (The previous content of these files, if any, is overwritten.) If the optional parameter B is specified, then the private key file is encrypted using the passphrase B and the command “passphrase-belief A C @ D:private B” is executed. The command h2h-verify [A] [B] precondition: shell A and host B are defined is used to determine whether the human C controlling shell A accepts the public key of host B. In order to simplify our simulation, we assume that such keys are always accepted. This acceptance is recorded by appending the public key of host B to the file D @ E:known hosts, where D @ E denotes the account in which shell A is running. (If file D @ E:known hosts is undefined, then it is created before appending.) The command append [A] [B] [C] precondition: shell A and file D @ E:B are defined, where D @ E denotes the account in which shell A is running appends file D @ E:B to file D @ E:C. (If file D @ E:C is undefined, then it is created before appending.) The command h2h-agent [A] precondition: shell A is defined creates/destroys an agent process running in shell A (i.e., this command acts as a toggle). Such an agent has an associated set of private keys. When the agent is created, this set is empty. The command h2h-add [A] [B] precondition: (1) shell A is defined, (2) an agent is running in shell A, and (3) file D @ E:B is defined and contains a single private key, where D @ E denotes the account associated with shell A 3