Mobile Security and Payments Infrastructure

1. Mobile Security and Payments Infrastructure AJ Dexter Sr. Security Consultant

2. A little about me.. • Sr. Security Consultant at Cigital • Former Lead Mobile Security Architect @ US Bank. • Mobile Platform & Application SME • Mobile Development Liaison for Security • BITS/FSTC Mobile Threat Assessment SME. • Portland OWASP Founder • Appreciator of nature and multi colored sunsets.

3. Agenda • Intro • Key Terms • Statistics • Mobile Security Issues • Mobile Services • Mobile Payments • Mobile Platforms • Common Issues • Android • iOS • Blackberry • Discussion

4. Key Terms Smartphone - Mobile phone offering advanced capabilities. PC-like functionality. Platform – The operating system on the smartphone. Mobile Web Applications – Web application with a constrained interface. Mobile Applications – “Thick” application meant to be run from the phone. Mobile Banking – View account balances, transactions, transfer funds between accounts, pay bills, receive account alerts, deposit checks, etc. Mobile Payments - Use mobile device for purchase or other payment-related transaction at point of sale (proximity) or via internet (remote).

5. Worldwide Broadband Growth Source: International Telecommunications Union

6. Mobile Broadband Subscriptions Source: International Telecommunication Union (Nov. 2011)

7. United States Mobile User Behavior Source: Adobe Mobile Experience Survey (Oct. 2010)

8. United States Mobile User Behavior Source: Adobe Mobile Experience Survey (Oct. 2010)

9. Mobile Payments

10. Mobile Payment Evolution Source: Marianne Crowe Federal Reserve Bank of Boston

11. Mobile Financial Services

12. Mobile Security Issues

13. OWASP Top Ten Mobile Risks Source: OWASP Mobile Security Project

14. Major Mobile Risks Source: OWASP Mobile Security Project

15. Major Mobile Risks continued Source: OWASP Mobile Security Project

16. Cryptography Store only what is absolutely necessary. Don’t trust the device to protect that sensitive information. Where possible leverage the application for robust encryption and make use of industry standard libraries. Don’t rely on Platform or “All device” encryption.

17. Transport Understand the architecture. Includes mobile carrier networks/operators, personal networks, and corporate networks. End to end encryption.

18. Backend Issues Understand additional risks that mobile devices bring to existing architectures. Secure the backend APIs just as you would for web services. Implement robust session handling.

19. Other Give users the ability to educate themselves, and take a role in their own security/safety. Just don’t trust them to make the right decisions. Build security into the application at all layers of the SDLC.

20. Apple iOS Google Android Blackberry Platform Capabilities

21. General Platform Issues 21 • Robust, well vetted platform encryption still not common. • Physical Security; • Single User security model. • Assume attacker has physical access. • Removable media can’t be trusted • Application Isolation/Sandboxing…Weak link? • Jail breaking adds an unknown to testing and security. • App stores can act as a mechanism to validate basic coding practices. They aren’t robust tests for security. • Also act as a means for distributing truly bad apps. Platforms teach users to intrinsically trust distribution channels. • Small displays make it difficult to inform users of choices, provide warnings. Makes easier phishing targets.

22. Apple iOS 22 Security Model Very similar to Mac OS X. Based on TrustedBSD Uses Mandatory Access Control to restrict the capabilities of applications. Implements a method for sandboxing applications. Permissions/Access Control Each application is given free access to it’s own file system resources. Any elevated privileges or access to specific APIs prompts user to allow or deny at time of use. Storage SQL Database: flat file databases where data can be accessed with conventional SQL queries. Keychain Storage: for securely storing small amounts of data. Passwords, cookies, short text strings. File System: Similar to a home directory for each application Development Applications are developed in Objective-C. Bundled with an entitlements and preferences file, code signed by an Apple issued certificate.

23. Google Android 23 Security Model • Based on Linux user and file permissions. • Each process is tied to a userid. • Applications are run isolated in their own virtual machine. Permissions/Access Control • Free for harmless interactions with the operating system. • For all other interactions the developer has to specify what permissions are needed in a manifest file. The user approves these interactions when the application is installed. Storage • File system: Similar to a home directory for each application • SQLite Databases: flat file databases where data can be accessed with conventional SQL queries. Development • Applications are developed in Java, compiled into DavlikExecutables, bundled with the manifest files, and packaged into Android Package files. • Packaged is signed by the developer’s public key pair, and sent to Google Market.

24. Blackberry 24 Security Model • Relies on a custom Java Virtual Machine to sandbox applications. • Controls application access on a per-API level. • Security enforcement is facilitated by signatures, java verification, and class restrictions. Permissions/AccessControl • Permissions are determined and assigned per application based on the signature and policy specified by the user. • Sensitive APIs may require the application to be signed before allowing access. Storage • Combined flash and external memory in virtualized view. Layout similar to a Unix based operating system. • Utilizes a pretty sophisticated content protection system that encrypts data when written to memory. Development • Applications typically developed in Java.

25. Discussion Questions/Thoughts? Check out the OWASP Mobile Project Contact Info: AJ Dexter adexter@cigital.com LinkedIn, Google+, Twitter