WO2014072725A1

WO2014072725A1 - Mobile tag reader security system

Info

Publication number: WO2014072725A1
Application number: PCT/GB2013/052931
Authority: WO
Inventors: Keith Mayes
Original assignee: Crisp Telecom Limited
Priority date: 2012-11-07
Filing date: 2013-11-07
Publication date: 2014-05-15
Also published as: GB2507742A; GB201220052D0

Abstract

This invention relates to secure access to machine-readable Tags using mobile devices such as mobile phones and subsequent intelligent action selection and execution depending on Tag, mobile, user and pre-known data. Current tagging systems may be attacked; redirecting users to malicious and/or offensive websites and fraudulent service providers. The invention addresses this issue and is designed to prevent and/or detect a range of attacks on tagging systems such as fake, modified, relocated, cloned Tags, and unauthorised mobile clients and server systems. In doing so it provides a trusted framework for the dynamic selection of services and service providers based on user interaction with mobile devices and tagged objects.

Description

Mobile Tag Reader Security System

FIELD OF THE INVENTION This invention relates to secure access to machine-readable Tags using mobile devices such as mobile phones to access a service via the mobile device.

BACKGROUND TO THE INVENTION

There is a great deal of interest in the Internet-of-Things whereby all items are equipped with some form of machine-readable Tag and/or communications device. We are already seeing supermarket goods equipped with traditional bar codes or Radio Frequency Identifier (RFID) Tags and many people also have passports that have RFID chips inside. The access to such Taps has been typically carried out by company employees or officials such as supermarket cashiers or immigration officers. However with the increasing sophistication of mobile devices there are new service opportunities in which phone users directly interact with tagged devices.

The relevant technical capabilities in mobile devices include the provision of cameras and applications that can process the images; and the support for Near Field

Communication (NFC) that permits a device to act as an RFID reader. NFC also supports smart card/RFID emulation, and a peer-to-peer mode whereby two NFC devices communicate with each other. These latter two modes can be relevant if at a point in time an NFC device is considered as a tagged or smart object, however for simplicity of description we will focus on the NFC mobile acting as a reader device interacting with traditional RFID Tags. NFC is further described at http://www.nfc- forum.org/home/

A popular service idea is the smart poster (see http://www.nfc- forum.ora resources/white papers/NFC Smart Posters White Paoer.pdft. which can be considered as a traditional poster equipped with a machine readable Tag. The mobile communicates with the Ta which results in a service action that is relevant to the poster. For example, the poster could relate to a concert and the phone browser might be re-directed to the website where more information may be found and tickets purchased. The smart poster is just one format and we could equally well attach Tags to all manner of objects (including living creatures/people) which are then often referred to as tagged objects or smart objects. The Tags could be of any form that has compatibility with the mobile device to at least allow transfer of information from the Tag to the device, however this description will focus on two types that are becoming common; QR-codes (see http://en.wikipedia.ora/wiki/QR code) and RFID Tags (see Mayes and Markantonakis, "Smart Cards, Tokens, security and Applications " Springer 2008, chapter 13). The QR-code is essentially a 2-D bar-code that would be read by the camera of the mobile device and interpreted by an application on the device. It is inherently passive and optical, meaning that it only supports simple read operations via line-of-sight, requires fairly precise positioning of the mobile, and can be copied. RFID Tags communicate using Radio Frequency (RF) means over a restricted separation range, although they do not have the orientation and line-of-sight issues of QR codes. Depending on the sophistication of the RFID, it may support a range of access options, from simple read of the ID to sophisticated security protocols. Whichever type of Tag we use, we may be interested in a core set of actions. We have already mentioned diverting to a web-site, but we may initiate a phone call, perhaps send a text message or simply read the data held on the Tag (which could be private and/or security sensitive). In general terms we are directing the user to some kind of service provision associated with a Service Provider (SP).

Although there is a lot of interest in using these capabilities there are well founded security and fraud concerns. For example, an attacker could modify a Tag or substitute a legitimate Tag with his own, directing the user to a fraudulent or offensive website. A variation is to simply add an attacker's Tag to a poster or object in a trusted context; so for example a bank customer may think he will get the latest interest rates form a poster, but instead gets directed to a phishing site. Another example is triggering a call to a premium rate phone number set-up for the benefit of the attacker. An attacker could also construct a realistic copy of a legitimate Service Provider's website (or sit between the user and the genuine website), so the misdirection may not be

immediately obvious. Attackers may also try to monitor the communications between the Tags, readers and servers to harvest private information and security credentials for later exploitation.

There is also a service concern that a simple direct action based on stored Tag data alone will not be appropriate for a user's changing preferences, profile and context. For example a French visitor reading a smart poster in the UK, may require the displayed website to be in French. Another example is that a child tapping a smart object may need a different style of explanation than an adult. What is displayed may also be optimised by considering past behaviour. Whilst these customisations make the solutions more usable the fact that preferences and behaviour are used in deciding actions also adds security concerns. For example the French visitor may not want it known that he his away from his own country and it perhaps should not be revealed that a child is accessing an object, nor should someone's likes, preferences and past history be revealed to untrusted parties.

If the action in response to accessing a smart object can be confidently and securely linked to a genuine user and a genuine SP there may also be new commercial opportunities whereby the action is linked to a promoted service and/or whereby additional relevant services are offered.

In tackling these challenges we exploit the fact that the mobile device is not simply a substitute reader, but rather a sophisticated, location-aware personalised device that is associated with the user (rather than the smart object) and network profile data. It also has security capabilities and credential data that can be used to augment the Tag data; creating a data set on which to base action decisions. We also move the service selection data and Tag sharing aspects away from the Tag itself by using a back- office/server-centric solution.

In short there is a need for a security solution to the smart object mobile access problem, whereby a trusted party ensures that the actions taken are secure and appropriate to the user and service providers, and that users and service providers have a high degree of trust in the integrity of the system data and functionality.

SUMMARY OF THE INVENTION

This invention relates generally to secure access to machine-readable Tags using mobile devices such as mobile phones and subsequent intelligent action selection and service execution depending on Tag, mobile, pre-known and dynamic data. A primary goal of the invention is to prevent and/or detect known attacks against conventional tagging systems so that they can be made secure and used with confidence. Some notable points are listed below.

The proposal concerns the tagging of objects of any kind that are then read by applications on smart phones (typically) that communicate to a server system that decides an appropriate service action to take.

The Tag means that a smart phone user can for example instantly get information about an object (e.g. how it works etc.) and related functions and services.

All Tags form part of a system set defined by the system operator.

The Tags may be assigned to sub-sets, typically managed by Service Providers

(SP)

Tapping/reading a Tag provides Tag data plus rich user and phone data for the Service Provider(s) (e.g. Tag ID, location, IMEI, IMSI) linked to pre-registered data.

The tap/read is equivalent to a request for action, which may often be to provide information from a web-site and or to initiate a transaction.

In satisfying the request the system operator and/or SP will ensure that the request is legitimate (a vital operation) and that the service action/information is appropriate and trusted.

The actual service action is dynamically decided e.g. based on time, location, customer and commercial aspects i.e. there is no deterministic link between a tag and/or its data, to the service provided.

One application example is using the Tag instead of a browser search to find offer the most relevant and commercially advantageous services/info.

In one aspect, the invention provides a system for determining a service to offer via a mobile client device, the system comprising:

a mobile client device having device data associated therewith;

a server device with which the client device can communicate over a communications network; and

a machine readable tag having tag data associated therewith and with which the client device can interact to obtain tag data;

wherein:

the tag data does not identify a specific service to be offered; the client device is operable to obtain tag data from the tag and to send to the server device, over the communications network, a dataset comprising obtained tag data and device data; and

the server is operable to receive the dataset from the client device and to determine at least one service to offer via the mobile client device, said determination being based on the received dataset and server data in a database accessible to the server.

In another aspect, the invention provides a method for determining a service to offer via a mobile client device, the method comprising:

using a mobile client device having device data associated therewith to obtain tag data from a machine readable tag;

sending a dataset from the client device to a server device over a

communications network, the dataset including said tag data and said device data, wherein the tag data does not identify a specific service to be offered;

receiving the dataset from the client device at the server;

and determining at the server at least one service to offer via the mobile client device, said determination being based on the received dataset and, optionally, server data. In either of the above aspects, the server data may, for example, identify a plurality of available services.

In some embodiments, for example in the case where no specific service can be identified based on the received dataset, the server may determine the service by randomly or pseudo randomly selecting a service from a predefined list.

In some embodiments, the server may determine the service to offer based on the results of a search using search parameters taken from the received dataset and, optionally also the server data.

Some embodiments of the invention offer a communications system in which a Server device securely determines the services to offer via a mobile Client device when the Client interacts with a machine readable Tag device, with the choice of offered services being based on data received from the Client in the form of a Data Set, the Server data within the Server databases and External Inputs controls. There is no definite link between a Tag and its data to the service provided and so a third party with complete knowledge of the Tag would not be able to confidently predict the offered service.

Embodiments of the invention may use a Client mobile device (typically a mobile phone) hosting a Client application (e.g. together a combination of an "app" and mobile phone hardware and interfaces; including the user interface) that implements the front end system processing. It is able to interact with a a Tag device, such as RFID Tags (preferred) or QR codes (legacy). The interaction may be via a secure protocol (in the case of advanced RFIDs) or just a Tag read in the case of the QR code or simple RFID. The application also interacts with the mobile itself to access phone and user data such as the International Mobile Subscriber Identity (IMSI), the International Mobile Equipment identity (e.g. IMEI), location (cell ID or GPS), time, phone model/ version and operational state. The application may also interact directly with the user to determine physical presence and/or preferences, as well as accessing stored user data such as a user ID, PIN/password, name, address, age, preferences and operational state. The data obtained by the Client is here referred to collectively as the Data Set. The Client has associated data such as IDs and cryptographic keys so that it can support secure communication with front end elements (e.g. RFID, user, phone data store) that support secured interaction. It also has the credentials to support secure communication with the Server device which hosts the Server application.

Embodiments of the invention may employ a Server device that receives the action request and Data Set from the Client. It can be considered as a typical combination of an application with server hardware resources and associated databases. If the action request is valid then the Data Set is used in conjunction with back office data (such as Tag, phone, user, Service Provider data, historical logs, black lists and system input data (such as service data, commercial factors, temporal variations and policies) to determine the service. In the simplest case the system operator is also the service provider and just computes the appropriate service to offer. In the generic case, addressed by the invention, the system operator will select Service Providers who then offer the service(s). This could be a fully dynamic selection, or potentially, Service Providers may be associated with a sub-set of Tags.

The security and attack resistance functionality can be illustrated by some simple example scenarios: (A) Simple RFID or QR code on smart poster.

In this example we will assume that the simple Issued RFID Tag maybe rewritten by an attacker, or that a QR code may be arbitrarily generated, but that in our case, for a legitimate Tag, the original Tag data and ID will be bound by a cryptographic calculation e.g. a Message Authentication Code (MAC)

The mobile Client reads the Tag data from the poster and collects/sends the Data Set to the Server. The Server checks the validity of the request (via the MAC) and the Data Set, and will reject the request if considered invalid.

(B) Simple RFID or QR code moved to a poster at a different location.

On this occasion the Tag data in the Data Set will pass the MAC validity check of example (A). However, we have location data from the phone data and a back office record of where the Tag should physically be, which may be used to detect the anomaly. Furthermore the Tag cannot direct to any service provider/service, but only those registered and supported by the system.

(C) RFID or QR code being accessed without the user's permission.

The Tag and mobile data will be valid, however if user presence checking is enabled the user data will report on the success of the user authentication.

(D) An attacker eavesdrops Client/Tag and Client/Server communication.

Cryptographic protection against eavesdropping is used between for Client/Server communication, and for Client/Tag communication when suitable RFIDs are used.

(E) An attacker uses an unregistered Client

Cryptographic authentication on the Client/Server communication link will detect an unregistered Client. (F) An attacker uses a Client clone emulator (copy of valid Client)

Usage patterns of the Clients will be logged by the Server and suspicious Client IDs will be black listed (blocked).

(G) An attacker deploys clone Tags in valid locations Usage patterns of the clones will be logged by the Server and suspicious Tag IDs will be black listed (blocked)

(H) A user misuses the tagging system

Usage patterns of the user will be logged by the Server and suspicious user IDs will be black listed (blocked)

In contrast to legacy solutions, the information coded onto the Tag (RFID or QR code) will not include details of the service to be accessed. Instead the Tag will include an ID that identifies it as unique (or part of a unique set) within the scope of the system and some form of cryptographic integrity value such as a MAC, that may be verified by the system. A sophisticated and attack resistant RFID Tag should also include

cryptographic functionality, keys and credentials to establish a mutually authenticated secure channel between the Tag and the Client mobile device. Tags may optionally include additional Tag data fields of relevance to the system processing.

ADVANTAGES OF EMBODIMENTS OF THE INVENTION In the Current State, it is possible to use a phone to read an RFID Tag or QR code and trigger a default application that could; go to a website, send a message or make a call; most commonly to go to a website URL. However, the Tags are not secure and so a malicious party could easily read the contents, clone Tags or replace genuine Tags and/or redirect users to the wrong site/service e.g. displaying an adult site rather than a toy store. Because of this, default applications prompt the user to confirm each URL access, however this is inconvenient and complex, and most users will just click "OK". In the case of a URL stored in a Tag it is normally fixed on deployment so cannot be dynamically adapted as service requirements evolve. Tag reading systems tend to be closed solutions for a single SP and do not make best use of the rich data that is available from the phone.

• In this invention there is a multi-SP framework that supports and manages

multiple sets of Tags and associated services. The Tags are authenticated and integrity checked before use and so the user does not need to confirm actions for safe usage. • Tag Data is combined with other rich sources of data such as Phone Data (including location) and User Data that can be used for back office fraud and security checks, and for dynamic service selection and customisation.

• The mobile Client and Server checks make use of cryptographic calculations as well as the rich Data Set and databases for secure dynamic contextual decisions.

• Tag Data does not need to store action related data such as a URL (which has security and ease of deployment/management aspects), as the actions are dynamically selected by the back-office.

• The Data Set message (or fields within it) may be encrypted so only visible to the back-office.

• The mapping of Tag request to SP and SP to Service are in the back-office and so can be dynamically adapted to provide the most appropriate primary service (and possible secondary service offers) to the user and/or to ensure that the most financially advantageous trusted SP (at any given moment) is used.

In summary, the action request resulting from accessing a Tag/QR code is only acted upon if the associated Data Set is valid and consistent with back-office data and policies. The actual action taken is determined by the back-office taking into account the Data Set, back-office data, input controls, factors and policies. This helps to protect against non authentic RFID Tags and QR codes, reprogrammed/modified RFID Ta s and QR codes, relocated authentic RFID Ta s and QR codes, copied/cloned RFID Taps and QR codes. The Server data also includes blacklists such that suspicious Tags, Clients and users may be denied service access, as appropriate.

An embodiment of the invention could use a mobile phone as the mobile device for the Client. There are a wide range of phones with cameras that could host the Client application although to interact with RFIDs requires phones with NFC capability. The invention was developed using LG Android phones, such that the Client supported both RFID Taps and QR code scanning. At the time of writing there are models available from Acer, Blackberry, C-mii, Casio, Fujitsu, Google, HTC, Huawei, Kuoziro, Lenovo, LG, Mobiwire, Motorola, Nokia, Panasonic, Samsung, Sharp, Sonim, Sony, Xolo, ZTE. An embodiment of the RFID Tag could be satisfied by a range of products compatible with the wireless capabilities (for Tag access) of the mobile device. NFC compatible devices typically support the following wireless/ Tag standards and interfaces.

- ISO 14443A (NXP Mifare)

- ISO 14443B/15693

- Sony Felica

For development of the invention, Kovio 2kbit Tags were used based on the ISO 14443A interface.

Embodiment of the Server is similar to any web server, however for operational use the server should be within a secure environment with appropriate IT security measured in place; typical of any server carrying out valuable and/or sensitive actions. For proof-of- concept development of the invention the Server was implemented on a commercial hosting service (Servage).

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings in which:

Figure 1 shows an example communications system architecture;

Figure 2 shows an example Data Set,

Figure 3 shows an example Service Provider hierarchy.

Figure 4 shows an example Server device.

Figure 5 shows an example Client device.

Figure 6 shows example Tag devices.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Figure 1 shows an example architecture for the invention. It consists of the following:

- (1 ) The Tag, which will typically be an RFID Tag or QR code. More generally it is any kind of machine readable device that can be accessed using an available interface supported by the mobile device. In its simplest form it can present an ID that either cannot be modified or its modification can be detected. In an advanced form it could include a tamper resistant chip, supporting secure storage and cryptographic functionality for secure communication with the mobile device.

- (2) The Tag Data, is the set of data stored on the Tag; the minimum being an ID.

- (3) The Tag Reader, this is part of the mobile device. For a QR code it would be the camera scanner, plus the section of the Client application that decodes the data. For an RFID this would be the NFC antenna, modem, APIs and section of the Client application to recover and check the data.

- (4) The Phone App, this is the overall Client control application including the various functionality to access Tag data, Phone Data, User data and to securely communicate with the Server. Note that although a phone is the most likely mobile device, other devices could be used such as laptops, tablet computers, e-books, PDAs, MP3 players etc.

- (5) The App Data, is the set of credentials such as IDs and cryptographic keys used for secure operations.

- (6) The Phone Data reader, is the interface/API that allows the Client to access phone data to include in the Data Set.

- (7) The Phone Data, is the relevant data that may be included in the Data Set,

- (8) The User Data reader, is the interface/API that allows the Client to interact with the user.

- (9) The User Data, is the locally stored user credentials used for user

authentication and/or inclusion in the Data Set. Typically this would include an ID and an authentication credential (password PIN), although other user data could be included.

- (10) The Challenge Generator, is the means to prompt the user for a response.

- (11 ) The Random Generator, is the means to great a nonce (freshness value) into the user challenge, so the challenge/response cannot be recorded and usefully re-used.

- (12) Intentionally missing to simplify the diagram, and just replaced by a note that (10), (11 ) and (13) could be replaced by a biometric sensor.

- (13) The User Interface, this is the means to interact with the user during

authentication and ultimately the normal means for accessing the service. Features could include a keypad, display, touch screen, motion sensor, sound, vibration etc.

- (14) The Server Application & Security Checker, is the part of the Se/verthat securely communicates with the mobile device Clients and verifies the legitimacy of the action request and the associated Data Set.

- (15) Similar to (5), for example, a store of shared IDs and diversified (by mobile device ID) matched symmetric or asymmetric cryptographic keys.

- (16) The SP Finder, is the part of the Server that determines the appropriate SP to handle the service request, based on all available data.

- (17) Back Office Database(s), are part of the Server that store data entries relating to Tags, phones, users, SPs as well as logs, blacklists and usage profiles/history.

- (18) SP, represents the set of SPs that may be selected to offer service. In the simplest case there is only one SP that is also the system operator.

- (19) Static/Dynamic Input, represent external inputs to the Se/verthat affect the selection of SP, such as the type of service data available, commercial factors, temporal variation, policies and preferences.

EXAMPLE SEQUENCE

(a) The user taps the phone against the Tag (1) and the Phone App (4) uses the phone reader functionality (3) to read the Tag data (2) out of the Tag (1 ).

(b) It then uses the Phone data reader (6) to read Phone Data (7) which could be static e.g. IMSI/IMEI or dynamic e.g. GPS location, time etc.

(c) The user data reader (8) is used to extract User Data (9). Optionally the user may be challenged via (10) & (1 1) to provide input (such as a PIN) via the user interface (13).

(d) The Phone App (4) then builds the Data Set message and applies the required cryptographic calculations based on the App data (5); including ID and keys.

(e) The Server App & security Checker (14) receives the Data Set and carries out cryptographic checks using the Server App data (15); discarding the message if invalid and/or updating the databases such as the blacklists.

(f) The Server App (14) uses the Data Set contents and the SP Finder (16) to determine the SP to use.

(g) The SP Finder (16) also makes use of the back office Database(s) (17) and the inputs (19) to make its selection of SP.

(h) The Server App (14) then passes an appropriate sub-set of the Data Set

contents to the selected SP (18).

(i) The selected SP (18) then responds to the Phone App (4) (or direct to standard phone functions such as browser etc.) based on the received contents from the Data Set. Alternatively, the Server App can send an identifier for the service to the Phone App so that the phone can initiate the execution of the service. An example embodiment of the Data Set is shown in Figure 2.

(a) In the example, the Data Set is represented as a flexible, expandable structure.

(b) The overall Data Set has a format type, an ID and an integrity check.

(c) The Data Set ID (=Client ID) is created during the application

download/registration process.

(d) The Data Set is comprised of one or more data fields, each of which adhere to a format type and have integrity checks.

(e) The integrity checks are in the form of Message Authentication Codes (MAC).

(f) The Data Set Format, Data Set ID and Data Set integrity check are in clear; other fields may be encrypted using keys relating to the ID fields. (g) The delivery of the Data Setls part of a HTTP request and the response may be the redirection of the request to the appropriate web service.

The DataSet is captured/constructed at the time that the the mobile Client interacts with a machine readable Tag. Typically it will be sent to the Server application without delay, however it can be sent at any time. One reason for sending a DataSet later is that the communications link is temporarily unavailable and so it is not possible to contact the Server or indeed the service that is being sought. Another reason to submit an old DataSet is if the user and or mobile device wishes to re-submit the service request. For example, a visitor to an art gallery, uses the system to get live information about the exhibits, and then the next day the visitor is back at home and wishes to show a friend the exhibit information.

It is important to note that there is no deterministic link between a tag and a particular service and so submitting a delayed DataSet (service request) may not result in the same service selection as would have resulted from sending the DataSet request without delay. For example the elapsed time between DataSet capture and its receipt by the Server will be a factor in dynamic service selection. Similarly the submission of the DataSet from a location other than where the DataSet was captured/constructed will also be a factor in dynamic service selection. Furthermore there may have been other variations and system weight changes during the elapsed time which would affect dynamic service selection.

An example embodiment of the process steps carried out by the Server when a Data Set is received are as follows, with the message/request being discarded (with updates to database contents) on a false result.

(a) Is the Client ID in the registered database and not blacklisted?

^• Compute/extract the MAC and encryption keys for the Data Set ID.

^• Check the MAC.

^• Decrypt if encrypted

(b) Is the User ID in the registered database and not blacklisted?

(c) Is the User Data cryptographically protected?

Compute/extract the MAC and encryption keys for the User ID.

Check the MAC. ° Decrypt if encrypted

(d) Is the Phone ID in the registered database and not blacklisted?

(e) Is the Phone Data cryptographically protected?

^• Compute/extract the MAC and encryption keys for the Phone ID.

° Check the MAC.

° Decrypt if encrypted

(f) Is the Tag ID in the registered database and not blacklisted?

(g) Is the Tag Data cryptographically protected?

^• Compute/extract the MAC and encryption keys for the Tag ID.

^• Check the MAC.

° Decrypt if encrypted

(h) Identify the default SP (if any) from the Tag ID system database entry.

(i) Finalise the actual SP choice based on other input and contextual data.

0) Establish a secure channel with the selected SP.

(k) Transfer all or part of the Data Set to the SP via the secure channel.

(I) The SP determines the appropriate service based on all supplied data and own policies and inputs.

(m)The SP provides the service direct to the Client device e.g. via a mobile phone browser and standard IT protocols.

Note that the Server could make an earlier selection of an SP e.g. after step (f) in which case the SP would be responsible for further processing of the supplied Data Set data. For example a SP that issues tags may hold the cryptographic keys associated with those tags, rather than the system operator, so if required the SP could check integrity and decrypt the Tag data.

In general, the determination of the correct SP will be strongly influenced by hierarchy of Service Providers and their mapping to physical Tags. An example embodiment is shown in Figure 3 and can be described as follows:

(a) All the Tags used in the system are referred to as the MasterSet which is under the overall management of the system owner.

(b) Services are provided by a SP based on Tag IDs and context.

^• Note that a single entity could be considered as multiple SP instances e.g. offering different services on sub-sets of Tags.

(c) There are various SP options including:

^• Single SP for all Tags = Master SP. ° SPs responsible for own sets of Tags.

° SPs responsible for sub-sets of Taps within the set associated with a higher-level SP.

° SPs that have no prior association with any Tags, but may still be selected to provide services to Client devices.

(d) On receipt of data from a Data Set message the system must first identify the default SP. This is typically the entity that purchased and deployed the tags.

(e) The system may then override the default choice based on dynamic context

° For example the performance or commercial benefits of another SP are greater than the default

Once the SP is identified it is then responsible for providing an appropriate service. The choice of service can be based on many factors including:

(a) Tag\D and Tag Data (if present)

(b) Phone Data

(c) User data

(d) Commercial Issues

(e) Dynamic timing

(f) Source data

(g) The Tag Data may also need pre-processing if this is not performed by the

Server.

(h) The SP uses the Tag D to determine cryptographic keys for the Tag.

(i) The SP can then check the integrity of the TagData

(j) The SP can decrypt the TaoOata (if encrypted format

The service to provide may be selected dynamically based on scores assigned to possible available services. For example, the service offered may be the highest scoring service. The scores may be determined based for example on the factors discussed above, such as time, mobile device location, type of device, etc and how these factors relate to attributes of the service, for example the locality of the service, the available times for the service, etc. Different weightings may be applied to these factors if desired. Scores may also take into account a history associated with the Client or user. Once the service has been selected the server can send back to the client an identifier for the service. The client can then subsequently access the service directly. The example may, for example, be a URL. In some embodiments, the identifier for the service my include additional parameters so that when the client accesses the service these parameters are passed to the service provider and can, for example, be used to effect some element of the service delivered (e.g. the language in which it is delivered or the forma for the particular client device). For example, the identifier may be a URL will added parameters at the end of the URL in a known manner.

An example embodiment of the Server Device is shown in Figure 4. Note that for simplicity of diagram we have shown a single unit, however in reality there may be a set of load balanced servers or an equivalent "virtual" implementation in the cloud. Figure 4 consists of a processor (1 ) and associated electronic logic circuitry and signals to enable general operation. It has access to a range of memories (2) such as nonvolatile (e.g. ROM/EEPROM/FLASH/Disk) and volatile (e.g. RAM). Typically the nonvolatile memory will be used for Operating System, Virtual Machine, Application and Data storage, whereas RAM will be used for temporary storage of variables, stacks etc. The Server device has a security sensitive role and so may be equipped with one or more security modules (3) which can be used for storage of sensitive data (e.g.

cryptographic keys), execution of sensitive functions (e.g. cryptographic algorithms) and/or to provide general cryptographic utility functions to the Server device hosted applications. In the invention it is envisaged that the operator of the Server might also act as a SP and there is a possibility of hosting user service applications (4) on the Server device. The Server is expected to hold a significant about of information on tags, Clients and Users and this is indicated by the databases (5). It is shown separate from the general memories (2) for clarity and to indicate that there may be multiple databases with diverse access control policies. The Server device communicates with Clients and SPs via external interfaces; typically via wired or wireless Internet (6) or Intranet (7) interfaces. Depending on the nature of the Server implementation and the type of Client device, the Server device might also have the capability for direct wireless communication with the Client device, such as via cellular radio (8). For completeness a user interface (9) is shown which represents all means of

administrative and operational control and configuration of the Server device. An example embodiment of the Client Device is shown in Figure 5. It consists of a processor (1 ) and associated electronic logic circuitry and signals to enable general operation. It has access to a range of memories (2) such as non-volatile (e.g.

ROM/EEPROM/FLASH/Disk) and volatile (e.g. RAM). Typically the non-volatile memory will be used for Operating System, Virtual Machine, Application and Data storage, whereas RAM will be used for temporary storage of variables, stacks etc. The Client device will typically have one or security modules (3) such as a SIM (associated with the IMSI), Security Element or Mobile Trusted Platform Module, which can be used for storage of sensitive data (e.g. cryptographic keys), execution of sensitive functions (e.g. cryptographic algorithms) and/or to provide general cryptographic utility functions to the Server device hosted. The Client device would typically have a user interface (4) such as a display screen and keypad/touch-screen entry means and/or audio I/O, which is used for user authentication and for consumption of the requested services. The Client device will typically have an optical sensor (5) e.g. capable of reading bar-codes. The preferred sensor is a camera which is able to capture bar-code images for interpretation by the Client application hosted on then Client device. The preferred Client device would have interfaces (6) to wirelessly access other Tag types. NFC is the preferred interface supporting access to carious RFID Tags. Other Tag interfaces may include Infra Red, Bluetooth, WLAN, Zigbee or other proprietary solutions. Communications interfaces such as WLAN and Bluetooth might also be used (direct or via Access Points) as interfaces (9) with the Server. More generally the communications to the Server be provided by a terrestrial (or possibly satellite) cellular wireless system such as GSM, UMTS/3G/4G (8) etc. The Client device is expected to be location aware (or track-able), either via the cell ID location of the cellular system or via a GPS receiver (7). The Client device will host its normal functions (e.g. browser, SMS, phone calls etc.) plus the Client application and its associated data and security credentials (preferably in a security module (3)). Because the C/enf communicates with tags it requires one or more triggers (10) to initiate the communication. In the case of an NFC mobile device running the Client application being brought in range of an RFID the device is able to trigger the communication and the Client application without the need for additional user interaction. In the case of an optical code such, as a QR code, it is not generally feasible in mobile phone devices to continually scan for codes. Instead, it would be normal for the user to first manually trigger/enable that optical reader part of the Client application and then for the QR code capture to be automatically triggered when correctly position within the field of view of the camera.

An example embodiment of the Tag Devices is shown in Figure 6. Part (A) of Figure 6 illustrates a conventional QR code with the indicated stored URL. There is no security associated with the stored URL and so there is opportunity for misuse.

Part (B) of Figure 6 is the same kind of QR code, but with textual content that is understood by the Client/Server rather than a URL. The content example shows an ID and a MAC computed over the ID. This does not inhibit copying of the tag, but it prevents and attack from creating tags with arbitrary IDs. The tag may contain additional data fields that would be protected by the MAC.

Part (C) represents an RFID Tag. All RFID Tags have some kind of antenna and wireless interface. The simplest Tags have a small memory and logic sufficient to communicate data similar to the QR code. Whereas the QR code can be read and copied by anyone the contents of the RFID are only revealed if it allows itself to be read without authentication, or the contents can be eavesdropped on the wireless interface during normal use. More sophisticated tags have secured memories and protocols that support authentication, integrity and confidentiality over the wireless interface, to prevent unauthorised access and and or eavesdropping. The most sophisticated RFIDs have CPUs and support multi-applications, and advanced protocols, and have advanced crypto co-processors for processing intensive cryptographic functionality (such as for asymmetric encryption/decryption and digital signatures). Good quality RFIDs are normally tamper-resistant i.e. able to resist a range of intrusive/aggressive attacks against the chip without revealing their contents. Note that the NFC standards include a mode in which a mobile device (e.g. phone, PDA, tablet computer etc.) is able to emulate an RFID (or contactless smart card device). In this mode such a mobile device would be a Tag within the terminology of this invention.

The following paragraphs set out various aspects and optional features of

embodiments of the present invention.

1. A communications system in which a Server device (Server) securely

determines the services to offer via a mobile device (Client) when the Client interacts with a machine readable Tag device (Tag), with the choice of offered services being based on data received by the Server from the Client (Data Set), which includes data sourced from the Tag (Tag Data) and data sourced from the Client (Phone Data), and data within the Server databases (Server Data) and Server controls (External inputs).

A communications system as in paragraph 1 in which the Data Set includes data associated with the user (User Data).

A communications system as in paragraph 2 in which the User Data set includes data indicating the physical proximity of the rightful user of the Client, to the Client.

A communications system as in paragraph 2 in which the User Data includes data indicating authorisation from the rightful user of the Client.

A communications system as in paragraph 2 in which the User Data includes data associated with the user of the Client.

A communications system as in paragraphs 2-5 in which the User Data includes a cryptographic integrity check such as a MAC or digital signature.

A communications system as in paragraphs 3-4 in which the data results from a user challenge and response compared to pre-stored authentication value such as a PIN or password.

A communications system as in paragraphs 3-4 in which the data results from a user sensor such as a biometric sensor.

9. A communications system as in paragraph 1 in which the Tag Data includes an ID for use in the system (Tag ID).

10. A communications system as in paragraph 9 in which the Tag Data includes a serial number associated with the physical Tag.

1 1. A communications system as in paragraph 9 in which the Tag Data includes a Tag type indicator.

12. A communications system as in paragraph 9 in which the Tag Data includes additional stored information accessible by the Client.

13. A communications system as in paragraphs 9-12 in which the Tag Data

includes a cryptographic integrity check such as a MAC or digital signature. 14. .A communications system as in paragraphs 9-13 in which all or part of the Tag Data reported to the Client by the Tag is in encrypted form. 15. A communications system as in paragraph 1 in which the Phone Data includes a unique identity of the user or account of the mobile Client device, such as the International Mobile Subscriber Identity (IMSI).

16. A communications system as in paragraph 1 in which the Phone Data includes a unique identity of the mobile Client device such as a serial number or the

International Mobile Equipment Identity (IMEI).

17. A communications system as in paragraph 1 in which the Phone Data includes a location indicator of the Client mobile device such as from GPS or cell ID.

18. A communications system as in paragraph 1 in which the Phone Data includes a representation of absolute, relative or elapsed time.

19. A communications system as in paragraph 1 in which the Phone Data includes information on the Client device such as its type, configuration, capabilities, and operational state.

20. A communications system as in paragraph 1 in which the Phone Data includes information on the operational state of the hosted applications, such as the

Client application.

21. A communications system as in paragraphs 15-20 in which the Phone Data includes a cryptographic integrity check such as a MAC or digital signature. 22. A communications system as in paragraph 1 in which the Server Data includes data associated with the Tags.

23. A communications system as in paragraph 22 in which the Server Data

includes data associated with mobile Clients.

24. A communications system as in paragraph 22 in which the Server Data includes data associated with services.

25. A communications system as in paragraph 22 in which the Server Data includes data associated with service providers.

26. A communications system as in paragraph 22 in which the Server Data includes data associated with users.

27. A communications system as in paragraph 22 in which the Server Data includes logs, histories, blacklists and usage profiles.

28. A communications system as in paragraphs 22-27 in which all or parts of the Server Data include cryptographic integrity checks such as provided by a MAC or digital signature. 29. A communications system as in paragraph 1 in which the External Inputs include static operational policies and preferences such as due to service performance, loading and reliability.

30. A communications system as in paragraph 1 in which the External Inputs

include dynamic operational policies and preferences such as due to service performance, loading and reliability.

31. A communications system as in paragraph 1 in which the External Inputs

include static commercial policies and preferences such as due to costs, fees, favoured services or service providers.

32. A communications system as in paragraph 1 in which the External Inputs

include dynamic commercial policies and preferences such as due to costs, fees, favoured services or service providers.

33. A Tag device providing the Tag aspect of the communications system of

paragraph 1 which stores data in machine readable form.

34. A Tag device as of paragraph 33 which is a Radio frequency Identifier (RFID) communicating with the Client via radio frequency means.

35. A Tag device as of paragraph 33 in which the Tag is an optically readable

pattern such as a QR code.

36. A Tag device as of paragraph 33 in which the Tag is any electronic device, with memory, logic and/or processor and wireless interface, such as an active RFID, Bluetooth device or NFC phone that communicates wirelessly, using any range of the electromagnetic spectrum, with the Client over a short range. 37. A Client device providing the Client aspect of the communications system of paragraph 1 , including memories, a processor and logic, and local short range and remote longer range interfaces and hosting the Client application.

38. A Client device as of paragraph 37 which is a mobile phone with a camera and Client application.

39. A Client device as of paragraph 37 which is an NFC enabled mobile phone with

Client application.

40. A Client device as of paragraph 37 which is any mobile electronic device that has means to communicate with a Tag and to host the Client application.

41. A Client device as of paragraph 37 with means to interact with a Tag that is within operational range of the appropriate wireless interface. 42. A Client device as of paragraph 41 which has an automatic trigger for interaction when the Tag and Client are within proximity limits.

43. A Client device as of paragraph 41 which has user interface means for the user to trigger the interaction.

44. A Client device as of paragraph 42 which has an automatic interaction trigger, activated by bringing an NFC phone into close proximity of an RFID Tag.

45. A Client device as of paragraph 43 which has a manual interaction trigger

activated by bringing an NFC phone into close proximity of an RFID Tag and the user enabling the process such as by pressing a key or touch screen.

46. A Client device as of paragraph 43 with a semi-automatic QR code trigger

activated by the user first enabling the Client application then position the Client device camera correctly with respect to the Tag to trigger reading of the code.

47. A Client device as of paragraph 37 in which the Client application has access means to the Phone Data from the Client mobile device such as via APIs, libraries, other applications and shared storage.

48. A Client device as of paragraph 37 in which the Client application includes and has storage means for all or part of the User Data.

49. A Client device as of paragraph 37 in which the Client has access means to all or part of the User Data from the mobile device such as via APIs, libraries, other applications and shared storage.

50. A Client device as of paragraph 37 which has one or more long range wireless communications interfaces such as cellular GSM, UMTS, WLAN, and satellite link.

51. A Client device as of paragraph 37 that has means to use the long range

wireless communications interfaces to facilitate communication with the Server.

52. A Client device as of paragraph 37 that has means to use the long range

wireless communications interfaces for access to services.

53. A Client device as of paragraph 37 which has the means to protect the

Client/Server communication via a security protected channel.

54. A Client device as of paragraph 37 which has the means to protect the

ClientlServer communication by authentication of at least one of the Client and Server. 55. A Client device as of paragraph 37 which has the means to provide integrity checking of the Client! Server communication.

56. A Client device as of paragraph 37 which has the means to encrypt/decrypt the Client 'Server communication.

57. A Client device as of paragraph 37 which has storage and access means for security credentials such as IDs and cryptographic keys to facilitate protected Client/Server communication.

58. A Client device as of paragraph 37 that has one or more security modules

capable of protected storage of sensitive data and for the protected execution of cryptographic functions.

59. A Server device providing the Server aspect of the communications system of paragraph 1 including memories, processor, logic and one or more hosted applications.

60. A Server device as of paragraph 59 in which the Server is the Server

application running on a traditional computer platform.

61. A Server device as of paragraph 59 in which the Server is the Server

application running on a virtual resource such as a Cloud. 62. A Server device as of paragraph 59 which has means to communicate via the

Internet.

63. A Server device as of paragraph 59 which has means to communicate via via a private intranet.

64. A Server device as of paragraph 59 which has means to communicate via a long range wireless communication interface.

65. A Server device as of paragraph 59 which has means to communicate with one or more Client mobile devices.

66. A Server device as of paragraph 59 which has storage and access means for security credentials such as IDs and cryptographic keys to facilitate protected CHentI Server communication.

67. A Server device as of paragraph 59 which has a communications interface to one or more service providers.

68. A Server device as of paragraph 67 in which the interface is a secure channel of typical IT security design. 69. A Server device as of paragraph 59 which has means to access to the Data Set received from the client, the Server Data and the External Input from which it selects the service provider to satisfy the Client request.

70. A Server device as of paragraph 59 that has one or more security modules capable of protected storage of sensitive data and for the protected execution of cryptographic functions.

71. A Server device as of paragraph 59 that has one or more databases for storage and access to Server data.

72. A Server device as of paragraph 59 that has a user interface for operational support, configuration and control.

73. A method to securely determine the services to offer via a mobile device

{Client) when the Client interacts with a machine readable Tag {Tag), with the choice of offered services being based on data received from the Client (Data Set), data within the Server databases {Server Data) and external input controls

(External inputs).

74. A method as in paragraph 73 for the Client to interact with the Tag to obtain the Tag Data.

75. A method as in paragraph 73 for the Client to interact with the mobile device to obtain the Phone Data.

76. A method as in paragraph 73 for the Client to interact with the mobile device to obtain all or part of the User Data.

77. A method as in paragraph 73 for the Client to interact with the user device to obtain all or part of the User Data.

78. A method as in paragraph 73 for the Client to securely communicate with the

Server.

79. A method as in paragraph 73 whereby an action request and the Data Set is sent from the Client to the server.

80. A method as in paragraph 73 for the Server to verify the integrity of protected parts of the Data Set.

81. A method as in paragraph 73 for the Server to decrypt the encrypted parts of the Data Set.

82. A method as in paragraph 73 for the server to access the Server Data.

83. A method as in paragraph 73 for the Server to access the External Inputs. 84. A method as in paragraph 73 for the Server to determine the appropriate service provider based on the Data Set, the Server Data and the External Inputs.

85. A method as in paragraph 73 by which the Server operator is also a service provider.

86. A method as in paragraph 73 by which a secure communications channel is set-up between the Server and the selected service provider.

87. A method as in paragraph 73 by which all or part of the Data set and relevant Server Data are communicated to the selected service provider.

88. A method as in paragraph 73 by which a selected service provider provides service to the requesting Client such as via conventional web-browser/webserver means.

89. A method as in paragraph 73 to prevent a Client being misdirected to the wrong service site/provider, achieved by associating the correct service with the Tag identity at the Server and not relying on an end service URL stored in the Tag.

90. A method as in paragraph 73 to detect a fake Tag, by the Server checking that the Tag ID is within a legitimate range.

91. A method as in paragraph 73 to detect a fake or modified Tag with legitimate Tag ID, by the Server recomputing and verifying the cryptographic integrity check such as a MAC contained within the Tag data.

92. A method as in paragraph 73 to detect a legitimate Tag moved to the wrong location, by the Server checking that the intended Tag location stored in the Server Data is consistent with the Client location reported in the Phone Data.

93. A method as in paragraph 73 to preserve the privacy of Tag Data, by encrypting all or part of the contents so that only the Server can decrypt them.

94. A method as in paragraph 73 to prevent unauthorised use of the Client

application, by the Client carrying out a user authentication process.

95. A method as in paragraph 73 to prevent unauthorised use of the Client

application, by the Server checking the User Data reported in the Data set, 96. A method as in paragraph 73 to prevent unregistered Clients from requesting service, by the Server authenticating the Client devices.

97. A method as in paragraph 73 to prevent eavesdropping or modification of the Client Server communications, via the use of a secure channel

98. A method as in paragraph 73 to exclude rogue service providers, by the Server selecting service providers from a pre-registered set. A method as in paragraph 73 to prevent eavesdropping, manipulation or man- in-the-middle attacks on server to service provider communications, achieved via conventional IT secure channels.

. A method as in paragraph 73 to provide users safe and trusted service information on Tagged objects.

. A method as in paragraph 73 for service providers to provide users with service information for Tagged objects and to provide information on additional relevant services.

. A method as in paragraph 73 for the service providers and system operators to obtain direct links to users that access Tagged objects.

. A method as in paragraph 73 for the system operator to map service requests to service providers and services based on a commercial model.. A method as in paragraph 73 for the system operator to map service requests to service providers and services based on a performance model.

Claims

CLAIMS:

1. A system for determining a service to offer via a mobile client device, the system comprising:

a mobile client device having device data associated therewith;

wherein:

the tag data does not identify a specific service to be offered;

the client device is operable to obtain tag data from the tag and to send to the server device, over the communications network, a dataset comprising obtained tag data and device data; and

2. A system according to claim 1 , wherein the server data includes attributes of said services and the server is operable to determine said at least one service to offer by assigning a score to each of said plurality of available services and selecting the at least one service to offer based on the assigned scores, wherein the scores are calculated from the received dataset and the service attributes comprised in the server data.

3. A system according to claim 1 or claim 2, wherein the device data includes any one or more of: a unique identifier for a user account associated with the client device; a unique identifier for the client device; location data that indicates the location of the client device; time data; data identifying device type, configuration (e.g. language setting), capabilities and/or operational state of the client device; and data indicating operational state of applications hosted on the client device.

4. A system according to any one of the preceding claims, wherein the server data includes any one or more of: data associated with tags; data associated with client devices; data associated with services; data associated with service providers; data associated with users; logs or histories of previously received datasets; blacklists; usage profiles for client devices, user accounts and/or users.

5. A system according to any one of the preceding claims, wherein the client device data includes location data identifying the location of the client device at the time the dataset is sent to the server and/or at the time the dataset is obtained from the tag; and the server is operable to compare said location with an expected location of the tag.

6. A system according to any one of the preceding claims, wherein the server is operable, having determined a service to offer, to send to the client device, over the communications network, an identifier for the service, whereby the client device can subsequently access the service directly.

7. A system according to any one of the preceding claims, wherein the machine readable tag is a two-dimensional barcode or other optically machine readable representation of data.

8. A system according to claim 7, wherein the tag data includes a tag ID and a message authentication code calculated from the tag ID, and the server is configured to calculate the message authentication code from the tag ID in the received dataset and then compare the calculated message authentication code with the message authentication code in the received data set to check the authenticity of the tag.

9. A system according to any one of claims 1 to 6, wherein the machine readable tag is an RFID device.

10. A system according to claim 9, wherein the tag data includes a hardware identifier (e.g. hardware serial number) bound to the RFID device, a tag ID stored on the RFID device, and a message authentication code calculated from the hardware identifier and the tag ID, and the server is configured to calculate the message authentication code from the hardware identifier and tag ID in the received dataset and then compare the calculated message authentication code with the message authentication code in the received data set to check the authenticity of the tag.

1 1. A method for determining a service to offer via a mobile client device, the method comprising:

sending a dataset from the client device to a server device over a

receiving the dataset from the client device at the server;

and determining at the server at least one service to offer via the mobile client device, said determination being based on the received dataset and server data that identifies a plurality of available services.

12. A method according to claim 1 1 , wherein the server data includes attributes of said services and the server is operable to determine said at least one service to offer by assigning a score to each of said plurality of available services and selecting the at least one service to offer based on the assigned scores, wherein the scores are calculated from the received dataset and the service attributes comprised in the server data.

13. A method according to claim 11 or claim 12, wherein the device data includes any one or more of: a unique identifier for a user account associated with the client device; a unique identifier for the client device; location data that indicates the location of the client device; time data; data identifying device type, configuration (e.g. language setting), capabilities and/or operational state of the client device; and data indicating operational state of applications hosted on the client device.

14. A method according to any one of claims 11 to 13, wherein the server data includes any one or more of: data associated with tags; data associated with client devices; data associated with services; data associated with service providers; data associated with users; logs or histories of previously received datasets; blacklists; usage profiles for client devices, user accounts and/or users.

15. A method according to any one of claims 11 to 14, wherein the client device data includes location data identifying the location of the client device at the time the dataset is sent to the server and/or at the time the dataset is obtained from the tag; and the server is operable to compare said location with an expected location of the tag.

16. A method according to any one of claims 11 to 15, wherein the server is operable, having determined a service to offer, to send to the client device, over the communications network, an identifier for the service, whereby the client device can subsequently access the service directly.

17. A method according to any one of claims 11 to 16, wherein the machine readable tag is a two-dimensional barcode or other optically machine readable representation of data.

18. A method according to claim 17, wherein the tag data includes a tag ID and a message authentication code calculated from the tag ID, and the server is configured to calculate the message authentication code from the tag ID in the received dataset and then compare the calculated message authentication code with the message authentication code in the received data set to check the authenticity of the tag.

19. A method according to any one of claims 11 to 16, wherein the machine readable tag is an RFID device.

20. A method according to claim 19, wherein the tag data includes a hardware identifier (e.g. hardware serial number) bound to the RFID device, a tag ID stored on the RFID device, and a message authentication code calculated from the hardware identifier and the tag ID, and the server is configured to calculate the message authentication code from the hardware identifier and tag ID in the received dataset and the compare the calculated message authentication code with the message authentication code in the received data set to check the authenticity of the tag.

21. A method operable by a server device for determining a service to offer via a mobile client device based on tag data obtained by the client device from a machine readable tag device, wherein the tag data does not identify a specific service to be offered, the method comprising:

receiving a dataset from the client device at the server device, the dataset including said tag data and device data associated with the client device; and determining at least one service to offer via the mobile client device, said determination being based on the received dataset and server data that identifies a plurality of available services.

22. A method operable by a mobile client device for obtaining from a server device an identifier for a service accessible from the mobile client device over a

communications network, the method comprising:

obtaining tag data from a machine readable tag, wherein the tag data does not identify a specific service;

sending a dataset to a server device over a communications network, the dataset including said tag data and device data associated with the client device; receiving the dataset from the client device at the server;