
MIT 6.858 Computer Systems Security Final Projects - jlrubin
http://css.csail.mit.edu/6.858/2014/projects.html
======
pkrumins
Here's the full course (20+ lectures) on youtube if anyone's interested:

[https://www.youtube.com/results?search_query=6.858+Fall+2014](https://www.youtube.com/results?search_query=6.858+Fall+2014)

~~~
myth_buster
Thanks. Videos in a playlist.

[https://www.youtube.com/watch?v=mffhPgsl8Ws&list=PLP941GogrX...](https://www.youtube.com/watch?v=mffhPgsl8Ws&list=PLP941GogrXs2akp7053CtkfEM3yw8fObm)

------
Canada
From Pretty Good Chat:

"We consider the case of the private key being stolen as very unlikely. The
users themselves are not able to access it outside the app, and no other
adversary will be able to either"

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

~~~
film42
True, but you can increase that reliability with encrypted sqlite. Gonna have
to pay for it, though.

~~~
chacham15
Why? [https://www.zetetic.net/sqlcipher/](https://www.zetetic.net/sqlcipher/)

------
mrb
Interesting how 4 of the 25 projects are related to Bitcoin. It just goes show
that the cryptocurrency inspires a good fraction of computer & network
security people:

CheckBits: [http://css.csail.mit.edu/6.858/2014/projects/adat-bschang-
er...](http://css.csail.mit.edu/6.858/2014/projects/adat-bschang-ericadu-
ptew.pdf)

TorCoin: [http://css.csail.mit.edu/6.858/2014/projects/bchrobot-
ynnad1...](http://css.csail.mit.edu/6.858/2014/projects/bchrobot-
ynnad19-dereklax.pdf)

Dryer21, a Bitcoin Anonymizer Service:
[http://css.csail.mit.edu/6.858/2014/projects/asuhl-
dannybd-s...](http://css.csail.mit.edu/6.858/2014/projects/asuhl-dannybd-
snp.pdf)

Merkelized Abstract Syntax Trees:
[http://css.csail.mit.edu/6.858/2014/projects/jlrubin-
mnaik-n...](http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-
nityas.pdf)

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

[1] [http://mitbitcoinproject.org/](http://mitbitcoinproject.org/)

~~~
jhurwitz
I'll note that OP is a founder of the MIT Bitcoin Project.

~~~
jlrubin
Correct. Also in connection to the post, I'm an author of Merkelized Abstract
Syntax Trees project for what it's worth.

------
achernya
I'd like to congratulate all the students for all of their hard work. 6.858
always produces new, original results, and this year is no different.

------
grdeken
I was a consultant for MIT and a student decided his final project would be to
hack the custom LMS system we were working on. To our surprise, he figured out
at least two ways before letting us know he was working on a final project.
Gotta love MIT.

------
e12e
If anyone has taken the time to go through all/all projects of a certain
category, I'd love to hear some impressions/TL;DRs.

~~~
keypusher
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.

------
dvorak42
To compare with previous years
([http://css.csail.mit.edu/6.858/2013/projects.html](http://css.csail.mit.edu/6.858/2013/projects.html)):

2013 vs 2014

2/35 vs 4/25 - Bitcoin Projects

12/35 vs 4/25 - Encrypted Filesystems

2/35 vs 1/25 - Privilege Separation

------
wyclif
The reference materials page is also worth checking out:
[http://css.csail.mit.edu/6.858/2014/reference.html](http://css.csail.mit.edu/6.858/2014/reference.html)

------
brador
There should be a final project like this to make distributed systems. It's a
new area and could disrupt major players.

~~~
dvorak42
There's actually another course (6.824,
[http://css.csail.mit.edu/6.824/2014/](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.

------
DannyBee
That's a lot of encrypted filesystems :)

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

------
girvo
I want to know about the Hacking MIT writeup! It's not available yet, I wonder
what they achieved?

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

------
tedivm
I really want to see the package manager security paper when it's out.

------
BlindWanderer
MAST looks interesring.

As to Kerby, all I have to say is Xposed.

