Software Security Aspects of Java-Based Mobile Phones ∗ Karsten Sohr Tanveer Mustafa Adrian Nowak Center for Computing Center for Computing Otaris Interactive Services Technologies (TZI) Technologies (TZI) GmbH Universität Bremen Universität Bremen Fahrenheitstr. 1 Bibliothekstr. 1 Bibliothekstr. 1 28359 Bremen, Germany 28359 Bremen, Germany 28359 Bremen, Germany [email protected] [email protected] [email protected] ABSTRACT now even e-mails can be sent or received. In particular, new More and more functionality is provided by mobile phones applications such as Java MIDlets [13], small Java programs today; this trend will continue over the next years. However, for mobile phones, can be downloaded or installed via In- with the increasing functionality new risks go along. This frared or Bluetooth. Furthermore, a broad number of Java not only applies to security-critical mobile applications such Specification Requests (JSRs) are made available for mobile as m-banking or m-commerce applications. The end user’s phones, again introducing new functionality which can be privacy may also be in danger or the operator may be the conveniently used, such as the Multimedia API [11]. Given target of an attack. In this paper, we discuss security risks the fact that most of the people in developed countries pos- introduced by mobile phones considering the perspectives sess a mobile phone and use those phones either for private of the different parties involved in telecommunications sys- or for business purposes, security- and privacy-relevant data tems. Specifically, we demonstrate those risks by means of a are stored on mobile phones such as lists with addresses of security hole discovered in a large number of mobile phones. customers, tasks lists and lists of phone numbers. The security hole can be exploited to obtain manufacturer As a consequence, one might assume that security and or even operator permissions. In particular, we implemented privacy seem to be at least important as in the PC world. Up a Java-based Trojan horse. This way, the compromised mo- to now, however, end users do not seem to be prepared for bile phone can be used as an eavesdropping device by an attacks on mobile phones, although some reports on hacking attacker. All in all, this demonstrates that the risks are not mobile phones already exist, e.g., [19, 25, 30]. In the future, only theoretical, but also real. We also sketch a methodology it can be expected that the rate of security incidents will rise for the security analysis of mobile phone software. because of the increasing attractiveness of the attack target “mobile phone” [10]. In this paper, we show by means of a concrete security hole Categories and Subject Descriptors occurring in a large number of current mobile phones from D.4.6 [Security and Protection]: Invasive Software Sony Ericsson which security risks can arise in the context of mobile applications. The security hole can be exploited General Terms by using simple Java API calls, and we have implemented a Trojan horse based upon the security hole. We also show Security that the end user can act as an attacker obtaining access rights originally not intended for him. For example, a user Keywords might circumvent digital rights management (DRM) mech- Mobile Phone, Java Security, Static Security Analysis anisms or obtain operator permissions. In the end, the secu- rity hole can be seen as a case study demonstrating security 1. INTRODUCTION risks related to mobile phone platforms. This specifically applies to high-end mobile phone platforms such as Black- More and more functionality is incorporated into mobile Berry and Android, which provide their own rich Java-based phones. Current mobile phones not only provide the possi- middleware. bility to initiate and accept phone calls. SMS, MMS, and We also briefly discuss a methodology for a static security ∗ This work was supported by the German Federal Min- analysis of the source code which Sony Ericsson could have istry of Education and Research (BMBF) under the grant employed for improving the security mechanisms of the Java 01IS09032 (VOGUE project). Virtual Machine (JVM). The proposed analysis technique is based upon the Java Modeling Language (JML) [2], a specifi- cation language for Java, and employs related static analysis tools such as ESC/Java2 [2] as well as a reverse engineering Permission to make digital or hard copies of all or part of this work for tool-suite called Bauhaus [23]. The Bauhaus tool allows one personal or classroom use is granted without fee provided that copies are to carry out an analysis on the software architecture, i.e., not made or distributed for profit or commercial advantage and that copies at a higher abstraction level. Thereafter, a more focused bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific security analysis at the source-code level can be performed permission and/or a fee. with the help of JML tools. SAC'11 March 21-25, 2011, TaiChung, Taiwan. The rest of the paper is structured as follows. In Section 2, Copyright 2011 ACM 978-1-4503-0113-8/11/03 ...$5.00. we provide an overview of related concepts and technologies 2.2 Security mechanisms for Mobile Java such as Java security mechanisms for mobile phones. Sec- Java for mobile devices provides various security-critical tion 3 gives more details on the security hole discovered in APIs. For this reason, a sandbox model similar to that of the mobile phones, discusses several attack vectors and specif- Java 2 Standard Edition (J2SE) has been introduced [17]. ically describes our Trojan horse. In Section 4, we discuss In particular, a byte code verification mechanism serves as a the consequences of the security hole for all parties involved, low-level security mechanism guaranteeing certain language whereas we sketch solutions for avoiding such problems in properties such as type safety, however, with a lower mem- Section 5. We outline our conclusions in Section 6. ory footprint and power consumption than its J2SE coun- terpart. The other important security concept of the J2ME 2. BACKGROUND are protection domains, once again similarly to the J2SE In the following, we first give a short overview of Java security model. A protection domain encompasses permis- for mobile devices (often called “Mobile Java”) including the sions on security-relevant Java APIs such as those mentioned Java 2 Micro Edition (J2ME). As indicated above, we later in Section 2.1. Java MIDlets can now obtain access rights employ Mobile Java as the main vehicle for exploiting the through the protection domains. In particular, one can con- aforementioned security hole, and in particular, the addi- figure a protection domain in a way that applications on mo- tional functionality made available by the Java APIs can be bile phones run in a sandbox with restricted access rights. conveniently used by the Trojan horse to exploit the security Four domains are predefined according to the MIDP spec- hole. To give a flavor of the functionality that can be used by ification [13], namely, Unidentified Third Party Protection an attacker, we describe the various security-relevant Java Domain, Identified Third Party Protection Domain, Opera- APIs for the J2ME in more detail. We also explain the basic tor Domain, and Manufacturer Domain. Java MIDlets are security concepts of the J2ME, and at the end of this sec- assigned to protection domains according to the X.509 code tion, we sketch DRM mechanisms for mobile phones because signing certificates used for signing the MIDlets. these mechanisms can also be circumvented by means of the The first two domains differ by the identification of the security hole. Third Party which created the application and different de- fault and other user settings. The MIDlets from the Identi- 2.1 Java for mobile phones fied Third Party Protection Domain have been signed by a The J2ME introduced by Sun Microsystems in 1999 was certificate from a trusted certification authority (CA) whereas meant for devices with low computational power and mem- the MIDlets of the Unidentified Third Party Protection Do- ory. In particular, this applies to PDAs and mobile phones, main have been signed by an unknown CA or have not been but also to other embedded systems such as VoIP phones signed at all. In both cases, however, the user shall be or sensors. The central part of the J2ME is a configuration. prompted (at least once) when a security-critical operation For mobile phones, the Connected Limited Device Configu- is performed such as sending an SMS. ration (CLDC) [26] is used. The CLDC defines a lean JVM The other two domains can be defined depending on the called “Kilo Virtual Machine”. Based upon the CLDC, the specific manufacturer and operator, respectively. Strictly Mobile Information Device Profile in version 2.1 (MIDP) speaking, the MIDlets in those domains should also ask for has been specified and then been implemented or licensed permissions on accessing sensitive APIs. This is, however, by most of the manufacturers of mobile phones. The MIDP not mandatory. makes available certain APIs for developing Java MIDlets. 2.3 Mobile digital rights management For example, functionality for networking, access to serial 1 ports, application auto invocation , and graphical user in- Ring tones, music files, games, and Java applications are terfaces are provided. In addition to the MIDP, various JSRs copy-protected in mobile phones by means of DRM mecha- are often implemented such as the Java Wireless Messaging nisms. There exist two different DRM mechanisms for Sony API (supports sending and receiving of SMS); the Bluetooth Ericsson mobile phones, one for the protection of Java appli- API (for creating Bluetooth applications); the Personal In- cations and games, which is proprietary.