We provide a detailed analysis of two largely unexplored aspects of the security decisions made by the Android operating system during the app installation process: update integrity and UID assignment. To inform our analysis, we collect a dataset of Android application metadata and extract features from these binaries to gain a better understanding of how developers interact with the security mechanisms invoked during installation. Using the dataset, we find empirical evidence that Android’s current signing architecture does not encourage best security practices. We also find that limitations of Android’s UID sharing method force developers to write custom code rather than rely on OS-level mechanisms for secure data transfer between apps. As a result of our analysis, we recommend incrementally deployable improvements, including a novel UID sharing mechanism with applicability to signature-level permissions. We additionally discuss mitigation options for a security bug in Google’s Play store, which allows apps to transparently obtain more privileges than those requested in the manifest.

Abstract—Application markets providing one-click software installation have become common to smartphones and are emerging on desktop platforms. Until recently, each platform has had only one market; however, social and economic pressures have resulted in multiple-market ecosystems. Multi-market environments limit, and in some cases eliminate, valuable security characteristics provided by the market model, including kill switches and developer name consistency. We outline a novel approach to retaining single-market security semantics while enabling the flexibility and independence of a multi-market environment. We propose Meteor as a security-enhancing application installation framework that leverages information (e.g., app statistics, expert ratings, developer history) from a configurable set of security information sources. We build a proof-of-concept Android application (Meteorite) to demonstrate the technical feasibility of our proposal. The Meteor approach provides valuable decisionmaking criteria useful not only for smartphone users, but technology consumers as a whole, as new and existing computing environments converge on a market-like model for software installation. I.

Android’s trust-on-first-use application signing model asso-ciates developers with a fixed signing key, but lacks a mecha-nism to transparently update the key or renew their signing certificate. As an advantage, this feature allows applica-tion updates to be recognized as authorized by a party with access to the original signing key. Changing keys or cer-tificates requires that end-users manually uninstall/reinstall apps, losing all non-backed up user data. In this paper, we show that with appropriate OS support, developers can securely and without user intervention transfer signing au-thority to a new signing key. Our proposal, Baton, modifies Android’s app installation framework enabling key agility while preserving backwards compatibility with current apps and current Android releases. Baton is designed to work consistently with current UID sharing and signature permis-sion requirements. We discuss the technical changes made to Android, and remaining open issues such as key loss and signing authority revocation on Android.

Android’s trust-on-first-use application signing model asso-ciates developers with a fixed code signing certificate, but lacks a mechanism to enable transparent key updates or cer-tificate renewals. The model allows application updates to be recognized as authorized by a party with access to the original signing key. However, changing keys or certificates requires that end users manually uninstall/reinstall apps, losing all non-backed up user data. In this paper, we show that with appropriate OS support, developers can securely and without user intervention transfer signing authority to a new signing key. Our proposal, Baton, modifies Android’s app installation framework enabling key agility while pre-serving backwards compatibility with current apps and cur-rent Android releases. Baton is designed to work consistently with current UID sharing and signature permission require-ments. We discuss technical details of the Android-specific implementation, as well as the applicability of the Baton protocol to other decentralized environments.

Malware and phishing are two major threats for users seek-ing to perform security-sensitive tasks using computers to-day. To mitigate these threats, we introduce Unicorn, which combines the phishing protection of standard security to-kens and malware protection of trusted computing hard-ware. The Unicorn security token holds user authentication credentials, but only releases them if it can verify an attesta-tion that the user’s computer is free of malware. In this way, the user is released from having to remember passwords, as well as having to decide when it is safe to use them. The user’s computer is further verified by either a TPM or a remote server to produce a two-factor attestation scheme. We have implemented a Unicorn prototype using com-modity software and hardware, and two Unicorn example applications (termed as uApps, short for Unicorn Applica-tions), to secure access to both remote data services and encrypted local data. Each uApp consists of a small, hard-ened and immutable OS image, and a single application. Our Unicorn prototype co-exists with a regular user OS, and significantly reduces the time to switch between the secure environment and general purpose environment using a novel mechanism that removes the BIOS from the switch time.