Quire: Lightweight Provenance for Smart Phone Operating Systems

TLDR

Smartphone apps often run with full privileges, enabling inter‑app communication that can lead to Confused Deputy attacks and making it hard for remote systems to trust the provenance of network connections. Quire introduces two new security mechanisms into Android to mitigate these privilege and provenance problems. It tracks the IPC call chain so apps can operate with the diminished privileges of their callers or on their own behalf, and implements a lightweight signature scheme that lets any app generate verifiable statements reflected in network RPCs for remote visibility. Using Quire, the authors built an advertising service that validates click data from its host and a payment service that authenticates user‑approved requests, preventing apps from forging payments or tampering with requests.

Abstract

Smartphone apps often run with full privileges to access the network and sensitive local resources, making it difficult for remote systems to have any trust in the provenance of network connections they receive. Even within the phone, different apps with different privileges can communicate with one another, allowing one app to trick another into improperly exercising its privileges (a Confused Deputy attack). In Quire, we engineered two new security mechanisms into Android to address these issues. First, we track the call chain of IPCs, allowing an app the choice of operating with the diminished privileges of its callers or to act explicitly on its own behalf. Second, a lightweight signature scheme allows any app to create a signed statement that can be verified anywhere inside the phone. Both of these mechanisms are reflected in network RPCs, allowing remote systems visibility into the state of the phone when an RPC is made. We demonstrate the usefulness of Quire with two example applications. We built an advertising service, running distinctly from the app which wants to display ads, which can validate clicks passed to it from its host. We also built a payment service, allowing an app to issue a request which the payment service validates with the user. An app cannot not forge a payment request by directly connecting to the remote server, nor can the local payment service tamper with the request.