A Runtime Monitoring Environment for Mobile Java∗ Fabio Martinelli Istituto di Informatica e Telematica Consiglio Nazionale delle Ricerche Pisa, Italy
[email protected] Thomas Quillinan Vrije Universiteit Amsterdam Amsterdam, Netherlands
[email protected]
Abstract The increased availability of mobile broadband connections enables the expansion of software downloads to mobile devices. This leads to greater number of available services and a better utilisation of the computational power of mobile devices. The downside of this increased software availability is an increase in the possible attack vectors. One scenario is the misuse of resources, for example, a game is sending more SMS’s than the user wishes it to send. Thus, techniques need to be in place that prevent downloaded software from misusing resources on the mobile device. In this paper, we show how it is possible to prevent such misuse of resources through the use of a runtime monitor that performs execution-time checks to monitor if the application is behaving correctly or not. This runtime monitor enhances the flexibility of the Java security model for mobile devices and allows to enforce security policies without having to rely on signatures of the downloaded applications.
1. Introduction Downloading software is increasingly more popular with users, in particular as more broadband networks become available. The mobile communication sector has also seen an increase in available bandwidth through the development of UMTS. The adaption of this technology enables more users to download software directly onto their mobile device. This will lead to a greater utilisation of the abilities ∗ This work is partly supported by the project EU-IST-STREP-S3MS FP6-27004.
Paolo Mori Istituto di Informatica e Telematica Consiglio Nazionale delle Ricerche Pisa, Italy
[email protected] Christian Schaefer DoCoMo Euro-Labs Munich, Germany
[email protected]
of mobile devices and also to a better interaction with an environment where special software might play a role. In addition, gaming software is considered to play an important role in the increased download of software for mobile devices [14]. This increased usage of third-party software raises a number of security issues for users, such as if an application will send more than an acceptable number of SMS messages, or if the application will use appropriate resources on their device. There are several potential approaches towards addressing these issues. A user could decide to not install any software and, therefore, prevent any unacceptable use of his device by downloaded software. Another approach could be for the user to unconditionally trust the software provider and, thus, trust that the software will not unacceptably use the device. However, these options are either too restrictive or too permissive with respect to security requirements. A better approach would be for users to have software on their mobile device that performs security checks for them, in order to determine if the downloaded software is behaving correctly. Flexibility would be increased if the user had the ability to specify different policies for different situations. For example, they might want to have one policy when using a banking application and another policy when playing games. One method of achieving this is to use runtime monitors that check if an application is allowed to use specific application programming interfaces (APIs). In this paper we introduce a runtime monitor for Java executing on mobile devices. This runtime monitor enhances the flexibility of the Java security model for mobile devices and allows to enforce security policies without having to rely on signatures of the downloaded applications. Additionally the monitor supports the usage of system information like available networks or the number of SMS’s sent to
decide if an API is allowed to be accessed. Thus, the monitor can test the actual execution of an application against the intended behaviour specified by the policies and interrupt the execution of the application if necessary. The paper is structured as follows: In Section 2 an overview of related work with respect to enforcing security policies in Java is given. Section 3 provides some background information regarding the overall architecture where the runtime monitor is embedded. This is followed by a description of the runtime monitor architecture in Section 4, including details on certain specific components. The implementation of the architecture is then described in Section 5, followed by the conclusion.
2. Related Work Java Microedition (Java ME) provides a security support that involves all the basic components of the Java ME architecture: Mobile Information Device Profile (MIDP), Connected Limited Device Configuration (CLDC) and Kilobyte Virtual Machine (KVM). The security support provided by the CLDC [18] concerns the low level and the application level security. The low level security concerns the safety issues related to the KVM, to guarantee that the J2ME applications, known as MIDlets, do not harm the device while running. The application level security, instead, deals with security relevant operations that MIDlets can perform, such as accesses to libraries or resources. To execute the MIDlet, the CLDC adopts a sandbox model that requires that: the MIDlet has been pre-verified; the MIDlet cannot bypass or alter standard class loading mechanisms of the KVM; only a predefined set of APIs is available to the MIDlet; the MIDlet can only load classes from the archive it comes from (i.e. from the Jar file including it); and, finally, that the classes of the system packages cannot be overridden or modified. The security support provided by the MIDP [12, 13] defines a set of protection domains, and pairs a set of permissions with each of these domains. Each MIDlet that runs on the device is bound to one of these protection domains, and this determines the value of its permissions. A protection domain is assigned to a MIDlet depending on the provider of the MIDlet itself, and can be: Untrusted, Trusted, Minimum, and Maximum. In particular, each MIDlet can be signed by a principal, and the CA that issued the certificate of this principal determines the protection domain of the MIDlet. If the MIDlet is not signed, then it is paired with the Untrusted protection domain. The permissions refer to the operations that the MIDlet can perform during its execution and the value that can be paired with them can be either allowed or user. For example, the javax.microedition.io.Connector.http permission refers to http connections. If the value is allowed, then the per-
mission is granted, otherwise a user interaction is required. The standard security support provided by Java ME is not flexible enough to allow the secure execution of complex MIDlets. In fact MIDlets that come from trusted providers are allowed to perform any kind of operation, while if the MIDlet provider is untrusted, the mobile device owner will be prompted to explicitly allow each action performed by the MIDlet. Hence, on one hand, the mobile device owner does not have any kind of control on trusted MIDlet. On the other hand, in case of untrusted complex MIDlets, that is, MIDlets that perform a large number of operations, the mobile device owner is bothered with many requests for permission. Therefore, the device owner could choose to allow any further invocation of a given operation, thereby disabling any further control on the MIDlet behaviour. Hence, the adoption of an enhanced and flexible security support is required, as modern mobile devices can even execute complex Java applications, such as applications that can establish an Internet connection, send SMS messages or initiate a phone call. Furthermore, mobile devices can store sensitive data, such as the phone book, the personal agenda, or even bank account information. A security analysis of the Java ME has been presented by Debbabi et al. in [4], [5] and [6]. In these papers, they describe in details the Java ME MIDP and CLDC security architecture, and they identify a set of vulnerabilities of this architecture. This study proves that there is the need for an improvement of the Java ME standard security support. An initial attempt towards integrating an alternative security support in the Java ME is shown in [10]. In this paper, the authors propose a runtime monitor architecture that consists of a Runtime Monitor, a Policy Manager and a History Keeper. This architecture enforces policies written in an adopted Security Policy Language (SPL) [15]. From an architectural point of view, a complete system architecture to enhance the security of the Java ME architecture is the reference monitor. The reference monitor is a trusted component that intercepts each request to the monitored resource. It associates decision policies and rules for controlling the accesses to digital objects. Subjects can access the resource only through the reference monitor, that is a part of the trusted computing base, and that must have properties like always-running, tamper-proof, non-bypassable, etc. The main features of reference monitors have been defined by the ISO standard for access control framework (ISO/IEC 10181-3) [11]. According to that standard, a reference monitor consists of two basic components: access enforcement facility (AEF) or policy enforcement point (PEP) and access decision facility (ADF) or policy decision point (PDP). Every request made by a subject is intercepted by AEF/PEP and then forwarded to ADF/PDP for an access decision evaluation. ADF/PDP may reply ei-
ther ’yes/grant’ or ’no/deny’ according to the access control policy, while AEF/PEP enforces this decision.
3. S×C Architecture and ConSpec In [8] the S×C 1 architecture is introduced that helps to increase the security on mobile devices when applications are downloaded to it. It is proposed that an application comes with a contract specified in ConSpec, that is described in more detail later in this section, and specifies the security relevant actions that the application will perform. This contract is checked against the policy of the mobile device. According to the S×C architecture, the contract can be either checked on the mobile device, or it can be checked by a trusted third party such as a mobile network operator. If the contract and policy match, then no further action is necessary on the mobile device. Nevertheless, the user can specify that the runtime monitor shall check if the application is behaving correctly. If the contract and policy do not match then either the runtime monitor checks if the application is behaving correctly, or the application is in-lined with code that checks for correct behaviour. In-lining of the code can be performed, again, either on the mobile device or by a trusted third party such as a mobile network operator. In order to perform code-contract checking and code in-lining using a trusted third party, the S×C architecture supports secure exchange of data and non-repudiation for the exchange of data between mobile device and trusted third party. This is achieved through the use of a security layer and a S×C layer, as shown in Figure 1, topped by the application layer.
Figure 1. S×C Architecture Overview The application layer uses the S×C layer and runs development tools and administration and certification services. The S×C layer enables the user to download code and request services like contract and code matching. The security layer is used by the S×C layer when remote operations 1 Security
by Contract: http://www.s3ms.org/
are to be performed and ensures for example secure connections. ConSpec [1, 2] is a policy specification language inspired by Erlingsson and Schneider’s PSLang [9] and was developed specifically for use on resource limited devices, such as PDAs and other mobile devices in the S×C project. For this reason, ConSpec is more restricted than PSLang to allow for automated matching of contracts and policies. Contract Policy matching is one of the basic requirements of the S×C project. The formal semantics of ConSpec are presented in terms of security automata [16]. In both PSLang and ConSpec, policy texts are intended to encode security automata. Specifically, state variables represent the automata states, and updates represent transitions. However, while this is the intention of PSLang, no specific means is suggested in how to perform this transition. This is not a trivial task in PSLang due to the programming language constructs that can be used. In contrast, ConSpec provides a much more limited set of programming language constructs in order to ease the extraction of the automata states [3]. Furthermore, ConSpec does not allow arbitrary types in representing the security state and restricts how state variables are changed. These restrictions allow ConSpec to be utilised as a common language for the entire S×C lifecycle, rather than the runtime enforcement mechanism that PSLang supports. ConSpec polices are made up of one or more rules. Each rule has a Scope that defines the limits of the policy rule. There are four types of scope: Object, Session, MultiSession and Global. The object scope indicates that the policy rule refers to a specific instantiation of an object. Session scopes define that the policy rule is to be enforced for an entire session of an application, regardless of the number of instantiations of an object, or the number of objects in use. Multi-session scope policy rules are enforced for more than one single execution of an application. Finally, Global scopes are enforced for all applications running on the device. As these scopes may use state across executions, some means to store and retrieve this state is a basic requirement. Furthermore, enforcement of the policy also requires that system information be retrieved from the device. As ConSpec was specifically designed to be utilised on mobile devices, there is a number of mobile device specific classes of information that can be retrieved. These include the types of networking available, such as WiFi, Bluetooth or Irda; the battery level remaining, or more mundane information such as the current date and time. The policy rule can define limits with this information, such as preventing specific applications executing when the battery level is below a particular level.
Midlet
Java ME MIDP
CLDC
method(args) monitor
y/n method(args) read system information
monitor y/n
KVM
Midlet Loader
start PDP
read - policy - state write state
System Information Service
Policy Information Service
policy
Policy Loader
Midlet Loader
Mobile Device Operating System
Figure 3. S×C runtime monitor architecture
4. S×C Runtime Monitor Architecture This section first provides an overview of the S×C runtime monitor architecture, and then details the main components. The runtime monitor architecture, shown in Figure 3, consists primarily of the following components: • The Execution Monitor is responsible for monitoring the MIDlet during its execution. Specifically, it intercepts all the security relevant actions that the MIDlet tries to perform on the underlying mobile device, asks the Policy Decision Point to decide whether the action is allowed and enforces the decision by actually executing the action or by returning an error to the MIDlet. • The Policy Decision Point is responsible for evaluating whether a given action is permitted in the current state by the policy on the mobile device. It is invoked by the Execution Monitor, and it exploits the Policy Informa-
tion Service to get the policy and to manage the policy state, while it exploits the System Information Service to retrieve information about the mobile device state. • The Policy Information Service is responsible for managing the policy state. In particular, it stores the policy variables, that could have different scopes, according to the ConSpec definition. • The System Information Service is responsible for providing information about the system, such as the current date and time, the battery state, the CPU load, and so on. • The Policy Loader is responsible for loading the mobile policy on the mobile device • The MIDlet Loader is responsible for loading the MIDlet on the mobile device
CONSPECVERSION 1.2 MAXINT 5 MAXLEN 10 RULEID Rule2 VERSION 1.0 SCOPE SESSION SECURITY STATE boolean secure = false; BEFORE Connection.open(String url) PERFORM url.startsWith("http") && !secure -> {skip;} url.startsWith("https") -> {secure = true;}
Figure 2. A sample ConSpec policy requiring the use of the SSL protocol once a secure state has been reached.
The main features of the introduced components will be described in the following and some details of the implementation will be given later.
4.1. Runtime Monitor From the architectural point of view, the runtime monitoring of the MIDlets is implemented through two main components: a Policy Decision Point (PDP) and an Execution Monitor (EM), as shown in Figure 3. The EM is integrated in the MIDP and CLDC components of the Java ME architecture, and it has two main tasks: i) intercepting the security relevant actions that the MIDlet tries to perform and ii) enforcing the decision that results from the evaluation of the security policy on the intercepted action. The execution of MIDlets is completely mediated by the Java ME architecture, and a MIDlet cannot access directly the resources of the mobile device, but it has to invoke the proper methods of the MIDP or CLDC core classes. Moreover, Java ME does not allow MIDlets to invoke external functions, i.e. functions that are not written in Java and that could access the underlying mobile device resources bypassing the Java ME architecture controls. Hence, embedding the EM in the Java ME components guarantees that our security support is always invoked when a security relevant action is performed and the MIDlet cannot bypass it. When a security relevant action has been intercepted, the EM invokes the PDP, by passing it the action name and all the invocation parameters. The security relevant actions that we are interested in monitoring are the invocation of some methods of the Java ME MIDP and CLDC core classes (for example, javax.microedition.io.Connector.open and javax.wireless.messaging.MessageConnection.send). The methods of such classes are the ones that interact with the underlying resource to perform security relevant actions, such as exchanging data through a
network connection, sending an SMS message, starting a phone call, and so on. For example, the method javax.wireless.messaging.MessageConnection.send interacts with the mobile device to send an SMS message to a remote device. Several solutions are possible towards integrating the Execution Monitor component into the Java ME architecture. Two immediately obvious solutions are intercepting the system calls that the KVM performs on the operating system of the underlying mobile device, or exploiting the architecture component that manages the permissions defined by MIDP. These solutions define as security relevant actions system calls, or the actions paired with a MIDP permission. However, the security relevant actions that we are interested in monitoring are the methods of certain Java ME core classes. The solution we chose, embedding the Execution Monitor component in the Java ME architecture, requires the modification of the source code of the monitored MIDP and CLDC methods. In particular, the invocation of the PDP is inserted at the beginning and at the end of the code that implements these methods. In this way the policy can be evaluated and enforced both before, and after, the execution of the method. Hence, every method of the Java ME could, in principle, be defined as security relevant action. The EM also enforces the decision of the PDP. If the result of the invocation of the PDP is positive, that is, the execution of the method is permitted, then the EM is allowed to continue the execution of the original method code. Instead, if the result is negative, that is, the execution of the method is denied according to the security policy, the EM throws a Java Exception. In this case, if the PDP invocation has been made before the execution of the method, the method is skipped. This Exception is returned to the MIDlet that invoked the forbidden method. This MIDlet could be instrumented to continue in case of Exception, or can terminate. The Policy Decision Point is the component of the architecture that decides whether a given security relevant method can be performed in a given state according to the security policy. The PDP is initiated by the KVM before beginning the execution of the MIDlet bytecode. The PDP initially gets the security policy from the Policy Information Service (PIS), and builds an internal representation of the policy. The PIS is a further component of the S×C runtime monitor architecture that is in responsible for the management of the policy and its state. This internal representation is used to efficiently evaluate the policy against the security relevant actions that the MIDlet tries to perform. The PDP is invoked by the Execution Monitor twice for each security relevant method that the MIDlet tries to execute, before and after the execution of the method. To evaluate the security policy, the PDP may need the value of specific policy variables. For example, a policy
could allow to open a further network connection only if this MIDlet has opened less than X connections. In this case, the number of connections is represented by a policy variable, and the PDP has to retrieve the value of this variable to decide whether a new connection can be opened, and to increase the variable value to represent the fact that a new network connection has been opened. In these cases the PDP interacts with the PIS, both to get, and to update, the variable value. The PDP may also need some information regarding the current state of the mobile device to evaluate the policy. For example, a policy could state that an SMS message may only be sent if the battery level is above a given threshold. In this case, the PDP interacts with a further component of the architecture the System Information Service (SIS), that is responsible for the collection of data regarding the mobile device state. In particular, the following operations can be requested from the SIS: get date and time, get CPU load, get free memory size, get network type, get battery level. From the performance point of view, the MIDlet monitoring slows down the execution of MIDlets because of the time spent to check the security policy. The overhead on the MIDlet execution time depends on two main factors: the enforced policy and the MIDlet that is executed. As a matter of fact, the number of rules of the policy and the number of predicates paired with each rule affect the policy evaluation time. Hence, in general, complex security policies could take more time to be evaluated than simple ones. The performance degradation also depends on the specific MIDlet, i.e. it depends on the methods that the MIDlet invokes. In particular, the overhead depends upon the number of security relevant methods invoked by the MIDlet with respect to the invocations to other methods, because only the security relevant methods introduce the overhead. However, in the average case, we believe that MIDlets mainly execute methods that are not security relevant, hence the overhead introduced by the MIDlet monitoring should be limited.
PDP Interface Library
System Information Service
Policy Information Service
Secure Hardware
Figure 4. The Policy Information Library
4.3. Policy Information Service The Policy Information Service provides a number of services including storing and retrieving data, digital signature verification and the provision of secure monotonic counters. The PIS uses a library that provides access to secure hardware on the mobile device. This hardware provides the secure storage, secure monotonic counters and digital signature primitives. The PIS uses the storage capabilities to securely store and retrieve the system policy.
4.4. System Information Service The System Information Service provides access to the hardware details of the mobile device. Such details include the current battery level, the types of networks available, the CPU load and the amount of free memory remaining. Policies can be enforced using specified limits to these attributes, as this information is available at runtime.
5. Implementation This section describes the implementation of the introduced runtime monitor architecture.
5.1. Runtime Monitor 4.2. Policy Information Library The Policy Information Library (PIL) provides information to the Policy Decision Point when required. It acts as the interface between the PDP and the Policy Information Service and the System Information Service. The PIL is executed as a separate service on top of the mobile device. Figure 4 shows the architecture of the Policy Information Library. The PIL manages communication between the PDP and both the PIS and SIS. The PDP communicates with the PIL using a message-based protocol. The PIL parses the messages sent by the PDP and calls the PIS or SIS where appropriate. The result of these calls are then sent back to the PDP by the PIL, through the construction of a reply messages.
To evaluate the effectiveness of our architecture, we developed a prototype of the modified Java runtime environment. The prototype is based on Sun’s Java ME simulation environment for desktop computers, that currently provides both the Mobile Information Device Profile v2.0 (JSR 118) and the Connection Limited Devices Configuration Reference Implementation v1.1 (JSR 139). According to Sun’s site [17], these packages fully reflect the CLDC and MIDP specifications, and are addressed to Java ME platform developers that want to understand CLDC or MIDP at a low level, or that want to port Java ME to new mobile devices. These packages can be installed on Linux machines, and they include the full source code, that consists of a set of Java classes and a set of C programs. In particular, the
KVM code is fully developed in C, both for efficiency reasons and because it interacts with the underlying operating system. Instead, the code of the Java ME core classes is developed partly in Java and partly in C. In this case too, C functions are used mainly to implement the interactions with the underlying operating system. Java methods invoke C functions through the Kilo Native Interface (KNI), that is a version for Java ME of the Java Native Interface of Java 2 Standard that can be used in the Java ME core classes source code. Sun’s Java ME simulation environment source code can be easily modified and recompiled to obtain a customised simulation environment. Hence, the Execution Monitor and the Policy Decision Point have been integrated in Sun’s Java ME simulation environment, according to the architecture described in Figure 3. From the implementation point of view, the Policy Decision Point is a thread developed in C language mainly for efficiency reasons. This thread is started by the KVM just before starting the execution of the MIDlet bytecode. In particular, an explicit invocation of the PDP thread has been inserted in the KVM source code, that is also written in C. Once activated, the PDP thread reads the security policy, builds the policy internal representation that is used to test the actions against the security policy, and suspends itself using a semaphore waiting for an invocation from the Execution Monitor component. The Execution Monitor component, in contrast, consists of a Java class and a C function. The Java class includes a method, checkPolicy, to activate the PDP. The invocations to the checkPolicy method are embedded in the source code of the Java ME methods that implement the security relevant actions, before and after the original code. In this way, the security policy is checked before and after the execution of the security relevant action. The implementation of the checkPolicy method exploits the Kilo Native Interface. KNI is used to invoke the C function that actually resumes the PDP and suspends the execution of the Java ME method through the use of semaphores. The Execution Monitor communicates with the PDP exploiting shared variables. In particular, the checkPolicy method copies into the shared variables the parameters of the security relevant method invocation. Once the PDP has evaluated the current action against the policy, its decision is stored in a shared variable as well, and the PDP resumes the monitor and suspends itself, waiting for a new invocation. The enforcement of the PDP decision, when the right to execute an action has been forbidden, is implemented by throwing a SecurityException error in the code of the Java ME method. This error will be reported to the MIDlet. This MIDlet either includes the code to manage it, and continues its execution, or terminates returning the error.
5.2. Policy Information Library The Policy Information Library executes in parallel to the runtime monitor. This allows the PIL to operate independently of the PDP. The PIL retains state across executions of the PDP and, therefore, the applications running on top of the PDP. For example, there are two basic approaches to runtime monitoring in the S×C project: runtime enforcement through the use of a monitor embedded into the virtual machine and application in-lining [9]. As there are a number of approaches to runtime enforcement, the PIL must provide a generic interface to its clients. For this reason, the PIL uses a client-server architecture to communicate with the runtime enforcement technologies. As the enforcement can take place either within the JVM or in an application executing on top of the JVM, it is necessary to provide a language independent interface. This is due to the fact that the JVM is written in one language, C, and applications in a second, Java. Therefore, it was decided to implement the PIL using a network socket based approach. In order to access the PIL, the PDP formulates a message and connects to the PIL’s socket. The PIL handles this message and replies to the PDP. This communication is performed using blocking communication to prevent concurrency problems. For example, it is imperative that a counter is not checked simultaneously by two separate process with both attempting to increment it.
5.3. Policy & System Information Services The core responsibility of the Policy Information Service is to provide a means to store and retrieve data. In this case, data can be the system policy and state associated with running applications. In order to achieve this, application data is stored using the name of the application and/or the scope of the policy that the data is relevant to as a key. For example, if the policy scope is Multi-session, the data is stored in a manner that any instance of the application can retrieve it. However, if a Object scope is used, the data is stored with a reference to the specific instance of the application. Data is stored in an encrypted filesystem managed by secure hardware. This data is stored in files and can only be accessed through the security library provided by the manufacturer of the secure hardware [7]. The data is accessed based on the message sent by the PDP. If the policy is of scope Session, the PDP indicates this by specifying the name of the session as part of the filename. This means that the PIS does not hold any state: all state is retained by the PDP. For this reason, the PDP must be considered part of the trusted computing base (TCB) of the system. If data is to be stored, the PIS attempts to securely store the data and sends an response back to the PDP indicating whether or not the storage request was completed. Simi-
larly, if data was sought for retrieval by the PDP, the PIS attempts to read this data. If the data was found, it is sent to the PDP. Otherwise, an error code is returned, indicating the error returned. The secure hardware also supports monotonic counters, a digital signature service and a secure time service. Monotonic counters may be either queried or incremented, the hardware ensures that they cannot be decremented. Similarly, the secure time service provides a non-alterable clock to the PDP. Finally, the secure signing service allows data to be digitally signed by the PDP. Each of these services is used in the same manner as the data storage and retrieval services. In contrast the System Information Service has a much simpler interface. The SIS acts as an oracle for the PDP. The PDP requests information from the SIS based on the hardware of the system, such as the current battery level. This information is then sent back to the PDP in a message. This allows the PDP to make decisions based on the capabilities of the device.
6. Conclusion We have introduced a runtime monitor that is part of the S×C architecture, ensuring the security of mobile devices when Java programs are installed on it. This runtime monitor enhances the flexibility of the Java security model for mobile devices and allows to enforce security policies without having to rely on signatures of the downloaded applications. Additionally, the monitor is able to use system information during its decision process. The monitor can also store information so that policies on a global scale can be enforced, thus policies, such as do not send more than 20 SMS per month, can be enforced. The current implementation is running in the Sun emulation environment. However, it is planned to port this implementation onto real mobile devices. Additionally, it should be checked if additions to the runtime monitor are required, in particular if other usage scenarios are considered outside of the current one.
References [1] I. Aktug. Syntax and semantics of conspec. Technical report, S3MS Project, 2007. [2] I. Aktug and K. Naliuka. Conspec: A formal language for policy specification. In Proceedings of the First Workshop on Formal Languages and Analysis of Contract-Oriented Software (FLACOS ’07), Oslo, Norway, October 2007. [3] I. Aktug and K. Naliuka. ConSpec: A formal language for policy specification. In Proceedings of the First International Workshop on Run Time Enforcement for Mobile and Distributed Systems (REM 07), Dresden, Germany, September 2007. ESORICS.
[4] M. Debbabi, M. Saleh, C. Talhi, and S. Zhioua. Java for mobile devices: A security study. In Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC’05), pages 235–244. IEEE Computer Society, 2005. [5] M. Debbabi, M. Saleh, C. Talhi, and S. Zhioua. Security analysis of mobile java. In Proceedings of the Sixteenth International Workshop on Database and Expert Systems Applications, 2005, pages 231– 235. IEEE Computer Society, 2005. [6] M. Debbabi, M. Saleh, C. Talhi, and S. Zhioua. Security evaluation of j2me cldc embedded java platform. Journal of Object Technolog, 2(5):125–154, 2006. [7] J. Delplancke, F. Martinelli, P. Mori, F. Piesses, and D. Vanoverberghe. D4.2.4 – runtime enforcement architectures. Technical report, S3MS Project Deliverables, 2007. http://www.s3ms.org/index.jsp?doc=179. [8] N. Dragoni, F. Massacci, C. Schaefer, T. Walter, and E. Vetillard. A Security-by-contracts Architecture for Pervasive Services. In 3rd Internation Workshop on Security, Privacy and Trust in Pervasive and Ubiquitous Computing (SecPerU 2007), July 2007. [9] U. Erlingsson and F. B. Schneider. Irm enforcement of java stack inspection. In IEEE Symposium on Security and Privacy, page 246, Oakland, California, USA, May 2000. IEEE Computer Society. [10] I. Ion, B. Dragovic, and B. Crispo. Extending the java virtual machine to enforce fine-grained security policies in mobile devices. In In Proceedings of the 23rd Annual Computer Security Applications Conference (ACSAC07), 2007. [11] ISO. Security frameworks for open systems: Access control framework. Technical report, ISO/IEC 10181-3, 1996. [12] JSR 118 Expert Group. Mobile information device profile for Java 2 micro edition. Java Standards Process JSP 118, Java Community Process, http: //jcp.org/aboutJava/communityprocess/ final/jsr118/index.html, November 2002. [13] JSR 118 Expert Group. Security for gsm/umts compliant devices recommended practice. addendum to the mobile information device profile. Java standards process, Java Community Process, http://www.jcp.org/aboutJava/ communityprocess/maintenance/jsr118/, November 2002. [14] J. Research. Juniper Research Predicts Mobile Games Market to Reach $10bn by 2009, Driven by Emerging Markets and Casual Gamers. Press Release, November 2007. http://www.juniperresearch.com/ shop/viewpressrelease.php?pr=63. [15] C. Riberio and P.Guedes. An access control language for security policies with complex contraints. In In Proceedings of Network and Distributed System Security Symphosium (NDSS01), 2001. [16] F. B. Schneider. Enforceable security policies. ACM Transactions of Infinite Systems Security, 3(1):30–50, 2000. [17] Sun Developer Network. Java ME. http://java.sun. com/javame/index.jsp. [18] Sun Microsystems Inc. The connectected limited device configuration specification. Java Standards Process JSR 139, Java Community Process, http: //jcp.org/aboutJava/communityprocess/ final/jsr139/index.html, March 2003.
