A Comparative Study of Indexing techniques of Moving points

1
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
WAP Architecture
Source WAP Forum, Wireless Application Protocol
Overview
11
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 Contd

• 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 Contd

• 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 users private information
• Examples DoubleClick and Engage
• Offline telemarketing
• Examples AtT 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
• W3Cs 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 customers 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 ltappletgt tags
• browser does not receive the ltappletgt 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 ltappletgt 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 applets 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 applets 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 applets 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 WAPs equivalent to JavaScript
• Derived from JavaScript

41
WMLScript Contd

• 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

• 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 users knowledge
• Does not prevent access to persistent storage
• Possible attacks
• Theft or damage of personal information
• Abusing users authentication information
• Maliciously offloading money saved on smart cards

43

• 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

• 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.