mobile security · 2021. 4. 2. · ©2014 patrick tague 3 prerequisites v. assumptions • while...

©2014 Patrick Tague 1

Mobile SecurityFall 2014

Patrick Tague

Class #2 – Mobile Devices andGeneral Security Challenges


Class #2• A few reminders, announcements, and notes

• Decomposing a smartphone

• Some general S&P issues

• A 20-minute history of telecom security


Prerequisites v. Assumptions• While this course has no official prereqs, we make

several assumptions about you– You have taken a graduate-level Information Security

course (e.g., 14-741, 18-631, 18-730)– You have taken a graduate-level Networking course (e.g.,

14-740, 18-756, 15-641)– You are proficient in Java programming and either have

experience with Android or have time to learn it on your own

– We will not explicitly teach you these things– If you're not comfortable with these assumptions, talk to

me NOW. Maybe take the course next year.


Waitlists• If you're currently on the waitlist:

1) Make sure you're on the correct waitlist

2) Send me an email ([email protected]) detailing:1) What year/term of your program are you in (priority will go to

students closer to graduation)?

2) What degree requirements does this course fulfill?

3) Why you want to take this course?

4) What prereqs/qualifications do you have?

• TODAY is my deadline– If I don't get an email from you by 11:59:59PM PDT today,

I'll skip you and move down the list

mailto:[email protected]


Assignment #1 Posted• Not a programming assignment, but requires some

knowledge of how Android works

• Due on September 9 (via BB)

• Tasks:– Read some papers about intent-based attacks in Android– Design a malicious app based on what you read– Do a nice write-up of your design


Assignments #2-#4• You'll be doing active development, testing, and

analysis of Android applications

• Deadlines are all on the website, details will be posted there too

• Most likely, what you do in Assignment #1 will affect your work in Assignment #2, which may affect Assignment #3, which may affect Assignment #4...consider this fair warning


Course Projects• First project group presentation is in mid-

September form groups and choose topics soon!→– Mid-Sept presentation requires a literature survey,

forming a high-level problem statement, and prep

• Blackboard discussion forum– Discuss project topics, find common interests, form

teams, share related work, etc.

• Some additional HW available if needed


Android Devices• We will provide an Android phone or tablet (w/o

service) running Android 4.1+ (dep. on device) to each student in the class

• These devices belong to CMU – treat them well or you'll be responsible for replacing them– Everyone will be required to sign a form promising to

return everything we give them

• If you decide you want to use your own phone, let us know (not really recommended)


Questions?


What is a Smartphone?• A “lifestyle” device

• A mini personal computer

• Phone allows 3rd-party apps


Smartphone “Smarts”

Graphics co-processors

Fast processors, multi-core

Cellular telephony

Address book, calendar - “PDA”

functions

“Internet” via WiFi

SMS/MMS Data services over cellular

Mobile OS

Multiple wireless connectivity

GPSCamera,

videoMobile applications

Sensors


So a Smartphone is...


Smartphone Components

Computation / processing

Communication / networking

Sensing / actuating / control

Entertainment / gaming

...


System Interactions


Mobile Computing

Onboard computing (single- or multi-core,

GPU, …)

Cloud computing / processing

Embedded computing

Collaborative / Peered

processing

Infrastructure-based computing,

“cloudlets”


Mobile Operating Systems• In order to deal with the variety of systems,

services, and applications, elaborate operating systems became necessary– Aliyun, Android, bada, BlackBerry, Boot2Gecko, Brew,

GridOS, iOS, Linux, Maemo, MeeGo, MXI, Palm, QNX, Symbian, Windows (Mobile / Phone / 8), Tizen, webOS

– Each operating system has different standards, services, styles, behaviors, foci, interactions, etc.

– Each operating system has different vulnerabilities...


Mobile Applications• Mobile and web apps have emerged as the glue that

binds all of the services and systems together to provide the mobile experience

• Apps have become a “service mash-up” with no limits in sight


Risks and Realities• When the Internet was born, nobody envisioned the

threats we would face in coming decades

• We like to say “We learn from our mistakes, and we won't make them again”...

• Not surprising...Nobody envisioned the threats wewould face in the mobile domain


As it turns out...• Mashing together all of these services on one

device...– Yeah, maybe we should have thought that one through a

bit more...

– The mashup of apps, protocols, services, and features of modern smartphones has opened the door to threats that nobody completely understands

– The complex system-of-system mobile architecture continues to expose new threats, and probably still hides several other ones...


Examples• Malware distribution has diversified

• Social networking apps can steal your private information

• Web browsers can interact with apps to subvert web-only or app-only protections

• Standard WiFi operations expose sensitive context information

• Sensors on your phone can leak your password

• Others?


Looking Forward• During the semester, we'll study various aspects of

security and privacy in smartphone systems– There's no way we can talk about everything!

– This is where course projects and later assignments come into play: you have the freedom to expand topic coverage in whatever way you like


Toward Project Topics• When thinking about project topics:– Don't limit yourselves to apps – think about different

components, inter-dependencies, interactions, …

– Pick an exciting topic, not an easy one – we'll grade you based on effort, not results

– Be creative! Be innovative!


And now...

A 20-minute history of telecom security


Basics of Telecom Security• Different players in the mobile ecosystem have

different security concerns

• Security concerns and techniques have evolved along with the infrastructure

• Let's go through that evolution, starting with some of the basic concerns that different players may have


Users' Security Goals• No user/entity should be able to bill calls on another user's

behalf

• Stolen mobile devices shouldn't be able to make calls

• The network shouldn't record calls, only enough info to perform billing functions

• No records of digital service usage should be made

• Voice eavesdropping should be impossible

• A mobile user's location should be private until disclosed (except in emergencies)

• A device's user should not be identifiable until disclosed

• …


Providers' Security Goals• Communication service billing should be correctly

managed

• All types of fraud should be prevented and mechanisms should be updated as necessary

• Correct naming and addressing of devices must be implemented; routing functions must be secure

• Providers should be able to add services / functions and provide desired security for them

• …


Government Security Goals• Location information must be provided to

emergency services

• Robust infrastructure should be available in emergencies

• Communication and information must be accessible to law enforcement

• Useful measures must be in place for monitoring and protection of essential assets and infrastructures

• …


Let's walk through some history to see how these goals were (not) met


Early Cell Systems - “1G”• Most well known system is AMPS

(advanced mobile phone system)– Analog mobile phone system

introduced in 1978 (FCC-approved and first used in 1983)

– First use of the hexagonal cell structure (W. R. Young @ Bell Labs)


1G Security• Security provided by AMPS– User/device authentication and call authorization in

AMPS is very simple:• Device provides the 10-digit telephone number (MIN: mobile

identity number) and the 32-bit serial number (ESN: electronic serial number – 8-bit manufacturer code + 6-bit unused + 18-bit mfg-assigned serial number)

• If MIN/ESN matches (in home or visiting register), connection is made

– No encryption is provided– See any vulnerabilities?


From 1G to 2G• Primary difference between 1G and 2G is the

switch from analog to digital– Better mechanisms for authentication / authorization

were also mandated, due to weakness of MIN/ESN matching protocol

– Digital also means voice can be encrypted for over-the-air transmission


2G GSM/CDMA ArchitectureMobile Stations Base Station

Subsystem

Exchange System

Network Management

Subscriber and terminal equipment databases

BSC MSCVLR

HLR

EIR

AUC

OMC

BTS

BTS

BTS

adapted from [M. Stepanov; http://www.gsm-security.net/]

SIM

SIM

SIM

SIM


2G GSM Security• Secure access– User authentication for billing and fraud prevention– Uses a challenge/response protocol based on a subscriber-

specific authentication key (at HLR)

• Control and data signal confidentiality– Protect voice, data, and control (e.g., dialed telephone

numbers) from eavesdropping via radio link encryption (key establishment is part of auth)

• Anonymity– Uses temporary identifiers instead of subscriber ID (IMSI)

to prevent tracking users or identifying calls


Auth. & Key Agreement

SIMMS MSC VLR HLR AUC

Authentication Request

A3 A8

RANDK

XRES Kc{RAND, XRES, Kc}RAND

A3 A8

RANDK

RES Kc

RES RES = XRES ?


Radio Link Encryption

SIMMS MSC VLR

Kc

A5 A5c

Kc Kc

Downlinkchannel

pcp

BTS

A5 A5c

Kc Kc

Uplinkchannel

pcp


Temporary ID Management• User and device identity:

– IMEI: Int'l Mobile Equipment ID - device

– IMSI: Int'l Mobile Subscriber ID - user

– TMSI: Temporary Mobile Subscriber ID – pseudonym

SIMMS MSC VLR

IMSI - 1st time, or if data unavailable in VLR

Authentication/encryption initialization

Encrypted TMSI update

Unencrypted TMSI-old[location update]

Authentication/encryption initialization

Encrypted TMSI update


Algorithm Implementations• A3 and A8 are implemented on the SIM, operator-

dependent– Most use COMP128 algorithm

• A5 is efficiently implemented in hardware– Design was never published (security through

obscurity...), but it leaked to R. Anderson and B. Schneier– Variants A5/1 (strong), A5/2 (weak), A5/3 (similar to

KASUMI used in 3G), and A5/4 (also based on KASUMI)


Attacks on GSM Security• April 1998– Smartcard Developer Association and UC-Berkeley

researchers crack COMP128 and recover K in hours– Discovered Kc is only 54 bits (instead of 64)

• Aug 1999– A5/2 was cracked using a single PC within seconds

• December 1999– Biryukov, Shamir, and Wagner publish break of A5/1 - 2

minutes of intercepted call and 1 second attack


Attacks on GSM Security• May 2002– IBM Research group extracts COMP128 keys using side-

channel attack

• More details:– M. Stepanov, http://www.gsm-security.net/

– G. Greenman, http://www.gsm-security.net/

– Traynor et al., Security for Telecommunications Networks

image from [M. Stepanov; http://www.gsm-security.net/]


More GSM Attacks• In-network attacks– Transmissions are only encrypted MS BTS→

• Any attacker between BTS-MSC (such as an eavesdropper on a microwave back-haul) or inside the operator's network has read/modify data access

– Signaling network (SS7) is completely unsecured– Access to HLR retrieve all K keys→

• Over-air attack– Repeated MS queries for RES values can be used to

recover K via cryptanalysis – potential attack by a rogue base station


Sept 2:Tutorial I: Advanced Android

Development

Sept 4:Telecom Security Issues;

Future Mobile Architectures

mobile security · 2021. 4. 2. · ©2014 patrick tague 3 prerequisites v. assumptions • while...

Documents