# A5 **Deadline:** Wednesday, 04/26/17, 11:59 pm *This assignment may be done as individuals or with one partner.* ## Problem 1 (30 pts) *inspired by the [Onity lock hack][onity]; beware that reading about it might poison your mind toward bad solutions* [onity]: http://demoseen.com/bhpaper.html Your task in this problem is to complete the design of an authentication system for a hotel. The hotel uses an electronic lock system to control access to rooms throughout the property. The system uses the "something you have" paradigm for authentication. We assume you are familiar with the kind of lock system typically employed in modern hotels, and essentially we are asking you to design that kind of system. The hardware constraints and design goals are given below. The specifics of what you needed to do are spelled out below in the section titled "Questions". Hotel guests are issued keycards that authenticate to locks. A guest's keycard should open their room, but not other rooms. We thus omit the issue of common access to the pool or side entrances. Staff are issued master keycards, which can open every lock in the hotel. We thus omit the issue of staff having differing privileges. You may assume that the hotel has at most 600 rooms spread across at most 10 floors, and that there are at most 100 staff employed in any given six month period, including all hirings and firings during that time. You may also assume that the expected lifetime of the system is 20 years. **Hardware Constraints:** The authentication hardware involved is as follows: * Humans are issued *keycards* as authentication tokens. * Rooms have electronic *locks* which require insertion of a keycard to authenticate. * The front desk has a stationary computer called an *encoder* that is used to configure keycards. * The front desk has a handheld computer called a *portable programmer* that is used to configure locks. There is no network in the system: the encoder is not connected to a network, nor are any locks. Keycards have a magnetic stripe (magstripe) used to store information. The magstripe can be read and written by inexpensive hardware/software products. The storage capacity of the magstripe is 416 bits. Yes&mdash;bits. Storage space is quite limited on the keycard. Locks execute a program stored in ROM. They additionally have 16 KiB non-volatile RAM that can be used for data storage. Locks are not tamper resistant: an adversary with physical access to a lock can extract and change any information stored in its RAM, as well as read (but not write) its ROM. Locks have two interfaces. The first interface is where users insert keycards; guests and staff use it to authenticate to locks then enter rooms. This *keycard interface* is capable of reading magstripes, but not writing them. The second interface is a port to which the portable programmer can be connected using an inexpensive, standard cable. Staff use this *programmer interface* to perform any other communication with a lock, such as configuration during installation, maintenance, and diagnostics. The port is located on same side of the lock as the keycard interface, hence is accessible from outside the room that the lock guards. Locks have a clock that can be set with the portable programmer. Twice a year (shortly before the two nights when daylight saving time changes), hotel staff take the portable programmer to each lock to correct its clock and update its knowledge of when daylight saving changes (since neither those dates nor their calculation is firmly fixed). The clocks drift at a slow enough rate that this biannual visit is sufficient to correct for any errors. The microprocessor inside a lock is relatively slow. Computing an AES-128 encryption or decryption of a single 128-bit block requires 1 ms. Computing a SHA-256 hash of message m requires 1+ceil(|m|/512) ms, where |m| denotes the length of m in bits. Those are the only cryptographic primitives available for use, but you are free to build more sophisticated algorithms out of them. Of course, simple bit operations like addition, xor, etc. are available and are much faster than the block cipher and hash operations. So the cryptographic primitives are likely to dominate the running time of whatever you design. Locks are not capable of generating cryptographically-strong random numbers. Locks are powered by batteries that hotel staff periodically replace. The expected lifetime of a fresh set of batteries is two to four years. The encoder is a general-purpose personal computer running a standard operating system. You are not responsible for designing the authentication system employed by that operating system. The encoder is connected to a peripheral that can read and write magstripes. The encoder executes a custom application for managing the electronic lock system. When a guest requests a keycard, the hotel front desk staff use the encoder to write information to a keycard, which might be reused from a previous guest. The portable programmer is a custom piece of hardware and software, but it is built out of standard parts. When not in use, it is kept in a safe behind the front desk; you are not responsible for designing authentication to that safe. The portable programmer has a general-purpose CPU, 16 GiB of flash memory, rechargeable batteries, no cryptographically-strong source of randomness, and limited I/O capability. For the user interface, there is a small LCD display and a keypad, similar to an electronic calculator. For interfacing with locks and the encoder, it has a port for connecting a cable. The portable programmer does not have an interface to read or write magstripes. The typical workflow with the portable programmer is to connect it to the encoder, download some information, disconnect, take the programmer to a lock, connect, perform some operation upon the lock that involves reading/writing the lock's memory, and possibly reconnect the programmer to the encoder afterwards. **Design Goals:** As you complete the design of the authentication system, you should satisfy the following goals. 1. When a room transitions in occupation from one guest to another, all that should normally be necessary is for the front desk to encode a new keycard, and for the new occupant to use the keycard to enter the room; at that point, the former occupant's keycard should no longer be accepted by the lock. This goal should be satisfied even if the former occupant never entered the room. (Maybe they rented the room but actually spent the night in another room with someone else. Maybe they wouldn't want their significant other to know that.) But it's rare that more than two occupants in a row would fail to ever enter the room, so it's okay in that scenario for additional mechanisms to be needed. 2. A lock should respond within 100 ms to any attempt to authenticate to it by keycard, either by guest or by staff. Together with the contraints on the microprocessor, this implies that the amount of cryptography that can be used is bounded. In other words, the system should be responsive, so that users don't complain about it. 3. Malicious guests are a possibility. The system shall prevent guests from accessing other guests' rooms, and from depriving other guests of access to their own room. It follows that it should be highly unlikely that a guest's keycard would be able to open other rooms at *any* hotel using the system. As usual, assume Open Design. Hence, technically capable guests could build their own portable programmers and magstripe readers/writers, or purchase them (perhaps on the gray market). But your solution does not need to defend against attacks that involve physical modification to locks (e.g., skimmers to read magstripes, overloading the lock with electricity to burn out the circuits, etc.), nor attacks that involve guests getting access to the encoder or portable programmer (e.g., distracting the front desk staff and using it themselves). 4. Lost keycards are an expected phenomenon for guests, and therefore should be easy to handle. Reenabling room access under a new keycard while revoking access under the lost keycard should at most require the front desk staff to issue a new keycard, and for the guest to authenticate to the lock with that new keycard. 5. Lost keycards (or revocation because of firing) is an uncommon phenomenon for staff, and therefore may be more expensive to handle. Recovering from such a loss may require a staff member to visit every lock that the keycard was capable of opening. But it should not require having to replace the keycards issued to the rest of the staff. **Questions:** Given the hardware constraints and design goals above, complete the design of the authentication system. To do that, figure out (i) what will be stored where, and (ii) what protocols will be used in the various tasks mentioned above. Then answer the following questions. Wherever protocols are involved in your answer, use protocol narrations with proper notation as we've used in class, and also explain the steps in more detail in English. In your solution, bear in mind that you are balancing security and usability. The needs of a hotel are not the same as a military installation. Your authentication system needs to do a good job of achieving security while providing the level of usability that hotel guests expect. 1. In one paragraph, summarize the design of your system. If it is similar to any of the systems we studied in class, mention those similarities, as well as any differences. Summarize what information is stored by each device (keycard, lock, portable programmer, and encoder) in the system. Your goal in answering this question is not necessarily to be complete, but to provide the grader with a high-level understanding of your design before they start reading about the specifics. *Hint: not only will this help the grader, but figuring out what is stored where will help you in constructing the rest of your design.* 2. How will the encoder be configured after it is installed at the hotel? Describe any initialization that is necessary for the authentication system. (You don't need to discuss configuration of the OS, etc.) 3. How will a lock be configured by the portable programmer after the lock has been installed in a door? Your answer needs to address only a single lock at a time. (Though, obviously, configuration of multiple locks simultaneously would be more time efficient for hotel staff.) Specify the protocol between the encoder, portable programmer, and lock. 4. How will guest keycards be created? Specify what the encoder does, especially what it writes on the keycard. Your answer should address creating keycards for guests when they first checkin, creating duplicate keycards at that point or later (e.g., if they want a keycard for a roommate), as well as creating keycards when the guest believes theirs has been lost or stolen. In the latter case, your answer should ensure that the lost or stolen keycard becomes revoked, such that it no longer will open the door. You do not need to address how the front desk staff authenticates the human who is the source of these requests. 5. How will staff master keycards be created? Specify what the encoder does, especially what it writes on the keycard. Your answer should address creating keycards for staff whey they are first hired, as well as creating keycards when the staff member loses theirs or is fired. In the latter case, your answer cannot assume that the staff member or keycard is physically present. 6. How will keycards authenticate to locks? Specify what the lock does with the information it reads from the keycard. Be clear about when the lock opens, and when it remains locked. 7. Explain how your solution satisfies Design Goal 1 (revocation of access from former occupants). 8. Explain how your solution satisfies Design Goal 2 (timely response from the lock). 9. Explain how your solution satisfies Design Goal 3 (defense against malicious guests). **What to submit:** a file named `hotellocks.pdf` answering questions 1 through 9. ## Problem 2 (30 pts) *adapted from Prof. Jim Martin (Clemson University)* Write a program whose purpose is automated review of a Linux system log. Your program should take as input the file `/var/log/auth.log` from Ubuntu 16.04. Then, your program should process the log to determine whether an attacker has attempted to login to an account for which he is guessing the password. Finally, your program should produce a single line of output that would be suitable to append to `/var/log/syslog`&mdash;that is, the output should be consistent in format and information with other entries in `syslog`. Somewhere in that line should be either the string `"OK"` or `"INTRUSION"` to indicate your program's determination. In case of `"INTRUSION"`, the output should further estimate the number of users whose accounts the attacker attempted to access. Since what constitutes an attack depends in part on the expected workload of the system, assume that the system is a server for a CS department at a small college: there are about 100 users, all of which commonly login at least once per day. Be clear in your solution about any additional assumptions you are making about the workload. <i> Hint: Here are some questions you need to address: * What constitutes an attack? * What evidence is recorded in `auth.log`? * How can you parse `auth.log`? * How can a program recognize an attack based on the evidence? * What information should you put into `syslog`? * How should you format that `syslog` entry? </i> **Server access:** Use the same Ubuntu 16.04 virtual machine as in [A4][a4]. [a4]: ../a4/a4.html **Implementation:** As in A4, you may use any programming or scripting language that can be installed on the virtual machine you created according to the instructions above, as long as that language can be installed by `apt-get`. **Execution:** Your program should accept the name (including path) of the file to be processed as a command-line argument. Do not hardcode `/var/log/auth.log` as that filename: the course staff needs to be able to test your program on many log files&mdash;as do you. **Design document:** Provide a file named `design.pdf` containing an explanation of the design of your automated reviewer, focusing on (i) what specific criteria you use to determine whether an attack occurred and (ii) why you are using these criteria. Discuss false positives and false negatives in light of points (i) and (ii). This design document will be worth about half the total points for this problem. **Usage:** Provide a file named `README.txt` describing how to install and execute your program. If you use any packages installed by `apt-get`, then you need to document at the beginning of your source code how the grader can easily install those packages in their own virtual machine. Document the exact command the grader should type in the virtual machine to run your program. It should not take more than a couple of minutes (excepting whatever time `apt-get` itself consumes) for the grader to follow the installation and execution instructions; if it does, your solution might be penalized. **What to submit:** an archive named `authlog.zip` containing your source code, readme, and design document. ## Problem 3 (25 pts) Your task in this problem is to design the logging system for an automated teller machine (ATM), whose functional requirements are given below. Your design should answer the following questions: 1. What log files will be kept, and where? 2. What is the format of an entry in a log file? 3. What are each of the possible entries that could be made into a file? Specify the information contained in the entry and the conditions under which the entry will be made. The entries should cover at least 10 different types of events. You are permitted to propose modest hardware improvements to the ATM for the purpose of logging. **ATM functional requirements** *(adapted from [Wang et al., *The formal design model of an automatic teller machine (ATM)*, IJSSCI 2(1):102&ndash;131, Jan&ndash;Mar 2010] and from Prof. Russell Bjork (Gordon University))* An ATM comprises the following subsystems: * a processor, which performs computation * a magnetic card reader * a keypad * a monitor * several bill storage canisters, one per denomination * a bill disburser * a thermal printer for customer receipts * a system clock * a slot through which customers can deposit envelopes * a communication link to a bank-operated network * a physical key-operated switch to enable an operator to start and stop the machine The ATM provides service to customers only if the key-operated switch is set to the "on" position. When an operator turns the switch to that position, the operator is required to enter into the keypad the amount of cash in each canister. (The denominations of the canisters are known to the machine.) The switch can be turned to "off" only if there is no customer currently in the midst of a series of transactions. When off, no customers will be served, and the operator can remove deposit envelopes, reload the ATM with cash, and replenish the paper for receipts. The ATM will not provide service to customers unless the communication link is active. If the link ever is inactive, the ATM cancels any in-process transactions and refuses to begin any new transactions. To receive service, a customer inserts their ATM card into the reader. The ATM reads the magnetic stripe and returns the card to the customer. The customer then enters a PIN on the keypad. The ATM authenticates the card and PIN, which requires using the communication link to the bank. * If authentication fails, the ATM re-prompts for the PIN. After three incorrect attempts, the ATM communicates to the bank that the card should be deactivated. * If authentication succeeds, the bank retrieves a set of accounts that are associated with the card. The customer can then perform a series of transactions with those accounts, which continues until the customer indicates they are finished or until the ATM detects that the customer has failed to respond to an input prompt within a period of one minute. At any point a customer may abort a transaction in process by pressing a Cancel key on the keypad instead of entering the next input requested by the ATM. If a transaction succeeds, the ATM prints a receipt for the customer. The following transactions are supported: * **Withdraw** cash from an associated account in any denominations supported by the ATM. If the ATM does not have sufficient cash available, it cancels the transaction. Furthermore, the bank must authorize the debit of funds. The ATM does not participate in that authorization decision. * **Deposit** funds into an associated account. The customer places cash or checks in an envelope and enters the amount of the deposit on the keypad. The bank will later decide whether the claimed amount is consistent with the funds available from the envelope and, if so, will credit the account. The ATM does not participate in that decision. * **Transfer** funds between associated accounts. * **Query** the bank for the funds available in an associated account. **What to submit:** a file named `atmlog.pdf` answering questions 1, 2 and 3. ## Submission If you work with a partner, first form a group on CMS; submit as that group, rather than submitting the same solution independently. Submit the files specified above to [CMS][cms]. [cms]: https://cms.csuglab.cornell.edu/ ## Evaluation You will be evaluated on the quality of your solutions and on your adherence to the submission stipulations above. We'll use the following criteria in evaluating quality: - *Validity:* do you present a logical, lucid, coherent, clearly focused, well structured, and appropriately detailed argument? - *Consistency:* do you employ concepts, principles, and terminology as they are used in this course? - *Evidence:* do you adequately support your conclusions? - *Writing:* do you use proper mechanics, grammar, and style?