42
Mobile Banking Security Petr Dvořák Partner & Mobile Strategy Consultant [email protected] SmartDevCon 2013 - Katowice

SmartDevCon - Katowice - 2013

Embed Size (px)

DESCRIPTION

As most people are aware, there has been an expansion in mobile banking applications in recent years. The Czech Republic is no exception to this, as nearly all banks have developed a mobile application for their modern mobile operating systems. Although different banks solve their security concepts in different ways, it is possible to discuss typical situations and problems that inevitably appear while designing mobile banking applications.

Citation preview

  • 1. Mobile Banking Security Petr Dvok Partner & Mobile Strategy Consultant [email protected] 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 spoitelna were developed with Cleverlance Enterprise Solutions a.s.
  • 5. securityconcerns For about 20% of smartphone users who dont 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 Typicallyadequatelevel of security. No consensus onHow. 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 usersside. 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. Dont attack the banking itself.
  • 27. ATA: Side Channels
  • 28. ATA: Password Guessing Limit the attempt count. Random shared key (symmetric cipher). Sequence / Freshness. Theunlocking passwordmay 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 attractsthe curious guys. Opens up unnecessary discussion = reputation risk. Discovering other implementation weaknesses.
  • 34. Reverse Engineering Dark side of iOS by Kuba Beka @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 Dvok Partner & Mobile Strategy Consultant [email protected] finance.inmite.eu