WO2016151147A1

WO2016151147A1 - Secure communications between a beacon and a handset

Info

Publication number: WO2016151147A1
Application number: PCT/EP2016/056743
Authority: WO
Inventors: Eamon STAFFORD
Original assignee: Hynes, Eoghan
Priority date: 2015-03-26
Filing date: 2016-03-28
Publication date: 2016-09-29
Also published as: GB201505209D0; GB2536698A

Abstract

This invention relates to a method of establishing a secure communication channel between a beacon (3) and a user device (UD) (5). The method comprises 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. Preferably, the common D-H shared secret is verified using one or both of PKI techniques and pinning techniques. By implementing such an invention, the functionality of the beacons will be greatly enhanced and they can now be used in a plethora of applications including those where sensitive information must be transmitted. One particularly useful application of the present invention will be the modification and individualization of tickets normally displayed on a screen (7) of the UD. These tickets (9) can be modified each time they are used so that fraudulent tickets can be detected and rejected.

Description

Title of the Invention:

"Secure communications between a beacon and a handset" Technical Field:

This invention relates to a method of establishing a secure communication channel between a beacon and a user device without the need for device interaction by a user. In this specification, user device will be understood to be a non-paired Bluetooth® 4.0 and above (BLE) enabled smartphone or other non-paired Bluetooth© 4.0 and above (BLE) enabled handheld portable communications device carried by an individual.

Background Art: Beacons are Bluetooth© nodes used by location aware applications (^"apps"). 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 within or 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 UUI D 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 reluctance to use the beacon for other tasks.

The Bluetooth (Registered Trade Mark) Core Specification Version 4.2, available from www.bluetooth.org/en-us/specification/adopted-specifications. provides for encrypted communications over Bluetooth however in order to do so, it is necessary to first of all pair the devices before encrypted communications can commence. WO2009/078784 entitled "System for receiving and transmitting encrypted data" in the name of Bjorhn et al describes a method in which encrypted data may be transmitted with the aid of Bluetooth. US2015/0049871 entitled "Systems and Methods for implementing Bluetooth low energy communications" in the name of Xie et al describes a method in which encrypted data may be transmitted with the aid of a Bluteooth Low Energy (BLE) connection. Importantly, it is necessary for the devices to be paired in advance of the encrypted communications and this limits the functionality and usefulness of the approaches.

It is an object of the present invention to overcome at least some of these problems.

Summary of Invention:

According to the invention there is provided a method of autonomously establishing a secure communication channel between a beacon and a non-paired 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. By autonomously, what is meant is that the method is executed without the need for device intervention by a user. For example, the user will not be required to input a code into the UD as would be the case when pairing a user device with another device over Bluetooth. Furthermore, it will be appreciated that the user device is "non-paired". In other words, the beacon and the user device are not paired together in the traditional sense understood in the field of Bluetooth and therefore there will have been no prior pairing steps undertaken by the user of the UD to pair the UD with the beacon.

In one embodiment of the invention there is provided a method of autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired UD in which the step of verifying the common D-H shared secret comprises using a pinning technique. Preferably, the pinning technique comprises a Secure Socket Layer (SSL) pinning technique.

In one embodiment of the invention there is provided a method of autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired UD in which the pinning technique comprises SSL certificate pinning.

In one embodiment of the invention there is provided a method of autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired 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. This is due to the fact that the hashing function will effectively digitally sign the transaction which can be used for non-repudiation purposes. 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 autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired UD in which the method comprises the steps of:

(i) 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;

(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 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 autonomously establishing a secure communication channel between a beacon and a non-paired 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. It will be understood that by communication of data, what is meant is a substantive communication of data between one of the beacon and the UD and is not to be confused with those communications between the beacon and the UD used to generate or share an encryption key.

In one embodiment of the invention there is provided a method of autonomously establishing a secure communication channel between a beacon and a non-paired 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 autonomously establishing a secure communication channel between a beacon and a non-paired UD in which the subsequent encrypted communications are encrypted using Blowfish encryption.

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

In one embodiment of the invention there is provided a method of autonomously generating a secure ticket code between a beacon and a non-paired 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 autonomously generating a secure ticket code between a beacon and a non-paired UD in which the secure ticket code is represented graphically and displayed on a user interface (Ul) of the UD.

In one embodiment of the invention there is provided a method of autonomously generating a secure ticket code between a beacon and a non-paired UD in which the secure ticket code is one of a QR code and a bar code. Brief Description of the Drawings:

The invention will now be more clearly understood from the following deschption of some embodiments thereof given by way of example only with reference to the accompanying drawings, in which:-

Figure 1 is a diagrammatic representation of a beacon and a user device communicating with each other; Figure 2 is a flow diagram of the method of establishing a secure communication channel between a beacon and a user device according to the invention;

Figure 3 is a flow diagram of an alternative method of establishing a secure communication channel between a beacon and a user device according to the invention;

Figure 4 is a flow diagram of a second alternative method of establishing a secure communication channel between a beacon and a user device according to the invention;

Figure 5 is a flow diagram of a third alternative method of establishing a secure communication channel between a beacon and a user device according to the invention; Figure 6 is a flow diagram of a fourth alternative method of establishing a secure communication channel between a beacon and a user device according to the invention;

Figure 7 is a flow diagram of a fifth alternative method of establishing a secure communication channel between a beacon and a user device according to the invention; and

Figure 8 is a view similar to Figure 1 showing the user device and beacon communicating with each other in a ticketing system . Detailed Description of the Drawings:

Referring to the drawings and initially to Figure 1 thereof, there is shown a system in which the method according to the invention may be carried out, indicated generally by the reference numeral 1 . The system 1 comprises a beacon, 3 and a user device, in this case a Bluetooth (RTM) - enabled smart phone 5. The beacon 3 and the user device (UD) 5 communicate with each other (as indicated by arrows) using Bluetooth Low Energy (BLE) communications. Referring now to Figures 2 to 7 inclusive, there are shown a plurality of flow diagrams of methods of establishing a secure communication channel between a beacon and a user device, indicated generally by the reference numerals 200, 300, 400, 500, 600 and 700 respectively. It will be understood that many of the steps overlap and for simplicity, like steps have been given the same reference numeral as before.

Referring first of all to Figure 2, 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, 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 (as illustrated in Figure 3) 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.

Referring now to Figure 4, there is shown a further step, step 90, added after the steps 10 to 80 shown in Figure 3. 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 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, 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, as illustrated in Figures 5 to 7 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 1 10, 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. In Figure 5, the steps 100 to 130 inclusive have been appended to the method steps illustrated in Figure 4. In Figure 6, the steps 100 to 130 inclusive have been appended to the method steps illustrated in Figure 2, and in Figure 7, the steps 100 to 130 inclusive have been appended to the method steps illustrated in Figure 3. It will be understood that depending on the criteria of the user, i.e. depending on the requirements of the user regarding the level of security, data processing efficiency, speed, security risk and complexity, one of the methods illustrated in Figures 2 to 7 inclusive may be provided.

In other words, it will be understood that various modifications may be made to the foregoing, preferred embodiment shown in Figure 4 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 (as illustrated in Figure 6), 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 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) (as illustrated by Figure 3) 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) as illustrated in Figure 4. 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.

Referring now to Figure 8, 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 3 (which is a component of the ticketing barrier (not shown)) will be recognised by a ticketing app on their smartphone (UD) 5. 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 modify the ticket stored on the phone so that the ticket will be presented in a unique different form on the user interface (Ui) 7 of the UD 5. For example, the ticket may be encrypted or the ticket may have an identifier placed therein before being graphically represented on the UI. The ticket is shown graphically represented as a Quick Response Code (QR code) 9. 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 internet. 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 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.

Claims

s:

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired user device (UD) (5), 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.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claim 1 comprising the intermediate step of verifying the common D-H shared secret.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claim 2 in which the step of verifying the common D-H shared secret comprises using a pinning technique.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claims 2 or 3 in which the step of verifying the common D-H shared secret comprises using a public key infrastructure (PKI) technique.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claim 3 in which the pinning technique comprises a Secure Socket Layer (SSL) pinning technique.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claim 5 in which the pinning technique comprises SSL certificate pinning.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim in which the method comprises the initial step of the UD (5) transmitting a prime number, p, to the beacon.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claim 7 in which the method comprises the step of the UD transmitting a base number, g, to the beacon.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim in which the common D-H shared secret is passed through a secure hash algorithm (SHA) and the hashed result is used as the common D-H shared secret.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim 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.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim in which the method comprises the steps of:

(i) 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;

(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. A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim in which a new common D-H shared secret is generated for each new communication of data between the beacon and UD.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any preceding claim in which the subsequent encrypted communications are encrypted using Advanced Encryption Standard (AES) encryption.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in any of claims 1 to 12 in which the subsequent encrypted communications are encrypted using Blowfish encryption.

A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) as claimed in claims 1 to 12 in which the subsequent encrypted communications are encrypted using Elliptic Curve Cryptography (ECC) encryption.

A method of autonomously generating a secure ticket code between a beacon (3) and a user device (UD), the non-paired UD (5) 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.

A method of autonomously generating a secure ticket code between a beacon (3) and a non-paired UD (5) as claimed in claim 16 in which the secure ticket code (9) is a represented graphically and displayed on a user interface (Ul) (7) of the UD.

A method of autonomously generating a secure ticket code (9) as claimed in claim 17 in which the secure ticket code is one of a QR code and a bar code. (19) A method of autonomously establishing a secure communication channel between a beacon (3) and a non-paired UD (5) substantially as hereinbefore described with reference to and as illustrated in the accompanying drawing. (20) A method of autonomously generating a secure ticket code between a beacon (3) and a non-paired UD (5) substantially as hereinbefore described with reference to and as illustrated in the accompanying drawing.