runtime adaptive multi-factor authentication for mobile devices

Runtime adaptivemulti-factor authenticationfor mobile devices

P. C. CastroJ. W. Ligman

M. PistoiaJ. Ponzo

G. S. ThomasU. Topkara

The Runtime Adaptive Multi-factor authentication ENvironment(RAMEN) is a client and server-side framework that providesmulti-factor authentication policy enforcement for mobile devicesrunning iOSA and AndroidA. On the client side, RAMEN uses asecurity manager that can intercept network calls and forward themfor secure authentication to a server-side proxy. The server-sideproxy contains a dynamic policy engine that can be configured tochoose between different authentication methods depending on themobile context. RAMEN is an extensible framework that hasinterfaces to plug in different authentication methods. We describethe policy model and implementation of RAMEN. We show thevalue of RAMEN to developers through an implementation oflocation-aware security policies that can be set up to enforcesecurity zones that relax or enhance security requirementsfor different applications.

IntroductionBuilt-in authentication schemes for mobile devices typicallyrely on an alphanumeric password. However, securitypolicies that mandate device-wide locking and long textpasswords can frustrate users [1]. Platform vendors areresponding by offering alternative authentication methodsbased on gestures [2], pictures [3], and biometrics [4].This allows for the possibility of context-based multi-factorauthentication, where a security policy can be sensitiveto the dynamic usage of the device. For example, facerecognition methods may perform well in brightly litenvironments but perform poorly when it is dark. For darkenvironments, it might be more appropriate to requirespeech-based authentication. Learning techniques couldbe used to model user behavior, and custom securitypolicies can automatically be crafted for individual users.We take a broad view of multi-factor authentication toinclude the combination of multiple authentication methodsand contextual information to better establish the identity

of the user. Given the high diversity of mobile usagepatterns [5], we are interested in a framework that canflexibly integrate multiple authentication schemes anddynamically adapt the authentication scheme for each user.This would allow highly personalized authentication policiesthat can be used for mobile applications employingcentralized or de-centralized authentication administration.In this paper, we present the Runtime Adaptive

Multi-factor authentication ENvironment (RAMEN) formobile devices. Our initial target audience is mobileapplication developers, such as users of IBM Worklight**[6], who develop mobile applications that connect to variouscloud-based resources and desire a flexible, multi-factorauthentication layer. Current popular mobile platformssuch as iOS** and Android** do not provide multi-factorauthentication out of the box. The RAMEN client-sidelibraries extend these platforms to enable context-awaremulti-factor authentication policies that work in conjunctionwith a policy enforcement server. RAMEN is designed tobe easily embedded in individual applications to providefine-grained management authentication policies and iseasily deployed on mobile platforms such as iOS thatrequire strong isolation between applications and disallowbackground processing [7]. This allows for authenticationpolicies that avoid device-wide locking and can be tailoredfor specific applications.

�Copyright 2013 by International Business Machines Corporation. Copying in printed form for private use is permitted without payment of royalty provided that (1) each reproduction is done withoutalteration and (2) the Journal reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied by any means or distributed

royalty free without further permission by computer-based and other information-service systems. Permission to republish any other portion of this paper must be obtained from the Editor.

P. C. CASTRO ET AL. 8 : 1IBM J. RES. & DEV. VOL. 57 NO. 6 PAPER 8 NOVEMBER/DECEMBER 2013

0018-8646/13 B 2013 IBM

Digital Object Identifier: 10.1147/JRD.2013.2281123

RAMEN provides the following security extensions formobile authentication:

• Runtime adaptationVRAMEN can be used to craftmobile security policies that adapt at runtime to providebetter usability. This runtime adaptation can take intoaccount a user’s behavior and select an authenticationmethod that is tailored for that user for a givensituation.

• ExtensibilityVRAMEN provides a plug-in architecturefor adding new authentication methods as part of thesecurity policy.

• EmbeddableVClient-side libraries in RAMEN areportable and have a very light footprint for iOS andAndroid devices. Mobile app developers can easilyinclude the RAMEN libraries during development oftheir application or use code injection to enhance existingapplications with RAMEN capabilities.

RAMEN’s contribution is a lightweight, flexible,multi-factor authentication layer that is easy to embedin Bmobile þ cloud[ applications and can be extended tosupport context-aware, multi-factor authentication policies.Our focus is on providing flexible administration policies,and we envision RAMEN as just one part of a complete

security solution; we do not focus on providing a trustedcomputing base for current mobile platforms, althoughclearly RAMEN, as well as other authenticationarchitectures, would benefit from work in this area.

RAMEN policy modelWe designed RAMEN to work in the context ofmobile þ cloud scenarios, where mobile clients requireaccess to protected services in the network. In Figure 1,mobile clients communicate with the RAMEN securegateway to enforce authentication. The RAMEN securegateway acts as a policy enforcement point that specifieshow authentication should be adapted to different usagecontexts. In our usage model, this gateway is centrallyadministered by the enterprise, which determinesthe authentication methods allowable in multi-factorauthentication policies. For example, an administratorcould use RAMEN to allow location-aware authenticationpolicies in addition to password and PIN protection.Users, devices, and applications have unique identifiers.

When an application needs to access a resource [dataor service application programming interface (API)],the client application uses the RAMEN frameworkto send an authentication request to the secure gateway.The gateway hosts policy declarations and the policy

Figure 1

Architecture of the RAMEN authentication framework.

8 : 2 P. C. CASTRO ET AL. IBM J. RES. & DEV. VOL. 57 NO. 6 PAPER 8 NOVEMBER/DECEMBER 2013

evaluation engine. It also provides an extensible interfacefor implementations of authentication methods, as wellas a transport architecture to communicate securelywith third-party services. If the gateway processes theauthentication request and approves the application, it candirect the application to talk directly to the third-party serviceif needed, or it can act as a reverse proxy and broker allrequests on behalf of the application.

Security zonesTraditional network security policies define the notionof zones to establish certain levels of protection [8].Messages originating in one network zone can flow freelyto destinations in that zone, but traffic between zones isrestricted and only allowed through well-defined securityinterfaces. In the RAMEN authentication policy model,the concept of a security zone is also fundamental butnot limited to network definitions. Informally, a zone inRAMEN defines an area that is subject to authenticationrequirements. When users cross between zones, they mustfulfill the authentication requirements for that zone. Zoneis an abstract concept and informally refers to the contextof the application, which in RAMEN is defined by a set ofattribute value pairs.We define the components of a zone as follows:

• Zone labelVA system unique identifier used to referencethe zone by name in a security policy. In RAMEN, thezone label is a text string that is an arbitrary label forthe zone.

• Zone contextVA specification of the zone boundaries asa set of constraints. In RAMEN, constraints are Booleanexpressions that denote some attribute of the devicecontext such as location, network, and load. RAMENuses the zone context to determine if the user falls underthe zone’s security policy. For example, we enablelocation-aware security with zones based on the physicallocation of the device. The constraint is based ona bounding box defined by latitude and longitudecoordinates. However, this context is not tied to location,and could specify other conditions where the zoneapplies, e.g., it could indicate an emergency such asBfire = true.[

• Resource identifiersVA filter that can be mapped toa URL or a set of URLs that defines what resourcesthe zone is protecting. RAMEN assumes that allprotected resources, both local to the device, and onthe network, have URLs can act as system uniqueidentifiers for data and services. The RAMEN evaluationengine uses the resource identifier to determine whethera URL is covered in the zone. For example, ourcurrent implementation of RAMEN uses regularexpressions as resource identifiers in the zonespecification.

• Identity constraintsVConstraints that define a set ofauthentication methods required by a zone. These consistof individual constraint items, each representing anatomic unit of evaluation. A constraint item is thetuple hL;Pi, where L is a system unique label and Pis a set of parameters that must be sent to the evaluationengine for authentication. RAMEN maps L to animplementation of an evaluation unit. For example,an identity constraint that requires username andpassword would look like S ¼ fh}userid}; }userid ¼jsmith}i; h}password}; }password ¼ foobar}ig. Theset S contains two constraint items, one that passesa label Buserid[ and parameter }userid ¼ jsmith} to theRAMEN evaluation engine, and another constraint forlabel Bpassword[ and parameters }password ¼ foobar}.The evaluation engine instantiates Bresolvers[ forBuserid[ and Blocation[ types that know how toprocess the constraint types.

In the current RAMEN implementation, userid genericallyrepresents the set of possible ways to identify a user, soit could also correspond to known group IDs or roles.By default, the mobile device always has to specify auserid as part of its credentials, which differs from somecontext-aware authentication schemes that may authenticatea device purely on context, e.g., its proximity to an RFIDtag [9, 10].Figure 2 shows zones based on a user’s physical location.

The figure shows three zones: home, office, and city. Eachzone has its own authentication requirements. At home,the user is subject to a default authentication policy whichrequires a long password. The office zone has relaxedauthentication requirements and the user only needs to entera four-digit PIN. The city zone is the least secure and requiresthe most stringent authentication requirements, e.g., a longpassword and a biometric.RAMEN defines zone context and identity constraints as

separate entities in the policy model for clarity. However,in practice, detecting if a mobile device is in a zone andalso authenticating the user identity constraints can be donetogether. The current implementation of RAMEN uses thesame resolvers for both zone context and identity constraints.From the perspective of evaluation, RAMEN will firstattempt to resolve the constraints in the zone context todetermine if the policy applies, then evaluate the constraintsin the identity constraint set for authentication.We present two examples of specifying a zone policy

in RAMEN:

Example 1. In this example, we create a policy thatstates that the user has to enter a PIN to accessthe URL http://protected.mycompany.com when hisIP address originates from a restricted range ofIP addresses (10.0.1.1 to 10.0.1.10).


zoneID ¼ ‘‘protectMyCompany’’;zoneContext ¼ ‘‘^10 n :0 n :1 n :ð½1� 9� j 10Þ$’’;resources¼ ‘‘http:==protected:mycompany:com;constraints ¼ ‘‘h‘‘PIN’’; ‘‘pin ¼ ’’i’’

In this example, the zone identifier is just the labelBprotectMyCompany[, which must be unique in the system.The zoneContext, which defines the boundaries of thezone, is expressed using a regular expression which filtersthe given range of IP addresses. The protected resourceis a URL for a protected company website. The policyindicates that a userid and PIN combination is necessaryto authenticate for this resource. The userid is inherent in anypolicy specification so does not need to be part of the identityconstraints. Note that the label PIN for the identity usesthe empty string value. This indicates that the PIN valuerequired for that userid is specified outside the policy file(usually in a database) by a policy resolver component.

Example 2. In this example, we create a policy set thatadapts to the user’s location. The policy states that

the user can enter a PIN to access the protectedresource when she is in the office. In any otherlocation, she has to enter a password and a PIN.

PolicyItem1¼GzoneId¼ ‘‘protectMyCompany2’’;zoneContext¼ ‘‘location:42:642041;�72:443848; 41:483891;�70:213623’’resources¼‘‘http:==protected:mycompany:com’’;constraints ¼ ‘‘h‘‘PIN’’; ‘‘pin ¼ ’’ ’’i

PolicyItem2 ¼ GzoneId ¼ ‘‘default’’;zoneContext ¼ ‘‘ ’’;resources¼‘‘http:==protected:mycompany:com’’;constraints ¼ ‘‘h‘‘Password’’; ‘‘password ¼ ’’i;h‘‘PIN’’; ‘‘pin ¼ ’’i’’

In this example, we create two policy items. Thefirst policy item enforces the constraint PIN for thezoneContext constraint located in Cambridge, Massachusetts(representing the office). The location constraint specifies abounding box in latitude and longitude points. The second

Figure 2

Zones based on location context in RAMEN. Each zone defines its own authentication requirements.


policy item has an empty zone context, which the policyengine interprets to mean Balways true.[ There are twoconstraints for policy item 2, which enforce password andPIN authentication. In this example, we assume that thepolicy engine will check the policy items sequentially andonly enforce the first policy item that applies. If the user isin Cambridge, then the evaluation will enforce the PINconstraint. Otherwise, it will enforce the second policy itemrequiring a PIN and password. Although we do not do thisin our current implementation, an alternative is to enforcethe identity constraints of all zones that apply within a policyset. In this case, it would be necessary to at least removeredundant constraints in each of the applicable policy items.It may potentially be better to treat identity constraintsabstractly as providers of different levels of protection.The Bunion[ of these abstract constraints is a set ofconstraints that provides an equivalent level of protection,but may contain fewer members.

Policy file declarationsIn this section, we describe how to declare policies inRAMEN. The policy specification complements the RAMENsecure gateway protocol which is based on the exchangeof JavaScript** Object Notation (JSON) [11] messageswith the mobile client. Figure 3 shows an examplepolicy set in RAMEN. In the figure, the policySetNameattribute has a value BlocationAware[, which is the zoneidentifier. The policySet defines a Bmode[, which indicateshow the evaluation engine should evaluate the policyitems. The mode is currently set to BatMost1[, whichindicates that the evaluation engine should only enforcethe identity constraints of one zone. Other modes, suchas BatMostN[ and Ball[, can be used to indicate that theclient can be in N or all zones, respectively, if it matchesthe zone context.

The policy set has three policy items that define three zonecontexts that are all defined by physical location. As notedearlier, the policy combines zone context and constraintsbecause the evaluation engine does not make a distinctionbetween the two. Constraints in the policy file are attributevalue pairs, where the attribute name should be a uniquelabel representing a constraint type. The attribute value canhave a value, as in the case of Blocation[, or it can be anempty string. In the case of the latter, this indicates that theconstraint should be resolved using values retrieved fromoutside the policy declaration. The details on retrieval areleft to the developer of the authentication method.In Figure 3, the security administrator can list the zone

context and constraints in any order, but ideally the zonecontext would come before the constraints since the engineresolves the constraints in the order they are listed in thepolicy file. This is not necessarily fixed, however. Oneoptimization is to list the constraints in the order ofincreasing cost to obtain. The RAMEN secure gateway relieson a negotiation style protocol with the mobile client toobtain values (e.g., the current location of the device) andtries to economize the resources used by the client to obtainthese values. By asking for Bcheaper[ values first, clientsdo not have to waste resources and needlessly prompt usersfor input. For example, the client should not have to promptthe user for a long password if that constraint is locationspecific. Rather, the policy should determine location first.As an extension to the current model in RAMEN,

we can employ an indexing scheme of zone context tospeed up policy evaluation. The type of index used is highlydependent on the content of the zone constraints. Forexample, location-aware authentication is an active areaof research [10, 12–14]. Zones based on location can bestructured hierarchically. Continuous location models such asthose based on latitude and longitude, would benefit from

Figure 3

Example declaration of policy set in JavaScript Object Notation (JSON).


spatial indices, such as R�-trees [15], which can quicklydetermine what zones are currently valid for a given GPSpoint. Other types of location, such as zones based ondiscrete labels common in proximity schemes (e.g.,location ¼ }office}, Bfloor 1[,Bfire escape[) could also beindexed, although this requires additional knowledge aboutthe relationship between the discrete, named locations.The current implementation of RAMEN uses the

BatMost1[ mode for evaluating policy items, which allows itto evaluate each zone in a policy set sequentially. BatMost1[means the only the first constraint will be enforced. Notethat the policy set in Figure 3 includes one policy item thatmatches all resources protected by a password. This policy

item will be evaluated if the preceding policy items inthe declaration are not valid for the current context. Thisguarantees that the RAMEN secure gateway will enforce atleast the Bdefault[ policy item, that is, the device needs toprovide a password for any resource that does not pass theBmycompany[ filter stated in the previous policy items.We plan to investigate power-aware multi-factor

authentication strategies and indexing schemes for zonesas part of our ongoing research.

Evaluation algorithmFigure 4 shows simplified Java**-styled code that illustratesthe selection algorithm used for BatMost1[ evaluation of a

Figure 4

Java-styled code for the atMost1 policy evaluation mode.


policy set. The algorithm is straightforward; it first retrievesthe policy set mapped to a particular user. For eachpolicy item in the policy set, it extracts the constraintsrepresenting zone context and identity constraints and sendsindividual constraints to a PolicyConstraintResolver. ThePolicyConstraintResolver is an interface a developer uses tointegrate an authentication method with the RAMEN policyevaluation engine. The evaluation engine uses constraintlabels to instantiate specific PolicyConstraintResolverimplementations. The function assumes there are threeresolver implementations using the reserved namesBpassword[, Bpin[, and Blocation[. As mentioned previously,the names of constraints in the policy file should beunique labels that the policy engine can map to specificimplementations of constraint resolvers for that type. Forexample, the Blocation[ resolver maps to a constraint resolverimplementation that treats the location parameters in thepolicy set declaration as the definition of a bounding box.Mapping between constraint attribute names and resolverimplementations is done using a configuration file forthe RAMEN secure gateway. The resolveConstraintfunction in Figure 4 includes an assignment of the resolverimplementation to a resolver registry if the label is notBpassword[, Bpin[, or Blocation[. This is to highlightthat the actual implementation of the RAMEN policyevaluation engine uses a registry to map the labels andimplementations. These mappings can be modified atruntime and extended as new authentication methodsbecome available.

RAMEN client and server implementationThe four major system components of RAMEN are shownin Figure 5. In the figure, client applications are installedon the mobile device with the RAMEN security managerembedded in the application. The RAMEN security manager

communicates with the RAMEN secure gateway. TheRAMEN secure gateway uses a plug-in interface to hostimplementations of various authentication methods.The RAMEN gateway can act as a standalone policyenforcement point. In this role, the gateway authenticatesclient authorization requests using a negotiation styleprotocol. The RAMEN gateway can also act as a reverseproxy to broker communications between the mobileclient and backed services. In the role, the RAMEN securegateway has the ability to perform authentication withOpen Authentication (OAuth) [16] compatible backendservices, or can be the authentication manager for backendservices that have no built-in authentication API.Figure 5 shows the client-side tiers in the RAMEN

architecture. Mobile clients have web applications whichrun in a mobile browser, native applications built usinga platform specific language like Objective-C or Java,or hybrid apps, which use web programming models thata hybrid layer extends to allow access to native platformresources such as the device camera of GPS. RAMENabstractly provides a security manager on top of any securityservices provided by the platform. This is only an abstractionsince restrictions on mobile platforms may not allow oneto install a security manager as a platform-level service.For example, iOS has strict isolation requirements forapplications and only allows limited inter-applicationcommunication [7]. Most background processing is alsorestricted. Although Bjail breaking[ or Brooting[ the mobiledevice would allow RAMEN to get around these restrictions,this removes any security guarantees provided by theplatform. Instead, as shown in Figure 5, each typeof application has code embedded in it that provides thefunctions of the RAMEN security manager. While thispotentially means that each application has its own copyof the security manager library, the library is small in

Figure 5

RAMEN client and server tiers.


practice. The RAMEN client bytecode library on Androidis 63 kb, while the iOS framework is 134 kb.From a language standpoint, the security manager is an

object that applications can use to obtain additionalauthentication capabilities:

• Zone-based, adaptive authenticationVWhen the mobileclient accesses resources for a zone defined in the securitypolicy, the security manager intercepts the call andforwards an authentication request to the secure gateway.The security manager implements the negotiationprotocol with the RAMEN secure gateway to providethe necessary proofs of identity and zone context.If the application has previously authenticated for thatzone and that authentication is still valid, the gateway canjust approve the request. All this is transparent to theapplication, which simply requests an access tokenfor a URL from the security manager.

• Platform security integrationVThe security managerintegrates with platform security services as needed toprovide standardized security support. For example, onAndroid, the security manager utilizes the AndroidAccount Manager to store online credential information itreceives from the secure gateway. On iOS, the securitymanager can use the built-in keychain API to securelystore usernames and passwords.

• Disconnected operationVIf the client is unable to accessthe network but would like to access local resourcesthat are protected, the security manager can use theresults of previously processed authentications toauthorize access. For example, a web applicationmight want to access a list of restricted contacts in thedevice’s address book. If the application has previouslyauthenticated for this and that authentication is still valid,the security manager can authorize the access withoutneeding to consult the gateway. Clearly, this assumesthat the security manager is tamper resistant and runs insome trusted mode.

• Transparent credential renewalVThe security managerimplements the negotiation protocol with the securegateway to provide the necessary information forresolving zone context and identity constraints. Thisprotocol can be implemented directly by the application,but the security manager additionally provides atransparent credential renewal feature. Authenticationapprovals may time out after a period of time. In thiscase, the security manager can detect the expiration andautomatically send a new authentication request withcached and updated information for zone context andidentity constraints.

Web, hybrid, and native integrationIn Figure 5, the RAMEN framework supports web, hybrid,and native application integration on the client. We provide

additional information about the security manager foreach application type.

Web application supportVWe developed a set of JavaScriptlibraries that implement the protocol with the securegateway as a proof-of-concept. Given well-knownvulnerabilities of web and JavaScript code, we do notexpect these to be used in a production system. Theselibraries can perform a limited form of transparentcredential renewal by utilizing the cookie manager inthe browser to store authentication request tokens. If theauthentication cookie expires, the request automaticallyrequires re-authentication. We built the JavaScriptlibraries for experimentation and rapid prototyping.Given well-known vulnerabilities of web and JavaScriptcode, we plan on investigating alternative methodsfor supporting mobile-web applications within theRAMEN framework.

Native application supportVRAMEN supports nativeapplications using a natively implemented securitymanager supplied as a shared library. Integratingapplications with RAMEN is currently done at compiletime where we assume that the developer is deliberatelyincluding the security manager into their applicationto take advantage of the RAMEN framework. As part ofour research, we are interested in alternative integrationtechniques for RAMEN. For example, it would beuseful to have the ability to provision an applicationwith RAMEN without involving the developer of theapplication. This would allow RAMEN to be transparentlyincluded in existing applications. As part of a broaderproject, our group is currently developing a frameworkthat uses decompilation, static code analysis, and codeinjection to automatically add code enhancements toan existing mobile application. Using our tool (whichcurrently supports Android), an administrator can specifythat context-aware authentication is enabled, whichwould create a version of the mobile app that uses theRAMEN security manager.

Hybrid application supportVLike native applications,hybrid applications use a natively implemented securitymanager supplied as a shared library. Hybrid applicationsallow developers to develop applications using mostly webprogramming tools such as JavaScript and HTML/CSS,but with access to native platform resources such as thedevice camera and GPS. Currently, hybrid applications canuse emerging HTML5 support in mobile web browsers,though more commonly developers turn to hybridapplication frameworks such as PhoneGap [17]. PhoneGapuses a native web container to execute JavaScript andrender user interface elements specified in HTML/CSSbut provides an extensible bridge between JavaScriptand native APIs. Simple applications can use the APIsin PhoneGap, but the bridge has a plug-in interface for


developers to add additional native services that can beexposed with a JavaScript API. We use this plug-ininterface to add the RAMEN security manager to hybridapplications. The RAMEN plug-in supplies additionalAPIs to hybrid applications that allow it to access thesecurity manager in JavaScript. These calls are tied tothe native security manager implementation for iOSand Android. We are also investigating extending thePhoneGap container to allow monitoring of network callsoriginating from the web container. The security managercould intercept these calls to see if the call needs to beauthenticated. This redirection would be transparent to thedeveloper of the JavaScript code which has no need toknow that RAMEN is deployed.

Negotiation protocolThe security manager and RAMEN secure gateway use anegotiation protocol to perform authentication. The clientdoes not have to have knowledge about what resources areprotected, or any information regarding policies or zonecontexts. For optimizations, the client can be minimallybootstrapped with a set of URLs that fall into security zonesto help filter requests that require authentication. This is notstrictly necessary, although in the absence of the URL list,the client may have to consult the secure gateway for everyURL request.The basic protocol requires the security manager to present

various proofs of identity to the secure gateway forauthentication. The policy declaration specifies the exactproofs needed for each zone context, but the securitymanager does not need to know the details beforehand. Thesecurity manager makes an initial authorization request,sending at a minimum a userid as the first proof and therequested URL. The secure gateway evaluates the policy andthe presented proofs; it may discover that additional proofsfrom the security manager are needed. The secure gatewayinforms the security manager of the additional proofs, whichthe security manager should then provide. This negotiationcontinues until A) the security manager successfullyauthenticates with the gateway or B) the security manager’sauthentication fails to prove the user’s identity. The client canfail because the presented credentials are incorrect, e.g.,wrong userid and password combination, or the client can failbecause it is unable to provide the required proof. Forexample, if the policy requires an image of the user’sfingerprint but the device cannot supply it, it will fail toauthenticate.Figure 6 shows the message flow for the negotiation

protocol when the secure gateway is acting as a reverseproxy. The secure gateway authenticates and forwardsrequests from mobile clients to backend services providingaccess to protected resources. The flow in Figure 6implements the location- aware example outlined previously.In the example, the user must provide both a PIN and a

password to access a URL unless they are in Cambridge,Massachusetts. If the latter is true, they only need to providea PIN. The message flow depicted in the figure is as follows:

1. The security manager requests authorization to accessa URL with a given userid. The secure gateway uses theuserid to retrieve the policy set for the user and beginsconstraint resolution.

2. In this case, the policy being evaluated requires thedevice location. The secure gateway responds tothe authorization request with a Bmissing requiredfeature location.[

3. The security manager knows that the Blocation[ featureis the current latitude and longitude reading from theGPS. The security manager retrieves this location andadds it to the parameters it sends to the gateway inthe next request.

4. The secure gateway checks the policy and determines thatthe current location places the client in the BCambridge[zone. The gateway responds that BPIN[ is needed.

5. The security manager receives the response and hasregistered BPIN[ as a label for a four-digit number. Thesecurity manager uses a built-in dialog to prompt theuser for his PIN. Once the PIN is entered, the securitymanager adds it to the parameters it sends to the gatewayin the next request. Note that the new parameters includeboth the current location and the PIN.

6. The gateway checks the policy and determines that theuser is authenticated based on location, PIN, and userid.The gateway generates a signed access token and sendsthis to the client.

7. The security manager is now free to access the URL aslong as it includes the access token in the request. Inthe getURL message, the security manager includes theuserid, URL, and accessToken.

8. The secure gateway validates the token as authenticand alive and forwards the request to the protectedresource.

9. The protected resource processes the request and returnsthe response to the secure gateway. The gateway, in turn,returns the response to the mobile client.

In the current implementation of RAMEN, the accesstoken is a cookie that contains the expiration time of thetoken, the resource identifier of the zone that specifies theURLs that the token authenticates, and a message digestto ensure the validity of the token. Although the flowin Figure 6 shows the token being returned only to thesecure gateway, it is also possible to implement a singlesign-on (SSO) protocol such as Lightweight Third PartyAuthentication (LTPA) [18] where the token conforms to theLTPA token specification. Clients send LTPA tokens directlyto third-party resources that are associated with the SSOscheme enforced by the LTPA authentication server (in this


case, the secure gateway). This scheme can also be used asa proxy for authenticated requests using a protocol such asOAuth [16].The authentication protocol is stateless; the gateway

performs its policy evaluation on the basis of the informationin the most recent request. Because of this, the mobileclient can reduce the number of messages required forauthentication by caching the required features needed toauthenticate for the desired resource. For the flow in Figure 6,the client would cache that location as a required feature.Authentication can still be adaptive for cached feature sets;the stateless protocol ensures that the gateway checks thecurrently installed authentication policy set for the useridand ignores irrelevant features in an authorization request.It may be prudent to cache that location is needed and not

PIN. The client cannot know beforehand what security zoneit is in. The client application should wait until it is surethat PIN is required before prompting the user for it. In ourexample, the point is moot as the PIN is required for both of

the defined zones in the example’s policy set. However,caching must also be sensitive to a Bfreshness[ requirementfor a given context or constraint value, e.g., location-awareauthentication may only accept location coordinates takenin the last few minutes.

Security manager implementation detailsRAMEN supports iOS and Android mobile clients. From theperspective of abstractions and APIs, the implementationson both platforms are equivalent, although clearly eachplatform has different internal implementation details.Figure 7 is the state diagram for authentication used bythe client-side security manager and is common to bothiOS and Android. In the figure, the state machine is eitherauthenticated or not authenticated for a given resourceidentifier. If the security manager is not authenticated andneeds to access a protected resource, it goes into the IdentityBuilder state, where it collects the proofs needed for theauthentication. Once it assembles the proofs, it transitions

Figure 6

Negotiation protocol used for authentication in RAMEN.


to the Authentication state. In the Authentication state, theclient sends an authentication request to the secure gatewayas shown in the message flow of Figure 6. This correspondsto the dashed line from the Authentication state, whichdenotes that the client sends a message to the gateway.If the request fails, the security manager enters the

Authentication Failed and then the Not Authenticated state.If failure was due to a missing feature, the security managergoes back to the Identity Builder state to retrieve thenecessary feature. Otherwise, failed authentication goes intoa halt phase until the client attempts to re-authenticate again.If the request succeeds, the security manager enters anAuthenticated Success and then an Authenticated State.In the Authenticated state, the security manager is ableto supply an access token for subsequent requests for theresource. As previously described, the access token hasan expiration time. The security manager enters the NotAuthenticated state when the expiration time is reached.For applications that require transparent credential

renewal, the Not Authenticated state always returns to theidentity builder after the authentication expires. The securitymanager attempts to re-authenticate using updated proofs.

In the current implementation, the secure gateway treatsthe re-authentication the same as the original authentication;the gateway makes no distinction between a client initiallyauthenticating and then subsequent authentications. Aspart of our research, we are investigating alternativepolicies that take into account the relative age of anauthentication. If the user recently authenticated, then itmight be sufficient to apply a relaxed authentication policy.In a relaxed policy, the security manager would prompt are-authentication to enter a PIN rather than a full password,or the security manager could attempt to infer from contextthat the user is still in possession of the device. This isrelatively straightforward to implement in our policy model.Figure 8 shows the native APIs for Android, and the

JavaScript API used for web and hybrid applications. TheiOS API is similar to the Android API. The native APIprovides basic calls defined by the state machine to obtainan access token from RAMEN. A brief description of thecalls is as follows:

• addAccount calls will initialize the security managerin the Identity Builder state. This sets aside platform

Figure 7

Authentication state diagram for the RAMEN security manager.


specific storage for managing the communicationwith the secure gateway and storing the accesstoken.

• confirmCredentials calls place the security manager inthe Authenticating state. If the security manager returns tothe Identity Builder state because of a missing featuresresponse, the security manager can use the callbackobjects passed into this method to prompt the applicationabout the missing feature (if necessary). Note that thecallback may just launch a dialog box to collect atext credential or some other utility to perform morecomplicated data collection such as gesture or facerecognition.

• getAuthToken calls allow the application to directlyobtain the access token so it can build requests tothe secure gateway or communicate directly with athird-party service in SSO schemes. It returns nullif there is no access token, i.e., the client is notauthorized.

• invalidateToken calls are made by the applicationto remove the access token for a given resource.

The JavaScript API is similar to the native API. InJavaScript, the client can set the IP address of the secure

gateway and authenticate using the setAuthCredential call.This is mapped to the confirmCredentials call in the nativeAPI. The getAuthToken call in JavaScript returns theaccess token, like its native counterpart.It might be necessary to allow the security manager to

perform authentication to a resource on the device when thesecure gateway is not reachable in the disconnected mode;the security manager still has access to any account it storedpreviously. For example, the Android implementation ofthe security manager uses the Android Account Manager topersist this data. To allow disconnected authorization, thesecurity manager can check for the existence of an accesstoken for the local resource in the Account Manager. Ifone is present and it is valid, then the security manager canauthenticate the user. If the access token has expired, thesecurity manager can choose not to authenticate the user. Itmay be allowable to authenticate a user even if the token isexpired as long as the token does not exceed a certain age.This relaxed authentication policy is not appropriate formany enterprise applications but may be allowable if theuser’s identity can be confirmed by a local mechanism, e.g.,she recently unlocked her device. We plan on investigatingdisconnection strategies as part of our research withRAMEN.

Figure 8

Native and JavaScript APIs for the RAMEN security manager.


Secure gateway implementationFigure 9 is an overview of the implementation of theRAMEN secure gateway. We implemented the securegateway as a J2EE web application running in the ApacheTomcat Application Server (version 6 and 7). The RAMENgateway is primarily a host for the policy evaluation engine,although by necessity it contains some user registry andpolicy management support features.In the figure, the gateway has two classes of APIs.

The mobile application service API is a REST API thatimplements the server side of the negotiation protocol.The management API provides basic interfaces to registerusers and credentials with the system, as well as to specifyand update policies. The management API is mainly accessedthrough configuration files, although this can be facilitatedby a simple secure gateway console application availablethrough a standard web browser.As shown in Figure 9, the secure gateway interfaces with

a number of databases to extract user model information,credential information, and policy information. It also logstransactions in historyDB to keep track of which usershave been authenticated. The secure backend transportcomponent allows the secure gateway to proxy requests

for backend services. We use a simple transport channelthat implements OAuth to access backend services thatrequire authentication.Figure 10 illustrates the plugin architecture used by

the secure gateway that enables the addition of newauthentication methods. Currently, the plug-in architectureuses the dynamic class loading feature in Java to load newclass definitions at runtime. Developers of an authenticationmethod must implement the policy constraint resolverinterface. The code snippet in Figure 10 shows the call;the resolveConstraint method in the class should returna Boolean value given a constraint in the policy, a userobject that contains a userid (or group or role ID), and a proofclause that the client provides as part of the authenticationprotocol. For example, the Bpassword[ resolver acceptsas arguments a userid, a password contained in the proofclause, and an empty constraint object. The internalimplementation of the interface understands that thepassword for the user can be obtained using a call to theuser model database with the userid as the key (which iswhy the constraint object is empty).Optionally, developers adding an authentication method

may have to implement the FeatureReader interface as part of

Figure 9

Secure gateway architecture.


their resolver plugin. The FeatureReader interface providesa level of indirection in reading proof clauses provided bythe client in order to allow nontextual values to be passed tothe secure gateway for policy evaluation. The FeatureReadertakes as an argument the request object so it has access tothe entire HTTP request. When the resolver reads the proofclause, it can use the FeatureReader implementation toextract the request values needed for resolving the clauseand the constraint.As an example of using a FeatureReader, a biometric

authentication method may store feature vectors in a customHTTP header. During the negotiation protocol, the servercan receive a request with the feature vectors and usethe FeatureReader to extract the vectors from the customHTTP header.

Security analysisOur implementation uses ideas borrowed from OAuth 1.0to reduce the attack surface of the RAMEN architecture.Fundamentally, the RAMEN protocol relies on a client tokento prove it is currently authenticated for every request to aprotected resource. To prevent well-known attacks such asBman-in-middle,[ we require Secure Socket Layer (SSL)

communication between the RAMEN gateway and the client.We have also experimented with message authenticationcodes similar to those used in OAuth 1.0 so SSL can beavoided. RAMEN does not explicitly protect against replayattacks and instead relies on the client to protect the token.However, the token has an expiry time whose value canbe determined by the expected frequency that a user wouldcross security zones. Clearly, this is not ideal and wehave investigated increasing the entropy of the messageexchange using server-side and client-side nonces toprevent replay attacks.RAMEN is vulnerable to attack originating from the

device because currently none of the more popular devicesprovide a trusted computing base. Instead, users are expectedto trust applications they install from app stores, whichmay be curated. Users can Bjailbreak[ or Broot[ their device,which obviates any security guarantees provided by theplatform. In this case, the device can maliciously reporterroneous context values, e.g., lie about its location,to gain advantage on the system. We stress that this is anindustry-wide problem that affects many authenticationmethods currently used. Mitigating this problem is a topicof research. For example, Varshavsky et al. [19] use radio

Figure 10

Plug-in architecture for the RAMEN secure gateway.


environment signatures to validate that two devices are inproximity of each other. RAMEN could use this methodto ensure verification of the user’s location assumingan additional trusted infrastructure can be added to theenvironment for this purpose.

Integration exampleTo demonstrate RAMEN, we extended an existing Androidmobile application that had no authentication feature [20].For Android, including RAMEN required one line of code.As shown in Figure 11, the application launches normallyon the device. The security manager intercepts the launchand requests authentication from the secure gateway.Based on location, the secure gateway will request eithera password or a PIN. The security manager opens a dialogwindow (included with the security manager) that promptsthe user for the credential. Once entered and successfullyauthenticated, the security manager obtains an access tokenfrom the secure gateway. The security manager then returnscontrol to the application, which proceeds normally. Notethat if authentication fails, the user is informed and theapplication exits. The user would have to launch theapplication to try again.

Related workAuth-SL [21] proposes a multi-factor authenticationlanguage based on Boolean combinations of authentication

methods. RAMEN can benefit from this formal specification,but we also add the notion of contextual attributes as partof the Boolean expression to guide the application of apolicy. Usable techniques to authenticate a user on amobile device are an important part of mobile security.Bao et al. [1] report on user frustration with monolithicmobile security policies. Context-aware security investigatesthe use of device context to augment or replace traditionalauthentication techniques. For example, Covington et al.[22, 23] investigated role-based access control (RBAC)models enhanced with context information. Miranda [24]developed an architecture called CAM2 that determinesthe appropriate authentication method given contextattributes and used an XML-based markup language toencode policies. CAM2 also allows extensions via plugins.Location has a privileged status for context-aware mobilecomputing efforts, and location-aware authenticationis an active area of research [9, 10, 12–14, 19, 25–28].Bertino and Kirkpatrick [13] have developed a formal modelof RBAC with location awareness. Kindberg et al. [10]authenticate devices on the basis of their proximity toa specific location. RAMEN can be part of a toolset thatallows flexible administration of policies. For example,RAMEN can be extended to support the distributedmanagement of custom personalized policies proposedin laissez faire file-sharing systems [29]. In such systems,end users, not administrators, author policies for all resources

Figure 11

Example integration with a hybrid application. Initially, the platform launches the application. The RAMEN security manager intercepts the initiallaunch and enforces location-aware authentication. Control returns to the application if authentication succeeds.


they own. In such a system, RAMEN would provideend users with the ability to craft context-aware policies.Break-glass models [30] have some similarity to laissezfaire systems by allowing users to override a securitypolicy. RAMEN’s policy evaluation engine could beuseful in defining emergency conditions used to allowor deny overrides.

ConclusionSecurity is an important but sometimes not understoodrequirement for mobile application developers. Studiesindicate that Bone-size-fits-all[ policies may be suboptimalfor typical mobile usage patterns [5]. RAMEN enables amore flexible authentication environment that can adapt toa mobile user’s context. The RAMEN policy engine canbe centrally administered and extended to include futureauthentication techniques. We plan to use RAMEN to helpanswer the question, what is the appropriate authenticationpolicy that has a certain utility value for a certain cost?This captures the notion of Busable authentication,[ whichtakes the perspective that the user’s cost of performingan authentication is as important as the reliability of thatauthentication method.

**Trademark, service mark, or registered trademark of Worklight (anIBM Company), Cisco, Google, Inc., or Sun Microsystems in theUnited States, other countries, or both.

References1. P. Bao, J. Pierce, S. Whittaker, and S. Zhai, BSmart phone

use by non-mobile business users,[ in Proc. 13th Int. Conf.Human Comput. Interact. Mobile Devices Services, 2011,pp. 445–454.

2. S. N. Patel, J. S. Pierce, and G. D. Abowd, BA gesture-basedauthentication scheme for untrusted public terminals,[ inProc. 17th Annu. ACM Symp. User Interface Softw. Technol.,2004, pp. 157–160.

3. X. Suo, Y. Zhu, and G. S. Owen, BGraphical passwords:A survey,[ in Proc. 21st Annu. Comput. Sec. Appl. Conf.,2005, pp. 463–472.

4. N. K. Ratha, J. H. Connell, and R. M. Bolle, BEnhancingsecurity and privacy in biometrics-based authenticationsystems,[ IBM Syst. J., vol. 40, no. 3, pp. 614–634,Mar. 2001.

5. H. Falaki, R. Mahajan, S. Kandula, D. Lymberopoulos,R. Govindan, and D. Estrin, BDiversity in smartphoneusage,[ in Proc. 8th Int. Conf. Mobile Syst., Appl. Services,2010, pp. 179–194.

6. IBM Worklight, IBM Corp., Armonk, NY, USA. [Online].Available: http://www-01.ibm.com/software/mobile-solutions/worklight/

7. C. Nachenberg, BA window into mobile device security,[Symantec, Mountain View, CA, USA, Tech. Rep. [Online].Available: http://www.symantec.com/podcasts/detail.jsp?podid=b-a-window-into-mobile-device-security

8. F. Cuppens, N. Cuppens-Boulahia, T. Sans, and A. Miege,BA formal approach to specify and deploy a network securitypolicy,[ in Proc. Formal Aspects Sec. Trust, IFIP, 2005, vol. 173,pp. 203–218.

9. J. Bardram, R. E. Kjær, and M. Østergaard Pedersen,BContext-aware user authentication-supporting proximity-basedlogin in pervasive computing,[ in Lecture Notes in

Computer Science. Berlin, Germany: Springer-Verlag,2003, pp. 107–123.

10. T. Kindberg, K. Zhang, and N. Shankar, BContext authenticationusing constrained channels,[ in Proc. 4th IEEE WorkshopMobile Comput. Syst. Appl., 2002, pp. 14–21.

11. D. Crockford, JavaScript Object Notation (JSON). [Online].Available: http://www.json.org/

12. C. A. Ardagna, M. Cremonini, E. Damiani,S. De Capitani di Vimercati, and P. Samarati, BSupportinglocation-based conditions in access control policies,[ inProc. ASIACCS, 2006, pp. 212–222.

13. E. Bertino and M. S. Kirkpatrick, BLocation-aware authenticationand access control concepts and issues,[ in Proc. AINA Conf.,2009, pp. 10–15.

14. D. Denning and P. F. MacDoran, BLocation-based authentication:Grounding cyberspace for better security,[ Comput. Fraud Sec.,vol. 1996, no. 2, pp. 12–16, Feb. 1996.

15. N. Beckmann, H. P. Kriegel, R. Schneider, and B. Seeger,BThe R�-tree: An efficient and robust access method for pointsand rectangles,[ in Proc. ACM SIGMOD Int. Conf. Manage.Data, 1990, pp. 322–331.

16. Oauth. [Online]. Available: http://oauth.net17. Phonegap. [Online]. Available: http://phonegap.com18. A. Desprets, BIBM websphere developer technical

journal: Web services security with websphere applicationserver v6VPart 4, IBM DeveloperWorks, Jul. 2006. [Online].Available: http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/0607_desprets.html

19. A. Varshavsky, A. Scannell, A. LaMarca, and E. De Lara. Amigo,BProximity-based authentication of mobile devices,[ in Proc.9th Int. Conf. Ubiquitous Comput., 2007, pp. 253–270,Springer-Verlag.

20. B. Curtis, Mysurance Hybrid Application. [Online]. Available:https://github.com/brycecurtis/phonegap-mysurance

21. A. C. Squicciarini, A. Bhargav-Spantzel, E. Bertino, andA. B. Czeksis, BAuth-SL: A system for the specification andenforcement of quality-based authentication policies,[ in Proc. 9thICICS, Berlin, Germany, 2007, pp. 386–397, Springer-Verlag.

22. M. J. Covington, M. R. Sastry, and D. J. Manohar,BAttribute-based authentication model for dynamic mobileenvironments,[ in Lecture Notes in Computer Science.Berlin, Germany: Springer-Verlag, 2006, pp. 227–242.

23. M. J. Covington, P. Fogla, Z. Zhan, and M. Ahamad,BA context-aware security architecture for emergingapplications,[ in Proc. Comput. Sec. Appl. Conf., 2002,pp. 249–258.

24. L. H. F. M. Miranda, BContext-Aware Multi-FactorAuthentication,[ M.S. thesis, Dept. Informatica, Univ.Nova de Lisboa, Lisbon, Portugal, 2009.

25. D. Jaros, P. Bednar, and K. Radek, BA new approach inmultifactor authentication and location-based authorization,[ inProc. 6th Int. Conf. Internet Monit. Protection, St. Maarten,The Netherlands, 2011, pp. 50–53.

26. S. Kurkovsky and E. Syta, BApproaches and issues inlocation-aware continuous authentication,[ in Proc. IEEECSE, 2010, pp. 279–283.

27. M. L. Damiani and E. Bertino, BAccess control and privacyin location-aware services for mobile organizations,[ in Proc.7th Int. Conf. MDM, 2006, p. 11.

28. I. Ray and M. Kumar, BTowards a location-based mandatoryaccess control model,[ Comput. Sec., vol. 25, no. 1, pp. 36–44,Feb. 2006.

29. M. Johnson, S. Bellovin, R. Reeder, and S. Schechter,BLaissez-faire file sharing: Access control designed forindividuals at the endpoints,[ in Proc. NSPW, 2009, pp. 1–10.

30. S. Marinovic, R. Craven, J. Ma, and N. Dulay, BRumpole:A flexible break-glass access control model,[ in Proc.16th ACM SACMAT, 2011, pp. 73–82.

Received February 15, 2013; accepted for publicationMay 6, 2013


Paul C. Castro IBM Research Division, Thomas J. WatsonResearch Center, Yorktown Heights, NY 10598 USA ([email protected]). Dr. Castro is a Research Staff Member in the Mobile EnterpriseTechnologies group at the IBM T. J. Watson Research Center. Hereceived a Ph.D. degree in computer Science from the Universityof California, Los Angeles, in 2001. His research area is mobilecomputing, where he has published more than 20 papers and holdsmore than 12 patents. He was the Chair of the Mobile ComputingProfessional Interest Community at IBM Research and has served onseveral mobile computing conference committees. He is a former officerin the U.S. Air Force.

Joseph W. Ligman IBM Research Division, Thomas J. WatsonResearch Center, Yorktown Heights, NY 10598 USA ([email protected]). Mr. Ligman is a Software Engineer at the IBM T. J. WatsonResearch Center. He has extensive engineering skills on various mobileplatforms. His work focuses on mobile application instrumentationand management.

Marco Pistoia IBM Research Division, Thomas J. WatsonResearch Center, Yorktown Heights, NY 10598 USA ([email protected]). Dr. Pistoia is a Research Staff Member and the Manager ofthe Mobile Enterprise Technologies group at the IBM T. J. WatsonResearch Center. He received a Ph.D. degree in mathematics from thePolytechnic Institute of New York University in 2005. His areas ofresearch are language-based security and mobile computing. He haswritten 10 books and more than 30 conference papers and journalarticles, and he is the inventor of more than 20 patents. He has lecturedat numerous universities worldwide. He has received two ACMSIGSOFT Distinguished Paper Awards, a Pat Goldberg Memorial BestPaper Award, an Outstanding Technical Achievement Award, andtwo Outstanding Innovation Awards.

John Ponzo IBM Software Group, Thomas J. Watson ResearchCenter, Yorktown Heights, NY 10598 USA ([email protected]).Mr. Ponzo is an IBM Fellow and the Chief Technology Officer forIBM Mobile First. He has extensive experience in mobile technologiesand leads strategic initiatives focused on the Mobile First portfolioof mobile technology.

Gegi S. Thomas IBM Research Division, Thomas J. WatsonResearch Center, Yorktown Heights, NY 10598 USA ([email protected]). Mr. Thomas is a Senior Engineer at the IBM T. J. WatsonResearch Center. He holds degrees in systems design engineering andin economics from the University of Waterloo in Waterloo, Ontario,Canada. His areas of interest include mobile collaboration services,mobile analytics, and enterprise collaboration. He is the recipient of anIBM Outstanding Technical Achievement Award for Contributionsto Collaboration Technologies, and his focus is on advancing mobileinnovations to impact IBM’s Enterprise portfolio.

Umut Topkara IBM Research Division, Thomas J. WatsonResearch Center, Yorktown Heights, NY 10598 USA ([email protected]). Dr. Topkara is a Research Staff Member in the SoftwareDepartment at the IBM T. J. Watson Research Center. He received aB.S. degree in computer engineering and an M.S. degree in computerscience from Bilkent University in 1999 and 2001, respectively. Hereceived a Ph.D. degree in computer science from Purdue Universityin 2007. Before joining IBM at the T. J. Watson Research Center,he worked at Carnegie Mellon University, the Polytechnic Instituteof New York University, and Google. He is an author or coauthor of6 patents and 20 technical papers.


runtime adaptive multi-factor authentication for mobile devices

Documents