The Journal of Systems & Software 193 (2022) 111460

Contents lists available at ScienceDirect

The Journal of Systems & Software

journal homepage: www.elsevier.com/locate/jss

Secure and flexible message-based communication for mobile apps

within and across devices✩
∗
Yin Liu a , , Breno Dantas Cruz b , Eli Tilevich c
a
Faculty of Information Technology, Beijing University of Technology, Beijing 100124, China
b
Department of Computer Science, Iowa State University, 226 Atanasoff Hall, Ames, IA, USA
c
Software Innovations Lab, Virginia Tech, 2202 Kraft Drive, Blacksburg, VA 24060, USA

article info a b s t r a c t

Article history: In modern mobile platforms, message-based communication is afflicted by data leakage attacks,
Received 26 September 2021 through which untrustworthy apps access the transferred message data. Existing defenses are overly
Received in revised form 31 May 2022 restrictive, as they block all suspicious message exchanges, thus preventing any app from receiving
Accepted 25 July 2022
messages. To better secure message-based communication, we present a model that strengthens
Available online 4 August 2022
security, while also allowing untrusted-but-not-malicious apps to execute their business logic. Our
Keywords: model, HTPD, introduces two novel mechanisms: hidden transmission and polymorphic delivery.
Mobile security Sensitive messages are transmitted hidden in an encrypted envelope. Their delivery is polymorphic:
Message-based communication as determined by the destination’s trustworthiness, it can be delivered no data, raw data, or encrypted
Secure inter-component communication data. To allow an untrusted destination to operate on encrypted data deliveries, HTPD integrates
homomorphic and convergent encryption. We concretely realize HTPD as PoliCC, a plug-in replacement
of Android Inter-Component Communication (ICC) middleware. PoliCC mitigates three classic Android
data leakage attacks, while allowing untrusted apps to perform useful operations on delivered
messages. Our evaluation shows that PoliCC supports secure message-based communication within
and across devices by trading off performance costs, programming effort overheads, and security1 .
© 2022 Elsevier Inc. All rights reserved.

1. Introduction 2014; Bosu et al., 2017) and in vulnerability reporting repositories

(e.g., CVE3 ) (CVE, 2018a,b; Blasco et al., 2016).
To prevent data leakage, state-of-the-art approaches fall into
An essential part of modern mobile platforms is inter-app
two general categories: (1) taint message data to track and an-
communication,2 which is typically message-based: apps send alyze its data flow (Enck et al., 2014; Arzt et al., 2014), and (2)
and receive various kinds of messages, some of which may con- track call chains, as guided by a permission restriction policy for
tain sensitive data. When a malicious app accesses sensitive data, sending/receiving data (Dietz et al., 2011; Felt et al., 2011; Bugiel
data leakage occurs. To prevent data leakage, modern mobile et al., 2011). Although these approaches4 strengthen the security
platforms (e.g., Android and iOS) customize their communica- of message-based communication, their high false positive rates
tion models to control how apps access message data. However, often render them impractical for realistic communication sce-
these models remain vulnerable to data leakage, commonly ex- narios. Once any app in a call chain or data flow is identified as
ploited by attacks that include interception, eavesdropping, and ‘‘malicious,’’ even as a false positive, they can no longer receive
permission escalation. These attacks leak volumes of sensitive any messages. Although ‘‘untrusted’’ may not be ‘‘malicious’’,
these data flow monitoring approaches block all untrusted-but-
data, as has been documented both in the research literature (Lu
not-malicious destinations. In addition, mobile users may change
et al., 2012; Xu et al., 2016; Bugiel et al., 2012; Fang et al.,
app permissions at any point, thus also causing false positives.
With high false-positive rates, these prior approaches lack flexi-
✩ Editor: W. Eric Wong.
bility required to secure message-based communication, without
∗ Corresponding author. blocking untrusted-but-not-malicious destinations from operat-
ing on delivered messages.
E-mail addresses: [email protected] (Y. Liu), [email protected]
(B.D. Cruz), [email protected] (E. Tilevich).
1 This article is a revised and extended version of our prior paper, pub- 3 CVE stands for the Common Vulnerabilities and Exposures, which is a
lished in the 17th EAI International Conference on Security and Privacy in well-known vulnerability reporting website (CVE, 2022).
Communication Networks (SecureComm 2021) (Liu et al., 2021) 4 All of them target Android, due to its open-sourced codebase, which can
2 In Android, it is also called inter-component communication (ICC). be examined and modified.

https://doi.org/10.1016/j.jss.2022.111460
0164-1212/© 2022 Elsevier Inc. All rights reserved.
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

In this paper, we present HTPD, a novel model that improves untrusted-but-not-malicious destinations can perform useful op-
the security of message-based communication. The name of HTPD erations on the delivered message data.
is from its two combined mechanisms: (1) Hidden Transmission (2) The first successful application of homomorphic and con-
of messages and (2) their Polymorphic Delivery. vergent encryption to the design of mobile message-based com-
Mechanism (1) serializes a message object with additional munication, offering operations on encrypted sensitive data as
information (e.g., data integrity or routing information) as an the middle ground between permitting access to raw data and
encrypted binary stream, and then hides the resulting stream denying access altogether.
as the data field of another message used for transmission. In- (3) PoliCC—a reification of HTPD that plug-in replaces Android
tercepting the transmitted message would not leak its hidden ICC, mitigating interception, eavesdropping, and permission es-
content to interceptors. In the meantime, it cannot be tampered calation attacks, without preventing untrusted-but-not-malicious
with undetectably either: before delivering the message to a apps from operating on delivered data. Through its plug-and-
destination, the model retrieves the message’s hidden content, play integration with the Android system, PoliCC requires only
using it to verify the message’s integrity and destination. minimal changes to existing apps.
Mechanism (2) steps away from the standard message deliv- (4) An experimental evaluation that shows how PoliCC pre-
ery, in which the delivered message data is presented identically vents the aforementioned attacks carried out against benchmarks
to all destinations, having so-called monomorphic semantic. In- and real apps, and reports its performance and programming
stead, depending on the destination’s trustworthiness at runtime, effort overheads.
the delivered message data is presented either in no form, raw This article extends our earlier paper, presented at the 17th
form, or encrypted form, thus having polymorphic semantic. No EAI International Conference on Security and Privacy in Commu-
data is presented for misrouted messages or when the message’s nication Networks (SecureComm 2021) (Liu et al., 2021). In com-
integrity cannot be verified. Raw data is presented to destinations parison to that conference publication (18-page, single-column),
whose trustworthiness can be established. Encrypted data is pre- this article reports on additional unpublished research that ex-
sented to all other destinations. However, the received encrypted tends our prior work as follows:
data can still be used in limited computational scenarios, due to (a) PoliCC now also supports Device-to-Device data commu-
homomorphic encryption (HE) and convergent encryption (CE), nication, unlike the previous version, which only worked within
which preserve certain arithmetic and comparison properties of a single device;
ciphertext, respectively. (b) We report on the results of an empirical study of thousands
To the best of our knowledge, our approach is the first to of popular Android apps that reveals their ICC usage, including the
apply HE and CE to the design of message-based communication prevalence of specific API methods and transmitted data types;
models. Homomorphic and convergent operations on sensitive (c) We explain the specifics of PoliCC’s programming inter-
data provide the middle ground between permitting access to
faces, through which Android developers can enable untrusted-
raw data and denying access altogether. The primary barrier to
but-not-malicious apps to perform useful business operations
widespread adoption of HE and CE has been their heavy per-
with encrypted data.
formance overhead. The resulting escalation in execution time
Our experiences of designing, engineering, and evaluating our
has rendered these encryption techniques a poor fit for intensive
approach that supports exchanging data within and across de-
computational workloads of large statistical analyses and ma-
vices should be of value and relevance to the audience of this
chine learning. In contrast, our work demonstrates that HE and
journal.
CE can effectively solve long-standing problems in the design of
The remainder of this paper is structured as follows. Sec-
mobile message-based communication. Because mobile commu-
tion 2 discusses our threat model. Section 3 presents the HTPD
nication rarely involves large computational workloads, the inclu-
model and gives an overview of our approach. Section 4 presents
sion of HE and CE provides the required security and flexibility
our empirical study of Intent API usage. Sections 5 and 6 de-
benefits, without noticeable deterioration in user experience.
tail PoliCC’s design and implementation, respectively. Section 7
To verify our model, we developed PoliCC, an Android mid-
presents our evaluation results. Section 8 discusses related work.
dleware5 that plug-in replaces Android inter-component commu-
Section 9 discusses conclusions and future work directions.
nication (ICC). PoliCC mitigates interception, eavesdropping, and
permission escalation attacks, without preventing untrusted-but-
not-malicious apps from operating on delivered message data. 2. Threat model
In addition, PoliCC applies HTPD to both inter-app and inter-
device communication, so messages can be transmitted uniformly By following our model, message-based communication can
within and across devices, thus demonstrating HTPD’s generality prevent data leakage, so it would not be exploited by interception,
and extensibility. eavesdropping, and permission escalation attacks. Our model can
When it comes to performance overheads, as compared to strengthen any message-based communication, but our reference
Android ICC, PoliCC’s attack mitigation adds at most 40.4 ms implementation is Android-specific. We generally define each
(15.4 times from baseline) and 2 mW (11.1% from baseline). of the aforementioned attacks, and present examples of their
Based on the security/performance trade-offs revealed by our real-world occurrences in Android apps.
experiments, app developers can make an informed decision on
whether to apply our security enhancements to their specific 2.1. Examples of data leakage attacks
application scenarios.
This article contributes: Interception:. Fig. 1-a demonstrates an interception attack:
(1) HTPD—a novel model that strengthens the security of source S is transferring data to destination D, with U intercepting
message-based communication via hidden transmission and the transferred data. Another common name of this attack is
polymorphic delivery. This model retains the protection of prior man-in-the-middle.
models, but eliminates their unnecessary restrictions, so In Android, this attack can target both within and across device
communication.
5 Similarly to prior works, we target Android as the dominant open-source (1) To communicate within the same device, Android provides
platform. the inter-component communication (ICC) mechanism (detailed
2
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Fig. 1. Examples of attacks.

in 3.4). Using ICC, a source app sends an Intent6 to user-permitted operations. Consider the scenario from the eavesdropping attack
destination apps: with explicit Intents, only specific destina- above: if, having received a message containing the device’s IP
tions can receive data; with implicit Intents, any destination address, an untrusted app uses the received IP only for legitimate
that registers a certain Intent Filter7 can receive data. As de- operations (e.g., host IP verification), is it reasonable to block all
fined in Common Attack Pattern Enumeration and Classification such message transmissions to strengthen security?
(CAPEC) (CAPEC, 2022), an interception attack occurs when mali- A more flexible solution could use homomorphic encryption
cious apps inappropriately receive an implicit Intent by declaring (HE) and convergent encryption (CE), currently most commonly
a certain Intent Filter (CAPEC, 2021). These attacks have been used for sending sensitive data to the cloud for processing by
detected in many real-world Android apps (Chin et al., 2011), untrusted providers. Using HE/CE schemes, data owners encrypt
which even be used in some developer tools for benign purposes. and send their data to the cloud server. The cloud server operates
For example, a developer tool, Intent Intercept, intercepts on and returns the encrypted results to the data owner. Only the
the transferred Intent to help developers in debugging ICC-based data owner, possessing the secret key, can decrypt the results. In
communication (Intent Intercept, 2019). the case above, an untrusted app can still receive the IP address’s
(2) For device-to-device communication (i.e., across devices), encrypted version to verify its host address, without accessing the
consider a real attack reported in CVE, the MensaMax app-4.3 raw IP address. By means of HE/CE, HTPD enables untrusted apps
transmits sensitive information to a web server as cleartext, with to operate on sensitive data without data leakage.
the transmissions maliciously captured at the network packets
level, resulting in data leakage (CVE, 2018b). Worse, attackers 2.3. Assumptions and scope
can tamper with the intercepted information to misroute them
to malicious destinations. To counteract the threats, our design is subject to the follow-
ing constraints:
Eavesdropping:. Fig. 1-b demonstrates an eavesdropping attack:
(1) Assumptions:
source S broadcasts data to destination D, but U (i.e., eavesdrop-
per) can also receive the data. In Android, when an app broadcasts • Trustworthiness. Since HTPD relies on apps’ trustworthiness
Intents, any app can receive them by declaring a certain Intent to determine whether to expose no data, raw data, or en-
Filter. Consider a real eavesdropping attack reported in CVE, when crypted data, we assume that application trustworthiness
WiFi is switched, the Android system broadcasts an Intent that can be reliably configured or calculated. Further, attackers
contains detailed WiFi network information (e.g., network name, cannot change the involved apps’ trustworthiness. As an
Basic Service Set Identifier (BSSID), IP address, and DNS server). abstract metric of how to expose the data, the trustwor-
However, having declared the corresponding Intent Filter, any thiness can be represented as many specific forms, such
applications can receive this Intent and disclose the sensitive as permissions in the above example attacks (discussed in
information (CVE, 2018a). Section 3.1).
• Mobile devices have been paired by the user. PoliCC trans-
Permission escalation:. Fig. 1-c demonstrates a permission esca-
mits Intents across paired devices via Bluetooth.8 However,
lation attack: source S has been granted sufficient permissions to
the pairing procedure is outside of PoliCC’s purview. An-
access sensitive data, but destination D has not. When S sends
droid users typically discover and pair with nearby mutu-
its sensitive data to D, D’s permission is escalated. In Android,
ally trusted devices using the built-in Bluetooth Settings
to access sensitive user data (e.g., GPS, contacts, and SMS), apps
component (i.e., Settings→Bluetooth).
must secure the required permissions. As previously reported,
attackers can force apps, with dissimilar permissions, to com- (2) Scope: Message-based data leakage vulnerabilities. HTPD’s
municate sensitive data to other apps, thus leaking it to the focus is message-based data leakage vulnerabilities. That is, the
destinations (Blasco et al., 2016; Mimoso, 2016). For example, vulnerabilities should (a) cause data leakage, and (b) occur dur-
if an app has GPS permissions, it can send its obtained user ing message transmission. Hence, other attacks, such as denial
geolocation information to any app that has no such permissions, of service (DoS)9 that target data transmission (not data leak-
which may cause sensitive data leakage. age), stealing data by breaking the system (not during message
transmission), are out of scope.
2.2. Untrusted data processing Moreover, various attacks against key management can pilfer
decryption keys. Although these attacks are a serious security
The aforementioned attacks that exploit data leakage share
the same root cause: a destination illicitly accesses and discloses 8 The proliferation of wearable devices, including watches, fitness trackers,
or tampers with sensitive message data. However, blocking all and smart-glasses, has standardized the Bluetooth technology as a foundation
suspicious message transmissions may paralyze apps’ legitimate for connecting wearables with a smartphone. Our conceptual contribution is
not bound to Bluetooth and would remain applicable for any device connection
protocol (e.g., WiFi-Direct).
6 In ICC, Intent objects serve as data delivery vehicles. 9 Although DoS is not our focus, one of PoliCC’s features mitigates them (see
7 Intent Filter declares expected Intent properties (action/category). Section 7.5).

3
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Fig. 2. HTPD Transmission Mechanisms.

challenge, mitigating these attacks is orthogonal to our approach. decrypted, and deserialized into the original message (steps 7,8).
By relying on Android’s private storage and straightforward data Then, the extracted extra information is used to examine the
synchronization to manage the keys, the HTPD model’s refer- destination’s trustworthiness (e.g., data integrity, app permis-
ence implementation does not exacerbate the key management sions), which determines in which form the message data can
vulnerabilities. Furthermore, as defenses against these vulnera- be accessed. In the cases of failed integrity checks or misrouted
bilities become more effective, they can be easily integrated with deliveries, HTPD would not disclose any data. If the destination’s
HTPD. trustworthiness is established, HTPD reveals the raw form of the
original message’s data; otherwise, it encrypts the data into its
3. The HTPD Model homomorphically or convergently encrypted form (step 11). Due
to its polymorphic delivery, the final received message is referred
We present the HTPD model and its application to Android ICC to as ‘‘polymorphic message’’ (step 12).
in turn next.
3.3. HTPD in Practice
3.1. Definitions
To verify HTPD, we developed PoliCC, a plug-in replacement
(1) Source/Destination. In message-based communication, a source of Android ICC. By mitigating Android ICC’s data leakage vul-
sends messages, and a destination receives messages. In mobile nerabilities, PoliCC prevents the aforementioned attacks (Sec-
platforms, apps can be both source and destination. tion 2.1). Following the definitions above, apps serve as message
(2) Sending and Receiving Points. We use the term a sending point source/destination, whose sending/receiving points are managed
to describe an API function, invoked by a source and passed by PoliCC (as shown in Fig. 3). PoliCC retains Intent objects as ICC
message data, that starts transmitting messages.A receiving point transmission vehicles, but hides the original Intent object within
is a callback API function, through which a destination retrieves a so-called Host Intent object, whose data field stores the original
the transferred message data. Intent object’s encrypted serialized version.
(3) Trustworthiness. Trustworthiness measures the degree to To guide its polymorphic delivery, PoliCC computes the desti-
which an app can be trusted. We use this metric to define how nation app’s trustworthiness: (a) the delivered message’s routing
an app can access message data. An app whose trustworthiness information,10 and (b) how the permission sets of the source and
is established can access raw message data; otherwise, encrypted destination apps relate to each other. PoliCC delivers no data
data or no data. Trustworthiness can be measured in different from messages identified as tampered with or misrouted; it de-
ways: (a) data integrity (i.e., to detect data tampering) and des- livers raw data to destinations whose permission sets are equal to
tination examinations (i.e., to detect misrouting). For example, or exceed those of source apps; and it delivers homomorphically
if the received message fails such examinations, the destination or convergently encrypted data to all other destinations.
app should not access the raw data. (b) apps’ permissions and Consider how PoliCC prevents the attacks described in 2.1:
the relationship between apps’ permission sets. For example, if Preventing Interception Attacks. As shown in Fig. 3, an in-
a source app’s permission set is larger than that of a destination terception attack can be carried out at the receiving point ❷:
app, messages transmitted between them may become vulnera- an untrusted app U becomes the final delivery destination by
ble to permission escalation attacks, causing data leakage 2.1. (c) declaring a certain Intent Filter (case-1 in 2.1), or at point ❸
reputation score. For example, if an app’s reputation score in app before the receiving point: U captures the network packets being
markets (Google, 2018) is low, then allowing it to access raw data transferred to an app on another device (case-2 in 2.1). In the first
may cause data leakage. HTPD can be parameterized with various case, having received the transferred Intent, U would be able to
measures of trustworthiness, as required for a given scenario of retrieve the contained raw data only if U’s permission set equals
message-based communication. In particular, to determine an app’s to or exceeds that of the source app. Otherwise, the received
trustworthiness, our HTPD’s reification uses both (a) and (b). data would be homomorphically or convergently encrypted, so it
would not be leaked. In the second case, U would receive a Host
3.2. Transmission mechanisms Intent, containing only the encrypted and thus inaccessible origi-
nal Intent. At this point, tampering with the Host Intent’s routing
Fig. 2 depicts HTPD’s hidden transmission and polymorphic information would be easily detected through data integrity and
delivery mechanisms. When a source starts transmitting a mes- destination examinations at ❷.
sage (step 1), the message’s data field is inserted with some extra Preventing Eavesdropping Attacks. As discussed in 2.1, an
information (e.g., custom routing) (step 2). After that, the message eavesdropping attack occurs when the Android system broadcasts
is serialized (step 3) and encrypted (step 4) to a binary stream, an IP address (i.e., string value), received by both a trusted app D
which becomes the data field of a newly created wrapper mes- and an untrusted app U. Without sufficient permissions, U would
sage. Hence, the original message is hidden within the wrapper receive the IP address as a convergently11 encrypted string. Since
message, which becomes the transmission message (step 5).
Next, the transmission message is dispatched via the system’s 10 In Android ICC, routing information can be used for both data integrity and
standard communication channel (step 6). Once the transmission destination examinations (detailed in 6.2).
message arrives to its receiving point, its data field is extracted, 11 Convergent encryption is applied to string data.

4
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Fig. 3. PoliCC solution overview.

convergent encryption makes it possible to compare encrypted the operands. Untrusted parties can operate on homomorphi-
values for equality, U can verify the host address by convergently cally encrypted ciphertext operands, while a trusted party can
encrypting the host address and comparing the result with the decrypt the encrypted result. PoliCC homomorphically encrypts
received data. message’s numeric data, so its ciphertexts can still be computed
Preventing Permission Escalation Attacks. As discussed in 2.1, without decrypting.
an escalation attack occurs when a source app with GPS permis- Convergent Encryption (CE) (Douceur et al., 2002) encodes string
sions obtains and sends user geolocation information to a destina- values, so the comparison order is preserved in their cipher-
tion without these permissions. Without the geolocation permis- texts, as a given string (i.e., cleartext) is always encrypted into
sions, destination D would be delivered geolocation (i.e., numeric the same ciphertext. Computed from a cleartext, a hash code
value) as a homomorphically12 encrypted numeric value, so no becomes the cleartext’s encryption key. Finally, the hash code
permissions would be escalated. If D forwards the delivered ci- itself is encrypted with a user-provided key. Both researchers and
phertext to malware M to decrypt the ciphertext, M’s permission practitioners have used CE to identify duplicated records in file
set would have to be equal or greater than the union of permis- systems (Duan, 2014). PoliCC convergently encrypts message’s
sion sets of the source app and D, a hard-to-satisfy requirement string data, so its ciphertexts can still be used in comparison to
for the granted permissions to access raw geolocations. find identical data.
Xposed (Xposed, 2019) is a framework for interception the invo-
3.4. Enabling technologies
cations of the Android system and app functions, without modi-
fying their code. Injected custom code can be executed before or
Intent and Android ICC. Intents carry data in their so-called
after the intercepted functions, using the beforeHookedMethod
‘‘extended data field’’. To store/retrieve key–value data into/from
or afterHookedMethod interfaces, respectively. PoliCC use these
an extended data field, apps call the ‘‘put/get’’ API methods
interfaces to hook sending/receiving points.
(i.e., putExtra(), get*Extra(), etc.). To dispatch Intents, Android
provides startActivity, which launches the Activity the user inter-
acts with, and sendBroadcast, which launches the 4. An empirical study of ICC Intent
BroadcastReceiver that processes broadcast Intents. Before deliv-
ering an Intent, ICC must resolve it by examining which Intent Since our solution is intended to plug-in replace Android ICC to
Filters the installed apps declared. Upon matching Intent Filters, secure message-based communication, it is necessary to study the
ICC delivers the resolved Intent to their corresponding destina- status quo of ICC Intent usage in the Android app. Although sev-
tion apps. With multiple destinations, ICC prompts the user to eral prior studies have analyzed how Android apps use ICC/Intent
select only one destination per Activity and allows all matched and provide a good baseline for understanding ICC scenarios, we
destinations to receive Intents broadcast using BroadcastReceiver. aspired to comprehensively analyze a larger sample of apps, dif-
Android Permission Scheme. To prevent the misuse and ex- ferentiated by their specific types (e.g., adware, spyware, trojan),
ploitation of sensitive data, the Android permission scheme re- with the goal of designing our solution to be able to prevent data
stricts which sensitive data or API calls can be used by which leakage in diverse ICC scenarios.
apps: to obtain certain data (e.g., ACCESS_FINE_LOCATION to ob- In this section, we first summarize the findings reported by
tain geolocations), an app must have secured user permissions, prior analyses. We then discuss the results of our analysis. These
either during installation or at runtime. Otherwise, invoking a findings drive the design of our solution presented in Section 5,
protected call raises an exception and causes the execution to i.e., why we choose to keep Intents (findings 1 and 4), why we
stop. Besides system-level permissions, an app can also require focus on Integer and String (findings 2 and 5), and why we focus
securing a custom permission to send/receive Intents. PoliCC on Activity and Broadcast (finding 3).
uses Android application permissions: the relationship between
the permission sets of the source/destination apps provides the 4.1. Summary of prior findings
trustworthiness measure that guides the polymorphic delivery of
messages. Finding 1: Common use of extended data fields in Intents. Octeau
Homomorphic Encryption (HE) (Acar et al., 2018) encodes a et al. analyzed the use of ICC in Android app on (1) a ‘‘random
numeric value, so its encrypted value (i.e., ciphertext) can be sample’’ dataset with 350 apps randomly selected from over
arithmetically operated on. HE preserves the invariant: the de- 200,000 apps in the Google Play Store, (2) a ‘‘popular app’’ dataset
crypted result of an arithmetic operation on ciphertexts is iden- of 850 apps from top 25 most popular free apps from 34 cate-
tical to the same operation’s result on the cleartext version of gories in the Play store. 36% of Intents in the ‘‘random sample’’
dataset and 46% in the ‘‘popular apps’’ contain key–value data in
12 Homomorphic encryption is applied to numeric data. the extended data fields (Octeau et al., 2013).
5
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Finding 2: The Intent’s API of operating Integer and String val- 5.1. Design choices
ues (i.e., putString and putInt) are the top 10 used Android API
methods (Li et al., 2016a).
PoliCC follows several design choices that we made by con-
Finding 3: startActivity is the most frequently used ICC method.
sulting both prior studies and our ICC usage studies above.
96% of the apps in the studied dataset (1023 malware samples
(1) Why keep Intents? Finding 1—Intent’s extended data fields
collected by Zhou and Jiang (2012) and 1023 apps randomly
are commonly used in storing data (Octeau et al., 2013). Our study
selected from the Google Play Store) call this method, which
confirmed this finding: Finding 4— About three-quarters of the
accounts for 56% of all the ICC methods calls (Li et al., 2015).
safeware apps and even more of the malware apps access the re-
ceived Intent data.13 Hence, as a plug-in replacement of Android
4.2. Studying ICC usage in the wild
ICC, PoliCC retains the Intent object as the message delivery
vehicle, so existing apps could continue using Intents whose data
I. Study Methodology. We downloaded 1507 safeware apps (i.e., a
would be protected from leakage.
complete set at the time of the study) from the online F-Droid
(2) Why Focus on Integer and String? Finding 2—Among the
repository (F-Droid, 2019), a repository of safe apps. We also
top 10 mostly used Android API methods are those that manipulate
analyzed over 9000 known malware apps from the RmvDroid
repository (Wang et al., 2019), including adware, spyware, trojan, Integer and String values (i.e., putString and putInt) (Li et al., 2016a).
and other riskware. We analyzed these safeware and malware’s Our study confirmed this finding: Finding 5—The most common
distribution binaries as follows: (1) download the *.apk files for data types stored in Intent’s extended data fields are String and In-
each Android app; (2) for each app, decompile its *.apk files into teger. Hence, our design supports operating on encrypted strings
their smali (Gruver, 2015) intermediate representation, which and integer values 6.3.
is amenable to automated program analysis (Gruver, 2015); (3) (3) Why Activity and Broadcast Communication? Finding 3—
examine the smali representation for the accesses to the data The startActivity ICC method is the most frequently used (Zhou and
stored in Intent objects. Jiang, 2012). Hence, PoliCC supports startActivity. To demonstrate
II. Major Findings. HTPD’s applicability, PoliCC also supports sendbroadcast, whose
data flow allows multiple destinations.
Finding 4: More than one-third of safeware/malware apps (4) Why Focus on Communication both within and across
put data into Intent’s extended data fields, and three- Devices? When it comes to the communication both within and
quarters of the safeware apps and even more of the malware across devices, we decided to provide this facility in our system
apps retrieve the received Intent data. Our study shows for two reasons: (a) Due to the growing popularity of wearable
that 34% of safeware, 77% of adware, 50% of spyware, and IoT Android devices, an increasing number of common ap-
50% of trojan, and 41% of other riskware invoke putExtra
plication scenarios now involve device-to-device communication.
to place data into Intents, while 73% of safeware, 91%
Hence, facilitating the implementation of cross-device communi-
of adware, 72% of spyware, 88% of trojan, and 43% of
cation is important. Furthermore, our approach to cross-device
other riskware invoke get*Extra to retrieve data from the
communication brings yet another option to the design space.
received Intents.
(b) We see value in providing a unified programming interface
for different communication types within and across devices. In
Finding 5: The most common data types stored in Intent’s lieu of a unified interface, app developers have to either im-
extended data fields are strings and integers. Our findings plement vastly dissimilar communication mechanisms on their
show that 58% of safeware, 83% of adware, 62% of spyware, own, or learn a different set of programming interfaces for what
77% of trojan, and 42% of other riskware retrieve String is essentially the same communication functionality (e.g., Wear-
objects or arrays. Also, 17% of safeware, 63% of adware, able Data Layer API Google, 2019a). These development practices
54% of spyware, 18% of trojan, and 5% of other riskware incur unnecessary programmer effort and can potentially open
retrieve int values, arrays, or Integer objects. In terms new attack surfaces (e.g., ad-hoc implementations of communica-
of the operations that retrieve Intent data, about 65%, tion mechanisms would likely be insecure). In addition, the time
59%, 54%, 80%, 79% of them return strings, in safeware, and the effort required to support these dissimilar communica-
adware, spyware, trojan, and other riskware, respectively; tion mechanisms divert the resources from the difficult problem
while 21%, 33%, 35%, 11%, 17% of them return integers, in of preventing dangerous data leakage attacks: monitoring data
safeware, adware, spyware, trojan, and other riskware, re- flow or call chains across devices does require additional and
spectively. That is, the data retrieval operations on strings
dissimilar implementation strategies.
and integers account for 86%, 92%, 89%, 91%, and 96% of
Hence, we design PoliCC to support uniform communication
the total retrievals, in safeware, adware, spyware, trojan,
within and across devices. Not only does our reference imple-
and other riskware, respectively.
mentation prove that the unified Intent interface can be applied
to both within and across devices communication and prevent
III. Threats to Validity. As all static analysis techniques, ours is relevant data leakage attacks with our secure message-based
vulnerable to false positives: not all detected scenarios of Intent- communication mechanism, but it also identifies the performance
based communication will be triggered in real app executions. overhead such a mechanism generates. We see this material
Nevertheless, the detected numbers reasonably approximate the
as being conducive in potentially guiding both researchers and
actual runtime occurrences of ICC.
practitioners in determining the acceptable trade-offs between
security and efficiency.
5. PoliCCdesign

We next explain PoliCC’s design and then describe its archi- 13 For conciseness, the term ‘‘Intent data’’ refers to ‘‘the key–value data stored
tecture and permission policies. in an Intent’s extended data field.’’

6
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Fig. 4. PoliCC Architecture.

5.2. System architecture convergent encryption: Variant of Elgamal encryption14 (Damgård

et al., 2003) for int/Integer/BigInteger values and convergent
Fig. 4 shows PoliCC’s system architecture. As discussed in encryption (combines SHA256 with AES) for String values. So
Sections 3.2 and 3.3, starting at a Source App (step 1), a regular int/Integer/BigInteger variables become HEInteger objects, and
Intent object is redirected to PoliCC Module twice (steps 2, 4), String one become encrypted String objects.
first becomes a Host Intent object (step 3), then a Polymorphic
Intent object, finally being delivered to the Destination App 5.3. Permission policies
(step 5). During this process, PoliCC utilizes Xposed hooks to redi-
rect the Intent object into PoliCC Module. To secure the Intent As discussed in 3.3, PoliCC uses Android app permissions and
object, PoliCC Module converts it into a Host Intent object then the relationship between the permission sets of the source/des-
a Polymorphic Intent object via modules Serialize & Dese- tination apps as the trustworthiness measure that determines
rialize, Re-encapsulation, Routing info & Permission whether to deliver raw data or encrypted data.15 Hence, we
Examination, and Encrypt & Decrypt. To enable cross-device design PoliCC as a policy-based middleware: an extensible set of
communication, PoliCC transmit Host Intents across devices via policies governs data access and Intent routing. → indicates the
PoliCC Service’s Device-to-Device Communication. Users From-To Intent transmission relationship within or across devices.
authorize which apps can send data across devices via Config- E.g., {I | (S → D)t } indicates that the source app S sends the Intent
uration, lest the transmitted Intents cannot cross the device’s I to the destination app D at time t (S and D can be installed on
boundaries (discussed in Sections 6.1 and 6.2). the same or different paired devices).
In addition, user-configured custom keys encrypt the decryp- P(S)t denotes the permission set of app S at time t. If the user
tion keys of homomorphic/convergent encryption, persisting changes P(S) at runtime, P(S)t ̸ = P(S)t +1 . Hence, PoliCC always
them in Keys, private storage managed by Key Management dynamically analyzes permissions, reading the latest permissions
(discussed in Section 6.4). Besides, by configuring PoliCC to for all apps. Further, I denotes the original Intent, and IEN denotes
notify of the transmission information (e.g., source/destination, that its data has been encrypted. We define the PoliCC policies as
permissions, data types, actions) (Notify), the user can stop the follows:
delivery of any PoliCC Intents. (1) Encryption & Decryption Policies. When D receives I (or IEN )
With the design choices above, consider how our architecture from S, if the permission set of S is a subset of or equal to that of
secure the Android ICC while enabling untrusted data process. D, I’s (or IEN ’s) data remains unencrypted; encrypted otherwise:
To transmit messages securely, PoliCC provides Host and Poly- If {I or IEN | (S → D)t },
morphic Intents for ICC’s data transmission flow of both Activity
and Broadcast. The Host Intent acts as a transmission vehicle • iff P(S)t ⊆ P(D)t , return I
over the Android ICC; it hides the original Intent’s data and • otherwise, return IEN
routing information. The Polymorphic Intent delivers data poly-
morphically: only destination apps with sufficient permissions 14 As fully homomorphic encryption is slow, its partial variant achieves a
can access raw Intent data. To allow untrusted apps to operate practical performance security tradeoff.
on sensitive data securely, PoliCC provides arithmetic and com- 15 Because the ‘‘no data’’ delivery is caused by failed data integrity checks
parison operations on ciphertext, enabled by homomorphic and rather than permissions, we detail it in 6.2.

7
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

(2) Permission Transitivity. Whether a destination app receives Within the device, Intents are transmitted using the Android
I or IEN is determined by the transitive closure of the permis- ICC channel. In contrast, to send/receive the Intent transmitted
sion relationships between the encountered apps in that Intent’s across devices, PoliCC service applies the Bluetooth technology.
transmission chain: Launched at the device start time, the service acts as both a server
If {I | ((S → D1)t → D2)t +1 }, and a client. As a client, to send Intents across devices, it transmits
serialized Host Intents to the paired devices. As a server, at launch
• iff (P(S)t +1 ∪ P(D1)t +1 ) ⊆ P(D2)t +1 , return I
time, it starts a background monitoring thread to keep track of
• otherwise, return IEN
the data streams sent by remote clients. Upon receiving a sent
stream, it deserializes the stream into a Host Intent, to be further
6. Implementation
transmitted by means of the Android ICC. By checking the source
information, PoliCC confirms if an Intent arrived from a remote
We describe PoliCC’s hidden transmission and polymorphic
device. It forwards such Intents directly to the receiving point,
delivery.
then to follow the same steps as Intents transferred within the
same device.
6.1. Hidden transmission

To seamlessly integrate hidden transmission into Android ICC, 6.2. Polymorphic delivery
we had to determine: (1) where to place the sending/receiving
points, (2) how to pack message data into its delivery vehicle, To seamlessly integrate polymorphic delivery into Android
and (3) how to transmit messages uniformly within and across ICC, we had to determine: (1) how to link trustworthiness (i.e.,
devices. We solve these problems as follows. routing info and permission relationships) to delivery strategies
(1) Hook Mechanism. For PoliCC to take control over the delivery (i.e., no data, raw data, or encrypted data), and (2) if it is possible
of Intent objects, the hook mechanism taps into the Android to bypass our secure delivery mechanism and how to defend
ICC. ICC commences by invoking the API methods startActivity against it. We solve these problems as follows.
to start an activity and sendbroadcast to send a broadcast, so (1) Examining Routing Info and Permissions. As described
we use them as ‘‘sending points.’’ Similarly, ICC ends up the above, in the sending point, PoliCC re-encapsulates the original
final delivery by invoking performLaunchActivity for the activ- Intent object, retaining its routing information, and inserts the
ity and deliverToRegisteredReceiverLocked for the broadcast, so source app’s information, which is checked as follows:
we use them as ‘‘receiving points.’’ PoliCC intercepts the send- (a) to check the routing information, having intercepted the
ing/receiving points by hooking into these API methods via the Intent in the receiving point, PoliCC extracts the routing infor-
beforeHookedMethod and afterHookedMethod interfaces, mation from both the Host and original Intents and compares
respectively. PoliCC’s custom code is injected to execute before them for equality (i.e., integrity check). Then, it checks whether
or after the intercepted API methods, thus performing HTPD’s the current destination is reachable through the original Intent’s
transmission strategies. Note that we used the Hook mechanism routing information (i.e., destination examination). If any of these
to create a viable proof of concept to be able to evaluate PoliCC’s checks fails, the Intent object may have been tampered with,
security-enhancing properties. To deploy HTPD commercially, causing PoliCC to deliver no data to the destination app.
one should consider an implementation fully integrated with the (b) to check the permission relationships between the source
system.
and destination apps, from the original Intent, PoliCC extracts
(2) Host Intent. A Host Intent is derived from an original Intent
the inserted source app information. Note that, before sending
by retaining the routing information (e.g., action, category) but
or forwarding an Intent (i.e., the sending point), PoliCC appends
removing the extended data (i.e., the data inserted via putExtra).
the current source app’s package name into the Intent’s data
Instead, the only piece of extended data in Host Intent are serial-
field, thus keeping track of the Intent’s transmission history.
ized and encrypted representations of the original Intent. This im-
At the receiving point, PoliCC computes the union of the per-
plementation strategy is non-intrusive, thus requiring no changes
missions granted to all source apps, through which the Intent
to the source app’s Intent API. Specifically, our implementation
has passed in that transmission. Next, PoliCC obtains the des-
intercepts the built-in Intent transmission procedure at the points
tination app’s permissions via the Android API. The results are
right before an Intent is dispatched (i.e., sending points) and
compared based on the permission transitivity policy (see 5.3):
delivered (i.e., receiving points). At the sending point, a Host
Intent is constructed, replacing the original Intent; at the re- if the destination app’s permissions are not equal to or exceed
ceiving point, the Host Intent’s content is extracted, decrypted, the union of the source permissions set, PoliCC delivers the
and deserialized into the original Intent, which is then polymor- homomorphically/convergently encrypted data to the destination
phically delivered to the destination app (see 6.2). Notice that app.
this strategy makes it possible to transmit Host Intents through (2) Defense against Encryption Bypassing Attack. When for-
the built-in Intent transmission channels. Because these two in- warding a polymorphic Intent with encrypted data to a suffi-
terception points cannot be bypassed, the Host Intents would ciently permitted destination app (see policies in 5.3), PoliCC de-
always be constructed at the sending point, and the original crypts the contained data. To that end, a special field,
Intent would always be reconstructed at the receiving point. In isEncrypted, reflects whether the extended data of a Polymorphic
essence, PoliCC can straightforwardly detect any tampering with Intent has been encrypted, so as to prevent the encryption of
the routing information of a Host Intent. ciphertext. However, malware can attempt to bypass the en-
(3) Transmitting Intents. To control how apps exchange data cryption process by maliciously setting the isEncrypted field of
with PoliCC, device users authorize apps to transmit data across an unencrypted Intent to ‘‘true,’’ an occurrence that we call an
devices. PoliCC maintains a list of the authorized apps to check encryption bypassing attack.
each app encountered by a transmitted Intent. If all encoun- To defend against this attack, PoliCC provides a simple but
tered apps are authorized, PoliCC continues transmitting the effective defense: when the isEncrypted field is set to ‘‘true’’,
Intent within and across devices; otherwise, only within the same PoliCC first decrypts the data and then encrypts it again. How-
device. ever, decrypting unencrypted data produces an unusable value,
8
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

out of which the original Intent data cannot be recovered.16 Recall the scenario from the threat model in 2.1, in which a
Hence, this design effectively defends against the attacks that source app with GPS permissions obtains and sends user geolo-
tamper with the isEncrypted field, albeit rendering the trans- cation information to a destination (e.g., a cloud or edge server)
ferred data unusable as a result of invalid data attacks. Our design to estimate the distance of the user’s movement.18 In our case,
contends with the possibility of Intent data becoming damaged in the destination is an Android app U without these permissions.
such cases, as the main objective is to defend against data leakage Suppose that every minute, U receives a polymorphic Intent,
attacks. whose contained HEInteger object represents the new latitude to
which the user moved during that minute. Having obtained the
6.3. Computing with encrypted data HEInteger object (lines 1,2 in the code snippet below), the app
can obtain the difference between the latest value and the saved
As discussed above, Intent’s String data become convergently encrypted old latitude value (line 4), multiplying the result by 69
encrypted String objects, and int/Integer/BigInteger data be- (i.e., 1 latitude ≈ 69 miles (US Geological Survey, 2019)) (line 5)
come homomorphically encrypted HEInteger objects in order to to estimate the distance (in miles) by which the user has moved.
allow untrusted apps to operate on ciphertext. The final result can be sent back to the source app without ever
(1) Operating on Encrypted String Data. PoliCC convergently decrypting it.
encrypts String value, so the ciphertext can be compared for
equality. The encrypted string’s hash code is computed via SHA256 1 Object newLatitude =
(Standard, 2002) to be used as the encryption key. This encryption 2 (Object)intent.getSerializableExtra("latitude");
(i.e., encrypt the string value with its hash code) uses AES (Miller 3 if (newLatitude instanceof HEType) {
et al., 2009) in the CTR mode.17 The computed hash is encrypted 4 oldLatitude.subtract((HEInteger)newLatitude);
with a user-provided key via AES in the CBC mode. Finally, 5 (HEInteger)oldLatitude.multiply(69); }}
PoliCC combines the encrypted String value and the encrypted
hash, outputting the combined value as the ciphertext. Since
the encrypted hash’s size is fixed, the outputted ciphertext can 6.4. Key management
be easily separated, so (a) the destination apps can obtain the
encrypted String value to compare with their own convergently In its operations, PoliCC manages three types of keys: pub-
encrypted String values; (b) PoliCC can obtain the hash value to lic, private, and symmetric. The former two types are used for
recover the raw String values. homomorphically encrypted data. The latter one is used for con-
Recall the threat model’s scenario from 2.1, in which the vergently encrypted data and encrypted Intent byte arrays inside
system broadcasts an IP address, received by an untrusted app Host Intents. To manage them, PoliCC’s API method
U (line 1 in the code snippet below). U wants to use the received getHEIntegerKey() returns public keys that enable developers to
IP address to verify its host IP. Since U’s permission set is smaller construct their own homomorphically encrypted data for arith-
than the system’s, U receives a convergently encrypted IP address. metic operations. When it comes to the private and symmetric
To still perform its IP verification operation, U can first retrieve keys, PoliCC places them into its private storage, which can only
the received encrypted IP, by obtaining the combined ciphertext’s be accessed by PoliCC itself. For device-to-device communication,
substring that begins at the hash size’s offset (line 2). Then, U we assume that the user has securely paired the communicating
can encrypt host IP in its stored collection (lines 3,4), comparing devices via Bluetooth (Section 2.3), so the PoliCC agents running
the received encrypted IP with its own encrypted IP (lines 5), and on these devices are considered trustworthy. Once the devices
respond whether they matched (lines 6,7). are paired, the paired PoliCC agents directly synchronize their
keys with each other. In the future, to exchange keys with un-
trustworthy devices, we plan to add new interfaces that configure
1 String combinedVal = intent.getStringExtra("IP"); PoliCC to use any available key exchange mechanism, such as
2 String recvIP = combinedVal.substring(HASH_SIZE); Diffie–Hellman exchange (Rescorla, 1999).
3 String hash = SHA256(hostIP);
4 String encryptedHostIP = AES(hash,hostIP);
7. Evaluation
5 if (encryptedHostIP.equals(recvIP))
6 return true;
we seek to answer the following questions: Q1. Effectiveness:
7 return false;
How effectively does PoliCC reduce the threats? Q2. Cost: What
(2) Operating on Encrypted Integer Data. HEInteger takes ad- is the performance overhead of PoliCC on top of the Android ICC?
vantage of the Variant of Elgamal encryption (Damgård et al., Q3. Effort: How much additional programming effort is required
2003), a partial homomorphic encryption scheme that allows to use PoliCC instead of Android ICC?
adding and multiplying the encrypted numeric data. HEInteger
extends java.math.BigInteger and overrides the add, subtract 7.1. Environment setup
and multiply methods to provide its own homomorphic ver-
sions of the addition, subtraction, and multiplication operations, Because PoliCC is implemented on top of the Xposed frame-
respectively. Thus, HEInteger not only protects the contained work, our evaluation uses this framework’s latest version
int/Integer/BigInteger numeric data, but also supports math- (XposedBridge version-82 and Xposed Installer-3.1.5). Besides,
ematical operations on the contained encrypted data. Besides, to make use of as many Android latest features as possible,
HEInteger implements a marker interface HEType to allow while guaranteeing the compatibility of Android apps, we use
instanceof queries in the apps to determine whether the re- the Android Nougat (7.x) and Lollipop (5.x), currently run by
trieved integer is encrypted. 28.2% (the first highest percentage among the 8 most popular
Android versions (Google, 2019b)) and 17.9% (the fourth highest
16 With PoliCC’s encryption implementation, decrypting unencrypted data
destroys the original data, which may not be the case for other encryption 18 GPS information can be used to estimate the movement, for example, one
implementations. degree of latitude equals approximately 69 miles (364,000 ft) (US Geological
17 CTR is used for performance reasons and can be replaced by other modes. Survey, 2019).

9
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

percentage) of Android devices. These Android releases as well as Having the geolocation permissions (ACCESS_COARSE_LOCATION
the latest one are vulnerable to all the aforementioned attacks. and ACCESS_FINE_LOCATION), Mylocation can obtain the user’s
In all experiments, the devices are: Nexus 6 with Android 7.1.1, geolocation and share it with other apps via an implicit Intent
Moto X with Android 5.1, and Moto G2 with Android 5.1.1. with the ACTION_SEND action. Using its Intent Filter for the
ACTION_SEND action, QKSMS can receive the Intents containing
7.2. Evaluation design this action. However, QKSMS has no geolocation permissions. In
our case studies, we always used Mylocation as the source and
Q1. Effectiveness. As discussed in 2, PoliCC plug-in replaces ICC QKSMS as the destination.
to secure its message-based communication against interception, Q2. Cost. To determine whether PoliCC’s performance overhead
eavesdropping, and permission escalation attacks. To evaluate is acceptable, we compare the respective execution time and
PoliCC’s security mechanisms, we simulated the attacks, dis- energy consumption19 taken to deliver Intent data from the
cussed in 2.1, and conducted a case study with three real-world source to the destination app by PoliCC and the Android ICC.
apps, discussed in turn next: Our measurements (a) exclude prompting the user to approve
(1) Reproducing Attacks. To test how effectively PoliCC defends the Intent transmission; (b) fix the length of intent data items
apps against the attacks described in 2.1, we had to reproduce (32 bytes for the String objects); (c) repeat all executions 20
these attacks with real apps. Unfortunately, several of the apps, times and then compute the average execution time; (d) trigger
mentioned in the CVE entries describing the attacks, are not open- startActivity/startBroadcast 100 times in 5 min, measuring the
sourced, while the target attacks would be impossible to trigger amount of energy consumed by the participating apps and the
in a black-box fashion. Hence, we had to recreate the described system; and (e) fix the experimental device (i.e., Moto G2) to
apps on our own. compare PoliCC with the Android ICC. Besides, we isolate the
(a) To reproduce the interception attack on messages exchanged time PoliCC takes to deliver Intents, including the hook points
by apps within the same device, we created: source app S, destina- and device-to-device transmission (if applicable) to identify the
tion app D, and interceptor app U. S invokes startActivity(Intent) performance bottlenecks.
to send an implicit Intent to D. However, by registering the same Q3. Effort. To confirm PoliCC’s portability, we test it on com-
Intent Filter, the untrusted app U receives the same Intent object binations of devices that run the Lolipop and Nougat Android
as well. To reproduce the interception attack on messages exchanged framework versions. To estimate PoliCC’s programming effort, we
by apps across devices, we implemented another interceptor app measure the uncommented lines of code (ULOC) required to mod-
U2, which intercepts the sent Intent objects before they leave the ify the original source app’s ICC code that sends an Intent to a des-
sender device’s boundary, to misroute their delivery by tamper- tination app on the same or a paired device to (a) access the Intent
ing with their routing. Without loss of generality, we assumed data, and (b) retrieve and use homomorphically/convergently
that the end-user had designated the destination apps as our encrypted data.
untrusted apps U and U2.
(b) To reproduce the eavesdropping attack, we created source
7.3. Results
and destination apps (i.e., S and D), with the same system-level
permissions, and IP Verification app V with no such per-
missions. S invokes sendBroadcast(Intent) to broadcast an Intent I. Effectiveness.
to be received by D. The Intent object contains an IP address. Reproducing Attacks
However, by registering the same Intent Filter, V can receive the Table 1 summarizes the outcomes of reproducing each of the
same Intent object as well. attacks:
(c) To reproduce the permission escalation attack, we created GC, (1) For the interception attack on messages exchanged by apps
a geolocation collecting app, permitted to obtain geoloca- within the same device (i.e., row ‘‘Interception—within device’’),
tions from the GPS sensor, and DE, a distance estimating app, whether the interceptor app U’s permissions are sufficient or
forbidden to read geolocations. To process the obtained geolo- not, Android ICC always delivers the Intent’s raw data to U, thus
cations, GC invokes startActivity(Intent) to directly send an ex- leaking sensitive data to an untrusted party. In contrast, if U’s per-
plicit Intent to DE. DE receives the Intent, retrieves the contained mission set is smaller than that of the source app (i.e., insufficient
geolocation, and estimates the distance of user movement. permissions), PoliCC delivers encrypted Intent data, thus success-
We simulated the above attacks using Android ICC and PoliCC, fully preventing the attack. For the interception attack on messages
and then compared the respective outcomes. To determine exchanged by apps across devices (i.e., row ‘‘Interception—across
whether PoliCC’s polymorphic delivery correctly responds to devices’’), after U2 tampers with the Host Intent’s routing infor-
changes in app permissions and device-to-device authorizations, mation, its examination fails causing PoliCC to deliver no data to
we carried out each attack scenario with sufficient and insuffi- the destination app, thus repelling the attack.
cient permissions, with allowed and forbidden communication (2) For the eavesdropping attack, whether the IP Verifi-
across devices. cation V’s permissions are sufficient or not, the Android ICC
More importantly, to illustrate that apps with insufficient per- always delivers a raw IP address, thus leaking the data to V.
missions can still execute useful operations, we reused the IP In contrast, when V’s permission set is smaller than that of
Verification V and distance estimator (DE) apps from the the source app, PoliCC delivers convergently encrypted IP ad-
attack scenarios (b) and (c) above to check if their original opera- dress. Although V cannot access the raw data, it can still validate
tions (i.e., verify host IP—V, estimate distance of movement—DE) the host IP using the received encrypted IP address (column
can still be executed. ‘‘Operations’’).
(2) A case study with real-world apps. We also evaluated how (3) For the permission escalation attack, similar to the attacks
effective PoliCC was at mitigating the aforementioned attacks above, the Android ICC always delivers an explicit Intent with
in three open-source, real-world apps: Intent Intercept (In- a raw geolocation to the distance estimator (DE), so the
tent Intercept, 2019) (a debugging app), Mylocation (My Loca-
tion, 2019) (a GPS app), and QKSMS (QKSMS, 2019) (a messaging
app). By registering numerous Intent Filters, Intent Inter- 19 We measure energy consumption with PowerTutor 1.4 (Mark Gordon and
cept intercepts implicit Intents and examines their data fields. Tiwana, 2019).

10
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Table 1
Effectiveness of PoliCC.
Attacks Permission Data retrieved Successful defense Operations Authorization (across devices) D-to-D
ICC PoliCC ICC PoliCC ICC PoliCC
Interception insufficient raw encrypted × ✓ – –
forbidden ×
—within device sufficient raw raw × × – –
Interception – – no data – ✓ – – allowed 
—across devices

insufficient raw encrypted × ✓  ✓

forbidden ×
sufficient raw raw × ×  ✓
Eavesdropping
insufficient – encrypted – ✓ – ✓
allowed 
sufficient – raw – × – ✓
insufficient raw encrypted × ✓  ✓
forbidden ×
Permission sufficient raw raw × ×  ✓
Escalation insufficient – encrypted – ✓ – ✓
allowed 
sufficient – raw – × – ✓

attack succeeds in exfiltrating the sensitive geolocation. In con- geolocation, sending it to an added Activity in QKSMS. In the
trast, PoliCC Intent data’s encryption status is determined by the original setup, this permission escalation attack always succeeds.
source/destination permission relationship. When DE has insuf- With PoliCC, the attack always fails, as long as QKSMS has no
ficient permissions, PoliCC delivers homomorphically encrypted geolocation permissions.
longitude and latitude values, so their raw values are not leaked. Q2. Cost. Table 2 (at the top) shows PoliCC’s overheads. Specifi-
More importantly, DE can still perform its distance estimation cally, PoliCC’s startActivity increases T by 28.3 ms (49.6%), Eapp by
operation to approximate the distance by computing with the 0.8J (10.1%), and ∆Esys by 1 mW (2.7%); sendBroadcast increases T
encrypted values. by 40.4 ms (15.4 times), Eapp by 0.5J (9.4%), ∆Esys by 2mW(11.1%),
In addition, PoliCC’s across-devices transmission works as ex- as compared to the Android ICC counterparts. Table 2 (at the
pected: with ‘‘allowed’’ authorization, the device-to-device Intent bottom) breaks down the execution time per each PoliCC pro-
transmission always succeeds (column ‘‘D-to-D’’); with ‘‘forbid- cedure. In both startActivity and sendBroadcast, the Sending/Re-
den’’ authorization, the Intent cannot be transferred across the ceiving Points perform similarly: these procedures’ hook and
device boundary. Moreover, whenever the destination app is re-encapsulation mechanisms are fixed for all operations. Not
running on the same or different devices, PoliCC correctly de- surprisingly, when communicating across paired devices, the ma-
livers no data, raw data, or encrypted data, by examining the jority of time is spent in the Bluetooth communication itself,
routing information and the permission relationships between which is a fixed cost.
the source/destination apps. In summary, the Android ICC leaves Quantity-wise, since PoliCC increases T by 40.4 ms (43.2–
the data vulnerable to all three attacks, while PoliCC prevents 2.8 in sendBroadcast column) at most, its execution time over-
these attacks in the cases of communication within and across heads are in line with other related solutions (e.g., Krohn et al.
devices, while still preserving the ability of untrusted destination (2007)’s performance overhead is ≈39 ms), with the total la-
apps to operate on the received encrypted message data. tency much lower than the Android response time limit (5000
(2) Case study with real-world apps. ms Google, 2021). Also, since PoliCC increases Eapp by 0.8J (8.7–
Case 1 (interception): (a) QKSMS acts as the malicious app 7.9 in startActivity column) and ∆Esys by 2 mW (20–18) at most,
that intercepts the implicit Intents sent by Mylocation. In the its energy consumption overheads are negligible. It is PoliCC’s pro-
original setup, QKSMS always obtains the raw geolocation value. tection mechanisms (i.e., re-encapsulation, encryption/decryp-
With PoliCC, since QKSMS lacks the geolocation permissions, it tion) that incur these performance and energy overheads.
obtains only a homomorphically encrypted geolocation. With the Percentage-wise, PoliCC increases Eapp by 10.1% ( 8.77−.97.9 ∗ 100%
geolocation permissions added to QKSMS’s manifest file, it is the in startActivity) and ∆Esys by 11.1% ( 2018 −18
∗ 100% in
end-user who determines the app’s data access by granting or sendBroadcast) at most, so the energy consumption overheads are
declining the geolocation permissions, so QKSMS obtains the raw negligible. In contrast, the execution time overheads are signifi-
or encrypted geolocation values, respectively. .2
cant: PoliCC increases T by 15.4 times ( 43 2.8
in sendBroadcast
(b) Intent Intercept acts as the malicious app that inter- 85.3−57.0
column) and 49.6% ( 57.0 ∗ 100% in startActivity). We report
cepts the implicit Intents. The app is configured to always obtain our evaluation results from the perspectives of both absolute
the implicit Intents sent by Mylocation. However, as it lacks numbers and percentage increases, as our ultimate objective is
GPS permissions, Intent Intercept can only access geolocation to make it possible for developers to make informed decisions on
data that is homomorphically encrypted, so the raw geolocations the suitability of our solution in specific scenarios.
are never leaked. For cross-device communication, the highest performance and
Case 2 (eavesdropping): To execute an eavesdropping attack, energy overheads are incurred by sending an Intent to start an
Mylocation sends the same Intent as in Case 1 via an added Activity across devices (T of 539.9 ms, Eapp of 11.4J, and ∆Esys
sendBroadcast. QKSMS receives this Intent via an added broadcast of 61 mW). The observed latency is in line with existing cross-
receiver, registered for the ACTION_SEND action. In the original device communication scenarios (Cruz and Tilevich, 2018; Kang
setup, QKSMS always obtains the raw geolocation, irrespective et al., 2016; Le and Clyde, 2018), while the energy consumption
of whether the end-user grants/declines the geolocation per- overheads are negligible, particularly due to battery capacities
missions. With PoliCC, it is the end-user who determines the soaring and fast charging technologies becoming mainstream.
app’s data access by granting or declining the geolocation permis- Q3. Effort. We first confirm PoliCC’s portability by testing its
sions, so QKSMS obtains the raw or encrypted geolocation values, operations on three Android devices/versions: Nexus 6/Android
respectively. 7.1.1, Moto X/Android 5.1, and Moto G2/Android 5.1.1 by running
Case 3 (permission escalation): To execute a permission escala- our subject apps on these devices in different combinations. This
tion attack, Mylocation creates an explicit Intent containing a
11
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Table 2
PoliCC’s Overheads (milliseconds—ms, Joules—J, milliwatt—mW).
ICCs startActivity (T /Eapp /∆Esys )a sendBroadcast (T /Eapp /∆Esys )a
Android ICC 57.0 ms/7.9 J/37 mW↑ 2.8 ms/5.3 J/18 mW↑
PoliCC (within device) 85.3 ms/8.7 J/38 mW↑ 43.2 ms/5.8 J/20 mW↑
PoliCC (across devices) 539.9 ms/11.4 J/61 mW↑ 333.1 ms/9.2 J/55 mW↑
Operations Sending point Receiving point Device-to-Device
startActivity 28.2 ms 13.5 ms 460.7 ms
sendBroadcast 28.8 ms 9.5 ms 202.9 ms
a
T : execution time (ms); Eapp : energy consumed by source/destination apps (J);
∆Esys : additional system energy consumed by ICCs (mW).

Table 3 40.4 ms). In fact, even with this large performance overhead,
PoliCC’s Extra Prog. Effort (ULOC). the end user should not suffer from poor responsiveness:
Send Retrieve Use Create even 43.2 ms (as compared to the original 2.8 ms) is still
int/Int./BigInt. Str. int/Int./BigInt. Str. int/Int./BigInt. Str. less than 1/20th of a second. 20
0 1/1/0 0 4/4/1 1 3/3/3 3

Takeaway-1: To mitigate the performance overhead,

test has not revealed any deployment and operational issues. For one can integrate our solution with the Android
source apps, the PoliCC API is indistinguishable from that of the system, which reduces the hooking process (Sec-
Android ICC as well as for sufficiently permitted destination apps, tion 6.1) to increase execution speed. One can also
as the delivered Polymorphic Intents return raw data. With in- refine the security mechanism for sendBroadcast
sufficient permissions, additional code is required in destination (e.g., relatively weaken the encryption phase or use
apps to handle the delivered homomorphically and convergently a faster encryption algorithm) in order to speed it
encrypted data. up.
Nevertheless, the extra programming effort is small, as Table 3
demonstrates: in the source apps, PoliCC requires no devia- • false positives/negatives: PoliCC’s HTPD implementation may
tion from the familiar Android ICC API (column ‘‘Send’’). In the suffer from false positives/negatives if app permissions are
destination apps, the code for retrieving, using, and creating granted incorrectly: (1) sufficient permissions are granted
int/Integer/BigInteger and String objects require extra lines of to a malicious app (i.e., false-negatives); (2) insufficient per-
code (columns ‘‘Retrieve’’, ‘‘Use’’, and ‘‘Create’’): (a) For BigInteger missions are granted to a benign app (i.e., false-positives).
and String objects (columns ‘‘BigInt.’’ and ‘‘Str.’’), due to the
inheritance hierarchies of their operations, the code for retrieving
them is indistinguishable between the Android ICC and PoliCC
Takeaway-2: To mitigate such false positives/neg-
(column ‘‘Retrieve’’). To use the retrieved String object, 1 extra
atives, one can notify users of potential security
LOC is required to separate its convergently encrypted value.
attacks by using PoliCC’s notification feature. As an
To use the retrieved BigInteger object, 1 extra LOC is required
extra feature 5.2, PoliCC’s Notify module can be
to check whether the data is homomorphically encrypted (col-
configured to report the transmission information
umn ‘‘Use’’). (b) For int/Integer values (columns ‘‘int’’/‘‘Int.’’),
(e.g., source/destination, permissions, data types, ac-
their original receiving and operating methods are replaced with
tions) to the user, who can then stop the delivery
HEInteger’s methods (add, subtract, and multiply), taking 4 extra of any PoliCC Intents. Further, the Notify module
LOCs at most (columns ‘‘Retrieve’’ and ‘‘Use’’). Finally, it takes 3
can also mitigate the denial of service attacks: it
extra LOC to create homomorphically and convergently encrypted
can detect and block notifications floods from any
int/Integer/BigInteger and String values (column ‘‘Create’’). source app.

7.4. Discussion

7.5. Limitation
In this section, we first discuss our key evaluation results, and
then present takeaways.
As a reference implementation, PoliCC did not cover all the
• performance characteristics: PoliCC applies the same security ICC Intent scenarios, which contained limitations below.
enhancement to both start- Activity and sendBroadcast,
• data type: As discussed in Section 5, PoliCC only supports
which in turn adds quite similar latency overheads: 28.3 ms
operating on string and integer values, including String,
for startActivity and 40.4 ms for sendBroadcast. However,
int, Integer, and BigInteger. However, it lacks support for
percentage-wise, PoliCC increases the execution time of
other data types (e.g., string/int arrays, char, long, Parce-
sendBroadcast by 1540%, while startActivity only by 49.6%.
lable, etc.) (Google, 2022). In fact, in order to allow un-
These differences is an artifact of how Android ICC imple-
trusted apps to operate on ciphertext, PoliCC converts In-
ments these communication mechanisms. In the original
tent’s String data into convergently encrypted String ob-
form, sendBroadcast takes about 2.8 ms, while startActivity
jects, and int/Integer/BigInteger data into homomorphi-
57.0 ms, a 2000% difference. Adding the same overhead to
cally encrypted HEInteger objects. Similarly, to enable other
two drastically different baselines explains the vast dissimi-
larities in the resulting overhead values. I.e.: startActivity in-
creased by 49.6% (57.0 ms → 85.3 ms, added extra 28.3 ms), 20 This total latency is still much lower than the Android response time limit
sendBroadcast by 1540% (2.8 ms → 43.2 ms, added extra (5000 ms Google, 2021).

12
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

types, we can either convert the data into our current ho- apply convergent encryption to securely de-duplicate the num-
momorphic/convergent encryption objects, or create new ber of backup files (Anderson and Zhang, 2010). Wilcox-O’Hearn
homomorphic/convergent encryption classes for them. Such et al. apply convergent encryption to build a secure distributed
an extension would only take an additional engineering storage (Wilcox-O’Hearn and Warner, 2008). In fact, many com-
effort. mercial systems used convergent encryption to enhance user
• intercepting communication APIs: As discussed in Section 5, data security and privacy: Bit (2019), Cip (2019), Fre (2019), flu
PoliCC only intercepts startActivity and sendBroadcast (2019), and GNU (2019). PoliCC brings homomorphic/conver-
rather than their relevant communication APIs (e.g., gent encryption to mobile computing to secure message-based
startActivityFromChild). We support ‘‘startActivity’’ because communication while enabling untrusted apps to execute useful
it is the most frequently used, and ‘‘sendBroadcast’’ because operations.
its data flow allows multiple destinations (discussed in Sec- Inter-Device Data Exchange. Several prior works focus on sup-
tion 5.1-(3)). It should be possible to reuse much of the ex- porting Android devices to exchange data. RICCi (Cruz and Tile-
isting code for intercepting startActivity and sendBroadcast vich, 2018) makes it possible to exchange data peer-to-peer or
to extend this feature to other APIs. over different networks by extending the built-in Intent API.
• hooking mechanism: PoliCC performs Hook mechanism via SAMD (Lee et al., 2018) supports platform-level device-to-device
Xposed. Note that we use Xposed to create a viable proof of collaboration, with the collaborating devices sharing code/re-
concept to be able to evaluate PoliCC’s security-enhancing sources and executing remote functionalities. Sip2Share (Canfora
properties. To commercially deploy HTPD, one can fully and Melillo, 2012) shares Services and Activities across devices by
integrate it and its mechanisms with any Android release extending the Android SDK. With ShAir, distributed mobile apps
and other mobile platforms, despite the peculiarities of our share data P2P (Dubois et al., 2013). PoliCC enables devices to
reference implementation. share data via a unified Intent API, while preserving the shared
data’s security.

8. Related work
9. Conclusions

Data flow & ICC calls Monitoring. Most of the existing solutions We have presented HTPD, hidden transmission and
counteract data leakage attacks by monitoring the data flow or polymorphic delivery, a novel message-based communication
ICC calls. TaintDroid (Enck et al., 2014) traces data flows by model that secures message-based communication while allow-
labeling sensitive data and transitively applying labels as the ing untrusted apps to operate on the received message data.
data propagates through program variables, files, and interpro- As a reference implementation of HTPD, PoliCC plug-in replaces
cess messages. If any tainted data is to leave the system via a and extends Android ICC to defend against common data leakage
sink (e.g., network interface), the system notifies the user about attacks within and across devices, while also providing a uniform
the coming data leakage. FlowDroid (Arzt et al., 2014) applies API for transmitting Intents. Our evaluation demonstrates that
static taint analysis to check if any app lifecycle contains data PoliCC mitigates interception, eavesdropping, and permission
leaks. XManDroid (Bugiel et al., 2011) tracks and analyses the ICC escalation attacks by trading off performance costs, programming
data transferred in Intent objects at runtime to enforce the app’s effort overheads, and security. In addition, we hope that our work
compliance with the defined permission policy. QUIRE (Dietz would lead to HE and CE becoming widely accepted in the design
et al., 2011) enables users to examine and terminate the chain space of mobile message-based communication.
of requests associated with an ICC call. ComDroid (Chin et al., As future work directions, we plan to enable PoliCC to support
2011) statically analyses *.dex binaries of Android apps to log po- more data types and communication APIs (e.g., startActivityFrom-
tential component vulnerabilities. Besides, ComDroid tracks how Result) as well as further enhance its protection capabilities,
an Intent object changes moving from its source to destination. for example, applying deep learning-based anomaly detection
Other state-of-the-art Intent vulnerabilities detectors (e.g., Ic- to identify the Intents that need to be protected, and utilizing
cTa Li et al., 2015, DINA Alhanahnah et al., 2019, DroidRA Li et al., Android Trusted Execution Environment (Trusty) to secure the
2016b, SEALANT Lee et al., 2017, IntentScope Jing et al., 2016) sensitive operations.
further improve the above methods for monitoring data flows
& ICC calls. However, their reliance on overly restrictive policies Declaration of competing interest
prevents them from supporting Android application-specific data
flows, also causing false-positives when data flows change unpre- The authors declare that they have no known competing finan-
dictably. In contrast, HTPD model systematically defends against cial interests or personal relationships that could have appeared
data leakage attacks, requiring neither data flow nor call chain to influence the work reported in this paper.
tracking.
Encryption. Homomorphic encryption enables computational op-
Acknowledgments
erations on ciphertext, with some prior applications to mobile
cloud computing. Carpov et al. (2016) use homomorphic encryp-
The authors thank the anonymous reviewers, whose insightful
tion to preserve the privacy of cloud-based health data. Drosatos
comments helped improve this paper. This research is supported
et al. (2012) use homomorphic encryption to preserve the privacy
by National Science Foundation (NSF, USA) Grant #1717065 and
of crowd-sourced data accessed via the cloud. Besides, homo-
Cisco Research (USA Grant CG# 1367161.
morphic encryption also can be used to compute the proximity
of users in mobile social networks: Carter et al. (2014) use ho-
momorphic encryption to find common locations and friends via References
private set intersection operations that preserve user privacy.
2019. Bitcasa. http://www.bitcasa.com/.
Convergently encrypted ciphertext can be compared, so this en-
2019. Ciphertite. http://www.ciphertite.com.
cryption can securely identify duplicated records. Bennett et al.’s 2019. Flud. http://flud.org.
convergent encryption-based encoding scheme allows boolean 2019. Freenet. https://freenetproject.org/.
searches on ciphertext (Bennett et al., 2002). Anderson et al. 2019. Gnunet. http://gnunet.org.

13
Y. Liu, B.D. Cruz and E. Tilevich The Journal of Systems & Software 193 (2022) 111460

Acar, A., Aksu, H., Uluagac, A.S., Conti, M., 2018. A survey on homomorphic Google, 2021. ANRs. developer.android.com/topic/performance/vitals/anr.
encryption schemes: Theory and implementation. ACM Comput. Surv. 51 (4), Google, 2022. Android developers : Intent API. developer.android.com/reference/
79. android/content/Intent.
Alhanahnah, M., Yan, Q., Bagheri, H., Zhou, H., Tsutano, Y., Srisa-an, W., Luo, X., Gruver, B., 2015. Smali/baksmali tool. github.com/JesusFreke/smali.
2019. Detecting vulnerable android inter-app communication in dynamically 2019. Intent Intercept - dev tool to view inter-app communication. f-droid.org/
loaded code. In: IEEE INFOCOM 2019. IEEE, pp. 550–558. en/packages/de.k3b.android.intentintercept/.
Anderson, P., Zhang, L., 2010. Fast and secure laptop backups with encrypted Jing, Y., Ahn, G.-J., Doupé, A., Yi, J.H., 2016. Checking intent-based communication
de-duplication.. In: LISA, Vol. 10. p. 24th. in android with intent space analysis. In: Proceedings of the 11th ACM
Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., Le Traon, Y., on Asia Conference on Computer and Communications Security. ACM, pp.
Octeau, D., McDaniel, P., 2014. Flowdroid: Precise context, flow, field, object- 735–746.
sensitive and lifecycle-aware taint analysis for android apps. ACM SIGPLAN Kang, H., Jeong, K., Lee, K., Park, S., Kim, Y., 2016. Android RMI: a user-
Notices. level remote method invocation mechanism between android devices. J.
Bennett, K., Grothoff, C., Horozov, T., Patrascu, I., 2002. Efficient sharing of Supercomput. 72 (7), 2471–2487.
encrypted data. In: ACISP. Springer. Krohn, M., Yip, A., Brodsky, M., Cliffer, N., Kaashoek, M.F., Kohler, E., Morris, R.,
Blasco, J., Chen, T.M., Muttik, I., Roggenbach, M., 2016. Wild android collusions.
2007. Information flow control for standard OS abstractions. In: ACM SIGOPS
In: The VB Conference.
Operating Systems Review, Vol. 41. ACM, pp. 321–334.
Bosu, A., Liu, F., Yao, D.D., Wang, G., 2017. Collusive data leak and more: Large-
Le, M., Clyde, S.W., 2018. INGRIM: A middleware to enable remote method
scale threat analysis of inter-app communications. In: Asia Conference on
invocation routing in multiple group device-to-device networks. In: 2018
Computer and Communications Security. ACM, pp. 71–85.
Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.-R., 2011. Xmandroid: IEEE International Conference on Internet of Things (iThings) and IEEE Green
A new Android Evolution to Mitigate Privilege Escalation Attacks. Technical Computing and Communications (GreenCom) and IEEE Cyber, Physical and
Report TR-2011-04, Technische Universität Darmstadt. Social Computing (CPSCom) and IEEE Smart Data (SmartData). IEEE, pp.
Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.-R., Shastry, B., 2012. 847–857.
Towards taming privilege-escalation attacks on android. In: NDSS. Lee, J., Lee, H., Seo, B., Lee, Y.C., Han, H., Kang, S., 2018. SAMD: Fine-grained
Canfora, G., Melillo, F., 2012. Sip2Share–a middleware for mobile peer-to-peer application sharing for mobile collaboration. In: 2018 IEEE International
computing. ICSOFT 12, 445–450. Conference on Pervasive Computing and Communications (PerCom). IEEE,
CAPEC, 2021. CAPEC-499: Android Intent Intercept. capec.mitre.org/data/ pp. 1–10.
definitions/499.html. Lee, Y.K., Yoodee, P., Shahbazian, A., Nam, D., Medvidovic, N., 2017. SEALANT:
2022. CAPEC. http://capec.mitre.org/. a detection and visualization tool for inter-app security vulnerabilities in
Carpov, S., Nguyen, T.H., Sirdey, R., Constantino, G., Martinelli, F., 2016. Practical android. In: Proceedings of the 32nd IEEE/ACM International Conference on
privacy-preserving medical diagnosis using homomorphic encryption. In: Automated Software Engineering. IEEE Press, pp. 883–888.
Cloud Computing. IEEE, pp. 593–599. Li, L., Bartel, A., Bissyandé, T.F., Klein, J., Le Traon, Y., Arzt, S., Rasthofer, S.,
Carter, H., Amrutkar, C., Dacosta, I., Traynor, P., 2014. For your phone only: Bodden, E., Octeau, D., McDaniel, P., 2015. Iccta: Detecting inter-component
custom protocols for efficient secure function evaluation on mobile devices. privacy leaks in android apps. In: Proceedings of the 37th International
Secur. Commun. Netw. 7 (7), 1165–1176. Conference on Software Engineering-Volume 1. IEEE Press, pp. 280–291.
Chin, E., Felt, A.P., Greenwood, K., Wagner, D., 2011. Analyzing inter-application Li, L., Bissyandé, T.F., Klein, J., Le Traon, Y., 2016a. Parameter values of android
communication in android. In: Proceedings of the 9th International
APIs: A preliminary study on 100,000 apps. In: 2016 IEEE 23rd International
Conference on Mobile Systems, Applications, and Services. ACM, pp. 239–252.
Conference on Software Analysis, Evolution, and Reengineering, Vol. 1. pp.
Cruz, B.D., Tilevich, E., 2018. Intent to share: enhancing android inter-component
584–588.
communication for distributed devices. In: 2018 IEEE/ACM 5th International
Li, L., Bissyandé, T.F., Octeau, D., Klein, J., 2016b. Droidra: Taming reflection
Conference on Mobile Software Engineering and Systems (MOBILESoft). IEEE,
pp. 94–104. to support whole-program analysis of android apps. In: Proceedings of the
2018. CVE-2018-9489. cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9489. 25th International Symposium on Software Testing and Analysis. ACM, pp.
2018. CVE-2018-15752. cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018- 318–329.
15752. Liu, Y., Cruz, B.D., Tilevich, E., 2021. HTPD: Secure and flexible message-based
2022. Common Vulnerabilities and Exposures (CVE). https://cve.mitre.org/. communication for mobile apps. In: Proceedings of the 17th EAI Inter-
Damgård, I., Groth, J., Salomonsen, G., 2003. The theory and implementation national Conference on Security and Privacy in Communication Networks
of an electronic voting system. In: Secure Electronic Voting. Springer, pp. (SecureComm 2021).
77–99. Lu, L., Li, Z., Wu, Z., Lee, W., Jiang, G., 2012. Chex: statically vetting android apps
Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A., Wallach, D.S., 2011. Quire: for component hijacking vulnerabilities. In: Proceedings of the 2012 ACM
Lightweight provenance for smart phone operating systems. In: USENIX Conference on Computer and Communications Security. ACM, pp. 229–240.
Security Symposium, Vol. 31. p. 3. Mark Gordon, L.Z., Tiwana, B., 2019. A power monitor. ziyang.eecs.umich.edu/
Douceur, J.R., Adya, A., Bolosky, W.J., Simon, P., Theimer, M., 2002. Reclaiming projects/powertutor/.
space from duplicate files in a serverless distributed file system. In: Proceed- Miller, F.P., Vandome, A.F., McBrewster, J., 2009. Advanced encryption standard.
ings 22nd International Conference on Distributed Computing Systems. IEEE, Mimoso, M., 2016. Mobile app collusion can bypass native android
pp. 617–624. security. threatpost.com/mobile-app-collusion-can-bypass-native-android-
Drosatos, G., Efraimidis, P.S., Athanasiadis, I.N., D’Hondt, E., Stevens, M., 2012. A security/121124/.
privacy-preserving cloud computing system for creating participatory noise 2019. My location. github.com/gjedeer/mylocation.
maps. In: Computer Software and Applications Conference (COMPSAC), IEEE Octeau, D., McDaniel, P., Jha, S., Bartel, A., Bodden, E., Klein, J., Le Traon, Y., 2013.
36th Annual. IEEE, pp. 581–586. Effective inter-component communication mapping in android: An essential
Duan, Y., 2014. Distributed key generation for encrypted deduplication: Achiev- step towards holistic security analysis. In: USENIX Security.
ing the strongest privacy. In: Proceedings of the 6th Edition of the ACM 2019. QKSMS. github.com/moezbhatti/qksms.
Workshop on Cloud Computing Security. ACM, pp. 57–68. Rescorla, E., 1999. Diffie-Hellman Key Agreement Method. Tech. Rep..
Dubois, D.J., Bando, Y., Watanabe, K., Holtzman, H., 2013. ShAir: Extensible Standard, Secure Hash, 2002. FIPS PUB 180-2. National Institute of Standards
middleware for mobile peer-to-peer resource sharing. In: Proceedings of the and Technology.
2013 9th Joint Meeting on Foundations of Software Engineering. ACM, pp. U.S. Geological Survey, 2019. How much distance does a degree, minute, and
687–690. second cover on your maps?
Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-G., Cox, L.P., Jung, J., Wang, H., Si, J., Li, H., Guo, Y., 2019. RmvDroid: towards a reliable android mal-
McDaniel, P., Sheth, A.N., 2014. Taintdroid: an information-flow tracking
ware dataset with app metadata. In: Proceedings of the 16th International
system for realtime privacy monitoring on smartphones. ACM Trans. Comput.
Conference on Mining Software Repositories. IEEE Press, pp. 404–408.
Syst. (TOCS) 32 (2), 5.
Wilcox-O’Hearn, Z., Warner, B., 2008. Tahoe: the least-authority filesystem. In:
2019. F-droid. f-droid.org/.
4th ACM International Workshop on Storage Security and Survivability.
Fang, Z., Han, W., Li, Y., 2014. Permission based android security: Issues and
Xposed, 2019. Xposed framework API. https://api.xposed.info/reference/packages.
countermeasures. Comput. Secur. 43, 205–218.
html.
Felt, A.P., Wang, H.J., Moshchuk, A., Hanna, S., Chin, E., 2011. Permission
Xu, K., Li, Y., Deng, R.H., 2016. Iccdetector: Icc-based malware detection on
re-delegation: Attacks and defenses.. In: USENIX Security Symposium.
Google, 2018. Google play. play.google.com/store/apps?hl=en. android. IEEE Trans. Inf. Forensics Secur. 11 (6), 1252–1264.
Zhou, Y., Jiang, X., 2012. Dissecting android malware: Characterization and
Google, 2019a. Send and sync data on wear. https://developer.android.com/
training/wearables/data-layer. evolution. In: 2012 IEEE Symposium on Security and Privacy. IEEE, pp.
Google, 2019b. Distribution dashboard. developer.android.com/about/dashboards. 95–109.

14