IEEE Consumer Electronics Magazine - May 2018 - 53

Table 1. Eight different records in the moci.sqlite file between Dattacker and Dvictim.
Key

Value (ID1)

Value (ID2)

1489063974653

1489061984928

d3b2cd658c458400

9d2eb8a790b43f0f

58c149dab2d7330551ac...

58c14860cb8ac6317ca9...

84789

86400

device_info

LGE Nexus 5X Android 7.1.1 (API 25)

LGE Nexus 5 Android 6.0.1 (API 23)

dv (in Korean)

No one knows who you are. What is my ideal type?

No one knows who you are. Please show off your lover!

push_token

APA91bEUzS5v1J6i35p...

APA91bGcApwFvWdZOOj...

Mobile Subscriber Identity, electronic serial number,
media access control (MAC) address from a device's
Wi-Fi or Bluetooth hardware, and phone number. If the
attacker does not know the exact algorithm to generate
the device-specific key, the plaintext user credential data
cannot simply be extracted from the application's storage files.
Against this defense approach, an attacker may certainly
attempt to reverse-engineer the application to analyze the
key generation algorithm and its parameters. However, the
use of device-specific keys can considerably raise the bar for
attackers, because the cost of reverse engineering is significantly greater than that of reading files. In addition, there
exist a number of antireverse-engineering techniques and
tools [13]-[15] to protect program codes, although it is
unclear whether such techniques are sufficiently strong to
protect sensitive software systems such as an encryption
algorithm implementation.

PREVENTING SUSPICIOUS LOGIN ATTEMPTS
Unfortunately, after successfully updating the attacker's files
with a victim's user credential data, it is not feasible to detect
automatic login attempts performed by the malefactor's
device, because the login attempt messages of both the victim
and the attacker's device are transmitted in exactly the same
manner. Alternatively, therefore, we can prevent suspicious
login attempts aimed at identifying the positions of user credential data in candidate storage files by targeting login patterns that are significantly different from normal ones. For
example, in the course of an attack, consecutive login
attempts with the wrong user credential data are periodically
made during a relatively short time. To prevent such login
attempts, a straightforward solution is limiting the number of
consecutive failed attempts from a particular device, e.g.,
based on its IMEI or MAC address. If we set this number
to, say, three, an attacker needs to exactly identify user

INCREASING THE SEARCH TIME FOR
IDENTIFYING USER CREDENTIAL DATA
As described in the "User Credential Cloning
Attack" section, an attacker has to search in the
collection of candidate files for user credential
data for extraction. Although this search process needs to be performed only once, we can
measurably boost the difficulty of the attack by
increasing the number of candidate paths for
the credential data. That is, the number of
changed fields and/or files can be intentionally
increased to make it more difficult for the
attacker to guess the correct positions of the
targeted information. Formally, given n candidate fields, 2 n - 1 different combinations should
be tested in the worst case. Therefore, if we
use a reasonably large value of n, identifying
user credential data becomes computationally
more expensive.

(a)

(b)

FIGURE 5. The results of a user credential cloning attack on the MOCI application: (a) before and (b) after the attack.

MAy 2018

IEEE Consumer Electronics Magazine

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - May 2018