Method of identification, authentication and control of coverage based on the bluetooth tm standard

ES 2 303 464 A1

DESCRIPTION

Identification, authentication and coverage control method based on the Bluetooth® standard.

Object of the invention

The object of the present invention is to define the way in which, in a beacon system that provide Bluetooth coverage^®When they go into coverage, the different terminals are identified, authenticated and provided with services, in addition to how they carry out the control of the status of their coverage.

The present invention falls within the field of telecommunications networks. And more specifically in the identification and authentication of mobile phone users within a beacon system that provide coverage based on the Bluetooth standard.^®.

Background of the invention

It is known that abbreviations and acronyms are frequently used in the field of mobile telephony. Below is a glossary of acronyms / abbreviations, as well as a series of terms that are used throughout this specification and that are defined below:

- RF: radio frequency.

- Bluetooth®: it is the standard that defines a global standard for wireless communication, which enables the transmission of voice and data between different devices through an RF link.

- Beacon: device that provides Bluetooth® coverage to an area and that manages the checking of credentials of the different Users (see Authentication - later).

- Bluetooth® device: mobile device enabled to use Bluetooth®.

- Terminal: mobile device with Bluetooth® capabilities that interacts with the Beacon.

- User: person who uses the Terminal.

- Authentication: it is the process of determining if a User is authorized to carry out a given action. Some authentication systems include both identification and authorization, while others only include one or the other. In this case, given that the objective of the system is simply to identify the User and inform him of his coverage status, only identification will be necessary.

- Coverage: radius of action in which the Beacon is visible to a Terminal.

- Bluetooth® profile: services offered by a Bluetooth® device.

- User Credential: data that identifies a Terminal and that allows it to authenticate successfully against a specific Beacon.

Bluetooth^® It is the standard that defines a global standard for wireless communication, which enables the transmission of voice and data between different equipment through an RF link. This exchange of voice and data is carried out through the execution of the different services available to the devices.

Bluetooth^® defines a Bluetooth device discovery procedure^®. In this way, a Bluetooth® device can “see” that other Bluetooth® devices are within range. This discovery is not automatic on mobile devices or computers, but it is the user who manually (or the application) who must update the list by launching the procedure that the Bluetooth standard^® provides for it. The list includes the name that the user has given to his device, and that can be any string since in a mobile phone the user is free to change the Bluetooth name^® of your device, and also the Bluetooth MAC address^®, a unique identifier of the device given by the manufacturer and that cannot be changed.

Once a Bluetooth device^® You have obtained a list of neighboring devices, that is to say that they are within range of action, you also have the possibility of discovering which services each of its neighbors exposes or of trying to connect directly to a service by means of the service identifier. Again it is the user, or an application, who launches the request. To carry out this task, both devices (both the querying and the queried) must implement the profile "Service Discovery Application (SDAP)" that will provide them with a service discovery service, regardless of redundancy, that both devices will know how to use.

ES 2 303 464 A1

Bluetooth® profiles define the services that a Bluetooth® device exposes and how they should be used. This definition ensures that devices that implement the same profile can communicate without interoperability problems. Examples of profiles follow:

- Generic Access (GAP))

- Service Discovery Application (SDAP)

- Serial port (SPP)

- Dial-up networking (DUN)

Bluetooth® defines, in turn, a procedure for discovering Bluetooth® devices. In this way a Bluetooth device^® You can poll the Bluetoothi1 devices within your reach.

The Bluetooth standard^® defines an authentication procedure based on device pairing. This pairing occurs only the first time that two devices try to connect and is used for users to allow the connection between their Bluetooth devices.^® by entering a common code (PIN). In mobile telephony, it is the user who decides if his device requires this authentication to accept connection requests from other Bluetooth devices^®. If no pairing is required, any other Bluetooth device^®It can connect with the user's mobile phone. It is a procedure, however, quite limited since it does not allow the exchange of additional data (it is neither flexible nor versatile), the exchanged codes do not provide a high level of security and, most importantly, authenticate at the device level , not at the service level, so that once two devices are paired, any of their services can exchange data.

After pairing two Bluetooth devices^® since they can start exchanging data using any of the services they have. Bluetooth® uses a Frequency Hopping system, that is, it changes the frequency at which it emits from time to time, in this way it tries to minimize interference from other systems that emit in nearby bands. Obviously, some synchronization must occur between two connected devices to always use the same frequency at any given time. For this Bluetooth^® It has a service channel called synchronism. Without this channel, communication cannot take place, the loss of the synchronism channel causes the connection to a service to drop.

The invention described in the present invention patent is integrated into a Bluetooth beacon system^®. These beacons are connected to a central entity that provides them with the credentials of its associated users. So we have a system with the following actors:

- A central entity that sends the user credentials both to the terminals and to the beacons that make up the system.

- A network of beacons each providing coverage to a specific area and storing the credentials of all the terminals associated with that beacon.

- A set of terminals (Bluetooth® devices attached to the system, each with a credential for each beacon in which it is authorized.

Beacons continuously search for Bluetooth terminals^® attached to the system, that is, users of the system. The beacons, therefore, must discriminate the attached terminals from the rest of the Bluetooth devices^®. However, the data that Bluetooth^® provided after a device discovery does not allow us to discriminate:

to. The Bluetooth identifier^® The device is defined by the user, therefore it is not unique, and can be changed at any time by the user. Furthermore, it does not provide any information beyond a user name recognizable by the owner.

b. The Bluetooth MAC address^® if it is unique, provided by the manufacturer, but it does not contain information that allows us to identify whether or not the device is a system terminal. To be useful, the system should properly maintain and update a database of Bluetooth MAC addresses^® terminals, which excessively complicates the provision of users.

A terminal detected by the beacon, that is, that has passed the filter and is recognized as an integral part of the system, must immediately know its new coverage status, the beacon, in turn, must control which terminals it has in coverage. Both entities, beacon and terminal must have strict control of coverage (that is, they must instantly know any entry or exit of coverage from the terminal). At the beacon, a procedure based on periodic discoveries of devices could be a valid method to control the entry and exit of terminals in coverage. This same method in the terminal is revealed as unfeasible due to the excessive battery consumption that it would entail.

ES 2 303 464 A1

Once the beacon has detected which are the real users of the system, the beacon and terminals must be able to launch the authentication procedure transparently to the user. This will allow that, upon completion, both entities know if the terminal is in the area defined by a beacon to which it is associated or not. At this point, the standard Bluetooth pairing procedure^® It is necessary as a previous step to the exchange of credentials but cannot be replaced for the following reasons:

to. It cannot be done transparently to the user. The user must enter their PIN on the phone.

b. Cannot add encryption beyond that provided by Bluetooth^® in the transport layer.

c. It is not extensible, we cannot make it send new parameters or data that may be necessary in future versions of the system.

By way of example, US patent application US 2002/141586 is cited, which describes a device and a method capable of communicating with other networks using Bluetooth.^®, including at least one authentication functionality.

Japanese patent application JP-2003-333052 describes a way to provide location-dependent services to mobile terminals, using short-range technology such as Bluetooth.^®. But no special identification and authentication of the mobile terminals is mentioned to receive these position-dependent services.

However, none of the aforementioned antecedents solve the aforementioned problems regarding:

- Identification: Beacons must be able to discriminate their own terminals from other Bluetooth devices^®.

- Coverage control: Between the beacon and the terminal, any entry or exit coverage of the terminal must be known instantly.

- Authentication: The beacon and the terminals must be able to launch the authentication procedure (in a transparent way to the user) that will allow, upon completion, that both entities know if the terminal is in the area defined by a beacon to which it is associated or not.

Description of the invention

The invention refers to a method of identification, authentication and coverage control according to claim

1. Preferred embodiments of the method are defined in the dependent claims.

The present invention refers to the method used to carry out the identification, authentication and coverage control of Bluetooth devices.^® attached to a system consisting of different beacons connected to a central entity that provides them with the credentials of its associated users. So, have us- a system that includes:

- A central entity that sends the User credentials to both the Terminals and the Beacons that make up the system.

- A network of Beacons each providing coverage to a specific area and storing the credentials of all Terminals associated with that Beacon.

- A set of Terminals (Bluetooth® devices attached to the system) each one with a credential for each Beacon in which it is authorized.

For the identification of the terminals, a Bluetooth profile is defined^® that all terminals are required to implement. This profile includes two services: the authentication service, which we will use as a way to exchange user credentials, and the coverage control service, which we will use to monitor coverage losses immediately. Both services have a unique and the same service identifier on all devices.

Once the Bluetooth device^® has been detected by the beacon, it tries to connect to the device's coverage service, using the unique service identifier defined for that service. If the connection request fails, then the Bluetooth® device is not its own terminal. If, on the other hand, the beacon manages to connect to the service identified by said service identifier, the next thing to do is make sure that it is really the coverage control service and not one with the same service identifier. They exchange two messages, one of service available from the beacon to the terminal and another of response from the terminal to the beacon. Once this process is complete, we know if the Bluetooth device^® is, or not, a terminal. In the event that it is, we are connected to your coverage control service.

ES 2 303 464 A1

The advantages offered by this system are, on the one hand, the possibility of discrimination of the terminals from the rest of Bluetooth® devices since the terminals will have (ex factory) certain Bluetooth® services with unique service identifiers, where said identifiers They cannot be changed without reconfiguring the internal software of the terminal that is not accessible to the user. Therefore, it is not possible to leave the terminal undetectable before a beacon by a user.

Another advantage it offers is that the beacon allows to discriminate the terminals from the rest of Bluetooth devices^®with hardly any collaboration from them. This means saving device battery power, which is a critical development parameter in this field of technology.

A third advantage is that the beacon will never attempt to pair with a Bluetooth device^® outside the system, since you must have previously identified the terminal as such. The procedure is as follows:

- If an error occurs when trying to connect to the coverage control service of the Bluetooth® device, the device does not find out and the beacon checks that it was not a terminal.

- If it does not give an error then, and only if it is the first time that both entities have seen each other, Bluetooth® will start the standard pairing procedure. The user will enter the predefined PIN and the process will continue normally until the connection is completed.

The coverage control service is a warning service. In this service, no more data is exchanged after the identification of the terminal. However, both beacon and terminal must monitor the status of said channel very carefully since the moment the terminal goes out of coverage, the Bluetooth synchronism channel^® will fall, the coverage control service, in turn, will also drop, generating an event that both devices will be able to capture (connection error), thus knowing immediately that coverage has been lost.

The advantages offered by the coverage control service are, on the one hand, the simplification of this control, since the monitoring of the coverage service makes unnecessary a system based on pings or on successive executions of the device discovery service, which are more complicated. to maintain and implement.

On the other hand, it allows both the beacon and the terminal to detect coverage losses instantly, capturing the "service connection error" event instead of successively executing the device discovery service or using a ping-based system. with the associated latency errors and with the battery power consumption that it would entail.

Finally, it allows the area under coverage of the beacon to be enlarged since, since there is no data exchange, the disconnection of the coverage service only depends on the availability of the synchronism channel of the system itself, optimized according to the Bluetooth® standard and more stable than a connection with data to be processed and interpreted, such as pings.

Authentication occurs after ensuring that the Bluetooth device^® it is a terminal and ensure your coverage control. The next step is to check if it is a terminal associated with this beacon or not. To do this, the beacon launches the authentication process. That is, it connects to the authentication service that the terminal must necessarily expose, since it is a device associated with the system. Four messages are exchanged in the authentication process:

Message 1: The beacon sends the terminal its beacon identifier, and asks it to send its user credentials.

Message 2: The terminal collects the identifier of the beacon and looks for the credential associated with that identifier.

Once it finds it, it sends it back to the beacon for it to check.

Message 3: The beacon checks the credential against its user database and sends a message back to the terminal, informing it of the result of said check (OK or KO).

Message 4: The terminal finally knows if it is at its beacon and returns an ACK (acknowledgment or acknowledgment) to the beacon.

The advantages of authentication are, firstly, that it defines a single way of exchanging data with the beacon, so that only the terminals can do so in a totally transparent way to the user.

Another advantage is that it is extensible, that is, new parameters can be added to exchange or more security if necessary.

Similarly, it allows additional authentication to Bluetooth pairing.^® defined by the standard. In other words, it allows authentication at the application level, regardless of the application to which it serves with this method. The use of this authentication is, therefore, more flexible, allowing periodic or arbitrary re-authentications to be carried out after a certain time and triggered by the beacon.

ES 2 303 464 A1

Brief description of the drawings

A series of drawings that help to better understand the invention and that expressly relate to an embodiment of said invention that is presented as an illustrative but not limiting example of this invention will now be described very briefly.

Figure 1 shows a diagram of the system with the method object of the present invention implemented.

Description of a preferred embodiment of the invention

As can be seen in the attached figures, the system where the identification, authentication and coverage control method is implemented comprises:

- A central entity: Sends the user credentials both to the terminals [1] and to the beacons [2].

- A network of beacons [2]: Each one provides coverage [3] to a specific area and stores the credentials of all the terminals [1] associated with that beacon [2].

- A set of terminals [1]: The terminals [1] are Bluetooth® devices [4] attached to the system, each one with a credential for each beacon [2] in which it is authorized.

For terminals [1] a profile is defined that includes two services, with a unique and equal service identifier for all devices [4]. These services are:

- The authentication service [5]: It is used as a means of exchanging user credentials.

- The coverage control service [6]: It is used to monitor coverage losses immediately.

When the Bluetooth device^® [4] is detected by the beacon [2], an attempt is made to connect to the coverage service of the device [4], using the unique service identifier service defined by this service. Two things can happen:

- Connection: Then it will make sure that it is really the coverage control service and not one with the same identifier. Two messages are exchanged, one of service available from beacon [2] to terminal [1] and one of response from terminal [1] to beacon [2]. With this we will know if the Bluetooth® device [4] is a terminal [1] of the system itself. In the event that it is, we are connected to your coverage control service [6].

- No connection: The Bluetooth® device [4] is not a terminal [1] belonging to the system.

The coverage control service [6] is a warning service. In this service [6] no more data is exchanged after the identification of the terminal [1], however, both beacon [2] and terminal [1] must monitor the status of the Bluetooth® synchronism channel, since at the time when terminal [1] goes out of coverage [3], this channel will go down, like the service, generating an "connection error" event that both devices [1] and [2] will be able to capture, knowing this so coverage [3] has been lost.

After determining that the Bluetooth® device [4] is indeed a terminal [1], and ensuring its coverage control, the method that is the object of the present invention describes the next stage, which is the process of checking the assignment of the terminal [1] to the beacon [2]. To do this, first, the beacon [2] launches the authentication process, that is, it connects to the authentication service [5] of the terminal [1]. In this process, four messages are exchanged:

Message 1: Beacon [2] sends terminal [1] its beacon identifier [2], and asks it to send its user credentials.

Message 2: The terminal [1] collects the identifier of the beacon [2] and searches for the credential associated with that identifier. Once it finds it, it sends it back to the beacon [2] for it to check.

Message 3: The beacon [2] checks the credential against its user database and sends a message back to the terminal [1], informing it of the result of said check (OK or KO).

Message 4: Terminal [1] finally knows if it is at its beacon [2] and returns an ACK (acknowledgment) to beacon [2].