Emerging mobile technologies such asPDAs, laptops and smart phones togetherwith wireless networking technologies suchas WLAN and UMTS promise to empowermobile employees to become betterintegrated into their companies' businessprocesses. However, the actual uptake ofthese technologies is still to come; onehindrance is security of mobile devices andapplications.
In this contribution we present an in-depth analysis of the current situationenterprises are faced with in the mobilearena, both from a security and amanagement perspective. We argue that thecurrently predominant model of perimetersecurity will not scale for future mobilebusiness applications that will requireappropriate application-level securitymechanisms to be in place.
We present a framework offeringsolutions for the development of securemobile business applications that takes intoaccount the need for strong securitycredentials, e.g. based on smart cards. Thisframework consists of software andabstractions that allow for the separation ofthe core business logic from the securitylogic in applications. Security managementinstruments in the form of enforceableenterprise policies are defined which targetthe security and trust-related deploymentand configuration of mobile devices andbusiness applications.
The presented architecture is open, in the sense that the actual mobile businessapplication can span over heterogeneousclient devices, forming a so-calledfederation.
1. Introduction
Modern infrastructures of enterprises tendto be based on a multi-tier architecture that– seen from a user’s perspective – usuallycomprises:
• a desktop tier, e.g. a web browser orother client-resident application;
• a portal, which presents to a user theenterprise resources according to thespecific role the user performs in a task-centred view;
• an application server tier, such as webapplication servers;
• a backend tier, often comprised ofdatabases or other business-specificbackend systems (e.g. in the productionprocess of a company).
Application server and backend tiers arebound together using additional enterpriseapplication integration systems, thusimplementing the actual business processes.
1.1. Security models
Enterprise information technology (IT)infrastructures are today protectedaccording to the so-called perimeter securitymodel: its principle is to implement securityat the network level using firewalls,intrusion detection systems, etc. Enterprisesturn into fortresses by building networkwalls to separate trustworthy and lesstrustworthy parts of the network; securityis managed and enforced at the networkborders.
Mobile and wireless technologies such aslaptops, PDAs, and smart phones with
opinion of the European Community. It is also the sole
responsibility of the authors and not the responsibility
of the European Community using any data that might
appear therein.
ISTR 0904.qxd 07/12/2004 14:03 Page 6
cellular and mobile network interfaces, e.g.for GSM/UMTS [23], potentially enableenterprises to let their mobile employees get access to the core informationtechnology infrastructure throughdedicated enterprise portals. Accessingcorporate resources without duplicatingthe corporate infrastructure would make itpossible to accelerate business processesand to integrate more tightly in-house andremote work, thus improving the usability,flexibility, and performance of informationsystems.
Seen from the enterprise's perspective,mobile access to networks will change thecore business processes of an enterpriseonly to a limited extent, since the actualbusiness of a company will most likely notbe affected. However, mobility support willsignificantly change the way businessprocesses are actually executed.
As a consequence of extending theenterprise perimeter to mobile devices, newthreats arise such as theft and loss ofmobile devices, wireless eavesdroppingwhich in turn might lead to leakage ofconfidential data, uncontrolled access tocorporate resources, etc. It should be notedthat the value of some business transactionscan be quite different from what is typicallyfound in business-to-consumer scenarios.Consider for example a financial controllerwho monitors key performance indicatorsof different enterprise branches –information typically considered as insiderinformation of significant value.
Compared to the overall number ofexisting business applications, only afraction of these are actually enabled formobile usage. We are convinced that one ofthe major reasons for the slow uptake ofmobile business applications is the fact thatsuitable frameworks for the development ofsecure applications still do not exist or are
not suitable for actual business needs [4].Security measures in place should be able tocope with a diverse range of securityrequirements.
1.2. Problem statement
Future mobile business applications willspan several trust domains from enterprisesto personal domains, across differentorganisations and businesses. In suchscenarios only the application will be ableto determine the security requirements thatneed to be implemented. This is very muchin contrast with the perimeter securitymodel where the network locationsdetermine whether mobile employees areallowed to enter the business domain.
Apart from the security problemsemerging with mobile usage, enterprisesmust also be able to integrate these devicesinto their IT infrastructure. Most notably,seamless solutions that build on usersworking habits and empower them withflexibility and ease-of-use should bepreferred. This also results in the followingnon-exclusive list of requirements:
• security modules in use (e.g.GSM/UMTS SIM cards [1], [2]) must beconfigurable and manageable by theenterprise itself (e.g. key management,authentication mechanisms,cryptographic algorithms);
• deployment, management, andmaintenance of secure mobile businessapplications must be as far as possibleexpressible in corporate policies;
• trustworthiness of mobile devices mustbe made accessible to businessapplications to allow for fine-grainedcontrol over the information flow withinan enterprise.
• security infrastructure in place on theclient and server must be accessible forthird-party application development.
Secure mobile business applications Thomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 7
ISTR 0904.qxd 07/12/2004 14:03 Page 7
Seen from the (usually) third-partyapplication developers’ and providers’ pointof view, additional requirements are:
• mobile business applications must beable to define their own securityrequirements in conjunction withcorporate security policies, somethingwhich is usually not possible on thenetwork level anymore;
• application development should allow forthe separation of core business logic,which implements the actual businessprocesses, and the security logic, whichdefines the security measures that mustbe enforced based on corporate policies.
1.3. Secure mobile businessapplications
Mobile devices equipped with wirelesscommunications facilities are a platform torun business applications anytime andanywhere. The term secure mobile businessapplication refers to the protection ofcritical corporate resources – data,processes and network equipment –accessed by applications deployed onmobile devices and beyond the securityperimeter of an enterprise.
Security, however, always is a termrelative to a given policy: assets are only assecure as what meets the explicitrequirements. A business model is definedby its policies and practices, which governhow assets are used, how people interact,and how processes are carried out.Applications are the way business modelsare technically implemented. They shouldtherefore reflect company policies (includingsecurity policies) through theirimplementation. Security policies clearlystate both required security services andsecurity mechanisms. The latter being thebuilding blocks that establish acorresponding standard of security.
1.4. Contributions of this work
This paper presents a framework andarchitecture for developing and deployingsecure mobile business applications. Weconcentrate on scenarios where mobileemployees require access to their owncorporate resources (business-to-employee,B2E) and to resources of business partners(B2B). Our work defines an integratedapproach for designing, integrating anddeploying secure mobile businessapplications.
The application security supportarchitecture provides the flexibility andadaptability to cope with the aboveidentified problems:
• A smart card hosted security module(Section 3.4.2) provides tamper-resistantstorage and an execution environmentfor security critical data and operations;
• Policy management (Section 3.5)supports the definition, maintenance andenforcement of corporate securitypolicies. Policies are bundled with anapplication and are pre-installed ordynamically downloaded to a device;
• As a sub-component of policymanagement, specific attributecertificates (Section 3.5.2) are employedto describe trustworthiness of mobiledevices as well as to define rights fordelegation of tasks between employees.
• Separation of business and security logicsupports deployment of applicationsirrespectively of any securityconsiderations which are dealt into thesecurity logic layer of the framework(Section 3.7).
The described framework andarchitecture have been defined, designedand implemented in the WiTness – WirelessTrust for Mobile Business – project [24]. Toour best knowledge no similar
Mobile Security
8 Information Security Technical Report. Vol. 9, No. 4
ISTR 0904.qxd 07/12/2004 14:03 Page 8
comprehensive approach such as thediscussed one exists.
1.5. Outline of paper
The following section provides additionalbackground material and basic definitions.Section 3 discusses the framework andarchitecture for implementing secure mobilebusiness applications. We argue for a strictseparation of business and security logic butalso for an integrated approach that takessecurity considerations into account from thevery beginning. The building blocks andgeneric components of our framework arediscussed. Section 4 discusses a use case thatemphasizes applicability of concepts in aspecific scenario. Before concluding thepaper we briefly compare our results torelated approaches (Section 5).
2. Federations of mobiledevices – extending thesecurity perimeter
Our proposed security framework extendssecurity features of a corporate intranet to amobile device and even further into thedomain of co-operating mobile devices.
2.1. Usage scenario – pervasivesalesperson
We consider a pervasive salesperson visitingcustomers and who enters new orders in thecorporate database; the database is locatedin the corporate domain. The mobile devicesin the salesperson’s immediate vicinity arecalled the personal domain:
• To read corporate emails, the salespersonuses a mobile phone;
• To plan forthcoming customer visits, heor she uses his or her PDA;
• To enter order data, he or she uses his orher laptop.
If a data item has been sent to a mobiledevice it is beyond the security perimeter ofthe enterprise. The challenge is to whatextent security can be enforced even underthe assumption that, as in the describedscenario, resources cannot be controlledexplicitly.
In the following sections we describe ourapproach to support application security invarious environments.
2.2. Federations of mobile devices –definition
The pervasive salesperson exampledemonstrated the advantage of exploringthe capabilities of different mobile devicesin performing business tasks. The notion ofa federation captures this aspect as well asthe co-operation of mobile devices andcorporate servers.
A federation is a combination of mobiledevices and corporate servers that executesdistributed business applications and thatoffers the following features:
• access control (i.e. authentication andauthorization), data confidentiality andintegrity as well as accountability ofcommunication events and non-repudiation of transactions areconfigured according to security policies;
• co-operation between mobile devices isconstrained by federation policies andtrust certificates;
• delegation of business tasks and dataresources between mobile devices andbetween mobile devices and corporateservers is constrained by delegationpolicies and authorization certificates.
Federations make it possible to extendthe capacity of each federated deviceincluding its deployed business applicationswith those of its federated counterparts.
Secure mobile business applications Thomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 9
ISTR 0904.qxd 07/12/2004 14:03 Page 9
For instance, using the screen of a laptopextends the display capabilities of a PDA; a laptop may extend the computingcapabilities of a cell phone, and so on.
2.3. Security and federations
By their very nature, federations of mobiledevices are more exposed to attacks thanplain mobile devices since an applicationrunning within a federation spans acrossdevices possibly owned by differentadministrations.
The enterprise must be able to implementand enforce its security policy regarding howits data are accessed by its employees and itspartners. Securing data access in afederation is achieved in two separate steps:first, the company must ensure that sensitivedata do not get disclosed in an uncontrolledfashion; second, the employee must be ableto designate used appliances in a context-dependent manner, based on his location,history, and last but not least definedpolicies.
Federating a device may increase itssecurity, and may be required with respectto authentication in the corporate policy.For instance, a user may access somespecially critical data on his or her laptoponly if he or she authenticates using afingerprint reader located on a PDA; or theuser may carry in his or her clothes a deviceproving his or her presence in a certaindistance range so that his or her mobilephone will lock if the user is too far awayfrom the device, thus reducing the risksincurred if the mobile phone is stolen.
Given the identified requirements (Section1.2) and mobile working scenarios (Section
2.1) it becomes obvious that applicationsecurity can only be orchestrated fromwithin applications themselves. Theapplication security architecture takes intoconsideration the needs for enhancedsecurity management, enabling true end-to-end security through application layersecurity, and allowing established securitymechanisms to be leveraged.
Enhanced security management isachieved by, first, a separation of businessand security logic and, second, acomprehensive security policy managementwhich includes security policy enforcementas well. Application layer security issupported end-to-end between mobiledevices and enterprise networks andbetween mobile devices used by theemployee in his or her personal domain – afederation.
3.1. Components of the WiTnessframework
This section introduces the WiTnessframework components that are the atomicsoftware parts provided by the frameworkwhich promote a (mobile) businessapplication to a secure mobile businessapplication (Figure 1).
Mobile Security
10 Information Security Technical Report. Vol. 9, No. 4
Figure 1: WiTness framework
ISTR 0904.qxd 07/12/2004 14:03 Page 10
Application management provides anenvironment for hosting the softwarecomponents of a business application whichare termed partlets in our Java™ basedframework. Application securityrequirements are expressed as securitypolicies which accompany partlets.Evaluation of policies during the executionof a partlet is done by applicationmanagement. Policies are bound to securityservices and mechanisms as available andimplemented by installed security librarieson the hosting mobile device. The selectionand instantiation of security services andmechanisms determine a partlet’s securitycontext. To a large extent, applicationsecurity logic is implemented by therespective security mechanisms of thesecurity context. Security libraries implementbasic security services and mechanisms butas well specific security services forcertificate handling and smart card access.
Multiple partlets can run in parallel andcan communicate with partlets on federateddevices or partlets in the enterprise intranet.
Federation management handles requestsfrom one partlet to federate with otherpartlets in either enterprise intranet orpersonal domain. Note that, vice versa,federation set-up requests may originatefrom other external partlets as well. Thus,federation management is in charge ofidentifying federated devices andcontrolling outgoing and incomingfederation requests.
3.2. Application management
The WiTness framework takes a policydriven approach to meet an application’ssecurity requirements. All business logic isimplemented as partlets running in theapplication execution environment calledapplication manager. The applicationmanager is the main enforcement point for
partlet related security policies as well. Itsduties encompass:
• Partlet lifecycle operations;• Dynamic addition and deletion of
partlets during runtime;• Partlet communication operations.
Partlets are accompanied by a set ofpolicies specifying the lifecycle behaviourand authorisations of this partlet such asconditions to be met before starting thepartlet or communication constraints. Theapplication manager then starts and stopsavailable partlets or dynamically downloadspartlets based on policy decisions. Sincecommunication handles in form ofconnectors (Section 3.6) are set up fromwithin the partlet and therefore in theapplication manager controlled executionspace, it is also possible to enforcecommunication related policies.
The following subsections describe indetail the relations of these applicationmanagement duties to other specializedWiTness framework components.
3.3. Federation management
A federation of mobile devices is a centrallyorganized structure that develops from thetrust assignment in the personal domain. Afederation itself is seen as a secure platformfor applications in the form of partlets.Security determination is hereby based onassigned policies regarding the differentcomponents, e.g. if the applicationmanagers on each device are able to enforceall participating partlets’ policies.
The central component receivingfederation related requests fromsurrounding devices in order to form andmaintain a federation, is called thefederation manager. Its communicatingcounterpart, the federation handler, is
Secure mobile business applications Thomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 11
ISTR 0904.qxd 07/12/2004 14:03 Page 11
available in each mobile device with aninstalled WiTness framework.
Federations are initiated by federationhandlers contacting the federation managerbased on a discovery mechanism which isspecified independently from implementednetwork layers or frameworks. The WiTnessproject implemented the frameworkspecification in different waysexperimenting with federations based onlower network layer mechanisms, e.g.UDP/IP broadcasts, and high level virtualnetworks such as Project JXTA [11].
3.4. Security libraries andmechanisms
Security in the WiTness framework isprovided from the beginning as potentiallyavailable, mostly static mechanismscollected in the so-called security library(Figure 1). Security policies state – andideally parameterize – where and how tomake use of the security mechanisms tomeet the application’s securityrequirements. A distinction is made betweendifferent kinds of security data and relatedoperations. Tokens for mobile deviceauthentication such as device certificates areless critical since these are only valid andutilized in the personal domain. They haveno impact in the enterprise domain wherethe high risk – high impact damage wouldbe inflicted. Critical data consist, forinstance, of the mobile user's credentials,and operations working on them such asdigital signatures utilizing the user's privatekey. These security properties obviouslyhave to be adequately protected in the so-called security module and will be describedseparately in the following subsection.
3.4.1. Security libraries
The security libraries (Figure 1) are presenton each device containing the static
mechanisms needed by the WiTness securityframework. These mechanisms are theessential tools to establish confidentialcommunication channels, verifyauthentication tokens, etc.
The security libraries also provide thebasic mechanisms for federations to enablethe federation manager to control theirlifecycle and constantly monitor their statethroughout their existence. The basicoperations required for these duties areoperating on certificate chains, and include,for instance, in chain verification orissuance/signing of certificates.
3.4.2. Security module and services
The security module in the WiTnesssecurity framework is assigned the crucialrole to provide a secure storage andexecution environment.
The secure and personal storage may beassured by using tamper-resistant hardwaresuch as smart cards. Security critical data,e.g. user credentials used for authenticationor associated administrative data such as achain of trusted root certificates, are storedin the smart card (Figure 2). The smart cardalso provides a secure executionenvironment, offering security services tothe federated devices. These securityservices are actively answering to requestsfrom the federated devices. They herebyprovide a protective layer between thesecured data and the outside world of thesecurity module. In this manner, theprotected data are never exposed outside ofthe security module.
Since the security module deals withcritical user data, there is always onesecurity module present per federation ofmobile devices. The security module isneeded throughout the federation's lifetime.Every device which performs validation of a
Mobile Security
12 Information Security Technical Report. Vol. 9, No. 4
ISTR 0904.qxd 07/12/2004 14:03 Page 12
certificate needs access to such services tovalidate the certification authority (CA)against the chain of trusted root certificatesstored inside the security module.
3.5. Security Policies
Security policies are the rules for creating amobile business application’s securitycontext, and are defined during applicationdevelopment and integration process.Within the WiTness framework (Figure 1)they are bundled with an application orpartlet, when the partlet is installed in thecorporate network and on mobile devices ordynamically downloaded to a device after itwas issued.
Basically, policies are concerned with:
Access control: the corporate servermust verify that resources are accessed onlyby authorized users. It can be based ondifferent types of credentials such asencrypted password, fingerprint, challenge-response (private key), authorizationcertificates, etc. in combination with accesscontrol lists. Policies that restrict access areprimarily specified in the corporate domain,although its enforcement is distributedbetween mobile devices.
Communications security: the corporateserver must maintain a securecommunication link with its clients. Itdefines the type of security properties(integrity, confidentiality, algorithm, keysize) that have to be negotiated forcommunication between devices.
Compliance with these properties isenforced both in the corporate domain aswell as in the personal domain.
Device trust: if and how data aredistributed between members of afederation depends on whether a device canbe trusted to execute a given operation orhow data and code have to be pre-processedbefore being given to the members of afederation. However, such a process isrestricted by the computational capabilitiesof a device, criticality of data (e.g. publicvs. confidential), as well as the trust levelthat can be assumed. Although such policiesare basically set forth in the corporatedomain they have to be enforced onfederated devices themselves.
Overall, however, one has to keep inmind that security and trust requirementsmay be specific for an application. Theyare, in general, hard-coded when theapplication is developed. For example, anapplication requiring non-repudiation orfair exchange will have to be developed withthose features included at the places wherethey are needed. Such security properties donot characterize an application but are apart of its logic: a non-repudiation propertymay not apply to an application while it canindeed apply to a message origin. Policiesthat go with such requirements are enforcedthrough the use of specific code dispersed inthe application. This code may either beprogrammed in an ad hoc way, using pre-determined mechanisms available in securitylibraries, or be automatically generated inthe corporate domain, before distributing
Secure mobile business applications Thomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 13
Figure 2: Security module – data and operation
ISTR 0904.qxd 07/12/2004 14:03 Page 13
the application. The latter approach therebypotentially permits retrofitting legacyapplication code, and may be enabled byuse of aspect oriented programming [7].
3.5.1. Automating security policies
The WiTness framework offers four typesof templates for automating securitypolicies, namely authorization,configuration, delegation and federation(Figure 3). The latter three types belong tothe core of the WiTness framework;however, we include the authorizationpolicies for completeness.
Authorization policies typically existwithin a corporate network and control theaccess to resources as well as the conditionfor a secure and trusted exchange of theseresources within the network (corporateand personal domain). The configurationpolicies are derivatives of the authorizationpolicies. The framework specifies adelegation policy that states the rules beforea task can be delegated between personaldomains of employees. The frameworkspecifies a federation policy for providing
assertions regarding the validity of devicesto be included in a federation. Trustcertificates are the containers that storeinformation on devices which is thenevaluated against federation policies.
The above described policies define ahierarchy as shown in Figure 3. At the top,the authorization policies define the rulesapplicable in the corporate domain.Configuration policies are defined such thatthey provide evidence that the fulfilment ofthe configuration policies implies thefulfilment of the authorization policies.Configuration policies are refined intodelegation and federation policies. This
refinement, however, must preserve theconfiguration policies in the sense that theabove mentioned implication, i.e.configuration policies implies authorizationpolicies, still holds.
3.5.2. Attribute certificates
Enforcement of security policies related toaccess control is based on the validation ofchains of authorization certificates. Theenforcement of policies related to device
Mobile Security
14 Information Security Technical Report. Vol. 9, No. 4
Figure 3: Security policy types
ISTR 0904.qxd 07/12/2004 14:03 Page 14
trust is based on the validation of chains oftrust certificates.
Authorization certificates are bound toemployees. They specify and determine therole of an employee and his or her rights.For instance, an employee in the role of asales department manager has the right toaccess the order database, to performapproval of orders and to revise budgetfigures. The sales manager may also beentitled to delegate certain tasks, e.g. thetask of approving orders.
Trust certificates are assigned to devices.They provide evidence on thetrustworthiness of devices. We can think ofa situation where secret data should only beprocessed on devices that come from theemployee’s company. Before delegation of atask to another device takes place, thedevice’s trust certificate is evaluated. If thecertificate proves that the device is ownedby the company, the application task anddata can be delegated and are transferred tothe device.
Additionally, co-operating companiesmay mutually agree to maintain anappropriate security and trust level on theirdevices. Then some tasks and data may beshared among devices that are owned bydifferent companies. All this can beexpressed respectively by attributecertificates and delegation and federationpolicies.
3.5.3. Enforcement of policies
For federation policies, first the scope offederative devices is specified which mightbe any device in the personal domain, anydevice in another employee’s personaldomain, or no restriction applies. Second,the assertions of a federation policy providedetails on the utilities and resources that areused for validating the device’s scope.
Whenever an employee attempts tofederate mobile devices in order to transferapplication tasks or data, e.g. transfersconfidential order information from anemail attachment on a mobile phone to alaptop, the WiTness framework checks thefederation policy associated with the task; itretrieves the mobile device’s trust certificateand performs the mentioned validation(Figure 4). Upon successful validation ofpolicies and certificates, the applicationtask can be transferred to the federateddevice for execution. [26] discusses thisexample in more detail. The validation ofdelegation policies is performed in a similarway, but additionally makes use ofauthorization certificates.
3.6. Connector
The connector is a framework componentfacilitating an abstraction from differentnetwork bearers for business applications.
Secure mobile business applicationsThomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 15
Figure 4: Policy enforcement – Federation policy and trustcertificate
ISTR 0904.qxd 07/12/2004 14:03 Page 15
A connector is always used as acommunication endpoint within federatedsecure mobile business applications. Theadvantage for application design anddevelopment is clearly that specialproperties of network bearers used tocommunicate in a federation are hiddenfrom the application logic. Regardless ofthe bearer, e.g. Bluetooth [3] or WirelessLAN [14], an application always uses thesame communication methods offered bythe connector.
As the dedicated framework componentfor communication handling, a connectoralso is the ideal enforcement point forsecurity policies regarding communicationsecurity. Communication security policiesstate certain requirements aboutcommunication security which have to befulfilled in order to establish acommunication channel betweenapplications.
The instantiation of a connector isorchestrated by security logic, ultimately inthe environment controlled by theapplication manager. Therefore, theapplication manager is still able to controlcommunication and more importantly, isstill able to override policies which forbidcertain types of communication.
3.7. Development of the framework
The modular structure of the WiTnessapplication framework supports severallevels of separation of concerns. First,separation of business and security logic,which is further discussed in Section [4].Second, the framework separatesmechanism definition from itsparameterization during applicationdevelopment as shown in Figure 5. For theframework, this separation meansintroducing a possibility to add, update oraugment additional functionality by adding,updating or augmenting respectiveproviders, i.e. to centrally offer frequentlyused security mechanisms as well as toadapt existing security policies and theirenforcement procedures. A new securitymechanism is simply supported by installingits respective implementation in the securitylibrary. To use the new feature, one maychange a given policy, add a constraint, andbind the respective security providerinstalled in the previous step. The updatedpolicy is sent to specific mobile devices,installation is done instantaneously, and thepolicy, and thus the new security feature,becomes active as soon as the bundledpartlet is executed.
4. Use case – secure mobileworkflow
Typically, applications are designed andimplemented with only functionality (i.e.business logic) in mind but it would oftenbe advantageous to separate different
Mobile Security
16 Information Security Technical Report. Vol. 9, No. 4
Figure 5: WiTness framework development – separation of concern
ISTR 0904.qxd 07/12/2004 14:03 Page 16
business logic segments, serving differentpurposes. The WiTness frameworkintroduces a solution for the separation ofbusiness and security logic. This separationof concerns brings an immediate advantagefor application developers: they can solelyconcentrate on business logic functionality.
We have used the WiTness framework toimplement a secure mobile workflowapplication which served to prove how toseparate business and security logic; theformer is encapsulated in specific partletsinstalled on the client device as well as onthe server, while the latter is centralized incorporate defined security policy files.
The workflow models a simpleauthorization process. An employee submitsan authorization request which is stored ina database (Figure 6). Under control of amobile workflow manager the authorizationrequest is passed through a sequence ofapproval steps. At each step, a manager mayeither approve or reject a request. Rejectionof a request immediately terminates theworkflow; otherwise the workflowterminates if the top manager in the
hierarchy approves the authorizationrequest.
The instantiation of the WiTnessframework for the specific application is asfollows:
• Application management as an executionenvironment for either client as well asfor CAP (corporate access point) partlet;
• Security libraries for encryption,decryption, and data integrity;
• Certificate handling for access tocertificates – public key as well as CAcertificates;
• Smart card access for handling of smartcard operation requests (client site only);and
• Network control, which provides accessto lower layer communication handlers(such as sockets [18]).
Enterprise security policies require thatthe client and the server mutuallyauthenticate. These policies also requirethat exchange of data is protected forconfidentiality and data integrity. Approvalof an authorization request is performed by
Secure mobile business applicationsThomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 17
Figure 6: Mobile workflow – Mobile equipment and backend
ISTR 0904.qxd 07/12/2004 14:03 Page 17
digitally signing the authorization request.We build upon security mechanismsavailable which are supported on client aswell as corporate side, as detailed below.
4.1. Mobile equipment and clientsoftware
The hardware platform in the personaldomain consists of a laptop equipped witha smart card reader facilitating low levelaccess to the security module implementedas WIM smart card [12]. The WIM smartcard provides the secure environment for theuser’s private key and can perform thedigital signature operation.
The application typically runs in aWindows® environment because of a nativelibrary containing the methods for smartcard access. Furthermore, JDK 1.4.2 [20] isused. Part of the security library is providedby a Bouncy Castle Java® CryptographicExtension (JCE) crypto provider [8]. It iscomplemented with the necessary WiTnessextensions to make use of the smart cardfunctionality from within a Java Virtualmachine (JVM).
The application itself consists of apartlet implementing the functionality forthe client application creating authorizationrequests and for the workflow inbox whereall processed and pending workflow itemsare shown. The partlet is executed in theWiTness framework context based on asmall application server deployed on themobile device itself, called Jetty [6].
4.2. Application server andcorporate access point
The corporate domain consists of twocomponents, an application server hostingthe corporate access point (CAP) and theinformation provider system (Figure 6), i.e.a database. The CAP is implemented as a
partlet and is the endpoint facing partletsfrom the personal domain.
The CAP is responsible for securityfunctionality on the application layer. Anycommunication channel to and from thecorporate domain firstly requires mutualauthentication; and secondly a session iscreated and secured by a session key (see[17] for an in-depth discussion ofcryptographic methods and networksecurity). The endpoints of thiscommunication channel are each locatedwithin the WiTness secure mobileapplication framework, i.e. within a partlet.
The CAP partlet implementation isexecuted as a standalone Java applicationimplementing the security logic and usingits own application management
The so-called mobile workflow managerincludes an implementation of the workflowmodel (the workflow steps) and keeps trackof all the workflow states. The mobileworkflow manager is designed withflexibility in mind not only regardingcommunication with different personaldomain connections in mind, but also withdifferent information provider systems. Inthis case, the mobile workflow manageruses a relational database [9] withoutintegrated application logic as itsinformation provider system.
5. Related work
5.1. SIM cards as ubiquitous crypto-processors
GSM SIM cards aim at protecting mobilenetwork operators and belong to them. Thewidespread availability of Java-enabled SIMcards opens this model by allowing theexecution of personalized applications in asecure environment. Numerous projects andapplications are based on those new
Mobile Security
18 Information Security Technical Report. Vol. 9, No. 4
ISTR 0904.qxd 07/12/2004 14:03 Page 18
features. It is worth noting that differentproposals like WLAN-SIM [27], EAP/SIM[5], or SecurID [15] use SIM cards to secureuser or corporate assets. The use of smartcards as integrated cryptographicprocessors in business applications, such asNetscape [10], is becoming increasinglycommon., but although their acceptance forsuch use can be observed, the mainhindrance to their widespread use is thecost or unavailability of readers; theWiTness approach makes it possible toforego this issue thanks to the federationconcept.
5.2. Secure platform for mobileapplications
It is becoming common to developapplications to be deployed in mobileenvironments. Java 2 Micro Edition (J2ME)[19] has been proposed to write and todeploy applications in mobile environments,although it makes little account of security,especially from a distributed applicationperspective. The Small TerminalInteroperability Platform (STIP) project [21]provides a framework for writing secureapplications on mobile devices with limitedresources such as payphones, parkingmeters, or vending machines. WiTness goesone step beyond by securing a distributedplatform that takes federations into accountand by extending the scope to mobilebusiness applications.
5.3. Trust evaluation of surroundingdevices
The execution of mobile code must besecured, both in terms of integrity ofexecution as well as in terms ofconfidentiality of execution. Theoreticalwork has shown that results can be achievedwithout depending on a reliableenvironment [15]. However, thoseapproaches are computationally expensive
and restricted to specific cases (e.g.protecting Boolean circuits). A morerealistic approach is to rely on some trust inthe execution environment. It is possible todistribute some secure hardware that willrun the mobile code, e.g. SIM cards orsecure coprocessors [25]. Alternately, it ispossible to certify some environment so thatone can check that it is secure to upload apiece of code, for instance, based on TCG[22]. In comparison, the approach taken inWiTness differs by three features: (1) thesecure hardware modules used are SIMs orUSIMs, which are ubiquitously available inmost mobile terminals, unlike dedicatedcoprocessors. (2) Secure hardware modulesneed not be neutral, which may implycomplex certification processes with acentral authority. Instead the secure modulecan be owned and managed by the companythat equips its mobile workforce itself. (3)WiTness focuses on interactions with otherentities, not on the separation from otherentities, i.e. this approach makes pervasivescenarios more explicit.
5.4. Security policies for mobileapplications
Generic Policy Languages such as Ponder[13] are sometimes replaced by dedicatedpolicy languages that are simpler but lessflexible. Some policy languages arededicated to security (RBAC [16]). Defininga policy language dedicated to security in amobile context is challenging. WiTness’policy language is based on Ponder.
6. Conclusion
The number of mobile employees is everincreasing and the demand for supportingthem with access to corporate networks isone that must be met. We presented anddiscussed an architecture and frameworkthat provides a comprehensive andevolutionary approach for the
Secure mobile business applicationsThomas Walter et al
Information Security Technical Report. Vol. 9, No. 4 19
ISTR 0904.qxd 07/12/2004 14:03 Page 19
implementation of secure mobile businessapplications. The architecture andframework allows for an integration ofexisting technologies (if useful, e.g. Bouncycastle Java Cryptographic Extension) aswell as for their complementation (ifrequired – WiTness security module);overall it consists in an open architectureand framework based on standards (e.g.WIM smart card specification).
As was proven by the implementation ofa use case, the WiTness framework providesthe flexibility that only parts of its elementsmay be employed in a real implementation.
We regard as a particularly importantcontribution of our framework that we haveachieved a separation of concerns thatsupports the separation of business andsecurity logic. It allows for a dynamicupdate of security mechanisms without theneed to re-install the whole businessapplication.
As further work we regard as mostimportant the generalization of thearchitecture and framework so that otherbusiness application implementationparadigms can be supported.
Acknowledgements
We would like to thank our partners in theWiTness project for fruitful discussions andcontributions to the presented framework.Special thanks go to Laurent Gomez, CedricHébert, Lars Brückner, and Marco Voss fortheir major contribution to the frameworkimplementation.
