mobile phone security: android - mayrhofer.eu.org · page 3 introduction: key security concepts...
TRANSCRIPT
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
Page 2
Basic Cryptography Terminology
Page 3
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
Page 4
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)
Page 5
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
Page 6
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.”
Page 7
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.
Page 8
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
Page 9
Cryptography on Mobile Phones:
Block Cipher Modes for Encryption,
Random Number Generation
Page 10
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
Page 11
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)
Page 12
Electronic Code Book (ECB)
Page 13
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
Page 14
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)
Page 15
Cipher Block Chaining (CBC)
Page 16
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
Page 17
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)
Page 18
Counter (CTR)
Page 19
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
Page 20
Feedback Characteristics
Page 21
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
Page 22
XTS-AES Modeper block
Page 23
XTS-AESModeOverview
Page 24
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
Page 25
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
Page 26
CCM Operation
Page 27
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
Page 28
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
Page 29
Cryptography on Mobile Phones:
Advanced Authentication Protocols
30
Page 30
Pervasive/Mobile Computing: What's new?
Page 31 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?
Page 3232
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
● ...
Page 3333
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?
Page 3434
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
Page 35
Out-of-Band Channels
Mobile Systems Security 36 Page 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
Mobile Systems Security 37 Page 37
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]
Mobile Systems Security 38 Page 38
Authenticating DH session keys
[F.-L. Wong, F. Stajano: “Multi-Channel Protocols”]
Mobile Systems Security 39 Page 39
Problem with this approach: short strings
[F.-L. Wong, F. Stajano: “Multi-Channel Protocols”]
Mobile Systems Security 40 Page 40
MANA IV Preliminaries
In practice: c = HMACpk
(m), d = m
[S. Laur, K. Nyberg: “Efficient Manual Data Authentication using Manually Authenticated Strings: Extended Version”]
Mobile Systems Security 41 Page 41
MANA IV Details
[S. Laur, K. Nyberg: “Efficient Manual Data Authentication using Manually Authenticated Strings: Extended Version”]
Mobile Systems Security 42 Page 42
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
Mobile Systems Security 43 Page 43
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
Mobile Systems Security 44 Page 44
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
Mobile Systems Security 45 Page 45
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
Mobile Systems Security 46 Page 46
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]
Mobile Systems Security 47 Page 47
“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]
Mobile Systems Security 48 Page 48
Gesture-based Authentication
[S. N. Patel, J. S. Pierce, and G. D. Abowd: “A Gesture-based Authentication Scheme for Untrusted Public Terminals”, UIST 2004]
Mobile Systems Security 49 Page 49
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
Page 50
Cryptography on Mobile Java
Mobile Systems Security 51 Page 51
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
Mobile Systems Security 52 Page 52
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);
Mobile Systems Security 53 Page 53
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]
Mobile Systems Security 54 Page 54
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]
Mobile Systems Security 55 Page 55
Exchangeable in- and out-of-band channels
Mobile Systems Security 56 Page 56
Manual comparison of pseudo sentences
Mobile Systems Security 57 Page 57
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
Mobile Systems Security 58 Page 58
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
Mobile Systems Security 59 Page 59
Button presses demo
Mobile Systems Security 60 Page 60
Channels - Class Hierarchy
J2ME J2SE
Mobile Systems Security 61 Page 61
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
Mobile Systems Security 62 Page 62
UACAP
Mobile Systems Security 63 Page 63
UACAP Specification (1)
Mobile Systems Security 64 Page 64
UACAP Specification (2)
Mobile Systems Security 65 Page 65
UACAP Specification (3)
Mobile Systems Security 66 Page 66
UACAP Specification (4)
Mobile Systems Security 67 Page 67
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}
Mobile Systems Security 68 Page 68
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, ...)
Page 69
Usability of Mobile Applications
Mobile Systems Security 70 Page 70
Creative users - designed for user‘s needs?
Write on paper capture on photo send as MMS
Mobile Systems Security 71 Page 71
Real-world usability examples
CS Building in Saarbrücken DFKI in Saarbrücken
(Pho
tos
A.
But
z)
Mobile Systems Security 72 Page 72
Real-world usability examples
Signs and explanations for things that are usually obvious are an indicator for a potential problem.
(German Rail IC-Train)
Mobile Systems Security 73 Page 73
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]
Mobile Systems Security 74 Page 74
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.
Mobile Systems Security 75 Page 75
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)
Mobile Systems Security 76 Page 76
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
Mobile Systems Security 77 Page 77
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
Mobile Systems Security 78 Page 78
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)
Page 79
Android Security Concepts:
Basic Architecture, Sandboxing,
Application Permissions,
Calling Other App Activities,
System Database Security
iPhone vs. Android Comparison
Mobile Systems Security 80 Page 80
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)
Mobile Systems Security 81 Page 81
iPhone Security APIs
Mobile Systems Security 82 Page 82
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
Mobile Systems Security 83 Page 83
Android Architecture
Mobile Systems Security 84 Page 84
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
Mobile Systems Security 85 Page 85
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
Mobile Systems Security 86 Page 86
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
Mobile Systems Security 87 Page 87
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.
Mobile Systems Security 88 Page 88
Comparison of Mobile Platform Exploit Prevention Measures
Table by Nicolas Economou and Alfredo Ortega, Presentation “Smartphone (in)security” at CanSecWest 2009
Page 89
Android Rooting
Mobile Systems Security 90 Page 90
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
Mobile Systems Security 91 Page 91
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
Mobile Systems Security 92 Page 92
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
Mobile Systems Security 93 Page 93
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
Mobile Systems Security 94 Page 94
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)
Mobile Systems Security 95 Page 95
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.