MOBILE TRUSTED COMPUTING TEE Architecture TEE in mobile device

MOBILE TRUSTED COMPUTING TEE Architecture TEE in mobile device
TEE Architecture
MOBILE
TRUSTED COMPUTING
TEE = Trusted Execution Environment
2015-10-15 B. Smeets
EITN050
1
TEE in mobile device
2015-10-15 B. Smeets
EITN050
2
Read
Ansokan et al. Mobile Trusted Computing
In course literature list
2015-10-15 B. Smeets
EITN050
3
2015-10-15 B. Smeets
EITN050
4
Techniques to realize TEE
• Recall ARM TrustZone (Lect 6)
• Intel SGX
SGX - ENCLAVES
Software Guard eXtensions
From:
Innovative Instructions and Software Model for Isolated
Execution, Frank McKeen, Ilya Alexandrovich, Alex Berenzon,
Carlos Rozas, Hisham Shafi, Vedvyas Shanbhogue and Uday
Savagaonkar, Intel Corporation
2015-10-15 B. Smeets
EITN050
5
2015-10-15 B. Smeets
EITN050
6
Overview
Enclaves
• SGX in a new technology introduced in Intel chipsets
• Enclaves are isolated memory regions of code and data
• SGX architecture includes 17 new instructions, new
• One part of physical memory (RAM) is reserved for
processor structures and a new mode of execution.
enclaves and is called Enclave Page Cache (EPC)
• These include loading an enclave into protected memory,
access to resources via page table mappings, and
scheduling the execution of enclave enabled
application. Thus, system software still maintains
control as to what resources an enclave can access.
• An application can be encapsulated by a single enclave or
can be decomposed into smaller components, such
that only security critical components are placed into an
enclave.
2015-10-15 B. Smeets
EITN050
7
• EPC memory is encrypted in the main memory (RAM)
• EPC is managed by OS/VMM
• Trusted hardware consists of the CPU Die only
2015-10-15 B. Smeets
EITN050
8
Protected Mode (rings) protects
Protected Mode (rings) protects
App
execute
?
O
K
App
?
?
?
App
execute
O
K
Priviledged Code
Priviledged Code
OS from app
1 OS from App
But Apps are not protect
malware attacks on OS
2 And from other Apps
2015-10-15 B. Smeets
9
EITN050
Reduced attack surface with SGX
• Application gains ability to defend is own secrets
• Smaller attack suface (App+processor)
• Malware that subverts OS or VMM, BIOS, Driveers cannot steal
app secrets of
App
App
EITN050
EITN050
Protected execution environment embedded in a process
OS
Enclave
code
Enclclave
data
OS
Enclave
(DLL)
VMM
Enclclave
data
TCS (*n)
User process
Enclave
11
10
SGX Programming Environment
App
Hardware
2015-10-15 B. Smeets
2015-10-15 B. Smeets
2015-10-15 B. Smeets
• With its own code and data
• Provide confidentiality and
integrity protection
• With controlled entry points
• Support for multiple threads
• With full access to app
memory
TCS= Thread Control Structure
EITN050
12
Protection against Memory Snooping
1.
SYSTEM
MEMORY
Cores
2.
3.
Cache
attacks
4.
The Enclave Page Cache (EPC) is protected memory used to store enclave pages and
SGX structures. The EPC is divided into 4KB chunks called an EPC page. The
Enclave Page Cache Map (EPCM) is a protected structure used by the processor to
track the contents of the EPC.
2015-10-15 B. Smeets
EITN050
13
Attestation and Sealing
2015-10-15 B. Smeets
Security perimeter is
the CPU package
boundary
Data and code
unencrypted inside
CPU package
Data and code
outside CPU package
is encrypted/integrity
protected,
External memory
reads and bus
snoops tapping gives
access to encrypted
EITN050
14
EITN050
16
Creation
• SGX supports also attestation and sealing
2015-10-15 B. Smeets
EITN050
15
2015-10-15 B. Smeets
Using
Example: Life-cycle of enclave SW
Intel® SGX-enabled software does not ship with sensitive data. After the
software is installed, it contacts the service provider to have data remotely
provisioned to the enclave. .
2015-10-15 B. Smeets
EITN050
17
Example: Life-cycle of enclave SW
3.
Provisioning – The service provider assesses the trustworthiness
of the enclave. It uses the attestation to establish secure
communication and provision sensitive data to the enclave. Using
the secure channel, the service provider sends the data to the
enclave.
4.
Sealing/Unsealing – The enclave uses a persistent hardwarebased encryption key to securely encrypt and store its sensitive
data in a way that ensures the data can be retrieved only when the
trusted environment is restored.
5.
Software Upgrade – Enclave software updates might be required
by the service provider. To streamline the migration of data from an
older software version to the newer version, the software can
request seal keys from older versions to unseal the data and
request the new version’s seal so that the sealed data won’t be
available to previous versions of the software.
2015-10-15 B. Smeets
EITN050
19
1.
Enclave Launch – The untrusted
application launches the enclave
environment to protect the service
provider's software. While the enclave is
built, a secure log is recorded , the
enclave’s "Measurement.
2.
Attestation –The enclave contacts the
service provider to have its sensitive
data provisioned to the enclave. The
platform produces a secure assertion
that identifies the hardware environment
and the enclave.
2015-10-15 B. Smeets
EITN050
18
SGX Summary
• SGX provides any application the ability to isolate itself and to keep a
secret
• Provide capability using new processor eXtentions
• Application can support multiple enclaves
• Provides integrity and confidentiality
• Resists hardware attacks
• Prevent SW attacks (also for priviledged software and SMM
• Applications run within OS
• Application writing is essentially as without SGX
• Open to all developers
• Resource managed by SW
• HW components are supported in a driver or OS
2015-10-15 B. Smeets
EITN050
20
refs
• Innovative Instructions and Software Model for Isolated
Execution, Frank McKeen, Ilya Alexandrovich, Alex
Berenzon, Carlos Rozas, Hisham Shafi, Vedvyas
Shanbhogue and Uday Savagaonkar, Intel Corporation
CAN WE TRUST ANDROID AND
IOS PHONES?
• See also Youtube video on SGX (in Literature list)
• Innovative Technology for CPU Based Attestation and
Sealing, Ittai Anati, Shay Gueron, Simon P Johnson,
Vincent R Scarlata, Intel Corporation
2015-10-15 B. Smeets
EITN050
21
Overview
2015-10-15 B. Smeets
EITN050
22
Android and iOS: what is it?
• Android and iOS: what is it?
• A platform for mobile devices using open source (but not
• Security in Android
• Foundation for security
• Interaction and access-control in Android
• Permissions
• Development is under control of Open Handset Alliance
• iOS: differences (security wise) compared to Android
• Everybody can install apps
drivers for hardware and modem interface library)
• Developers can use public development tools (SDK and
• Can we trust smartphones?
• Current views
• App trust through reputation
• BYOD
• App dynamics
2015-10-15 B. Smeets
Source code: http://source.android.com
•
NDK)
o
EITN050
23
see : http://developer.android.com
2015-10-15 B. Smeets
EITN050
24
Android and iOS: what is it?
Android: what is it ?
• Modified Linux kernel
• A platform for mobile devices using proprietary code
• Uses more than 90 open source libraries
• Integrated WebKit based browser
• SQLite database for structured data storage
• Development is under control of Apple
• OpenSSL
• BouncyCastle
• Apps can be installed from special (trusted?) source(s)
• libc based on OpenBSD
• Apache Harmony and Apache HttpClient
• Support for many common sound-, video- and image codecs
• Developers can use public development tools SDK
• See for example:
•
https://developer.apple.com/devcenter/ios/checklist//
• API support for implementing control and I/O to a cellular modem
• Data communication: Bluetooth, EDGE, 3G, WIFI
• Periferiral : camera, video, GPS, compass, accelerometer, speaker
microphone(s), vibrator
• Etc, etc
2015-10-15 B. Smeets
EITN050
25
2015-10-15 B. Smeets
EITN050
26
EITN050
28
Android components and stack
“THE BASICS”
IN ANDROID
2015-10-15 B. Smeets
EITN050
27
2015-10-15 B. Smeets
Android security – basics
Dalvik
• Applications can be written in a Java-like language and run in
• Dalvik Virtual Machine
• JVM => .class
• DVM => .dex
an own ART VM- instantiation. Also Native code can be used
• Interaction between applications is constrained through a
special AP and by giving each application an own (Linux)
identity.
Constant Pool:
-References to other classes
-Method names
Class
Definition:
-Numerical
constants
-Access flags
-Class names
• Dalvik dx compiler
• Applications developed on other platforms cannot
Data:
-Method code
-Info related to methods
-Variables
execute
• Through permissions one controls access/use of resources.
ART = Android Run Time is replacing Dalvik used in earlier
From: A Study of Android Application Security, Enck et al
2015-10-15 B. Smeets
EITN050
29
2015-10-15 B. Smeets
EITN050
Fundament: Android Package
(APK) file structure
ART (Android RunTime)
30
HelloWorld.apk
/META-INF
• MANIFEST.mf - sha-1 digest for each file of the applicationen
• HelloWorld.sf - sha-1 digest of each file (based on info from
Manifest.mf)
• HelloWorld.rsa - PKCS#7 RSA signature of HelloWorld.sf
/res
• Application’s resource files
/
• AndroidManifest.xml – app information to Android system
• classes.dex - compiled Android Dalvik app
• resources.arsc – table on all resources in the application
ON ART: https://www.youtube.com/watch?v=USgXkI-NRPo
2015-10-15 B. Smeets
EITN050
31
2015-10-15 B. Smeets
EITN050
32
Fundament: Processes and Threads
Fundament: Android applications are built
according a common design pattern
• Each application gets it’s own Linux process
• Each component runs per default in the main thread of
the process
• Activities form the presentation layer; one for each
•
•
• One can create threads for long running processes
• Threads can be created by the app through standard Java
•
Thread objects
•
2015-10-15 B. Smeets
33
EITN050
Android Applications - Example
FoxSearch-app
StartFoxPosition
Broadcast receiver
FoxSearchControl
Activity
2015-10-15 B. Smeets
34
EITN050
Android Applications - Example
FoxMap-app
FoxPosition
StartFoxSearch
Service
Broadcast receiver
FoxMap
Activity
ShowFoxControl
FoxPositions
Activity
ContentProvider
FoxSearchControl : UI for starta/stop searchfunction
FoxPosition: Contacts external localisation server
FoxPositions: Save last positions
2015-10-15 B. Smeets
screen and Views make the UI for an activity.
Intents specify what is to be done
Services are background processeses with no UI:
update data and trigger events
Broadcast receivers offer message mailboxes from
other applications and can trigger intents that start an
application
Content providers provide data/resources
EITN050
StartFoxPosition
Broadcast receiver
FoxSearchControl
Activity
FoxPosition
StartFoxSearch
Service
Broadcast receiver
FoxMap
Activity
ShowFoxControl
FoxPositions
Activity
ContentProvider
FoxSearchControl : UI for starta/stop searchfunction
FoxPosition: Contacts external localisation server
FoxPositions: Save last positions
35
2015-10-15 B. Smeets
EITN050
36
Program interaction in Android
Example - Interaction
Broadcast intent
FoxSearch-app
FoxMap-app
• Most interactions in Android are inter-component
StartFoxPosition
interactions (ICC):
FoxPosition
read/write
• Intents: message object with target address and data
Start/stop
FoxSearchControl
• Actions: actual process for inter-component interaction
Broadcast
intent
StartFoxSearch
FoxMap
read
Start/stop
FoxPositions
ShowFoxControl
• Android’s philosophy is that applications can make (part
of) their APIs accessible for other applications. This is
called exporting components
2015-10-15 B. Smeets
EITN050
37
Most interactions in Android are inter-component interactions
2015-10-15 B. Smeets
EITN050
Intents – implicit vs explicit
Intent Filters
• Implicit Intents
• Simply put a broadcast for service:
• To inform the system which implicit intents they can
38
handle, activities, services, and broadcast receivers can
have one or more intent filters.
• Explicit intents:
• Dedicated to a destination
• Each filter describes a capability of the component, a set
of intents that the component is willing to receive. It filters
intents of a desired type, while filtering out unwanted
intents
2015-10-15 B. Smeets
EITN050
39
2015-10-15 B. Smeets
EITN050
40
Attacks
Type 1 – Broadcast Theft
• Only consider attacks on exported components
• Broadcasts (via implicit Intent) vulnerable to eavesdropping
• Consider non-exported components and exported
components with a Signature (or higher) permission
level to be private and not susceptible to the below
attacks
• Type 1 - Intents sent to the wrong application
• Can leak data
• Broadcast theft, activity and service hijacking
• Type 2 – Receiving external Intents
• Data corruption, code injection
• Malicious broadcast injection, malicious activity launch,
malicious service launch
2015-10-15 B. Smeets
EITN050
41
and denial of service attacks
• Eavesdropping
• A public broadcast can be intercepted by attacker because a loose
intent filter leaves a hole and no confirmation checking
2015-10-15 B. Smeets
EITN050
42
EITN050
44
Some Recommendations
• Use caution with implicit Intents and exporting
•
•
•
•
•
Components
Use explicit Intents to send private data
Use explicit Intents for internal communication
Returned results should be checked for authenticity
Avoid exporting Components
The same Component should not handle both internal
and external Intents
2015-10-15 B. Smeets
EITN050
43
APPLICATION
SECURITY
Access control
Runtime protection
2015-10-15 B. Smeets
Access control in Android
• Android protects applications att
• (Linux) system level and
• inter-component communication level:
User ID Table
0
Permissions
• Each application runs as a unique Linux user under its
own identity (user ID) which limits the damage an
application program error can inflict on other applications :
system
1000-1999
Root: Only few root processeses e.g. init, runtime, Zygote,
2000-2999
System services
ADB and other debug services
3000-3999
Android services that the kernal is aware
... 9999
• Linux access control (as usual) keeps apps apart
• User ID is (locally) assigned during app installation
2015-10-15 B. Smeets
EITN050
10000 …
45
Apps get user ID
2015-10-15 B. Smeets
10000
EITN050
46
Access control in Android
Access control
• Android has implemented a comprehensive mechanism
for access control.
SysResource
• The use of signed applications is an important ingredient
Inter-component access(ICC) control
Middleware
Linux
in this BUT NOT to assure the (correct) origin of the
applications but to assure that the assignment of unique
user IDs cannot be spoofed.
User: app_100
User: app_105
Usr/home/FoxPositioner
Usr/home/FoxKarta
2015-10-15 B. Smeets
EITN050
• We look at signed applications first
47
2015-10-15 B. Smeets
EITN050
48
Signed applications
PKI structure and access control
without signature permissions
• To distinguish an application. Application signing by self-
signed certificates is used.
Note I do not write “identify”
Spotify
• Androids Distribution does not accept app signed with the
SpotifySignatur
FoxMap
MYSignature
default key in the SDK
• Hence it is a policy issue if known (SDK) keys are accepted for an
app.
• In vanilla Android the signatures have no security value if
• Two applications can share the same user ID if they are
signed by using the same key/certificate (should normally
be avoided)
signature permissions are not used.
• Remember: signature is in this case only used to tell
applications apart.
2015-10-15 B. Smeets
EITN050
49
with signature permissions
Android distinguishes four core platforms components each
having their own key
• Platform: a key for packages that are part of the core
platform.
• Shared: a key for things that are shared in the home/contacts
process.
• Media: a key for packages that are part of the media/download
system.
• Testkey/releasekey (Application) : the default key to sign
with if not otherwise specified
EITN050
EITN050
50
Access control – the problem
PKI structure and access control
2015-10-15 B. Smeets
2015-10-15 B. Smeets
51
• The Android API consists of 1665 classes with a total of
16732 public and private methods
• Number of Permissions
Checks. There are 1244 Android
.
API calls with permission checks, which is 6% of all API
methods (including hidden and private methods). In
addition the manufacturer might have added APIs with
permission checks.
Old data but it still describes the
current situation
2015-10-15 B. Smeets
EITN050
52
Using Permissions Configuration of manifest
• A basic Android application has no permissions associated with it,
meaning it can not do anything that would adversely impact the user
experience or any data on the device.
• To get access to protected features of the device the application
needs to declare which permission it needs. This is done in the
manifest.xml file of the application.
• Applications not declaring needed permission will in most cases get a
SecurityException when exercising a not allowed permission failure.
Permissions (1/3)
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" >
<uses-permission android:name="android.permission.RECEIVE_SMS"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous" />
</manifest>
• Permissions are defined in a text string in the manifest file
Very flexible but doubtful if user realy understands what is going to happen. There are meny predefined permissions
e.g. Manifest.permission_group
• The application gets its requested permision at time of
installation.
For example, an application that needs to monitor incoming SMS messages would specify:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" >
• Depending on the API, its permissions and who has
<uses-permission android:name="android.permission.RECEIVE_SMS"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous" />
signed the application the user has to approve the use of
the access to the requested API..
</manifest>
2015-10-15 B. Smeets
Permissions (2/3)
EITN050
54
Permissions (3/3)
• ICC is set att installation time and can not be altered after
that: compare to mandatory access control (MAC).
• When updating an application the same key/certificate
must be used
• Access errors can be signaled to the application but not
allows. Normally they will appear in the system log.
Permission control happens in the system processes
2015-10-15 B. Smeets
EITN050
55
2015-10-15 B. Smeets
EITN050
56
Permission model: protection levels
Android 2.2 had already 134 permissions divided in 4 levels
• Files normally belong to a user ID. (on SD cards it gets
tricky though)
• normal:
gives applications automatically access, e.g. SET_WALPAPPER
• dangerous:
use of the API is with risk and requires users consent
• signature:
access allowed only if the app is signed with same
certificate as the app that has declared the permission
• signatureOrSystem:
as above but can be used freely by packages in the
system partition (careful here)
2015-10-15 B. Smeets
User ID and File access
EITN050
57
Use of permissions- investigation
• Remember Max two different Android packages kan get
the same user ID (signerad against same certificate and
in the manifestet we have ”sharedUserId” attribute).
• One can set MODE_WORLD_READABLE and/or
MODE_WORLD_WRITEABLE flags on a file so att alla
apps are allowed to read/write from/to the file.
2015-10-15 B. Smeets
EITN050
58
Common permissions
• In a study of 940 Android applications from the Android
Market one found that about one-third of applications are
overprivileged.
• The overprivileged applications generally request few
extra privileges:
• more than half only contain one extra permission,
• and only 6% request more than four unnecessary permissions.
Android Permissions Demystified
Adrienne Porter Felt, et al 2011.
2015-10-15 B. Smeets
EITN050
59
2015-10-15 B. Smeets
EITN050
60
File Encryption
Overpriviledged apps
• Android 3.0+ provides full filesystem encryption, so all
user data can be encrypted in the kernel
• For a lost or stolen device, full filesystem encryption on
Android devices uses the device password to protect the
encryption key, so modifying the bootloader or operating
system is not sufficient to access user data without the
user’s device password.
2015-10-15 B. Smeets
EITN050
61
2015-10-15 B. Smeets
EITN050
62
block oriented storage
Runtime protection
DM-VERITY
• Address Space Layout Randomization (ASLR) is a known
• Transparent block-level integrity protection solution for read-
technique that aims to reduce the possibility of mounting
attacks that exploit ways to get access to desired memory
locations through randomization. Attackers are with ASLR in
place faced with a much harder problem to find thus address
locations. This reduces, for example, the possibility to make a
buffer overflow condition into something useful in an attack.
ASLR is introduced in Android 4.0
• ARM NX Since many Android devices use ARM type CPUs the
not execute (NX) feature for data reduces the risk of exploits
where stored data is executed. Using the NX bit data can be
tagged as not executable until, say, a successful verification
has been carried out on which the NX status is removed.
Android supports HW based NX since the Ice cream sandwich
release.
only partitions
• dm-verity is a device mapper target
• Uses hash-tree
• Calculates a hash of every block
• Stores hashes in the additional block and calculates hash of that block
• Final hash – root hash – hash of the top level hash-block
• Root hash is passed as a target parameter and protected by signature.
A public key is included on the boot partition, which must be verified
externally. That key is used to verify the signature for that hash.
• Update can be done only by overwriting entire partition
• Used in ChromeOS, KitKat 4.4, and some Unix systems to
protect read-only partition
http://source.android.com/devices/tech/security/verifiedboot/
2015-10-15 B. Smeets
EITN050
63
2015-10-15 B. Smeets
EITN050
64
A possible addition:
Linux: IMA Integrity Measure Architecture
The goals of the kernel integrity subsystem are to detect if files have
been accidentally or maliciously altered, both remotely and locally,
appraise a file's measurement against a "good" value stored as an
extended attribute, and enforce local file integrity. These goals are
complementary to Mandatory Access Control(MAC) protections
provided by LSM modules, such as SElinux and Smack, which,
depending on policy, can attempt to protect file integrity. The following
modules provide several integrity functions:
IMPLEMENTATION
• Collect - measure a file before it is accessed.
• Store - add the measurement to a kernel resident list and, if a
hardware Trusted Platform Module (TPM) is present, extend the IMA
PCR
• Attest -if present, use the TPM to sign the IMA PCR value, to allow a
remote validation of the measurement list.
• Appraise - enforce local validation of a measurement against a 'good'
value stored in an extended attribute of the file.
• Protect - protect a file's security extended attributes
The first three functions were introduced with Integrity Measurement
Architecture (IMA) in 2.6.30. The EVM/IMA-appraisal patches add
support for the last two features.
Source: http://linux-ima.sourceforge.net/
2015-10-15 B. Smeets
EITN050
65
2015-10-15 B. Smeets
EITN050
Android’s platform security
Weak and strong points
All Android product vendors do make adoptions to Android
when integrating Androiod to their hardware
• Secure boot process: which components that are
verified and how differ among vendors and products
• Vendors try to limit access to root: some suceed better
than others, eg Knox by Samsung
• Most products that use a mobile network modem have
modem hardware that is isolated from the application
processor subsystem. The modem is controled via the RIL
(Radio Interface Layer) which is in practice a proprietary
library with a standard API
• Very good isolation of APPs.
2015-10-15 B. Smeets
EITN050
67
66
• Very good control of what can be permitted and what not but it is
•
•
•
•
questionable if the user can really handle it. Careful user may select
good apps based on reputation.
Recent Android version have file system encryption (but not always
SD card file encryption is supported)
Freedom to download reduces incentive to root the device but also
increases risk of downloading malware.
APPs via Google play are only screened by a tool. This is not a
device but more a ecosystem issue.
Security of an Android device (even with same OS version) varies
depending on manufacturer’s integration and choice of platform
2015-10-15 B. Smeets
EITN050
68
iOS – remark on material
• Since Apple has not revealed all iOS details we have less
exact knowledge how things work and in some cases we
rely on people that reported on their analysis and reverse
engineering work
IOS
• Here we treat iOS through comparison with Android
2015-10-15 B. Smeets
EITN050
69
2015-10-15 B. Smeets
EITN050
70
Objectives of several Apple devices
iOS Stack
• Consistent, fluent and simple user interfaces
• iOS uses XNU a free and open source operating system kernel also utilized in Mac OS X. XNU is a
• Integrity protection of the operating system and updates
• Restriction of third party software
• Restriction of source
• Restriction of software capabilities
• Restriction of content
• Restriction of payment models
•
•
•
•
• Protecting the user’s data is not a primary design goal
but protection level is increasing!
• It’s primarily designed as a consumer device – not a
corporate user device
2015-10-15 B. Smeets
EITN050
71
hybrid kernel based on the Mach 3.0 microkernel modified for performance and other reasons to
include components from Free BSD
The core (Core OS) of IOS/Mac OS X is called Darwin (=open source) and besides the kernel XNU
includes facilities like the I/O Kit – a modular dynamic device driver framework, the Virtual File
System (VFS), and networking support.
The main application environment for both IOS and Mac OS X is called Cocoa, and this includes the
Objective-C libraries (a.k.a. frameworks), APIs and runtimes.
Both IOS and Mac OS X require the use of the Foundation framework which includes basic object
management such as memory management and notifications, object wrappers for programmatic
primitives, etc. The main difference between applications in iOS and Mac OS X lies in the user
interface frameworks.
The AppKit and UIKit frameworks
contain the objects used to implement
a graphical event-driven user interface
in Cocoa applications .
FreeBSD: POSIX API, basic security policies, user and group ids, permissions, cryptographic framework, mandatory access control, among others.
2015-10-15 B. Smeets
EITN050
72
iOS sandboxing
iOS sandboxing – cont’d
• All applications in iOS run as user “mobile”.
• Therefore iOS applies fine-grained process runtime security policies
• Some apps are built-in/preinstalled into the device. These apps have the
specifying file and system access restrictions for the applications.
same User ID (501, mobile) as the 3rd party application but in different
sandboxes.
• iOS assigns each installed third party application (incl. preferences and data)
a home catalogue1 (or container) of the file system. By default the application
may only read and write files within their container, but more specific
permissions are detailed in the sandbox profile. When an application is
launched, its sandbox profile is determined by so-called profile entitlements.
• IOS only supports static sandbox profiles,
• there are 35 custom made profiles usually named by the single built-in
application that uses them (MobileMail, MobileSafari, MobileSMS, …). Third-party
applications are placed in a container sandbox.
The XNU Sandbox kernel extension (a.k.a.
“Seatbelt”) is implemented as a policy module
for the TrustedBSD Mandatory Access
Control (MAC) framework. The Sandbox
extension is a loadable kernel module that
installs MAC policy hooks for accessing
system objects and resources.
Sandbox profile
(entitlements)
1 /var/mobile/Applications/UUID, where the application Universally Unique IDentifier (UUID) is
randomly generated when the application is installed.
2015-10-15 B. Smeets
73
EITN050
iOS Access control (1/2)
2015-10-15 B. Smeets
EITN050
74
iOS Access control (2/2)
Access control is based on sandboxing and MAC (TrustedBSD) profiles.
The “container” sandbox profile defines access permissions of 3rd party
applications and is a white-list that in general restricts access to the
application’s own home directory but includes permissions to access
• some necessary system files, e.g.
• random number generation & crypto functions
• address book (read and write)
• photos and music (read). Note: Geotagged photos require app to have
user granted permission to access location data.
• customizations related to carriers including voice mail numbers, MMS
and APN settings etc. (read)
Furthermore
• outbound network connections are allowed,
• applications are allowed to execute binaries from within
their application bundle, and
• applications are allowed to create sockets to receive
kernel events.
• the Documents/Inbox directory (read and delete files related to the app,
e.g. viewing mail attachment documents with the associated application)
• keyboard cache (read), presumably to enable auto-completion
Privacy concerns
2015-10-15 B. Smeets
EITN050
75
2015-10-15 B. Smeets
EITN050
76
Entitlements and Provisioning Profile
iOS and certificates
• The execution of apps is controlled by a Provisioning Profile (PP), which is an
• Apple uses X.509 certificates for signature verification.
Apple signed .plist (“property list”) .
• The PP defines which entitlements the developer is permitted to give to apps
he/she signs. In this way access conditions can be modified from their
defaults
• Examples of entitlements are:
Typically, there is a certificate chain, like:
• Apple Root CA
• Some intermediate CA
• yet another intermediate CA
• End-Entity
• get-task-allow which allows debugging (not applicable to applications that
are being distributed)
• keychain-access-groups which defines a list of Keychain namespaces
the applications are allowed to access. This allows apps to share Keychain
items
• seatbelt-profile which specifies which built-in sandbox profile to apply to
the process
2015-10-15 B. Smeets
EITN050
77
• Disassembling the bootloader (2012) and looking at the
X.509 implementation revealed that the code does not
check X.509v3 basic constraints. (still true ?, 2014)
2015-10-15 B. Smeets
78
EITN050
Code signing and verification
Built-in trusted boot
All IOS executable binaries and applications must be signed against a trusted
certi cate.
The iPhone products implement a trusted boot scheme. The root of trust is an Apple root
certificate stored in the boot ROM. Firmware images are stored encrypted and signed.
Apple Root CA
While Apple’s certi cates are inherently trusted, any other certi cates must be installed via a properly signed
Provisioning Pro le (PP). The PP also contains any specific entitlements deviating from default for the App.
The PKI scheme in use has three levels
There are three different boot modes:
Verification: The CodeDirectory (CD) is a resource (in the application’s master
directory) consisting of a versioned header followed by an array of hashes,
including pages of the main executable. Before an application is launched, the
kernel verifies the signature of the CD against the trust caches.
The kernel contains a static set of known CD hashes for built in system binaries
(static trust cache) and a dynamic list (cache) of CD hashes of all verified
executables executed since boot.
Apple Secure Boot
Certification
<processor> Secure Boot
• In the Normal boot mode the trusted boot sequence is:
Boot ROM
LowLevelBootloader (LLB)
Iboot
Kernel.
• Recovery mode is a fail-safe option in the lboot bootloader that allows uploading of a RAM
disk and reflashing of the device.
• DFU mode is a fall-back option that allows to restore from a given boot state. DFU has a
slightly different boot sequence.
DFU and Recovery modes are accessible over the USB interface.
iPhone jailbreaking targets mostly the circumvention of this trusted boot (see, e.g., iPhone Dev
Team)
Thus here the signature has the purpose to identify the app
2015-10-15 B. Smeets
EITN050
79
2015-10-15 B. Smeets
EITN050
80
File encryption
iPhone iOS vs Android
• iOS implements a comprehensive file encryption scheme called
DataProtection using an hw AES engine
• By setting up a device passcode, the user automatically enables Data
Protection.
• Every time a file on the data partition is created a new 256-bit key (the “per-
file” key) is created and gives it to the AES engine, which uses the key to
encrypt (AES CBC) the file as it is written to flash memory. The CBC
initialization vector is the output of a linear feedback shift register (LFSR)
calculated with the block offset into the file, encrypted with the SHA-1 hash of
the per-file key.
Similarities
• Unix/Linux based, ASLR, NX protection
• Use of profiled open source libs
• SDK tools freely available
• APP installation packages must be
signed
• APPs and their data are isolated
• Permission model present
• Native browser uses webKit
• More details are known
2015-10-15 B. Smeets
EITN050
81
2015-10-15 B. Smeets
Differences
• Kernel protection differences
• Programming languages differ
• Signing is used to check origin of APP
installation packages (e.g. limit to come
from specific source)
• iOS uses sandboxing for isolation, most
apps have same user id (501, mobile), 35
sandbox profiles.
• iOS permission are more handled through
fixed policies. Very few by user consent.
• Screening of APPs before releasing for
deployment (is not a device issue though)
• iOS has more developed data/file
encryption support
• Trusted boot in iPhones which in Android
phones is vendor specific
• iPhone APPs are DRM protected during
delivery and on the device
EITN050
82
Rank of Top Mobile Threats
October 4, 2012 – The Cloud Security Alliance (CSA) Mobile Working Group today released
findings from a new survey that calls out the specific security concerns enterprise executives
say are the real and looming threats as it relates to mobile device security in the enterprise
CAN WE TRUST
SMARTPHONES ?
And the result is ….
2015-10-15 B. Smeets
EITN050
83
1.
Data loss from lost, stolen or decommissioned devices
2.
Information-stealing mobile malware
3.
Data loss and data leakage through poorly written third-party applications
4.
Vulnerabilities within devices, OS, design and third-party applications. Insecure Wifi
network or rogue access points
5.
Insecure WiFi, network access and rogue access points.
6.
Insecure or rogue marketplaces
7.
Insufficient management tools, capabilities and access to APIs (includes personas).
8.
NFC and proximity-based hacking.
2015-10-15 B. Smeets
EITN050
84
Malware statistic
Apple’s screening of apps before
placing them in App Store pays off.
So in Q1 2014
• Compared to PC-based threats, the number of mobile
malware is very small. Android is popular among malware
producers.
F-Secure Mobile Threat report
Q1 2014:
2015-10-15 B. Smeets
EITN050
85
2015-10-15 B. Smeets
EITN050
86
EITN050
88
References
• Android developer site pages: (too many to list here)
• Understanding Android Security, William Enck, et. al, Security &
Privacy January/February 2009
• Developing Secure Mobile Applications For Android, iSEC Partners
•
•
•
•
2008
Android Permissions Demystified, Adrienne Porter Felt, et al 2011.
iOS Security, Apple Inc, May 2012
https://media.blackhat.com/bh-us
11/DaiZovi/BH_US_11_DaiZovi_iOS_Security_WP.pdf
http://esec-lab.sogeti.com/dotclear/public/publications/11hitbamsterdam-iphonedataprotection.pdf
2015-10-15 B. Smeets
EITN050
87
BYOD….
Corporate use of smartphones
Security perspective
2015-10-15 B. Smeets
BYOD trend
Examples:
• Companies and organizations allow increasing their
• Define profiles that govern the behaviour: private or work
employees to use their own devices as work platforms.
usage
• Obviously this reduces companies cost of device (PC,
• Samsung Knox
phone, etc) hardware
• Mostly people are satisfied with using their own device
• Android at work
• Blackberry
BUT
• security wise BYOD is problematic. How to enforce
security policies
2015-10-15 B. Smeets
EITN050
89
References
• Android developer site pages: (too many to list here)
• Understanding Android Security, William Enck, et. al, Security &
Privacy January/February 2009
• Developing Secure Mobile Applications For Android, iSEC Partners
•
•
•
•
2008
Android Permissions Demystified, Adrienne Porter Felt, et al 2011.
iOS Security, Apple Inc, May 2012
https://media.blackhat.com/bh-us
11/DaiZovi/BH_US_11_DaiZovi_iOS_Security_WP.pdf
http://esec-lab.sogeti.com/dotclear/public/publications/11hitbamsterdam-iphonedataprotection.pdf
2015-10-15 B. Smeets
EITN050
91
2015-10-15 B. Smeets
EITN050
90
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement