Security and Separation

in a Mobile World

19th June, 2014

Phil Yialeloglou, Senior Consulting R&D Engineer

phil@au.ngc.com

Cyber Solutions Division

2

“How hard can it be?”Jeremy Clarkson

“What were you thinking!”Dr Phil

Mobility Reality Check

• Relentless demand for “anywhere” access to information

• Users accustomed to unfettered access to unclassified information

demand similar access to classified information

• Low acceptance factor for carrying multiple devices for “Work” and

“Play”

• Denial is not a good coping strategy

Additional Risks in a Mobile Environment

• Using the device to access sensitive information in insecure locations

• Drawing unwanted attention by carrying easily identified classified

hardware

• Increased possibility of device loss e.g. Theft, seizure, loss in taxi, etc

Design Goals

• Enable a commercial smartphone or tablet to provide concurrent

access to multiple security zones

• Each security zone must support enterprise applications normally

available for a smartphone or tablet, and provide local storage for

classified data

• Each security zone must have strong isolation from other zones for

data at rest, in use and in motion

• Achieve high assurance levels for data protection with the aim of

allowing devices to be treated at a lower security classification when

not in use

Architectural Approaches to Mobility Security

• Bottom Up:

– Start with commercial baseline and harden up to your requirements.

• Top Down:

– Start with a high security reference design and relax security controls down to your

requirements.

Conventional Operating System Implementation

• Security trade off in favour of usability

• Feature bloat

– Linear growth in code and features results in exponential growth in complexity

• “After all our hard work, we finally have a secure baseline. Now

what?”

– Patches and hot fixes create a moving assurance target

• Summary: Mixing security and complexity usually ends in tears

Survey of existing CoTS Mobility Solutions

• Android 4.4 (KitKat)

– Uses SE Android in enforcing mode

– Provides SE Linux kernel Mandatory Access Control (MAC) and Middleware MAC

(MMAC) to provide strong isolation between applications, effectively reducing the

likelihood that applications can access each other’s data or escalate privileges

– Uses a mixture of native and vendor provided Mobile Device Manager APIs that

primarily monitor enterprise policy compliance. Minimal enforcement.

– Provides trusted boot via vendor-specific boot chain

– Open source

Survey of existing CoTS Mobility Solutions

• Samsung Knox

– Builds on SE Android by implementing secure boot via ARM’s trustzone

– Isolates enterprise application network access via per-application VPN

– Provides per-application encryption of Data at Rest

– Provides Mobile Device Manager APIs that allow for enterprise policy enforcement

– Samsung Knox extensions are closed source

Survey of existing CoTS Mobility Solutions

• Apple iOS 7

– Trusted boot

– Implements similar capabilities with application isolation, per app data encryption,

managed applications and per application VPN

– Relatively strong MDM APIs providing for device lockdown and policy enforcement

– Address Space Layout Randomisation (ASLR)

– Predominately closed source, rendering independent kernel modification and

security analysis impractical

Survey of existing CoTS Mobility Solutions

• Microsoft Windows RT 8.1

– UEFI for trusted boot

– Trusted Platform Module (TPM) support

– Kernel memory randomisation

– Remote device management via Open Mobile Alliance Device Management (OMA

DM) protocol

– Predominately closed source, rendering independent kernel modification and

security analysis impractical

Suitability of existing CoTS Mobility Solutions

• The isolation based application models used by SE Android and Knox

are a leap forward in protecting against rogue applications

• They have a sea of complexity below their container models making

accreditation above Protected impractical

• Kernel and privileged user space application vulnerabilities not yet

addressed

• Underlying SE Linux helps, but residual threats can’t be addressed by

SE Android and SE Linux alone

MLS or MILS?

• Multiple Levels of Security (MLS) system

– An information system that handles information at different security

classifications, typically via labelling and access controls

– Traditionally achieved via a trusted operating system

• Multiple Independent Levels of Security (MILS)

– Isolated security zones, each handling a single security classification,

interconnected or isolated by cross-domain trusted components

– Architecture divided into trusted and untrusted components, allowing for a divide-

and-conquer security model

Trick Question

• How do I trust a conventional mobile device operating system to keep

my secrets?

• Answer: You don’t!

Isolate it in a single security domain and trust the isolation mechanisms instead.

Conclusions

• Minimise trusted code base to simplify accreditation

• Ensure OS has minimal security role to allow for easy upgrade with

minimal accreditation impact

• Obvious choice: Separation kernel based multiple persona device

Virtualisation 101

• Enterprise Virtualisation

– Goal: Allow separate servers to execute as VMs on a single physical machine to

leverage available hardware, memory and storage

– Examples: VMWare, HyperV, Xen, KVM

• Separation Kernels

– Goal: Provide security isolation and strictly enforced access controls between VMs

– Examples: Integrity, seL4

Tools for Handling Classified Information with

Commercial Systems

• NSA Suite B Cryptography

– Equivalent protection to Suite A using appropriate MoTS implementation

– Cannot guarantee equivalent protection in CoTS

• NSA CSfC Program

– VPN Capability Package

• Current Approved Version: 2.0, May 2013

• Current Draft Version: 2.08

– Mobility Capability Package

• Current Draft Version: 2.3

– Currently best practice for CoTS risk management

Mobility Accreditation Building Blocks

• ASD ISM

• Common Criteria Protection Profiles

• Defence in depth architecture leveraging a separation kernel for

containment

• Risk minimisation strategies leveraging NSA’s CSfC VPN and Mobility

capability packages

– Accreditation trend originating from US for CoTS based solutions to support up to

Top Secret with appropriate controls

System Accreditation

• Biggest project risk

• Early and regular engagement with accrediting body

– Lowers accreditation risk

– Eliminates “bolt-on” complexity to meet unforseen security requirements or design

flaws

– Removes unnecessary complexity based on security “over-engineering”

Handset Case Study - Design

• Install a separation kernel on a CoTS Android handset

• Provide high assurance isolation of sub-systems on the handset by

hosting “sandboxes” with enforced kernel communication channels

• Host separate instances of Android for “Work” and “Play”

• Isolate hardware components by assigning them to “handler”

sandboxes

Handset Case Study (continued)

• Use a “secure element” for cryptographic functions, keystore and

encryption of Data at Rest

• Use CSfC framework to implement two layer Suite B VPN with

separate trust anchors for the Inner and Outer VPN

• Implement a trusted boot chain to provide assurance of the initial

handset state

• Implement remote attestation to evaluate the runtime security posture

of the handset

Handset Case Study (continued)

Security Zone HighSecurity Zone Low

Separation Kernel

HW Layer

Guest Android Guest Android

Virtual Services

CellvAudio,

vDisplay, vRIL,

vWifi, vGSM,

vSys, IP

Gateway

Android Apps

MDMAndroid

AppsMDM

Security Services

Cell

Secure Element Services

CellvHSM,

vKeyStore

vDaR

z

z

Baseband

Radio

WiFi

Radio

Bluetooth

RadioCamera

Touch/

keys

Secure

Element

Speaker/

MicStorageGraphics

Gateway Case Study

• Two independent VPN layers with different codebases and separate

inner and outer trust anchors

• Strict whitelist policy on network traffic at each layer enforced by

firewalls and cryptographic separation

• Cybersecurity monitoring at each layer

• Inner security zone separated from internal network by trusted filters to

manage exposure risk from mobile environment

Gateway Case Study

User Experience

Or “A day in the life of a dual-domain phone user”

Summary

• Virtualisation does not fundamentally change the security model

• New focus on assurance of separation kernel, trusted VMs and

underlying hardware

• Defence in depth using “secure element” for dual VPN keying and DaR

lowers the risk of using CoTS hardware

• Lowering security reliance of hosted operating system allows for rapid

upgrade cycle

References

Australian Signals Directorate

Australian Government Information Security Manual (ISM)

Mobile Device Fundamentals Protection Profile, version 1.1

ASD Mandatory Requirements Addendum, version 1.0

http://www.asd.gov.au/infosec/ism/index.htm

G. Heiser, “Hypervisors for Consumer Electronics”

http://www.ssrg.nicta.com.au/publications/papers/Heiser_09.abstract

S. Smalley, “Laying a Secure Foundation for Mobile Devices”

http://www.internetsociety.org/doc/laying-secure-foundation-mobile-devices

NSA CSfC Program

http://www.nsa.gov/ia/programs/csfc_program/index.shtml

NSA Suite B Cryptography

http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

28