Android Security Internals

2/28/2019 Android Security Internals
ﬁle:///home/karim/opersys-dev/presentations/ewc-2019/android-security-internals/slides-main.html#/ 1/68
Android Security InternalsAndroid Security Internals
Embedded World 2019Embedded World 2019

CC-BY-SA 3.0 - Attribution requirements and misc.,
PLEASE READ:
This slide must remain as-is in this specific location (slide #1),
everything else you are free to change; including the logo :-)
Use of figures in other documents must feature the below "Originals
at" URL immediately under that figure and the below copyright
notice where appropriate.
You are FORBIDDEN from using the default "About" slide as-is or
any of its contents.
Copyright (C) 2019, Opersys inc.
These slides created by: Karim Yaghmour
Originals at: http://www.opersys.com/training/

AboutAbout

Introduced Linux Trace Toolkit in 1999
Originated Adeos and relayfs
(kernel/relay.c)
Training, Custom Dev, Consulting, ...

TopicsTopics
1. The Chain / Root of trust
2. SoC Internals
3. General System Architecture
4. Secure Booting
5. TrustZone & Trust Execution Environments
6. HLOS / Linux
7. SELinux / SEAndroid
8. AOSP User-Space
9. Cloud & Network

The Chain / Root of trustThe Chain / Root of trust
Silicon
PCB
Software, etc.

Taken from "Thompson -- Reflections on Trusting Trust -- Turing Award
Lecture, 1984"

/ Also at
/ Also at and
DDR analysis tools: , ,
Logic analyzer ( )
JTAG tools: , , ...
UART soldering -- see Ch13 "Android Hacker's Handbook"
,
iPhone chip "data recovery" tools: , ,
,
Chip programmers (and readers):
JTAGulator Adafruit
Bus Pirate Sparkfun Adafruit
Teledyne/Lecroy EPN Solutions
FuturePlus Systems
saleae
Lauterbach Flyswatter 2
Interposer film chip sockets
AliExpress AliExpress
pinterest pinterest
xeltek

USB analysis/hacking tools:
Any dev board w/ USB client interface running Linux
Cold boot attacks:
DMA attacks
And many, many more ...
Facedancer 2.0
Total phase
Wireshark
IDA
FROST
"Reverse engineering the PSP"

Software, etc.Software, etc.
Early boot software
Trusted environment
HLOS/Linux
Android
Apps
Network
Cloud services
OTA

Soc InternalsSoc Internals
Overall arch
Resource power management
AXI/AHB/Amba/APB
Crypto hardware
eFuses
Internal memory
"Secure" bit
Protection units
Cores/TZ
Modem
Other cores

Taken from "ARM -- TrustZone Ready Program"

Taken from "ARM -- Building a Secure System using TrustZone Technology"

Taken from "ARM -- ARM1176JZ-S Technical Reference Manual"

Taken from "LCU13: An Introduction to ARM Trusted Firmware"

VulnerabilitiesVulnerabilities
Probing available pins
Tapping into JTAG / test points
Side channel attacks:
Cache attacks
Timing attacks
Power-monitoring attacks
Electromagnetic attacks
Acoustic cryptanalysis
Differential fault analysis
Data ramanence
Fault attacks (row hammer)
Optical
Decapsulation

Secure BootingSecure Booting
Overall flow
Execution location
Bootloader

1. Overall flow1. Overall flow

Taken from "LCU13: Deep Dive into ARM Trusted Firmware"

2. Execution Location2. Execution Location
PBL & RPM FW: RPM ROM and RPM RAM
SBL1: OCM
SBL2: OCM
TZ Image: OCM
SBL3: System RAM
APPSBL (bootloader): System RAM
HLOS: System RAM

3. Bootloader / LK3. Bootloader / LK
Google doesn't mandate a specific bootloader
Vendors can use whatever they want, including U-Boot
Many Android bootloaders based on "Little Kernel":
15-20KB in size on ARM
Almost NO traces of Android functionality in main LK
Highly customized in every case
SoC vendor LKs have the goodies -- Linaro sample:
Detailed internals explanation for 410E/8016E:
https://github.com/littlekernel/lk/wiki/Introduction
https://git.linaro.org/landing-
teams/working/qualcomm/lk.git/
https://developer.qualcomm.com/download/db410c/little-
kernel-boot-loader-overview.pdf

Locked vs. unlocked:
Locked: Device cannot be flashed, verif OEM or user key
Unlocked: Device freely flashable, no sig verif done
Lock state communicated to TEE and persisted:
CRUCIAL: ties TEE key instantiation to lock state
Boot image sig verification -- built-in key
Bootloader signed by manufacturer key
Build system:
Android-like
Allows unmodified inclusion into bigger project
"apps" listed in table, started as threads
LK APIs provide: wait queues, mutexes, semaphores, timers, events,
threads

TrustZone & Trusted Execution EnvironmentsTrustZone & Trusted Execution Environments
Issues
Hardware-backing
Secure monitor
TEE services
TEEs on the market
TAs
REE communication
Secure storage
Attestation
Example Trusty TAs

1. Issues1. Issues
Lack of public documentation
Some common GP devices have disabled TZ
Linaro TZ emulator:
Optee on Hikey
"Arm TrustZone in QEMU"
"Testing QEMU Arm TrustZone"

2. Hardware-backing2. Hardware-backing
Processor always boots in secure mode
Peripherals boot in most secure state
Peripherals can be configured to be secure
"Secure flag" communicated across internal buses
Caches are security-aware
Secure interrupts
Internal memory:
SRAM
Reset on reboot (avoid coldboot attacks)

Taken from "ARM -- Fundamentals of HW-based Security"

3. Secure monitor3. Secure monitor
Must use SMC call to enter into monitor
SMC call only possible from kernel, not user-space
Switches to ARM Trusted Firmware (ATF)
ATF ensures the switch to the TZ OS
Register switching and saving done on call

Taken from "LCA 2014 -- Adopting ARM Trusted Firmware"

4. TEE services4. TEE services
Completely separate execution from HLOS/Linux
OS with APIs, like other OSes:
Scheduling
IPC
Communication with HLOS
Secure storage
Not very open world
Some systems run two TEEs in the same time

5. TEEs on the market5. TEEs on the market
Qualcomm Secure Execution Environment (QSEE):
Looks like it's widely used
Trustonic/Kinibi
This one too
:
Google OSS TEE for Android
Based on Little Kernel
Used in some real products
:
Also OSS
Trusty
Optee

6. Trusted Applications6. Trusted Applications
Actual applications like any other OS
Can be loaded from HLOS by request to TEE
Isolated from one-another like HLOS processes
Ever-increasing number of them

7. REE communication7. REE communication
Done via driver on the HLOS/Linux side
Might involve a user-space daemon
TA<->kernel communication done in RAM

8. Secure storage / RPMB8. Secure storage / RPMB
Taken from "ARM -- Fundamentals of HW-based Security"

9. Example Trusty TAs9. Example Trusty TAs
See
AVB resource manager
Keymaster
Gatekeeper
Fingerprint
Secure storage service
Access-controlled NVRAM
https://android.googlesource.com/trusty/app/

HLOS / Linux KernelHLOS / Linux Kernel
Security-related built-in mechanisms
Verified boot
Full disk encryption
File-based encryption

1. Security-related built-in mechanisms1. Security-related built-in mechanisms
Process isolation
DAC
LSM hooks
Device Mapper
Module signing
seccomp
ASLR
Keyring
Crypto API
HW-accelerated crypto

2. Verified Boot2. Verified Boot

3. Full Disk Encryption3. Full Disk Encryption
Taken from "ELCE 2017 -- Protecting your system from the scum of the
universe"

4. File-Based Encryption4. File-Based Encryption
Taken from "ELCE 2017 -- Protecting your system from the scum of the
universe"

SELinux / SEAndroidSELinux / SEAndroid
Technology generalities
Functionality generalities
Core Policies
Linux integration
Linux Security Module Hooks
Current Linux implementation

1. Technology generalities1. Technology generalities
Tremendous amount of unreferenced and undocumented baggage
Quite a few concepts and tenets required to begin understanding
Lumps together several key concepts that were developed and
discussed independently within security research communities over
several years/decades.
Almost invariably presented with no reference to its historical roots
Nomenclature has evolved over the years
Different people refer to different parts using different terms
Own authors/maintainers use several terms for same things
SEAndroid/SELinux have built-in simplifications over source
designs
Vast majority of explanations require absorbing semantic space as-is
Some explanations rely on over-simplified analogies
"life is too short to enable SELinux" -- Ted Ts'o

From: Linus Torvalds
Newsgroups: fa.linux.kernel
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change
Date: Wed, 03 Jun 2009 16:48:28 UTC
Message-ID:
On Wed, 3 Jun 2009, Rik van Riel wrote:
>
> Would anybody paranoid run their system without SELinux?
You make two very fundamental mistakes.
The first is to assume that this is about "paranoid" people. Security is
_not_ about people who care deeply about security. It's about everybody.
Look at viruses and DDoS attacks - the "paranoid" people absolutely depend
on the _non_paranoid people being secure too!
The other mistake is to think that SELinux is sane, or should be the
default. It's a f*cking complex disaster, and makes performance plummet on
some things. I turn it off, and I know lots of other sane people do too.
So the !SElinux case really does need to work.
Linus

2. Functionality generalities:2. Functionality generalities:
Denial by default
-EPERM
permissive vs. enforcing vs. disabled
"Security context" specified as:
user:mode:type:mls_level
Principle of least privilege

3. Core Policies3. Core Policies
MLS
TE
RBAC
UBAC/UID

3.1. Multi-Level Security (MLS)3.1. Multi-Level Security (MLS)
Taken from "Red Hat Enterprise Linux Deployment Guide"

3.2. Type Enforcement (TE)3.2. Type Enforcement (TE)
Taken from "Usenix SSYM'03 -- Analyzing Integrity Protection in the SELinux
Example Policy"

3.3. Role-Based Access Control (RBAC)3.3. Role-Based Access Control (RBAC)
"... provides a higher level abstraction to simplify user management."
Authorize each user as a set of roles
Authorize each role for a set of TE domains
Role field in security context in SELinux:
Maintained per RBAC model for each process
Set to a generic "object_r" for objects => i.e. unused
Role transition limited to certain TE domains per policy
Mostly unused in SEAndroid

3.4. User-Based Access Control (UBAC)3.4. User-Based Access Control (UBAC)
Issues w/ regular Linux UID model:
Often change to express permission or privilege, not user change
Change at any time w/ setuid calls w/o control over initialization
Arbitrarily changed by superuser
SELinux uses orthogonal UIDs:
Rigourous enforcement, unlike Linux
Policy limits UID changes to certain TE domains
Mostly unused in SEAndroid

4. Linux integration4. Linux integration
Taken from "USENIX/FREENIX 2001 -- Integrating Flexible Support for
Security Policies into the Linux Operating System"

5. Linux Security Module Hooks5. Linux Security Module Hooks
Taken from "USENIX SSYM 2002 -- Linux Security Modules: General Security
Support for the Linux Kernel"

6. Current Linux implementation6. Current Linux implementation
Taken from "Haines -- The SELinux Notebook (4th Ed.)"

AOSP User-SpaceAOSP User-Space
adb
App signing
App permission system
OTA
Google's on-device security
Keystore/Keymaster
Logging in
DRM
Android for work
App reverse engineering

1. adb1. adb

2. App signing2. App signing
All apps signed
All certs used are self-signed -- no CA in Android ecosystem
Signature used by Package Manager:
Ensures replaced apps is signed with same key:
If >1 apps have same signature, can share same User ID
Signature used between apps to gate permissions:
granted to same-sig apps only
Can define permissions
Can manually check remote app signature
"Signature" permissions
"custom"

3. App permission system3. App permission system
Managed by PackageManager System service
At boot time, PM's
grants
platform-signed apps perms they've requested.
Normal apps checked at runtime for dangerous perms now
System services check caller permissions on call reception
Global framework permission definitions:
checkCallingPermission()
enforceCallingPermission()
grantPermissionsToSysComponentsAndPrivApps()
frameworks/base/core/res/Android.mk

4. OTA4. OTA
Two paths:
Recovery: Relies on recovery image
A/B ("seamless"): Relies on:
update_engine user-space binary
boot_control HAL
Both use AOSP release tools
A/B supports "streaming" updates
A/B support is SoC-vendor dependent: Qualcomm, Mediatek

5. Google's on-device security5. Google's on-device security
Connected to Google backend
Runs on all official Android devices (> 1B)
Provides:
Verify apps:
Continuously running on all apps
Detects/removes harmful apps and warns
Attestation
Safe browsing (phishing, malware, etc.)
Recaptcha
SafetyNet

6. Keystore/Keymaster6. Keystore/Keymaster
Taken from "Google -- Keystore attestation"

7. Logging in7. Logging in
Taken from "Google -- Authentication overview"

8. DRM8. DRM
Taken from "Inforce -- Protecting your premium HD content with Widevine™
Digital rights management (DRM) on Inforce platforms

9. Android for work / EMM9. Android for work / EMM
Taken from "Google -- Develop a solution"

Google's InfrastructureGoogle's Infrastructure
Taken from "Google -- Keeping Google Play safe"

Thank You!Thank You!
karim.yaghmour@opersys.com

Android Security Internals

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Android Security Internals

Similar to Android Security Internals (20)

More from Opersys inc.

More from Opersys inc. (20)

Recently uploaded

Recently uploaded (20)

Android Security Internals