programming4us
programming4us
MOBILE

Java Mobile Edition Security : Permissions and User Controls

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
The MIDP security system is clearly described in the MIDP specification and should behave similarly on all devices. In the real world, many phones and carriers do behave slightly differently, and this is one of the primary challenges of JME development.

Each application is granted a set of permissions that allows the application to use sensitive phone functionality (for example, GPS or the cellular network). The permissions are defined using fully qualified package names. Earlier in the sample JAD file, you saw the permission javax.microedition.io.Connector.http. Many of these permissions are defined in the MIDP JSR, but Optional JSRs may define permissions as well. The Location Services JSR, for example, defines permissions that are required in order to access location data. Applications are isolated from each other almost completely, with small exceptions made for applications signed with the same signature.

Not all applications may be authorized to use all permissions because not all applications are equally trusted. JME applications trust is determined by examining the application’s origin and integrity. Most devices use X.509 certificates and rely on the certificate’s common name (CN) and issuing CA as proof of origin. The signature in the JAD file binds the origin to the application and ensures that the application’s code has not been tampered with since it was signed.

After its identity is verified, the JVM assigns the application to a protection domain. These are groups of permissions that allow access to certain classes and functionality. A MIDlet suite may only be allowed to access one protection domain at a time, although MIDP 3.0 may change this. Frankly, having more than one set of permissions applying to an application at one time may be confusing. It will be interesting to see how that problem is resolved.

The protection domains are not standard across manufacturers and carriers, but with MIDP 2.1 there was an effort to standardize protection domains for GSM/UMTS phones. This effort produced the following domains, as detailed in the MIDP 2.1 specification:

  • Unidentified Third Party protection domain (a.k.a. untrusted) All unsigned code is placed in this domain. Irrespective of the MIDP 2.1 specification, all phones must have an untrusted domain and support running unsigned code.

  • Identified Third Party protection domain Code that has been signed with a certificate issued by a CA that the operator or manufacturer trusts. Code in this domain may be able to use the network or advanced phone functionality without user prompting.

  • Operator protection domain A highly trusted domain restricted to code signed by an operator-owned certificate. Generally allowed to do anything on the device.

  • Manufacturer protection domain A highly trusted domain restricted to code signed by a manufacturer-owned certificate. Generally allowed to do anything on the device.

Not all carriers follow these specifications exactly, but any changes tend to err on the more restrictive side. T-Mobile North America, for example, doesn’t include an Identified Third Party domain. Therefore, applications signed with popular JME signing certificates aren’t allowed to run on T-Mobile’s phones.

The untrusted protection domain is a special case and must exist on all MIDP phones. Applications without signatures are automatically placed in this domain, and for many applications that arrangement works perfectly well. Games, for example, don’t need to access much of the phones functionality, and the MIDP API set is intentionally designed to allow them to run without requiring signatures or special permissions. This means there are a lot of unsigned JME applications out there.

Interestingly, if an application has a signature that is either unknown or corrupted, the application will not be placed into the untrusted zone. Instead, the application will simply be rejected. This causes problems for developers with applications signed with a certificate that is recognized on one network but not on another. Just like getting into an exclusive night club, getting into the desired domain on certain carriers can be a combination of luck and skill.

The JVM enforces all permissions at runtime, and if an application attempts to access an API without permission, a dialog will be shown to the user asking for permission (see Figure 1 for an example of this). Alternatively, the device could fail the API call by throwing a java.lang.SecurityException. The MIDP specification contains a list of which APIs require prompting, but manufacturers can always choose to completely block access. Two sample APIs that require prompting are javax.microedition.io.HttpConnection and javax.microedition.io.HttpsConnection. These APIs are considered sensitive because they allow access to the network.

Figure 1. Device prompting for network access


Devices may adopt different prompting modes that control how often the user is asked for permission. The MIDP specification outlines three models: oneshot, session, and blanket. These models are respectively valid for one API use, one execution lifetime of an application, and for the entire lifetime of an application. Most devices use the oneshot mode because it is the most annoying and will force the developer to sign their code. Granting a permission is granting the application access to an entire API. Permissions are not necessarily provided on a per-item basis. For example, MIDP is asking “Do you want this application to be able to manipulate contacts?” It is not asking, “Do you want this application to be able to manipulate Nancy Jones’s contact?”

Overall, the MIDP permission system does well at controlling how applications are allowed to interact with each other and with the system, and there have been few reports of JME malware. The system is not without its downsides—the prompts can be confusing to users, and getting code signed properly can be difficult due to the way each carrier handles security.

Data Access

Mobile devices are nothing without the ability to access data from different sources. Normally, the Java.io and Java.net packages contain Java’s data access functionality. However, including all of these classes in JME would require too much memory. So JME uses the CLDC generic connector API, which is a framework for defining read/write operations on arbitrary stream data. By having one API, the number of classes in the standard API is kept down.

The connector API references data sources using standard URIs—for example, www.isecpartners.com for accessing the iSEC Partners website and “comm:0; baudrate=9600” for using the serial port. There are also connectors for accessing sockets, Bluetooth, and HTTPS. Not all connector exist on all devices, because not all devices support the same hardware. Three permission modes are defined when using the connector API: READ_ONLY, WRITE_ONLY, and READ_WRITE. The semantics of these modes change depending on the connector being used.

Network Access

All MIDP 2.1 platforms must support HTTP, HTTPS, Socket, and Secure Socket connectors. By default, untrusted applications are not allowed to use the network without prompting. On some carriers (but not all), signed applications can use the network silently. To learn more about the connector API, review the CLDC 1.1 specification and the javax.microedition.io.Connector documentation. Both describe the reasoning behind the generic connection framework and how to use it.

Record Stores

JME devices are normally resource constrained and may not have file systems. However, every device supports MIDP2 Record Management Store (RMS) databases. These can be used for persistently storing arbitrary blobs of binary data. For example, a geo-caching application may store the last location it recorded. Because they persist data, they are particularly interesting to security review. Thankfully, MIDP does the right thing—RMS databases are, by default, only accessible to the MIDlet suite that creates them. (Note that I said “by default.”)

RMS databases can be shared between applications if the AUTHMODE_ANY flag is specified at RMS creation time. This publicizes the database to any other application that knows the package and RMS database name (for example, com.isecpartners.testapp.RMS_STORE). The sharing is limited to the named record store and does not affect any of the application’s private record stores.

Sharing is not recommended for both privacy and security reasons, because users aren’t able to control which applications can access shared RMS databases. Even untrusted MIDlets can read or update shared RMS databases. Additionally, RMS doesn’t synchronize access to RMS records, so corruption is highly likely. If you’re planning on sharing any data, make sure the user is properly informed before doing so and be aware that sharing does not work on all phones. BlackBerry, for example, requires applications to use a more secure proprietary sharing mechanism.

Cryptography

By default, JME storage is not encrypted, and robust cryptographic classes are not included with the default SDK. To perform in-depth encryption, use the Legion of the Bouncy Castle’s JME cryptographic provider, available for free from http://www.bouncycastle.org/.

Other  
  •  Integrating Applications with the Windows Phone OS : Working with Launchers and Choosers
  •  Introducing Windows Phone 7 Launchers and Choosers
  •  Java Mobile Edition Security : Development and Security Testing (part 3) - Code Security & Application Packaging and Distribution
  •  Java Mobile Edition Security : Development and Security Testing (part 2) - Reverse Engineering and Debugging
  •  Java Mobile Edition Security : Development and Security Testing (part 1) - Configuring a Development Environment and Installing New Platforms & Emulator
  •  Java Mobile Edition Security : Configurations, Profiles, and JSRs
  •  Programming the Mobile Web : Performance Optimization
  •  Programming the Mobile Web : Testing and Debugging (part 3) - Client-Side Debugging
  •  Programming the Mobile Web : Testing and Debugging (part 2) - Server-Side Debugging & Markup Debugging
  •  Programming the Mobile Web : Testing and Debugging (part 1) - Remote Labs
  •  
    Soccer Highlights
    - VIDEO Strasbourg 2 – 4 PSG (League Cup) Highlights
    - VIDEO West Ham 0 – 0 Arsenal (Premier League) Highlights
    - VIDEO Liverpool 0 – 0 West Brom (Premier League) Highlights
    - VIDEO Tottenham Hotspur 2 – 0 Brighton (Premier League) Highlights
    - VIDEO Manchester United 1 – 0 Bournemouth (Premier League) Highlights
    - VIDEO Southampton 1 – 4 Leicester City (Premier League) Highlights
    - VIDEO Swansea 0 – 4 Manchester City (Premier League) Highlights
    - VIDEO Bayern Munich 1 – 0 FC Cologne (Bundesliga) Highlights
    - VIDEO Newcastle United 0 – 1 Everton (Premier League) Highlights
    - VIDEO Rennes 2 – 2 Marseille (League Cup) Highlights
    - VIDEO Hoffenheim 1 – 0 VfB Stuttgart (Bundesliga) Highlights
    - VIDEO Fiorentina 3 – 2 Sampdoria (Coppa Italia) Highlights
    REVIEW
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    programming4us
     
     
    programming4us