Implementing Trusted Endpoints in the Mobile World
-
Upload
line-corporation -
Category
Technology
-
view
3.363 -
download
0
Transcript of Implementing Trusted Endpoints in the Mobile World
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