Filelocker: Simplifying Secure File Transfers Presented by: Brett Davis, IT Security Engineer Copyright William Brett Davis, 2010. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

Agenda Initial needs Filelocker v1 (currently in production) Lessons learned and feedback Filelocker v2 (going to beta soon) Future Action Items/Plans for v2.5 Questions

How do you send sensitive information? Currently… How do you send sensitive information? PGP? S/MIME? Encrypted Zip? Out of band password transmission? Sneaker-net? How about larger files???

Project Initiating Problems Faculty and staff would unknowingly use regular email to send sensitive data to others Implementing email security campus wide is expensive or complex (but usually both) Security personnel needed a secure means to communicate back and forth and with end users E-mail is inefficient for sending large files - especially to multiple users People unknowingly sending infected files Lack of ability to (easily) authenticate senders of files via email Auditing

Sensitive data would hang around on the network for much too long. and zombies Sensitive data would hang around on the network for much too long. We still the effects of this today when someone plugs in an old workstation or server Oh what secrets the undead have to tell

Filelocker v1 Enter Filelocker v1 -Developed in house (WHICH MEANS IT’S FREE RIGHT?) -Designed around securing the transfer (security in transit, at rest, secure deletion, separation of keys from files, minimized need for pre-shared keys) -Attempted to be intuitive so that users would be less resistant to adoption and would opt to use it over email -Designed to be efficient for larger files (<1GB) – upload once, download many -Tied into Purdue’s directory -Allowed for (relatively) secure sharing out to the public -Kept history of uploads and downloads (though not easily user accessible)

Uploads in Action! Drawback:Did not allow virus scans and encryption!

Sharing and Searching

It’s nice but… Feedback Needs a way to let people outside Purdue upload Needs groups Needs bigger files Mandatory encryption Can it be used to distribute AV and other security related software? Can students use it? If so, can’t they use it to share music!?! OH NO!!!!

So Filelocker v2 now has Groups Larger file upload capacity (arbitrarily large now, max can be set in config) Upload requests (allows people outside Purdue to upload to Filelocker) Mandatory encryption A provision to check file md5 hashes against known copyrighted material – just need to find a database Ability to scan encrypted files Among other core and UI upgrades (better OOP, more intuitive interface) -The alternative to hashes would be disallowing .mp3 extensions or possibly just disallowing them for students.

Filelocker V2 UI mock ups Some of you might find this layout… familiar

Upload options

Uploads in progress

Sharing with other users

Public uploads

Public Sharing

Core is written in Python (CherryPy for the web server) MySQL database Technologies used Core is written in Python (CherryPy for the web server) MySQL database jQuery and some other JQ plugins (all open source) on the front end to manage concurrent uploads

Security Specifics SSL used to encrypt files in transit Files are spooled to disk Virus Scan MD5 calculation and lookup Encrypted using AES-128 Temp file is securely deleted Auto-encrypted files store keys in database (which should be on a different server than the file server) Files are not at risk if only the file server or only the db server is compromised Files and users have a max lifetime – purged after x days

In the works for 2.5 SMB server support (users can link FL to an SMB share – serve files directly from it) Caveat: No file encryption and credentials for share must be stored by FL! Secure Messaging (Think Facebook style messages) Mobile (iPhone, Blackberry) apps Login federation and ability to “connect” Filelocker instances at different organizations Desktop application to emulate network drive (maybe…)

Can anyone see something like this being adopted at your institution?

Beta testing to start mid-May Where we are now Beta testing to start mid-May If anyone is interested in testing at their own site – please send me an email at wbdavis@purdue.edu The core of Filelocker will be open sourced soon (since I know you were going to ask)

Suggestions? Questions? Have any of you approached secure file sharing in a different way?