Device-Centric Monitoring for Mobile Device Management

The ubiquity of computing devices has led to an increased need to ensure not only that the applications deployed on them are correct with respect to their specifications, but also that the devices are used in an appropriate manner, especially in situations where the device is provided by a party other than the actual user. Much work which has been done on runtime verification for mobile devices and operating systems is mostly application-centric, resulting in global, device-centric properties (e.g. the user may not send more than 100 messages per day across all applications) being difficult or impossible to verify. In this paper we present a device-centric approach to runtime verify the device behaviour against a device policy with the different applications acting as independent components contributing to the overall behaviour of the device. We also present an implementation for Android devices, and evaluate it on a number of device-centric policies, reporting the empirical results obtained.Comment: In Proceedings FESCA 2016, arXiv:1603.0837

Verifying Policy Enforcers

Policy enforcers are sophisticated runtime components that can prevent failures by enforcing the correct behavior of the software. While a single enforcer can be easily designed focusing only on the behavior of the application that must be monitored, the effect of multiple enforcers that enforce different policies might be hard to predict. So far, mechanisms to resolve interferences between enforcers have been based on priority mechanisms and heuristics. Although these methods provide a mechanism to take decisions when multiple enforcers try to affect the execution at a same time, they do not guarantee the lack of interference on the global behavior of the system. In this paper we present a verification strategy that can be exploited to discover interferences between sets of enforcers and thus safely identify a-priori the enforcers that can co-exist at run-time. In our evaluation, we experimented our verification method with several policy enforcers for Android and discovered some incompatibilities.Comment: Oliviero Riganelli, Daniela Micucci, Leonardo Mariani, and Yli\`es Falcone. Verifying Policy Enforcers. Proceedings of 17th International Conference on Runtime Verification (RV), 2017. (to appear

COST Action IC 1402 ArVI: Runtime Verification Beyond Monitoring -- Activity Report of Working Group 1

This report presents the activities of the first working group of the COST Action ArVI, Runtime Verification beyond Monitoring. The report aims to provide an overview of some of the major core aspects involved in Runtime Verification. Runtime Verification is the field of research dedicated to the analysis of system executions. It is often seen as a discipline that studies how a system run satisfies or violates correctness properties. The report exposes a taxonomy of Runtime Verification (RV) presenting the terminology involved with the main concepts of the field. The report also develops the concept of instrumentation, the various ways to instrument systems, and the fundamental role of instrumentation in designing an RV framework. We also discuss how RV interplays with other verification techniques such as model-checking, deductive verification, model learning, testing, and runtime assertion checking. Finally, we propose challenges in monitoring quantitative and statistical data beyond detecting property violation

Runtime Verification For Android Security

Users of computer systems face a constant threat of cyberattacks by malware designed to cause harm or disruption to services, steal information, or hold the user to ransom. Cyberattacks are becoming increasingly prevalent on mobile devices like Android. Attacks become more sophisticated along with countermeasures in an ever-increasing arms race. A novel attack method is ’collusion’, where the attack gets hidden by distributing the steps through many malicious software actors [7].We investigate the use of runtime verification to detect collusion attacks on the end-users device. We have developed a novel algorithm called Reverse-Ros¸u-Havelund that is a variation of an exist-ing algorithm by Grigore Ros¸u and Klaus Havelund [26]. Our approach is computationally efficient enough to detect collusion in realtime on the Android device and does not require prior knowledge of malware source code. Thus, it can detect future malware without modification to the detection system or the software under scrutiny

Procedures and tools for acquisition and analysis of volatile memory on android smartphones

Mobile phone forensics have become more prominent since mobile phones have become ubiquitous both for personal and business practice. Android smartphones show tremendous growth in the global market share. Many researchers and works show the procedures and techniques for the acquisition and analysis the non-volatile memory inmobile phones. On the other hand, the physical memory (RAM) on the smartphone might retain incriminating evidence that could be acquired and analysed by the examiner. This study reveals the proper procedure for acquiring the volatile memory inthe Android smartphone and discusses the use of Linux Memory Extraction (LiME) for dumping the volatile memory. The study also discusses the analysis process of the memory image with Volatility 2.3, especially how the application shows its capability analysis. Despite its advancement there are two major concerns for both applications. First, the examiners have to gain root privileges before executing LiME. Second, both applications have no generic solution or approach. On the other hand, currently there is no other tool or option that might give the same result as LiME and Volatility 2.3

Resolving the predicament of android custom permissions

Android leverages a set of system permissions to protect platform resources. At the same time, it allows untrusted third-party applications to declare their own custom permissions to regulate access to app components. However, Android treats custom permissions the same way as system permissions even though they are declared by entities of different trust levels. In this work, we describe two new classes of vulnerabilities that arise from the ‘predicament’ created by mixing system and custom permissions in Android. These have been acknowledged as serious security flaws by Google and we demonstrate how they can be exploited in practice to gain unauthorized access to platform resources and to compromise popular Android apps. To address the shortcomings of the system, we propose a new modular design called Cusper for the Android permission model. Cusper separates the management of system and custom permissions and introduces a backward-compatible naming convention for custom permissions to prevent custom permission spoofing. We validate the correctness of Cusper by 1) introducing the first formal model of Android runtime permissions, 2) extending it to describe Cusper, and 3) formally showing that key security properties that can be violated in the current permission model are always satisfied in Cusper. To demonstrate Cusper’s practicality, we implemented it in the Android platform and showed that it is both effective and efficient

Amulet: a Secure Architecture for Mhealth Applications for Low-Power Wearable Devices

Interest in using mobile technologies for health-related applications (mHealth) has increased. However, none of the available mobile platforms provide the essential properties that are needed by these applications. An mHealth platform must be (i) secure; (ii) provide high availability; and (iii) allow for the deployment of multiple third-party mHealth applications that share access to an individual\u27s devices and data. Smartphones may not be able to provide property (ii) because there are activities and situations in which an individual may not be able to carry them (e.g., while in a contact sport). A low-power wearable device can provide higher availability, remaining attached to the user during most activities. Furthermore, some mHealth applications require integrating multiple on-body or near-body devices, some owned by a single individual, but others shared with multiple individuals. In this paper, we propose a secure system architecture for a low-power bracelet that can run multiple applications and manage access to shared resources in a body-area mHealth network. The wearer can install a personalized mix of third-party applications to support the monitoring of multiple medical conditions or wellness goals, with strong security safeguards. Our preliminary implementation and evaluation supports the hypothesis that our approach allows for the implementation of a resource monitor on far less power than would be consumed by a mobile device running Linux or Android. Our preliminary experiments demonstrate that our secure architecture would enable applications to run for several weeks on a small wearable device without recharging