Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

CS 1657: Privacy in the Electronic Society

Project 2

Released: Tue, Mar 14

Proposal due: Tue, Mar 21, 11:59 PM

Final report due: Fri, Mar 31, 11:59 PM

Motivation

In this course, we discussed authorization at length, including multiple factors that can be used for authentication, several approaches to representing and enforcing access control policies, and the use of disk encryption and/or secure boot to prevent specific subversions of authorization systems. In this project, you will study some aspect of the authorization framework in detail. For instance, consider:

• implementing and testing a prototype enforcement engine for an access control policy language of your choice, studying the benefits and drawbacks to including advanced features

• comparing the psychological acceptability of various biometric authentication factors

• developing and analyzing a sophisticated brute-force approach to breaking a disk encryption scheme

• comparing secure boot strategies used in video game consoles vs. smartphones

Your submission should consist of the following components.

• Any code that you wrote for the project, satisfying the C tasks in your outline. Code can be written in the language of your choice (check with your instructor if you’re not sure it will work for them).

• A writeup that explains the motivation behind the project, the experiment(s) carried out, the results, and an interpretation of the results. The writeup should satisfy the W tasks in your outline and discuss your approach to the C tasks, mentioning specific lines, function names, etc. to help us understand your code. Each task should be discussed in your writeup.

All features, bugs, and other details regarding your code should be made clear in your writeup (i.e., do not submit a separate README or expect us to read every comment in your code). Each writing task should be clearly titled, and each code task should be clearly discussed in the writeup. In short, do not make us search for the components of your submission. Show off the hard work you did!

You may work individually or in a group of 2 or 3. If you work in a group, make sure all members use the GitHub Classroom link to join the repository. (One member should create the team, then the other(s) should join the existing team.) You do not need to work in the same group for all projects throughout the semester.

Proposal

Before the proposal deadline above, submit a proposal in PDF format that explains the goals of your project and any preliminary results you have to demonstrate that the project is worth pursuing.

First, consider the overarching theme of your project. What questions do you want to answer, and what course goals will you make progress toward by attempting to answer them? Think about our high-level course goals as well as your individual goals, and discuss them in your proposal.

As you work through the details that you will include, consider the ways you can satisfy two main criteria:

Technical depth: What is the intellectual merit of this project? How do you know that it will be sufficiently challenging? If some steps are easier than expected, what will you add to compensate?

Relevance: What are the privacy impacts of this project? What will you hope to learn by completing it, and what evidence do you have that it will be successful? What options do you have if your plan does not work, or you otherwise need to pivot?

In addition to answering the above, your proposal should include an outline of the writeup you will submit at the end of the project. For each (code or writing) task, specify what steps you will complete and what you hope to learn (and explain to us!) by doing so. Show any preliminary results that you have collected to demonstrate the feasibility and impact of each task.

Suggested things to include in an example outline are available below, but we encourage you to think beyond these guidelines if you have ideas that don’t fit perfectly into what we suggest.

The proposal period is your chance to start working on your project before you have a firm idea. This allows you to explore the topic, especially if you have multiple ideas and/or are unsure if your ideas will work. During this period, it is your responsibility to experiment and determine what you will be able to complete by the deadline. Plans can always change for a variety of reasons, but your proposal should be well-thought-out and based on having made a reasonable amount of progress toward your goals.

Submit your proposal as the only PDF file within the proposal subdirectory. Your submission should be committed and pushed before the proposal deadline above.

Within a few days after the proposal deadline, you will receive full feedback on your proposal, formalizing the standard by which your final submission will be evaluated. You are encouraged to keep working on your project in between. My goal is not to radically change the direction of your project, but instead to give suggestions to help you execute your ideas as strongly as possible.

Example Outline

This section contains an example outline of tasks geared toward exploring the advantages and disadvantages of certain types of expressiveness of access control systems. Task W0 introduces an access control language, and Task W1 fully specifies the syntax you will use to represent it. Task C2 demonstrates how the language can be interpreted and enforced. Tasks W3, W4, and W5 give specific examples and use cases for the main features of the language. Tasks C6 and W7 study how policies with differing levels of complexity effect the efficiency of enforcement.

Task W0: Choose an access control language that supports indirection, administrative delegation, and at least one other feature. You may consider forms of ABAC, ReBAC, SD3, or RT, but you are not limited to these options! I would be happy for you to choose something unique and impressive!

Your language must support at least the following features:

• Indirection: The ability to assign a large set of permissions at once. Consider roles, attributes, groups, etc.

• Administrative Delegation: The ability to set additional entities that have the ability to affect a resource’s access policy. For example, consider RT’s delegation of attribute authority, or the $ notation in SD3. You might represent different administrative entities as different text files, each representing the relations published by one particular entity.

• At least one other: At least one other feature that allow administrators to write expressive policies. Consider role inheritance (role hierarchy), attribute intersection, parameterized attributes, etc.

You may include more than the required features for extra credit.

To start your writeup, overview the access control system that you chose, the features it supports, and any extra tools you developed.

Task W1: Fully describe the syntax used to write a policy file for your access control language. This file should be plaintext and simple for an administrator to write. This means that your policy should not be hardcoded in the program. I should be able to adjust the policy without changing or recompiling the code.

Explain how each supported feature is represented in plaintext. If your file needs to include a list of all existing users/subjects or files/resources/objects, explain the format for this information as well. Your format is allowed to consist of multiple files (e.g., delegated attributes may be declared in separate files).

If your access control system is inspired by an existing language, note that the syntax used in your policy file may differ from how we viewed example policies in class. For instance, you may use <- or :- to represent RT’s ← symbol. Alternatively, you may consider standard formats for structured input, which would enable you to utilize existing parsing libraries. Consider JSON, XML, Datalog, etc. Again, you do not need to type your policies in the exact format that existing languages use.

To give one simple example using XML, you might represent Pitt.student ← Juliana as follows:

<attribute name="student" domain="Pitt" constant="Juliana">

Task C2: Implement a program to interpret your access control language. It should be able to do the following steps:

Read, parse, and preprocess (if necessary) a specified policy file(s) in the format you describe in Task W1.

Prompt the user for an access query (that is, a query of the form, “Can user u access file f with read privilege?” or similar). Clearly state the format in which the user must type their query.

Using the policy that was parsed from the input file, determine whether the access should be permitted, and output the response (allow or deny).

Repeat from Step 2.

Note that you are only required to support access queries, but you can implement additional queries for extra credit (e.g., “Is user u a member of role r?”).

Task W3: Explain, with examples, how indirection is represented, and how it should be used, in your language. You should give at least 2 examples to make it clear how this feature works and how it can be used.

Discuss the benefits to having this feature, from the perspective of privacy, expressiveness, efficiency, administrative overhead, usability, or some other metric. Does it allow for easier assignment of certain types of permissions? Will it prevent errors in the policy? Does it allow users to set policies that more closely match their preferences? Does it allow resource owners to set policies they could not without the feature, and therefore support more diverse types of privacy requirements?

Next, discuss the potential drawbacks of having this feature, again considering privacy, administrative overhead, usability, and/or other metrics. Could it make it slower to render access decisions? Could it give the user too many options and potentially overwhelm them? Could it be misunderstood and lead users into granting accesses they did not intend to? Could it prevent, or make more complex, an automated analysis to detect insecure policies? Consider specific scenarios wherever possible.

Task W4: Explain, with examples, how administrative delegation is represented and used in your language. Again, you should give at least 2 examples.

Discuss the benefits and potential drawbacks of having this feature, similar to how you did in Task W3.

Task W5: Name any other access control features that you implemented in your program (at least one is required). Explain, with examples, how they are represented and used in your language. As before, give at least 2 examples of each feature.

Discuss the benefits and potential drawbacks of having each additional feature, similar to how you did in Task W3.

Task C6: Construct at least 5 experimental policies (manually written or randomly generated) of varying size/complexity. Your goal is to study the efficiency of enforcing policies of various complexities to investigate how your enforcement program scales to large, complicated policies. Consider, for instance, long chains of trust.

Write a program to time (benchmark) your processing of a policy and query. This program should not be interactive and should run hardcoded (or randomly generated) queries on the policies you constructed, then report the results.

You might consider measuring separately the time for two distinct tasks for each policy, if it makes sense for the implementation you wrote:

The time it takes your program to read and preprocess the policy, without considering queries.

The time it takes your program to respond to a query after the policy has been read and processed.

You are welcome to adjust this according to your particular implementation strategy; what makes the most sense to get a detailed picture of your implementation’s efficiency as policies scale?

Use the average of multiple trials if your timing is not consistent.

Task W7: Interpret the results of Task C6. Show a chart, table, or graph of your data. Explain what this tells you about how your enforcement engine scales. If the runtime scales poorly, is this a problem with the language you chose, or with your specific enforcement engine? Is this language reasonable to use for personal computers? What about enterprise scenarios? Can it scale to a large cloud storage service? Show off as much as you can regarding what this experiment taught you about access control enforcement.

Project Choice

We believe that more interesting results, and more genuine learning, will occur if you explore the goals of this project in a unique way that is compelling to you in particular. A strong submission should be creative and interesting, and should help the reader learn something new about authorization. Whatever you choose to experiment with, you should have concrete questions you wish to answer, and you must be able to observe, reflect on, and interpret the results.

Note: It might be helpful to think about a project that focuses on one specific type of scenario, rather than studying a fully-featured general-purpose scheme. If you are considering access control systems, think about things like the following:

• A theater scenario, where ticketholders access seats and concessions, actors and other staff access backstage areas, etc.

• A self-driving car, where different processes in the car have access to different signals, the manufacturer collects some information for debugging purposes, etc.

• An online newspaper, where journalists and reporters can submit their stories, sub-editors can modify stories for grammar, photographers can add images, and editors can add headlines and approve stories for publication.

Any of these specific examples will make a much more interesting (and manageable) project than, “a company with 1000 employees and hierarchical supervision.”

Note

As this course is an upper-level elective, you are being given a lot of freedom in terms of how you tackle this project. In exchange, you also have a lot of responsibility to demonstrate your hard work adequately to your instructor. As such, there are tasks in this assignment that require you to discuss your code in detail. Your discussion should closely align to, and refer to, your specific implementation. Do not claim that your code does something that you know it does not (see the Academic Integrity Policy).

Your submission should demonstrate two main criteria:

Technical depth: What is the intellectual merit of this project? Demonstrate that you achieved something sufficiently challenging.

Relevance: What are the privacy impacts of this project? Demonstrate what you learned by completing it and why it is meaningful.

You may use any programming language and library functions that you prefer, but you must ensure that your choice of language/library does not prevent you from demonstrating sufficient technical depth. This is a (more than) 2-week project in an upper-level technical course; if you satisfy the requirements in only 4 lines of code, you’re probably using a library function that has reduced the technical depth of your particular contributions. Show us that you’ve thought hard about this problem and mitigations, and that you learned something valuable about timing attacks and implementing ways around them. If you need help deciding whether something should be permitted, contact your instructor.

Submission

Submit your writeup as the only PDF file within the report subdirectory. Your submission should be committed and pushed before the deadline above. Any relevant code should also be discussed and included in your commit.