The document discusses the state of mobile banking security, highlighting features of mobile devices, banking architecture, and various security concerns, including attacks such as man-in-the-middle and fake applications. It emphasizes the need for better security measures, including multi-factor authentication and secure coding practices, due to the increasing threat of mobile malware. The presentation also covers the challenges in balancing user experience with security and calls for heightened awareness among users and developers regarding mobile security issues.

1. Mobile Banking
Security
Petr Dvořák
Partner & Mobile Strategy Consultant
petr@inmite.eu
SmartDevCon 2013 - Katowice

2. 2008
Company founded in
with mission to improve
the world with high-tech
solutions.

3. 100%
Year-by-year growth
in employee count and
financial results.

4. First versions of apps for KB and Česká spořitelna were developed with Cleverlance Enterprise Solutions a.s.

5. securityconcerns
For about 20% of smartphone users
who don’t use the mobile banking,
were the primary reason for making
the decision.

6. Mobile Banking
Security

7. Outline
• Features of the mobile devices.
• Mobile banking architecture.
• The current status of mobile banking
security.
• Topics for 2013/14.

8. Mobile Devices

9. Mobile Devices
• Smartphones and tablets.
• Cheap. Ubiquitous.
• Highly portable, mobile.
• Always on-line (GSM i Wi-Fi).
• With sensors.

10. Mobile Operating Systems
• Rich application platform with stores.
• iOS: Mac OS X, Objective-C / Cocoa.
• Android: Linux, Java (Dalvik).
• Relatively simple runtime modification.
• Benevolent memory management.
Simple attack after
jailbreak or failbreak.

11. Mobile Bankig
Architecture

12. Overview
Front-end Facing
Server
IntegrationPlatform
Transaction System
Authentication
System
...
XML/JSON
over REST
Penetration
testing before
“big” releases.

13. Mobile Banking App
Ideally, a native
application.
Various
operating
systems

14. Mobile Banking App
Objective-C

15. Mobile Banking App
Java

16. Mobile Banking App
C/C++ (shared code)

17. Current Status

18. Current Status
• Typically“adequate”level of security.
• No consensus on“How”.
• UX vs. security compromise.
• Old and new topics.
• Coming problems are foreseen.

19. The Good Old Attacks
• MITM attack.
• Fake app.
• After-theft attack.
• Reverse engineering.

20. MITM Attack
• iOS - trivial (Wi-Fi, e-mail).
• Android - less trivial
(SD card).
• Signing on application level.
• Strict SSL certificate
validation.

21. MITM Attack
• iOS - trivial (Wi-Fi, e-mail).
• Android - less trivial
(SD card).
• Signing on application level.
• Strict SSL certificate
validation.

22. MITM Attack
• iOS - trivial (Wi-Fi, e-mail).
• Android - less trivial
(SD card).
• Signing on application level.
• Strict SSL certificate
validation.
What happens if the
certificate expires?

23. Fake App
• iOS -“impossible”(review).
• Android - Trivial (open).
• Manual Google Play
(and App Store) checks.
• User ratings.
Users are waiting
eagerly.

24. Fake App
• iOS -“impossible”(review).
• Android - Trivial (open).
• Manual Google Play
(and App Store) checks.
• User ratings.
The best defense: release an app,
make it great and share it!

25. After-Theft Attack (ATA)
• Theft or loss of the device.
• Small real impact, large fear on the users’side.
• Attack subtype:
• Side channels.
• Guessing password.
• Password mining.

26. ATA: Side Channels
• Usage of the same password for many
apps.
• Weak password storage.
• Fingerprints on the display.
Don’t attack the banking itself.

27. ATA: Side Channels

28. ATA: Password Guessing
• Limit the attempt count.
• Random shared key (symmetric cipher).
• Sequence / Freshness.
• The“unlocking password”may be simple.
In the case of the right
implementation of partial
verification.

29. ATA: Password Guessing
• Anti-DoS features required.
• Recognize if user has the device, or just
guesses and asks server.
• Multi-factor authentication.
The opposite requirement than
limiting the attempt count.

30. ATA: Password Mining
• Memory dump or runtime attack.
• Strict memory management required.
• Low-level implementation (C/C++
module).
• Android NDK.
Jailbreak + Cycript.

31. ATA: Password Mining
Application
Starts
Application
Closed
Application
terminated
User: The app is done. Attacker steals the device or
she steals it...
Malware?
Game over...
Password
entered
System: I will keep it for a while.

32. ATA: Password Mining
• Erasing keys and
intermittent values from the
memory.
• Harder decompilation of
the security
implementation.
• Special secure keyboard
with Vernam cipher for
secure PIN entry.

33. Reverse Engineering
• Uncovering implementation details
attracts“the curious guys”.
• Opens up unnecessary discussion
= reputation risk.
• Discovering other implementation
weaknesses.

34. Reverse Engineering
Dark side of iOS
by Kuba Břečka @kubabrecka
11:15

35. Topics for 2013/14

36. Application
Starts
Application
Closed
Application
terminated
User: The app is done. Attacker steals the device or
she steals it...
Malware?
Game over...
Password
entered
System: I will keep it for a while.

37. Mobile Malware
• Problem mainly for Android OS.
• Intensity will increase.
• Hijacking authorization SMS (Eurograbber).
• Hijacking URL schemes and intents.
• Mobile anti-viruses will not save the day.
Quite easily...

38. Stronger Authorization
• Current mobile banks are retail oriented.
• Almost no SME and enterprise oriented
solutions.
• Feature-wise and security-wise.

39. HW Token, ARM TrustZone, ...
Many options.

40. HW Token, ARM TrustZone, ...
Many options.None is totally great. ☹

41. evangelization
One big challenge we are facing is
of both app users and app
developers on the subject of
mobile security.

42. Thank you!
Petr Dvořák
Partner & Mobile Strategy Consultant
petr@inmite.eu
finance.inmite.eu