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