Implementing Trusted Endpoints in the Mobile

WorldNikolay Elenkov

LINE and Intertrust Security Summit

May 2017, Tokyo

Agenda

• Mobile endpoint security overview

• Secure boot and OS integrity

• Sandboxing

• Monitoring and app vetting

• Protecting secrets

• Runtime protection

• Security policy

• Endpoint security needs at LINE

1

Traditional endpoint security

• Antivirus

• Personal Firewall

• (maybe) AD group policy

• (maybe) Smartcard/HW token login

2

Mobile endpoint security requirements

• Trusted OS

• App isolation and vetting

• User data/secrets protection

• (enterprise) Security policy enforcement

3

Secure boot

• Secure boot chain

• Root of trust in hardware

• Asymmetric crypto – digital signatures

• Validation at each stage

• bootloader(s)

• SEP/TEE

• kernel (and modules)

• main/rich OS

4

iOS secure boot chain

Boot ROM iBoot LLB iOS kernel

1.verify

2.load

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

SEP

3.verify

4.load

5.verify

6.load

5

Android Boot Process

Boot ROM SBLLinux +initrd

abootAndroid fmwks

verify

TEE

verify verify verify*

6

verify

iOS Code Signing

• Chain of trust extends from OS to apps

• All executable code signed w/ Apple-issued cert

• Apple apps

• third-party apps

• Code signature check on all loaded dynamic libs

• Code signature checks on all exec memory pages

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

7

Android code signing• System and third-party apps (APKs) are signed

• Self-signed certificates

• no PKI/hierarchy

• Signing certificate + pkg name = package identity

• Updates require same signing certificate

• Some permissions controlled by signing cert

• Native code not signed

8

dm-verity

• Applied to read-only partitions like system and vendor

• transparent integrity checking for block devices

• Read error if block integrity check fails

• Error correction in 7.0 (FEP)

• Requires block-based OTA updates

• Stateful in Android 6.0+

• Default is enforcing mode

• Stops boot in Android > 7.0

9

Runtime kernel monitoring

• iOS• Kernel Patch Protection (KPP)

• iOS 9+, AArch64

• Android – Samsung KNOX TIMA• Periodic Kernel Measurement (PKM)

• Realtime Kernel Protection (RKP)

• Both make use of ARM TrustZone• Secure World monitors Normal World

The ARMs race for kernel protection: https://www.slideshare.net/codeblue_jp/cb16-levin-en

10

Sandboxing

• App-private data directory

• App process isolation

• Limited IPC• no direct IPC in iOS

• Android has intents, Binder, Unix sockets

• policy-driven MAC• SELinux/MACF

• Can only use granted permissions/entitlements

11

SELinux

12

App Vetting

• iOS allows only apps from Appstore

• inhouse and MDM only exceptions

• Apps need to be approved by Apple’s to golive

• Android allows third-party (‘untrusted’) apps

• Android allows sideloading

• off by default

• traditionally system-wide setting

• per-app in Android )

• Play Store vetting is (mostly?) automated

• ‘Bouncer’

• GMS-devices have Verify Apps

• install-time and periodic scanning

iOS Android

13

Android app checks

14

User data encryption

• Transparent data encryption• File-based Encryption (FBE)

• more flexible

• iOS and Android 7.0+

• Full Disk Encryption (FDE)

• data agnostic

• Android < 7.0

• Encryption mixes in device-specific key and user PIN/password• binds to device – harder to bruteforce off device

• may use hardware module to manage keys

15

iOS FBE

Source: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

16

Android FDE

17

Secrets protection

• Secrets

• Cryptographic keys

• Biometric templates

• TouchID

• Nexus/Pixel Imprint

• Ideally protect even if OS is compromised

• Unextractable

• Device-bound

18

Traditional protection methods• Dedicated hardware• smart card/USB device, HSM, TPM

• better isolation

• slow

• Hybrid methods• SIM card as secure element (SE)

• Embedded SE (Google Wallet gen1)

• smartSD (smart card with SE)

• centralized control -> hard to deploy/manage

19

iOS – Keychain and Secure Enclave (SEP)

User space Secure EnclaveOS

Application

Security.framework

SecItem()

LocalAuthentication

Keychain

TouchID

Credential Mgmt

Key Mgmt

Based on: WWDC14 -- Keychain and Authentication with Touch ID

20

Trusted Execution Environments• Minimal trusted OS, isolated from main OS

• could be part of TCB

• Usually implemented using ARM TrustZone

• Memory isolation, but runs on same HW

• Not accessible from user mode

• Can run ‘trusted apps’

• TEE implementations

• Google Trusty

• Qualcomm QSEE

• Trustonic TAP

• hybrid

• OpenTEE (emulation)

21

Trusty TEE: https://source.android.com/security/trusty/

Android – gatekeeper and keystore

Source: https://source.android.com/security/authentication/

22

Android – key attestation• Certifies keys generated by keystore

• Issues attestation certificate for each key

• Additional info about device/HW

• OS version and patch level

• keymaster version

• security level (SW or TEE)

• root of trust / verified boot state

• key purpose/authn required

• Not working yet..

• as of Android O preview1

KeyDescription ::= SEQUENCE {attestationVersion INTEGER,attestationSecurityLevel SecurityLevel,keymasterVersion INTEGER,keymasterSecurityLevel SecurityLevel,…softwareEnforced AuthorizationList,teeEnforced AuthorizationList,

}AuthorizationList ::= SEQUENCE {

purpose [1] EXPLICIT SET OF INTEGER OPTIONAL,algorithm [2] EXPLICIT INTEGER OPTIONAL,userAuthType [504] EXPLICIT INTEGER OPTIONAL,rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL,osVersion [705] EXPLICIT INTEGER OPTIONAL,osPatchLevel [706] EXPLICIT INTEGER OPTIONAL,attestationChallenge [708] EXPLICIT INTEGER OPTIONAL,attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL,…

}SecurityLevel ::= ENUMERATED {

Software (0), TrustedEnvironment (1),}RootOfTrust ::= SEQUENCE {

verifiedBootKey OCTET_STRING, deviceLocked BOOLEAN,verifiedBootState VerifiedBootState,

}

23

Runtime protection -- SafetyNet

• Android device risk management/attestation

• CTS compatibility check

• unknown CA certificates in trust store

• dm-verity/SELinux disabled

• core system properties modified

• debugging settings

• SSL downgrade

• su/setuid files check

• Ensures that OS is trustworthy

• "ctsProfileMatch": true

• "basicIntegrity": true

More info: https://koz.io/inside-safetynet/

24

https://developer.android.com/training/safetynet/attestation.html

Device security policy

• Android device administrators/owners

• iOS configuration profiles

• MDM

• policy installed at login/activation time

• managed devices

• Policies mandate

• password complexity

• device encryption

• VPNs

• trusted certificates

25

The Android problem

• New Android versions propagate slowly

• security features not always available

• Not all devices receive security updates

• lower-end devices esp. problematic

• Cannot always trust the OS

• Fairly diverse hardware

• lower-end devices may lack TEE

• fingerprint reader not mandatory in CDD (SHOULD)

https://source.android.com/compatibility/cdd https://developer.android.com/about/dashboards

26

Android Treble – a new hope?

• Separate vendor implementation from Android framework

• Introduces new Vendor Interface

• Validated by Vendor Test Suite (VTS)

• Allows framework updates without changing vendor interface

• Starting with devices shipping with O?

27

https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html

LINE apps and services

28

LINE endpoint security needs

• Large user base in multiple countries

• > 200 million MAU

• multiple carriers

• data-only SIMs (no SMS)

• Diverse device base

• Android prevalent outside Japan

• older/cheaper devices in certain markets

• Services need to work on non-mobile

• Web

• traditional desktop OSes

• Protect LINE auth and encryption keys

• Protect local chat history

• Protect chat history in cloud backups

• Protect content

• music/stickers/video streams (DRM-like)

• games

• Protect payment/financial transaction data

• Detect fraudulent clients

• app/device tampering

Userbase characteristics Security needs

29

Security technologies we are evaluating• TEE and hybrid trusted applications

• could potentially provide same interface on iOS and Android

• not very stable ATM

• TEE not available on all devices

• Whitebox cryptography• runs on all hardware/OSes

• memory analysis and/or side-channel attacks possible

• fairly young tech, no well established evaluation criteria

• Biometrics• OS-provided fingerprint authentication

• various FIDO authenticators

30

Conclusion

• Modern mobile OSes are designed with security in mind

• iOS and Android provide both OS integrity and app isolation

• User data is encrypted and secrets protected

• FDE not always default

• protection level differs by OS version/device model

• fingeprint authentication fairly mainstream

• Android fragmentation and slow updates still a problem

• Security technologies that augment OS security worth considering31