Mobile Commerce Security

1. Presentation By Mahmoud Youssef Mohamed PhD Candidate – IT major Mobile Commerce Security

2. Topics Mobile Commerce: The future of E-commerce Mobile Commerce Applications Mobile Computing Technologies New Security Risks New Privacy Risks Software Risks Conclusion

3. What is Mobile Commerce • Mobile Commerce (M-Commerce) is an emerging discipline involving applications, mobile devices, wireless networks, location technologies, and middleware [Cousins and Varshney] • Mobile devices usually use a different set of Internet protocol called the Wireless Application Protocol (WAP)

4. The Enabling Technologies • Wireless Networks • Wireless WAN (CDPD) • Wireless LAN (802.11a and 802.11b) • Short Range (Bluetooth) • Radio Frequency Identification (RFID) • Location Technologies • Outdoor Technologies • Infrastructure-based • Device-based • Indoor Technologies • Mobile Devices • Programming Standards (J2ME)

5. The Market Opportunityfor M-Commerce • Reports from Siemens and Ericsson (2001) predict: • the number of mobile devices to reach 500 million devices by 2002, and • 1 billion devices by 2004 • Durlacher (2000) expects the European market to reach € 23 billion by 2003 • Mobile advertising will be the killer application with 23% of the market size and mobile shopping will be the third major application with 15% of the market size

6. Mobile Commerce Applications Source (Ovum): http://www.ovum.com

7. Mobile Commerce Applications • Mobile Financial Services • Mobile Security Services • Mobile Shopping • Mobile Advertising • Mobile Dynamic Information Management • Mobile Information Provisioning • Mobile Entertainment • Mobile Telematics • Mobile Customer Care

8. Mobile Computing Technologies Mobile Computing Environment Wireless Application Protocol (WAP) Architecture Comparison between Internet and WAP technologies Bluetooth

9. Mobile Computing Environment Source: Barbara, D. 1999, Mobile Computing and Databases – A survey

10. Client Web Server WAP Gateway WML CGI Scripts etc. WML Encoder WML-Script WSP/WTP HTTP WML Decks with WML-Script WMLScript Compiler WTAI Protocol Adapters Content Etc. WAP Architecture Source: WAP Forum, Wireless Application Protocol Overview

11. Wireless Application Protocol Wireless ApplicationEnvironment (WAE) Other Services and Applications HTML JavaScript Transaction Layer (WTP) Session Layer (WSP) HTTP TLS - SSL Security Layer (WTLS) Transport Layer (WDP) TCP/IP UDP/IP Bearers: IS-136 CDPD PDC-P CDMA Etc.. SMS USSD CSD Comparison between Internet and WAP technologies Source: WAP Forum, Wireless Application Protocol Overview

12. Bluetooth • Bluetooth is the codename for a small, low-cost, short range wireless technology specification • Enables users to connect a wide range of computing and telecommunication devices easily and simply, without the need to buy, carry, or connect cables. • Bluetooth enables mobile phones, computers and PDAs to connect with each other using short-range radio waves, allowing them to "talk" to each other • It is also cheap

13. Bluetooth Security • Bluetooth provides security between any two Bluetooth devices for user protection and secrecy • mutual and unidirectional authentication • encrypts data between two devices • Session key generation • configurable encryption key length • keys can be changed at any time during a connection • Authorization (whether device X is allowed to have access service Y) • Trusted Device: The device has been previously authenticated, a link key is stored and the device is marked as “trusted” in the Device Database. • Untrusted Device: The device has been previously authenticated, link key is stored but the device is not marked as “trusted” in the Device Database • Unknown Device: No security information is available for this device. This is also an untrusted device. • automatic output power adaptation to reduce the range exactly to requirement, makes the system extremely difficult to eavesdrop

14. New Security Risks • Abuse of cooperative nature of ad-hoc networks • An adversary that compromises one node can disseminate false routing information. • Malicious domains • A single malicious domain can compromise devices by downloading malicious code • Roaming (are you going to the bad guys ?) • Users roam among non-trustworthy domains

15. New Security Risks Cont’d • Launching attacks from mobile devices • With mobility, it is difficult to identify attackers • Loss or theft of device • More private information than desktop computers • Security keys might have been saved on the device • Access to corporate systems • Bluetooth provides security at the lower layers only: a stolen device can still be trusted

16. New Security Risks Cont’d • Problems with Wireless Transport Layer Security (WTLS) protocol • Security Classes: • No certificates • Server only certificate (Most Common) • Server and client Certificates • Re-establishing connection without re-authentication • Requests can be redirected to malicious sites

17. New Privacy Risks • Monitoring user’s private information • Examples: DoubleClick and Engage • Offline telemarketing • Examples: At&T and Sprint • Who is going to read the “legal jargon” • Value added services based on location awareness (Location-Based Services) • Example: Pushing cuisine information and coupons

18. Targeted Marketing Applications • Keeping customers interested mandates personalization (Based on their user profiles) • Adding location to the customer selection criteria makes it even more effective. • Much information can be inferred by linking a user profile to her current location • W3C’s Platform for Privacy Preferences (P3P) • informing users about the privacy policy of the cites they visit

19. Privacy Protection • Considerable privacy protection can be achieved by designing an access control model that enables the user to define the access modes granted to merchants based on: • The individual merchant or a class of merchants • The time interval in the query • The location windows in the query • However, centralized management of profiles is needed.

20. Software Risks Wireless Application Protocol (WAP) Risks Platform Risks Java Security Application Risks WMLScript Risks of WMLScript

21. WAP Risks • WAP Gap • Claim: WTLS protects WAP as SSL protects HTTP • Problem: In the process of translating one protocol to another, information is decrypted and re-encrypted • Recall the WAP Architecture • Solution: Doing decryption/re-encryption in the same process on the WAP gateway • Wireless gateways as single point of failure

22. Platform Risks • Without a secure OS, achieving security on mobile devices is almost impossible • Learned lessons: • Memory protection of processes • Protected kernel rings • File access control • Authentication of principles to resources • Differentiated user and process privileges • Sandboxes for untrusted code • Biometric authentication

23. What is Java? • The most robust, easy-to-use, versatile language available today • Applications written for traditional operating systems are tied directly to that platform and cannot be easily ported to other platforms • often vendors need to provide different versions of the same software • Java has Write Once/Run Anywhere executables • allows Java programs written on one type of hardware or OS to run unmodified on almost any other type of computer • Best aspects is that it is architecture neutral Java applications Java Virtual Machine Unix Windows OS/2 MacOS Sparc Intel/Others PowerPC

24. What is Java? • Java is both interpreted and compiled • interpreted languages - BASIC • translates line-by-line and executes them, so slower • compiled languages - COBOL, C, C++, FORTRAN • translates the entire program into machine code and then the machine code is executed, so faster • First, source code is compiled to an intermediate code called bytecode • Java runtime interpreter then translates the complied bytecode to machine code • bytecode is different from machine code (more like assembly language) • includes the best aspects of C/C++, leaving out complicated aspects such as multiple inheritance, pointers etc.

25. What is mobile code? • Mobile code is a general term that refers to executable code that migrates and executes on remote hosts • Code travels from server machine to the client machine Provides • rich data display • a stock broker may publish the results of a financial analysis model • instead of publishing the result of the model as a graph, the broker could publish the model itself with connections to live stock market data and customer’s portfolio • efficient use of network

26. What is Mobile Code?

27. Types of Mobile Code • One-hop agents • sent on demand from a server to a client machine and executed • after execution, the result generated by the agent or the agent itself is sent to the owner who sent it • e.g. Java applets • Applet is a small piece of executable code, which may be included in a web page • Multi-hop agents • sent on the network to perform a series of tasks • These agents may visit multiple agent platforms and communicate with other agents • you may send personalized agents to roam the Internet. • To monitor your favorite Web sites • get you the ticket you couldn't get at the box office • help you to schedule meetings for your next overseas trip.

28. Threats to and due to mobile code • Malicious code • may disclose or damage our private data • spend our money? • Crash the system? • challenge is to execute useful applets while protecting systems from malicious code • Malicious host • challenge is to protect the agents from malicious servers

29. Techniques to prevent malicious code • Code blocking • authentication • safe interpreters • fault isolation • code inspection and verification

30. Code blocking • Disabling applications • switching off Java in Java-enabled browsers • relies on users complying with the security policy • not easy to administer in a large environment • prevents intranet use of mobile code • Filtering • firewalls to filter web pages containing applets • does not rely on user compliance • management can be centralized

31. Code blocking using firewalls • Rewriting <applet> tags • browser does not receive the <applet> and so no applet is fetched • Blocking by hex signatures • Java class files start with a 4-byte hex signature CA FE BA BE • apply in combination with <applet> blocker • Blocking by filenames • files with names ending .class • need to handle .zip files that encapsulate Java class files

32. Authentication • Achieved through code signing • based on the assurance obtained when the source of the code is trusted • on receiving the mobile code, client verifies whether it was signed by an entity on a trusted list • used in JDK 1.1 and Active X • once signature is verified, code has full privileges • Problems • trust model is all or nothing (trusted versus untrusted) • needs public key infrastructure • limits users (the untrusted code may be useful and benign) • no protection if the code from a trusted source is malicious

33. Safe Interpreters • Instead of using compiled executables, interpret mobile code • interpreter enforces a security policy • each instruction is executed only if it satisfies the security policy • Examples of safe interpreters • Safe-Tel • telescript • Java VM

34. Safe interpreter: The Sandbox security model • The applet’s actions are restricted to a sandbox • the applet may do anything it wants within its sandbox, but cannot read or alter any data outside of its sandbox • Applets and applications • Local code is trusted and has full access to system resources • downloaded remote code is restricted • Java applications may be purchased and installed just like traditional applications, these are trusted Remote code sandbox Local code JVM Valuable Resources

35. Building the sandbox • class loader • responsible for loading classes • given class name, fetches remote applet’s code (I.e, locates, generates its definitions) • keeps namespaces of different applets separate • bytecode verifier • checks a classfile for validity (bytecode conformance to language specification and that there are no violations of Java language rules) • code has only valid instructions • code does not overflow or underflow stack • does not change the data types illegally • goal is to prevent access to underlying machine via crashes, undefined states

36. Building the Sandbox • security manager • enforces the boundaries of the sandbox • whenever an applet tries to perform an action, the Java virtual machine first asks the security manger if the action can be performed safely • JVM performs the action only if the security manager approves • e.g, a trusted applet from the local disk trying to read the disk • imported untrusted applet may be trying to connect back to its home server • if no security manager installed, all privileges are granted

37. Building the sandbox • Security manager will not allow • untrusted applet to read/write to a file, delete a file, get any info about a file, execute OS commands or native code, load a library, establish a network connection to any machine other than the applet’s home server

38. Extensions to the Sandbox • JDK 1.1.x • supports digitally signed applets • if signature can be verified, a remote applet is treated as local trusted code • JDK 1.2 • no concept of local trusted code • all code is subject to verification • fine grained domain based and extensible access control • typed and grouped permissions • configurable security policy

39. Application Risks to Mobile Devices • Java Virtual Machine (JVM) implementation • No type check is implemented • No sandbox or stack introspection • The use of C language with its related problems • Security tradeoffs imposed by limited capabilities

40. WMLScript • Scripting is heavily used for client-side processing to offload servers and reduce demand on bandwidth • Wireless Markup Language (WML) is the equivalent to HTML, but derived from XML • WMLScript is WAP’s equivalent to JavaScript • Derived from JavaScript™

41. WMLScript Cont’d • Integrated with WML • Reduces network traffic • Has procedural logic, loops, conditionals, etc • Optimized for small-memory, small-CPU devices • Bytecode-based virtual machine • Compiler in network • Works with Wireless Telephony Application (WTA) to provide telephony functions

42. Risks of WMLScript • Lack of Security Model • Does not differentiate trusted local code from untrusted code downloaded from the Internet. So, there is no access control!! • WML Script is not type-safe. • Scripts can be scheduled to be pushed to the client device without the user’s knowledge • Does not prevent access to persistent storage • Possible attacks: • Theft or damage of personal information • Abusing user’s authentication information • Maliciously offloading money saved on smart cards

43. Conclusion • The platform and languages used have failed to adopt fundamental security concepts • Encrypted communication protocols are necessary to provide confidentiality, integrity, and authentication services to m-commerce application • The greatest risk is possibly coming from mobile code

44. Conclusion Cont’d • Some of these problems are expected to be fixed in the near future. However, other problems will continuo to exist. • Security models have to be part of the design • Currently, accumulated experience in the security field has not been fully utilized in mobile commerce systems. • The success of mobile commerce will depend critically on the level of security available.