Wireless Security Quantification and Mechanisms

1. Wireless Security Quantification and Mechanisms Bill Sanders Professor, Electrical and Computer Engineering Director, Information Trust Institute www.iti.uiuc.edu

2. Sample Projects Mechanisms: Mobile Device Protection using the Reliability & Security Engine OS Architecture for Reliability and Security Quantification: Experimental Quantification of Mobile Phone Failure Mobile Phone Virus Effect Mitigation and Quantification

3. Providing Application-aware Reliability and Security Ravi Iyer & Zbigniew Kalbarczyk • Customize mechanisms for detecting security attacks and execution errors based on knowledge about expected/allowed program behavior • Extract application characteristics using compiler analysis • Enforce the characteristics at runtime using configurable hardware • Develop methods for automated derivation of runtime checks Application Middleware Operating system Processor • Example techniques: • data value checking – detects corruption of critical program variables • data-flow signatures checking – detects violation of data dependencies in the computation of critical variables • FPGA prototype of RSE in the pipeline of DLX and LEON3 processors • Plan to implement in the ARM pipeline

4. Client2 Data Client1 Data OS Architecture for Security & Reliability Roy Campbell Our Approach: State Management Traditional Microkernel OS Partitioning Distribution • Recovering from errors using server restarts • Server restart is not sufficient for recovery • State information maintained by OS services may be lost when service is terminated and restarted • Error in server due to one client affects all clients Server Client1 Info Client2 Info Server + Client 1 Client2 Client 1 Client2 Client 1 Client2 Client2 Info Server Server Data Client1 Info Client1 Data Client2 Data Client1 Data Client2 Data Local Data Local Data Microkernel Microkernel Microkernel Request Processing Dependability Characteristics • Reliability • Client state not lost when server crashes • Error propagation between clients reduced • Availability • SSR memory allocation charged to client: prevents DoS • Confidentiality & Integrity • “Need to Know” basis for server access to SSRs • Maintainability • Server Upgrade: Terminate old and start new Client1 Info • Client Information is managed in Server State Region (SSR) structures • SSR’s are mapped into server address spaces only when processing requests • When request is processed, the server’s access to the associated SSR is revoked Client2 Info Req Client1 Client2 Resp Server Client1 Data Client2 Data Local Data Microkernel

5. Failure Data Analysis of Smart-Phones: How do Mobile Phones Fail? Ravi Iyer & Zbigniew Kalbarczyk Data sources: Publicly available failure reports (from ’03 to ’06) Failure data collected from actual smart-phones Data collected from 25 smart phones (running Symbian OS) over 14 months Regular phones instrumented with a logger program Collects data on phone freezes and self-shutdowns Use collected data to guide enhancement of robustness of mobile phones

6. Sample Results Analysis of Failure Reports Analysis of Data from Monitoring Smart phones Reboot duration Self-shutdown duration: 80 s MTBFr = 313 h (~13days) MTBS = 250h (~10days) Freeze: device does not respond to inputs Self-shutdown: device shuts down itself Unstable behavior: device exhibits erratic behavior, e.g. back light flashing Output failure: device, in response to an input, delivers an unexpected output Input failure: user inputs have no effect on device behavior Panics Cascading panic events indicate error propagation across applications MTBFr – Mean Time Between Freezes MTBS – Mean Time Between Self-shutdowns

7. Mobile Phone Virus Mitigation and QuantificationElizabeth van Ruitenbeek, Bill Sanders, Tod Courtney Smartphones—mobile phones with operating systems—have sophisticated computational and communication capabilities that make them attractive to virus writers The threat of mobile phone viruses is real Viruses already exist that can send unauthorized text messages, replace screen icons, install corrupted applications, replace font files, delete data, steal data, or infect system application files on phones The situation is expected to worsen as more viruses are written and more people acquire smartphones This research evaluates that threat By modeling the propagation of viruses between mobile phones By providing insight on the effectiveness of potential virus response mechanisms

8. Modeling Phone Virus Spread using Möbius We model the biggest potential mobile phone virus threat: virus propagation via Multimedia Messaging Service (MMS) message attachments We model the spread of viruses via MMS using the Möbius stochastic modeling software tool Each phone in the simulation is represented by a submodel To produce a network of 1000 phones, the phone submodel is replicated 1000 times Of the 1000 phones, 800 are designated as susceptible to the virus Of the phones repeatedly exposed to the virus, 40% eventually choose to accept the infection. Thus, when the virus completely penetrates the population, we can expect 320 phones to become infected. At initialization, each phone is assigned an identification number and a contact list containing the numbers of other phones

9. Phone Submodel for MMS Virus Infection of this Phone Virus Propagation from this Phone

10. Simulation Results Generated X X X X X X X X X X X X

11. How quickly should the patches be distributed? Immunization Software Patches & Virus 4