Source-linked AI summary
Quire: Lightweight Provenance for Smart Phone Operating Systems
Michael Dietz, Shashi Shekhar, Yuliy Pisetsky, Anhei Shu, Dan S. Wallach
TL;DR
Smartphone apps’ broad privileges and inter-app communication make caller provenance and intent difficult to trust. QUIRE extends Android with IPC call-chain tracking and lightweight authenticated statements reflected in RPCs. Two applications demonstrate click-fraud prevention and user-validated micropayments, while the design depends on protecting keys and addressing RPC privacy.
Problem
Smartphone platforms do not reliably let local or remote services determine which app initiated a request or whether a trusted app is being misused through IPC.
Method
QUIRE extends Android with automatic IPC call-chain propagation and lightweight message authentication, embedding provenance and attestations into remote RPCs.
Results
QUIRE was implemented efficiently and demonstrated with separate advertising and payment applications supporting click-fraud prevention and in-app micropayments.
Takeaways & Limitations
Remote servers can make policy decisions using attestations about message origins and IPC call chains, while local services can validate requests before acting.
Takeaways & Limitations
The security context is limited by the device and OS’s ability to protect key material, and phone-specific RPC keys can create privacy concerns.
Abstract
from arXiv · showhide
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.
1 Introduction
QUIRE addresses smartphone security problems caused by broad app permissions, confused deputies, and unverifiable caller intent. It adds provenance tracking and lightweight authentication for local IPC and remote RPC, demonstrated through advertising and payment services.
- Security problem: Android isolates apps by Unix user ID but does not prevent malicious apps from manipulating trusted apps through IPC.The platform also lacks a mechanism preventing an IPC callee from misrepresenting its caller’s intentions to third parties.
- Core approach: QUIRE provides low-overhead provenance and OS-managed data security for applications communicating through IPC and RPC.The design targets both local communication and remote systems that need context about network requests.
- Core approach: QUIRE annotates IPCs with the full call chain so recipients can observe the request’s upstream callers.For network RPCs, OS-built credentials provide context that applications cannot forge through raw sockets.
- Core approach: QUIRE uses message authentication codes to let apps tag objects with verifiable statements across IPC and RPC channels.A trusted OS service verifies the signature when annotated data leaves the device.
- Applications: A separate advertising service can distinguish trusted RPCs and legitimate clicks from host-generated forgeries.Running the service separately addresses spoofing opportunities created when advertising libraries share the host app’s process.
- Applications: A payment agent validates an app’s request with the user before forwarding it to a remote payment server.The payment design addresses fraudulent requests by the main app and protects the request as it moves to the server.
2 Design
QUIRE propagates IPC call-chain context and authenticated statements so downstream services can evaluate provenance before granting sensitive privileges. Its design combines stack-like privilege intersection with lightweight cryptographic protection, subject to key-protection and privacy boundaries.
- Design comparison: Unlike dynamic tainting, QUIRE carries unprivileged context to the dangerous operation, while avoiding static policy annotations and service poly-instantiation.The trade-off is lower precision than dynamic taint analysis.
- IPC provenance: QUIRE carries complete IPC call chains to sensitive-resource endpoints, preserving context that ordinary indirect calls would lose.This allows endpoints to reason about every principal involved before granting access.
- IPC provenance: Each downstream callee receives a statement such as “B says A says Ok” and must establish that every principal is authorized.If any principal lacks the required privilege, the requested action is denied.
- IPC provenance: QUIRE can explicitly drop caller context when an app intentionally exercises its own privilege regardless of the caller.This provides an enablePrivilege-style escape from inherited privilege restrictions.
- Performance: QUIRE propagates IPC call chains with very little impact on overall IPC performance.Efficient implementation is a stated design requirement because every IPC must be annotated and verifiable.
- RPC attestations: QUIRE’s security context depends on the device and operating system protecting the cryptographic key material.A malicious application that extracts a private key could make arbitrary provenance claims.
- RPC attestations: Using a phone-specific public key for every RPC can identify the phone’s owner, creating a privacy concern.Anonymous attestation is presented as a possible production alternative, while switching between anonymous and identifying attestations remains future work.
3 Implementation
QUIRE extends Android with locally verifiable statements, IPC call-chain propagation, and authenticated RPC while preserving backward compatibility. Its implementation combines trusted OS services, modified AIDL-generated stubs, and lightweight HMAC-based authentication.
- System architecture: QUIRE extends Android runtime libraries and Binder IPC with locally verifiable statements, IPC provenance, authenticated RPC, and backward compatibility for existing applications.The implementation comprises about 1300 lines of Java and C++ code.
- Principal representation: QUIRE defines phone principals as user-id/process-id tuples and resolves them into application-name call chains when data moves to remote services.Lazy resolution reduces statement memory footprint while producing externally meaningful RPC context.
- Trusted services: The Authority Manager issues shared secrets, verifies statements, and resolves principals into externally meaningful forms.It runs as an operating-system service in reserved user-id space.
- Trusted services: A new key replaces the previous key whenever the same application requests one, preventing attacks that exploit reused user-id/process-id pairs.The replacement handles applications that come and go over time.
- Verifiable statements: QUIRE attaches parcelable statement objects containing a principal identifier and authentication token to objects carried over Android IPC.The Authority Manager later validates the token using the information embedded in the annotated object.
- Verifiable statements: HMAC digests replace public-key signatures, reducing statement creation and verification cost while retaining authentication and integrity semantics.Pure-Java HMAC-SHA1 was initially too slow, so the implementation used native OpenSSL through a Dalvik intrinsic.
- Call-chain propagation: QUIRE’s AIDL generator propagates call-chain context by adding marshaling and unmarshaling directives to generated IPC proxy and stub code.These directives provide the quoting semantics used by stack-inspection policies.
- Call-chain propagation: The prototype requires developers to mark selected AIDL methods with a reserved auth flag, although production code would propagate context implicitly on all IPC calls.The flag causes the generator to emit the additional proxy and stub code.
4 Applications
QUIRE demonstrates separate-process advertising and payment applications that use signed statements and call-chain context to authenticate indirect events and requests. The examples let remote services distinguish legitimate user-mediated activity from host or intermediary tampering.
- Demonstrations: QUIRE’s two demonstration applications are an advertising system and the PayBuddy micropayment service.Both applications use QUIRE infrastructure to address mutual distrust between communicating components.
- Advertising: Separating advertisement code into its own application isolates it from the host and removes the host’s direct ability to spoof reported ad activity.The design also avoids requiring the host application itself to request network privileges solely for advertising.
- Advertising: The stacked advertising design places the host above a translucent advertisement activity, but must establish that ads are visible and UI events are genuine.The host forwards events from the advertisement region to the advertisement application.
- Advertising: Each MotionEvent receives a MAC-based signature, after which the advertisement app validates the statement, obscuration status, and timestamp freshness.This protects event delivery despite Android’s shared-memory event path.
- Advertising: The advertising prototype demonstrates separate-process hosting and defeating click-fraud attacks, but omits scenarios including orientation changes and advertisement-app termination under low memory.The implementation added around 500 lines of Java plus modest C code.
- PayBuddy: In PayBuddy, ExampleApp signs a purchase order, PayBuddy obtains user confirmation, and the Network Provider verifies and forwards it over client-authenticated HTTPS.The RPC includes the purchase order and the call chain “ExampleApp, PayBuddy” in an HTTP header.
- PayBuddy: PayBuddy.com learns the device identity, the purchase order’s ExampleApp origin and integrity, and PayBuddy’s approval of the request.The server can then accept the transaction and return a transaction identifier for follow-on application actions.
- PayBuddy: Signing the purchase order with a unique order number prevents a compromised PayBuddy app from modifying or replaying it.The OS network provider supplies remote context about both applications, supporting later payment repudiation handling.
5 Performance evaluation
QUIRE’s performance evaluation measures statement operations, IPC call-chain tracking, IPC-to-RPC conversion, and network RPC latency against practical overhead goals. Across these tests, the reported overhead remains small relative to the corresponding Android IPC or secure-network baseline.
- Overall findings: The benchmarks report no significant performance penalty for call-chain tracking, low-cost signing of every touch event, or QUIRE relative to TLS-encrypted communication.Experiments used a Nexus One running Android 2.3, comparing unmodified and QUIRE-enabled builds.
- Signed statements: Statement creation adds 20 microseconds of fixed overhead plus 15 microseconds per kilobyte, while verification adds 556 microseconds plus 96 microseconds per kilobyte.Verification costs more primarily because the Authority Manager requires a context switch and copying.
- IPC call-chain tracking: 70 microseconds of one-hop call-chain tracking overhead produces a 21% slowdown for worst-case no-op IPC calls.Measurements used payloads from 0 to 6336 bytes and repeated runs at each size.
- IPC call-chain tracking: 145 microseconds of two-hop call-chain tracking overhead produces a 20% slowdown for worst-case no-op IPC calls.The reported overhead is approximately a constant factor above stock Android IPC regardless of call-chain length.
- RPC communication: Converting an IPC call-chain into a serialized form for remote services costs a small number of milliseconds even for very long statement chains.The paper reports this cost as irrelevant beside TLS connection setup and maintenance costs.
- RPC communication: 6 ms average and 13.5 ms maximum additional latency are reported for QUIRE network RPCs, with the overhead shrinking as payload size increases.The experiments compared QUIRE RPCs with regular HTTPS over a small WiFi LAN.
6 Related work
Related systems protect mobile applications through install-time or runtime permissions, information-flow tracking, process isolation, authenticated RPC, or trusted hardware. QUIRE instead emphasizes provenance-aware communication between mutually distrustful applications and remote services while relying on Android’s existing process separation.
- Permission systems: Install-time and runtime permission systems restrict applications through static or environmental policies but do not address all collaboration, application-separation, or privilege-escalation concerns.The cited systems include Kirin, Security-by-Contract, Saint, Apex, and CRePE.
- Information-flow control: TaintDroid and ParanoidAndroid track information flow to support policies against runtime attacks and data leakage.TaintDroid monitors outbound network connections and propagates taint through instrumented application data and IPC messages.
- Information-flow control: QUIRE modifies the IPC subsystem rather than instrumenting application code, allowing it to work with native libraries without instrumentation overhead.This distinguishes its implementation approach from TaintDroid’s bytecode instrumentation.
- Decentralized information flow: DIFC systems and QUIRE both use process isolation and labeled message passing, while the paper identifies limitations of prior systems involving deep copying or distributed security labels.The comparison includes decentralized information-flow control, DEFCon, and Asbestos.
- Authenticated systems: QUIRE is closely related to Taos but replaces expensive digital signatures with relatively inexpensive HMAC authenticators.The paper notes that HMAC-based authentication is practical in QUIRE because its trust model differs from large-node distributed systems.
- Browser and application isolation: Browser isolation systems protect principals from one another, whereas QUIRE focuses on expanding communication mechanisms between applications on the phone and the outside world.QUIRE obtains application separation from Android’s process model.
- Authenticated systems: Kerberos and OAuth provide alternative secure-RPC designs, but the paper contrasts them with QUIRE’s mobile setting and trust requirements.The cited discussion raises trust in ticket-granting servers and delegated rights as relevant design considerations.
7 Future work
The paper identifies future directions for using QUIRE’s provenance and authenticated communication mechanisms in secure interfaces, licensing, single sign-on, and web browsers. These directions extend the demonstrated smartphone mechanisms toward broader application and browser security settings.
- Usable and secure UI design: QUIRE’s IPC extensions can support secure user interfaces by efficiently signing UI events so they can be shared and delegated safely.The paper presents this as an already demonstrated building block for secure UI design.
- Usable and secure UI design: Low-level client-authenticated RPC channels could support smartphone single sign-on without relying on traditional username/password dialogs.PayBuddy demonstrated the possibility of building single-sign-on systems within QUIRE.
- Usable and secure UI design: Integrating QUIRE-based single sign-on with multiple certification authorities or OpenID/OAuth services is identified as a future direction.The paper describes this extension as an avenue for further work.
- Web browsers: QUIRE could provide infrastructure for browsers with smaller trusted computing bases by separating webpage principals while preserving provenance and sharing mechanisms.The paper contrasts this direction with Chrome’s monolithic webpage model and relates it to Gazelle.
- Web browsers: A future challenge is harmonizing long-term-state web applications needing additional privileges with the principle of least privilege on phones and desktops.The paper frames this as a security-design challenge across web and conventional applications.
8 Conclusion
QUIRE extends Android to propagate call-chain context and authenticate indirectly received data, including attestations in remote requests. The implementation remains backward-compatible, and evaluation includes Binder microbenchmarks plus applications for click-fraud prevention and in-app micropayments.
- QUIRE embeds message-origin and IPC call-chain attestations into RPC requests so remote servers can make policy decisions.
- QUIRE was implemented as a backward-compatible Android extension, allowing existing applications to coexist with applications using its services.
- The evaluation measured modifications to Android’s Binder IPC system with a series of microbenchmarks.
- Two applications used QUIRE extensions for click-fraud prevention and in-app micropayments.
- The work shows that Taos-style call-chain tracking and signed statements can be implemented efficiently on a mobile platform.