Android Security Internals

CC-BY-SA 3.0 - Attribution requirements and misc., except 3rd party material, 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.
Several diagrams taken from 3rd party material:
- Attribution/citation made in every case
- Refer to each original for redistribution/citation
- Facts and data are not in principle copyrightable (ex: constants in header files), however if you don't feel comfortable with our use of your material then let us know and we'll remove it: courseware@opersys.com

These slides created by: Karim Yaghmour

Originals at: http://www.opersys.com/training/

About

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

Topics

The Chain / Root of trust
SoC Internals
General System Architecture
Secure Booting
TrustZone & Trust Execution Environments
HLOS / Linux
SELinux / SEAndroid
AOSP User-Space
Cloud & Network

The Chain / Root of trust

Silicon
PCB
Software, etc.

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

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

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

Software, etc.

Early boot software
Trusted environment
HLOS/Linux
Android
Apps
Network
Cloud services
OTA

Soc 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"

Vulnerabilities

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 Booting

Overall flow
Execution location
Bootloader

1. Overall flow

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

2. 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 / LK

Google doesn't mandate a specific bootloader
Vendors can use whatever they want, including U-Boot
Many Android bootloaders based on "Little Kernel":
https://github.com/littlekernel/lk/wiki/Introduction
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:
https://git.linaro.org/landing-teams/working/qualcomm/lk.git/
Detailed internals explanation for 410E/8016E:
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 Environments

Issues
Hardware-backing
Secure monitor
TEE services
TEEs on the market
TAs
REE communication
Secure storage
Attestation
Example Trusty TAs

1. Issues

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

2. 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 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 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 market

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

6. 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 communication

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

8. Secure storage / RPMB

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

9. Example Trusty TAs

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

HLOS / Linux Kernel

Security-related built-in mechanisms
Verified boot
Full disk encryption
File-based encryption

Process isolation
DAC
LSM hooks
Device Mapper
Module signing
seccomp
ASLR
Keyring
Crypto API
HW-accelerated crypto

2. Verified Boot

3. Full Disk Encryption

Taken from "ELCE 2017 -- Protecting your system from the scum of the universe"

4. File-Based Encryption

Taken from "ELCE 2017 -- Protecting your system from the scum of the universe"

SELinux / SEAndroid

Technology generalities
Functionality generalities
Core Policies
Linux integration
Linux Security Module Hooks
Current Linux implementation

1. 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:

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

3. Core Policies

MLS
TE
RBAC
UBAC/UID

3.1. Multi-Level Security (MLS)

Taken from "Red Hat Enterprise Linux Deployment Guide"

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)

"... 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)

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

AOSP 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. adb

2. 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:
- "Signature" permissions granted to same-sig apps only
- Can define "custom" permissions
- Can manually check remote app signature

3. App permission system

Managed by PackageManager System service
At boot time, PM's grantPermissionsToSysComponentsAndPrivApps() 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:
frameworks/base/core/res/Android.mk
checkCallingPermission()
enforceCallingPermission()

4. 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 security

SafetyNet
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