1. Secure File System - Final Meeting Industrial Project (234313) Prof. Michael Elad Students Noam Hershtig Yuri Bronshtein 04.02.13 Supervisors Boris Dolgunov Constantine Elster

2. Agenda  Goals  Problem Description  High Level solution  Demo  Methodology  Technical  Team Work  Protocol  Conclusions

3. Motivation

4. Motivation (cont.)  Defcon 20 (July 2012): “Into The Droid” by Thomas Cannon  Shows how easy is to crack the Android Encryption “Into The Droid” DEFCON20 Slides from: https://viaforensics.com/mobile-security/droid-gaining-access-android-user-data.html

5. Goal: Prevent Brute Forcing Encryption Key  Solution: 2 Stage Authentication  Store Key in TrustZone™ (KeyDB)  KeyDB Throttles key retrieval attempts  Key management is transparent to user & applications.

6. Solution Components OS kernelTrustZone dm-crypt- skm KeyDB Key Manager SFS Kernel Modules (skm, skm-udp) User mode Screen lock application SFS configuration application dm-crypt Unmodified Optional Changes Original

7. Demo

8. Our Process  Study Android & Linux Encryption mechanisms:  Device-mapper, dm-crypt  LUKS (key management alternative)  Create “proof of concept” encryption key manager  Create modular design  Define protocol  Implement Separate components:  Divide labor by platform: Android Apps / Linux Kernel  Use TDD principles:  Unit Tests before code (where applicable)  Use “simulation” (python test scripts) to test interfaces in early stages.  Integration  Verify separate modules work as expected together

9. Key Management  Runs in TrustZone  Login Attempt Throttling:  Different Locking Schemes available  Long Term Locking  “Burst Mode”  User Management:  Multiple PIN/Key pairs  Useful for Tablets  Administrative Rights  Recovery Options

10. Kernel Modules  Implemented as part of the device-mapper framework  /drivers/md  dm-crypt-skm:  device-mapper target.  Wraps dm-crypt, the original crypto device service.  skm (secure key management)  Implements the protocol generically.  Uses “pluggable” modules for communication with KeyDB in TrustZone.  Managed from usermode via ioctls. Creates “/dev/skm” device.  skm-udp  Uses netpoll API to communicate with KeyDB via UDP packets. TrustZone (KeyDB)skm-udpskm /dev/skmUser: Settingsdm-cryptdm-crypt-skmdm (dmsetup)User: Lock Screen

11. Development Platform and Languages  Android TrustZone Simulator  Java + Android SDK (Eclipse)  Testing: jUnit for Android, python for network simulation  Linux kernel modules (dm-crypt-skm, skm, skm-udp)  ANSI C  Run on GNU/Debian as vmware guest  Tested on 2.6.32 kernel, compatible with 3.3 kernel API.  Testing: python for network simulation  Configuration Application  ANSI C  Lock Screen Demo  Python and wxPython  Source Control  git (assembla private repository)

12. Kernel  TrustZone Protocol  Key Retrieval  getKey  getStatus  loadKey  unloadKey  Misc.  getVersion (For backward compatibility)  User Management  addID  removeID  changePIN  setParams  getParams  unlockID HW Support

13. Challenges  Minimal Architectural Changes  An early goal was to minimize changes to Android OS & Apps.  After studying the linux crypto services, dm-crypt was chosen as the best subsystem to modify  Kernel  Usermode Communications  Unorthodox model (simulate ‘CPU mode’ as usermode process)  Usually communication is initiated from usermode  Options which were considered:  polling (easy to implement, breaks design for actual ARM chips)  sysfs/proc (not secure enough)  sockets (incompatible with dm)  netpoll (modern API in kernel, used primarily for low level debugging)

14. Conclusions  Design  Good design simplifies code stage  Allows modularization  Modularization  Very important for team based coding  Allows easy testing & relatively smooth integration  Helps minimizing changes in porting to another platform  Minimizing Kernel Code  Debugging kernel code is non-trivial and time consuming  Linux APIs are changing all the time:  No current documentation available  Version dependent code  Automatic testing is nearly impossible  Early Testing (Test Driven Development)  Quick development  Easy regression testing

15. Thank You!