Overview

As systems security researchers, we must frequently learn how a new system operates and coherently present it to colleagues, identifying salient concepts. The investigation itself is often motivated by either the discovery of architectural flaws or the inclusion of enhanced security infrastructure, with the goal publishing a paper in an academic venue. In this course, students will follow the research process "soup to nuts," learning a mobile phone system, discovering shortcomings, and performing novel research.

Students will complete a survey from which the instructor will determine groups. Each group will investigate one of the approved mobile phone operating systems. Students wishing to work on an alternative OS or system should indicate as such on the survey.

The pre-approved mobile phone operating systems are as follows (see OS Notes for conditions):

The course consists of five student reports. In the first portion of the course, reports are purely informational. The second portion will be geared towards producing a paper of publishable quality.

Grading

Students will receive a grade for both the written and oral presentation of reported material. The grade itself will be reflective of the demonstrated technical depth and competence, as well as the clarity of the writing and oral presentation. To repeat the latter more clearly, the instructor reserves the right to deduct points based on spelling, grammar, and clarity of explanations. The ability to convey one's ideas is a foundation of the scientific method. See each report description for possible point values. All group members will share the same written report grade.

There will be an in-class presentation corresponding to each report. The presentations must be evenly distributed between the group members. For fairness, each student will receive an individual presentation grade.

Finally, each report description includes a list of grading criteria that must be part of the report. "We could not find it" is not an appropriate response. If a grading criteria does not apply to your specific operating system, explain why, but be prepared to defend your response if the instructor believes otherwise. In the event that information simply is not available, or there is a technical reason why you cannot provide information on a grading criteria, you must see the instructor at least 48 hours prior to the report deadline. So, don't wait until the last minute to get started. When meeting with the instructor, you must demonstrate that significant effort was performed before contacting the instructor.

Report Format

Reports 1, 2, and 3

The written portion of Reports 1, 2, and 3 will be composed on the class Phone-OS Wiki. Details with login instructions have been sent to students. Students encountering difficulties loging into the wiki should contact the instructor as soon as possible.

Project Proposal and Final Project

All written portions of the project proposal (Report 4) and the final report (Report 5)must be composed in LaTeX and include appropriate citations. If you do not know how to use LaTeX, it's time to learn. David R. Wilkins' LaTeX Primer is a good place to start.

Reports should be formatted as single column, single space, 11pt font, with 1" margins. See the report descriptions for page length restrictions. The following is an appropriate preamble: 

\documentclass[11pt,pdftex]{article}
\usepackage[margin=1in]{geometry}
\usepackage{times}

Report 1: Background Information

The goal of this report is to discover and document the historical context behind your operating system. Commonly, the design philosophy strongly impacts a system's security. This report will also serve as a means of understanding what resources are available, for example, "is the SDK publicly accessible?" and "is there an emulator?".

The written report should include (but not be limited to) the following information with appropriate citations:

Note: You are required to work with the same OS for Reports 1, 2, and 3. The only exception is if you can convince the instructor that there is not enough publicly available information on your OS. This can only occur after Report 1. Therefore, it is important to spend sufficient time researching your OS in Report 1 to determine if Reports 2 and 3 are feasible.

Note: If you believe we need to purchase hardware for the investigative reports or course project, please let the instructor know as soon as possible.

Report 2: Developing Applications

The goal of this report is to discover and document how applications are developed for your operating system. The investigation will survey available APIs, which will serve as a basis for the security analysis in Report 3. The goal of your presentation is to teach the class how to get started building applications for your OS.

The written report should include (but not be limited to) the following information with appropriate citations:

Report 3: Security Architecture

The goal of this report is to discover and document the security model for your operating system. It is important to look at how the operating system protects itself from applications, how it protects sensitive resources (e.g, hardware), as well as how it provides protection between applications. Consider how concepts such as a "reference monitor" fit into the security architecture. Finally, for each area, discuss possible shortcomings of the design and potential vulnerabilities that may result.

The written report should include (but not be limited to) the following information with appropriate citations:

Report 4: Project Proposal

The course project is designed to demonstrate applied knowledge of mobile phone operating systems security. Students are required to identify a shortcoming in a specific OS or broader concern with mobile phone operating systems. The students must then design a solution and provide an implementation where appropriate (consult the instructor for project specific requirements).

Projects may be done individually or in groups of at most three; however, group projects are expected to be significantly more involved than individual projects. Likewise, more is expected of three person groups than two person groups.

It is encouraged to base your course project on your assigned operating system, but it is not required. Throughout the course, the instructor will describe the Google Android OS for example purposes. An Android-based project is encouraged if the student wishes to work with an alternative OS. Android is completely open source, which makes implementation and integration easier.

The project proposal should include (but not be limited to) the following:

Note: After reading your report, the instructor may make adjustments to your project and the deliverables. This is why the report is called a "proposal."

Report 5: Final Project Report

This report is the final project for the course. Students will complete the proposed tasks along with instructor specified modifications. The report should be written as if it were submitted to an academic venue and therefore should contain all of the necessary components: abstract, introduction, body, related work, conclusion, references, etc.

The report itself is expected to be between 7 and 10 pages of single column, single space, 11pt font, 1" margins not including the references and well marked appendices. Any project source code should be submitted in one file (.zip, .tar.gz, .tar.bz2 accepted) to the instructor via email or CD.

A well written report will clearly articulate the area and problem, describe how the existing mobile phone operating system works (to the respect required to understand the solution), clearly explain the solution (figures and diagrams where appropriate), and evaluate the effectiveness of the solution, potentially considering the performance overhead.

OS Notes

Android (reserved for example purposes)

Android is an mobile phone operating system created by the Open Handset Alliance, which is visibly let by Google. While Android runs on top of a Linux kernel, the programming environment is anything but, defining a middleware API based on Java. The first Android-based phone is the T-Mobile G1, released October 2008; however, more expected to follow in early 2009. The source code for Android is publicly available, as is an SDK including an emulator based on QEMU.

Apple iPhone OS

The Apple iPhone OS is a mobile version of Mac OS X also based on Darwin. It debuted on the first generation iPhone and iPod Touch, but had limited application capacity. Version 2.0 of iPhone OS, released along with the 3G iPhone, added the capacity of the Apple AppStore, though which developers distribute there applications. The iPhone is the canonical smartphone used for comparison purposes, and its AppStore has revolutionized mobile phone software. Due to application limitations, the "iPhone Dev Team" has released methods of "jailbreaking" the iPhone.

BlackBerry OS

BlackBerry OS is a proprietary operating system seen exclusively on Research In Motion's (RIM) BlackBerry handsets, known simply as "BlackBerries". With a long history as the mobile device for business professionals, BlackBerry devices are known primarily for email; however, an application SDK is available with an applications store about to appear.

Symbian OS

Symbian OS is one of the most widespread operating system for smartphones. It has also been the target of most mobile phone malware, despite its maturing security architecture. An SDK exists for third-party development. Students researching Symbian OS are required to note significant changes in the application and security architectures as the operating system matured.

Windows Mobile OS

Microsoft Windows Mobile the latest iteration of Windows CE, which was originally called PocketPC 2000. Windows Mobile is an increasingly common platform for smartphones. An SDK exists for third-party development. Students researching Windows Mobile OS are required to note significant changes in the application and security architectures as the OS matured.

LiMo Foundation

The Linux Mobile (LiMo) Foundation is an alliance founded in January 2007 by a number of handset developers and telecommunications providers. Their goal is to create a open hardware-independent Linux-based operating system for mobile devices. LiMo has replaced previous standards groups such as LiPS (Linux Phone Standards) Forum. Students researching LiMo are required to survey similar mobile linux standards to identify what currently exists, what is waning, and what is expected to come out on top.

Openmoko

The Openmoko project consists of more than just the operating system, including open hardware specifications. While Openmoko handsets have been known to run Android, students researching Openmoko will consider the Openmoko operating system. The OS is opensource and a QEMU emulator exists.

Garnet OS (formerly Palm OS)

Garnet OS is the new name for Palm OS after ACCESS acquired Palm, Inc. Palm OS has a long history in the PDA market and has been ported to support mobile phones. Students researching Garnet OS do not need to worry about Palm OS Cobalt, which is a Linux-based Palm OS that was introduced but eventually terminated. Note that the Access Linux Platform (APL) contains support for Garnet applications; however, at least for Report 1, it will be a separate group.

Access Linux Platform (ACCESS acquired Palm)

The Access Linux Platform (APL) is the newest operating system offering from Palm after being acquired by ACCESS. Students researching APL will focus on now native applications operate, as well as it contains applications running in the Garnet VM. Note, the Access Linux Platform is expected to become LiMo compatible, but is still a distinct platform with its own APIs and software stack.

BREW (Binary Runtime Environment for Wireless)

BREW is an mobile phone operating system developed by QUALCOMM. BREW is distinct from Java ME, and students researching BREW are required to contrast BREW and Java ME from both an application and security perspective. In doing so, students should describe the core operation and security model of Java ME.