Mobile Phone Security: Android - pub.doc.to Phone Security: Android Priv.-Doz. Dr. René Mayrhofer...

Mobile Phone Security: AndroidPriv.-Doz. Dr. René Mayrhofer

Cryptography material based on text book “Cryptography and Network Security” (5th edition) by William Stallings with slides by Lawrie Brown

HCI/usability material based on slides by Albrecht SchmidtMaterial on Android Security based on official Android documentation and source code

Basic Cryptography Terminology

Introduction:Key security concepts

Confidentiality / secrecyonly authorized users are allowed to gain access to the protected data,

message, service, resource, etc.

Integrityundetected modification is only allowed by authorized users

Availabilityauthorized users should have access to resources, and unauthorized users

should not be able to deny this access

Non-repudiabilityit should be possible to prove to third parties who the original sender of a

message was

The first three are often referred to as the CIA triad

Introduction:AAA Terminology

Additional security requirementsAuthentication

prove that a party is who they claim to be (typically second step after identification, but not necessarily required)

Authorization / Access control

Auditing / Accounting

log of who did what, when

post-hoc identification of attack and attackers

(Typically referenced for classical operating systems)

Cryptography: Basic terminology

plaintext (Klartext) – original message

ciphertext (Chiffrat) – coded message

cipher / chiffre (Verschlüsselungsalgorithmus) – algorithm for transforming plaintext to ciphertext and vice versa

key (Schlüssel) – info used in cipher known only to sender/receiver

encipher / encrypt (verschlüsseln) – converting plaintext to ciphertext

decipher / decrypt (entschlüsseln) – recovering plaintext from ciphertext

cryptography (Kryptographie) – study of encryption principles / methods

cryptanalysis (Kryptoanalyse) – study of principles / methods of deciphering ciphertext without knowing key

cryptology (Kryptologie) – scientific field of both cryptography and cryptanalysis

Cryptography: Kerkhoff's principle

security of cipher may only depend on the security of the key

always assume all details of the algorithm / method / protocol to be publicly known

all modern cryptographic methods follow this principle (cf. AES selection process – done completely in the open, with public rounds of dicussion)

„The security of a cryptosystem must not depend on keeping the cryptographic algorithm secret.”

Introduction:Definition of security

A system is considered secure when the cost of successfully attacking it is higher than the potential

gain.

Remember that there is no perfect security.

Caveat lector!

They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety.

Benjamin Franklin, ca. 1775

People willing to trade their freedom for temporary security deserve neither and will lose both.

Common paraphrased quote of the original

Cryptography on Mobile Phones:

Block Cipher Modes for Encryption,

Random Number Generation

block ciphers encrypt fixed size blocks

eg. DES encrypts 64-bit blocks with 56-bit key

need some way to en/decrypt arbitrary amounts of data in practise

NIST SP 800-38A defines 5 modes

have block and stream modes

to cover a wide variety of applications

can be used with any block cipher

Modes of operation

message is broken into independent blocks which are encrypted

each block is a value which is substituted, like a codebook, hence name

each block is encoded independently of the other blocks

Ci = EK(Pi)

uses: secure transmission of single values

Block cipher modes:Electronic Code Book (ECB)

Electronic Code Book (ECB)

message repetitions may show in ciphertext

if aligned with message block

particularly with data such graphics

or with messages that change very little, which become a code-book analysis problem

weakness is due to the encrypted message blocks being independent

main use is sending a few blocks of data

Block cipher modes:Advantages/Limitations of ECB

message is broken into blocks

linked together in encryption operation

each previous cipher blocks is chained with current plaintext block, hence name

use Initialization Vector (IV) to start process ⇒ need to transmit IV

Ci = EK(Pi XOR Ci-1)

C-1 = IV

uses: bulk data encryption, authentication

Block cipher modes:Cipher Block Chaining (CBC)

Cipher Block Chaining (CBC)

a ciphertext block depends on all blocks before it

any change to a block affects all following ciphertext blocks

need Initialization Vector (IV)

which must be known to sender and receiver

if sent in clear, attacker can change bits of first block, and change IV to compensate

hence IV must either be a fixed value (as in EFTPOS)

or must be sent encrypted in ECB mode before rest of message

Block cipher modes:Advantages/Limitations of CBC

a “new” mode, though proposed early on

similar to OFB but encrypts counter value rather than any feedback value

must have a different key & counter value for every plaintext block (never reused)

Oi = EK(i)

Ci = Pi XOR Oi

uses: high-speed network encryptions

Block cipher modes:Counter (CTR)

Counter (CTR)

efficiency

can do parallel encryptions in h/w or s/w

can preprocess in advance of need

good for bursty high speed links

random access to encrypted data blocks

provable security (as good as other modes)

but must ensure never reuse key/counter values, otherwise could break (cf OFB)

Block cipher modes:Advantages/Limitations of CTR

Feedback Characteristics

new mode, for block oriented storage use

in IEEE Std 1619-2007

concept of tweakable block cipher

different requirements to transmitted data

uses AES twice for each block

Tj = EK2(i) XOR αj

Cj = EK1(Pj XOR Tj) XOR Tj

where i is tweak & j is sector no

each sector may have multiple blocks

Block cipher modes:XTS-AES

XTS-AES Modeper block

XTS-AESModeOverview

efficiency

can do parallel encryptions in h/w or s/w

random access to encrypted data blocks

has both nonce & counter

addresses security concerns related to stored data

Block cipher modes:Advantages/Limitations of XTS

Block cipher modes:Counter with CBC-MAC (CCM)

CCM mode combines the well-known counter (CTR) mode of encryption with the well-known CBC-MAC mode of authentication

allows to use same block cipher with same key for ensuring confidentiality and authenticity/integrity

all previous modes only provide confidentiality and need additional MAC (Message Authentication Code) or digital signature to provide authenticity/integrity

only requires encryption to be implemented, no decryption function

CCM currently only defined for block ciphers with 128 bit block size

RFC 3610 defines AES-CCM

designed by Russ Housley, Doug Whiting and Niels Ferguson

currently used in wireless network standards

IEEE 802.11i (WiFi WPA2 with CCMP)

ZigBee

RFC 4309 defines used of AES-CCM for IPsec (not yet in widespread use)

has been criticized for not being on-line and for being complex

see [Rogaway and Wagner 2003: “A Critique of CCM”]

EAX suggested as alternative

CCM Operation

many uses of random numbers in cryptographynonces in authentication protocols to prevent replay

session keys

public key generation

keystream for a one-time pad

in all cases its critical that these values bestatistically random, uniform distribution, independent

unpredictability of future values from previous values

true random numbers provide this

care needed with generated random numbers

especially for session keys: use true random numbers (possible on mobile devices by using sensor data, e.g. accelerometer)

Random numbers

best source is natural randomness in real world

find a regular but random event and monitor

do generally need special h/w to do thiseg. radiation counters, radio noise, audio noise, thermal

noise in diodes, leaky capacitors, mercury discharge tubes etc

starting to see such h/w in new CPU's

problems of bias or uneven distribution in signalhave to compensate for this when sample, often by passing

bits through a hash function

best to only use a few noisiest bits from each sample

RFC4086 recommends using multiple sources + hash

Natural random noise

Cryptography on Mobile Phones:

Advanced Authentication Protocols

30

Pervasive/Mobile Computing: What's new?

31

● Wireless communication

● Small, mobile devices

● limited user interfaces

● limited resources (run time!)

● Many devices

● integrated with/into physical objects

● communicate among each other

● communicate with the user

● Sensing

⇒ (mobile and stationary) devices and communication become more and moreinvisible, unobservable and uncontrollable

Pervasive/Mobile Computing: What's new?

32

Security for Whom?

● Security for whom?

● User

● Mobile device

● Used service

● How much security?

● Life safety / medical applications

● Military

● E-Banking

● Credit card transactions

● Transferring files (music, pictures, multi-Million-€ contracts)

● Using infrastructure services (hotspots, printers, Bluetooth headsets)

● Gaming

● ...

33

Securing Spontaneous Interaction

How to protect devices

● Not all discovered components (devices, services, systems, people, ...) are necessarily friendly

● Users require security for their resources, and privacy for themselves

Consequence: Authentication of devices and services

● Humans can make judgments about trustworthiness of their environment

● Trusting a printer because it is in a friend’s house

● Trusting a PDA because its owner is judged to be trustworthy

● Trusting a merchant's payment terminal in a foreign city because ...you want/need to use it...

But how can wireless device associations be authenticated?

34

What needs to be solved?

Issues● wireless

● spontaneous interaction

● restricted user interfaces

● scalability

Approaches● authentication

● peer-to-peer, context

● human-verifiable authentication with personal mobile device

Out-of-Band Channels

Mobile Systems Security 36

Security properties of out-of-band channels

Out-of-band channels can be

confidential

stall-free

authentic

or provide partial integrity

or any combination


Recent protocol proposals

“MANA I-III” (display/keypad) [C. Gehrmann, C. J. Mitchell, and K. Nyberg: “Manual authentication for wireless devices”, RSA Cryptobytes 7, 2004]

Balfanz “pre-authentication” [D. Balfanz, D. K. Smetters, P. Stewart, H. C. Wong: “Talking to Strangers: Authentication in Ad-Hoc Wireless Networks”, NDSS 2002]

Hoepman “ephemeral key exchange φKE” [J.-H. Hoepman: “The Emphemeral Pairing Problem”, Financial Cryptography, 2004]

Vaudenay “SAS” [S. Vaudenay: “Secure Communications over Insecure Channels Based on Short Authenticated Strings”, CRYPTO 2005]

→ MANA IV family of protocols [S. Laur and K. Nyberg: “Efficient Mutual Data Authentication Using Manually Authenticated Strings”, CANS 2006]


Authenticating DH session keys

[F.-L. Wong, F. Stajano: “Multi-Channel Protocols”]


Problem with this approach: short strings

[F.-L. Wong, F. Stajano: “Multi-Channel Protocols”]


MANA IV Preliminaries

In practice: c = HMACpk

(m), d = m

[S. Laur, K. Nyberg: “Efficient Manual Data Authentication using Manually Authenticated Strings: Extended Version”]


MANA IV Details

[S. Laur, K. Nyberg: “Efficient Manual Data Authentication using Manually Authenticated Strings: Extended Version”]


Recent protocol proposals: standards

Bluetooth pairing in current standard and WEP are completely broken[Y. Shaked and A. Wool: “Cracking the Bluetooth PIN”, Mobisys 2005][F.-L. Wong, F. Stajano, and J. Clulow: “Repairing the Bluetooth pairing protocol”, Security Protocols 2005][E. Tews, R.-P. Weinmann, and A. Pyshkin: “Breaking 104 bit WEP in less than 60 seconds”, Cryptology ePrint Archive 2007/120]

Bluetooth Simple Pairing [Bluetooth SIG: Simple Pairing Whitepaper, 2006]

“just works” - insecure against MITM

“numeric comparison” of six digit number, yes/no on both devices

“out of band” e.g. with NFC

“passkey entry” with transferring a six digit number (human as out-of-band channel)

Wi-Fi Protected Setup

“push button configuration” - insecure against MITM

“PIN” with four to eight digit number

“out-of-band” e.g. with NFC


Usability analysis are slowly being done...

Good summary of recent protocol proposals and initial protocol taxonomy[J. Suomalainen, J. Valkonen, and N. Asokan: “Security Associations in Personal Networks: A Comparative Analysis”, ESAS 2007]

Usability analysis for Bluetooth Simple Pairing and Wi-Fi Protected Setup [C. Kuo, J. Walker, and A. Perrig: “Low-cost Manufacturing, Usability, and Security: An Analysis of Bluetooth Simple Pairing and Wi-Fi Protected Setup”, USEC 2007]

More general usability analysis on security in pervasive computing [E. Uzun, K. Karvonen, and N. Asokan: “Usability Analysis of Secure Pairing Methods”, USEC 2007][T. Kindberg, A. Sellen, and E. Geelhoed: “Security and Trust in Mobile Interactions: A Study of Users' Perceptions and Reasoning”, HP Labs Techreport HPL-2004-113][D. Balfanz, G. Durfee, R. E. Grinter, and D.K. Smetters: “In Search of Usable Security: Five Lessons from the Field”, IEEE Security&Privacy 2(5), 2004]

Common issues:

small and/or non-representative group of subjects

bias/obvious results


Context-based authentication

main threat scenario: MITM on wireless communication channel

intended communication partners A and B share some context

attacker E has inferior access to this context

respective aspect of context represented by sensor data streams ⇒ shared (weakly) secret information

identification vs. authentication anonymous/pseudonymous authentication possible

physical identities are more important than virtual ones


Context-based authentication

We can define context authentication as: A group of devices is authenticated with each other when

certain aspects of their context match.

Appropriate sensors to ensure that two or more devices are in common context

Tim Kindberg et al: Concept of “constrained channel”:[T. Kindberg, K. Zhang, N. Shankar: “Context Authentication Using Constrained Channels”, WMCSA 2002]

channels that are restricted by contextual constraints

either send- or receive-constrained

Dirk Balfanz et al: “location-limited channel”:[D. Balfanz, D. K. Smetters, P. Stewart, H. C. Wong: “Talking to Strangers: Authentication in Ad-Hoc Wireless Networks”, NDSS 2002}

requires “demonstrative identification”: identification based on physical context (i.e. location)

requires authenticity of channel


Location/position as context

Conventional methods:GPS

other RF time of flight/signal strength (e.g. GSM)

ultra sound

Methods depending more on qualitative than on quantitative factors:visible light (laser, but also LED/display and camera)

infrared

audio

motion

But never forget the users: we design for users, so be aware of their perception of how secure an authentication method seems to be![T. Kindberg, A. Sellen, E. Geelhoed: “Security and Trust in Mobile Interactions: A Study of Users’ Perceptions and Reasoning”, HP Labs Research Report]


“Seeing-is-Believing”

Visual out-of-band channel[J. M. McCune, A. Perrig, and M. K. Reiter: “Seeing-Is-Believing: Using Camera Phones for Human-Verifiable Authentication”, IEEE Symp. on Security and Privacy 2005]

extended to use blinking patterns[N. Saxena, J.-E. Ekberg, K. Kostiainen, and N. Asokan: “Secure Device Pairing based on a Visual Channel”, Cryptology ePrint Archive 2006/050]


Gesture-based Authentication

[S. N. Patel, J. S. Pierce, and G. D. Abowd: “A Gesture-based Authentication Scheme for Untrusted Public Terminals”, UIST 2004]


Other suggested approaches

“LoKey”: use SMS as out-of-band channel, integration with applications[A. J. Nicholson, I. E. Smith, J. Hughes, and B. D. Noble: “LoKey: Leveraging the SMS Network in Decentralized, End-to-End Trust Establishment”, Pervasive 2006]

“Loud and Clear”: comparing non-sensical English sentences, “HAPADEP” extension[M. T. Goodrich, M. Sirivianos, J. Solis, G. Tsudik, and E. Uzun: “Loud And Clear: Human Verifiable Authentication Based on Audio”, ICDCS 2006] [C. Soriente, G. Tsudik, and E. Uzun: “HAPADEP: Human Asisted Pure Audio Device Pairing”, Cryptology ePrint Archive 2007/093]

“Personal Pen” coupled with RFID for seamless, transparent user login[Jakob E. Bardram, Rasmus E. Kjær, and Michael Ø. Pedersen: “Context-Aware User Authentication - Supporting Proximity-Based Login in Pervasive Computing”, Ubicomp 2003]

Location-based WLAN authentication[D. B. Faria and D. R. Cheriton: “No Long-term Secrets: Location-based Security in Overprovisioned Wireless LANs”, HotNets-III, 2004]

“Harmony” protocol for comparing interlocked media streams[T. Kindberg, K. Zhang, and S. H. Im: “Evidently secure device associations”, HP Labs Techreport HPL-2005-40, 2005]

“Amigo” using RF environment as common context[A. Varshavsky, A. Scannell, A. LaMarca, and E. de Lara: “Amigo: Proximity-based Authentication of Mobile Devices”, Ubicomp 2007]

“BEDA”: synchronized button presses[Claudio Soriente, Gene Tsudik, and Ersin Uzun: “BEDA: Button-Enabled Device Pairing”, IWSSI 2007]

“Shake them Up”: moving devices to achieve source indistinguishability[C. Castelluccia and P. Mutaf: “Shake Them Up!”, Mobisys 2005]

Elena Vildjiounaite, Satu-Marja Mäkelä, Mikko Lindholm, Reima Riihimäki, Vesa Kyllönen, Jani Mäntyjärvi, Heikki Ailisto (Technical Research Cente of Finland): Unobtrusive Multimodal Biometrics for Ensuring Privacy and Information Security with Personal Devices, Pervasive 2006

Cryptography on Mobile Java


Bouncycastle crypto toolkit

A lightweight cryptography API.

A provider for the Java Cryptography Extension and the Java Cryptography Architecture.

A clean room implementation of the JCE 1.2.1.

A library for reading and writing encoded ASN.1 objects.

A lightweight client-side TLS API.

Generators for Version 1 and Version 3 X.509 certificates, Version 2 CRLs, and PKCS12 files.

Generators for Version 2 X.509 attribute certificates.

Generators/Processors for S/MIME and CMS (PKCS7/RFC 3852).

Generators/Processors for OCSP (RFC 2560).

Generators/Processors for TSP (RFC 3161).

Generators/Processors for OpenPGP (RFC 2440).

A signed jar version suitable for JDK 1.4-1.6 and the Sun JCE.The lightweight API works with everything from the J2ME to the JDK 1.6.http://bouncycastle.org/java.html


Bouncycastle lightweight API

AESLightEngine blockCipher = new AESLightEngine();CFBBlockCipher cfbCipher = new CFBBlockCipher(blockCipher,8);StreamCipher streamCipher = new StreamBlockCipher(cfbCipher);

// Create an IV of random data.byte[] iv = new byte[blockCipher.getBlockSize()];mSecureRandom.nextBytes(iv);

// Concatenate the IV and the message.byte[] messageBytes = mMessage.getBytes("UTF8");int length = messageBytes.length + blockCipher.getBlockSize();byte[] plaintext = new byte[length];System.arraycopy(iv, 0, plaintext, 0, iv.length);System.arraycopy(messageBytes, 0, plaintext, iv.length, messageBytes.length);

// Encrypt the plaintext.byte[] ciphertext = new byte[plaintext.length];streamCipher.init(true, key);streamCipher.processBytes(plaintext, 0, plaintext.length, ciphertext, 0);


OpenUAT

Documentation, demo applications, data sets: http://www.openuat.org

Source code, mailing list, bug tracker: http://sourceforge.net/projects/openuat

[R. Mayrhofer: “Towards an open source toolkit for ubiquitous device authentication”, PerSec/PerCom 2007]


Cryptographic primitives: ciphers, hashes (JCE and Bouncycastle with wrappers), DH with default parameters and utility methods, interlock*, on-the-fly creation of X.509 CAs and certificates

Communication channels: threaded TCP and Bluetooth RFCOMM servers using same interface (transparently interchangeable), UDP multicast, Bluetooth background discovery and peer management (opportunistic authentication)

Key management protocols: DH-over-streams (TCP or RFCOMM), Candidate Key Protocol

Sensors and feature extractors: ASCII line reader with various implementations for accelerometers, simple statistics, time series aggregation, activity detection/segmentation, FFT, quantizer

Context authentication protocols:

Manual comparison

Spatial references

Visual: mobile phone camera + QR codes

Audio: midi tunes for transfer or verification

Accelerometer data

Simultaneous button presses

Secure channels: IPSec tunnel and transport (Linux, MacOS/X, Windows)Utilizing Log4j, JUnit, Ant build system including J2ME builds

Components in the current release

[R. Mayrhofer: “Towards an open source toolkit for ubiquitous device authentication”, PerSec/PerCom 2007]


Exchangeable in- and out-of-band channels


Manual comparison of pseudo sentences


Video Channel

Workflow:Hash encoded in a QR code

Take a picture of the other device and decode

Experiences:ZXing library for QR codes from Google

No lens autofocus support in Java for mobile phones


Button Channels

Workflow:

Common input by simultaneous button presses

OR message transmission through button presses

One device signals, the other receives

Experiences:

Canvas display and vibration


Button presses demo


Channels - Class Hierarchy

J2ME J2SE


UACAP

Unified Auxiliary Channel Authentication ProtocolDifferent modes of operation from user point of view

Input channels

– IN: input non-confidential

– IC: input confidential → pre-authentication possible

Transfer channels

– TS: transfer “short” (10-60 Bits)

– TL: transfer “long” (>= 128 Bits) → pre-auth. possible

Verification

– V: explicit user verification (always “short”), non-confidential

Main phases:

1. Pre-authentication: only for TL and IC

2. Diffie-Hellman key agreement with pre-commitment

3. Out-of-band key verification


UACAP


UACAP Specification (1)


Using UACAP for Key Agreement

HostServerBase server = new TCPPortServer(PORT, 10000, true, true); server.start(); server.addAuthenticationProgressHandler(this);

Creating a TCP socket to listen for incoming requests (verify or transfer):

Need to implement AuthenticationProgressHandler to listen for events:public void AuthenticationFailure(Object sender, Object remote,

Exception e, String msg) {System.out.println("Authentication FAILED with remote " + remote + ": " + msg);

}

public void AuthenticationProgress(Object sender, Object remote,int cur, int max, String msg) {

}

public boolean AuthenticationStarted(Object sender, Object remote) {System.out.println("Incoming authentication from remote " + remote);return true;

}

public void AuthenticationSuccess(Object sender, Object remote,Object result) {

System.out.println("Authentication SUCCESS with remote " + remote);

Object[] res = (Object[]) result; sharedSessionKey = (byte[]) res[0];

byte[] sharedOObMsg = (byte[]) res[1];

socketToRemote = (RemoteTCPConnection) remote;

// verify / transfer and verify sharedOObMsg and, if equal, use sharedSessionKey}


Using UACAP for Key Agreement

System.out.println("Connecting to remote " + connectTo); Socket client = new Socket(connectTo, PORT);

HostProtocolHandler.startAuthenticationWith( new RemoteTCPConnection(client), this, 10000, true, "", true);

Connecting to a remote TCP socket and starting authentication

And that's it – both sides (client and server will receive their callbacks). Either use an implemented out-of-band channel or verify sharedOObMsg in the application.

Hash.getHexString(sharedOObMsg).substring(0, ...)

Usability of Mobile Applications


Creative users - designed for user‘s needs?

Write on paper capture on photo send as MMS


Real-world usability examples

CS Building in Saarbrücken DFKI in Saarbrücken

(Pho

tos

A.

But

z)


Real-world usability examples

Signs and explanations for things that are usually obvious are an indicator for a potential problem.

(German Rail IC-Train)


What is Usability: Usability 101 by Jakob Nielson

“Usability is a quality attribute that assesses how easy user interfaces are to use. The word ‘usability’ also refers to methods for improving ease-of-use during the design process.”

Usability has five quality components:

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?

Efficiency: Once users have learned the design, how quickly can they perform tasks?

Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?

Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?

Satisfaction: How pleasant is it to use the design?

[Jakob Nielsen's Alertbox, August 25, 2003: Usability 101: Introduction to Usability

http://www.useit.com/alertbox/20030825.html]


How it will NOT work

Usability tests at the end when the product is ready and needs to be shipped

Designing a new and pretty skin to a product

Introducing HCI issues after the system architecture and the foundations are completed

Comparison: An interior designer can not make a great house if the architect and engineers forgot windows, set the doors at the wrong locations, and created an unsuitable room layout.


Paper Prototypes

Specify the set of tasks that should be supported

Create a paper prototype using office stationery

Screens, dialogs, menus, forms, …

Specify the interactive behavior

Use the prototype

Give users a specific task and observe how they use the prototype

Ask users to “think aloud” – comment what they are doing

At least two people

– One is simulating the computer (e.g. changing screens)

– One is observing and recording

Evaluate and document the findings

What did work – what did not work

Where did the user get stuck or chose alternative ways

Analyze comments from the user

Iterate over the process (make a new version)


Low-Fidelity Prototyping

Advantages of paper prototypes

Cheap and quick – results within hours!

Helps to find general problems and difficult issues

Make the mistakes on paper and make them before you do your architecture and the coding

Can save money by helping to get a better design (UI and system architecture) and a more structured code

Enables non-technical people to interact easily with the design team (no technology barrier for suggestions)

Get users involved!

To get the full potential of paper-prototypes these designs have to be tested with users

Specify usage scenarios

Prepare tasks that can be done with the prototype


Minimize the time for design Iterations - Make errors quickly!

Idea of rapid prototyping

Enables the design team to evaluate more design options in detail

If you go all the way before evaluating your design you risk a lot!

Sketches and paper prototypes can be seen as a simulation of the real prototype

Without paper prototyping:

Idea – sketch – implementation – evaluation

With paper prototyping:

Idea – sketch/paper prototype – evaluation – implementation - evaluation

Slow Iteration

Slow IterationQuick Iteration


High-fidelity Prototype

Looks & feels like the final product to the user

Colors, screen layout, fonts, …

Text used

Response time and interactive behavior

The functionality however is restricted

Only certain functions work (vertical prototype)

Functionality is targeted towards the tasks (e.g. a search query is predetermined)

Non-visible issues (e.g. security) are not regarded

Can be used to predict task efficiency of the product

Feedback often centered around the look & feel

Standard technologies for implementation

HTML, JavaScript

Flash, Director, Presentation programs

GUI Builder (e.g. Visual Basic, Delphi, NetBeans)

Android Security Concepts:

Basic Architecture, Sandboxing,

Application Permissions,

Calling Other App Activities,

System Database Security

iPhone vs. Android Comparison


iPhone Security Concept

Closed eco-system

All applications need to go through Apple Store, checked by Apple

unless device has been “jailbroken”...

iOS offers APIs for securing applications

Keychain API to store passwords, keys, certificates, and other secrets

Certificate, Key, and Trust Services API for (asymmetric) encryption and signature management, based on X.509 certificates

Randomization Services provides cryptographically secure pseudorandom numbers

Device encryption allows to encrypt most (all?) user data on the device

However, OS can transparently decrypt as soon as it is running...

Exploit protection measures

Data Execution Prevention (DEP) using ARM XN feature

but no ASLR in kernel

Sandboxing restricted to few applications (e.g. MobileSafari)


iPhone Security APIs


Android Security Concept

Open eco-system

Arbitrary applications can be installed by the user (may need to enable “USB debugging for installation from PC or download on-device and install)

All applications are sandboxed

upon installation, the package manager creates a dynamic user ID

all application files and processes are restricted to this UID

enforced by Linux kernel and therefore same restrictions for all code (Java + native)

by default, even the user and debugging shells are restricted to a special UID (SHELL) → “rooting” is possible by default on Google phones (oem unlock) and, using exploits, on most of the current Android handsets and allows the user/debugging shells to gain “root” access (super user / system level access on UNIX without further restrictions)

permissions granted at installation time allow to call services outside the application sandbox

DRM and application copy protection introduced recently (Android 2.2 and new market API)

No further security measures

no ASLR, no DEP

no on-device encryption


Android Architecture


Android Security Architecture

Applications must be signed for installation

can be self-signed by the developer, therefore no requirement for centralized application Q/A or control

signature allows non-repudiability (if the public key/certificate is known)

signature by same private key allows applications to share data and files

automatic application updates possible when signed by same private key

Applications may install data on the device flash memory

/data/data/<package name> with sub-directories for files, databases, etc.

API for centralized account data storage (one accounts database on system)

– protected against normal applications

– but no specific protection of this database on rooted devices (i.e. not encrypted)

all files in application directories only accessible by the respective application UID

Applications may install (larger) data on extended memory (typically MicroSD)

however, MicroSD cards typically formatted with VFAT (or exFAT)

→ no DAC (Discretionary Access Control) by kernel, all files accessible to all apps


Android Permissions: Requesting Permissions

For example, an application that needs to monitor incoming SMS messages would specify:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.android.app.myapp" >

<uses-permission android:name="android.permission.RECEIVE_SMS" />

...

</manifest>

All requested permissions need to be granted at application installation (or otherwise, the application will not be installed) by explicit user consent

However, how many users read (and understand) the list of permissions??

Permissions stored in /data/system/packages.xml, world readable, writable by user system (and root, obviously)

Permissions checked (partially) at run-time by the respective services being called


Android Permissions: Demanding Permissions

An application that wants to control who can start one of its activities could declare a permission for this operation:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.me.app.myapp" >

<permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"

android:label="@string/permlab_deadlyActivity"

android:description="@string/permdesc_deadlyActivity"

android:permissionGroup="android.permission-group.COST_MONEY"

android:protectionLevel="dangerous" />

...

</manifest>

→ Allows user to decide if another application might call an activity.

Declare activity as not being exported at all (can be launched only by components of the same application or applications with the same user ID)

<activity android:exported=”false” ...>

Arbitrarily fine-grained permissions can be enforced with the Context.checkCallingPermission() method


Android Permissions: Permission Checking

Activity permissions (applied to the <activity> tag) restrict who can start the associated activity.

checked during Context.startActivity() and Activity.startActivityForResult(); if the caller does not have the required permission then SecurityException is thrown from the call.

Service permissions (applied to the <service> tag) restrict who can start or bind to the associated service.

checked during Context.startService(), Context.stopService() and Context.bindService(); if the caller does not have the required permission then SecurityException is thrown from the call.

BroadcastReceiver permissions (applied to the <receiver> tag) restrict who can send broadcasts to the associated receiver.

checked after Context.sendBroadcast() returns, as the system tries to deliver the submitted broadcast to the given receiver; permission failure will just not deliver the intent. In the same way, a permission can be supplied to Context.registerReceiver() to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when calling Context.sendBroadcast() to restrict which BroadcastReceiver objects are allowed to receive the broadcast (see below).

ContentProvider permissions (applied to the <provider> tag) restrict who can access the data in a ContentProvider. Unlike the other components, there are two separate permission attributes you can set: android:readPermission restricts who can read from the provider, and android:writePermission restricts who can write to it.

checked when you first retrieve a provider (if you don't have either permission, a SecurityException will be thrown), and as you perform operations on the provider. Using ContentResolver.query() requires holding the read permission; using ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requires the write permission. In all of these cases, not holding the required permission results in a SecurityException being thrown from the call.


Comparison of Mobile Platform Exploit Prevention Measures

Table by Nicolas Economou and Alfredo Ortega, Presentation “Smartphone (in)security” at CanSecWest 2009

Android Rooting


Rooting Overview

1. Achieve temporary root privileges

on “developer” devices (Google ADP1 / G1, Nexus One, Nexus S) simply with

– fastboot oem unlock

booting into recovery mode on devices that allow this without restriction

exploiting an implementation bug

– either during normal system run-time

– or in the boot loader code to get into recovery mode (see above)e.g. flawed signature checking allows booting custom recovery image and from within that running image, flashing a new system image

2. Achieve permanent root privileges

by flashing a new system image with pre-installed binaries for root access

by installing a /system/(x)bin/su binary with “setuid” Bit set and the “SuperUser” application that will ask the user on each (first-time) access

by modifying the root image, e.g. to set the global property ro.secure=0

3. Secure system against abuse by other applications


Details (1)

Android based on Linux kernel“root” is the super-user, equivalent to system-level access

kernel implements DAC (Discretionary Access Control) on filesystem (includes kernel virtual files, e.g. /proc, /sys, etc.)

optional MAC (Mandatory Access Control) schemes available in upstream kernel

SELinux (NSA, flexible, comprehensive, but complex)

SMACK (simpler, path-based, used on MeeGo)

TOMOYO (path-based, more flexible than AppArmor)

AppArmor (simpler, path-based, used on Novell and Ubuntu servers)

could all be used to further restrict root user, often based on application context

But none of them used in Android at this time!

goal is therefore to achieve root privileges


Details (2)

UNIX standard filesystem ACLsread, write, execute bits for owning user, group, and all others

additional bits available, e.g. setuid and setgid

→ binary called with privileges of owner, not privileges of caller

→ typical combination is a file owned by root with setuid Bit set

setuid binaries used on many UNIX/Linux systems to allow normal users to perform administrative tasks (e.g. passwd) or for arbitrary code elevation (e.g. su, sudo)

for controlled root access, simple and effective method on Android

no changes required for the system

only need one additional binary installed with setuid Bit set

typically /system/(x)bin/su as on standard UNIX systems, but with Android-specific GUI to ask user for permission on root access


Android Debug Bridge (adb)

Must be enabled by user (USB Debugging)

but then available over USB, WiFi, or locally on device

Supports debugging, file transfer, package installation, reboot control, etc.

Normally runs as user SHELL (uid 2000)

Can be restarted as user root (uid 0)

with global property ro.secure=0

then can call adb root to restart

or use one of the known exploits to force adb to retain root privileges

will then support e.g. adb remount to remount /system with read-write option


Devices with NAND-Lock

Some HTC devices have a “NAND lock” implemented in their kernel and boot loader

also called “S-On” in contrast to “S-Off” (no additional protection)

Boot loader sets global flag “S-On” for booting into Android and “S-Off” for booting into recovery mode

Radio firmware prevents write access to system (and sometimes recovery) NAND partitions even with root privileges and when /system has been re-mounted for read-write access

Currently known devices with NAND Lock: all HTC Desire and EVO variants

Other devices “only” have a boot loader that verifies signatures before installing updates for recovery and system and even which kernels it would boot (e.g. Motorola Milestone)


What can be done after rooting?

DevelopmentInstalling custom root, recovery, and system images

[on devices without NAND lock] changing files on the /system partition

GeneralReading all files on /system and /data partitions (including centralized system databases, e.g. accounts)

Changing kernel settings

e.g. CPU over-/underclocking

IPv6 address privacy

custom routing, WiFi/3G connection sharing on devices that do not support “tethering” out of the box or have it disabled by the manufacturer/carrier

Installing/using applications that require root access

Backup/restore

OpenVPN, Webkey, SSH daemon, etc.

Mobile Phone Security: Android - pub.doc.to Phone Security: Android Priv.-Doz. Dr. René Mayrhofer...

Documents

Transcript of Mobile Phone Security: Android - pub.doc.to Phone Security: Android Priv.-Doz. Dr. René Mayrhofer...