MIT 6.858 Computer Systems Security Final Projects

Thanks. Videos in a playlist.

https://www.youtube.com/watch?v=mffhPgsl8Ws&list=PLP941GogrX...

Reminds me of Google Authenticator, hiding the private key (used for generating the one time codes) by hand-waving and wishful thinking. Most users probably don't realize that there is a shared key -- and are left wondering why there's no sane way to import/export keys/accounts (there's of course no good reason for this other than dumbing down/simplifying the UI/UX: I suppose opinions are divided on whether or not this is a good thing). When you don't understand that there's a shared secret, you don't realize that that secret could be backed up/leaked from the server side -- without you knowing. Pretending that it's a HSM type deal and hiding the complexity of key management obscures some pretty obvious attack vectors from the users.

All that said, (T)OTPs have some advantages versus traditional "provably shared-secret, by way of salt+hash+stretching" of traditional passwords.

Not a very good starting point to consider phone app storage a reliable secure black box...

I would say in comparison to storing it on the server, storing the encrypted private key in Keychain probably offers a lot more security. An attacker would need direct access to the device and would need to either a) know the user's passphrase, b) be able to fool TouchID or c) be able to bypass Keychain's security.

However if iCloud Keychain is enabled then this opens up the attack surface a lot more.

No doubt influenced by the MIT Bitcoin Project [1] that gave $100 in BTC to every MIT undergrad this fall.

[1] http://mitbitcoinproject.org/

I can try to offer some impressions on the encrypted filesystems, as I went through all of those. Perhaps it's a bad choice, as it is the "default" project, but it's the area I am most interested in. I am not an expert in encrypted file systems, but I am a developer for a private cloud storage provider, and have some passing familiarity with the subject.

* Paranoia: Another Encrypted File System

They make repeated statements about relying on the server to protect the file from access such as "We depend on the server to correctly process ACLs and serve files that the user is authorized to view." and "If the server can be trusted to enforce the ACLs,no malicious user, perhaps named Mallory, can be permitted to read Alice's files." but since the premise of these projects is to deny trust to the server it seems odd to trust the server with anything. They do make sure that file contents cannot be read by the server without the client key, however I'm not sure why they went ahead and implemented a server except as a learning exercise or perhaps to provide an end-to-end solution. Inspection of the GitHub code raised some odd practices, such as explicit calls to sys.path.insert(0, '/home/henchill/Documents/Workspace/encrypted_file_system/server'), which makes me think perhaps it wasn't packaged correctly. At least they put it on GitHub, some of the other project were shipped as tar.gz.

* FyreBox - Encrypted File System

"Our filesystem is made up of 3 components: the client, the server, and a trusted cloud service." A trusted cloud service for the keys? I don't know why you would trust a cloud service and not the server. GitHub code seems reasonably clean, but requiring trusted cloud service seems like a dealbreaker.

* KBox: An Encrypted File System

I see a lot of math and LaTex, and security seems well considered, but I have to wonder about usability. The solution seems to store so much on the client side, including information needed to reconstruct the root directory and file names, that access from multiple clients or using it for sharing files seems untenable. However, I could have misunderstood. Noticed mixed tabs and spaces in the Python code, as well as cleartext password and private key in the code. Even if it is for testing, seems like bad practice.

* DarkFS - An Encrypted File System

I think I actually liked this one the best. They start right out by saying they do not trust the server for anything, and implemented their solution against the Dropbox API. They insert and encrypt the permissions/ACLs with the file data. However, these permissions are enforced by the client, so I wonder if a malicious client implementation could sidestep the permissions checking entirely. It is unclear if the permissions are enforced by the nature and sequence of the encryption itself. They also mention that had some issues with the Dropbox API, specifically being unable to encode file sharing data. I wonder if they would have been better served to implement their solution against the Amazon S3 API, as it supports file metadata and is quickly become the standard for file storage. S3 API is implemented by OpenStack Swift, EMC Atmos, Hitachi HCP, etc. Their code seemed well organized and the writers seemed familiar with Python. Would have preferred to see it on GitHub.

I was also a bit disappointed not to see anything here about distributed filesystems, leveraging torrents or other distributed infrastructure so that no server has the whole picture. There was interesting work done in projects such as Tahoe-LAFS years ago, nothing in these MIT projects seems radically innovative.

There's actually another course (6.824, http://css.csail.mit.edu/6.824/2014/) that runs in the Spring that focuses on distributed systems, and also has had a number of interesting final projects. While we haven't released project writeups in the past, its possible we'll do something similar to 6.858 and put them up online at the end of the class for 2015.

Yeah, we made that the default project for teams to work on.

They asked for a delay on release so that affected services can be patched.