GB2536698A

GB2536698A - Secure communications between a beacon and a handset

Info

Publication number: GB2536698A
Application number: GB1505209.5A
Authority: GB
Inventors: Stafford Eamon
Original assignee: Individual
Current assignee: Individual
Priority date: 2015-03-26
Filing date: 2015-03-26
Publication date: 2016-09-28
Also published as: GB201505209D0; WO2016151147A1

Abstract

A secure communication channel between a Bluetooth (RTM) beacon and a user device (UD) is established by generating a common Diffie-Hellman (D-H) shared secret on both the UD and the beacon and thereafter using the common D-H shared secret as an encryption key in subsequent encrypted communications between the beacon and the UD. Preferably, the common D-H shared secret is verified using one or both of PKI techniques and pinning techniques. The communications may be encrypted using Elliptic Curve Cryptography. The invention enhances the functionality of beacons so that they can be used in a plethora of applications including those where sensitive information must be transmitted. An application of the present invention is the modification and individualization of tickets normally displayed on a screen of the UD. These tickets can be modified with the D-H shared secret each time they are used so that fraudulent tickets can be detected and rejected.

Description

Intellectual Property Office Application No. GII1505209.5 RTM Date:28 January 2016 The following terms are registered trade marks and should be read as such wherever they occur in this document: QR code Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo -1 - "Secure communications between a beacon and a handset"

Introduction

This invention relates to a method of establishing a secure communication channel between a beacon and a user device. In this specification, user device will be understood to be a Bluetooth®-enabled smartphone or other Bluetooth®-enabled handheld portable communications device carried by an individual.

Beacons are Bluetooth® nodes used by location aware applications Capps"). The beacon co-operates with the app running on a nearby smartphone to indicate to the smartphone precisely where the smartphone is located. The app on the smartphone can then act on that information. For example, the beacon may be operated by a certain retailer and located in the vicinity of their premises. The app on the user's smartphone, on detection of the beacon, can determine if there are any coupons for the retailer associated with that beacon. The app can then display those coupons on a user interface of the smartphone.

Heretofore, the functionality of the beacons has been relatively limited. Generally speaking, the beacons periodically transmit their Unique User Identifier (UUID) into the surrounding environment. A smartphone in the vicinity of the beacon with a suitable app thereon will detect the transmitted UUID and the app then queries a remote database to see whether the UUID corresponds to a beacon of interest to the app. If the beacon is one of interest to the app, the app will thereafter retrieve further data which might be location of the beacon (and hence the smartphone) or special offers being offered by the operator of the beacon. It can be seen that the app does all the heavy lifting and the beacon has very limited functionality.

The applicant herein believes that it would be advantageous to expand the functionality of the beacon. However, one characteristic of beacons limiting the expansion of their functionality is that the communications with the beacon are inherently unsecure. Therefore, there is a reticence to use the beacon for other tasks. It is an object of the present invention to overcome at least some of these problems. -2 -

Statements of Invention

According to the invention there is provided a method of establishing a secure communication channel between a beacon and a user device (UD), the method comprising the steps of: generating a common Diffie-Hellman (D-H) shared secret on both the UD and the beacon; and thereafter using the common D-H shared secret as an encryption key in subsequent encrypted communications between the beacon and the UD.

By having such a method, the communications between the UD and the beacon will be more secure, providing peace of mind to the UD operator that other sensitive information may be exchanged with the beacon. For example, it is envisaged that financial information could now be communicated with a beacon. This will allow the beacon to be used in payment processing or other sensitive transactions.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD comprising the intermediate step of verifying the common D-H shared secret. This is seen as a preferred embodiment of the present invention. By verifying the common D-H shared secret, the method will further protect against potential man-in-the-middle attacks.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the step of verifying the common D-H shared secret comprises using a pinning technique. Preferably, the pinning technique comprises an SSL pinning technique.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the step of verifying the common D-H shared secret comprises using a public key infrastructure (PKI) technique.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the certificate pinning technique comprises secure socket layer (SSL) certificate pinning. -3 -

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the method comprises the initial step of the UD transmitting a prime number, p, to the beacon.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the method comprises the step of the UD transmitting a base number, g, to the beacon.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the common D-H shared secret is passed through a secure hash algorithm (SHA) and the result is used as the common D-H shared secret. By passing the common D-H shared secret through a SHA function, the security of the system will be even further enhanced. The hashing in this step provides a key that can be used to encrypt information in subsequent communications. The shared secret in itself is typically too big to use as an encryption key, (E.g. AES-256 needs a 256bit key -32 characters) so it is advantageous to use SHA-256 on the shared secret to obtain the 32 characters encryption key from the shared secret. It is envisaged that SHA 128 or SHA 512 could also be used as the secure hashing algorithm.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the beacon and the UD pass the common D-H shared secret through an MD5 message digest algorithm to create an initialization vector. The initialization vector value is passed as a secondary check for further validation and protects against a brute force attack.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the method comprises the steps of: the beacon encrypting the common D-H shared secret with a private key of a private-public key pair; (ii) the beacon transmitting the thus encrypted common D-H shared secret to the UD; -4 - (iii) the beacon transmitting a public key of the private-public key pair to the UD; (iv) the UD using the public key to decrypt the encrypted common D-H shared secret; and (v) the UD verifying the authenticity of the beacon by comparing the decrypted common D-H shared secret with the common D-H shared secret generated on the UD.

In this way, the UD can verify the authenticity of the beacon by comparing the decrypted 10 common D-H shared secret with the common D-H shared secret that was generated on the UD. The UD can authenticate the public key of the beacon and ascertain whether or not they have been communicating with a trusted beacon.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which a new common D-H shared secret is generated for each new communication of data between the beacon and UD. This is seen as a particularly advantageous aspect of the present invention. By changing the common shared secret for each new communication of data, the communications between the beacon and the UD will be highly secure and able to withstand attack. Effectively, the encryption of the communications will change for each communication making a successful attack practically impossible. This is made possible by the simplicity and hence speed of the method proposed herein.

In one embodiment of the invention there is provided a method of establishing a secure 25 communication channel between a beacon and a UD in which the subsequent encrypted communications are encrypted using Advanced Encryption Standard (AES) encryption.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the subsequent encrypted communications are encrypted using Blowfish encryption.

In one embodiment of the invention there is provided a method of establishing a secure communication channel between a beacon and a UD in which the subsequent encrypted communications are encrypted using Elliptic Curve Cryptography (ECC) encryption. -5 -

In one embodiment of the invention there is provided a method of generating a secure ticket code between a beacon and a user device (UD), the UD having a ticket code stored thereon, the method comprising the steps of: generating a common Diffie-Hellman (D-H) shared secret on both the UD and the beacon; and modifying the ticket code with the common D-H shared secret thereby generating a secure ticket code. This is seen as a very useful practical application of the present invention. A graphical representation of a ticket can be modified to incorporate a code agreed between the UD and the beacon. The graphical representation of the ticket thus modified will therefore be considered unique as it will change each time with information determined in part by the beacon in its vicinity. This will obviate the possibility of many common fraudulent techniques for ticketing on public transport and the like services where tickets are displayed as codes on the user interface of a mobile device or smartphone. It will no longer be possible to simply take a screenshot of a valid ticket code and for multiple people to use that screenshot of the ticket for their travel.

In one embodiment of the invention there is provided a method of generating a secure ticket code between a beacon and a UD in which the secure ticket code is represented graphically and displayed on a user interface (UI) of the UD.

In one embodiment of the invention there is provided a method of generating a secure ticket code between a beacon and a UD in which the secure ticket code is one of a QR code and a bar code.

Detailed Description of the Invention

The invention will now be more clearly understood from the following description of some embodiments thereof given by way of example only with reference to the accompanying drawings, in which:-Figure 1 is a flow diagram of the method of establishing a secure communication channel between a beacon and a user device according to the invention. -6 -

Referring to the drawing, there is shown a method of establishing a secure communication channel between a beacon and a user device, indicated generally by the reference numeral 1. In step 10, a user device (UD) comes within range of a beacon and receives the unique user identifier (UUID) from the beacon. In response to detecting the presence of the beacon, the UD transmits a prime number, p, to the beacon in step 20.

If desired, the UD may also transmit a base number, g, that is a primitive root modulo p, to the beacon in step 20. Alternatively, the base number g may be pre-agreed by all devices operating the method.

Once the beacon has the p value, the beacon will create a B value specific to the beacon in step 30 and transmits that B value to the UD in step 40. Meanwhile, the UD uses the p value to calculate a U value specific to the UD in step 50 and in step 60, the UD transmits the U value to the beacon. In step 70, both the UD and the beacon are able to calculate a common Diffie-Hellman (D-H) shared secret. In order to create the common D-H shared secret, the UD uses the B value received from the beacon along with the value other than the p value that it used to create the U value. The beacon uses the U value received from the UD along with the value other than the p value that it used to create the B value in order to create the common D-H shared secret. At this stage, indicated by dashed line 75, both the UD and the beacon will have a shared secret and that shared secret may be used as a key of a symmetric encryption algorithm to encrypt and decrypt communications between the UD and the beacon or to modify data being sent between the UD and the beacon. In other words, this level of encryption may be sufficient for some purposes and further encryption building steps or verification steps need not be carried out if this level of security is deemed sufficient.

However, if greater computational simplicity is required, the method can proceed onwards to step 80 in which a secure hash algorithm (SHA), in this case SHA 256, is applied to the common D-H shared secret. This will create a hashed common D-H shared secret that will be more manageable in subsequent processing and encryption.

Then, in step 90, both the beacon and the UD apply a message digest algorithm, in this case MD5, to the hashed common D-H shared secret to create an initialization vector. The initialization vector provides enhanced security against brute force attacks. The Initialisation Vector (IV) is used to ensure that encrypting the same plain text with the same keys always results in a different cipher text. The IV is randomly computed from -7 -the hashed Shared Secret (known by both sides) and is the first packet in the data to be encrypted. Therefore each encryption (the resulting cipher text) will always be different regardless of whether it is the same plain text and key. At this stage, indicated by dashed line 95, both the UD and the beacon will have a hashed shared secret and an initialisation vector for use in subsequent communication steps and this will provide an even greater level of security to an already robust method. It is possible for the method to stop at this point also. In other words, this level of encryption may be sufficient for some purposes and further verification steps need not be carried out if this level of security is deemed sufficient for a given purpose.

However, if there is a concern regarding man-in-the-middle attacks, it may be desirable to conclude with the method steps 100 to 130 inclusive. These method steps entail verifying the common D-H shared secret using a secure socket layer (SSL) pinning technique. In step 100, the beacon uses its private key to encrypt the (hashed) common D-H shared secret. In step 110, the beacon sends that encrypted (hashed) common D-H shared secret to the UD. The beacon may transmit it's public key to the UD or the user device may retrieve the public key of the beacon in step 120. Finally, in step 130, the UD uses the public key of the beacon to decrypt the encrypted (hashed) common D-H shared secret. The UD compares the decrypted value with the value of the common D-H shared secret that it previously calculated and if the values match, then the UD is guaranteed that there is communications between the UD and the beacon and there is no man-in-the-middle.

It will be understood that various modifications may be made to the foregoing embodiment without departing from the invention. For example, it has been suggested that the steps 80 onwards and/or the steps from 100 onwards need not be carried out in certain instances if the level of security does not warrant the computational effort or a more computationally efficient key is not required. It is envisaged that in one aspect of the present invention, the method could comprise a combination of the steps 10 to 70 inclusive and the steps 100 to 130 inclusive, omitting steps 80 and 90. In other words, in such a case, the hashing steps would be omitted and the beacon will encrypt the shared secret rather than the hashed shared secret and the encrypted shared secret would be sent to the UD. The UD will then use the public key of the beacon to decrypt the shared secret received from the beacon and compare it with the shared secret calculated on the -8 -UD. This may be sufficient for certain implementations. However, in light of the small computational overhead of implementing the additional hashing steps, there may be no significant benefit in omitting these steps. Furthermore, it is envisaged in another aspect of the invention, the method could comprise the combination of steps 10 to 80 inclusive (i.e. creating a shared secret and hashing the shared secret for use in subsequent encryption) and in another embodiment, the method could comprise the combination of steps 10 to 90 inclusive (i.e. creating a shared secret, hashing the shared secret for use in subsequent encryption and creating an initialization vector for enhancing security against brute force attacks). The present invention is flexible in this regard.

It will be understood from the foregoing that there is provided a secure communication channel between the beacon and the UD. This opens up a plethora of opportunities for the use of the beacons in heretofore unexplored areas. For example, it is envisaged that one particularly preferred implementation of the present invention is in electronic ticketing.

Many tickets, coupons or reward schemes are now presentable as a digital image on a user interface of a UD. For example, the digital image may comprise a monthly train ticket. There has been a reluctance to roll out this type of ticketing for public transport as it is highly susceptible to fraud in that environment. For example, it is not unknown for unscrupulous individuals to capture the image from another phone, effectively duplicating the ticket, and for both users to derive the benefit of the ticket. Theoretically, many multiples of the original ticket purchaser could duplicate the ticket in this way, resulting in a significant loss in revenue to the train operator. Many of the ticketing machines operate off line and it is not possible for those machines to detect that the ticket has been used already or elsewhere.

This problem can be obviated by placing a beacon in the ticketing barrier or ticket reader that the train user must present their ticket to. According to a preferred implementation of the invention, as the owner of the UD approaches a ticketing barrier, the beacon will be recognised by a ticketing app on their smartphone (UD). The UD and the beacon will agree a common D-H shared secret (which may be hashed and verified if desired) and the resultant value can then be used to encrypt and decrypt communications between the beacon and the UD. In this case, the common D-H shared secret may be used to -9 -modify the ticket stored on the phone so that the ticket will be presented in a unique different form on the user interface of the UD. For example, the ticket may be encrypted or the ticket may have an identifier placed therein. This pictorial representation will be detected by the ticket reader as a genuine ticket modified in the expected manner and the ticket reader with the beacon will be able to decrypt and analyse the ticket. It will be understood that a simple screen shot or other copy of the ticket will not be modified in this manner and will alert the ticket barrier to the fact that the ticket is fraudulent.

It will be understood that the method according to the present invention will be performed largely in software and therefore the present invention extends also to computer programs, on or in a carrier, comprising program instructions for causing a computer, smartphone or a beacon to carry out one or more steps of the method. The computer program may be in source code format, object code format or a format intermediate source code and object code. The computer program may be stored on or in a carrier, in other words a computer program product, including any computer readable medium, including but not limited to a floppy disc, a CD, a DVD, a memory stick, a tape, a RAM, a ROM, a PROM, an EPROM or a hardware circuit. The computer program product may be stored in the memory of a computing device and the present invention is intended to extend to computing devices programmed to implement the method according to the present invention.

It will be further understood that the present invention may be performed on two, three or more machines or components with certain parts of the computer-implemented method being performed by one machine or component and other parts of the computer-implemented method being performed by another machine or component. The devices may be part of a LAN, WLAN or could be connected together over a communications network including but not limited to the intemet. One or more of the method steps could be performed "in the cloud", meaning that remotely located processing power may be utilised to process certain method steps of the present invention. Accordingly, it will be understood that many of the method steps may be performed remotely, by which it is meant that the method steps could be performed either on a separate machine in the same locality or jurisdiction or indeed on a separate machine or machines in one or several remote jurisdictions. For example, the UUID database and the beacon may be in one jurisdiction or located in different jurisdictions. The present invention and claims are -10 -intended to also cover those instances where the method is performed across two or more machines or pieces of apparatus located in one or more jurisdictions and those situations where the parts of the system are spread out over one or more jurisdictions.

In this specification the terms "include, includes, included and including" and the terms "comprise, comprises, comprised and comprising" are all deemed totally interchangeable and should be afforded the widest possible interpretation.

The invention is in no way limited to the embodiment hereinbefore described but may be varied in both construction and detail within the scope of the appended claims