Mobile Payment Security

Mobile Payment

Security

Maurice Aarts & Nikita Abdullin

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

Secure Element transaction

NFC transaction evolution (1)

• Coordination between multiple

parties

• Issuers vs. SE vendors

Secure Element transaction

NFC transaction evolution (2)

NFC transaction evolution

• Issuing banks are independent

from SE vendors

• Agile development cycles and

continuous application improvement

Can we run secure applications in a smartphone?

A security comparison

Terminal App User

Assets

• Key proves transaction participation

• PIN proves user consent

Conceptual transaction protection

pu

bl

ic

8

Transaction details Approval request

User approval Signed transaction Approve (PIN) Sign Key

Android Payment Ecosystem

• Risk mitigation data

Payment network Point of Sale (PoS)

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

Platform / ecosystem overview

1. Sign manipulated transactions

Malware intercepts and change details in valid transaction

2. Sign arbitrary transactions

Malware invokes signing function

3. Extract key

Malware reads key

Main malware threats

pu bl ic 12 Mobile phone OS App Crypto Key Malware

Attacks are s

c

a

l

a

b

l

e

!

Android vulnerabilities

• Rooting = getting system level access to all resources

• Files

• Memory

• Peripherals

• Interfaces

• All OS protection voids with rooting

• Rooting is achieved by exploiting an OS bug

• All attacks start by rooting…

Rooting

pu

bl

ic

• Any phone may be rooted • Any application may be reversed • Any asset may be compromised

• Is there any hope for mobile software security?

Rooting impact

pu

bl

ic

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

• Varying levels of expertise

• From buyer of an exploit pack to expert black-box criminal attacker

• Can eventually achieve full control of the device

• Can mount scalable attacks

• Can interact with the legitimate users (spear-phishing, etc.)

Attacker Model

pu

bl

ic

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

• Main concept:

• Endless psychological warfare on attackers

• Developer time / effort to release a new version

– vs.

• Deterrence / frustration of the attacker

o Attacker has a budget, too

o Compartmentalization of the assets limits damage

o Agile development cycle helps to stay ahead of the attackers

Attacks vs. countermeasures

pu

bl

ic

Root Detection

public

Root Detection

public

21

Attack!

1. Change device property to “release-keys”

2. Rename each of the files if they exist. An attacker doesn’t care if the file is called “Superuser.apk” or “Xp@suwn$55.apk”, as long as it works.

3. Change the name of the ‘su’ binary to something else, e.g. ‘p0wn’ which will not trigger the check.

Debug and Emulation Detection

What if we

could modify

these checks?

Hooking?

Caller

Callee

Hook

x

1. Inspect and log calls

2. Prevent calls

o E.g. skip setting a flag that indicates security violation

3. Modify parameters

o E.g. redirect communications to a malicious server

4. Modify return values

o E.g. always return true after password check

5. Replace a function

o E.g. hide suspicious files from the application

What can we do with hooking?

pu

bl

ic

Debug and Emulation Detection

public

25

We can just let

checkDebuggable()

and

checkEmulator()

• Run-time integrity checks (anti-instrumentation)

• Self-checking code (inline self-checks)

• Check APK package and binary code hashes

• Use vendor-supplied device profiling & risk assessment

mechanisms

• Anti-debugging checks

• For Java: ask Android Framework

• Try to self-debug or do other profiling for native code

• Check environment variables & properties

Other anti-tamper techniques

pu

bl

ic

• Make the environment more stealthy

• Move/rename binaries

• Intercept APIs in user-mode

• Use less invasive techniques

• Stealthy DBI approaches that do not use splicing

• Customize system images, emulators

• Android Kernel modules with kernel-mode hooks

Attacks on anti-tamper

pu

bl

ic

Goal: complicate human analysis of code

• Name obfuscation: make names meaningless

e.g. encrypt( byte[] plain ); → m1( byte[] p1 );

information lost, manual improvement possible

• String obfuscation: make strings incomprehensible

e.g. String algo = “AES/CBC/PKCS5Padding”; → String s1 = m2(“802e8)Qjrq_zgF)2LUx”);

automatic decryption possible if encryption is static

• Flow obfuscation: prevent decompiling and hide logic

e.g. insert jump statements in binary incompatible with source code constructs; exploit decompiler analysis engines

binary analysis and partial reconstruction still possible

Code Obfuscation (1)

pu

bl

ic

Goal: complicate human analysis of code

• Java Reflection/Class loaders: load bytecode dynamically

e.g. com.my.core.crypto.rand(); → a.getClass(…).getMethod(…);

dynamic analysis or AST transformations needed to get the original code

• Native code obfuscation – all state-of-the-art techniques, even slow ones

o Self-modifying code

o CFG flattening

o Opaque predicates & bogus code inlining

o Arithmetic transformations

o Stack/register variable manipulation

o …

dynamic analysis or advanced automation needed to get the original code+CFG

Code Obfuscation (2)

pu

bl

ic

• Each of the lines represents control flow transfer between basic blocks of code

• Obfuscators can make CFG

analysis much harder

Code Obfuscation (3)

public

Goal: complicate human analysis of code

Impact: reverse engineering slowed down

Code Obfuscation (4)

• Automated deobfuscation

• Popular obfuscator tools will have public deobfuscators

• Scriptable disassemblers/decompilers/debuggers

• Run-time code dumping

• Advanced program analysis

• Symbolic execution

• SAT/SMT solvers

• Java: bytecode runs on top of JVM, so attacks on the JVM level

• More manual effort

Attacks on code obfuscation

pu

bl

ic

• Attackers may want to exfiltrate data + code and run it on another device

• So capture an unique fingerprint from inside the device

• Serial numbers/model strings/version/patch level/…

• Make cryptography device-dependent

• Use the device binding data in key derivation, etc.

• Use hardware-backed features when possible

• Hardware-backed KeyStore / TEE / …

Device Binding

pu

bl

ic

• Identify code that does device binding “scans”

• Which code queries the serial number, etc.

• Intercept the device fingerprint if it is used in a different place from

where it is captured

• Copy & spoof all well-known device properties on the OS level

• As the standard Android emulator source code already does

Attacks on Device Binding

pu

bl

ic

• Resists logical and physical attacks

• Strong mitigation of key exposure risk

Secure Element - Overview

pu

bl

ic

• TEE is the new trend • Clear split between Rich OS and TEE • Resists logical attacks • Fair mitigation of key exposure risk

Trusted Execution Environment – Overview

pu

bl

ic

Obfuscation: White-box Crypto (1)

pu

bl

ic

Strengths

• Algorithm code size multiplies

Manual reverse engineering is tedious

• Diversification across instances

Attack does not scale well

Weaknesses

• White-box hides the key, not the function

Attackers may still copy the entire WB function and run it externally (code lifting)

• Immature technology

Attacks have already emerged (automation, side channel, fault injection, …)

E. Sanfelix et al. “Unboxing the White-Box. Practical attacks against Obfuscated Ciphers.”

https://www.blackhat.com/docs/eu-15/materials/eu-15-Sanfelix-Unboxing-The-White-Box-Practical-Attacks-Against-Obfuscated-Ciphers-wp.pdf

Obfuscation: White-box Crypto (2)

pu

bl

ic

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

• Static analysis

• Decompilation / Disassembly / Unpacking

• Dynamic analysis

• Debugging

• Tracing (code / API / …)

• DBI / Hooking

• Anti-anti-debugging / anti-root-detection / anti-anti-emulation

• Emulation / Replay

• Side channel / Fault Injection

• Domain-specific

• Libraries and helpers: EMV, NFC, crypto

Tools

pu

bl

ic

Riscure

Inspector

Android attack tools

pu

bl

ic

41

Rooting tool

e.g. Towelroot Development kit

Inspection tool e.g. Androguard

Disassembler e.g. IDA, JEB

Debugger e.g. GDB, JDWP

Decompiler e.g. JEB

Instrumenting e.g. ADBI, DDI, Frida,

Substrate, Xposed, LD_PRELOAD

Side Channel / Fault Analysis

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

• Distance in time and space raises attacker cost

• Limited Use Payment Credentials/Keys must be limited

• Back-end risk management & security controls

• Security is a moving target

• Development process has to outrun the attackers

• Continuous security evaluation

• Mobile platform security is far from smart card standards

Things to Keep in Mind

pu

bl

ic

• Introduction

• EMV & NFC for HCE

• Platform / ecosystem overview

• Attacker model

• Attacks and countermeasures

• Tools

• Things to keep in mind

• Conclusions

Content

•

Smart phones are

not secure

platforms

•

Mobile payment apps

need

additional

security

•

Several new concepts are

emerging

that may enable

secure apps

•

Evaluation can help

identify & mitigate

risk

Conclusion

Riscure North America

550 Kearny Street, Suite 330 San Francisco CA 94108 USA

Phone: +1 650 646 99 79

[email protected]

Riscure B.V.

Frontier Building, Delftechpark 49 2628 XJ Delft

The Netherlands

Phone: +31 15 251 40 90

www.riscure.com

Contact: _{Maurice Aarts} – [email protected]

Riscure is Hiring!