Access control

Abstract

Methods and systems of access control are disclosed in which a user device 206 such as a smartphone is used as a credential for accessing one or more secure areas. The user device is authenticated and provided 214 with time-limited access codes which are updated from time to time. The user device is further arranged to make an additional determination 222 of whether access should be approved (beyond simple possession of the user device) before providing 226 an access code to an access control device 202.

Description

[0001] ACCESS CONTROL

[0002] The present invention relates to methods and systems of electronic access control.

[0003] Electronic access control systems are known in which a user presents a credential to a reader, a controller determines whether the credential is valid and, if so, allows the user through a door or other barrier into a secure area.

[0004] The credential might be a swipe card, a bar or QR code, a Radio Frequency Identification (RIFD) tag and so on.

[0005] Increasingly, credentials may be stored in software carried on a mobile phone or other user equipment (UE). A typical access scenario entails the UE or user device receiving a unique message identifying an access point, transmitting that message to a remote server, receiving an access code from the server and conveying that access code (also known as an Auth token) to the access point. The access point then authenticates the access code and, assuming that this step is successful, will allow access. Further encryption steps are usually performed to protect the messages while being sent over wireless links and public / private key encryption and signing may be used to verify the identity of the UE and / or user.

[0006] This process is rather cumbersome and time-consuming which causes inconvenience to the user. It is also prone to difficulties arising from limits to cellular radio coverage. One solution for a controlled door located outside of cellular data coverage is that the control unit of the access point associated with the door contains a database of all valid users. This has two main disadvantages; 1) additional cost at the door, 2) there will be a limit to the number of users at that door (the memory has a finite size).

[0007] United States patent US6353899 discloses a system in which biometric authentication (e.g. a fingerprint) is required to provide access. However, the biometric authentication is required for every single access which can be cumbersome for a user.

[0008] It is an object of the present invention to ameliorate these problems.

[0009] According to a first aspect of the present invention, there is provided: a computer-implemented method executed at a user device arranged to interact with an access switch responsive to an access code, the method comprising;

[0010] 1. authenticating the user device in response to communications received from a server,

[0011] 2. receiving, from a server, at least one time-limited access code for one or more access locations,

[0012] 3. receiving an identity of an access location,

[0013] 4. determining whether an access code for the access location is stored on the user device,

[0014] 5. determining whether at least one stored access condition is met,

[0015] 6. and, in response to the presence of an access code and the at least one stored access condition being met, transmitting a locally-stored access code to the access switch or

[0016] 7. in response to the at least one stored access condition not being met, further comprising an additional authentication step as a precondition to transmitting an access code to the access switch.

[0017] An important element, therefore, is that an instant decision regarding whether the user is authorized to access the location is made locally by the user's device, not at the access switch or remotely at a controller or server. In other words, there is an additional test applied locally at the UE beyond simple possession of the device, improving convenience and giving the user a very smooth experience. If the additional test is failed, then a further authentication step is performed at the user's device. This provides a security system having at least two tiers of security which can be better tailored to manage risk and convenience. For example, if the user's device is presented during working hours then access may be automatically provided. If the device is presented outside of working hours, when there may be few or no people present to challenge an interloper, then a further authentication step is required. This provides a balance between convenience and risk which can be customized to local requirements. Further tiers may be provided, for example using Boolean operators as discussed below.

[0018] In a security setting, however, the unintended consequence of convenience can be a weakening of security. This is addressed in the present case by both limiting the validity of the access codes and requiring a further condition to be satisfied. By not providing updated access codes to a compromised or suspect user device, access can be revoked quickly and easily. The stored access condition might comprise a time limitation such as only allowing access during working hours. If the stored access condition is not met, then a further authentication step is performed at the user's device. For example, the access test may comprise a time limit such as a limit to working hours and the additional authentication step may comprise a biometric test such as presenting a fingerprint to the user's device. The nature of the access test and the additional authentication step can be selected to suit the circumstances. For example, the access test may be arranged to limit access to times when a manager is on the premises. The user's device may be informed whether a manager is present during a two- way communication with the access switch. Several further conditions may be combined, for example access may be permitted during working hours OR if a manager is on the premises. This could be useful in the scenario where only a manager is able to disarm a security alarm to prevent other staff entering the building and being unable to disarm the alarm. A flag could be set to indicate that a manager was in the building and this flag could be set to clear at a particular time, such as midnight.

[0019] Also, by facilitating the installation of one or more apps on the user's device and authenticating the device, the problem of numerous credentials is addressed without compromising security and by making the access decision on the user's device the speed and reliability of the process is enhanced.

[0020] The step of receiving an identity of an access location preferably comprises receiving a short-range radio signal, meaning a signal having a range of a metre or less, preferably 30cm or less, more preferably 20cm or less a most preferably 10cm or less. The signal is preferably a Near Field Communication (NFC) signal. This is probably the most convenient for a user since all they have to do is bring their device within range of a radio beacon (typically 4cm for NFC) located near the access point. Alternatively, however, the location may be identified by an optical code such as a barcode or QR code, an identifier entered by the user via a user interface or by precise geolocation of the user device. Preferably, one or more of these alternatives may be provided as an alternative to the short- range radio signal to allow access to UEs that are not equipped with Near Field Communication transceivers. The app on the user's device will then respond to one or the other identification technique as appropriate.

[0021] The step of determining whether a user is entitled to access the location may be based on time. For example, a user may be authorised to access a particular location between 8am and 6pm on weekdays but not at other times. Alternatively, or in addition, a user may only be allowed to access the location a limited number of times per day. Other examples are; Only being allowed to access the door if the intruder alarm has been disarmed, or if a manager is on-site, or if the air-quality is good etc. Again, further conditions such as these may be combined in a Boolean fashion, such as: the air quality is good AND (a manager is on-site OR the access attempt is during working hours). To provide improve security, further authentication steps are required under certain conditions such as when a UE is presented at certain times. For example, the method may further comprise asking a user for a PIN or biometric identification if the UE is presented to the lock between 6pm and 8am or at the weekend. This guards against a malicious user accessing a building or facility when there might be few, or no, other people around to challenge them.

[0022] The step of receiving the identity preferably includes receiving a challenge code and the step of transmitting the access code preferably comprises applying encryption to a received challenge code. The access code is preferably generated from a locally-stored code and the identity of the access location.

[0023] The locally-stored access code(s) preferably comprise time-limited access codes and further preferably, these are updated regularly to improve security. By limiting the validity of the codes, the possibility of a replay attack is reduced. The codes may conveniently be updated at a frequency between every 5 minutes and every day. This provides a good compromise between security and resources required for the updating process although longer periods of, for example, two days or a week may also be used.

[0024] The locally-stored codes may include at least one code with a longer validity to address the situation in which the lock is out of cellular coverage.

[0025] The method preferably further comprises encrypting an access code using a private key for a user device. This ensures that the genuine user device is being presented as a credential.

[0026] According to a second aspect of the present invention there is provided a computer-implemented method of provisioning a software routine on a user device to generate codes for activating an access switch, the method comprising:

[0027] 1. receiving an authority public key from an authority,

[0028] 2. generating an app public / private key pair,

[0029] 3. transmitting the app public key to the authority,

[0030] 4. receiving a code from the authority,

[0031] 5. encrypting the code received from the server using the app private key and the authority public key to generate encrypted data,

[0032] 6. sending the encrypted data to the authority, and 7. receiving a signature from the authority.

[0033] This provides an efficient but secure provisioning process for the user device.

[0034] Although the software may be pre-installed on the user device, the provisioning method preferably further comprises installing the software routine on the user device.

[0035] The lock, or access control switch is preferably a low-cost device without access to an internet connection. There is no requirement to send further keys to the access control switch. The access control switch will have the authorities' public key (set during manufacture), and will use this to verify the authenticity of any data it receives.

[0036] The skilled reader will appreciate that certain steps of the described and claimed methods may be reordered without affecting the effectiveness or security of their operation.

[0037] The present invention will now be described by way of example, with reference to the accompanying drawings, in which:

[0038] Figure 1 shows a block schematic diagram of an access arrangement according to embodiments of the present invention,

[0039] Figure 2 shows a sequence of events in an access method according to an embodiment of the present invention,

[0040] Figure 3 shows a sequence of events for provisioning an access control switch,

[0041] Figure 4 shows a diagram according to another embodiment of the present invention, and

[0042] Figure 5 shows a sequence of events for provisioning an access control app.

[0043] Figure 1 shows a system 100 for managing access to a secure area, the system comprises a controller 102, a mobile phone (or UE) 104 and a door switch 106. The controller 102 and switch 106 are designed to be located on the secure side of a wall or other barrier 114. The UE is loaded with an app which manages the user's access to the secure area. The UE is capable of receiving a message 108 from the controller 102 and transmitting one or more messages 110 to the controller. Assuming that access is permitted, the controller will send a message 112 to the switch 106 to effect access. The UE is in communication, at least sometimes, with a security server via the internet. Further features (not shown) will be apparent to the skilled reader such as warning lights for success or failure of an access attempt and an exit button (meaning that no credential or authorization is necessary to leave the secure area). The functions of the controller 102 and switch 106 may be combined as an access control switch. The sequence and nature of the communications between the UE and the controller will be described in more detail below.

[0044] Figure 2 shows a first sequence 200 of method steps illustrating an access interaction between a user equipment and the controller or access control switch. The skilled reader will appreciate that the precise order of some of the steps may vary without jeopardizing either the security or ease-of-use of the system.

[0045] There are four participants in the process: an access control switch 202, a Near Field Communication (NFC) tag 204, a user device 206 and a security server 208.

[0046] At step 210, the user device requests one or more access codes (also known as Auth tokens) from the server 208. This step may be triggered periodically, by expiry of existing stored codes or in response to the user device connecting to the internet. At step 212, the server determines whether the user device is entitled to the requested codes and, if so, sends the requested codes to the user device at step 214. The user device stores the codes at step 216.

[0047] Later on, the user may be outside of cellular or other network coverage and wishes to access a secure area. The secure area is protected by the access control switch and is provided with a specific NFC tag 204 which identifies the location. The user taps his or her device onto the NFC tag and the user device receives the location ID at step 218. The security app then checks whether there are any codes stored on the device for that location at step 220. Assuming that there is at least one relevant code, the app then checks a further condition at step 222. This may comprise time of day, whether a security alarm is disarmed, whether a manager is on-site or various combinations of further conditions. A further, optional, check on conditions may be performed by the user device at step 224. Such a condition may be for the user to enter a PIN code or to provide biometric data such as an eye-scan or a fingerprint scan.

[0048] Once the app has determined that all necessary conditions are met, it will transmit the access code to the access control switch at step 226. One suitable link for this is a short-range packet-based messaging service such as Bluetooth ™ Low Energy (BLE). For simplicity, the app on the user device may transmit the code as a BLE advertisement (i.e. a one-way transmission to the access control switch). A richer transaction may be had between the app and the switch, however, by establishing a full bidirectional connection. This transaction may be used to inform the user device of one or more conditions that play a role in whether or not to provide access to the user. One example is an indication that a manager is present and another might be whether the air quality in the protected area is adequate. This bi-directional transaction could also provide further features such as include acknowledgment of a successful access attempt, live data for the for the door state and door relocked. It could also include an explanation for a failed access attempt.

[0049] After receiving the access code, the access control switch will decrypt the code at step 228 (for example by decrypting the code using the security company's public key) and verify the code at step 230. The verification preferably comprises checking that the access code has not expired. If the code is valid, the access control switch opens the door at step 232.

[0050] There is no requirement for many access codes to be stored at the access control device for comparison purposes because the expiry time (or, more broadly, validity) of the Auth tokens is protected by the private key of the security company. Provided that the Auth token, after decryption using the security company's public key, is valid then the user can be permitted to access the controlled area.

[0051] A number of modifications may be applied to the described sequence. For example, the NFC ID may be replaced by:

[0052] An alternative short range wireless signal

[0053] An optical code such as a barcode or QR code which is read by a camera on the UE An alphanumeric code which the user can enter into the app on their UE A highly precise geolocation

[0054] The embodiment of Figure 2 is convenient and easy for the user but does have a weakness: namely by storing Auth tokens at the user's device, it is vulnerable to theft of the Auth token(s) stored thereon. The tokens have limited life, which provides some protection, but they must live at least as long as the longest permissible period between internet connectivity of the user device and an access attempt.

[0055] Figure 4 shows a more secure embodiment of the present invention which only allows access for an Auth token presented by the authorised device. As for Figure 2, there are four participants in the process: an access control switch 602, a Near Field Communication (NFC) tag 604, a user device 606 and a security server 608. The app on the user device further has a public / private key pair which are used to verify the device as follows.

[0056] During production the security server (or servers) will acquire the access control switch's public key and the access control switch will acquire the security server's public key.

[0057] During the commissioning of the users' device, it will have a signature generated by the security servers (described further with reference to Fig. 5). This allows the device to pass its public key to the access control switch, and that access control switch can verify that the public key is genuine.

[0058] The skilled reader will appreciate that certain of the following steps may be performed in a different order without compromising either convenience or security.

[0059] At step 610, the user device requests one or more access codes (also known as Auth tokens) from the server 608. This step may be triggered periodically, by expiry of existing stored codes or in response to the user device connecting to the internet. At step 612, assuming that the user device is entitled to the requested code(s), the server generates at least one access code and encrypts it using the public key of the user device. It then sends the encrypted codes to the user device at step 614 and the user device stores the codes at step 216.

[0060] Later on, the user device is outside of cellular and other network coverage and wishes to access a secure area. The secure area is protected by the access control switch and is provided with a specific NFC tag. The user device reads an ID from the NFC tag at step 618 in response to the user tapping or touching their UE to the tag. The security app then checks whether there are any codes stored on the device for that location at step 620. Assuming that there is at least one relevant code, the app then checks a further condition at step 622. This may comprise time of day, whether a security alarm is disarmed, whether a manager is on-site or various combinations of conditions. A further, optional, check on conditions may be performed by the user device at step 624. Such a condition may be for the user to enter a PIN code or to provide biometric data such as an eye-scan or a fingerprint scan.

[0061] At step 626, the user device requests a challenge code from the access control switch 602 which in generated at step 628 and returned at step 630. Alternatively, the access control switch could periodically broadcast challenge codes as part of a beacon signal. At step 632, the user device encrypts the challenge code from the access control switch and the access code from the server using its private key and at step 634 it transmits this package to the access control switch.

[0062] At step 636, the access control switch decrypts the package using the public key of the user device and at step 638 further decrypts the package using the public key of the security company. At step 640 the access control switch verifies the access code and at step 642, if appropriate, opens the door.

[0063] If the "open door" command is determined at step 640 to be invalid, then the access control switch will compare, at step 640, the received package and decrypt the package with the previous challenge code. This is to cover the scenario in which the user device read a challenge code from the access control switch just before it changed or "rolled over". If this "open door" command is now determined to be valid then processing continues to step 642 and the door is opened.

[0064] It is worth noting that the specific data that is encrypted may comprise a very wide variety of information. It could well be the entire auth token content, but doesn't have to be. The key thing to note is that if the access control switch receives some data from the user's device, only the switch will be able to decrypt it (because it has the relevant private key). The user's device is relaying information that was encrypted by the server(s) using the switch's public key so the switch and only the switch will be able to decrypt it.

[0065] The switch obtains the public key of the user's device from the device itself, and it is proved genuine by the device also sending the signature for the public key, which was generated by the security servers (see Figure 5 below). Once the switch has this, it can use it to verify the signature of anything the user's device itself chooses to sign.

[0066] A number of modifications may be applied to the described sequence. For example, the NFC ID may be replaced by:

[0067] An alternative short range wireless signal

[0068] An optical code such as a barcode or QR code which is read by a camera on the UE

[0069] An alphanumeric code which the user can inter into the app on their UE

[0070] A highly precise geolocation

[0071] To summarise, Auth Tokens are issued to a users' device (when in an area with cellular coverage) and the Auth Token(s) will include the door identity and also the identity of any associated Bar / QR code, NFC tag etc. associated with the door. The association will have been established in software when the system was commissioned.

[0072] Two possible use cases are:

[0073] 1) The access control switch transmits the door identity via a beacon. The user's device receives the door identity and sends an unlock request (auth token) using, for example, Bluetooth Low Energy (BLE) to the access control switch, addressed by the door identity.

[0074] 2) The user's device scans Bar / QR code or a near field communication (NFC) identity close to the relevant door. The device then searches its cache of auth tokens to find one with 'associated identity' that matches. The device then reads Door ID and sends an unlock request (auth token) using BLE to the access control switch, addressed by the door identity.

[0075] Figure 3 illustrates the process 300 of provisioning an access control switch using Rivest-Shamir- Adelman (RSA) encryption. There are two entities, the manufacturer 302 and the access control switch 304. The manufacturer has a private key 306 stored in a secure vault and a corresponding public key 308 which is shared with the switch. The switch generates its own private key 312 and corresponding public key 310 which is shared with the manufacturer.

[0076] The manufacturer then creates a signature 314 from the manufacturer's private key 306 and the switch's public key 310. The signature is then sent to the switch 304 which can verify the signature using the manufacturer's public key 308 and the switch's private key 312. Once provisioned, therefore, the access control switch can provide its public key 310 and the signature 314 to other elements of the access infrastructure. These elements, for example an app installed on a UE, will have a copy of the manufacturer public key allowing them to verify that the manufacturer has signed the switch 304 and the validity of the lock's public key.

[0077] It is preferred to use a minimum of 2048bit encryption keys.

[0078] Thanks to the use of public / private keys, the provisioning process may be conducted as part of the switch manufacture.

[0079] Figure 5 shows a process 500 whereby a manufacturer 502 initializes an app on a UE 504. The app may be pre-installed in the UE but will more typically be downloaded and installed from an app store. The manufacturer has a private key 506 stored in a secure vault and a corresponding public key 508 which is shared with the app (or may be hard coded into the app). The app generates an app public key 510 and a corresponding private key 512. The app public key is shared with the manufacturer. The app receives a verification code 514 from the manufacturer via a suitable channel such as SMS or email. This code is only valid for a predetermined time. The app then encrypts the verification code using the manufacturer's public key 508 and its own public key 510 to generate encrypted data 516. This is shared with the manufacturer.

[0080] The manufacturer then decrypts the encrypted data 516 with its private key 506 and verifies that the code 514 is correct. The manufacturer then generates a signature 518 for the app's public key 510. The app can then authenticate itself to other elements of the access control infrastructure.

[0081] We now describe an example of the access code or Auth token used to activate the access control switch.

[0082] AUTH TOKEN

[0083] {

[0084] Issuer: <issuer name>

[0085] Issued: <date-time>

[0086] Expires: <date-time>

[0087] Door: <switch identity>

[0088] Constraints: <access-rules>

[0089] }

[0090] {

[0091] Algorithm: <signing-algorithm>

[0092] Signature: <signature>

[0093] }

[0094] The constraints field is a convenient way of storing the rules that govern access to the door (and which are enforced by the app on the UE). For example, the token could be valid for a week but only allow access during working hours.

[0095] The signature block is computed over the data block and is signed by the manufacturer or issuer, not by the UE or app.

[0096] Advantageously, further fields may be provided in the token as follows: A key hash so that the receiver can determine which of the issuer's keys was used to sign the token, and

[0097] The identity of the user, if possession of the token (phone) is not sufficient in itself. The identity may be required only when access is attempted at unusual times.

[0098] A "valid from" field so that a token may be issued before its period of validity. This could be used to prevent access to a user until such time as they are permitted

[0099] We now describe an unlock request in JSON terms for ease of understanding:

[0100] {

[0101] "Requestld": "123-999",

[0102] "AuthToken": {

[0103] "Issuer": "123456@control.manufacturer.com",

[0104] "ValidDate": 771638400,

[0105] "ExpiryDate": 771724800,

[0106] "Switchld": 123456,

[0107] "Keyld": "key#l",

[0108] "UserKey": {

[0109] "Algorithm": "SHA256-EDCSA256",

[0110] "Content": "gsgkkjfShYF=" },

[0111] "Constraints": "Mon 08:00-18:00" },

[0112] "Signature": {

[0113] "Algorithm": "SHA256-EDCSA256",

[0114] "Content": "SGkgdGhlcmUuCg==" }

[0115] "IdProof": {

[0116] "Algorithm": "SHA256-EDCSA256",

[0117] "Content": "SGkgdGhlcmUuCg==" }

[0118] }

[0119] All "content" properties are shown as (short) base 64encoded strings.

[0120] The dates are measured in seconds from 1 January 1999 so the validity of the token is 24 hours.

[0121] If the "UserKey" property is present in the "AuthToken", it is a public key. In that case, the sender (phone) must add an "IdProof" block as shown to prove it owns the corresponding private key.

[0122] The Constraint is simply an example.

[0123] For ease of understanding, the messages above have been shown in JSON format. However, Bluetooth™ Low Energy (BLE) has limited bandwidth and representing data in ASCII code (e.g. using JSON or YAML) is inefficient. To convey the messages, they are preferably represented as Combined Binary Object Representation (CBOR), which is an IETF standard aimed at loT devices. The reference is RFC 8949 whose abstract states:

[0124] The Concise Binary Object Representation (CBOR) is a data f ormat whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.l and Messagepack.

[0125] Any JSON or YAM L document can be represented in CBOR but it does have the admitted disadvantage of not being human-readable.

[0126] We give some more detail on data transmission as follows:

[0127] ► BLE has a limited message length

[0128] ► Messages may reach 200-300 bytes, depending on key sizes

[0129] ► MTU (maximum transmission unit) varies between implementations

[0130] ► SiLabs BLE stack limits it to approx. 240 bytes

[0131] ► Phone implementations may have lower limits

[0132] ► Fragmentation scheme required

[0133] ► We need to indicate the AsyncAPI "channel" when sending messages

[0134] ► Light-weight encapsulation using the first byte:

[0135] ► Values 0..127 indicate the channel (or message type)

[0136] Values 128..255 reserved for fragmentation management.

[0137] The messages in the preferred embodiment comprise information according to the AsyncAPI standard. More information can be found here

[0138] The elements of AsyncAPI are similar to an OpenAPI, but it has some additional features regarding the accommodation of an event. It supports many messaging protocols and transports, including WebSockets, Kafka, STOMP, JMA, AMQP, MQ.TT, and HTTP, along with event schema format.

Claims

CLAIMS1. A computer-implemented method executed at a user device arranged to interact with an access switch responsive to an access code, the method comprising; authenticating the user device in response to communications received from a server, receiving, from a server, at least one time-limited access code for one or more access locations, receiving an identity of an access location, determining whether an access code for the access location is stored on the user device, determining whether at least one stored access condition is met, and, in response to the presence of an access code and the at least one stored access condition being met, transmitting a locally-stored access code to the access switch or in response to the at least one stored access condition not being met, further comprising an additional authentication step as a precondition to transmitting an access code to the access switch.

2. A computer-implemented method as claimed in claim 1, wherein receiving an identity of an access location comprises at least one of receiving a short-range radio signal, reading an optical code or receiving a code via a user interface.

3. A computer-implemented method as claimed in claim 2, wherein the receiving an identity of an access location comprises receiving a short-range radio signal.

4. A computer-implemented method as claimed in claim 3, wherein receiving a short-range radio signal comprises receiving a Near Field Communication signal.

5. A computer-implemented method as claimed in claim 3 or claim 4, further comprising alternatively receiving an identity of an access location by reading an optical code or receiving a code via a user interface.

6. A computer-implemented method as claimed in claim 5, wherein alternatively receiving the identify of an access location comprises reading a 2-dimensional optical code.

7. A computer-implemented method as claimed in any one of the preceding claims, wherein the at least one stored condition comprises a time limit.

8. A computer-implemented method as claimed in any one of the claims 1 to 7 , wherein the at least one access condition includes a maximum number of accesses.

9. A computer-implemented method as claimed in any one of the preceding claims, wherein transmitting a locally-stored access code to the access switch comprises encrypting a locally stored access code prior to transmission.

10. A computer-implemented method as claimed in claim 9, wherein the step of encrypting the locally-stored access code includes the identity of the access location.

11. A computer-implemented method as claimed in any one of the preceding claims wherein the locally-stored access codes comprise time-limited access codes.

12. A computer-implemented method as claimed in claim 11, wherein the time-limited access code has a lifetime of one week or less.

13. A computer-implemented method as claimed in claim 12, wherein the time-limited access code has a lifetime of two days or less.

14. A computer-implemented method as claimed in claim 11, wherein the time-limted access code has a lifetime of between 5 minutes and 24 hours.

15. A computer-implemented method as claimed in any one of the claims 11 to 14, further comprising downloading at least one further access code in response to the expiry of a locally-stored access code.

16. A computer-implemented method as claimed in any one of the preceding claims, further comprising an additional step of determining the identify of a user as a precondition to sending an access code to the access switch.

17. A computer-implemented method as claimed in claim 16, wherein the additional step comprises entry of a code into a user interface.

18. A computer-implemented method as claimed in claim 16 or claim 17, wherein the additional step includes capturing a biometric feature.

19. A computer-implemented method as claimed in any one of the preceding claims, further comprising encrypting an access code using a private key for a user device.

20. A user equipment comprising a memory, processor and at least one communications interface adapted to carry out any of the methods claimed in claims 1 to 19.

21. A computer-implemented method of provisioning a software routine on user device to generate codes for activating an access switch, the method comprising: receiving an authority public key from an authority, generating an app public / private key pair, transmitting the app public key to the authority, receiving a code from the authority, encrypting the code received from the server using the app private key and the authority public key to generate encrypted data, sending the encrypted data to the authority, and receiving a signature from the authority.

22. A method as claimed in claim 21, further comprising installing the software routine on the user device.

Images