four-factor authentication

Abstract

Verifying that a user is using a device at a pre-designated location between a start time and an end time includes: computing a challenge and an answer as a function of the challenge; generating and storing in a blockchain a commitment including an identity of the user, an identity of the device, the pre-designated location associated with the user, a start time of the device usage, an end time of the device usage, and the computed challenge; generating a visual code for the device to carry the answer; encrypting the generated visual code using a public key of the device, wherein the encrypted visual code can only be decrypted with a private key of the device; and storing the encrypted visual code in the blockchain.

Description

Technical Field

[0001] This disclosure relates to technologies for authentication, and more specifically, to systems and methods for storing and verifying data used to indicate multiple factors. Background Technology

[0002] Proving that a person is using a specific device at a given location and time is often crucial. For example, such proof can authorize access to restricted resources within a given time slot. For instance, it might be important to ensure that a remote user is operating a computer obtained from a company within a given time period and that the computer is being used in a private space at the user's residence, not in a public café. Summary of the Invention

[0003] This disclosure provides: associating users with user identification data, password keys, and mobile devices; and associating devices with device identification data and password keys. This disclosure also includes: a scheduler system that manages commitments and includes one or more databases for storing user data and device data; and a validator system that accesses data to verify commitments and user and device data.

[0004] In one embodiment, a method for verifying that a user is using a device at a pre-specified location between a start time and an end time is disclosed. The method includes: calculating a challenge and an answer as a function of the challenge; generating and storing in a blockchain an identity including the user, the device, the pre-specified location associated with the user, the start time of device use, the end time of device use, and a commitment to the calculated challenge; generating a visual code for the device to carry the answer; encrypting the generated visual code using the device's public key, wherein the encrypted visual code can only be decrypted using the device's private key; and storing the encrypted visual code in the blockchain.

[0005] In one embodiment, the method further includes transmitting encrypted visual code to a device. In one embodiment, the method further includes decrypting the encrypted visual code using the device's private key; and displaying an image of the visual code on a display. In one embodiment, the method further includes capturing an image of the visual code using a mobile device; and extracting the visual code. In one embodiment, the method further includes: generating a message by the mobile device including a commitment having the location of the mobile device, the device's identity obtained from the extracted visual code, and the current time; and signing the message using a user's private key to generate a signature. In one embodiment, the method further includes verifying the commitment upon receiving the message and the signature matching the user's public key. In one embodiment, the method further includes verifying the commitment upon receiving the message and the value of the extracted visual code matching a calculated challenge. In one embodiment, the method further includes verifying the commitment upon receiving the message and the pre-specified location being substantially equal to the location of the mobile device. In one embodiment, the method further includes verifying the commitment upon receiving the message and the current time being within a time slot defined by a start time and an end time.

[0006] In another embodiment, a non-transitory computer-readable storage medium is disclosed, which stores a computer program that verifies a user's use of a device at a pre-specified location between a start time and an end time. The computer-readable storage medium includes executable instructions that cause a computer to: compute a challenge and an answer as a function of the challenge; generate and store in a blockchain a commitment including the user's identity, the device's identity, the pre-specified location associated with the user, the start time of device use, the end time of device use, and the computed challenge; generate visual code for the device to carry the answer; encrypt the generated visual code using the device's public key, wherein the encrypted visual code can only be decrypted using the device's private key; and store the encrypted visual code in the blockchain.

[0007] In another embodiment, a system is disclosed for verifying that a user is using a device at a pre-specified location between a start time and an end time. The system includes: a blockchain; a device to be authenticated, wherein the device accesses the blockchain via a network connection, wherein the blockchain stores the identity of the device to be authenticated, the identity of the user of the device, the pre-specified location associated with the user, the start time of device use, the end time of device use, and a commitment to a challenge; a public and private key of the device for encryption and decryption stored in the device and the blockchain; and a public and private key of the user for encryption and decryption stored in the blockchain; and a scheduler that generates a visual code for the device carrying the answer to the challenge, encrypts the generated visual code using the device's public key, wherein the encrypted visual code can only be decrypted using the device's private key, and stores the encrypted visual code in the blockchain.

[0008] In one implementation, the system also includes a mobile device that captures an image of the decrypted visual code and generates a message including the location of the mobile device, the device's identity obtained from the extracted visual code, and a commitment to the current time.

[0009] Other features and advantages will become apparent from this specification, which illustrates various aspects of the disclosure by way of example. Attached Figure Description

[0010] Details of the structure and operation of this disclosure can be partially gathered by studying the accompanying drawings, in which:

[0011] Figure 1 This is a block diagram of a system for implementing multi-factor authentication according to one embodiment of the present disclosure;

[0012] Figure 2 This is a flowchart of a process for verifying that a user is using a device at a pre-specified location from a start time to an end time, according to one embodiment of the present disclosure;

[0013] Figure 3 This is a flowchart of a process for verifying a user's compliance with a generated commitment, according to one embodiment of this disclosure;

[0014] Figure 4 This is a flowchart of a process for verifying a user's compliance with a generated commitment, according to one embodiment of this disclosure;

[0015] Figure 5 This is a block diagram of a system for implementing multi-factor authentication according to another embodiment of the present disclosure;

[0016] Figure 6 This is a flowchart of a process for verifying that a user is using a device at a pre-specified location from a start time to an end time, according to one embodiment of the present disclosure;

[0017] Figure 7 This is a flowchart of a process for verifying a user's compliance with a generated commitment using a smart contract, according to one embodiment of this disclosure;

[0018] Figure 8 This is a flowchart of a process for verifying a user's compliance with a generated commitment, according to another embodiment of this disclosure;

[0019] Figure 9 This is a flowchart of a process for verifying a user's compliance with a generated commitment using a smart contract, according to another embodiment of this disclosure;

[0020] Figure 10AThis refers to the computer system and user representation according to embodiments of this disclosure; and

[0021] Figure 10B This is a functional block diagram illustrating a managed authentication application computer system according to an embodiment of the present disclosure. Detailed Implementation

[0022] As mentioned above, it is often crucial to prove that a person is using a specific device at a given location and time.

[0023] Certain embodiments of this disclosure provide systems and methods for implementing techniques for authentication. In one embodiment, the system stores and verifies data indicating four factors (user, device, location, and time period). In another embodiment, different factors or different numbers of factors may be used.

[0024] After reading these descriptions, it will become clear how this disclosure can be implemented in various embodiments and applications. While various embodiments of this disclosure will be described herein, it should be understood that these embodiments are presented by way of example only and not as limitations. Therefore, the detailed descriptions of the various embodiments should not be construed as limiting the scope or breadth of this disclosure.

[0025] Figure 1 This is a block diagram of a system 100 implementing multi-factor authentication according to one embodiment of the present disclosure. Figure 1 In the embodiment shown, system 100 includes mobile device 110, scheduler 130, device 150, and verifier 160.

[0026] Each user participating in system 100 (e.g., user 102) may have a user identity, a user public key, and a user private key. In one implementation, mobile device 110 is configured to capture images, detect its own location, and communicate with a remote server. The mobile device may also maintain the user's private key.

[0027] Each device participating in system 100 (e.g., device 150) may have a device identity, a device public key, and a device private key. Device 150 also includes components for displaying images and communicating with a remote server.

[0028] In one implementation, scheduler 130 generates at least one commitment for a user. The commitment may include at least the following parameters: user identity; device identity of the device to be authenticated; location to be authenticated (e.g., the user's residence); start time of device usage; end time of device usage; generated challenge; and status flags. Scheduler 130 may include at least: a user database 132 for storing user identities and user public keys linked to user identities; a device database 134 for storing device identities and device public keys linked to device identities; and a commitment database 136 for storing at least one generated commitment.

[0029] In one implementation, verifier 160 queries scheduler 130 to confirm whether user 102 has successfully adhered to using the device at a given location and time slot. Therefore, when verifier 160 requests scheduler 130 to verify that user 102 is using device 150 at a pre-specified location from start time to end time, scheduler 130 may do so as described below.

[0030] Figure 2 This is a flowchart of a process 200 for verifying that a user is using a device at a pre-specified location from a start time to an end time, according to one embodiment of this disclosure. Figure 2 In the embodiment shown, a random number called a challenge can be generated in step 210 in the format of a challenge and an answer, where the answer = f(challenge) and f is an irreversible function, that is, it is computationally difficult to guess the challenge if the answer is known.

[0031] At step 220, a new commitment may be generated to store at least the following information: (1) the user's identity; (2) the identity of the device to be authenticated; (3) the location to be authenticated (e.g., the user's residence); (4) the start time; (5) the end time; (6) the generated challenge; and (7) a status flag initially set to "false". Then, at step 230, a visual code carrying the answer is generated, and at step 240, the visual code is encrypted using the public key of device 150. Then, at step 250, the resulting encrypted visual code 140 can be transmitted to device 150. It should be noted that the encrypted visual code can only be decrypted using the device's private key. In one implementation, steps 210 through 250 are performed by scheduler 130.

[0032] Figure 3 This is a flowchart of a process 300 for verifying a user's compliance with a generated commitment, according to one embodiment of this disclosure. Figure 3In the illustrated embodiment, at step 310, device 150 decrypts the encrypted visual code 140 using its device private key. If decryption is successful, then at step 320, device 150 displays an image of the decrypted visual code on display 152 at step 324. Otherwise, if decryption fails, then processing 300 is aborted at step 322.

[0033] exist Figure 3 In the illustrated embodiment, at step 330, user 102 uses mobile device 110 to capture an image (of the decrypted visual code) displayed on display 152 of device 150. Then, at step 340, mobile device 110 can extract the decrypted visual code (i.e., the visual code) from the captured image. If extraction is successful at step 350, mobile device 110 can generate a message 120 including commitment information by signing the message 120 using the user's private key at step 354. Otherwise, if extraction is unsuccessful, processing 300 is aborted at step 352. In one embodiment, the commitment information includes at least the following: (1) the user's identity; (2) the value carried by the visual code; and (3) the location of the mobile device. At step 360, mobile device 110 can transmit the signed message 120 to scheduler 130.

[0034] Then, scheduler 130 can verify the commitment information using the signed message at step 370. In one implementation, scheduler 130 verifies the following four conditions at step 370: (1) the signature of the signed message matches the user's public key stored in user database 132; (2) the value of the visual code matches the generated challenge (i.e., f(challenge) == code); (3) the location to be authenticated substantially matches the location of the mobile device; and (4) the current time is between the start and end times. If it is determined at step 380 that all four conditions are met, then scheduler 130 can set the status flag to "true" at step 382. Otherwise, if it is determined at step 380 that not all four conditions are met, then scheduler 130 can keep the status flag "false" at step 384.

[0035] Figure 4 This is a flowchart of a process 400 for verifying a user's compliance with a generated commitment, according to one embodiment of this disclosure. Figure 4In the illustrated embodiment, a determination is made at step 410 to check whether user 102 is committed to using device 150 from a specific location at the current time. In one embodiment, the determination is made by authenticator 160 querying scheduler 130 using at least the user's identity and device identity. Scheduler 130 can then search the commitment database 136 at step 420 for commitments with the expected user, device, and current time within a time slot defined by the start and end times. If no such commitment is determined at step 430, scheduler 130 can respond to authenticator 160 with a "not committed" message at step 432, and the process terminates. Otherwise, scheduler 130 can check the corresponding status flag at step 440 to determine if the status flag is "true". If scheduler 130 determines the status flag is "true" at step 440, scheduler 130 responds to authenticator 160 at step 450 with a "committed" message along with the end time. Otherwise, scheduler 130 responds to authenticator 160 with a "not committed" message at step 442.

[0036] Figure 5 This is a block diagram of a system 500 for implementing multi-factor authentication according to another embodiment of this disclosure. Figure 5 In the diagram, optional modules and signals are represented by dashed lines. Figure 5 In the illustrated implementation, system 500 includes mobile device 510, scheduler 530, device 550, and blockchain 570. In one implementation, blockchain 570 is a permissioned blockchain (such as Hyperledger Fabric). Blockchain 570 can manage... Figure 1 The functions of the verifier 160, user database 132, device database 134, and commitment database 136 shown are illustrated.

[0037] exist Figure 5 In the illustrated embodiment, blockchain 570 executes a dedicated application including at least one smart contract 572, wherein entities registered in the permissioned blockchain can invoke at least one smart contract 572. Therefore, in Figure 5 In Chinese, blockchain can refer to the infrastructure and algorithms of blockchain (such as distributed ledgers, consensus algorithms, and verification of the signatures of invoked smart contracts).

[0038] Each user participating in system 500 (e.g., user 502) can be a registered member of blockchain 570. Therefore, the blockchain's certification authority (which provides various certificate services to blockchain members) can provide the user's public and private keys. In one implementation, the Hyperledger architecture uses a 256-bit elliptic curve cryptography system.

[0039] Each device participating in system 500 (e.g., device 550) can also be a registered member of blockchain 570. Therefore, the blockchain's certification authority can also provide the device's public and private keys.

[0040] In one implementation, the scheduler 530 is also a registered entity of the blockchain 570 with a scheduler role. In order to create a new commitment, the scheduler 530 may invoke the smart contract “create commitment” process (hereinafter referred to as the first smart contract process) using information including: (1) the user’s identity (i.e., user identity); (2) the identity of the device to be authenticated (i.e., device identity); (3) the location to be authenticated, which can be defined by GPS location; (4) the start time; and (5) the end time.

[0041] Figure 6 This is a flowchart of a process 600 for "creating a commitment" in a smart contract according to one embodiment of the present disclosure to verify that a user is using a device at a pre-specified location from a start time to an end time. Figure 6 In the illustrated implementation, at step 610, it is determined whether the blockchain contains any information about the user's identity and the device's identity. If it is determined at step 610 that the blockchain contains information about the user's identity and the device's identity, then two random numbers are generated at step 620. Otherwise, process 600 aborts at step 612. In one implementation, the generated random numbers are the answer and the seed. At step 630, the challenge can be computed as challenge = f(seed|answer), where f is a secret function. In one implementation, the secret function is the SHA256 function.

[0042] At step 640, a new commitment may be generated to store at least the following information: (1) the user's identity; (2) the identity of the device owned by the user; (3) a pre-specified location (e.g., the location of the user's residence); (4) a start time; (5) an end time; (6) a generated challenge; (7) a seed; and (8) a state flag initially set to "false". At step 650, a visual code carrying the answer may be generated, and then at step 660, the visual code may be encrypted using the public key of device 150 via processing 600. The encrypted visual code can only be decrypted using the private key of device 150. That is, only device 150 with its private key can display the visual code containing the answer. In one embodiment, the visual code is a Quick Response (QR) code. In other embodiments, the visual code is a text code or a barcode. Then, at step 670, the resulting encrypted visual code may be stored in the blockchain via the first smart contract processing 600.

[0043] Figure 7This is a flowchart of process 700 for verifying a user's compliance with a generated promise using a smart contract, according to one embodiment of this disclosure. In one embodiment, process 700 is executed after process 600 has been completed.

[0044] exist Figure 7 In the illustrated embodiment, process 700 checks at step 710 whether user 502 is faithful to using device 550 from a specific location at the current time. In one embodiment, when user 502 attempts to use device 550, device 550 queries blockchain 570 at least using the user's identity at step 720. Then, at step 730, blockchain 570 can verify that the query was issued by a known device and provide the device identity to the smart contract.

[0045] Then, at step 740, the smart contract can search the blockchain 570 for a commitment that includes the user's identity, the device's identity, and the current time within a time slot defined by the start and end times. If it is determined at step 750 that no such commitment exists, then process 700 can return a "disloyal" message to device 550 at step 752. Otherwise, at step 760, process 700 can check the corresponding status flag to determine if the status flag is "true". If process 700 determines at step 760 that the status flag is "true", then process 700 can return a "loyal" message along with the end time to device 550 at step 770, and at step 780 grant user 502 access to device 550 until the end time.

[0046] Otherwise, process 700 returns a "disloyal" message to device 550 at step 762. If device 550 receives the "disloyal" message, then at step 752 or 762, device 550 denies user 502 access. If device 550 receives the "disloyal" message, then at step 752 or 762, process 700 proceeds to... Figure 8 The process shown is 800.

[0047] Figure 8 This is a flowchart of a process 800 for verifying a user's compliance with a generated commitment, according to another embodiment of this disclosure. Figure 8 In the illustrated embodiment, device 550 decrypts the encrypted visual code (stored in blockchain 570 at step 670) using its private key at step 810. If decryption is successful, then at step 820, device 550 displays an image of the decrypted visual code on display 552 at step 824. Otherwise, if decryption fails, then processing 800 is aborted at step 822.

[0048] exist Figure 8In the illustrated embodiment, at step 830, user 502 uses mobile device 510 to capture an image (of the decrypted visual code) displayed on display 552 of device 550. Then, at step 840, mobile device 110 can extract the code from the decrypted visual code (i.e., the visual code) in the captured image. If extraction is successful at step 850, mobile device 510 can generate a message 120 including commitment information at step 854. Otherwise, if extraction is unsuccessful, processing 800 is aborted at step 852. In one embodiment, the commitment information (generated in step 854) includes at least the following: (1) the extracted code; and (2) the location of the mobile device.

[0049] Then, at step 860, the mobile device 510 can use a message as a parameter to invoke process 900 on behalf of user 502 for the smart contract "answer challenge". In the Hyperledger architecture, the caller can sign a request for a smart contract using their private key. Therefore, the invocation of process 900 corresponds to a signed message.

[0050] Figure 9 This is a flowchart of a process 900 for a smart contract "answer challenge" that verifies a user's compliance with a generated promise using a smart contract, according to another embodiment of this disclosure. Figure 9 In step 910, process 900 queries blockchain 570 at least using the user's identity. When process 900 receives a call to a smart contract, at step 920, the blockchain (i.e., the Hyperledger architecture) can check whether the registered entity has correctly signed the call and can provide the caller's identity to ensure the caller is legitimate. Then, at step 930, the smart contract can search blockchain 570 for a commitment with the expected user identity, device identity, and the current time within a time slot defined by the start and end times.

[0051] exist Figure 9In the illustrated implementation, process 900 verifies three conditions. For the first condition, at step 940, the challenge can be calculated as challenge = f(seed | extracted code), where the extracted code is generated as commitment information included in message 120 (at step 854), and the seed is generated as a new commitment (at step 640). In one implementation, the function f is a SHA256 function. For the second condition, at step 950, the location of the mobile device (generated in step 854) is compared with a pre-specified location (generated in step 640). For the third condition, at step 960, it is checked whether the current time is within the time slot defined by the start and end times. If all three conditions (steps 940, 950, and 960) are satisfied at step 970, then the status flag is set to true at step 980. Otherwise, at step 990, the status flag remains false.

[0052] Figure 10A This is a representation of a computer system 1000 and a user 1002 according to embodiments of the present disclosure. User 1002 uses the computer system 1000 to implement, respectively, the following... Figures 2 to 4 and Figures 6 to 9 The processing steps 200, 300, 400, 600, 700, 800, and 900 are shown, and the authentication application 1090 is described.

[0053] Computer System 1000 Stores and Executes Figure 10B The authentication application 1090. Furthermore, the computer system 1000 can communicate with the software program 1004. The software program 1004 may include software code for the authentication application 1090. The software program 1004 may be loaded onto external media such as a CD, DVD, or storage drive, as will be explained further below.

[0054] Furthermore, computer system 1000 can connect to network 1080. Network 1080 can be connected in various different architectures (e.g., client-server architecture, peer-to-peer network architecture, or other types of architecture). For example, network 1080 can communicate with server 1085 (e.g., a group of servers located at a data source), which coordinates the engine and data used within authentication application 1090. Moreover, the network can be of different types. For example, network 1080 can be the Internet, a local area network (LAN) or any variant of a LAN, a wide area network (WAN), a metropolitan area network (MAN), an intranet or extranet, or a wireless network.

[0055] Figure 10BThis is a functional block diagram of a computer system 1000 illustrating a managed authentication application 1090 according to an embodiment of the present disclosure. The controller 1010 is a programmable processor and controls the operation of the computer system 1000 and its components. The controller 1010 loads instructions (e.g., in the form of a computer program) from memory 1020 or an embedded controller memory (not shown) and executes these instructions to control the system. In its execution, the controller 1010 provides software systems to the authentication application 1090, such as enabling the creation and configuration of engines and interfaces within the authentication application 1090. Alternatively, the application may be implemented as a separate hardware component within the controller 1010 or the computer system 1000.

[0056] The memory 1020 temporarily stores data for use by other components of the computer system 1000. In one embodiment, the memory 1020 is implemented as RAM. In another embodiment, the memory 1020 also includes long-term or permanent memory (such as flash memory and / or ROM).

[0057] Storage device 1030 temporarily or permanently stores data for use by other components of computer system 1000. For example, storage device 1030 stores data used by authentication application 1090.

[0058] In one embodiment, storage device 1030 is a hard disk drive.

[0059] Media device 1040 receives removable media and reads and / or writes data to the inserted media. In one embodiment, for example, media device 1040 is an optical disc drive.

[0060] User interface 1050 includes components for accepting user input from user 1002 of computer system 1000 and presenting information to user 1002. In one embodiment, user interface 1050 includes a keyboard, mouse, audio speakers, and a display. Controller 1010 uses input from user 1002 to adjust the operation of computer system 1000.

[0061] I / O interface 1060 includes one or more I / O ports for connecting to corresponding I / O devices (such as external storage devices or supplementary devices, such as printers or PDAs). In one embodiment, the ports of I / O interface 1060 include ports such as USB ports, PCMCIA ports, serial ports, and / or parallel ports. In another embodiment, I / O interface 1060 includes a wireless interface for wireless communication with external devices.

[0062] Network interface 1070 includes wired and / or wireless network connections that support Ethernet connectivity (such as RJ-45 or “Wi-Fi” interfaces (including but not limited to 802.11)).

[0063] Computer system 1000 includes typical additional hardware and software of a computer system (e.g., power supply, cooling, operating system), but for simplicity, these components are not listed here. Figure 10B This is illustrated in detail. In other embodiments, different configurations of the computer system may be used (e.g., different bus or storage configurations or multiprocessor configurations).

[0064] The description of the disclosed embodiments is provided to enable any person skilled in the art to make or use this disclosure. Many modifications to these embodiments will be apparent to those skilled in the art, and the principles defined herein can be applied to other embodiments without departing from the spirit or scope of this disclosure. For example, authentication can be used for various applications (such as granting, monitoring, restricting, or leasing device access or content access). Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principal and novel features disclosed herein.

[0065] Various embodiments of this disclosure are implemented using electronic hardware, computer software, or a combination of these technologies. Some embodiments include one or more computer programs executed by one or more computing devices. Generally, a computing device includes one or more processors, one or more data storage components (e.g., volatile or non-volatile memory modules and persistent optical and magnetic storage devices such as hard disk and floppy disk drives, CD-ROM drives, and magnetic tape drives), one or more input devices (e.g., game controllers, mice, and keyboards), and one or more output devices (e.g., display devices).

[0066] A computer program includes executable code, which is typically stored in persistent storage media and then copied to memory at runtime. At least one processor executes the code by retrieving program instructions from memory in a prescribed order. When executing program code, the computer receives data from input and / or storage devices, performs operations on the data, and then delivers the resulting data to output and / or storage devices.

[0067] Those skilled in the art will recognize that the various illustrative modules and method steps described herein can be implemented as electronic hardware, software, firmware, or a combination thereof. To clearly illustrate this interchangeability between hardware and software, various illustrative modules and method steps have been generally described herein according to their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functionality in various ways for each specific application, but such implementation decisions should not be construed as departing from the scope of this disclosure. Furthermore, the grouping of functions within a module or step is for ease of description. Specific functions can be moved from one module or step to another without departing from this disclosure.

[0068] Not all features of every example discussed above are necessary in a particular embodiment of this disclosure. Furthermore, it should be understood that the descriptions and figures presented herein represent subject matter broadly contemplated by this disclosure. It should also be understood that the scope of this disclosure fully covers other embodiments that will become apparent to those skilled in the art, and the scope of this disclosure is therefore limited only by the appended claims.

Claims

1. A method for verifying that a user is using a device at a pre-specified location between a start time and an end time, the method comprising: Calculate the question and the answer as a function of the question; Generate and store in the blockchain information including the user's identity, the device's identity, the pre-specified location associated with the user, the start time of device usage, the end time of device usage, and the calculated commitments to the challenge; Generate visual code for the device to carry the answer; The generated visual code is encrypted using the device's public key, and the encrypted visual code can only be decrypted using the device's private key. Storing encrypted visual code in the blockchain; Transmit encrypted visual code to the device; Use the device's private key to decrypt the encrypted visual code; Display images of visual codes on a monitor; Capture images of visual codes using mobile devices; Extract visual code; A message is generated by a mobile device, the message including the location of the mobile device, the device's identity obtained from extracted visual codes, and a commitment to the current time; as well as The message is signed using the user's private key to generate a signature.

2. The method of claim 1, further comprising: Verify the commitment upon receiving the message and confirming that the signature matches the user's public key.

3. The method of claim 1, further comprising: Verify the commitment when the message is received and the value of the extracted visual code is matched with the calculated challenge.

4. The method of claim 1, further comprising: Verify the commitment when a message is received and the pre-specified location is substantially equal to the location of the mobile device.

5. The method of claim 1, further comprising: Verify the commitment when the message is received and the current time is within the time slot defined by the start and end times.

6. A non-transitory computer-readable storage medium storing a computer program that verifies that a user is using a device at a pre-specified location between a start time and an end time, the computer program including executable instructions that cause the computer to: Calculate the question and the answer as a function of the question; Generate and store in the blockchain information including the user's identity, the device's identity, the pre-specified location associated with the user, the start time of device usage, the end time of device usage, and the calculated commitments to the challenge; Generate visual code for the device to carry the answer; The generated visual code is encrypted using the device's public key, and the encrypted visual code can only be decrypted using the device's private key. Storing encrypted visual code in the blockchain; Transmit encrypted visual code to the device; Use the device's private key to decrypt the encrypted visual code; Display images of visual codes on a monitor; Capture images of visual codes using mobile devices; Extract visual code; Generate a message that includes the location of the mobile device, the device's identity obtained from the extracted visual code, and a commitment to the current time; as well as The message is signed using the user's private key to generate a signature.

7. The non-transitory computer-readable storage medium of claim 6, further comprising executable instructions that cause the computer to: Verify the commitment upon receiving the message and confirming that the signature matches the user's public key.

8. The non-transitory computer-readable storage medium of claim 6, further comprising executable instructions that cause the computer to: Verify the commitment when the message is received and the value of the extracted visual code is matched with the calculated challenge.

9. The non-transitory computer-readable storage medium of claim 6, further comprising executable instructions that cause the computer to: Verify the commitment when a message is received and the pre-specified location is substantially equal to the location of the mobile device.

10. The non-transitory computer-readable storage medium of claim 6, further comprising executable instructions that cause the computer to: Verify the commitment when the message is received and the current time is within the time slot defined by the start and end times.

11. A system for verifying that a user is using a device at a pre-specified location between a start time and an end time, the system comprising: Blockchain; Devices to be authenticated, wherein the devices access the blockchain via a network connection. The blockchain storage includes the identity of the device to be authenticated, the identity of the user of the device, the pre-specified location associated with the user, the start time of device use, the end time of device use, and the commitment to challenge. Public and private keys of the device used for encryption and decryption, stored in the device and blockchain; The user's public and private keys, stored in the blockchain, are used for encryption and decryption; The scheduler generates visual code for the device to carry the answer to the challenge, encrypts the generated visual code with the device's public key, wherein the encrypted visual code can only be decrypted with the device's private key, and stores the encrypted visual code in the blockchain. as well as The mobile device captures an image with decrypted visual code, generates a committed message including the location of the mobile device, the device's identity obtained from the extracted visual code, and the current time, and signs the message using the user's private key to generate a signature. The scheduler also transmits encrypted visual codes to the device, decrypts the encrypted visual codes using the device's private key, and displays an image of the visual codes on the monitor.

Images