Automated Partitioning of
Android Applications for
Trusted Execution
Environments
Demil Omerovic
[Konstantin Rubinov, Lucia Rosculete, Tulika Mitra, Abhik Roychoudhury]
• Increase for services like
• online banking, premium content access, enterprise network
connection,..
• Adapting open software platforms, installing 3rd party
applications
• Potential entry point for attackers
• Countermeasure -> security through HW protection
• ARM TrustZone
• TEE
• TrustZone technology
• HW enforced security for authorized software
Background
• Approach facilitates application development and
tranformaion for TEE using ARM TrustZone
• Automatically partitionig existing Android app.
• Unidirectional TEE execution model
• Lack of standardization -> just few Andorid app. use this
technology
• TEE offers Trusted Applications (TAs)
• TA composed of TEE Commands
• Providing services to clients of the TA
• Enforcing confidentiality, integrity and access rights for
resources and data
• Each TA is independent and protected agianst ecosystem of
the application providers
• TAs can access secrue resources and services
• key management
• cryptography
• secure storage
• secure clock
• trusted display
• trusted virtual keyboard via TEE Internal API.
• Client
applications
running in the
rich OS can
access and
exchange data
with TAs via TEE
Client API.
PHASE 1
INPUT:
+Android App (binary)
+ Source:
Any method that reads and returns confidential data.
+ Sink:
Writes confidential data into a resource that can be accessed or
controlled outside the application.
Gray area -> external components
PHASE 2:
• Partitioning Framework
• Generates candidate code segments to be deployed as TEE
commands of a TA
• Algorithm: Selection of candidate program segments
PHASE 3:
• Grouping statements operating on conf. data
• Including:
• Code segments that manipulate OS-dependent code
• Confidential operations with overlapping contexts which
cannot be isolated
• Code fragments control-dependent on conf. data
PHASE 4:
• Assisting the engineer in transforming code fragments
into TEE Commands.
• Autom. generated code with TEE API calls for
establishing communication and parameters passing
btw normal and secure world
Gray area -> manually supported components
Partitioning Framework
• Starting with taint analysis enhanced with annotation of
taint-propagating statements with contextual
information
• Classifying the annotated statements and capture a
subset of the statements that will form a secure
partition to be deployed on TEE
• Then identifying groups of statements
• Resolve corner cases
• To maintain the flow of data through transfer
statements -> substitute confidential data references
with opaque references in the transformed application
Unique Opaque References
• Secure transfer of confidential data btw. normal world and
secure wolrd.
• Enable context-sensitive addressing of confidential data from
normal world in cases
when privileged statements can be reached from different contexts
or with data propagated from different sources.
• It´s an object reference that points to a unique Java object of a
required type, whereas object’s unique hash code serves as a
key to a hashtable of actual confidential data references stored
in TEE.
• A reference is created by allocating a new unique Java object
of a required type.
Unique Opaque References
• Avoiding compile and runtime errors by generating opaque
references of types as expected by the original implementation.
• Uniquely identify primitive types:
Applying minor code refactoring on the original application
Substitute tainted primitive variables with objects of primitive wrapper
classes.
• Opaque references do not conflict with polymorphic method
invocations.
Polymorphic method invocations with tainted base objects are marked as privileged
and deployed in TEE Commands
The runtime type of a base object (its opaque reference) does not affect the control
flow of the application.
• Input:
• List of sources
• List of sinks
• Interprocedural CFG (control-flow-graph)
• Worklist of methods
• Output:
• Map of candidate privileged stmts and associate
in/output taint sets
• Stage 1
• Extending the worklist
• Stage 2
• Classifying taint-propagation stmts
Implementation
General view of the components
Experimental Evaluation
• 6 real-world applications and a set of micro-benchmarks
on SierraTEE
• Standard Android Benchmarks
• -> Droidbench and SecuriBench
• Designed to check taint analysis for different cases of data
flow arising in secure context.
• -> Control-dependent
• Text extension from the authors for extracting the decision
part of the control structure as a TEE Command
• Total:
• Number of cases of confidential
data flow from source to sink
• Each benchmark obtained
through taint analysis
• Correct:
• Prototype framework applied
• Manually checked partition
• Results -> number of cases where
resulting transformation is
successful
• -> 86% of cases were
successfully partitioned
and transformed.
Case Study
• 6 widely-used open-source applications
• Google Authenticator
• Tiqr
• OpenKeychain
• Card.io
• Hash it!
• Pixelknot
• Summarize of the
contribution of commands
to the TCB size in SierraTEE
and the change to the
client code.
• It compared the TEE
command with the
execution time of the
original Java code in
Android OS but not
deployed to TEE.
• Table 3 -> computation in
TEE is faster than the
original application.
• Not surprising -> execution
in C code is usually faster
than execution in Java code.
• Most of the Overhead:
• Penalty for setting up TEE
context
• Establishing TEE session
• Switching between normal and
secure world
Thank you for your attention!
