LINE and intertrust security summit (c)LINE

1. ImplementingTrusted
Endpoints in the Mobile
World
Nikolay Elenkov
LINE and Intertrust Security Summit
May 2017,Tokyo

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

3. Traditional endpoint security
• Antivirus
• Personal Firewall
• (maybe) AD group policy
• (maybe) Smartcard/HW token login
2

4. Mobile endpoint security requirements
• Trusted OS
• App isolation and vetting
• User data/secrets protection
• (enterprise) Security policy enforcement
3

5. 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

6. iOS secure boot chain
Boot ROM iBoot LLB iOS kernel
1.verify
2.loa
d
https://www.apple.com/business/docs/iOS_Security_Guide.pdf
SEP
3.verify
4.load
5.verify
6.load
5

7. Android Boot Process
Boot ROM SBL
Linux +
initrd
aboot
Android
fmwks
verify
TEE
verify verify verify*
6
verify

8. 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

9. 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

10. 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

11. Runtime kernel monitoring
• iOS
• Kernel Patch Protection (KPP)
• iOS 9+, AArch64
• Android – Samsung KNOXTIMA
• Periodic Kernel Measurement (PKM)
• Realtime Kernel Protection (RKP)
• Both make use of ARMTrustZone
• SecureWorld monitors NormalWorld
The ARMs race for kernel protection: https://www.slideshare.net/codeblue_jp/cb16-levin-en
10

12. 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

13. SELinux
12

14. AppVetting
• iOS allows only apps from Appstore
• inhouse and MDM only exceptions
• Apps need to be approved by Apple’s to go
live
• 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 haveVerify Apps
• install-time and periodic scanning
iOS Android
13

15. Android app checks
14

16. 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

17. iOS FBE
Source: https://www.apple.com/business/docs/iOS_Security_Guide.pdf
16

18. Android FDE
17

19. Secrets protection
• Secrets
• Cryptographic keys
• Biometric templates
• TouchID
• Nexus/Pixel Imprint
• Ideally protect even if OS is compromised
• Unextractable
• Device-bound
18

20. Traditional protection methods
• Dedicated hardware
• smart card/USB device, HSM,TPM
• better isolation
• slow
• Hybrid methods
• SIM card as secure element (SE)
• Embedded SE (GoogleWallet gen1)
• smartSD (smart card with SE)
• centralized control -> hard to deploy/manage
19

21. 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 andAuthentication withTouch ID
20

22. 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
TrustyTEE: https://source.android.com/security/trusty/

23. Android – gatekeeper and keystore
Source: https://source.android.com/security/authentication/
22

24. 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 orTEE)
• 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

25. 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

26. 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

27. 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 lackTEE
• fingerprint reader not mandatory in CDD
(SHOULD)
https://source.android.com/compatibility/cdd https://developer.android.com/about/dashboards
26

28. AndroidTreble – a new hope?
• Separate vendor implementation from
Android framework
• Introduces newVendor Interface
• Validated byVendorTest 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

29. LINE apps and services
28

30. 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

31. 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

32. 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 considering
31