Trusted Location Based Services

Trusted Location Based Services

Institute for Applied Information Processing and Communications

Graz University of Technology

Peter Teufl - [email protected]

IAIK

mailto:[email protected]


[email protected] http://www.iaik.at

Myself

PHD in 2012: Knowledge discovery in security related applications

Lectures: Computer networks, smartphone security

Current projects, research: Smartphone security, cloud security, Android malware detection






IAIKProf. Reinhard Posch

e-Government

NFC security

Design and verification

Cryptography

Java security

Smartphone security










Contents

[email protected]

Location Based Services (LBS) and mobile devices

Trusted services - Proving that you are at a location at a specific time

Qualified digital signatures, cryptographic RFID tags

Two prototypes based on Trusted Location Based Services (T-LBS)

Using two smartphones

Using a cryptographic RFID Tag

Security analysis


Location Based ServicesLocation Based Services (LBS)

Success attributed to recent popularity of smartphones (especially iOS, and Android)

Examples: Maps, navigation, Point-Of-Interests, context-aware applications (Google Now, Siri, etc.)

Service:

How accurate is the user’s location?

Can it be used to prove that the user is at a certain place?






LBS - Security?No security - in terms of proving that the user is at the claimed location

Missing: Trusted GPS receivers, cryptographic measures, support of the operating system, defences against external influences

Why?

Not necessary for current applications (maps, navigation...)

Users benefit from accurately providing their location

...and simply not possible with one user’s device






LBS - Trust?Current technology on smartphones cannot provide trusted locations

We rely on a Trusted Third Party (further denoted as TTP)

This party verifies the location/time claim of a user

User, TTP use digital signatures to sign the location/time information

We present two ways of implementing such a TTP

Two users with smartphones, where one user represents the TTP

One user with a smartphone: TTP based on cryptographic RFID tag






Qualified SignaturesAustrian Citzien Card

Smartcard (on top of nationalhealth insurance card: ecard)

Mobile Signature Solution (Signature is created on an external HSM)

Smartcards cannot be deployed on smartphones (at least not in a simple way)

Thus: deployment of mobile signature solution

Based on two channels: Internet and SMS (mTans)






Mobile Signature

Login - 1st step: Phone Number/Password

SMS to phone number with mTAN

Login - 2nd step: entering the mTan






Cryptographic Tag

RFID tag, which is capable of executing cryptographic operations

Tag stores assymetric key pair

Private key cannot be extracted from tag

Tag creates a digital signature with this private key

Communication with NFC enabled smartphone






Components, DefinitionsService Provider (SP): An application service provider that employs trusted location based services

User: The user who provides a trusted location to a Service Provider (SP)Creates signature with qualified signature (mobile signature)

Trusted Third Party (TTP): A trusted party that verifies the claimed location of the user, and also signs the ticket which is already signed by the user

Trusted Location Time Ticket (T-LTT): Digitally signed “Location Time Ticket” that contains the correct location and the time






Trusted Location Based Service

LocationSource

Time Source

Trusted Third Party(TTP)

Signature Creation

Signature Verification

User Service Provider(SP)1

4

2

1 … Access from User to service of SP2 … Request for T-LTT from SP to User3 … Request for T-LTT from User to TTP

5

3

4 … TTP sending T-LTT to User5 … User showing T-LTT to SP


Signature Creation


1: The user initiates a session with the SP

2: The SP requests a T-LTT from the user

3: The user signs his current location andtime (LTT) and sends it to the TTP

4: The TTP verifies the LTT and thesignature and signs the LTT (> T-LTT)

5: The user sends the T-LTT to the SP

6: SP can now verify the T-LTT and provide a location/time specific service to the user




Prototype Overview

SmartphoneUser A

SmartphoneUser B

TTP

Service Provider(SP)

LTT T-LTT

T-LTT

TTP

SmartphoneUser A

Cryptographic Tag

ServerLocation of crypto tags

T-LTT Service Provider(SP)

LTT

T-LTT

NonceSigned Nonce

Public Key

Protoype A Protoype B

Different TTPs






Prototype A - Two SmartphonesScenario A

User A needs a trusted location that proves that he/she has been at the location of User B (TTP)

User B has a strong interest that User A provides the right location (User A and B do not collaborate to fake the location)

Requirements: Two smartphonesdigital signatures






Prototype A - Two Smartphones1: User A signs location/time

2: User A submits LTT to User B (TTP)

3: TTP verifies LTT and signs LTT > T-LTT

4: T-LTT returned to User A

5: User A sends T-LTT to SP

User Trusted User

2

SP

5

Prover TTP

4

Signature Creation


Smartphone

LocationSource

Time Source

Signature Creation


Smartphone

31a 1b






Security Analysis - Prototype AMain threat to prototype A:

When User B (the TTP) and User A have the intention to work together in order to provide the wrong location

When User A alone has this intention, the TTP (User B) will not sign the location

More advanced threats described in the paper

Malware installed on User’s B smartphone.

Real User A at another location, fake User A has a proxy.






Prototype B - Cryptographic TagScenario B

A user is at a specific location at a specific time and needs to prove this. (e.g. a security guard that needs to inspect a certain location)

An unremovable cryptographic tag has been placed at this location.

With a smartphone, the cryptographic tag and an external server the user can prove that he was at the location at a given time.

Threat: User A could fake the time/location (TTP is not a real person, which simplifies certain attacks)






Prototype B - Cryptographic Tag1a/b: User: Gets public key from Tag

2a/b: Public key sent to server (looks up tag in DB), User gets nonce from server

3a/b: Tag returns signed nonce

4a/b: Server verifies tag signature, nonce, sends LTT to user

5a/b/c: User signs LTT, Server verifies LTT, signs LTT > T-LTT, returns T-LTT

6: User sends T-LTT to SP

User

SPProver TTP

Signature Creation


Smartphone

LocationSource

Time Source

Signature Creation


Server

Crypto Tag

LocationSource

4b

5b

1b

1a

3b

3a

2b

2a

4b

4a

5c

5a

5a

5c

5a

5c

6






Security Analysis - Prototype BMain threat to prototype B

TTP is not a real person, which makes it easier for User A to create the T-LTT at another location (e.g. sending someone else to the location and creating the digital signature remotely)

Compared to Prototype A

TTP is always trusted: more possible scenarios

More complicated






Current StatePrototypes are implemented

Scenario A:

User A/B have an accident, photos andreport are signed by both users

User B verifies location claim of User A

Scenario B:

Deployment of cryptographic tags, location/time log on a server






Questions?Thank you for your attention!

Please send your questions to [email protected]

Best Regards from Graz,

Austria!






