Mario Čagalj University of Split 2013/2014. Understanding Android Security

Mario Čagalj

University of Split

2013/2014.

Understanding Android Security

Introduction

Application Security for the Android Platform by Jeff SixAndroid Security Underpinnings by Marko Gargenta

Produced by Mario Čagalj

Why Should You Care?As a developer you write mobile apps that

Allow people to access their social media accountsManage their email accounts and calendars in the cloud etc.

One day you read that personal details for thousands of users were compromised and posted onlinePasswords, personal preferences, photos, etc.Shortly after, you learn that a malicious Android app was looking for

unsecured database instances, like the one used in your app

Who is to blame? Obviously you, the developer!

3

Why Should You Care?Android app and poor use of the SSL/TLS protocol to

protect transmitted dataUpdated its virus signatures

via a broken SSL connection (failed to verify hostnames)

Hackers were able to create a virus signature for the anti-virus app itself and sent it to the phone

4Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security by Fahl et al., ACM CCS’12

What is Security About?Security is all about managing risk

Risk = Vulnerability + Threat + ConsequencesVulnerability – unintended and undesirable actionThreat – something/someone who can exploit a vulnerabilityConsequences – incurred loss

Open mobile platforms imply a high riskMalware, physical access to device (loss/theft), wireless comm.Lots of personal data on mobile devicesDetailed profiling of end users (high economic incentives)

5

Your RoleAs a developer you should be able to evaluate risk and

act accordingly, i.e., implement secure (Android) apps

The very first step is to understand how Android worksYou need to understand how your app will/will not interact with

other apps and the Android system itself

6

Android Architecture

Android Software Stack

8Unlocking Android by Frank Ableson, Charlie Collins and Robi Sen

Android Security FrameworkAndroid operating system security objectives

Protect user dataProtect system resources (including the network)Provide application isolation

To achieve these objectives, Android provides the following security featuresRobust security at the OS level through the Linux kernelApplication sandbox for all apps (application isolation)Secure interprocess communicationApplication signingApplication-defined and user-granted permissions

9

Linux Security ObjectivesLinux kernel is the foundation of the Android platform

Linux is a multiuser operating system, with the main security objective to mutually isolate different usersPrevents user A from reading user B’s fileEnsures that user A does not exhaust user B’s memory/CPU

resources

Central to Linux and Android security are concepts ofDiscretionary Access Control (DAC) – used to isolate apps (Linux)Mandatory Access Control (MAC) – used to mediate the

establishment of inter-component/application communication (Android middleware)

10

Access ControlComputer Security: Principles and Practiceby William Stallings and Lawrie BrownAccess Control: Principles and Practiceby Ravi S. Sandhu and Pierangela SamaratiInformation Security and Trust: Access Controlby Yingjiu Li


Access ControlConstraints what a user can do directly, as well as what

programs executing on behalf of the users are allowed to do, with the goal toPrevent activity that could lead to breach of securityProtect against accidental and malicious threats by regulating the

reading, writing and execution of data and programs

Central element of computer security

12

AC is enforced by a reference monitor which mediates every attempted access by a user/process to system objects

Reference monitor consults access rights/authorization database in to check if user is authorized for the requested operation

Access Control (AC) Principles

13

Reference monitor

Authorization database

Access control ObjectsAuthentication

Auditing

Security admin.

User

Discretionary Access Control (DAC)User-oriented security policy (based on identity of requestor)Entity has rights to enable another entity to access a resource

Mandatory Access Control (MAC)Access permissions are defined by a system itself (e.g. RECEIVE_SMS)Based on comparing security labels of system resources with security

clearances/permissions of entities accessing the resourcesCleared entity cannot pass on access rights to another entity

Other policies are outside of our scope

Access Control Policies

14

Subject – entity that can access objectsA process representing user/application

Object – access controlled resourceE.g. files, directories, records, processes, memory segments, pages,

directory trees, mailboxes etc.

Access right – a way in which subject accesses an objectE.g. read, write, execute, delete, create, search

Access Control Elements

15

Discretionary Access Control (DAC)

User-oriented security policy (based on ID of requestor)

Discretionary because an owning entity has rights to enable another entity to access a resource

General approach as used in operating systems is that of an access matrixLists subjects in one dimension (rows)Lists objects in the other dimension (columns)Matrix entries specify access rights of subjects to objects

Discretionary Access Control

17

Access Matrix: Example

18

Subjects

Objects

User A

File 1

OwnReadWrite

File 2 File 3 File 4

User B

User C

OwnReadWriteOwn

ReadWrite Own

ReadWrite

Read Read

Read

Write

ReadWrite

Access rights

Used to efficiently store the access matrix

Access Control Lists (ACL)

User A

File 1

OwnReadWrite

File 2 File 3 File 4

User B

User C

OwnReadWrite

OwnReadWrite

OwnReadWrite

Read Read

Read

Write

ReadWrite

File 1

19

File 2

File 3

File 4

Access rights stored with objects

Linux and Windows use ACLs to protect files/processes

Access Control Lists (ACL)

20

Linux Access Matrix: Example

21

Subjects

Objects

user (u)

File 1

rwx

File 2 Dir 1 Dir 2

group (g)

other (o)

r--

rw-

Access rights

r – read file or directory

w – write to file or directory

x – execute file or search directory

-wxrwx

---

rwxrwx

rwx

rwx---

---

owner

3 types of users (subjects)u – user who owns a fileg – group user (all the members of the group g)o – all other users

3 types of permissions (access rights)r – read file or directoryw – write to file or directoryx – execute file or search directory

Given a file (object), each of the 3 access rights can be set for any of 3 the types of users by the file owner (u)

Almost everything in Linux is viewed as a file

Linux Discretionary Access Control

22

Linux Discretionary Access Control

23

/home/mcagalj$ ls -l -htotal 468K-rw-r--r-- 1 mcagalj fesb 212K 2008-05-16 11:52 amrnb-6.1.0.1.tar.bz2drwxr-xr-x 3 mcagalj fesb 4.0K 2011-02-03 16:24 bkup-rw------- 1 mcagalj fesb 542 2007-05-22 10:26 Drafts-rw-r--r-- 1 mcagalj fesb 0 2010-12-06 10:32 fingerdrwx------ 3 mcagalj fesb 4.0K 2012-12-04 21:37 maildrwx------ 1916 mcagalj fesb 228K 2011-11-05 22:35 Maildirdrwxr-xr-x 2 mcagalj fesb 4.0K 2006-08-01 15:26 MailFoldersdrwxr-xr-x 34 mcagalj fesb 4.0K 2013-12-19 15:48 public_html

/home/mcagalj$ ls -l -htotal 468K-rw-r--r-- 1 mcagalj fesb 212K 2008-05-16 11:52 amrnb-6.1.0.1.tar.bz2drwxr-xr-x 3 mcagalj fesb 4.0K 2011-02-03 16:24 bkup-rw------- 1 mcagalj fesb 542 2007-05-22 10:26 Drafts-rw-r--r-- 1 mcagalj fesb 0 2010-12-06 10:32 fingerdrwx------ 3 mcagalj fesb 4.0K 2012-12-04 21:37 maildrwx------ 1916 mcagalj fesb 228K 2011-11-05 22:35 Maildirdrwxr-xr-x 2 mcagalj fesb 4.0K 2006-08-01 15:26 MailFoldersdrwxr-xr-x 34 mcagalj fesb 4.0K 2013-12-19 15:48 public_html

Each user in a Linux system is assigned a unique user ID (UID) and a group ID (GID) when they are created

Each user UID’s resource is assigned the same UIDprocess, file, directory, etc.

Linux Security Model

24

/home/mcagalj$ iduid=10239(mcagalj) gid=201(fesb) groups=201(fesb)/home/mcagalj$ iduid=10239(mcagalj) gid=201(fesb) groups=201(fesb)

/home/mcagalj$ iduid=10239(mcagalj) gid=201(fesb) groups=201(fesb)

/home/mcagalj$ ps -o pid,ppid,args,uid -p 6822 PID PPID COMMAND UID 6822 6820 sshd: mcagalj@pts/1 10239


/home/mcagalj$ ps -o pid,ppid,args,uid -p 6822 PID PPID COMMAND UID 6822 6820 sshd: mcagalj@pts/1 10239

Each user UID’s resource is assigned the same UID, GIDprocess, file, directory, etc.


25


/home/mcagalj$ ps -o pid,ppid,args,uid,euid,fsuid,gid -p 6822 PID PPID COMMAND UID EUID FSUID GID 6822 6820 sshd: mcagalj@pts/1 10239 10239 10239 201

/home/mcagalj$ ls -l -htotal 468Kdrwx------ 3 mcagalj fesb 4.0K 2012-12-04 21:37 maildrwx------ 1916 mcagalj fesb 228K 2011-11-05 22:35 Maildirdrwxr-xr-x 2 mcagalj fesb 4.0K 2006-08-01 15:26 MailFoldersdrwxr-xr-x 34 mcagalj fesb 4.0K 2013-12-19 15:48 public_html


/home/mcagalj$ ps -o pid,ppid,args,uid,euid,fsuid,gid -p 6822 PID PPID COMMAND UID EUID FSUID GID 6822 6820 sshd: mcagalj@pts/1 10239 10239 10239 201

/home/mcagalj$ ls -l -htotal 468Kdrwx------ 3 mcagalj fesb 4.0K 2012-12-04 21:37 maildrwx------ 1916 mcagalj fesb 228K 2011-11-05 22:35 Maildirdrwxr-xr-x 2 mcagalj fesb 4.0K 2006-08-01 15:26 MailFoldersdrwxr-xr-x 34 mcagalj fesb 4.0K 2013-12-19 15:48 public_html

user’s primary group

user’s primary group

Each User’s resource is assigned the same UIDprocess, file, directory, etc.

Every process running on a Linux system, executes on behalf of a given User who is identified by a unique UIDThus, the process may do what this User is allowed to doThe process may access the Files that its User-owner may access

On each access by a user or process to a given resource, the Linux kernel enforces the access control policy based on the access rights and the requestor’s UID/GUIDThe Linux kernel acts as a reference monitor


26

Android Application Isolation (Sandboxing)

Android Application SandboxingThe application sandbox specifies which system

resources the application is allow to access

On Android, sandboxing is enforced by the Linux kernelEach application is isolated in its own sandboxEach app is assigned a unique user ID (UID) and

runs as that user (UID) in a separate process

On Android each app is effectivelly a different userSome exceptions are possible (e.g., android:sharedUserId)

28

Linux kernel

Linux process

Dalvik VM

Android app

Android Application SandboxingWhen an Android package is installed

A new user ID (UID) is created

All data stored by the app have the same UID (e.g., dir, files, DBs, etc.)

29

<package name="com.example.hellofesb“ codePath="/data/app/HelloFESB.apk“ … userId="10051"> <sigs count="1">

<cert index="4" key="3082030d30820…37cf0aa3a31243230f4e48f"/> </sigs> </package>



root@generic_x86:/data/data # ll | grep 'fesb'drwxr-x--x u0_a51 u0_a51 2014-01-15 03:26 com.example.hellofesb

root@generic_x86:/data/data/com.example.hellofesb # lldrwxrwx--x u0_a51 u0_a51 2014-01-15 03:26 cachedrwxrwx--x u0_a51 u0_a51 2014-01-15 03:26 files

root@generic_x86:/data/data # ll | grep 'fesb'drwxr-x--x u0_a51 u0_a51 2014-01-15 03:26 com.example.hellofesb

root@generic_x86:/data/data/com.example.hellofesb # lldrwxrwx--x u0_a51 u0_a51 2014-01-15 03:26 cachedrwxrwx--x u0_a51 u0_a51 2014-01-15 03:26 files

PackageManager packages.xml file

owner group

Android Application SandboxingWhen an Android package is installed

A new user ID (UID) is created

All data stored by the app have the same UID (e.g., dir, files, DBs, etc.)

The new app (the corresponding process) runs under the same UID

30





root@generic_x86:/data/data/com.example.hellofesb # ps | grep 'fesb'u0_a51 1983 924 257736 31060 fffffff b76eff2b com.example.hellofesbroot@generic_x86:/data/data/com.example.hellofesb # ps | grep 'fesb'u0_a51 1983 924 257736 31060 fffffff b76eff2b com.example.hellofesb

PackageManager packages.xml file

owner

Android Application SandboxingBy default, app cannot adversely affect other apps,

processesE.g. read/write user data, modify other apps '/system' files and

settings, access network, keep the device awake, etc.

31

user ID (UID)

The restrictions applyeven to native codethat runs outside ofthe Dalvik VM!

The restrictions applyeven to native codethat runs outside ofthe Dalvik VM!

Demo: Android Filesystem Isolation

32

…# ps | grep 'hellofesb'u0_a56 1889 … com.example.hellofesb…# ll-rw-rw---- u0_a56 … FESB.txt




Benefits of Application SandboxingIn 2008 the Web browser vulnerability discovered

By Charlie Miller, Mark Daniel, and Jake Honoroff of ISEThe first commercial Android phone, the T-Mobile G1 by HTC, shipped

with the vulnerability

The impact:”...Upon visiting the malicious site, the attacker can run any code they wish with the privileges of the web browser application...

The Android security architecture is very well constructed and the impact of this attack is somewhat limited by it. ... attacker will have access to any information the browser may use, such as cookies ... saved passwords, etc. ... However, [he] can not control other, unrelated aspects of the phone, such as dialing the phone directly. This is in contrast, for example, with Apple's iPhone which does not have this application sandboxing feature...”

33http://securityevaluators.com/knowledge/case_studies/android/index.php

Android Filesystem Isolation: Cautionary NoteData written to external storage (such as SD cards) lacks

Linux discretionary access controlAny file written to external storage is accessible by any app on the

device (and by any other external device supporting such storage)

Consider encrypting such files/data

34

Playing Outside the SandboxAndroid provides permission system that restricts what

apps can do if they want to play outside the sandboxApps statically declare permissions they needThe Android system prompts the user for consent at install-time

More on permissions in the next lecture…35

root@generic_x86:/ # pm list permissions -ggroup:android.permission-group.NETWORK … permission:android.permission.NFC permission:android.permission.CHANGE_WIFI_STATE permission:android.permission.ACCESS_WIFI_STATE permission:android.permission.INTERNET

root@generic_x86:/ # pm list permissions -ggroup:android.permission-group.NETWORK … permission:android.permission.NFC permission:android.permission.CHANGE_WIFI_STATE permission:android.permission.ACCESS_WIFI_STATE permission:android.permission.INTERNET

Playing Outside the SandboxApps can explicitly share resources/data via

ContentProviders, Intents, Inter-Process Communication (IPC), local network sockets, or the file system

36

ICC – Inter-Component CommunicationDAC – Discretionary Access ControlMAC – Mandatory Access Control

Android Application Signing

All Android apps must be digitally signed prior to installationThe developer signs the corresponding *.apk file using his/her

digital certificate (i.e., the corresponding private key)

Android uses the digital certificate as a means ofIdentifying the developer of an application

Used to ensure the authenticity of future application updates (same origin policy)

Establishing trust relationships between applicationsApplications signed with the same certificate can share, for example,

the user ID (i.e., file system resources) and runtime process

Application Signing

38

APK is the file format used to distribute and install apps and middleware onto Android OS APK files are ZIP archives based on JAR (Java ARchive format) Bundle together compiled Android classes (.dex), metadata (in META-INF/ directory)

and resources the code uses

Android Application Package File (APK)

39

C:\FESB\teaching\2013_2014\AndroSec\code>aapt list HelloFESB.apk

res/drawable/fesb_button.xmlres/layout/activity_main.xmlres/menu/main.xmlAndroidManifest.xmlresources.arscres/drawable-hdpi/ic_launcher.pngres/drawable-mdpi/ic_launcher.pngres/drawable-xhdpi/ic_launcher.pngres/drawable-xxhdpi/ic_launcher.pngclasses.dexMETA-INF/MANIFEST.MFMETA-INF/CERT.SFMETA-INF/CERT.RSA

C:\FESB\teaching\2013_2014\AndroSec\code>aapt list HelloFESB.apk


META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity The signing process is based on cryptographic hash functions (e.g., SHA1) and

public-key cryptography

APK Meta Information (META-INF/)

40

C:\...\META-INF>more MANIFEST.MF

Name: res/drawable-xhdpi/ic_launcher.pngSHA1-Digest: vWrq4ApK74D3ktrs7+elAA8A1a8=

Name: AndroidManifest.xmlSHA1-Digest: zdtiD7i7BR8in+Iu1oE3Hv3GlnY=

…

Name: res/layout/activity_main.xmlSHA1-Digest: cg8ZwPxIycCc6xS0P6DEjhCBusA=

Name: classes.dexSHA1-Digest: IBvlm6sUhzUibItLsfEdRAnQ0zg=




…



C:\...\META-INF>more CERT.SFSHA1-Digest-Manifest: bFgRd0zf0ZHRZOr71smRiPIoo+I=

Name: res/drawable-xhdpi/ic_launcher.pngSHA1-Digest: iXOQFkCAFFovdXQunW5Lj2sge4k=

Name: AndroidManifest.xmlSHA1-Digest: SzwnLPA+WyeFvnDNHiognCbm7to=

…

Name: res/layout/activity_main.xmlSHA1-Digest: /izaF34OgiteuhCmykT3c82WmQs=

Name: classes.dexSHA1-Digest: tW37HMcEZ0S4daTE9i65fL5DoMk=

C:\...\META-INF>more CERT.SFSHA1-Digest-Manifest: bFgRd0zf0ZHRZOr71smRiPIoo+I=



…



META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity The signing process is based on cryptographic hash functions (e.g., SHA1) and

public-key cryptography

APK Meta Information (META-INF/)

41

C:\...\META-INF>keytool -printcert -file CERT.RSA

Owner: CN=Android Debug, O=Android, C=USIssuer: CN=Android Debug, O=Android, C=USSerial number: 33ac9dfaValid from: Thu Jan 09 16:41:38 CET 2014 until: Sat Jan 02 16:41:38 CET 2044Certificate fingerprints: MD5: A3:12:E2:09:D7:AF:88:AC:6F:0A:BF:C8:79:82:4A:86 SHA1: 95:1C:B1:D0:4E:3D:57:FA:89:39:54:27:35:DC:25:53:8B:62:24:D0 SHA256: A3:32:FB:6F:4D:37:5D:A3: ... :07:26:03:6C:EA:91:06:FC:9D Signature algorithm name: SHA256withRSA Version: 3

C:\...\META-INF>keytool -printcert -file CERT.RSA

Owner: CN=Android Debug, O=Android, C=USIssuer: CN=Android Debug, O=Android, C=USSerial number: 33ac9dfaValid from: Thu Jan 09 16:41:38 CET 2014 until: Sat Jan 02 16:41:38 CET 2044Certificate fingerprints: MD5: A3:12:E2:09:D7:AF:88:AC:6F:0A:BF:C8:79:82:4A:86 SHA1: 95:1C:B1:D0:4E:3D:57:FA:89:39:54:27:35:DC:25:53:8B:62:24:D0 SHA256: A3:32:FB:6F:4D:37:5D:A3: ... :07:26:03:6C:EA:91:06:FC:9D Signature algorithm name: SHA256withRSA Version: 3

Cryptographic Hash Functions andPublic-Key Cryptography

Secure (Cryptographic) Hash FunctionsA hash function accepts a variable-size input message

m and produces a fixed-size message digest (a hash value)

43

... Message m of a variable length ...

Hash value/message digest/hash code(fixed length)

Hashfunction

hm = H(m)

Secure (Cryptographic) Hash FunctionsA hash function accepts a variable-size input message

m and produces a fixed-size message digest (a hash value)

44

C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest.xml | openssl base64zdtiD7i7BR8in+Iu1oE3Hv3GlnY=

C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest_MODIFIED.xml | openssl base647FK0VT/21ki6OMw+WPYBLunahI0=

C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest.xml | openssl base64zdtiD7i7BR8in+Iu1oE3Hv3GlnY=

C:\...\META-INF>openssl sha1 -binary ..\AndroidManifest_MODIFIED.xml | openssl base647FK0VT/21ki6OMw+WPYBLunahI0=


…


…


…


…

Hash Function RequirementsHash functions produce a unique fingerprint of a message m

Easy to generate a hash value for any input message m

One-way propertyGiven hash value h, computationally infeasible to find m such that H(m) = hVirtually impossible to find a message given the hash code/value

Weak-collision resistanceGiven m, it is practically impossible to find m such that H(m) = H(m)

Strong-collision resistancePractically impossible to find a pair (m, m) such that H(m) = H(m)

45

An example of the use of a hash function to authenticate a given message m

Authentication with a Hash Function

46

m

K

E

K

D

ll

H

m

H

Compare

Source

Destination

Hash function

Encryption algorithm

Decryption algorithm

E[K, H(m)]

Hash FunctionsGiven the properties, a hash value (message digest) can

prove both source and message integrity

SHA is the most widely used hash algorithmSHA-1 gives 160-bit hash value (some attacks discovered recently)SHA-256, SHA-384, SHA-512 provide improved size and securityOther hash functions MD2, MD4 (not in use) and MD5 (insecure, but

still in use)

47

Some Applications of Hash FunctionsPassword hashing

Store a password hash value instead of the password itselfAttacker cannot invert the hash function (one-way property)

Ensuring integrity of a piece of software (Android)

Efficient digital signatures

Digital currency (Bitcoins)

48

Public-Key vs. Symmetric EncryptionSymmetric key encryption KEnc = KDec

Public-key encryption KEnc ≠ KDec

49

Encryption Decryption

Key Generation

Plaintext Ciphertext Plaintext

KEnc KDec

MessageChannelKey

Channel

Public-Key EncryptionPublic-key cryptography is asymmetric

Involves the use of two separate keys (symmetric only one)Public key (all have access to it) and private key (only known by the

owner)If one key is used for encryption, the other one is used for

decryption (both keys can be used for both encryption and decryption)

50

Public-Key Crypto: Confidentiality

Party B generates a pair of keys (PUB, PRB) PUB – B’s public key, PRB – B’s private key

PUB is a public information (avaliable to all, including entity A)

Private key PRB known only to B (A does not know PRB)

Protecting confidentiality: A sends a secret message m to B A encrypts m with public key PUB: c = E[PUB, m]

B decrypts c using his private key PRB: m=D[PRB, c] = D[PRB, E[PUB, m]]

Nobody else can decrypt ciphertext c (only B holds PRB) 51


Key Generation

m c m

PUB PRB

MessageChannelKey

Channel

Source A Destination B

Public-Key Crypto: Integrity

Authentication and integrity: Entity A wants to send authenticated message m to B A encrypts m using her own private key PRA: c = E[PRA, m]

B decrypts ciphertext c using A’s public key PUA : m = D[PUA, c]

Only A knows PRA, so only A could have produces valid (decryptable) c - source authentication The whole ciphertex c serves as a digital signature If in addition it would not be possible to change m without knowing the private key PRA, then

m would also be authentic in the sense of data integrity52


Key Generation

m c m

PRA PUA

MessageChannel Key

Channel


Public-Key Crypto: Confident. & Integrity

Confidentiality and authentication: A wants to send authenticated and secret message m to B We can realize this by using two pairs of (PU,PR) keys A encrypts m as follows: c = E[PRA, m], c’ = E[PUB, E[PRA, m]]

B decrypts cihpertext c’ as follows: c = D[PRB, c’], m = D[PUA, c]

53

Key Generation


Encryptionm Encryption Decryption Decryption m

Key Generation

PUB PRBPRA PUA

c c’ c

Some Public-Key AlgorithmsRSA (Rivest, Shamir, Adleman)

Developed in 1977Only widely accepted public-key encryption algorithmSecurity requires keys of size > 1024-bit (300 decimal digits)

Diffie-Hellman key exchange algorithmOnly allows secure exchange of a secret key (no encryption)

Digital Signature Standard (DSS)Provides only a digital signature function with hash f. SHA-1

Elliptic curve cryptography (ECC)New, security like RSA, but with much smaller keys

54

Digital Signature: “Hash and Sign”

HH EncEnc

private key (PR)of the sender

message hash signature

HHmessage hash

DecDec

public key (PU)of the sender

signature

CompareCompare

yes/no

gene

ratio

nve

rifica

tion

55

hash

signed message

Public-Key CertificatesCertificate structure

Public keyPublic key ownerCertificate IssuerDate of issuingCertificate validity periodOther information (type,

standards,...)Digital signature of the

certificate issuer

56

Certification Authority’s (CA)private key

Unsigned certificate

Signed certificate:Recipient can verify signature using CA’s public key

H

Hash function

E

Public-key encryption algorithm

Verifying Public-Key Certificates

57

Bob’s ID information

Bob’s public key PUB

Certification Authority (CA) Info.

Signed certificate

H

Hash function

Generate hash value of unsigned certificate

Encrypt hash value with CA’s private key PRCA to form signature

E

H

D

Decrypt signature with CA’s public key PUCA to recover hash value

Compare

Create signed digital certificate Use certificate to verify Bob’s public key PUB

Self-signed CertificatesCertificate structure

Public key (your key)Public key owner (you)Certificate IssuerDate of issuingCertificate validity periodOther information (type,

standards,...)Digital signature of the

certificate issuer

58

Unsigned certificate

Signed certificate:Recipient can verify signature using the Public key owner’s (your) public key

H

Hash function

ECertification Authority’s (CA)private key

Public key owner’s (your) private key

Public-key encryption algorithm

Example: Certificate from the APK File

59

C:\...\META-INF>openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -textC:\...\META-INF>openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -text

How APK File (its content) is Signed?res/drawable/fesb_button.xmlres/layout/activity_main.xmlres/menu/main.xmlAndroidManifest.xmlresources.arscres/drawable-hdpi/ic_launcher.pngres/drawable-mdpi/ic_launcher.pngres/drawable-xhdpi/ic_launcher.pngres/drawable-xxhdpi/ic_launcher.pngclasses.dexMETA-INF/MANIFEST.MFMETA-INF/CERT.SFMETA-INF/CERT.RSA




…





…



SHA1-Digest-Manifest: bFgRd0zf0ZHRZOr71smRiPIoo+I=



…



SHA1-Digest-Manifest: bFgRd0zf0ZHRZOr71smRiPIoo+I=



…



SHA-1

. . .

SHA-1

. . .

SHA-1- PKCS#7 Certificate - Signature- PKCS#7 Certificate - Signature

PKCS#7sign

HelloFESB.apk META-INF/MANIFEST.MF

META-INF/CERT.SF

META-INF/CERT.RSA

. . .

SHA-1

Android Application Signing: Step-by-step (JDK keytool and jarsigner)

Application signing begins by generating a private and public key pair and a related public-key certificateOn Android, certificates can be self-signed

Application Signing: Step 1

C:\...\AndroSec\code>keytool -genkey -v -keyalg RSA -alias fesb -keystore fesb.keystore –validity 10000

C:\...\AndroSec\code>keytool -list -v -keystore fesb.keystore

Certificate[1]:Owner: CN=Mario Cagalj, OU=Andro, O=FESB, L=Split, ST=Croatia, C=HRIssuer: CN=Mario Cagalj, OU=Andro, O=FESB, L=Split, ST=Croatia, C=HRSerial number: 262e3f3fValid from: Thu Jan 16 15:34:26 CET 2014 until: Mon Jun 03 16:34:26 CEST 2041Certificate fingerprints: MD5: A6:2B:D7:F3:70:07:71:6A:FF:59:A9:E5:46:1F:0F:2C SHA1: A5:ED:D9:9C:AA:AE:70:19:0E:9D:F6:42:D5:8C:31:13:D9:0F:8F:0E...

C:\...\AndroSec\code>keytool -genkey -v -keyalg RSA -alias fesb -keystore fesb.keystore –validity 10000

C:\...\AndroSec\code>keytool -list -v -keystore fesb.keystore

Certificate[1]:Owner: CN=Mario Cagalj, OU=Andro, O=FESB, L=Split, ST=Croatia, C=HRIssuer: CN=Mario Cagalj, OU=Andro, O=FESB, L=Split, ST=Croatia, C=HRSerial number: 262e3f3fValid from: Thu Jan 16 15:34:26 CET 2014 until: Mon Jun 03 16:34:26 CEST 2041Certificate fingerprints: MD5: A6:2B:D7:F3:70:07:71:6A:FF:59:A9:E5:46:1F:0F:2C SHA1: A5:ED:D9:9C:AA:AE:70:19:0E:9D:F6:42:D5:8C:31:13:D9:0F:8F:0E...

62Publishing on the Android Market requires the end period > 22 October 2033.

A note of caution: safeguard your private key

If the private key is lost or compromisedA third party could sign and distribute applications that

maliciously replace/change your authentic applications Such a person could steal user data under your identityYour private key is required for signing all future versions of

your application (lost private key means no application updates)

You cannot regenerate a previously generated key

Your reputation as a developer is dependent on that key


63

Sign your application with your private key


64

C:\...\AndroSec\code>jarsigner -verbose -keystore fesb.keystore HelloFESB.apk fesbEnter Passphrase for keystore: adding: META-INF/MANIFEST.MF adding: META-INF/FESB.SF adding: META-INF/FESB.RSA signing: res/drawable/fesb_button.xml signing: res/layout/activity_main.xml signing: res/menu/main.xml signing: AndroidManifest.xml signing: resources.arsc signing: res/drawable-hdpi/ic_launcher.png signing: res/drawable-mdpi/ic_launcher.png signing: res/drawable-xhdpi/ic_launcher.png signing: res/drawable-xxhdpi/ic_launcher.png signing: classes.dex

C:\...\AndroSec\code>jarsigner -verbose -keystore fesb.keystore HelloFESB.apk fesbEnter Passphrase for keystore: adding: META-INF/MANIFEST.MF adding: META-INF/FESB.SF adding: META-INF/FESB.RSA signing: res/drawable/fesb_button.xml signing: res/layout/activity_main.xml signing: res/menu/main.xml signing: AndroidManifest.xml signing: resources.arsc signing: res/drawable-hdpi/ic_launcher.png signing: res/drawable-mdpi/ic_launcher.png signing: res/drawable-xhdpi/ic_launcher.png signing: res/drawable-xxhdpi/ic_launcher.png signing: classes.dex

Optimizing your application and verifying the signatureRead more on http://developer.android.com

Your application is ready to be uploaded to the Android Market


65

C:\...\AndroSec\code>zipalign -v 4 HelloFESB.apk HelloFESBalig.apk

C:\...\AndroSec\code>jarsigner -verify HelloFESB.apkjar verified.

C:\...\AndroSec\code>zipalign -v 4 HelloFESB.apk HelloFESBalig.apk

C:\...\AndroSec\code>jarsigner -verify HelloFESB.apkjar verified.

Normally, users can update an already installed appYour tasks as a developer

Increment the android:versionCode and android:versionName attributes The package name must be the same and the .apk must be signed with the same

private key If the package name and signing certificate do not match those of the existing

version, the Android Market will consider it a new application and will not offer it to users as an update

Why can’t I update my app?!

66

Demo: Android App Update

67

Basic version New/updated version

Here, we are just simulating the updating process on the emulator using adb toolHere is what happens if we try to update the old app with the new

one that is signed with a different private key

Demo: Android App Update

68

C:\FESB\teaching\2013_2014\AndroSec\code>adb install -r HelloFESBv1.apk74 KB/s (287733 bytes in 3.796s) pkg: /data/local/tmp/HelloFESBv1.apkFailure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]

C:\FESB\teaching\2013_2014\AndroSec\code>adb install -r HelloFESBv1.apk74 KB/s (287733 bytes in 3.796s) pkg: /data/local/tmp/HelloFESBv1.apkFailure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]

Android Permission Model

An In-Depth Introduction to the Android Permission Model by Jeff SixAndroid Security Architecture by Ahmad-Reza SadeghiUnderstanding Android Security by Enck, Ongtang and McDaniel


We know from before that by default each app has access only to its own components and dataLinux kernel enforces this (provides app isolation) Applications have no access to the components of the system

Access to the system resources and to the components of other application can be gained if the application has required permissions

Introduction

70

Security Enforcement in Android

71

Android applications

HelloFESB app HelloIPC app…

Linux kernel

ICC reference monitor

Android middlewareuser: u0_a52home: data/data/hellofesb

user: u0_a53home: data/data/helloipc

The Linux-kernel provides DAC – Discretionary Access Control.The Android middleware provides MAC – Mandatory Access Control. (ICC stands for Inter-Component Communication).

Discretionary Access Control (DAC)User-oriented security policy (based on identity of requestor)Entity has rights to enable another entity to access a resource

Mandatory Access Control (MAC)Access permissions/labels are defined by a system itself

e.g., android.permission.RECEIVE_SMS, android.permission.INTERNET

Based on comparing security labels of system resources with security clearances/permissions of entities accessing the resources

Cleared entity cannot pass on access rights to another entity

Access Control Policies

72

Core idea of Android security enforcement - labels assignment to applications and componentsAccess to each component is restricted by assigning it an access

permission labelA reference monitor provides mandatory access control (MAC)

enforcement of how applications access components (with some exceptions)

When a component initiates inter-component communication (ICC), the reference monitor looks at the permission labels assigned to its containing application and — if the target component’s access permission label is in that collection — allows ICC


73

Security Enforcement: Example

Example: Access permission logic. The Android middleware implements a reference monitor providing mandatory access control (MAC) enforcement about how applications access components. The basic enforcement model is the same for all component types. Component A’s ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application 1.

Not all system permissions are enforced at the Android middleware (i.e., by the ICC reference monitor)

Some important permissions are mapped to Linux GIDsThe UID of the app that is granted such a permission is added (at the

installation time) to the corresponding Linux group


75

# cat /system/etc/permissions/platform.xml... <permission name="android.permission.BLUETOOTH" > <group gid="net_bt" /> </permission>

<permission name="android.permission.INTERNET" > <group gid="inet" /> </permission>

<permission name="android.permission.READ_EXTERNAL_STORAGE" > <group gid="sdcard_r" /> </permission>

# cat /system/etc/permissions/platform.xml... <permission name="android.permission.BLUETOOTH" > <group gid="net_bt" /> </permission>

<permission name="android.permission.INTERNET" > <group gid="inet" /> </permission>

<permission name="android.permission.READ_EXTERNAL_STORAGE" > <group gid="sdcard_r" /> </permission>

Applications declare (in their manifest file) which permissions they request/require When an application is installed, the Android system will present this

list to the user, who must decide to allow the installation or not This is an all-or-nothing decision; the user can install the app or not,

but cannot choose to install it with reduced permissions

Specifying Required Permissions

76

<manifest xmlns:android=“http://schemas.android.com/apk/res/android” package=“com.example.hellofesb”> … <uses-permissionandroid:name=“android.permission.INTERNET”/> … </manifest>

<manifest xmlns:android=“http://schemas.android.com/apk/res/android” package=“com.example.hellofesb”> … <uses-permissionandroid:name=“android.permission.INTERNET”/> … </manifest>

Listing Android Permissions: Example

77

# pm list permissions -d -gDangerous Permissions:

...

group:android.permission-group.DISPLAY permission:android.permission.SYSTEM_ALERT_WINDOW

group:android.permission-group.CAMERA permission:android.permission.CAMERA

group:android.permission-group.COST_MONEY

group:android.permission-group.NETWORK permission:android.permission.NFC permission:android.permission.CHANGE_WIFI_STATE permission:android.permission.CHANGE_WIMAX_STATE permission:android.permission.INTERNET

...

# pm list permissions -d -gDangerous Permissions:

...

group:android.permission-group.DISPLAY permission:android.permission.SYSTEM_ALERT_WINDOW

group:android.permission-group.CAMERA permission:android.permission.CAMERA

group:android.permission-group.COST_MONEY

group:android.permission-group.NETWORK permission:android.permission.NFC permission:android.permission.CHANGE_WIFI_STATE permission:android.permission.CHANGE_WIMAX_STATE permission:android.permission.INTERNET

...

Android permissions fall into four levels: Normal – cannot impart real harm to the user (e.g. change the

wallpaper); apps need to request them, but automatically granted

Dangerous – can impart real harm (e.g. call numbers, open Internet connections) and apps need to request them with user confirmation.

Signature – these are automatically granted to a requesting app if that app is signed by the same certificate as that which declared the permission (see the demo later)

Signature/System – same as Signature, except that the system image gets the permissions automatically as well (for use by device manufacturers only)

Android Permission Levels

78

Custom Permissions and Application Component Security

As you well know, Android apps are composed of one or more components of the following typeActivity – provide a user interface

Service – executes background processing

Content Provider – facilities data storage

Broadcast Receiver – acts as a mailbox for messages from other apps

Android Application Components

80

Intent - primary mechanism for component interaction Message object containing a destination component address and dataExample com.example.hellofesb: the MainActivity activity

starts SecureStoreActivity and passes data plaintext

Inter-Component Communication (ICC)

81

Intent secureStoreIntent = new Intent(this, SecureStoreActivity.class); secureStoreIntent.putExtra(PLAINTEXT, plaintext); this.startActivity(secureStoreIntent);

Intent secureStoreIntent = new Intent(this, SecureStoreActivity.class); secureStoreIntent.putExtra(PLAINTEXT, plaintext); this.startActivity(secureStoreIntent);

com.example.hellofesb

MainActivity SecureStoreActivity

Each Android component can be either public or privateIf it is public, other components (from other apps) can interact with it If it is private, the only components that can interact with it are those

that are part of the same app (or one that runs with the same UID)

By default, a component … … is public if it specifies a filter to receive implicit Intents or its

exported attribute (in the manifest) is set to true … otherwise, it is private

Inter-Component Communication (ICC)

82

Example: Starting a Private Component

83

<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:exported = “false" > </activity>

<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:exported = “false" > </activity>

com.example.helloipc com.example.hellofesb

MainActivity

Intent launchIntent = new Intent(); launchIntent.setClassName("com.example.hellofesb",

"com.example.hellofesb.SecureStoreActivity");launchIntent.putExtra("MESSAGE", "Regards from Hello IPC!");this.startActivity(launchIntent);



SecureStoreActivity

Example: Starting a Public Component

84

<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:exported = “true" > </activity>

<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:exported = “true" > </activity>







We conclude that any component that is public can be accessed by any component in any app on the deviceGlobal access is sometimes necessary (e.g., the main activity is public

so that the app can be started)In many cases, however, we should be able to control which

components in other apps can access “our” component

Custom-defined permission can be used to restrict access to various components/services

Restricting Access to Components

85

We would like to prevent that an arbitrary app (HelloIPC) can start the public SecureStoreActivity activity (HelloFESB)First, a permission must be declared in the HelloFESB manifest fileSecond, include the permission attribute in the manifest for the

activity that has to be protected

Custom Permissions: Example

86

<permission android:name="com.example.hellofesb.MY_PERMISSION" android:protectionLevel="dangerous"></permission>...<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:permission="com.example.hellofesb.MY_PERMISSION" ... android:exported = "true"> <intent-filter></intent-filter></activity>

<permission android:name="com.example.hellofesb.MY_PERMISSION" android:protectionLevel="dangerous"></permission>...<activity android:name = "com.example.hellofesb.SecureStoreActivity" android:permission="com.example.hellofesb.MY_PERMISSION" ... android:exported = "true"> <intent-filter></intent-filter></activity>


87

com.example.helloipccom.example.hellofesb


"com.example.hellofesb.MY_PERMISSION"

However, if the developer of HelloIPC app learns and includes your custom permission in his app, we are back to the beginning


88

<uses-permission android:name="com.example.hellofesb.MY_PERMISSION"/><uses-permission android:name="com.example.hellofesb.MY_PERMISSION"/>



"com.example.hellofesb.MY_PERMISSION""com.example.hellofesb.MY_PERMISSION"

We would like to prevent that an arbitrary app (HelloIPC) can start the public SecureStoreActivity activity (HelloFESB)Only those apps developed by the same developer shoud be granted

this permissionSolution: we can elevate the protection level of our custom

permission from dangerous to signature


89


90

com.example.hellofesb


"com.example.hellofesb.MY_PERMISSION"

com.example.helloipc"com.example.hellofesb.MY_PERMISSION"

Signed by fesbSigned by fesb_2

Due to lack of time not studied here, but the same general ideas apply

For more details consider consulting the following source:

Securing other Component Types

91

An In-Depth Introduction to the Android Permission Model by Jeff Six

Confused deputy attacksIf you do not have a right permission, ask your neighborExample: MalwareApp with no permissions granted, invokes

BrowserApp (having INTERNET permission) to download malicious files

Attacks by colluding applicationsDivide necessary permissions among two or more appsExample: MalwareApp-1 has access to user LOCATION,

MalwareApp-2 has INTERNET permission and the two malware apps communicate (e.g., Intents, file sharing, etc.)

Security Weaknesses of Android Permissions

92

Protecting stored dataEncryption, hashing, password-based key derivation

Securing network communication and server interactionsSSL/TLS using HTTPSURLConnection()and SSLSocket()Many sources for (fatal) errors, so exercise caution

Other Important Security Aspects

93

Documents

Mario Čagalj University of Split 2013/2014. Understanding Android Security