1 / 15

Secure File System - Final Meeting

04.02.13. Secure File System - Final Meeting. Industrial Project (234313). Prof. Michael Elad Students N oam Hershtig Yuri Bronshtein. Supervisors Boris Dolgunov Constantine Elster. Agenda. Goals Problem Description High Level solution Demo Methodology Technical Team Work

phiala
Download Presentation

Secure File System - Final Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 04.02.13 Secure File System -Final Meeting Industrial Project (234313) Prof. Michael Elad Students Noam Hershtig Yuri Bronshtein 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 User mode OS kernel TrustZone dm-crypt Unmodified Optional Changes Original Screen lock application dm-crypt-skm SFS Kernel Modules (skm, skm-udp) SFS configuration application KeyDB Key Manager

  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 • <kernel>/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.

  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 • User Management • addID • removeID • changePIN • setParams • getParams • unlockID • Key Retrieval • getKey • getStatus • loadKey • unloadKey • Misc. • getVersion (For backward compatibility) 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!

More Related