Lotus Rich Client Experience and Security Related Device API Requirements

 

Lee Griffin, IBM, WPLC Mobile Development

Mary Ellen Zurko, IBM, WPLC Online Collaboration Services Security

 

Lotus Notes Traveler <http://www-01.ibm.com/software/lotus/products/notes/traveler.html> is a mobile messaging rich client for Lotus Domino software. The basic design of Traveler includes software that is installed on to devices.  We then use applications that communicate using HTTP or proprietary protocols. We expect that the requirements we have in this area for both the current version and near term future versions in the area of basic security related capabilities will be the same for web-based applications. For web user agents, including browsers, we expect the same requirements for signing software, validating user identity, and ensuring the security and trustworthiness of the device and platform.

 

Protecting the Device Software Integrity

 

Mobile devices have their own models for software integrity, that are not currently entirely aligned with web models. For example, both Windows Mobile and Symbian have provisions for signing applications.  The Symbian operating system is very rigid to the point of making development difficult.  During development individual device IMEIs must be included in each developers deliverables in order for the application to be later installed to the device.  This is not practical for large scale development, especially worldwide.  This restrictive model is based on capabilities that applications use.  The Symbian capabilities strata can be rigid compared to application needs. As an example, an application that does nothing to any radio (either voice or data) is under those restrictions because it uses a data pipe.  More strata with reduced restrictions as one moves up the stack from the hardware would better model the trust needed in a specific application. For web applications, signing applications will be critical. The question of how the web user agent will align trust and capabilities of a web application with the diverse device models. A harmonized model will benefit the security and usability of all platforms.

 

Validating the user

 

Traveler uses simple user id/password combinations identify and authenticate users.  We provide a method to securely store these on the device. This is likely to be a more general purpose requirement which web user agents are expected to fulfill. When coupled with device security policies for things like screen time out and password revocation, this provides a good baseline for rudimentary usability and security. Devices provide the possibility for additional forms of authentication. For example, APIs could allow an application to positively identify a person using biometric information.

 

Application key management

 

Domino support for encrypted email includes existing support for public/private key management. Domino private keys are stored in the Notes ID file, which is encrypted under a user password. After the user is authenticated so that they are allowed to access their email, they must again provide their credentials to access the keys for any encrypted email.  The keys are kept downloaded on the mobile device for performance and usability reasons, and to allow offline access to encrypted emails. APIs are needed that support application key management in scenarios such as this one. Consideration should be given to extra security features, such as erasing cached private keys after some period of time or style of use. The needs of pre-existing infrastructures, as well as new ones, should be taken into account. In some cases, encryption at the database or file level may be substituted for data level encryption. Currently we're implementing our on one-off version of key caching and management for Windows Mobile OS and plan to do the same for Symbian shortly. 

 

Managing security and other attributes on the device

 

Domino has remote administration features for monitoring and setting policy attributes in the Notes client. In the case of Traveler, this information includes security related information for operations on the device. While we install an application to a device to facilitate monitoring, standardizing such an API would facilitate central administration by business and enterprise administrators. The Domino infrastructure leverages a public key infrastructure, signatures, and local overrides to secure such interfaces. Management features operate the same way, allowing immediate revocation of access to data or data removal from the device, or the disabling of features or entire applications.

 

Analogously, both Windows Mobile and Symbian include a special function that allows the device to be remotely restored to factory settings. The same security concerns that apply to remote application management interfaces apply even more to these device level functions. Some form of authentication or “pairing” to restrict access to such commands is needed, whether through physical proximity and user acknowledgement (as in the simplified trust management work of Smetters and others), or a more general purpose set of installed trust roots (the challenges of which are well known through existing web phishing attacks).

 

Constraints of the mobile device

 

Mobile devices are constrained in several ways, including screen real estate, disk space, and memory. Several approaches to securing user web interactions look to use more of these resources. Anti phishing approaches that represent identity (such as the Firefox identity signal) or enhanced assurances (such as extended validation certificates) use more screen real estate. The complex web security models are currently unmanageable, spawning work in sandboxing (such as in Google Chrome) or site specific browsers (such as Mozilla Prism). The constraints of mobile devices may allow us to instead consider a radical stripping down of unsecured functionality, or other counter constraints (such as rich client applications) that will provide secured functionality within mobile device limitations.