Chapter 3 Client Security Architecture

This chapter contains an overview of the Sun Java System Mobile Enterprise Platform (MEP) client security features and describes how the Secure MusicDB application implements these features.

This chapter covers the following topics:

• Client Security Limitations

• Best Practices for Secure Client Applications

• Authentication on the Client Device

• Data Encryption

• Transport-layer Security

• Data Destruction

• Lockout

• Data Fading

• Secure MusicDB Java ME Application

Client security must perform the following tasks:

• Provide a simple PIN-based form of authentication (see Authentication on the Client Device)

• Provide a means to secure data at rest on the mobile device (see Data Encryption)

• Provide a means to securely synchronize with the Gateway Engine on the server (see Transport-layer Security)

• Provide a mechanism to destroy business data (see Data Destruction)

• Provide a means to prevent the client device from synchronizing (see Lockout)

• Provide a means to remotely destroy all of the data on the device (see Poison Pill)

• Provide a means to notify the application that a certain quiet period has elapsed (see Data Fading)

• Provide an API that allows developers to replace the MEP default implementation with their own (see The DefaultSecurityManager Class and The SecurityManager Class)

Client Security Limitations

This is not a perfectly secure system, so some best-practice recommendations are needed. Since MEP provides a library, it is not possible to control how sensitive information (that is, credentials) is managed. The application programmer is responsible for managing this information.

Best Practices for Secure Client Applications

Developers of secure client applications should observe the following rules:

• Do not hard-code values for the Gateway credentials into the application

• Do not store or cache form data on the device

• Require or encourage end users to use the native security services of the device

• You must use HTTPS to provide transport-layer security

Authentication on the Client Device

There are two forms of authentication on the client device:

• User Authentication: the end user authenticates with the device through an alphanumeric Personal Identification Number (PIN)

• Gateway Authentication: the end user authenticates with the Gateway Engine through a username and password

The MEP client library provides an API to validate an arbitrary length alphanumeric PIN against a PIN derivative stored on the device. The library also maintains a count of validation attempts (even across restarts of the application). If a threshold of failed attempts is exceeded (specified by the client application), data destruction and device lockout can occur.

Storing the PIN derivative and a count of validation attempts on the device is an obvious weakness in the security architecture, as this data could be easily subverted. Therefore, it is recommended that users follow the best practices outlined above to improve the overall security of the system.

Supplying the correct PIN allows users to access the application and perform local operations, but users will not be able to synchronize with the Gateway Engine unless they supply the proper username/password credentials for the Gateway Engine.

Authentication Implementation

Let:

	S = alphanumeric secret (random key sequence entered exactly once by user)
	S' = md5sum( S )

	P = alphanumeric PIN (entered by user every time)
	P' = md5sum( P )

	cipherText = encrypt( S, P' )

	persist { S', cipherText } on the device

Upon subsequent logins:

	P = PIN
	P' = md5sum( P )
	plainText = decrypt( cipherText, P' )

	if ( md5sum( plainText ) == S' )
		success
	else
		failure

Data Encryption

Data at rest on the mobile device is encrypted by using a digest of the PIN as the encryption key. There are four locations in the MEP client library where encryption and decryption must occur. In these locations, the MEP library will invoke encrypt/decrypt callback methods that perform the tasks.

Transport-layer Security

It is assumed that transport-layer security is provided by HTTPS. Data streaming in the OMA DS protocol is always encoded simply in base64.

Data Destruction

The MEP client library keeps track of how many times client applications attempt to validate a PIN against the PIN derivative stored on the device (even across application restarts). If the application exceeds the threshold specified by the application developer, the MEP library will erase all of the MEP records on the mobile device and prevent any further attempts to validate the PIN.

Lockout

The MEP client library keeps track of how much time has lapsed since the last synchronization attempt with the Gateway Engine. At the beginning of each synchronization, the MEP library calculates how much time has elapsed. If the time since the last synchronization exceeds the threshold specified by the application developer, then all MEP records can be erased from the device.

The library also maintains a count of validation attempts (even across restarts of the application). If a threshold of failed attempts is exceeded, both data destruction and lockout can occur.

Poison Pill

A MEP administrator can remotely trigger the destruction (wiping) of all the data on a particular device.

Data Fading

The client security implementation keeps track of how much time has elapsed since the last successful synchronization. The client application may specify a maximum quiet period after which the application may decide to activate the data destruction feature.

Secure MusicDB Java ME Application

The Secure MusicDB application demonstrates most of the security features described in this document:

• Authentication on the Client Device: The first time you launch the MIDlet, you are prompted to set a security PIN. The PIN can be any alphanumeric string. You are also asked to enter a long random sequence of key-presses on the device in the “secret” field. The PIN and secret are used to compute the derivatives described above, which are stored on the mobile device's RMS record store. Upon subsequent launches of the MIDlet, you are prompted to enter the PIN. If the PIN does not correctly reverse the computation of the derivatives stored in RMS, then an error message appears, and you are prompted to enter the PIN again. The MIDlet also clearly indicates how many attempts you have left before it performs data destruction.

• Data Destruction and Lockout: After you fail to enter the PIN 3 times, the MIDlet destroys all MusicDB data on the device, and you are prevented from using the application.

• Recovering from Lockout: If you are locked out of the application, you must remove and reinstall the Secure MusicDB application on your device. This should reset the security information stored in RMS, and you will see the initial screen asking for a secret and PIN.

• Encryption: The PIN you enter is used to encrypt and decrypt all data at rest on the device.

• Transport-layer Security: The Gateway Engine is configured to allow mobile clients to communicate using HTTPS in order to provide transport-layer security.