Spoof-of-Work

Evaluating Device Authorisation in Mobile Mining Processes

Dominik Ziegler

, Bernd Pr

unster

, Marsalek Alexander

and Christian Kollmann

Know-Center GmbH, Graz, Austria

Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology, Graz, Austria

A-Sit Plus GmbH, Vienna, Austria

Keywords:

Device Authorisation, Android, Cryptocurrency, Mining, REST, App Integrity, Smartphone, Electroneum,

Remote Attestation, Key Attestation.

Abstract:

Mobile mining of cryptocurrencies, without relying on CPU-heavy computations, is a novel attempt to foster

adoption of a token. However, this approach leaves room for attacks. In this paper, we perform a thorough analy-

sis of Electroneum, one of the ﬁrst cryptocurrencies to introduce a mobile mining process. We show that mobile

mining, without relying on a consensus algorithm (e.g. Proof-Of-Work), is not feasible on current generation

Android smartphones. We further demonstrate that the security mechanisms employed by Electroneum can be

circumvented and that mobile mining can be exploited successfully. Based on this analysis, we discuss several

practical countermeasures, which can be applied on smartphones to enforce device authorisation and prevent

abuse.

1 INTRODUCTION

The popularity of cryptocurrencies, such as Bit-

coin (Nakamoto, 2008), has increased vastly in the past

decade. Despite this fact, mass adoption cannot be ob-

served, due to poor user experience (Devries, 2016).

In addition, cryptocurrencies typically require large

amounts of computing power, to validate transactions

and to reach a common consensus. This is attributed to

the fact that cryptocurrencies usually store their tran-

sactions in a distributed ledger (usually referred to as

blockchain). To participate in this consensus mecha-

nism, users need to solve a cryptographic puzzle. This

task is commonly called mining. As a reward, users

receive new tokens.

In theory, this process could also be replicated

on smartphones. However, mining poses a signiﬁcant

strain on hardware, especially in a mobile environment

with limited battery capacity. Nevertheless, creators

of cryptocurrencies seek to foster adoption, and try to

make currencies available on mobile devices.

One approach for a mobile mining process is a so-

called Airdrop of tokens, where a large number of to-

kens is generated by the creator of the cryptocurrency

in advance. Tokens are then awarded to users, e.g., for

using a dedicated smartphone application. Hence, pho-

nes do not mine in the conventional sense. Instead,

mobile mining apps periodically benchmark the the-

oretical system performance and report performance

ﬁgures to a back-end service. Based on this, the sy-

stem awards the user with tokens. This approach sig-

niﬁcantly reduces the load on the device. However,

one major problem of mobile mining is that the back-

end can hardly validate whether it is interfacing with a

benign application executed on a genuine device.

The scientiﬁc contribution of this paper is twofold.

First, we analyse the mobile mining process of Electro-

neum (Electroneum Ltd, 2017), one of the ﬁrst crypto-

currencies to introduce mobile mining. We show that

if the reward system is not solely based on Proof-of-

Work (PoW) or similar consensus algorithms, and no

additional measures are in place to ensure execution

on a real device, it is impossible to prevent tampering

with the mobile mining process. Secondly, we discuss

currently practical countermeasures and show how to

authorise mobile devices. We further describe how to

mitigate protocol exploitation and prevent device and

app impersonation. To do so, we ﬁrst introduce the

topic of cryptocurrencies and Android application se-

curity. Subsequently, we describe the Electroneum ar-

chitecture and discuss possible attack vectors. Finally,

we propose a solution based on existing as well as no-

vel approaches for device authorisation in the context

of Android applications.

380

Ziegler, D., Prünster, B., Alexander, M. and Kollmann, C.

Spoof-of-Work - Evaluating Device Authorisation in Mobile Mining Processes.

DOI: 10.5220/0006859003800387

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 380-387

ISBN: 978-989-758-319-3

2 BACKGROUND

This work focuses on analysing the feasibility of

resource-saving cryptocurrency mining on smartpho-

nes. We, therefore, discuss cryptocurrencies in brief.

We also provide background information regarding the

Android Operating System (OS) and mobile applica-

tion development.

2.1 Cryptocurrencies

The ﬁrst blockchain-based cryptocurrency, Bitcoin,

was conceived in 2008. It uses a fully decentralised

consensus algorithm and the blockchain as a distri-

buted ledger, which records all transactions in blocks.

Each block is linked to is its predecessor. To create a

block, so-called miners, try to solve a cryptographic

puzzle. Whoever manages to solve this puzzle, and

thus manages to create a new block, receives a so-

called block reward and the fees of all transactions

included in the block. This consensus mechanism is

called Proof-of-Work (PoW). The difﬁculty of the puz-

zle is regularly adapted with the goal of an average

block creation time of ten minutes. It is this competi-

tion among the miners which secures the blockchain.

An attacker who wants to modify or delete a block in

the blockchain must thus solve a puzzle at least as hard

as the block to replace. If this block is not on top of the

chain, the attacker must also recalculate all subsequent

blocks. Thus, an attacker needs signiﬁcant computing

resources to outperform the remaining, honest miners.

However, the price of this security mechanism is

high power consumption, as all miners race against

each other and only one miner per block will ﬁnally

win and earn the reward. In recent years, several deve-

lopers thus tried to improve various cryptocurrencies

in different aspects, like scalability or privacy.

One of these cryptocurrencies is Electroneum. It

focuses on user privacy and uses the CryptoNight (Sei-

gen et al., 2013) PoW algorithm. Still, it is not opti-

mised for mining on mobile devices, as the high load

on the CPU would lead to an increased ageing rate of

speciﬁc hardware components (Leng et al., 2015). The-

refore, Electroneums’ mobile mining process does not

rely on the PoW algorithm to secure the blockchain.

Instead, Electroneum distributes pre-mined coins for

the mobile mining process (Electroneum Ltd, 2017).

2.2 Android Application Development

Android provides an ecosystem for third-party develo-

pers to create and publish applications. Applications

resemble, in principle, a zip archive ﬁle. This structure

and the fact that Android applications are typically ba-

sed on Java or Kotlin enables easy decompilation and

analysis (Enck et al., 2011). Mobile applications for

Android can also be developed using Web technology.

As such hybrid applications typically are not converted

to native instructions, code can easily be extracted.

2.3 Android Security Model

Android incorporates extensive security mecha-

nisms (Enck et al., 2009). Due to the scope of this

work, we do not provide a thorough analysis of the

architecture. Instead, we discuss speciﬁc in-place secu-

rity features necessary for the analysis of Electroneum

and refer to the ofﬁcial documentation

Android, executes each application within a dedi-

cated virtual memory in an Application Sandbox. This

process ensures that applications do not access or mo-

dify (private) ﬁles of other applications.

With Trusty

, Android also offers a Trusted Exe-

cution Environment (TEE). TEEs offer a secure and

tamper resistant runtime environment for applications,

separated from the actual OS. As of this writing, Trusty

does not support third-party applications. Instead, all

applications are developed and packaged into an image

by a single manufacturer. The digitally signed image

is then veriﬁed by the bootloader on startup.

Android provides pre-installed root Certiﬁcate Aut-

horitys (CAs) for network security. Device manufac-

turers are not allowed to modify the system provided

CAs, which are located on the read-only partition. By

default, applications only trust system provided CAs.

3 RELATED WORK

To the best of our knowledge, no extensive analysis

of the security of mobile mining approaches exists.

However, a signiﬁcant amount of research has been

conducted in the ﬁeld of client-side detection of ap-

plication vulnerabilities or mobile malware. Thus, we

ﬁrst discuss related work targeting Android security

and provide an overview of selected device veriﬁca-

tion and authorisation mechanisms.

3.1 Android Security

Many tools have been developed to detect malware

on Android (Enck et al., 2009; Vidas and Christin,

2014; Karbab et al., 2016). As a result, adversaries

shift their focus to so-called app repacking attacks. In

https://source.android.com/security/

https://source.android.com/security/trusty/

Spoof-of-Work - Evaluating Device Authorisation in Mobile Mining Processes

381

these attacks, an attacker modiﬁes well-known appli-

cations, to, for example, acquire account information.

Typically, users can hardly detect whether a binary has

been tampered with. Hence, several solutions target

this problem by providing detection mechanisms or

frameworks to automatically identify rogue Android

applications (Desnos and Gueguen, 2011; Jung et al.,

2013; Zhou et al., 2013; Huang et al., 2013; Ren et al.,

2014). However, these approaches do not account for

an adversary who is actively modifying an application

to manipulate genuine functionality of the app.

Further, several studies have examined whether An-

droid applications are vulnerable to speciﬁc TLS at-

tacks or exhibit substantial ﬂaws in their TLS imple-

mentations (Fahl et al., 2012; Georgiev et al., 2012;

Sounthiraraj et al., 2014). Results show that a signi-

ﬁcant amount of applications are either vulnerable to

Man-In-The-Middle (MITM) attacks or do not provide

sufﬁcient transport layer security. These studies focus

on monitoring network trafﬁc in a passive attack sce-

nario. In contrast to that, our approach covers active,

deliberately altered network trafﬁc.

3.2 Device Integrity & Authorisation

Multiple approaches, which allow service providers to

verify whether an Android device is in a trusted state,

have been proposed in the last decade (Nauman et al.,

2010; Bente et al., 2011; Jeong et al., 2014). These

attestation mechanisms, typically also allow detecting

if an application has been installed and whether it has

been altered or not. Thus, service providers can not

only rely on the fact that the device is in an uncompro-

mised state but also that an adversary has not tampe-

red with installed applications. However, while these

approaches provide a solution, most of them are not

integrated into the Android system. Additionally, some

approaches are either purely academic, and their proof

of concept is based on Trusted Computing (TC) and

Trusted Platform Modules (TPMs), neither of which

are currently available at large scale on mobile plat-

forms, or they are implemented in software, which, in

theory, allows an adversary with root access to tamper

with this mechanism. Hence, current service providers

cannot directly rely on these techniques. Similarly, re-

lated approaches targeting Android application inte-

grity, such as static or dynamic code integrity checks

at runtime are currently not integrated into the Android

operating system.

4 ANALYSIS: ELECTRONEUM

We provide an overview of the Electroneum mobile

miner and discuss its system security mechanisms and

properties. We further show how the mobile mining

process can be tampered with.

4.1 System Architecture

The Electroneum mobile miner is a mobile application

relying on the Apache Cordova

framework. As such

it is implemented using mainly JavaScript and HTML.

To analyse as well as attack the application we could

thus directly modify JavaScript ﬁles. In the following,

we describe core elements of the mobile mining pro-

cess we learnt from this analysis.

Authentication & Authorisation: Electroneum enforces

a Two-Factor Authentication (2FA) mechanism con-

sisting of a combination of username and password

as well as a user-deﬁned PIN. Furthermore, a valid

phone number is necessary. To authorise devices, the

server ﬁrst authenticates the user. Subsequently, it eva-

luates the transmitted User-Agent header to identify

the accessing device. If the device is not yet known, a

veriﬁcation email is sent. A reCAPTCHA

challenge

is presented, to prevent automatic device authorisation.

A user can only continue if they can successfully solve

the reCAPTCHA. Once a user successfully authorises

a device, it can be used for mobile mining.

Benchmarking: The mobile miner application does not

rely on PoW. Instead, a custom benchmarking algo-

rithm, depicted in Algorithm 1, is used. This mecha-

nism evaluates the CPU performance without relying

on expensive hash operations. Hence, battery drain of

smartphones is reduced. In the ﬁrst step of this process,

the hash duration, i.e. the maximum time the bench-

marking process is allowed to run, is retrieved from the

server. Next, the algorithm retrieves the current system

time. These two parameters serve as the termination

condition for a while loop. In each iteration, several

slow operations, i.e. regular expression matching, are

performed. At the end of each loop, the program re-

trieves the current system time again and increases a

counter (amt). As soon as the program reaches its ter-

mination condition, it sends the number of loops (amt)

to the server. The server will then determine the hash

rate awarded to the device.

Mining: One of the goals of the mobile miner appli-

cation is to reduce battery drain. Hence, the applica-

tion does not perform any network validation services.

Instead, the application periodically performs a system

benchmark. Subsequently, the mobile miner transmits

https://cordova.apache.org

https://www.google.com/recaptcha

SECRYPT 2018 - International Conference on Security and Cryptography

382

Algorithm 1: Benchmarking algorithm used in Electroneum

Mobile Miner.

1: hash duration ← getDurationFromServer()

2: start ← currentMillis()

3: end ← 0

4: while end < (start +(hash duration∗1000))) do

5: regexTest(

HelloWorld!

)

6: indexO f (

HelloWorld!

) > −1

7: regexMatch(

HelloWorld

)

8: end ← currentMillis()

9: amt ← amt + 1

10: end while

the benchmark results to the server. Based on the cal-

culated theoretical hash rate the server awards the user

with tokens. As long as a device notiﬁes the service

periodically, the application is considered active, and

the service continuously awards the user with tokens.

4.2 Security Mechanisms

Electroneum employs several mechanisms to prevent

fraud. We discuss prominent features we discovered.

Account Veriﬁcation: To create a mobile mining

account, ﬁrst, a valid email address is required. Once

the user conﬁrms control over its address, a valid phone

number is required. The server veriﬁes phone numbers

via an SMS-veriﬁcation challenge. In each step, the

user further needs to solve a reCAPTCHA.

Maximum Hash Rate: Our analysis suggests that

the maximum hash rate for one device is limited to

50 H/s

. A device claiming better performance is auto-

matically banned. Once the device claims lower com-

puting power again, mobile mining is resumed.

Maximum Number of Devices: Electroneum does

not restrict logging into the same account with multi-

ple devices. However, our tests implicated that using

multiple devices linked to a single account does not

increase the number of tokens received.

Device Authorisation: In the process of analysing

the Electroneum API, we observed that devices seem to

be authorised based on the supplied User-Agent header

as well as the source IP address. Once the IP address

changed, the device needed to be authorised again.

Automation Protection: Electroneum claims to pro-

vide systems to protect against large automation sys-

tems. Our tests have indicated that once more than ﬁve

different accounts are used with a single IP address,

users need to reauthorise their accounts periodically.

This process too requires users to solve a reCAPTCHA

challenge.

This number does not represent the actual hashing per-

formance. Instead, it only represents a performance index.

4.3 Attacking the Mobile Mining

Process

Based on the analysis of the system architecture, con-

ducted in Section 4.1, we describe possible approaches

to bypass the security mechanisms. The procedures

described in this section enables the emulation of an

arbitrary number of devices. As a consequence, an ad-

versary can, in theory, illegitimately obtain a virtually

unlimited number of tokens.

4.3.1 Attack Classes

We present three different methods to attack the mobile

mining process. These procedures include modiﬁca-

tion of network trafﬁc, modiﬁcation of the application

and application impersonation.

[A1] - Modiﬁcation of Network Trafﬁc: An adver-

sary may alter network trafﬁc transmitted to the Elec-

troneum servers. As a result, they can submit arbi-

trary values, including benchmarking results. Modi-

ﬁcation of network trafﬁc, in most cases, does not re-

quire changing the application code. However, recent

studies have shown that Android applications are re-

lying on TLS connections on a large scale (Fahl et al.,

2012). When implemented correctly, TLS can prevent

tampering with network trafﬁc—on uncompromised

devices at least. Considering that applications, since

Android 7.0 (Android Developers Blog, 2016), do not

automatically trust user imported CAs certiﬁcates, this

attack requires additional modiﬁcations of the mobile

operating system.

In general, several tools exist to modify network traf-

ﬁc on Android devices. For example, trafﬁc can either

be altered on the device directly via Virtual Private

Network (VPN) applications or via proxies running on

desktop machines such as Burp Suite

[A2] - App Repackaging: The Electronum mobile

miner is using the Cordova framework. Such apps do

not need to b compiled to machine code. As a result,

Cordova apps are easy targets for repackaging attacks,

as shown by (Kudo et al., 2017). When attacking the

application, an adversary can directly modify the ben-

chmarking algorithm described in Algorithm 1. Hence,

it is possible to skip benchmarking altogether. By re-

packaging the application, an adversary can thus create

modiﬁed binaries and distribute them on multiple de-

vices. As a result, high hash rates can be spoofed even

on outdated hardware.

[A3] - Application Impersonation: A signiﬁcant

problem of REpresentational State Transfer (REST)

APIs is the veriﬁcation of clients. In fact, by exposing

a REST API, a server can hardly distinguish between

https://portswigger.net/burp

Spoof-of-Work - Evaluating Device Authorisation in Mobile Mining Processes

383

trusted and rogue clients. An adversary, who can re-

construct the network protocol, could thus impersonate

the Electroneum mobile miner. Indeed, the imperso-

nation of the application also entails that an adversary

can run multiple instances of an application on a sin-

gle machine. This fact, however, contradicts the goal

of mobile mining. An attacker who can operate a vir-

tually unlimited amount of app instances would also

gain an unjustiﬁed advantage over regular users.

4.3.2 Results

Our tests indicated that the security mechanisms can be

successfully circumvented and an arbitrary amount of

mobile miners could be emulated on a single machine.

[A1]: To test whether the Electroneum mobile mi-

ning process is vulnerable to modiﬁcations of network

trafﬁc, we tried to directly tamper with the outgoing

network trafﬁc of the application. The Electroneum

application does not enforce certiﬁcate pinning (c.f.

Section 5.3). Thus, we used Magisk

, to import a proxy

CA, into the system’s trust store. As a result, we were

able to tamper with the benchmarking results the appli-

cation sent to the server. Relying on this method, we

could achieve the maximum possible hash rate, even

on outdated hardware.

[A2]: We performed this attack by repackaging the

application and exchanging the benchmarking algo-

rithm. Our test device, a Samsung Galaxy S5 achieved

around 6 H/s without any modiﬁcations. After modi-

fying the source code, the modiﬁed binary was able to

claim a maximum hash rate of 50 H/s.

[A3]: We reconstructed the network protocol, used

by the mobile miner. We then developed an application

which emulates the behaviour of the Electroneum

mobile miner. We used Tor

and ﬁxed exit nodes to

prevent blocking of IP addresses and keep virtual

devices authorised. We set the benchmarking results

to match values between 42 H/s and 47 H/s to reduce

possible conspicuousness. With this setup, we success-

fully evaded the in-place automation protection and

emulated more than ﬁve devices on a single machine.

To summarise, all employed techniques allowed

us to either tamper with the mobile mining process

or completely emulate a device. This setup allows us

to mine approximately

9.36

ETN/day per account. A

PoW miner with a comparable hash rate, could mine

around

1.787

ETN/day (numbers based on values from

Magisk allows gaining root access on an Android ope-

rating system without modifying the system. It has been

successfully evading virtually all relevant Frameworks ai-

med at detecting system modiﬁcations.

https://www.torproject.org

Figure 1: Successful payout with impersonated miner.

March 2018). Figure 1 shows the successful payout of

tokens using a single emulated miner. In general, an

adversary can proﬁt from these loopholes by creating

a large number of accounts and running multiple in-

stances on a single machine. This scheme can even be

extended to a larger scale as multiple services exist to

solve reCAPTCHA automatically. Phone number veri-

ﬁcation can also be circumvented by relying on virtual

phone numbers to receive SMS, with prices ranging

from 0.2 USD/month to 1.5 USD/month.

These results lead to one conclusion: Tamper proof

mobile mining, without consensus algorithms or pro-

per device authorisation and veriﬁcation is infeasible.

5 DEVICE AUTHORISATION

We have shown that we can easily tamper with the

Electroneum mobile mining process. We argue that

this behaviour is due to two major design ﬂaws. First,

the mobile mining process does not ensure that the

application is running on a smartphone. Second, the

benchmarking algorithm is designed to replace com-

plex computations. However, the server cannot vali-

date reported numbers, which, by deﬁnition, renders

the process practically ineffective. We propose several

currently feasible procedures, to ensure proper device

authorisation, with high certainty. Electroneum is used

as the prime example, but the methods described are

suitable for any case of device authorisation.

5.1 Remote Attestation (SafetyNet)

Remote attestation is one of the most important fea-

tures of TC (Haldar et al., 2004). It allows a server to

establish a trust relationship with a client, running in

an unmanaged environment. Although many different

approaches for remote attestation exist, in this work,

we focus on the most prominent one for Android, na-

mely SafetyNet (Android Open Source Project, 2018a).

SECRYPT 2018 - International Conference on Security and Cryptography

384

SafetyNet allows applications on Android devices to

request an attestation about the device they are running

on. Locally, SafetyNet loads (signed) code from Goo-

gle servers

. The process runs in the background and

continuously gathers data from various sources on the

device. All information gathered that way is sent to the

back-end service operated by Google and analysed in

private. The result of an attestation request reports on

e.g. a locked bootloader, a custom system image, the

certiﬁcation of the manufacturer and essential integrity

features like running on a non-emulated and not-rooted

device. Additionally, the attestation result includes the

package name of the requesting app, a digest of the

application package as well as a digest of the certiﬁ-

cate used to sign the package. However, several tools,

including Magisk, successfully bypass this basic inte-

grity check and provide a rooting method that is not

detected.

5.2 Device Attestation (Key Attestation)

Device attestation mechanisms enable a device to

prove its integrity. Typically, TEEs are used for this

process. However, as discussed in Section 2.3, Android

does not provide a TEE for third-party applications.

We present an approach, how device attestation can be

achieved on current-generation smartphones.

Since Android 7.0, applications can request attes-

tations about key pairs generated in the Android KeyS-

tore (Android Open Source Project, 2018b). The attes-

tation contains information about the key pair itself,

e.g. the algorithm, key size, and whether user authenti-

cation is required to use the private key. Optionally, the

attestation also includes information about the appli-

cation itself: the application identiﬁer and a digest of

the signature of the package. Additionally, information

about the system may be included: The version of the

operating system, the patch level, and the state of the

veriﬁed boot chain. Most importantly, security levels

for both the attestation and the KeyStore implementa-

tion are provided. The value indicates the type of the

respective module: It may either run as a system-level

software or inside a TEE. The data structure represen-

ting the attestation can be authenticated by verifying

the chain of certiﬁcates signing the data. If the attesta-

tion was generated in secure hardware, the root certiﬁ-

cate contains a known public key from Google.

Hence, to establish trust with a device, a server

sends an attestation challenge to the application. Sub-

sequently, the application creates a new key in the An-

droid KeyStore and attaches this challenge. Next, the

application sends the attestation, which was created

https://koz.io/inside-safetynet/

during this process, to the server. Finally, the server ve-

riﬁes the transmitted attestation. If successful, access

can be granted, and the device is authorised. However,

only very few devices run Android 7.0 and support

hardware-level key attestation, and nearly all informa-

tion in the attestation structure is marked as optional.

Therefore, on most devices, the attestation is genera-

ted by the Android system in software and can thus

be tampered with by an attacker. Further, attestation

via the Android KeyStore cannot guarantee the inte-

grity of an Android application and may not include

all desirable information. However, if the KeyStore is

hardware-backed and the device is not rooted, this pro-

cess can guarantee that an application is running on a

genuine device.

5.3 Certiﬁcate Pinning

We have shown that a signiﬁcant amount of applicati-

ons already relies on TLS connections to secure com-

munications between client and server. However, only

a small amount of applications also implements certiﬁ-

cate pinning. Certiﬁcate pinning, also known as Public

Key Pinning, allows an application to “pin” a speciﬁc

X.509 certiﬁcate. In general, this mechanism enables

the application to verify a particular certiﬁcate of a

server upon connection establishment. Depending on

the desired security level, applications can choose to

either trust root, intermediate or leaf certiﬁcates. Ho-

wever, leaf certiﬁcates typically have a shorter expiry

time. Thus, applications employing certiﬁcate pinning

need to be redistributed or updated on a regular basis.

Certiﬁcate pinning also mitigates MITM attacks, as

even system-wide certiﬁcates trusted by the OS are

rejected. However, it cannot protect against repacka-

ging attacks or network trafﬁc modiﬁcation on rooted

devices.

5.4 Comparison

In the following, we will discuss how the presented

mechanisms can ensure device authorisation to a high

degree. However, it should be noted that it is currently

not possible to guarantee that an application running on

an arbitrary, unmanaged Android device has not been

modiﬁed. As a result, all attacks discussed in Section 4

are, in theory, still feasible.

Table 1 provides an overview of the aforementioned

countermeasures. It also indicates whether a technique

can mitigate a speciﬁc attack. A ﬁlled circle implies

that the countermeasure can prevent a certain attack

on unrooted devices. A partially ﬁlled circle indicates

that the effort for a successful attack can be increased

with this mechanism. An empty circle implies that this

Spoof-of-Work - Evaluating Device Authorisation in Mobile Mining Processes

385

Table 1: Overview of various attacks and possible countermeasures.

Trafﬁc Modiﬁcation App Repackaging App Impersonation Rooting

SafetyNet

Key Attestation

Certiﬁcate Pinning

technique does not help mitigating an attack.

SafetyNet: We argue that SafetyNet can prevent app

repackaging attacks as it can attest the certiﬁcate, the

Android Application Package (APK) was signed with.

This can also prevent app impersonation attacks, as

SafetyNet can attest whether the application runs on a

genuine device. To establish a trust relationship with

and authorise a certain client a SafetyNet attestation

can be requested.

Android KeyStore: In principle, this procedure allows

drawing conclusions about the state of a device. This

includes attestation concerning the state of the boot-

loader (unlocked or not) or installed applications. Ho-

wever, KeyStore attestation does not attest whether a

device has been rooted. Still, we can rely on this in-

formation to restrict access to a service. As a result, a

service provider can exclude devices with, unlocked

bootloaders. Indeed, KeyStore attestation suffers from

two drawbacks. First, it is not available on all devices.

Second, if the KeyStore is not hardware-backed, an

adversary can still tamper with the attestation process.

Certiﬁcate Pinning: Certiﬁcate Pinning is an effective

way to prevent monitoring or modiﬁcation of network

trafﬁc. In combination with remote or device attesta-

tion, an attacker can be prevented from tampering with

environment variables.

Summarising, applications employing all presented

approaches can signiﬁcantly increase the chances for a

service provider to successfully detect the device state.

5.5 Improvements

One of the goals of the Electroneum mobile mining

process is to enforce adaption of their token. Howe-

ver, we have shown in Section 4.3 that the current im-

plementation can successfully be exploited and large-

scale app impersonation is, in theory, possible. We, the-

refore, propose several procedures, which can harden

the mobile mining process and increase the detection

rate of manipulation attempts.

First, we propose to alter the benchmarking al-

gorithm, to include server-side veriﬁcation of bench-

marks. For example, the server can send some random

nonce to the device. Similar to conventional PoW

implementations, the device needs to solve a crypto-

graphic puzzle of a certain difﬁculty. The server then

measures the time the device needs to solve this task.

This way, repackaged applications cannot simply skip

the benchmarking process. As benchmarks are not per-

formed constantly, this approach should also not affect

battery life. However, relying on server-side veriﬁca-

tion of benchmarks can increase the load on the server.

Naturally, this countermeasure does not prevent

app impersonation attacks. An adversary can still per-

form these calculations on a much more powerful de-

vice. Similarly, it is possible to emulate multiple devi-

ces on a single machine due to benchmarking proces-

ses not being performed constantly. Hence, we advise

to employ both SafetyNet as well as Android KeyStore

device attestation mechanism, to enforce execution on

a genuine device.

Admittedly, we cannot prevent app impersonation

on rooted devices. An adversary can still emulate a

genuine device, by forwarding attestation challenges

to a device with a modiﬁed, rooted OS. In this setting,

benchmarking computations are performed on dedi-

cated hardware, whereas valid attestation claims are

generated on a smartphone.

6 CONCLUSIONS

We have conducted an extensive analysis of the Elec-

troneum mobile mining process. The analysis shows,

that even though mechanisms to protect against auto-

mated systems exist, the in-place security mechanisms

seem to be vulnerable to app repackaging attacks as

well as app emulation. In our tests, we successfully

emulated multiple mobile miners on a single machine

leading to an accumulated hash rate equal to several

PoW miners. We further showed that for these attacks

no root access or modiﬁcations of the operating sys-

tems were necessary. Based on these vulnerabilities

we concluded that a mobile mining process without

veriﬁcation of benchmark results could lead to exploi-

tation of the reward system. We further have presented

several approaches which can be used to increase the

trust relationship between server and client applicati-

ons. We adhered to responsible disclosure guidelines

and informed the developers about our ﬁndings.

SECRYPT 2018 - International Conference on Security and Cryptography

386

REFERENCES

Android Developers Blog (2016). Android Developers Blog:

Changes to Trusted Certiﬁcate Authorities in Android

Nougat.

Android Open Source Project (2018a). Protecting against

Security Threats with SafetyNet.

Android Open Source Project (2018b). Verifying Hardware-

backed Key Pairs with Key Attestation.

Bente, I., Dreo, G., Hellmann, B., Heuser, S., Vieweg, J.,

von Helden, J., and Westhuis, J. (2011). Towards

Permission-Based Attestation for the Android Platform.

In Lecture Notes in Computer Science, volume 6740

LNCS, pages 108–115.

Desnos, A. and Gueguen, G. (2011). Android: From Rever-

sing to Decompilation. Proc. of Black Hat Abu Dhabi,

pages 1–24.

Devries, P. D. (2016). An Analysis of Cryptocurrency, Bit-

coin, and the Future. International Journal of Business

Management and Commerce, 1(2):1–9.

Electroneum Ltd (2017). Electroneum overview & white

paper.

Enck, W., Octeau, D., McDaniel, P., and Swarat Chaudhuri

(2011). A Study of Android Application Security Wil-

liam. In Proceedings of the 20th USENIX Security

Symposium, pages 315–330.

Enck, W., Ongtang, M., and McDaniel, P. (2009). On Light-

weight Mobile Phone Application Certiﬁcation. Pro-

ceedings of the 16th ACM conference on Computer and

communications security - CCS ’09, page 235.

Fahl, S., Harbach, M., Muders, T., Smith, M., Baumg

artner,

L., and Freisleben, B. (2012). Why Eve and Mal-

lory Love Android: An Analysis of Android SSL

(In)Security. Proceedings of the 2012 ACM conference

on Computer and communications security - CCS ’12,

page 50.

Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D.,

and Shmatikov, V. (2012). The Most Dangerous

Code in theWorld: Validating SSL Certiﬁcates in Non-

Browser Software. In Proceedings of the 2012 ACM

conference on Computer and communications security

- CCS ’12, page 38, New York, New York, USA. ACM

Press.

Haldar, V., Chandra, D., and Franz, M. (2004). Semantic

remote attestation: a virtual machine directed approach

to trusted computing. In USENIX Virtual Machine

Research and Technology Symposium.

Huang, H., Zhu, S., Liu, P., and Wu, D. (2013). A Framework

for Evaluating Mobile App Repackaging Detection Al-

gorithms. In Huth, M., Asokan, N.,

Capkun, S., Fle-

chais, I., and Coles-Kemp, L., editors, Trust and Trust-

worthy Computing, pages 169–186, Berlin, Heidelberg.

Springer Berlin Heidelberg.

Jeong, J., Seo, D., Lee, C., Kwon, J., Lee, H., and Milburn, J.

(2014). MysteryChecker: Unpredictable attestation to

detect repackaged malicious applications in Android.

In 2014 9th International Conference on Malicious and

Unwanted Software: The Americas (MALWARE), pages

50–57. IEEE.

Jung, J.-H., Kim, J. Y., Lee, H.-C., and Yi, J. H. (2013). Re-

packaging Attack on Android Banking Applications

and Its Countermeasures. Wireless Personal Communi-

cations, 73(4):1421–1437.

Karbab, E. B., Debbabi, M., Derhab, A., and Mouheb, D.

(2016). Cypider: Building Community-Based Cyber-

Defense Infrastructure for Android Malware Detection.

ACSAC ’16 (32nd Annual Computer Security Applica-

tions Conference), pages 348–362.

Kudo, N., Yamauchi, T., and Austin, T. H. (2017). Access

Control for Plugins in Cordova-Based Hybrid Applica-

tions. In 2017 IEEE 31st International Conference on

Advanced Information Networking and Applications

(AINA), number 2, pages 1063–1069. IEEE.

Leng, F., Tan, C. M., and Pecht, M. (2015). Effect of Tem-

perature on the Aging rate of Li Ion Battery Opera-

ting above Room Temperature. Scientiﬁc Reports,

5(1):12967.

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic

Cash System. www.bitcoin.org, page 9.

Nauman, M., Khan, S., Zhang, X., and Seifert, J.-P. (2010).

Beyond Kernel-Level Integrity Measurement: Enabling

Remote Attestation for the Android Platform. In

Acquisti, A., Smith, S. W., and Sadeghi, A.-R., editors,

Trust and Trustworthy Computing, pages 1–15, Berlin,

Heidelberg. Springer Berlin Heidelberg.

Ren, C., Chen, K., and Liu, P. (2014). Droidmarking: Re-

silient SoftwareWatermarking for Impeding Android

Application Repackaging. 29th ACM/IEEE internati-

onal conference on Automated software engineering,

pages 635–646.

Seigen, Jameson, M., Nieminen, T., Neocortex, and Juarez,

A. M. (2013). CryptoNight Hash Function.

Sounthiraraj, D., Sahs, J., Greenwood, G., Lin, Z., and Khan,

L. (2014). SMV-HUNTER: Large Scale, Automated

Detection of SSL/TLS Man-in-the-Middle Vulnerabi-

lities in Android Apps. In Proceedings 2014 Network

and Distributed System Security Symposium, number

February, pages 23–26, Reston, VA. Internet Society.

Vidas, T. and Christin, N. (2014). Evading Android Runtime

Analysis via Sandbox Detection. Proceedings of the

9th ACM symposium on Information, computer and

communications security - ASIA CCS ’14, pages 447–

458.

Zhou, W., Zhang, X., and Jiang, X. (2013). AppInk: Water-

marking Android Apps for Repackaging Deterrence.

In Proceedings of the 8th ACM SIGSAC symposium on

Information, computer and communications security

- ASIA CCS ’13, page 1, New York, New York, USA.

ACM Press.

Spoof-of-Work - Evaluating Device Authorisation in Mobile Mining Processes

387