Secure barcode

Abstract

A computer-implemented method of generating a barcode for a ticket involves receiving information associated with the ticket (ticket data), generating signature data based on the ticket data, and gene

Description

Field of Invention The present invention relates to a method of generating a barcode for a ticket. The present invention also relates to a method of verifying a ticket including a barcode. Background Events such as concerts or sporting events typically use devices such as turnstiles to prevent unauthorised users (e.g. users with previously redeemed tickets) from accessing the event. Event tickets often include barcodes which can be read or scanned by a barcode reader on a turnstile in order to verify that the ticket is valid and allow the ticket holder to access the event. Summary of Invention One issue with using barcodes on tickets is that it may be possible to forge the barcode or manipulate the data within it. This may allow unauthorised users to gain access to an event or venue. The present invention addresses this issue by providing a novel barcode format including a digital signature which can be used to verify the barcode. The barcode format has been designed to prevent forgery or manipulation of data contained in the barcode, providing an additional layer of security. Furthermore, the barcode format may allow for enforcement of ticket validation rules, including verifying: • The ticket's validity for the current location • The ticket's validity for the present date and time • That the ticket, if it grants multiple entries, hasn't exceeded the allowed entry count • That the ticket hasn't been cancelled. Information associated with the ticket can be updated, for example when the ticket is redeemed. The updated ticket information can be propagated to turnstiles at an event. This propagation can be carried out using a range of communication methods, providing multiple levels of backup in the event of local area network (LAN) or wide area network (WAN) disruptions. According to an aspect of the present Invention, there is provided a computer-implemented method of generating a barcode for a ticket. The method comprises: generating first data identifying that the barcode is in a specific format for a barcode reader; generating second data based on booking information associated with the ticket; generating third data based on status information identifying a status of the ticket; combining the first data, the second data and the third data to form first message data; generating, based on the first message data, a private key and a cryptographic hash function, signature data; combining the first message data and the signature data to form second message data; and generating, based on the second message data, the barcode. Generating the signature data may comprise: generating a hash-based message authentication code (HMAC) using the first message data, the private key and the cryptographic hash function; and generating the signature data based on a selected portion of the HMAC. Generating the signature data based on the selected portion of the HMAC may comprise encoding the selected portion of the HMAC according to an encoding scheme. The selected portion of the HMAC may be the first n bytes of the HMAC, where n Is an integer. The cryptographic hash function may be a secure hash algorithm (SHA). The cryptographic hash function may be a SHA-2 hash algorithm. The first data, the second data and the third data may be strings. Combining the first data, the second data and the third data to form the first message data may comprise combining the strings to form a first string. The signature data may be a second string. Combining the first message data and the signature data to form the second message data may comprise combining the first string and the second string to form a third string. The information identifying the event may include a booking serial number and a ticket sequence variable. The information identifying the status of the ticket may include a ticket version variable. The method may further comprise: generating a data packet based on the booking serial number, the ticket sequence variable and the second data; and transmitting the data packet to a turnstile device. According to another aspect of the present invention, there is provided a computer-implemented method of verifying a ticket comprising a barcode. The method comprises: decoding the barcode to obtain first data identifying that the barcode is in a specific format for a barcode reader, second data encoding booking information associated with the ticket, third data encoding status information identifying a status of the ticket, and first signature data; combining the first data, the second data and the third data to form first message data; generating, based on the first message data, a private key and a cryptographic hash function, second signature data; and comparing the generated second signature data with the first signature data to verify the ticket. Generating the second signature data may comprise: generating a hash-based message authentication code (HMAC) using the first message data, the private key and the cryptographic hash function; and generating the second signature data based on a selected portion of the HMAC. Generating the second signature data based on the selected portion of the HMAC may comprise encoding the selected portion of the HMAC according to an encoding scheme. The selected portion of the HMAC may be the first n bytes of the HMAC, where n Is an integer. The cryptographic hash function may be a secure hash algorithm (SHA). The cryptographic hash function may be a SHA-2 hash algorithm. The first data, the second data and the third data may be strings. Combining the first data, the second data and the third data to form the first message data may comprise combining the strings to form a first string. The method may further comprise decoding the third data to obtain the status information, and comparing the obtained status information with stored status information for the ticket to determine whether the ticket is valid. The status information obtained from the barcode may include a ticket version variable having a first value and the stored status information may include a ticket version variable having a second value. The method may further comprise: comparing the first value of the ticket version variable with the second value of the ticket version variable; determining that the ticket is not valid if the first value is less than the second value; and determining that the ticket is valid if the first value is equal to or greater than the second value. The method may further comprise: receiving a data packet; decoding the data packet to obtain a booking serial number, a ticket sequence variable and data encoding second status information identifying a status of the ticket; decoding the data to obtain the second status information; and storing the second status information as the stored status information. According to another aspect of the present invention, there is provided a computer-implemented method of generating a barcode for a ticket. The method comprises: receiving information associated with the ticket; generating signature data based on the information associated with the ticket; and generating the barcode based on the information associated with the ticket and the signature data. According to another aspect of the present invention, there is provided a computer-implemented method of verifying a ticket comprising a barcode. The method comprises: decoding the barcode to obtain information associated with the ticket and first signature data; generating, based on the information associated with the ticket, second signature data; and comparing the generated second signature data with the first signature data to verify the ticket. According to another aspect of the present invention, there is provided a computer-readable medium comprising instructions which, when executed by a processor, cause the processor to perform any of the methods set out above. According to another aspect of the present invention, there is provided an apparatus comprising a processor configured to perform any of the methods set out above. The apparatus may be one of: a mobile point-of-sale device; a point-of-sale device arranged to be installed at a fixed location; and a turnstile device. Brief Description of the Drawings The present disclosure will now be described by way of example only with reference to the accompanying drawings in which: Figure 1 is a schematic diagram showing an example of an event environment; Figure 2 is a block diagram showing an example of a point-of sale device; Figure 3 is a block diagram showing an example of a turnstile; Figure 4 is a flowchart showing an example of a barcode generation method; and Figure 5 is a flowchart showing an example of a barcode verification method. Detailed Description Figure 1 shows an example of an event environment. Multiple point-of-sale (POS) devices 100 are provided within the environment. A POS device 100 can be used to sell tickets for the event. A POS device 100 may be a mobile device, or a device which is installed at a fixed location. In the present example, POS devices 100A, 100B, 100C are mobile POS devices operated by ticket attendants, while POS devices 100D and 100E are self-service ticket kiosks which can be operated by users. Turnstiles 200 are provided within the environment to control access to the event. In the present example, the turnstiles 200A, 200B, 200C have moveable arms 250A, 250B, 250C. When in their default position, the arms 250 block users from passing. The turnstiles 200A, 200B, 200C also include barcode readers (not shown). Each turnstile 200A, 200B, 200C is located within its own ticket lane LI, L2, L3. The POS devices 100 and the turnstiles 200 may communicate with each other over a LAN via a central router (not shown). The POS devices 100 and the turnstiles 200 may also communicate with each other via Wi-Fi Direct connections, thereby forming a peer-to-peer mesh network. In this case, if the LAN goes down, the POS devices 100 and the turnstiles 200 can still communicate with each other and share up-to-date ticket information without needing a central router. The POS devices 100 and the turnstiles 200 may also communicate with a server (not shown) via the internet. The server may periodically broadcast the latest known status of all active tickets. Upon receiving this information, the POS devices 100 and the turnstiles 200 may update their local databases with this new information. This ensures that the statuses of active tickets are kept current in the system. Further, when a new device is added to the system, the server can send the new device the latest list of tickets and their associated status information. A user wishing to access the event purchases a ticket at one of the POS devices 100. The ticket may be a physical ticket which is printed by the POS device, or may be an electronic ticket which sent to the user's mobile device (not shown). The ticket includes a barcode (e.g. a QR. code) which is unique to the ticket. The user then enters a ticket lane (e.g. LI) and scans the ticket barcode using a barcode reader (not shown) on the turnstile 200A within the ticket lane. The turnstile 200A performs a verification process on the ticket. If the ticket is verified, the turnstile 200A allows the user to move the arm 250A to pass through the turnstile 200A into the event. An example of a POS device is shown in Figure 2. The POS device 100 includes a processor 110 which is configured to control the overall operation of the POS device 100. In particular, the processor 110 is configured to generate a barcode for a ticket purchased by a user. An example of the barcode generation process will be described below with reference to Figure 4. The POS device 100 includes a memory 120. The memory 120 may store data which can be used by the processor 110 to generate the barcode. This data may include a private key and / or a cryptographic hash function. The POS device 100 also includes a communicator 130. The communicator 130 may be configured to communicate with other devices in the event environment, such as the turnstiles 200. The communicator 130 may communicate with the other devices via multiple different communication modes. For example, the communicator 130 may be configured to communicate with other devices in the environment over a LAN via a router (e.g. using Wi-Fi). The communicator 130 may also be configured to communicate with other devices in the environment directly (e.g. using Wi-Fi Direct). In the present example, the POS device 100 includes a printer 140 configured to print tickets. In some examples, the printer 140 may be omitted. An example of a turnstile is shown in Figure 2. The turnstile 200 incudes a processor 210 which is configured to control the overall operation of the turnstile 200. In particular, the processor 210 Is configured to control the operation of the arm 250 based on verification of a ticket. The turnstile 200 Includes a memory 220 and a communicator 230. The memory 220 may store data which can be used by the processor 210 to verify a barcode. These data may include the same private key and cryptographic hash function which are stored by the memory 120 of the POS device 100. The memory 220 of the turnstile 200 may also store data relating to tickets which is received via the communicator 230. More specifically, the memory 220 may store a database of ticket status data. The communicator 230 may be configured to communicate with other devices in the event environment, such as the POS devices 100. As with the communicator 130 of the POS device 100 shown in Figure 2, the communicator 230 may communicate with the other devices via multiple different communication modes. For example, the communicator 230 may be configured to communicate with other devices in the environment over a LAN via a router (e.g. using a wired Ethernet connection). The communicator 230 may also be configured to communicate with other devices in the environment directly (e.g. using Wi-Fi Direct). The turnstile 200 also includes a barcode reader 260. The processor 210 may be configured to control the barcode reader 260 to read or scan barcodes on tickets for an event. The processor 210 can verify the ticket based on the data contained in the barcode. An example of the barcode verification process will be described below with reference to Figure 5. Figure 4 shows an example of a method of generating a barcode for a ticket. The ticket may be a physical ticket, or may be an electronic ticket, e.g. a ticket which can be displayed on a user device such as a mobile phone. The method may be performed by the processor 110 of the POS device 100 shown in Figure 2. Two types of Information for the ticket are used in the barcode generation process: booking information and ticket status information. The booking information describes what the ticket holder is entitled to, such as entry to a particular event or venue. The booking information may be generated by the processor 110 based on information received from a user via an input device of the POS device 100. The status information provides the status of the ticket. The status information may be generated by the processor 110 with default values when the ticket is first created. The status information may be updated e.g. when the ticket is redeemed. Non-limiting examples of booking information and ticket status information are given In the tables below. Table 1 - booking information Type Example value Purpose Supplier ID 205 (Merlin Istanbul) Supplier serial number Product ID 15 (General Admission) Product serial number Option ID 2 (Fast Track) Option serial number Travel Date 20221115 (YYYYMMDD) If a ticket is given, its date is used, otherwise, today's date is used. The date is formatted in ISO8601, dashes are removed, and it is converted to an integer value Travel Time 960 (minutes from 00:00) Number of minutes since midnight for a tour time Booking Serial Number 888339811742 Booking serial number Ticket Sequence 1 Used to determine the order of tickets, if a booking includes multiple tickets. Unit ID 1 (adult) Encodes unit names (adult, child, senior, etc) as numbers (e.g. 0, 1,2,3) The combination of the booking serial number plus the ticket sequence value may be used to uniquely identify a ticket. For example, if there are two tickets with the same booking serial number, the first ticket will have its ticket sequence value set to 1, and the second 5 ticket will have Its ticket sequence value set to 2. Table 2 - ticket status information Type Example value Purpose Status Redeemed Defines current ticket status. If a ticket is cancelled, the status changes to "Cancelled," and the 'next action' value becomes 0, Indicating no further actions can be taken with this ticket. Code Version 1 An integer value which increases by 1 every time the ticket is updated. Next Action 0 (Nothing) An integer value which indicates what action can be performed next. Determined based on current state: • If balance is due, then next action is set to collect balance (3) • If waivers are not completed, then next action Is set to complete waivers (4) • If unscannable reason is not 0, then next action is set to nothing (0) • If ticket or booking has yet to be redeemed, then next action is set to redemption (1) • Otherwise, next action is set to scan (2) Unscannable Reason 3 (Ticket scan limit) An integer value selected from one of the following: • Active from early (0) • Active to elapsed (1) • Scan interval not elapsed (2) • Counter limit exceeded (3) • External redemption (4) Active From 1668517200 (unix epoch) Ticket or booking "active from" value converted to integer. Refers to ticket validity timeframe, specifically start. If a customer scans a ticket at a turnstile before this time, the turnstile can display a message informing the customer that the ticket not yet valid and asking for the customer to come back later. Active To 1668520800 (unix epoch) Ticket or booking "active to" value converted to integer. Related to "Active From", "Active To" type refers to the end of the timeframe when the ticket can be validly scanned. The method begins with the generation of several types of data: prefix data (S401), booking data (S402) and status data (S403). These data may be generated in any order, or may be generated simultaneously. In the present example, these data are expressed as strings. The prefix data identifies that the barcode is in a specific format which can be parsed and read by a barcode reader, such as the barcode reader 260 of the turnstile 200. The prefix data may be a static identifier including a version of the code format, for easier identification and future proofing. For example, the static identifier may take a value of 11 for version 1, !2 for version 2, etc. The booking data is generated by hashing the booking information for the ticket. Similarly, the status data is generated by hashing the status information for the ticket. The hashing may be performed using any suitable technique, such as the Sqids open-source library. Once generated, the prefix data, the booking data and the status data are combined to form first message data (S404). In the present example, this involves combining the strings for the prefix data, the booking data and the status data to form a single string. Signature data for the barcode is then generated (S405). The signature data is generated using a private key and a cryptographic hash function. The private key and the cryptographic hash function may be stored in the memory 120 of the POS device 100. The cryptographic hash function may be a secure hash algorithm (SHA), such as a SHA-2 hash algorithm. In the present example, the cryptographic hash function is a SHA-256 hash algorithm. The generation of the signature data may involve generating a hash-based message authentication code (HMAC). The HMAC may be generated using the first message data, the private key and the cryptographic hash function according to any suitable technique, such as that set out in Request for Comments (RFC) 2104. A portion of the HMAC may then be selected to generate the signature data. Using a portion of the HMAC rather than the whole HMAC reduces the total length of the signature data, thereby saving storage space. The portion of the MAC may be the first few bytes (e.g. the first 12 bytes) of the HMAC, or alternatively the last few bytes (e.g. the last 12 bytes) of the HMAC. In the present example, the first 12 bytes of the HMAC are used. The selected portion of the HMAC may be encoded using an encoding scheme such as Base64. Alternative encoding schemes include hexadecimal or binary encoding schemes. In the present example, the string resulting from the Base64 encoding may be stripped of spaces to produce the signature data. The first message data and the signature data are then combined to form second message data (S406), In the present example, this step involves combining the string for the first message data with the string for the signature data to form a single string. The barcode is then generated based on the second message data (S407). The generated barcode incorporates the signature data which can be used to verify the barcode, thus providing extra security. The method may further include generating a data packet (e.g. a JavaScript Object Notation (JSON) packet) which includes a key and a value. The key may include the serial number and the ticket sequence value of the booking information. For example, for the booking information given in Table 1 above, the key would be 888339811742 / 1. The value may be the status data generated for the ticket in step S403. The data packet can then be transmitted to other devices in the event environment. For example, the POS device 100 may transmit the data packet to the turnstiles 200 via the communicator 130, over a LAN or a Wi-Fi Direct connection. This ensures that the other devices have information on the ticket and its current status. Figure 5 shows an example of a method of verifying a ticket including a barcode. The ticket may be a physical ticket, or may be an electronic ticket, e.g. a ticket which can be displayed on a user device such as a mobile phone. The method may be performed by the processor 210 of the turnstile 200 shown in Figure 3. The barcode may have been generated by the method described above in relation to Figure 4. The barcode may be decoded to obtain several types of data (S501). These data may include prefix data identifying that the barcode is in a specific format for a barcode reader; booking data encoding booking information identifying an event associated with the ticket; status data encoding status information identifying a status of the ticket; and first signature data. In the present example, these data are expressed as strings. The prefix data, the booking data and the status data may be combined to form first message data (S502). In the present example, this involves combining the strings for the prefix data, the booking data and the status data to form a single string. Second signature data is then generated (S503). The second signature data is generated using a private key and a cryptographic hash function. The private key and the cryptographic hash function may be stored in the memory 220 of the turnstile 200. In the present example, the private key and the cryptographic hash function are the same as the private key and the cryptographic hash function described above in relation to Figure 4. The generation of the second signature data may involve generating a hash-based message authentication code (HMAC). The HMAC may be generated using the first message data, the private key and the cryptographic hash function according to any suitable technique, such as that set out in Request for Comments (RFC) 2104. A portion of the HMAC may then be selected to generate the second signature data. The portion of the MAC may be the first few bytes (e.g. the first 12 bytes) of the HMAC, or alternatively the last few bytes (e.g. the last 12 bytes) of the HMAC. In the present example, the first 12 bytes of the HMAC are used. The selected portion of the HMAC may be encoded using an encoding scheme such as Base64. Alternative encoding schemes include hexadecimal or binary encoding schemes. In the present example, the string resulting from the Base64 encoding may be stripped of spaces to produce the signature data. The second signature data are compared against the first signature data to verify the ticket (S504). If the two sets of signature data are the same, it can be assumed that the ticket is genuine. A difference in the two sets of signature data may Indicate that the ticket has been forged, or that the data of the genuine ticket has been manipulated in some way. The method may include a step of validating the ticket. This may involve de-hashing the status data from the barcode to obtain the status information for the ticket. The obtained status information may then be compared with stored status information for the ticket to determine whether the ticket is valid. The stored status information may be obtained by receiving a data packet from another device (e.g. a POS device 100), and decoding the data packet to obtain a serial number, a ticket sequence value and status data. The second status data can be de-hashed to obtain status information, which can be stored In the memory 220 of the turnstile 200. In the case of receiving two data packets for the same ticket (i.e. data packets including the same serial number and the same ticket sequence value), the data with the greater code version variable value will be stored. Comparing the two sets of status information may involve comparing a first value of the code version variable in the obtained status information with a second value of the code version variable in the stored status information. If the first value is equal to or greater than the second value (e.g. the first value is 1 and the second value is 1), the processor 210 may determine that the ticket is valid. If the first value is less than the second value (e.g. the first value is 1 and the second value is 2), the processor 210 may determine that 5 the ticket is not valid, as it would indicate that a reprinted, newer ticket exists. If either the ticket verification process or the ticket validation process returns a negative result, the turnstile 200 may deny the ticket holder access to the event, e.g. by controlling the arm 250 to remain in a fixed position so that the user cannot pass through the turnstile 200. 10 Various further modifications to the above described examples, whether by way of addition, deletion or substitution, will be apparent to the skilled person to provide additional examples, any and all of which are intended to be encompassed by the appended claims.

Claims

1. A computer-implemented method of generating a barcode for a ticket, the method comprising:generating first data identifying that the barcode is in a specific format for a barcode reader;generating second data based on booking information associated with the ticket; generating third data based on status information identifying a status of the ticket; combining the first data, the second data and the third data to form first message data;generating, based on the first message data, a private key and a cryptographic hash function, signature data;combining the first message data and the signature data to form second message data; andgenerating, based on the second message data, the barcode.

2. The method according to claim 1, wherein generating the signature data comprises: generating a hash-based message authentication code (HMAC) using the first message data, the private key and the cryptographic hash function; andgenerating the signature data based on a selected portion of the HMAC.

3. The method according to claim 2, wherein generating the signature data based on the selected portion of the HMAC comprises encoding the selected portion of the HMAC according to an encoding scheme.

4. The method according to claim 2 or 3, wherein the selected portion of the HMAC is the first n bytes of the HMAC, where n Is an integer.

5. The method according to any one of the preceding claims, wherein the cryptographic hash function is a secure hash algorithm (SHA).

6. The method according to claim 5, wherein the cryptographic hash function is a SHA-2 hash algorithm.

7. The method according to any one of the preceding claims, wherein the first data, the second data and the third data are strings, and combining the first data, the second data and the third data to form the first message data comprises combining the strings to form a first string.

8. The method according to claim 7, wherein the signature data is a second string, and combining the first message data and the signature data to form the second message data comprises combining the first string and the second string to form a third string.

9. The method according to any one of the preceding claims, wherein the information identifying the event comprises a booking serial number and a ticket sequence variable, and the information identifying the status of the ticket comprises a ticket version variable; andwherein the method further comprises:generating a data packet based on the booking serial number, the ticket sequence variable and the second data; andtransmitting the data packet to a turnstile device.

10. A computer-implemented method of verifying a ticket comprising a barcode, the method comprising:decoding the barcode to obtain first data identifying that the barcode is in a specific format for a barcode reader, second data encoding booking information associated with the ticket, third data encoding status Information identifying a status of the ticket, and first signature data;combining the first data, the second data and the third data to form first message data;generating, based on the first message data, a private key and a cryptographic hash function, second signature data; andcomparing the generated second signature data with the first signature data to verify the ticket.

11. The method of claim 10, wherein generating the second signature data comprises: generating a hash-based message authentication code (HMAC) using the first message data, the private key and the cryptographic hash function; andgenerating the second signature data based on a selected portion of the HMAC.

12. The method of claim 11, wherein generating the second signature data based on the selected portion of the HMAC comprises encoding the selected portion of the HMAC according to an encoding scheme.

13. The method according to claim 11 or 12, wherein the selected portion of the HMAC is the first n bytes of the HMAC, where n is an integer.

14. The method according to any one of claims 10 to 13, wherein the cryptographic hash function is a secure hash algorithm (SHA).

15. The method according to claim 14, wherein the cryptographic hash function is a SHA-2 hash algorithm.

16. The method according to any one of claims 10 to 15, wherein the first data, the second data and the third data are strings, and combining the first data, the second data and the third data to form the first message data comprises combining the strings to form a first string.

17. The method according to any one of claims 10 to 16, further comprising decoding the third data to obtain the status information, and comparing the obtained status information with stored status information for the ticket to determine whether the ticket is valid.

18. The method according to claim 17, wherein the status information obtained from the barcode comprises a ticket version variable having a first value and the stored status information comprises a ticket version variable having a second value, andthe method further comprises:comparing the first value of the ticket version variable with the second value of the ticket version variable;determining that the ticket is not valid if the first value is less than the second value; anddetermining that the ticket is valid if the first value is equal to or greater than the second value.

19. The method according to claim 17 or 18, further comprising:receiving a data packet;decoding the data packet to obtain a booking serial number, a ticket sequence variable and data encoding second status Information identifying a status of the ticket;decoding the data to obtain the second status information; and storing the second status information as the stored status information.

20. A computer-implemented method of generating a barcode for a ticket, the method comprising:receiving information associated with the ticket;generating signature data based on the information associated with the ticket; and generating the barcode based on the information associated with the ticket and the signature data.

21. A computer-implemented method of verifying a ticket comprising a barcode, the method comprising:decoding the barcode to obtain information associated with the ticket and first signature data;generating, based on the information associated with the ticket, second signature data; andcomparing the generated second signature data with the first signature data to verify the ticket.

22. A computer-readable medium comprising instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 21.

23. An apparatus comprising a processor configured to perform the method of any one of claims 1 to 21.

24. An apparatus according to claim 23, wherein the apparatus is one of:a mobile point-of-sale device;a point-of-sale device arranged to be installed at a fixed location; anda turnstile device.AMENDMENTS TO THE CLAIMS HAVE BEEN FILED AS FOLLOWS:21 05 25Claims1. A computer-implemented method of verifying a ticket to control access to an event or venue, the ticket comprising a barcode, and the method comprising:5 decoding the barcode to obtain first data identifying that the barcode is in a specificformat for a barcode reader, second data encoding booking information associated with the ticket, third data encoding status Information identifying a status of the ticket, and first signature data, wherein the first signature data is generated based on first message data, a first private key and a first cryptographic hash function, the first message data 10 comprising fourth data identifying that the barcode is in a specific format for a barcode reader, fifth data encoding booking Information associated with the ticket, and sixth data encoding status information identifying a status of the ticket;combining the first data, the second data and the third data to form second message data;15 generating, based on the second message data, a second private key and a secondcryptographic hash function, second signature data, wherein the second private key Is the same as the first private key and the second cryptographic hash function is the same as the first cryptographic hash function;comparing the generated second signature data with the first signature data to 20 verify the ticket; andcontrolling a device to prevent or allow access to the event or venue, based on verification of the ticket.

2. The method of claim 1, wherein generating the second signature data comprises: 25 generating a hash-based message authentication code (HMAC) using the secondmessage data, the second private key and the second cryptographic hash function; and generating the second signature data based on a selected portion of the HMAC.

3. The method of claim 2, wherein generating the second signature data based on the 30 selected portion of the HMAC comprises encoding the selected portion of the HMAC according to an encoding scheme.

4. The method according to claim 2 or 3, wherein the selected portion of the HMAC is the first n bytes of the HMAC, where n is an integer.

355. The method according to any one of claims 1 to 4, wherein the second cryptographic hash function is a secure hash algorithm (SHA).

6. The method according to claim 5, wherein the second cryptographic hash function is a SHA-2 hash algorithm.5 7. The method according to any one of claims 1 to 6, wherein the first data, the seconddata and the third data are strings, and combining the first data, the second data and the third data to form the second message data comprises combining the strings to form a first string.10 8. The method according to any one of claims 1 to 7, further comprising decoding thethird data to obtain the status information, and comparing the obtained status information with stored status information for the ticket to determine whether the ticket is valid.

9. The method according to claim 8, wherein the status information obtained from the 15 barcode comprises a ticket version variable having a first value and the stored status information comprises a ticket version variable having a second value, andthe method further comprises:comparing the first value of the ticket version variable with the second value of the ticket version variable;20 determining that the ticket is not valid if the first value is less than the secondvalue; anddetermining that the ticket is valid if the first value is equal to or greater than the second value.25 10. The method according to claim 8 or 9, further comprising:receiving a data packet;decoding the data packet to obtain a booking serial number, a ticket sequence variable and data encoding second status information identifying a status of the ticket;decoding the data to obtain the second status information; and30 storing the second status information as the stored status information.

11. The method according to any one of claims 1 to 10, wherein controlling a device to prevent or allow access to the event or venue comprises controlling the operation of a turnstile arm.3512. A computer-readable medium comprising instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 11.CM13. An apparatus comprising a processor configured to perform the method of any one of claims 1 to 11.

14. An apparatus according to claim 13, wherein the apparatus is one of:5 a mobile point-of-sale device;a point-of-sale device arranged to be installed at a fixed location; and a turnstile device.

Images