Reference no: EM132362214

Part One: Short answer questions:

This assignment is about authentication and access control.

1. A phonetic password generator picks two segments randomly for each six-letter password. Each segment has 3 English letters. The form of each segment is ΔΦΔ(consonant, vowel, consonant), where ΔΦΔ is an element in {a, e, i, o, u} and ? is an English letter which is not in a, e, i, o, u . For example, "pampam" can be a possible output of the generator. However, "iamiam" is not.

Determine the entropy associated with the above method of generating a password.

2. Consider the following statements and answer the subsequent question:

Alice can climb walls and jump fences.

Bob can push walls and push doors.

Chris can push Alice, push fences and jump walls.

Dan can open doors and jump Alice.

Draw an access control matrix representing this scenario.

3. Consider the BLP level relationship diagram in A1-Q3.pdf, and the associated explanation of the notation, and answer the subsequent questions. In this question write is used to refer to the BLP operation append.

(a) Does the diagram define a lattice? Justify your answer.

(b) Assume that if the diagram didn't define a lattice you have fixed it so it does, without changing the relationships between the existing levels. Some of the domination relationships shown in the diagram are redundant. Identify two such lines and explain why they are unnecessary.

(c) Assume that if the diagram didn't define a lattice you have fixed it so it does, without changing the relationships between the existing levels. If we have an object at level G and another object at level K, what single level should we assign a subject to be able to read both objects and be consistent with the principle of least privilege. Justify your answer.

(d) Assume that if the diagram didn't define a lattice you have fixed it so it does, without changing the relationships between the existing levels. If we put objects at levels B and J, what single level should we assign a subject to be able to write to both objects and be consistent with the principles of least privilege. Justify your answer.

Part Two: Authentication and access control system

You are to implement a simple "file system" with login authentication and access control. Specifically:
• Construct a hash/salt/shadow based user/password creation system.
• Construct a hash/salt/shadow based user authentication system.
Construct an associated file system, into which a user can log. Files can be created, read from, written to, but only in accordance with a four-level access control model.

The levels of the four-level access control model are 0, 1, 2 and 3. 0 is dominated by 1, 2 and 3; and 1 and 2 are dominated by 3; and 1 is dominated by 2.

Remark: You do not need to have an actual file system, simply an internal collection of records at the levels specified.
You can implement the program in C++, C or Java. You will use MD5 in this task.

The initialisation details
Your program will, initially, need blank files salt.txt and shadow.txt. Running your FileSystem with the instruction
FileSystem -i
runs the hash/salt/shadow based user/password creation system. This program should prompt for a username, something like...
Username: Bob
Check if the username exists already. If it does, terminate the program with an appropriate notification to the user. If it doesn't, request a password with something like ...
Password: ........
Confirm Password: ........
You should add some appropriate checks on the password and give a warning if the user fails to meet a requirement. The warning should explain what the requirements are. Assuming the passwords are acceptable and the same, we make a final request of the user, something like ...

User clearance (0 or 1 or 2 or 3): 1
Once we have this information we can modify the salt.txt and shadow.txt files to include this user. To
salt.txt we add a line, with a generic example and a specific one for user Bob given here:

Username:Salt Bob:38475722
where Salt is a randomly chosen string of 8 digits.
We also add a line to shadow.txt, with a generic example and a specific one for user Bob given here:

Username:PassSaltHash:SecurityClearance Bob:dd2da44f4437d529a80809932cb3da83:1
PassSaltHash is generated as the MD5 hash of the concatentation of the user's password with the salt, For example if the Password is "alphabet" and the Salt is "12345678", we would pass "alphabet12345678" to the MD5 function.

Logging in
Running FileSystem with no arguments will allow a user to try and log into the file system.
Remark: The file Files.store needs to be loaded, see later as to what this contains.

Username: Bob Password: ........

The system checks if the Username is listed in the file salt.txt. If the Username is in the file then their salt value is retrieved and the PassSaltHash is generated. A message should be displayed to indicate that the salt has been retrieved.

Bob found in salt.txt salt retrieved: Salt hashing ...
hash value: PassSaltHash

The system should now compare the PassSaltHash value with that in the file shadow.txt. If the informa- tion in shadow.txt doesn't match the generated information, FileSystem should stop with appropriate error messages.
If the shadow.txt information matches, the clearance of the user is reported, and authentication is reported to be complete.

Authentication for user Bob complete. The clearance for Bob is 1.

Once logged in ...
A list of allowed actions is now displayed

Options: (C)reate, (A)ppend, (R)ead, (W)rite, (L)ist, (S)ave or (E)xit. (1)
The C option will result in a request for filename from the client.
Filename: alpha
The classification level of a "file" is the same as its owner's clearance level.
The program should maintain a list of "files" as internal entries. If the passed file doesn't exist, it's name, owner and classification should be added to the list. If the passed file does exist an appropriate message should be displayed and the system should re-display the menu marked (1).
The A, R and W choices each results in a request for a filename.
Filename: alpha
Again a check is made as to whether the file exists. If the file doesn't exist an appropriate error message should be provided and the menu (1) should be re-displayed. If the file does exist, a message informing success or failure will be displayed. Success or failure is determined by the relative clearance of the user and the classification of the file they are trying to access, in accordance with the Bell-LaPadula model. Subsequently the menu (1) should be re-displayed.
The L option lists all files in the FileSystem records. The S option saves all the data to a file Files.store. This file should be human readable. This file should always be loaded if it is available when FileSystem starts without the -i argument.
The E option should exit the FileSystem, after checking with the user:
Shut down the FileSystem? (Y)es or (N)o
NOTE: When your program starts, before bringing up a prompt, it should report a test output of the MD5. You should call your MD5 with the string "This is a test".
MD5 ("This is a test") = ce114e4501d2f4e2dcea3e17b546f339
Don't hard code this output.