Creating a private key with location data

Abstract

A system for generating a master seed using location-based data includes a pseudo-random number generator configured to generate a random number and a global positioning system module configured to determine a location of the system. The system also includes a cryptographic module configured to generate a signature request message. The signature request message includes the random number and the location. The system further includes a communication device configured to send the signature request message to a location authority for approval. The communication device is further configured to receive a signature from the location authority upon approval of the signature request message. The system is further configured to generate a master seed based on the signature.

Description

[Technical Field]

[0001] The present invention relates to the creation of private cryptographic keys, and more particularly to the creation of a master seed on a hardware security module using a predetermined location approved by a location authority. [Background technology]

[0002] In public key cryptography, there are two keys: one to encrypt and one to decrypt. The encryption key is called the public key and is generally considered public to any party who wishes to send an encrypted message to a receiving party. The decryption key used to decrypt the encrypted message is called the private key and is typically not shared between the parties.

[0003] A digital signature is a mathematical scheme for verifying the authenticity of a digital message or document using public key cryptography. A digital signature can prove that the owner of the private key associated with a particular digital signature signed a message and that the signature is authentic. A valid digital signature, provided that certain requirements are met, assures the receiving party that the message was created by the sending party and that it was not altered in transit. Summary of the Invention

[0004] One aspect of the present invention is directed to a location-based hardware security module (HSM) that uses a location to create a master seed, the location-based hardware security module including at least one processor and at least one memory component. The location-based hardware security module also includes a pseudo-random number generator (PRNG) configured to generate a random number and a global positioning system (GPS) module configured to determine the location of the location-based HSM. The location-based hardware security module also includes a cryptographic module configured to generate a signature request message. The signature request message includes the random number and the location. The location-based hardware security module further includes a communication device configured to send the signature request message to a location authority for approval. The communication device is further configured to receive a signature from the location authority upon approval of the signature request message. The cryptographic module is further configured to generate a master seed based on the signature.

[0005] Another aspect is directed to a computer-implemented method for creating a master seed using location data. The computer-implemented method includes creating a signature request message using a location-based HSM located at a location. The computer-implemented method also includes sending the signature request message, with the coordinates of the location attached, to a location authority. The location authority is physically located at a geographically secured location, the location being within the location authority's zone of acceptance. The computer-implemented method further includes receiving a response from the location authority approving the signature request message based on the coordinates and providing a signature. The computer-implemented method also includes creating a master seed based on the signature.

[0006] Yet another aspect is directed to a computer program product for creating a master seed using location data, which may include one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media. The program instructions include program instructions for creating a signature request message using a location-based HSM located at a location. The program instructions also include program instructions for sending the signature request message with the coordinates of the location attached to a location authority. The location authority is physically located at a geographically assured location, the predetermined location being within the location authority's zone of acceptance. The program instructions further include program instructions for accepting the signature request message based on the coordinates and receiving a response from the location authority providing a signature. The program instructions also include program instructions for creating a master seed based on the signature. [Brief explanation of the drawings]

[0007] These and other features, aspects, and advantages of embodiments of the present disclosure will become better understood with regard to the following description, appended claims, and accompanying drawings.

[0008] [Figure 1] 1 is a block diagram illustrating an infrastructure discovery system in a computing environment, according to an embodiment of the present disclosure.

[0009] [Figure 2A] 1 illustrates a map upon which an exemplary key generation process can be performed, according to an embodiment of the present disclosure. [Figure 2B] 1 illustrates a map upon which an exemplary key generation process can be performed, according to an embodiment of the present disclosure.

[0010] [Figure 3] 1 illustrates an exemplary countermeasure location data structure, according to an embodiment of the present disclosure.

[0011] [Figure 4] FIG. 10 is a flow diagram illustrating a process for creating a master seed using location data according to an embodiment of the present disclosure.

[0012] [Figure 5] FIG. 4 is a flow diagram illustrating a process for creating a signature request message according to an embodiment of the present disclosure.

[0013] [Figure 6] FIG. 4 is a flow diagram illustrating a process for approving a signature request message according to an embodiment of the present disclosure.

[0014] [Figure 7] FIG. 10 is a flow diagram illustrating a process for recreating a master seed according to an embodiment of the present disclosure.

[0015] [Figure 8] FIG. 1 depicts a high-level block diagram of an exemplary computer system that may be used in implementing one or more of the methods, tools and modules described herein, and any associated functionality, in accordance with embodiments of the present disclosure.

[0016] While the present disclosure is susceptible to various modifications and alternative forms, specific examples thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the disclosure to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure. In the accompanying drawings, like reference numerals are used to designate like parts. DETAILED DESCRIPTION OF THE INVENTION

[0017] The present disclosure relates to the creation of private cryptographic keys, and more particularly to creating a master seed on a hardware security module using a predetermined location approved by a location authority. While the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be understood through a discussion of various examples using this context.

[0018] A hardware security module is a physical computing device that can protect and manage digital keys, perform encryption and decryption functions for digital signatures, authentication, and other cryptographic functions. Hardware security modules typically come in the form of a plug-in card or external device that connects directly to a computer or network server.

[0019] Hardware security modules may have features that provide evidence of tampering, such as visible signs or logging of tampering. Additionally, anti-tamper mechanisms may make tampering difficult without rendering the hardware security module inoperable. Hardware security modules are designed to manage private keys that can be used for user authorization and authentication.

[0020] Typical functions of a hardware security module include, for example, on-board secure cryptographic key generation, secure cryptographic key storage, key management, and performing encryption or digital signature functions. Hardware security modules can support symmetric and asymmetric cryptography. For some applications, such as certificate recognition and digital signatures, public key cryptography is used by hardware security modules.

[0021] Cryptocurrencies such as Bitcoin can use hardware security modules as hardware wallets, or personal security devices, designed to isolate cryptographic secrets (e.g., Bitcoin private keys) from potentially insecure devices (e.g., personal computers). These devices allow users to securely perform operations using private keys stored on the device.

[0022] Some hardware security modules use a hierarchical deterministic key generation process to derive cryptographic secrets (e.g., private keys) from a single master seed, which allows private keys to be generated on-demand by the hardware security module from the master seed.

[0023] A common method for creating / restoring wallets for Bitcoin is Bitcoin Improvement Proposal (BIP) 0039, hereafter referred to as BIP39. BIP39 describes the implementation of a mnemonic code or mnemonic sentence to generate a deterministic wallet. This consists of generating a mnemonic and then converting the mnemonic into a master seed. The mnemonic word can be a mnemonic of 12 to 24 words.

[0024] However, using a hardware security module to recover the master seed still has security limitations. When using traditional recovery techniques such as BIP39, revealing or leaking the recovery mnemonic sentence would result in a complete compromise of the hardware security module. This can prevent users from accessing sensitive information such as cryptocurrencies or potentially having that information stolen.

[0025] Embodiments of the present disclosure may overcome these and other problems by using a location-based hardware security module (HSM). The location-based HSM can generate a master seed using a predetermined location approved by a location authority. The predetermined location is a private location known only to the user operating the location-based HSM. Furthermore, to regenerate the master seed, a 24-word mnemonic is used in the process along with the predetermined location. The generation of the master seed can also occur only within the location-based location authority's zone of approval. For example, if the location is within the location authority's zone of approval, the location authority can approve the signing request message. However, if the predetermined location is outside the zone of approval, the signing request message is not approved and cannot be used by the location-based HSM.

[0026] More specifically, a location-based HSM generates a master seed by creating a signing request message while physically located at a location. The location-based HSM can obtain location coordinates via a Global Positioning System (GPS) module located within the HSM. Once the signing request is generated, the location-based HSM can send the signing request to the appropriate location authority for approval. If the location coordinates are within the location authority's approval zone, the location-based HSM receives a response back from the location authority and provides approval of the signing request message. The location-based HSM then generates a master seed based on the approved signing request message.

[0027] In some embodiments, the location-based HSM creates the signing request message by obtaining location data for a location via a GPS module. The location-based HSM can use the GPS coordinates of the location data to determine whether the location data matches a predetermined location. Longitude and latitude values ​​for the location can be extracted, and a random number can be generated by the location-based HSM. These values ​​can be used to generate the signing request message. In some embodiments, the random number is generated with a pseudo-random number generator that uses the current time of the location-based HSM as an entropy value.

[0028] In some embodiments, the location data is obtained via a map application. For example, an operator of a location-based HSM can select a predetermined location on the map application. The coordinates of this location can be used to create the signing request message. In some embodiments, multiple predetermined locations are selected as location data via the map application. For example, an operator can select four locations on the map application and then add the coordinates of these four locations to the signing request message. Additionally, the order in which the locations are selected can also be added. Each selected location, as well as the order of selection, can be verified by the location authority. When recreating the master seed, each location must be verified, as well as the order in which the locations were selected.

[0029] 1 is a block diagram illustrating an authentication environment 100 according to an embodiment of the present disclosure. The authentication environment 100 includes a location-based HSM 105 and a location authority 160. The location-based HSM 105 includes a cryptographic module 120, a pseudo-random number generator (PRNG) 130, a GPS module 140, and a communication device 150.

[0030] Location-based HSM 105 is a component of authentication environment 100 that is configured to use its location to generate and store a master seed. In some embodiments, location-based HSM 105 is a personal security device. The personal security device can be used to generate the master seed and maintain isolation from insecure devices. The master seed is a key from which other cryptographic secrets, such as private keys, can be derived, which can be used for cryptographic purposes such as digital signatures and authentication.

[0031] The cryptographic module 120 is a component of the location-based HSM 105 that is configured to perform cryptographic functions to create a master seed. The cryptographic module 120 can generate a signature request using the Secure Hash Algorithm 2 (SHA-2). SHA-2 is a set of six hash functions with digests (hash values) of 224, 256, 384, or 512 bits (SHA-224, SHA-256, SHA-384, SHA-512). These functions can perform calculations on 32-bit and 64-bit words. Additionally, various shift amounts and additive constants (e.g., location data) can be used when performing the calculations.

[0032] In some embodiments, encryption module 120 generates a signature request by applying a SHA-256 function using the random number generated by PRNG 130 and the location data detected by GPS module 140. This is shown using Equation 1, defined below: SRM=sha256(ENT)+LD Equation 1 where SRM represents the Signature Request Message, sha256 represents the SHA-256 cryptographic hash function from the SHA-2 set of functions, ENT represents a random number used as the entropy value, and LD represents the location data of the location-based HSM 105 at the time of generation.

[0033] Encryption module 120 is further configured to generate a master seed using a signature provided by location authority 160. In some embodiments, encryption module 120 creates the master seed using a key derivation function. A key derivation function is a cryptographic hash function that derives one or more private keys from a secret value, such as a master key. The key derivation function may be, for example, Password-Based Key Derivation Function 1 (PBKDF1), PBKDF2, or Argon2.

[0034] The encryption module is further configured to generate a checksum and a mnemonic sentence. The checksum can be generated by applying a SHA-2 function to the signature. The first 8 bits of the function can represent the checksum. The mnemonic sentence can also be generated by dividing the random number appended to the checksum into 11-bit units. In some embodiments, each 11-bit unit is given a word from the BIP39 word list.

[0035] The encryption module 120 is further configured to verify the signature received by the location authority 160. The encryption module 120 can utilize a public key available at the location authority 160 to perform a verification algorithm to ensure the validity of the location authority 160.

[0036] The encryption module 120 is further configured to recover the master seed using the mnemonic sentence. In some embodiments, the mnemonic sentence is received by the location-based HSM 105. Upon receipt, the encryption module 120 can separate the random number and checksum from the mnemonic sentence to create a new signature request message with the current location data attached.

[0037] In some embodiments, to recover the master seed, nine signature request messages are created using the information just described, as well as eight other signature messages containing location data incremented or decremented by one for generated neighborhoods surrounding the location data. The location authority can verify each location data and perform a signing operation on each signature request message.

[0038] The PRNG 130 is a component of the location-based HSM 105 that is configured to generate random numbers. Cryptographic systems such as the location-based HSM 105 utilize the PRNG 130 as a source of uncertainty or entropy within the system. The PRNG 130 uses cryptographic algorithms to generate random bits from a source of randomness. The randomness can come from an analog, uncertain, and unpredictable environment. In some embodiments, the PRNG 130 uses a RNG, which is a software or hardware component that exploits entropy in analog mechanisms to generate unpredictable bits in a digital system. For example, the RNG can directly sample bits from measurements of temperature, acoustic noise, turbulence, or static electricity.

[0039] In some embodiments, the PRNG 130 derives entropy from the current time when the location-based HSM 105 generates the signature request message. For example, the location-based HSM 105 begins generating a master seed at 6:05 PM. The PRNG 130 can then use 6:05 PM as entropy when generating random numbers. While minutes are shown, other time units may be used. For example, hours, seconds, or milliseconds may also be used.

[0040] The PRNG 130 may receive random bits from the RNG at regular intervals and use those bits to update the contents of the entropy pool. The PRNG 130 may run a deterministic random bit generator algorithm that expands some bits from the entropy pool into longer sequences to generate random numbers for the location-based HSM 105.

[0041] GPS module 140 is a component of location-based HSM 105 that is configured to determine the location of location-based HSM 105 based on its GPS coordinates. GPS module 140 can communicate with a GPS system to obtain location information for location-based HSM 105. In some embodiments, GPS module 140 provides location data to encryption module 120 at predetermined intervals (e.g., periodic location pings to the GPS system).

[0042] Communication device 150 is a component of location-based HSM 105 that is configured to send a signature request message to location authority 160. Communication device 150 is further configured to receive a response back from location authority 160. Communication device 150 can send and receive messages via short-range wired communication (e.g., Universal Serial Bus (USB), Serial AT Attachment (SATA), Thunderbolt, USB-C) or via short-range wireless communication (e.g., Near Field Communication (NFC), Bluetooth, Radio frequency identification (RFID), Bluetooth low energy, QR Code, Wi-Fi, Z-Wave, Li-Fi, Ultrasound).

[0043] The communication device 150 is further configured to digitally sign transactions for payments or the like via wired or wireless communication using a private key generated from the master seed.

[0044] Location authority 160 is a component of authorization environment 100 that is configured to approve signature request messages and respond with a signature. In some embodiments, location authority 160 is a facility located in a fixed location that can sign messages based on location. For example, location authority 160 can be located in a public building or monument in a city or town. Location authority 160 can also be assigned an authorization zone. An authorization zone is an area designated to location authority 160 within which location authority 160 has the authority to approve signature requests submitted by location-based HSM 105. For example, an authorization zone can include that area of ​​a city. If location-based HSM 105 generates a signature request within the authorization zone, location authority 160 can approve the signature request. However, if the signature request is not within the authorization zone, location authority 160 cannot approve the signature request.

[0045] In some embodiments, multiple location authorities 160 exist within the same authorization zone. Each location authority within the authorization zone may have the same private key for approving signature requests. For example, location authorities 160 may be located in all public buildings within a city, as well as at predetermined locations around the city.

[0046] In some embodiments, location authority 160 includes a response limiter. The response limiter limits the number of signature requests from a particular hash function in a signature request message. For example, if a signature request message is sent to location authority 160 multiple times with the same hash function, the response limiter automatically rejects the request after a predetermined number of attempts. The rejection of the request can be delayed indefinitely or for a predetermined time (e.g., one hour, one day, one week, etc.). The response limiter can be considered a countermeasure against brute force attacks that send a large number of requests.

[0047] In some embodiments, the location authority 160 verifies the movement of the location-based HSM 105. The location authority 160 can evaluate the time and / or route taken by the location-based HSM 105 based on the location data received in the signing request. For example, a time limit corresponding to the distance from the location data to the location authority 160 can be set. If the location-based HSM 105 cannot send the signing request within the time limit, the signing request is rejected. In some embodiments, the location authority 160 can receive location information obtained by the location-based HSM 105 from the time the signing request message was generated to the time the signing request message was sent to the location authority 160. The location authority 160 can analyze the location information to determine whether the location-based HSM 105 moved in a normal manner (e.g., roadway, train, etc.) or whether the location information does not provide an accurate travel path (e.g., a straight line through a mountain, incomplete information, etc.).

[0048] In some embodiments, a location authority 160 requires approval from multiple location authorities 160 within an approval zone. For example, there may be 15 location authorities 160 within an approval zone. Of the 15, a location authority 160 may require approval from three before the location-based HSM 105 will receive a signature. In some embodiments, location authorities 160 are given different approval levels within an approval zone. For example, there may be a city-level location authority 160 and a county-level location authority 160. In some embodiments, a location authority 160 requires approval from location authorities 160 with different approval levels 160. For example, a location authority 160 may require approval from a city-level location authority 160 and a county-level location authority 160 before sending an approval signature.

[0049] It should be noted that Figure 1 is intended to illustrate major representative components of an exemplary authorization environment 100. However, in some embodiments, the individual components may be more or less complex than depicted in Figure 1, components may be present other than or in addition to those depicted in Figure 1, and the number, type, and configuration of such components may vary.

[0050] 2A and 2B are example maps 200, 205 illustrating approval regions, according to an embodiment of the present disclosure. The example map 200 includes location authorities 210-1, 210-2, 210-3, 210-4, and 210-5 (collectively, "location authorities 210"). As shown in FIG. 1, the location authorities 210 may be the same as or equivalent to the location authorities 160. Each of the location authorities 210 includes an acceptance area 214-1, 214-2, 214-3, 214-4, and 214-5 (collectively, "acceptance areas 214") and an approval zone 218-1, 218-2, 218-3, 218-4, and 218-5 (collectively, "approval zones 218").

[0051] Location authorities 210 may be distributed throughout regions, regions, countries, and the like. Additionally, location authorities 210 may be located at fixed locations within a zone of approval 218. In some embodiments, multiple location authorities 210 may be located within the same zone of approval 218, and each location authority 210 within the same zone of approval 218 may be approved based on the zone of approval 218.

[0052] Reception area 214 indicates an area proximate to location authority 210 to which location-based HSM 105 can send a signature request message via wired or near-field communication. Location authority 210 can send a response to the signature request back to location-based HSM 105 based on the location data included in the signature request message.

[0053] The approval zone 218 indicates an area around the location authority 210 within which the location authority 210 can approve a signing request message. For the location authority 210 to approve a signing request, the signing request message must be generated at a location within the approval zone of the location authority 210.

[0054] 2B illustrates a map 205 of an exemplary key generation process between location-based HSM 105 and location authority 210-1. Entity 280 with location-based HSM 105 can generate a signature request message at a location within authorization zone 218-1. Once generated, entity 280 can move into acceptance area 214-1. In the acceptance area, location-based HSM 105 can send a signature request message with location data of the original location to location authority 210-1. Location authority 210-1 can verify the signature request message and the location data. If verified, location authority 210-1 can send a signature back to location-based HSM 105.

[0055] 3 illustrates an exemplary countermeasure location data structure 300, according to an embodiment of the present disclosure. GPS location data is typically accurate to within about 10 meters. Thus, if location data is collected at a particular point, it may be inaccurate around the 10-meter point. To account for possible inaccuracies, the location-based HSM 105 may implement the countermeasure location data structure 300 when it initially generates a signing request message and creates a master seed.

[0056] In some embodiments, multiple signature request messages may be required to regenerate the master seed using the mnemonic sentence. Location-based HSM 105 may initially generate the signature request message at the same location LD1 where the original signature request message was generated. Location-based HSM 105 may use that location data LD1 to derive other locations. As shown in configuration 300, location data LD1 may generate LD2, LD3, LD4, LD5, LD6, LD7, LD8, and LD9 by adjusting the longitude and latitude coordinates of location data LD1.

[0057] For example, location data LD2 can be generated by incrementing the longitude coordinate by a predetermined amount (e.g., 1, 2, 5, etc.) and decrementing the latitude coordinate by the same predetermined amount. The remaining location data locations LD3-9 can be generated in a similar manner and included in the corresponding signature request messages. In this particular configuration, location-based HSM 105 generates nine signature request messages, each of which requires approval from location authority 160 before receiving a signature.

[0058] 4 is a flow diagram illustrating a process 400 for creating a master seed using a location-based HSM according to an embodiment of the present disclosure. Process 400 may be implemented by, for example, one or more entities in authentication environment 100, computer system 800, a processor, or another configuration of hardware or software, or both.

[0059] Process 400 begins with location-based HSM 105 creating a signature request message, as shown in step 410. Encryption module 120 may generate the signature request using Secure Hash Algorithm 2. In some embodiments, encryption module 120 generates the signature request by applying a SHA-256 function using a random number generated by PRNG 130 and location data detected by GPS module 140.

[0060] Communication device 150 transmits the signature request message to location authority 160. This is shown in step 420. Communication device 150 can transmit the signature request message via short-range wired communication or via short-range wireless communication, depending on the configuration of location-based HSM 105. For example, location-based HSM 105 may connect to a USB slot on location authority 160 and transmit the signature request message. In some embodiments, location-based HSM 105 transmits the signature request message to location authority 160 via short-range communication, such as NFC or Bluetooth.

[0061] Communication device 150 receives the response back from location authority 160. This is shown in step 430. The response back from location authority 160 can be received in the same or similar manner as the sending of the signature request message. For example, if the signature request message was sent via NFC, the returning response is received via NFC. However, in some embodiments, location authority 160 can be configured to send the returning response only in one direction. For example, location authority 160 need only send the response back via Bluetooth, regardless of how the signature request message was received from location-based HSM 105.

[0062] The location-based HSM 105 determines whether the response includes a signature response or an error response. This is shown in step 440. If it is determined that the response includes a signature, the encryption module 120 can generate a master seed. This is shown in step 450. In some embodiments, the encryption module 120 creates the master seed using a key derivation function that uses the mnemonic sentence as the password and a SHA-2 hash algorithm of the signature as the salt variable. With the master seed, the encryption module 120 can generate a checksum and mnemonic sentence that can be used to regenerate the master seed. However, if the response includes an error message, the location-based HSM 105 can display the error message. This is shown in step 460. The location-based HSM 105 can display the error message via a display located on the location-based HSM 105, via an indicator light, via a noise indicating an error, or via some other means.

[0063] 5 is a flow diagram illustrating a process 500 for creating a signature request message according to an embodiment of the present disclosure. Process 500 may be implemented by, for example, one or more entities in authorization environment 100, computer system 800, a processor, or another configuration of hardware or software, or both. In some embodiments, process 500 is a sub-process of step 410 of FIG. 4.

[0064] Process 500 begins by GPS module 140 obtaining location data for location-based HSM 105, as shown in step 510. The location data is the current GPS coordinates of location-based HSM 105 at the time signature request message generation process 500 begins. GPS module 140 extracts longitude and latitude coordinates from the location data, as shown in step 520. The extracted longitude and latitude coordinate values ​​may be rounded to four decimal places. For example, if the longitude and latitude coordinates are 35.658581° N, 139.745438° E, the resulting values ​​are 35.6585 and 139.7454.

[0065] The PRNG 130 generates random numbers, as shown in step 530. The PRNG 130 may implement a deterministic random bit generator algorithm that expands some bits from the entropy pool into longer sequences to generate random numbers for the location-based HSM 105. In some embodiments, the PRNG 130 uses the current time as entropy for generating random numbers. For example, the current time may be obtained to add to the entropy pool from which the PRNG 130 generates random numbers.

[0066] The encryption module 120 creates a signature request message, as shown in step 540. The encryption module 120 can generate the signature request by applying a SHA-256 function using the random number generated by the PRNG 130 and adding the longitude and latitude coordinates extracted by the GPS module 140.

[0067] 6 is a flow diagram illustrating a process 600 for approving a signature request message according to an embodiment of the present disclosure. Process 600 may be implemented by, for example, one or more entities in authorization environment 100, computer system 900, a processor, or another configuration of hardware or software, or both.

[0068] Process 600 begins by receiving a signing request message from location-based HSM 105, as shown in step 610. Location authority 160 may receive the signing request message via short-range wired communication or via short-range wireless communication, depending on the configuration of location-based HSM 105 and location authority 160. For example, location-based HSM 105 may connect to a USB slot on location authority 160 and transmit the signing request message. In some embodiments, location authority 160 receives the signing request message from location-based HSM 105 via short-range communication, such as NFC or Bluetooth.

[0069] The location authority 160 determines whether the location data attached to the signing request represents a location within the location authority's 105 zone of approval. This is shown in step 620. For example, the zone of approval may be a 20-mile radius around the location authority 160. If the location data attached to the signing request message represents a location within a 20-mile radius, the location authority 160 may proceed to step 630. However, if the location data is not within the location authority's 160's assigned zone of approval, the location authority 160 sends an error response back to the location-based HSM 105. This is shown in step 640.

[0070] The location authority 160 verifies that the location-based HSM 105 has not reached a predetermined limit on the signature request message. This is shown in step 630. For example, if a signature request message is sent to the location authority 160 multiple times with the same hash function, a response limiter automatically rejects the request after a predetermined number of attempts (e.g., once per hour, day, week, month, etc.). The rejection of the request can be delayed indefinitely or for a predetermined amount of time (e.g., once per hour, day, week, etc.). If the location authority 160 determines that the location-based HSM 105 has reached its predetermined limit, the location authority sends an error response back to the location-based HSM 105. However, if the location-based HSM has not reached its limit, process 600 can proceed to step 650.

[0071] The location authority 160 performs a signing operation on the signature request message, as shown in step 650. In some embodiments, the location authority 160 generates a digital signature, which is a mathematical scheme for verifying the authenticity of a digital message or document. Upon completion, the location authority 160 sends the digital signature back to the location-based HSM 105, as shown in step 660.

[0072] 7 is a flow diagram illustrating a process 700 for recreating a master seed according to an embodiment of the present disclosure. Process 700 may be implemented by, for example, one or more entities in authentication environment 100, computer system 800, a processor, or another configuration of hardware or software, or both.

[0073] Process 700 begins by first receiving a mnemonic sentence generated from a random number and a signature checksum, as shown in step 710. Location-based HSM 105 creates a signature request message in the same location as the previous signature request message, as shown in step 720. Encryption module 120 may generate the signature request using Secure Hash Algorithm 2. In some embodiments, encryption module 120 generates the signature request by applying a SHA-256 function using a random number separate from the mnemonic sentence and location data detected by GPS module 140.

[0074] Communication device 150 transmits the signature request message to location authority 160. This is shown in step 730. Communication device 150 can transmit the signature request message via short-range wired communication or via short-range wireless communication, depending on the configuration of location-based HSM 105. For example, location-based HSM 105 may connect to a USB slot on location authority 160 and transmit the signature request message. In some embodiments, location-based HSM 105 transmits the signature request message to location authority 160 via short-range communication, such as NFC or Bluetooth.

[0075] Communications device 150 receives the response back from location authority 160. This is shown in step 740. The response back from location authority 160 can be received in the same or similar manner as the sending of the signature request message. For example, if the signature request message was sent via NFC, the returning response is received via NFC. However, in some embodiments, location authority 160 may be configured to send the returning response only in one direction. For example, location authority 160 need only send the response back via Bluetooth, regardless of how the signature request message was received from location-based HSM 105.

[0076] The location-based HSM 105 determines whether the response includes a signature response or an error response, as shown in step 750. If it is determined that the response includes a signature, process 700 may proceed to step 770. However, if the response includes an error message, the location-based HSM 105 may display the error message, as shown in step 760. The location-based HSM 105 may display the error message via a display located on the location-based HSM 105, via an indicator light, via a noise indicating an error, or via some other means.

[0077] The location-based HSM 105 compares the checksum, which is separate from the mnemonic sentence, with the signature received by the location authority 160. This is shown in step 770. The new checksum can be generated by applying a SHA-2 function to the signature. The first 8 bits of the function can represent the checksum. The location-based HSM 105 determines whether the checksums match. This is shown in step 780. If the checksum does not match the new checksum, the location-based HSM 105 indicates an error.

[0078] If the checksums match, the encryption module generates a master seed, as shown in step 790. In some embodiments, the encryption module 120 creates the master seed using a key derivation function that uses the mnemonic sentence as the password and a SHA-2 hash of the signature as the salt variable.

[0079] 8, there is shown a high-level block diagram of an exemplary computer system 800 (e.g., authorization environment 100, location-based HSM 105) that may be used in implementing one or more of the methods, tools, and modules described herein, and any associated functionality (e.g., using one or more processor circuits of a computer or computer processor), in accordance with embodiments of the present disclosure. In some embodiments, the major components of computer system 800 may include one or more processors 802, memory 804, terminal interface 812, I / O (input / output) device interface 814, storage interface 816, and network interface 818, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via memory bus 803, I / O bus 808, and I / O bus interface 810.

[0080] Computer system 800 may include one or more general-purpose programmable central processing units (CPUs) 802-1, 802-2, 802-3, and 802-N, generally referred to herein as processors 802. In some embodiments, computer system 800 may include multiple processors typical of relatively large systems, while in other embodiments, computer system 800 may alternatively be a single CPU system. Each processor 801 may execute instructions stored in memory 804 and may include one or more levels of on-board cache.

[0081] The system memory 804 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 822 or cache memory 824. The computer system 800 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 826 may provide for reading from and writing to non-removable, non-volatile magnetic media, such as a “hard drive.” Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. Additionally, the memory 804 may include flash memory, such as a flash memory stick drive or flash drive. Memory devices may be connected to the memory bus 803 by one or more data media interfaces. The memory 804 may include at least one program product having a set of program modules (e.g., at least one) configured to perform the functions of various embodiments.

[0082] 8 as a single bus structure providing a direct communication path between processor 802, memory 804, and I / O bus interface 810, memory bus 803, in some embodiments, may include multiple distinct buses or communication paths that may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Additionally, while I / O bus interface 810 and I / O bus 808 are shown as single respective units, computer system 800, in some embodiments, may include multiple I / O bus interface units, multiple I / O buses, or both. Additionally, while multiple I / O interface units are shown separating I / O bus 808 from the various communication paths to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0083] In some embodiments, computer system 800 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 800 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0084] It should be noted that Figure 8 is intended to illustrate major representative components of an exemplary computer system 800. However, in some embodiments, the individual components may be more or less complex than depicted in Figure 8, components may be present other than or in addition to those depicted in Figure 8, and the number, type, and arrangement of such components may vary.

[0085] One or more programs / utilities 828, each having at least one set of program modules 830 (e.g., authentication environment 100, location-based HSM 105), may be stored in memory 804. The programs / utilities 828 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may comprise an implementation of a network environment. The programs 828 and / or program modules 830 generally perform the functions or methodologies of various embodiments.

[0086] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0087] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media may also include portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or groove-embossed structures having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0088] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0089] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the “C” programming language or similar. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0090] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0091] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine such that the instructions, executed via the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein comprises a product containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0092] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0093] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, having one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be executed as a single step, may be executed concurrently or substantially concurrently, in a partially or fully overlapping manner, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0094] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit various embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will be further understood that the terms "includes" or "including," or combinations thereof, when used herein, specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof. In the preceding detailed description of exemplary embodiments of various embodiments, reference has been made to the accompanying drawings (in which like numerals represent like elements), which form a part of this specification, and which show, by way of illustration, specific exemplary embodiments in which various embodiments may be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the embodiments, but other embodiments may be used, and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. In the foregoing description, numerous specific details have been set forth to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the embodiments.

[0095] Where different reference numerals have a common number followed by a different letter (e.g., 100a, 100b, 100c) or a punctuation mark followed by a different number (e.g., 100-1, 100-2 or 100.1, 100.2), use of the reference symbol alone (e.g., 100) without the letter or subsequent number may refer to the entire group of elements, any subset of the group, or illustrative examples of the group as a whole.

[0096] Furthermore, the phrase "at least one," when used in conjunction with a list of items, means that one or more different combinations of the listed items may be used, and only one of the items in the list may be required. In other words, "at least one" means that any combination of the items and number of items in the list may be used, but not all items in the list are required. An item may be a particular object, thing, or category.

[0097] For example, without limitation, "at least one of item A, item B, or item C" may include item A, item A and item B, or item B. This example may also include item A, item B and item C, or item B and item C. Of course, any combination of these items may be present. In some illustrative examples, "at least one" may be, for example, without limitation, 2 items A, 1 item B, 10 items C, 4 items B, and 7 items C, or other suitable combinations.

[0098] Different instances of the word "embodiment" as used herein do not necessarily refer to the same embodiment, although they may. Any data and data structures shown or described herein are merely examples; other embodiments may use different amounts of data, types of data, fields, numbers and types of fields, field names, numbers and types of rows, records, entries, or organizations of data. Furthermore, any data may be combined with logic, such that a separate data structure may not be necessary. Therefore, the foregoing detailed description should not be taken in a limiting sense.

[0099] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles, practical applications, or technical improvements of the embodiments beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0100] While the present invention has been described with respect to particular embodiments, it is anticipated that variations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications that fall within the true scope of the invention.

Claims

1. creating a signature request message using a location-based Hardware Security Module (HSM) located at a location, the signature request message being created using a random number generated using a random number generator that generates random numbers using a current time of the location-based HSM; sending the signature request message with the location coordinates attached to a location authority; receiving a response from the location authority providing a signature based on the coordinates of the location; and generating a master seed based on said signature; 10. A computer-implemented method for creating a master seed using location data, comprising:

2. generating the signature request message comprises: obtaining location data for the location-based HSM; determining that the location data is located at a predetermined location; extracting longitude and latitude values ​​from the location data; generating a random number using the random number generator; and The computer-implemented method of claim 1 , further comprising using the random number to create the signing request message and appending the longitude and latitude values.

3. receiving a reconstruction mnemonic sentence for regenerating a second master seed; creating a signing request message using the location-based HSM at the location; sending the signature request message to the location authority with the coordinates of the location attached; receiving a second response from the location authority approving the signature request message and providing a second signature; verifying a checksum derived from the recovered mnemonic sentence with a second checksum derived from the second signature; and generating a second master seed based on the recovered mnemonic sentence and the verification of the second signature and the checksum; The computer-implemented method of claim 1 or 2, further comprising:

4. The computer-implemented method of claim 3 , wherein the signing request message includes location data surrounding the location.

5. The computer-implemented method of any one of claims 1 to 4, wherein the location is within a zone of approval of the location authority.

6. The computer-implemented method of any one of claims 1 to 4, wherein the location authority is located at a geographically fixed location.

7. 1. A computer program for generating a master seed using location data, the computer program comprising: creating a signature request message using a location-based Hardware Security Module (HSM) located at a location, the signature request message being created using a random number generated using a random number generator that generates random numbers using a current time of the location-based HSM; sending the signature request message with the location coordinates attached to a location authority; receiving a response from the location authority providing a signature based on the coordinates; and generating a master seed based on said signature; of A computer program to be executed.

8. The steps for creating the signature request message include: obtaining location data for the location-based HSM; determining that the location data is located at a predetermined location; extracting longitude and latitude values ​​from the location data; generating a random number using said random number generator; and creating the signature request message using the random number and attaching the longitude and latitude values; 8. The computer program of claim 7, comprising:

9. The computer, receiving a restoration mnemonic sentence for regenerating a second master seed; generating a signature request message using the location-based HSM at the location; sending the signature request message to the location authority with the coordinates of the location attached; receiving a second response from the location authority approving the signature request message and providing a second signature; verifying a checksum derived from the recovered mnemonic sentence with a second checksum derived from the second signature; and generating a second master seed based on the recovered mnemonic sentence and the verification of the second signature and the checksum; 9. The computer program according to claim 7 or 8, further comprising:

10. The computer program product of claim 9 , wherein the signature request message includes location data surrounding the location.

11. The computer program of any one of claims 7 to 10, wherein the location is within a zone of approval of the location authority.

12. The computer program of any one of claims 7 to 10, wherein the location authority is located at a geographically fixed location.

13. a pseudorandom number generator (PRNG) configured to generate random numbers; a global positioning system (GPS) module configured to determine a location of a location-based hardware security module (HSM); a cryptographic module configured to generate a signature request message, the signature request message including the random number and the location; a communications device configured to send the signature request message to a location authority for approval, the communications device further configured to receive a signature from the location authority upon approval of the signature request message; and The encryption module is further configured to generate a master seed based on the signature. A location-based HSM for generating a master seed using location data having:

14. The location-based HSM of claim 13 , wherein the PRNG uses a current time as entropy to generate the random numbers.

15. 15. The location-based HSM of claim 13 or 14, wherein the location is the longitude and latitude coordinates of the location-based HSM within the location authority's zone of approval.

16. 16. The location-based HSM of claim 13, wherein the encryption module is further configured to recreate the master seed based on a mnemonic sentence.

17. 17. The location-based HSM of claim 13, wherein the communications device is further configured to send the signature request message to a plurality of location authorities to receive the signature.

18. 18. The location-based HSM of any one of claims 13 to 17, wherein the location authority is a facility at a fixed location.

Images