A Low Power Security Architecture for Mobile …...gain popularity among the next generation mobile applications. These services will be developed on top of location-aware middleware

A Low Power Security Architecture for Mobile Commerce

Peter Langendoerfer+, Zoya Dyka+, Oliver Maye+ and Rolf Kraemer+

+ IHP, Im Technologiepark 25, Frankfurt (Oder), Germany [email protected]

Abstract:Mobile devices have limited resources in terms ofcomputational power and energy. With the up-comingwireless Internet a lot of new applications that requiresecurity and privacy will be deployed. The exhaustive useof encryption mechanisms will drain down the batterywithin short time. In this article we present a securityarchitecture that enables mobile devices to negotiate thecipher mechanisms with the infrastructure. Thus, themobile devices are enabled to exploit the differences in thecomputational effort required for public and private keyoperations of RSA and elliptic curve cryptography (ECC).The benefit of this approach is that the mobile only has toexecute RSA public key and EC private key operations. Wepresent measurements for a given scenario, showing thatby exploiting the differences in the computational effort ofRSA and ECC, the computational burden on the mobilecan be reduced by up to forty seven times.

Keywords: security architecture, elliptic curvecryptography, RSA, mobile devices, energy consumption

I. INTRODUCTIONThird generation mobile phones and Bluetooth or W-LANenabled PDAs offer easy and efficient access to theInternet. The aspect of mobility and the actual location ofthe service user make it possible to address new types oftasks. We are convinced that a whole set of (probably onlylocally available) applications which adapt their content tothe user’s location or other usage context will significantlygain popularity among the next generation mobileapplications. These services will be developed on top oflocation-aware middleware platforms. Such platformsprovide functions such as profile handling, positioning andlocation handling, event services etc. An example for alocation aware service is an “Airport Scout” that guidesyou to your gate. Such a service could charge a certainamount of money per meter of the guided distance.

Privacy and security are of crucial importance when itcomes to mobile business. Here end-to-end security andprivacy have to be provided on the application level.Encryption techniques can be used to ensure security andprivacy. Public key encryption methods, which aredefinitely needed in this context e.g. for digital signatures,are computationally intensive. The problem that arises is

that all messages have to be encrypted in order to ensureprivacy and that mobile devices have very limitedresources in terms of calculation and battery power. Thechallenge here is to ensure privacy and security without asignificant reduction of the up time of the mobile device.

In this paper we propose a security architecture thatenables mobile devices to exploit the imbalance ofcomputational effort of the private and public keyoperations of RSA and elliptic curve cryptography (ECC).In case of RSA, public key operations require asignificantly smaller computational effort than private keyoperation whereas for ECC it is the other way around. Thebasic idea is to use an EC key pair on the mobile side andan RSA key pair on the infrastructure side. The benefit ofthis is that the mobile has to execute only RSA public keyand ECC private key operations. We presentmeasurements for a given scenario that show that by usingthis approach the computational burden on the mobile canbe reduced by up to forty seven times.

Throughout this paper we use the reduction of thecomputational effort for a specific algorithm on a givendevice as an equivalent to the energy reduction.

This article is structured as follows. In the next section wedescribe the overall architecture of our security concept.Thereafter we describe the scenario we used in ourperformance evaluation. In section 4 we present ourmeasurement results and discuss the potential performancegain of our approach. Then we draw conclusions on theapplicability of our approach. The paper concludes with ashort summary of the main results and an outlook onfurther research steps.

II. ASYMETRIC SECURITYARCHITECTURE

A platform that supports m-commerce has at least onecomponent that provides accounting and paymentfunctionality. We think that location aware services willgain a significant popularity so that platforms deployed form-commerce will be enhanced with components thatprovide location handling. The following types of data

must be exchanged between such an infrastructure (serverside) and a mobile device:

• Current location of the mobile device• Payment information (credit card, e-cash)• Purchased goods (information, data)

If these data are not protected properly they can be used todevelop detailed profiles of the subscribers. Since Internetsubscribers are already highly concerned about theirprivacy this information has to be protected againsteavesdropping and misuse [1]. Therefore all messages thatare exchanged between the infrastructure and the mobileclient as well as all messages that are exchanged betweeninfrastructure servers should be encrypted. In addition, allthese data have to be digitally signed in order to guaranteeauthenticity. Digital signatures are also needed to providesecure payment functionality. For signing messages publickey cryptography is the best approach. This is due to thefact that with symmetric cryptography, each of thecommunication partners can easily forge a message. Thus,RSA and ECC or a combination of both should be used forsigning messages. This can be handled in the followingways:

• The infrastructure and the mobile both use RSAfor all purposes. The receiving side applies thepublic key of the sending side to verify thesignature of the sending side as well as forencrypting its response. For generating its ownsignature it and for decrypting received data ituses its private key (see figure 1(a)).

• The infrastructure and the mobile device both useECC for all purposes. The use of public and

private keys is equivalent to the RSA scenario(see figure 1(b)).

• The infrastructure uses its private RSA key tosign messages sent to the mobile. It encrypts thesemessages using the mobile client’s public EC key.The mobile encrypts data using the public RSAkey of the infrastructure and signs messages usingits private EC key (see figure 1(c)).

The computational burden that arises from exhaustive useof public key cryptography will significantly decrease theup time of the mobile terminal. The minimal effort isachieved when a combination of RSA and ECC is used [2].The reason for this phenomenon is that with RSAcryptography, public key operations are relatively easily tocompute, whereas for ECC private key operations arecalculated inexpensively.

In an environment in which the server side and the clientdo not know each other, a priori the use of encryptionmechanisms has to be negotiated after the discovery phase.In order to minimize the encryption effort a symmetric keyis exchanged in the suggested approach after thenegotiation of the cipher algorithms.

A. Cipher Negotiation Protocol

In the following paragraphs we describe the initialcommunication set-up and how the cipher mechanisms areselected.

Mobile client and server sideDuring the initial communication set up the server side,and the mobile device have to agree about the encryptionmechanisms that will be used. The server side broadcastsperiodically its identity, its certificate and the set ofencryption mechanisms it supports. When a mobile clientreceives this message it verifies the certificate of the serverside using a set of stored public keys of trust centers whichit knows. Then it responds with a message including itsidentifier, its public key and its preferred encryptionalgorithm for the uplink and the downlink, the selectedsymmetric cipher mechanism etc. Since the server side hasunlimited resources in comparison to the mobile device, itaccepts by default the proposal of the mobile device.If the server side and the mobile device have no ciphermechanism in common they can agree to exchangemessages without encrypting and signing of thesemessages. But in this case the server side as well aspotential service providers have to agree explicitly.In the next step the server side generates a pseudonym forthe mobile client and a symmetric key for furthercommunication. These data are encrypted and signed usingthe private key of the selected cipher mechanism of theserver side and are then sent to the mobile client. Thesymmetric key is used to encrypt and decrypt all followingmessages. The pseudonym is used to identify the mobile

(a)

(b)

(c)

Figure 1: Application scheme of public keymechanisms. (a) pure RSA approach; (b) pureEC approach; (c) RSA on the infrastructureside and EC on the mobile side

and also to find the correct symmetric key for en- anddecryption on the server side. All these messages areencrypted and digitally signed. The digital signature isverified before the message is decrypted. Thus, only validmessages are decrypted so that no useless operations areexecuted.

Mobile and service providerThe initial communication set-up between the mobileclient and the service provider is very similar to thosebetween mobile and infrastructure. If the mobile wants touse a certain service it sends a request with the serviceprovider identity to the infrastructure. The server sideresponds with a message including the IP address of theservice provider, the encryption mechanisms that theservice provider supports and the public keys of the serviceprovider. Then the mobile selects the cipher mechanismsfor further communication and sends the correspondingmessage to the service provider. Thereafter the client cansend requests to the service provider. All messagesexchanged during the service usage are encrypted usingthe common symmetric key and signed with client’s andservice provider’s private key respectively.Since the infrastructure has provided the public key of theservice provider, the mobile may skip the authentication ofthe service provider.

Message encodingThe messages exchanged during the negotiation of thecipher mechanisms are encoded using XML. Figure 2 (a)shows the message that is broadcasted by the server side;

the answer of the mobile is depicted in figure 2(b). Thesemantics of the message is defined in the document typedefinition. Thus, the mobile device can interpret themessage even if there are cipher mechanisms that it doesnot know. So, it can select one algorithm per categoryaccording to its needs. Using XML encoded messages inthe cipher mechanism negotiation phase has the benefitthat there is no need to have standardized cipher chainslike the ones used in TLS [3]. Therefore, extensions can bemade for the server side and for the mobile sideindividually. During the connection set up the mobile andthe server side create their own “cipher chain” .

B. Key distribution

In this section we explain which of the system components(infrastructure, mobile client, and service provider)manage which keys.

InfrastructureWe assume an m-commerce infrastructure which covers ahot spot such as a train station or airport. This means it willconsist of a set of access points, covering a certain part ofthat region, a set of servers responsible for a set of accesspoints, and a single server that is responsible for the initialkey exchange with new subscribers.

All messages exchanged between infrastructurecomponents and between the infrastructure and mobile

Figure 2: Messages of the cipher negotiation given in XML: (a) Security features supported bythe infrastructure; (b) cipher mechanisms selected by the mobile device

<?xml version = ‘ ’1.0’ ’?><!DOCTYPE cipher_mechanisms [ …]<UPLINK><PUBLICKEYMECHANISM>

<ALGORITHM> RSA<PUBLICKEY> 123456789018745762362

</PUBLICKEYMECHANISM><PUBLICKEYMECHANISM>

<ALGORITHM> B163 /*ECC*/<PUBLICKEY> F12654

</PUBLICKEYMECHANISM>….</UPLINK><DOWNLINK> …..<DOWNLINK><SECRETKEYMECHANISM>

<ALGORITHM></ SECRETKEYMECHANISM><SECUREHASH> MD5 </ SECUREHASH><SECUREHASH> SHA-1 </ SECUREHASH>….<NOSECURITYMECHANISM>

<?xml version = ‘ ’1.0’ ’?><!DOCTYPE cipher_mechanisms [ …]<UPLINK><PUBLICKEYMECHANISM>

<ALGORITHM> B163 /*ECC*/<PUBLICKEY> F12654

</PUBLICKEYMECHANISM></UPLINK><DOWNLINK><PUBLICKEYMECHANISM>

<ALGORITHM> RSA<PUBLICKEY>123456789018745762362

</PUBLICKEYMECHANISM></DOWNLINK><SECRETKEYMECHANISM>

<ALGORITHM> DES</SECRETKEYMECHANISM><SECUREHASH> MD5 </ SECUREHASH>

(a) (b)

clients must be encrypted. The messages exchangedbetween the server side components are encrypted using asymmetric encryption mechanism. For the initialcommunication set up with new clients, public keymechanisms are used. The corresponding keys are alsoused to sign messages that are sent to the mobile devices.Each infrastructure server has two public/private keyspairs: one individual and one common. The individual keypair is used to exchange the common symmetric key aswell as to exchange the common public/private key pair.The latter is used for the communication with mobileclients. This approach has the following benefits:

• Any server can run the client subscriptionprocedure.

• The mobile device must not authenticate newservers after a handover between two platformservers.

• The encryption mechanism, RSA or ECC do nothave to be negotiated again after a handover.

After the initial communication set-up, a symmetric key isused to cipher data exchanged between the server side andthe mobile. The subscribing server generates an individualkey for each mobile client. This key is forwarded to theclient as well as to the server that covers the client’scurrent location. It is also forwarded inside theinfrastructure as part of the information exchanged duringa handover.

Mobile deviceEach mobile has its own public and private keys forasymmetric cipher mechanisms that it supports. In additionit stores the public key of the server side that fits to theselected cipher algorithms. It also has a key for thesymmetric ciphering used for data communication with theserver side. If the mobile has requested a service that is notprovided by the infrastructure itself, the mobile managesalso the public key of that service and a symmetric key forthe data exchange with that service. The symmetric keysused for the communication with the infrastructure and theservice are different.

Figure 3: Structure of the infrastructure and key distribution within the infrastructure

Service ProviderThe service provider stores the public key of each mobilethat is currently served. Thus it is capable of verifying thepayment tokens. In addition it manages one symmetric keythat it uses to encrypt data sent to its current clients.

III. SCENARIOThe estimation of the time needed for encryption,generation, and verification of digital signatures is basedon the following scenario. The mobile client and the serverside negotiate the encryption mechanisms. After this initialphase the mobile requests a certain service. The server sideprovides the IP address and the set of supported ciphermechanisms and the public keys of the service provider.After receiving this information the mobile sends itsselection of cipher mechanisms to the service provider. Itresponds with a pseudonym and a symmetric key forfurther communication. After receiving this informationthe mobile starts to create service requests. In our scenariowe assume that it creates ten service requests which areserved individually by the service provider. Thesemessages contain a certain service request. The answerconsists of the requested data, a service identifier, and therequested payment. The client responds with a paymenttoken that represents the service identity and the requestedamount of money. The service provider signs the paymenttoken and sends it back as a receipt for the payment. In thisscenario the following operations are executed on theclient side:

• En-/decryption of the initial messages• Signature verifications• Signature generations• Ciphering of the exchanged data with symmetric

key.For the performance evaluation we did not take intoaccount the time for encrypting and decrypting data withthe symmetric key. The messages exchanged are verysmall so that symmetric encryption is done extremely fast.More important is that the time needed for symmetricencryption operations is independent of the public keyencryption features used. Thus, it has no influence on theperformance gain of our approach.

IV. MEASUREMENTSIn order to verify whether the combination of RSA andECC helps to reduce the computing effort on the clientside we evaluated the computation time for the abovesketched scenario. We investigated the following threecases:

• Client, infrastructure and service provider useRSA (pure RSA approach).

• Client, infrastructure and service provider useECC (pure ECC approach).

• Client uses ECC for the up link and theinfrastructure as well as the service providerapplies RSA for the down link (combinationapproach).

The number and type of operations executed in our samplescenario are given in Table 1. The number of operations isindependent of the public key mechanism applied.

We evaluated three different hardware configurations: aPC (PentiumIII with 450MHz), a HP Jornada (SH3processor with 133MHz) and a Palm Pilot. For theciphering we used RSA with a public exponent of 3, 17and 216+1 as well as B-163 and K-163 (recommended byNIST) that provide the same level of security as RSA-1024. We implemented the cipher mechanisms on aPentiumIII and on a HP Jornada. For our ownimplementation we used the MIRACL library fromShamus Software Ltd. (Ireland) [4], that providesoperations in GF(p), GF(2m) as well as modulo arithmeticimplemented in C.The execution time of the cipher operations is the onlydecisive part in our scenario. Therefore we did notmeasure the whole scenario including all lower layeroperations and transfer through the network. Instead wemeasured each operation: signature generation, signatureverification, en- and decryption for RSA and ECC 1000times. Columns four and six of Table 2 present the averageof these measurements for the PC and the Jornadaimplementation, respectively. We used these values tocalculate the execution time for the cipher operations onthe client side.For the Palm Pilot device we used measurements presentedin [5] to calculate the execution time for isolated cipher

Table 1. Number and type of public/private key operations on the client side.Number of operationsName of operationsPure RSA Pure ECC Combination

Public Key of InfrastructureEncryption

RSA Public Key2

EC Public Key2

RSA Public Key2

Private Key of ClientDecryption

RSA Private Key2

EC Private Key2

EC Private Key2

Private Key of Clientsignature generation

RSA Private Key23

EC Private Key23

EC Private Key23

Public Key of Infrastructuresignature verification

RSA Public Key24

EC Public Key24

RSA Public Key24

operations. Then we summed them up in the same way aswe did for the PC and Jornada in order to get the executiontime for our scenario. These values are given in columnsseven and eight of Table 2.

Columns four, six and eight of Table 2 show the executiontime on the client side for our scenario for all RSAexponents (both elliptic curves as well as for thecombination of the different RSA exponents and the

elliptic curves). The comparison of these values indicatesclearly that RSA operations on the server and the mobileside need the longest execution time. On the PC and thePalm Pilot even EC on both side is outperformed by thecombination of RSA public and EC private key operations.The factor that can be achieved by our approach dependsstrongly on the elliptic curve and the RSA exponent thatare used for the operations. It reaches from 1. 6 to 1.8 forthe RSA part and from 2.2 up to 2.5 for the ECC part on

Table 2. Time performance of cryptographic operations on the client side (Pentium I I I 450MHz and HPJornada, MIRACL implementation); and Palm Pilot device, “ Dragonball” 16MHz, calculation based onmeasurements presented in [5] in msec.

time

measuredon PC

measured onHP

calculationbased on

values from [5]Parameters Operation per

operation

forscenario

peroperati

on

forscenari

o

peroperati

on

forscenari

o

3

RSA client private key signature generationRSA server public key signature verification

RSA client private key decryptionRSA server public key encryption

67.40.5

67.40.5

1698.0 18610138

18610138

468838 36130729

362841023

923.1

17



67.41.1

67.41.1

1713.6 18610312

18610312

473362 361301058

362841349

931.65

pure

RSA

publ

ic e

xp:

216+1



67.43.6167.43.61

1778.86 186101006

186101006

491406 361302374

362842670

965.87

B-163 EC client private key signature generationEC server public key signature verification

EC client private key decryptionEC server public key encryption

39.8653.8848.7855.02

2417.5 266357331367

16082 2230537035645458

198.21

pure

EC

C

EC

:

K-163 EC client private key signature generationEC server public key signature verification

EC client private key decryptionEC server public key encryption

37.4557.0841.3558.62

2431.21 253354284364

15611 1793326316102928

128.63

3

EC client private key signature generationRSA server public key signature verification

EC client private key decryptionRSA server public key encryption

39.860.5

48.780.5

1020.84 266138331138

10368 2230729

35641023

77.96

17



39.861.1

48.781.1

1036.44 266312331312

14892 2230105835641349

86.51

RSA

pub

lic e

xp:

216+1

EC

: B-1

63



39.863.61

48.783.61

1101.70 2661006331

1006

32936 2230237435642670

120.73

3



37.450.5

41.350.5

957.05 253138284138

9975 1793729

16101023

64.00

17



37.451.1

41.351.1

972.65 253312284312

14499 1793105816101349

72.55

com

bina

tion

appr

oach

RSA

pub

lic e

xp:

216+1

EC

: K-1

63



37.453.61

41.353.61

1037.91 2531006284

1006

32543 1793237416102670

106.78

the PC. Table 3 shows these factors for all combinations ofRSA exponents and EC curves we investigated. For thePalm Pilot the performance gain is even bigger. Here thefactor ranges from 8 to 14.4 for the RSA part and for theECC part it covers a range from 1.2 to 2.5 (see Table 4).

All combination of RSA and EC that we analyzed reducedthe execution time for the PC and the Palm Pilot. When aHP Jornada is used as mobile client the situation changes.For the combination of K-163 and B-163 with RSA withexponent 216+1 the performance decreases (see Table 5).Thus, for these combinations it is better to use ECC for theuplink and the downlink. But for all other combinations ofRSA and ECC the performance is increased. The speed-upfactor ranges from 31.8 for the RSA part and 1.1 for theECC part up to 47 for the RSA part and 1.6 for the ECCpart (see table 5).

We are not able explain in detail why the performance ofthe Jornada decreases for several combinations of RSA

and EC. The implementation on the Jornada is exactly thesame as we used on the PC. The problem seems to stemfrom the poor RSA implementation1, which causes severeperformance problems on the Jornada. Table 2 shows thatthe performance of RSA operation is 150 up to 300 timesslower on the Jornada than they are on the PC. The ECCoperations are slowed down only by a factor of seven.

The reduction of the computation time leads to adramatically increased uptime for the mobile device.Depending on the mobile device and the cipher algorithmsapplied, the mobile device can be used up to 13 minuteslonger (see Figure 4). This extension of the uptime wasachieved for a very simple scenario in which only 26public and 25 private key operations were executed on theclient side. This indicates strongly that the features of oursecurity architecture (cipher negotiation procedure, no newsubscription procedure after internal handover etc.) offersuitable means to reduce the power consumption of mobiledevices.

V. CONCLUSIONSCommunication set-up requires that all communicationpartners agree on the cipher mechanisms that will be used.Here two cases can be distinguished:

• mobile and a fixed infrastructure arecommunicating

• two mobiles are communicating

1 e.g. we did not use Montgomery multiplication

Figure 4: Increased uptime of the mobile devices whena combination of RSA and ECC is used

Table 3. Speed-up factor of using Combinationapproach on the Client side (Pentium I I I , 450MHz,MIRACL implementation) for proposed scenario.

pure RSA pure ECCECRSA

publicexp:

3 17 216+1B-163 K-163

3 1.7 / / 2.4 /17 / 1.7 / 2.3 /

B-163

216+1 / / 1.6 2.2 /3 1.8 / / / 2.517 / 1.8 / / 2.5

Com

bina

tion

K-163

216+1 / / 1.7 / 2.3

Table 4: Speed-up factor of using Combinationapproach on the Client side (Palm Pilot device,implemented [5]) for proposed scenario.


publicexp:

3 17 216+1

B-163 K-163

3 11.8 / / 2.5 /17 / 10.8 / 2.3 /

B-163

216+1 / / 8.0 1.6 /3 14.4 / / / 217 / 12.8 / / 1.8

Com

bina

tion

K-163

216+1 / / 9.0 / 1.2

Table 5: Speed-up factor of using Combinationapproach on the Client side (HP Jornada 540, 32MB,133MHz, MIRACL implementation) for proposedscenario.


publicexp:

3 17 216+1B-163 K-163

3 45.2 1.617 31.8 1.1

B-163

216+1 14.9 0.53 47.0 1.617 32.6 1.1

Com

bina

tion

K-163

216+1 15.1 0.5

In the former sections we discussed the first case. Ourmeasurements show that in such a configuration, themobile can benefit substantially from an asymmetric use ofpublic key cryptography. Here the infrastructure will agreeto use the computationally more intensive ciphermechanism. This is allowed since the infrastructure sidehas no limitations in terms of energy and computationalpower. The situation changes completely if two mobiledevices try to set up secure communication. In this case,normally both communication partners will try to use ECCfor their own sending path. If they agree to do so thecomputational burden is still smaller than with RSA onboth sides. But the benefit in terms of energy andcomputational time-saving is much smaller than it is in theinfrastructure case. There are some exceptions where oneof the mobiles is willing to run the RSA part:

• If it is very eager to get a certain service from theother.

• If it will be recharged within a very short time.• If it is equipped with specialized hardware, so that

running RSA consumes less power than runningECC.

The results we measured on the HP Jornada indicate thatthe possible performance gain depends on theimplementation. Therefore the selection preferences on theclient side have to be chosen carefully. We recommend tomeasure the performance of all implemented ciphermechanisms in advance.

VI. SUMMARY AND OUTLOOKWe have presented a security architecture that reduces thecomputational burden on the mobile clients. The basic ideais to use two different types of public key mechanismsRSA and ECC, respectively. The computational effortneeded for public key operations is relatively low for RSAbut high for ECC. For private key operations it is the otherway around. Thus, it is advantageous to use RSA for thedownlink communication and ECC in the uplinkcommunication. The measurements presented show thatthe computing time on the mobile side can be reduced upto a factor of 47 compared to a pure RSA approach. Incomparison to a pure ECC approach the gain can go up to2.5 if our approach is applied.

Our main goal is to reduce the energy consumption of themobile device. Therefore we will focus on energy-efficientimplementations of cipher mechanisms in our nextresearch steps. The basic idea is to design hardwareaccelerators that can be used to support several cipheralgorithms.

ACKNOWLEDGMENT

The work described here was partially funded by theGerman Government as part of the “Wireless Internet:Cellular” project under grant: 01AK047F

References:

[1] Cranor L. F, 1999: Beyond Concern: Under-standing NetUsers’ Attitudes About Online Privacy. In Ingo Vogelsang andBenjamin M. Compaine, eds. The Internet Upheaval: RaisingQuestions, Seeking Answers in Communications Policy.Cambridge, Massachusetts: The MIT Press, p. 47-70, 2000

[2] Oliver Krone (ed.): Jini & Friends @ Work: Towards Securedservice access. Eurescom Technical Information ProjectP1005, 2001 http://www.eurescom.de

[3] IETF: The TLS Protocol Version 1.0, RFC2246, 1999,http://www.ietf.org/rfc/rfc2246.txt

[4] Shamus Software Ltd. (Ireland): The Multiprecision Integerand Rational Arithmetic C/C++ Library MIRACL (Version4.7), http://indigo.ie/~mscott/

[5] Michael Brown, Donny Cheung, Darrel Hankerson, JulioLopez Hernandez, Michael Kirkup, Alfred Menezes: PGP inConstrained Wireless Devices. USENIX Association,Proceedings of the 9th USENIX Security Symposium Denver,Colorado, USA, August 14 –17, 2000http://www.usenix.org/events/sec00/full_papers/brown/brown.pdf

Documents

A Low Power Security Architecture for Mobile …...gain popularity among the next generation mobile applications. These services will be developed on top of location-aware middleware