150 likes | 232 Views
This project aims to enhance Android security by implementing a two-stage authentication solution to prevent brute-forcing of encryption keys. The solution involves storing the key in TrustZone™ (KeyDB) and throttling key retrieval attempts. Components include user-mode OS, kernel, TrustZone, dm-crypt, key manager, and more. The project involves studying Android and Linux encryption mechanisms, creating a prototype key manager, defining protocols, and implementing separate components for Android apps and Linux kernel. Development platforms and languages include Android, Java, ANSI C, and Python. The project also addresses challenges such as minimal architectural changes and kernel-user mode communications. Conclusions highlight the importance of good design, modularization, minimizing kernel code, and early testing for successful implementation.
E N D
04.02.13 Secure File System -Final Meeting Industrial Project (234313) Prof. Michael Elad Students Noam Hershtig Yuri Bronshtein Supervisors Boris Dolgunov Constantine Elster
Agenda • Goals • Problem Description • High Level solution • Demo • Methodology • Technical • Team Work • Protocol • Conclusions
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
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.
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
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
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
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.
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)
Kernel TrustZone Protocol • User Management • addID • removeID • changePIN • setParams • getParams • unlockID • Key Retrieval • getKey • getStatus • loadKey • unloadKey • Misc. • getVersion (For backward compatibility) HW Support
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)
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