TECHNICAL FIELD

[0001] The present embodiments relates generally to management and configuration of network devices, and more particularly, to a Hardware Security Module (HSM) cryptographic unit for networked communications having a location tracker coupled thereto to support data residency requirements.

BACKGROUND

[0002] A Hardware Security Module (HSM) is a dedicated crypto processing unit that is specifically designed for the hardware protection of the cryptographic key lifecycle. HSMs act as trust anchors that protect the crypto infrastructure of some of the most security-conscious organizations in the world by securely managing, processing, and storing cryptographic keys inside a hardened, tamper-resistant device. Enterprises use hardware security modules to protect transactions, identities, and applications, as HSMs excel at securing cryptographic keys and provisioning encryption, decryption, authentication, and digital signing services for a wide range of applications.

[0003] HSM protect keys and are used by applications in on premise, virtual, and cloud environments. They are hardware appliances that can be stored in racks in a data center and associated with cryptographic networking components. They are deployed and securely configured remotely in any of these environments. Because they are secure and operate on sensitive data only authorized applications are allowed access. Access to a HSM is usually controlled via a management interface.

[0004] FIG 1 illustrates an existing work flow for setting up an HSM in a protected environment using untrusted hardware. Here, as seen in the first step, when the lab operator receives a delivery of HSM units, the operator must rack and stack the HSM units within the highly secure lab environment. The operator then powers up and onboards the HSM units onto a network cluster to provide cloud services. This onboarding is the process of connecting a new unit, first to the network, then the Internet, then subsequently enabling services on the unit. A cluster is a collection of individual HSMs that a Cloud HSM service provider synchronizes and maintains such that an external user or customer considers the cluster as one logical HSM for their purposes. From the customer’s perspective, when they sign up for HSM services, they commission and use the services of one generic HSM, where the company provisions the HSM according to their specifications. The customer is not responsible for allocation, delegation and maintenance of services amongst the multiple HSMs in the cluster. Generally, onboarding is performed by the company hosting the cluster of HSMs, and includes provisioning and configuring the units for use by a particular customer/user according to their preferences, one of which, is the unit’s network configuration settings, such as an Internet Protocol (IP) address.

[0005] As seen in the second step, to configure the HSM network communication, the lab operator manually connects a serial cable from a workstation lap-top to the HSM to take control of it, and then manually configures the HSM IP address. The workstation lap-top is however an untrusted device, which may further include a keyboard, mouse, etc. In this existing approach, the HSM detects the serial connection and opens up a terminal window to the untrusted device, here, the workstation lap-top. Although the current implementations support secure shell logging into the HSM over the serial console connection, it only provides for secure access over an unsecured network from the administrators perspective; it does not guarantee the work-station laptop or other device the lab operator uses is trusted or authorized for use

[0006] The lab operator, by way of a user interface or command console on the untrusted lap-top through the serial interface, can then manually program in each IP address for the HSM, and any other related parameters, such as MAC addresses, gateway, masks, Ipv4, subnets and so on. This is a tedious manual process that must be done for each HSM during set-up and possibly later if further initialization is required for the network configuration. This manual configuration process is not easily automated because of company policy based lab restrictions. For example, the DHCP protocol cannot be used. In this process, the HSM relies on default user and roles to the initial setup and control of the HSM. Moreover, the use of a serial port is being deprecated as it adds components costs. Furthermore, it is manually laborious for the lab operator to set-up and configure each HSM unit, for example, finding and identifying the serial port, plugging in the serial cable, connecting and setting up the HSM, reboots, and so on. The complexity increases as some customers request installation and provisioning of many HSMs at once.

[0007] To further complicate matters, Data Sovereignty laws in many countries restrict certain data hosting beyond geographical boundaries of the country in question. In almost all cases, this sensitive data is related to payments, Health, Employment, or card Industry.

[0008] There are many cloud based HSM related solutions that various vendors provide to customers. In those solutions, although they specify where the actual HSM devices are located, there is no way that a customer can confirm such claim by the cloud based HSM provider. At present, there is no mechanism by which a customer using an HSM over the cloud can determine the location of the HSM device.

[0009] All of the subject matter discussed in this Background section is not necessarily prior art and should not be assumed to be prior art merely as a result of its discussion in the Background section. Along these lines, any recognition of problems in the prior art discussed in the Background section or associated with such subject matter should not be treated as prior art unless expressly stated to be prior art. Instead, the discussion of any subject matter in the Background section should be treated as part of the inventor's approach to the particular problem, which, in and of itself, may also be inventive.

SUMMARY

[0010] In some embodiments, a system supportive of data residency requirements includes a Hardware Security Module (HSM) hosted on a cloud environment and a location tracker embedded within or directly connected to the HSM to provide an HSM location, the HSM including one or more processors and memory coupled to the one or more processors, where the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations. The operations can include receiving a request for access to information over a network, obtaining authorized location information where the HSM is authorized to process the request from a source of the request for access, comparing the HSM location with the authorized location information from the source, processing the request for access if the HSM location is within the authorized location information and rejecting the request if the HSM location is not within the authorized location information.

[0011] In some embodiments, the location tracker embedded within or directly connected to the HSM is a global navigation satellite system (GNSS) module.

[0012] In some embodiments, the system further includes computer instructions which causes the one or more processors to obtain the authorized location by generating a user interface in response to the receipt of the request which provides an option for a manual input of a location or locations where the HSM is authorized to process the request as the authorized location information.

[0013] In some embodiments, the system further includes computer instructions which causes the one or more processors to obtain authorized location information by receiving a key from the source, wherein the key contains the authorized location information from the source.

[0014] In some embodiments, the system further includes computer instructions, which causes the one or more processors to maintain the HSM location hidden from users.

[0015] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to generate a key that can only be used by HSMs in predetermined locations and responding with the transmission of a key that cannot be used with HSMs outside the predetermined locations.

[0016] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to generate a key that can only be used in predetermined countries and responding with the transmission of a key that cannot be used outside the predetermined countries.

[0017] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to generate a key and responding with the transmission of a key that cannot be used outside the country of the HSM location. [0018] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to process a key containing meta data of the location information where the HSM is authorized and processing the key if the HSM location is within the meta data of the location information where the HSM is authorized. [0019] In some embodiments, the system further includes computer instructions, which causes the one or more processors to securely configure the HSM using a computer or mobile device within a protected environment for programming a secure element by detecting a presence of the secure element in a vicinity of the HSM, authenticating the secure element as a trusted device to the HSM by way of the certificate stored thereon, authenticating a user of the secure element to the HSM, retrieving a set of IP addresses and authorized location information in the secure element associated with an HSM network configuration responsive to authenticating the secure element and authenticating the user, and configuring an initial network state of the HSM for external communication with the set of IP addresses, where the external communication proceeds with an IP address if the HSM location is within the authorized location information associated with the IP address of the set of set of IP addresses.

[0020] In some embodiments, the security element is one of: (a) embedded in a smart card having stored thereon a certificate for establishing the smart card as a trusted device, and the presence of the secure element is detected when the smart card is inserted; (b) embedded in a LISBC e-Token having stored thereon a certificate for establishing the LISBC e-Token as a trusted device, and the presence of the secure element is detected when the LISBC e-Token is inserted; or (c) embedded in a Near Field Communication (NFC) chip of a mobile device having stored thereon a certificate for establishing the NFC chip as a trusted device, and the presence of the secure element is detected when the NFC chip is in close proximity to the computer or mobile device.

[0021] In some embodiments, a system supportive of data residency requirements can include a plurality of Hardware Security Modules (HSMs) hosted on a cloud environment and a location tracker embedded within or directly connected to the plurality of HSMs in a protected environment to provide an HSM location, the plurality of HSMs including one or more processors and memory coupled to the one or more processors, where the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations. The operations can include receiving a request for access to information over a network at one of the HSMs among the plurality of HSMs, obtaining authorized location information where the HSM is authorized to process the request from a source of the request for access, comparing the HSM location with the authorized location information from the source, processing the request for access if the HSM location is within the authorized location information, and rejecting the request if the HSM location is not within the authorized location information.

[0022] In some embodiments, a method supportive of data residency requirements at a Hardware Security Module (HSM) hosted on a cloud environment and further having a location tracker embedded within or directly connected to the HSM to provide an HSM location, the method including the steps of receiving a request for access to information over a network, obtaining or receiving authorized location information where the HSM is authorized to process the request from a source of the request for access, comparing the HSM location with the authorized location information from the source, and processing the request for access only if the HSM location is within the authorized location information.

[0023] In some embodiments, the method further includes the step of rejecting the request if the HSM location is not within the authorized location information.

[0024] In some embodiments, the method further obtains the authorized location by generating a user interface in response to the receipt of the request which provides an option for a manual input of a location or locations where the HSM is authorized to process the request as the authorized location information.

[0025] In some embodiments, the method further obtains the authorized location information by receiving a key from the source, wherein the key contains the authorized location information from the source.

[0026] In some embodiments, the method further receives a request to generate a key that can only be used by HSMs in predetermined locations or countries and responding with the transmission of a key that cannot be used with HSMs outside the predetermined locations or countries.

[0027] In some embodiments, the method further receives a request to generate a key and responding with the transmission of a key that cannot be used outside the country of the HSM location.

[0028] In some embodiments, the HSM in a secure configuring mode by a computer or mobile device in the presence of a secure element performs one of detecting insertion of a smart card embedded with the secure element, detecting insertion of a LISBC eToken embedded with the secure element, or detecting a near-field communication chip embedded with the secure element, where a step of authenticating a user of the secure element includes entry of a personal identification number (PIN) or multi-factor authentication (MFA).

[0029] In some embodiments, a customer configuration file in the secure element includes a set of unique IP addresses and authorized locations specific to each HSM in a configuration of multiple HSMs in a protected environment, whereby upon detection of the presence of the secure element, each of the multiple HSMs is automatically configured with a respective set of the unique IP addresses and authorized locations.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which are incorporated in and constitute a part of this description, illustrate embodiments consistent with the embodiments and, together with the description, serve to explain the principles of the embedments.

[0031] FIG. 1 illustrates an existing work flow for setting up an HSM in a non-secure manner using untrusted devices;

[0032] FIG. 2A depicts a protected environment for generating and programming secure element content into a trusted device thereafter used for configuring an HSM in a secure manner in accordance with an embodiment;

[0033] FIG. 2B illustrates methods steps for programming the trusted device in the protected environment of FIG 2A in accordance with an embodiment; [0034] FIG. 3A depicts an environment for onboarding an HSM with trusted devices used to configure the HSM for network communications in a secure manner in accordance with an embodiment;

[0035] FIG. 3B illustrates methods steps for onboarding an HSM with trusted devices used to configure the HSM for network communications in a secure manner in accordance with an embodiment;

[0036] FIG. 4 depicts exemplary components of a Hardware Server Module (HSM) in accordance with one embodiment;

[0037] FIG. 5 depicts a system having a plurality of HSMs in a datacenter and corresponding location trackers in accordance with the embodiments;

[0038] FIG. 6 depicts a system having an HSM and a location tracker in accordance with the embodiments;

[0039] FIG. 7 depicts a system having an HSM and a location tracker where a request to generate a key is received and generated by the HSM in accordance with the embodiments; [0040] FIG. 8 depicts a system having an HSM and a location tracker where a request to generate a key is received and rejected by the HSM in accordance with the embodiments; [0041] FIG. 9 depicts another system having an HSM and a location tracker where a request to generate a key is received and generated by the HSM in accordance with the embodiments;

[0042] FIG. 10 depicts a system having an HSM and a location tracker where a request to import a key generated in a particular location is received and rejected by the HSM in accordance with the embodiments; and

[0043] FIG. 11 illustrates a flow chart for a method supporting data residency requirements using an HSM with an embedded GNSS tracker in accordance with the embodiments.

[0044] Specific embodiments have been shown by way of example in the foregoing drawings and are hereinafter described in detail. The figures and written description are not intended to limit the scope of the inventive concepts in any manner. Rather, they are provided to illustrate the inventive concepts to a person skilled in the art by reference to particular embodiments.

DETAILED DESCRIPTION

[0045] Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings in which the same numbers in different drawings represent the same or similar elements unless otherwise represented. The implementations set forth in the following description of exemplary embodiments do not represent all implementations consistent with the embodiments. Instead, they are merely examples of apparatuses and methods consistent with aspects related to the embodiments as recited in the appended claims.

[0046] In the context of the present description, an HSM is a hardened, tamper-resistant hardware device that secure cryptographic processes by generating, protecting, and managing keys used for encrypting and decrypting data and creating digital signatures and certificates. A “payments HSM” is an HSM for use in financial payments industry. A “hosted HSM” is a payments HSM physically hosted by a computing service provider, for example, within a data center. A “cloud HSM” provides same functionality as on-premises HSMs with the benefits of a cloud service deployment, without the need to host and maintain on premises appliances. A HSM deployment can provide for Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (laaS) models.

[0047] The “configuring” of a HSM refers to the process/procedure of setting up or changing the parameters of the HSM for its operational or administrative use. It can also refer to the configuring of resources/services offered by the HSM (e.g., network, security, users, data protection, etc.) and associated objects (e.g. keys, data, devices, drivers, etc.). Configuration may be further defined by access rights, permissions of policies and for different users or groups (e.g., administrators, officers, users, etc. The “enforcement” of a configuration refers to confirming to adherence of a quorum policy, for example, to confirm a user has permissions to access, view, update or otherwise interact with a resource, service or object. The manner in which the embodiments limit the use of the HSM dependent on location information is not limited to those disclosed herein. If there is a manner in which location can be used, either by configuring resources, services, associated objects, access rights, permissions, policies or otherwise, such implementations are contemplated herein.

[0048] The term “warranting’ is the process of establishing manufacturer’s trust in the HSM, usually through a software controlled factory installation process. The term “commissioning” is the process of changing from using the pre-placed HSM manufacturer’s trust to the customer’s trust by the end-user, usually within an environment controlled by a service provider. The term “provisioning” of a HSM refers to the process/procedure of managing the allocation of the hosted HSM allocation to a particular end-user. A third party “service provider” is a vendor providing the HSM, or component thereof, a service associated with the HSM, or selling the HSM as a service (including microservices), and a “customer” is an enduser of the hosted HSM’s payment services.

[0049] The acronym “IP” designates any protocol of the Internet protocol suite for operation of network applications, such as, for instance: i) in the Application layer of the OSI model: the Hypertext Transfer Protocol (HTTP) or its secure version HTTPS, DHCP, SMTP, TLS/SSL, etc., ii) in the Transport layer of the OSI model which can be used to transmit data over the Internet or any Local Area Network (LAN) : the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP) needing only one port for full-duplex, bidirectional traffic, the Stream Control Transmission Protocol (SCTP) and the Datagram Congestion Control Protocol (DCCP) which also use port numbers that match the services of the corresponding TCP or UDP implementation, if they exist; and iii), in the Internet (Network) layer: Internet Protocol (IPv4 or IPv6), ICMP, IGMP, etc.

[0050] In described embodiments, there will be considered the non-limiting example of a cloud-based (web-based) payment system architecture, wherein a hosted HSM is housed in a data center and is remotely accessible/configurable by end-users, or operators, through the Internet as a communication network. An operator is a user with administrative privileges for configuring the HSM, for example, a system administrator having their own password and a separate device card, such as a Java Card, for providing additional credentials. Here, a user can also refer to an operator with special privileges above a normal user. It will become apparent to the one with ordinary skills in the art, however, that other public and/or private communication, including for instance a Local Area Network (LAN), can be similarly contemplated.

[0051] FIG. 2A depicts a protected environment for generating and programming secure element content into a trusted device to be used for securely configuring an HSM. The protected environment is the lab facility where one or HSMs are racked and stacked. The trusted device is a certificate based authenticator 4 that is one of a smart card, a USBC e- Token, or a mobile device with near field communication (NFC). The certificate based authenticator 4 is a known device over which the organization has control and can assume a certain level of security. Each certificate based authenticator 4 includes a secure element 5 that contains content, for example, keys 6, certificates 7, IP addresses, and/or other information specifically tied to the HSM, such as a serial number and location information or more authorized location information indicating (e.g., what countries, regions, etc.) where the HSM is authorized to process data. Once the secure element content is programmed into the trusted device, it will be used to securely configure the network setup of the HSM and guarantee an end to end trust chain.

[0052] The secure element 5 is a tamper resistant chip capable of running secure applications with a certain level of security and features. It is an integrated circuit chip that by design protects its host device from unauthorized access and is used to run a limited set of applications, as well as store confidential and cryptographic data. Here, the secure element 5 is pre-programmed with a multi-application OS that takes advantage of the hardware's memory protection features to ensure that each application's data is only available to itself. Application installation and access is controlled by requiring the use of cryptographic keys for each operation. The secure element 5 contains at least one certificate 7 and one or more keys, for example, an asymmetric key pair 6, comprising a private key within a secure memory of the secure element associated with the corresponding public key of a certificate 7 stored therein.

[0053] As shown, the workstation lap-top 3 can be communicatively coupled to the one or more certificate based authenticators 4, each of which can provide multi-factor authentication. MFA is an authentication method that requires the user to provide two or more verification factors to gain access to a resource. With MFA, a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism - usually from at least two of the following three categories: knowledge-something one knows such as a password or personal identification number (PIN), possession-something one has such as a cryptographic identification device, smart card or secure token, and inherence-biometrics such as fingerprints, iris, face, palm print, etc. The goal of MFA is to create a layered defense and make it more difficult for an unauthorized person to access a target such as a physical location, computing device, network or database.

[0054] FIG. 2B illustrates a method 250 for programming a trusted device in the protected environment of FIG 2A in accordance with an embodiment. The method 250 may include more or less than the number of steps shown and is not limited to only these steps or the order shown. The method 250 is the first part required for generating and programming secure element content into the trusted device; namely, one of the certificate based authenticators 4. Reference will be made to FIG 2A and the components therein when describing the method 250.

[0055] Briefly, the workstation 3 is a computer, or lap-top, comprising one or more processors and memory coupled to the one or more processors, wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations of the method steps 252-262. In another embodiment, a mobile phone may serve as the computer workstation for programming the trusted device with secure element content.

[0056] At step 252, the workstation 3 detects the presence of the secure element 5. When embedded in a smart card, the presence of the secure element 5 is detected when the smart card is inserted in its card reader port. When embedded in a LISBC e-Token, the presence of the secure element 5 is detected when the e-Token is inserted in its USB port. When embedded in an NFC, the presence of the secure element 5 is detected when the NFC is in close proximity to the workstation 3.

[0057] At step 254, the workstation 3 authenticates the secure element as a trusted device by way of the certificate 7 stored thereon. It is one-way because the workstation needs only to authenticate the trusted device, which is occurring here in a protected environment. It should also be noted that multiple certificates might be stored in the secure element. For this device authentication step, this particular certificate may have been issued by a private certificate authority, for example, the internal organization or HSM manufacturer. Once authenticated, a secure channel is configured for communications by and between the workstation 3 and trusted device 4.

[0058] At step 256, the workstation 3 authenticates the user of the trusted device 4 (e.g. smart card) via the secure element 6. At the most basic level, this can occur when the workstation presents the user with a username and password prompt, and the user thereafter responds with correct credentials/responses (securely stored in, and accessed via the secure element 6). As noted above, a more sophisticated user authentication is contemplated with multi-factor authentication. MFA provides greater assurance that user is really who they are claiming to be, and may include the addition to the user password of a one-time password (OTA), a token, an answer to a security question, or a biometric print, as examples.

[0059] Once the trusted device and the user are both authenticated, the workstation 3 establishes a secure communication for programming the trusted device with secure element content, as seen in step 258. These secure communications can be achieved by way of other certificates and keys stored on the certificate based authenticator 4, including SSL/TLS and standard PKI mechanisms for key generation, exchange and session management.

[0060] At step 260, the workstation 3 receives a set of Internet Protocol (IP) addresses responsive to user entry thereon for association with a HSM custom network configuration. The set of IP addresses can also include additional information such as meta data that indicates authorized location for use of each IP address. For example, the lab operator, knowing what IP addresses are needed to set up the cluster of HSMs in the protected environment, can type them in manually, or by way of DevOps automations and scripting, has those I P addresses entered into the workstation 3 (included the corresponding authorized locations for use for each IP address), which thereafter programs them into the trusted device (e.g. Smart Card, LISBC e-Token, NFC). [0061] At step 262, the workstation 4 securely stores the set of IP addresses (and the corresponding authorized location of use for each IP address) in the secure element 5 of the trusted device. This step further includes generating a customer configuration file 10a that includes the set of IP addresses (other HSM specific/relevant data/information such as the corresponding authorized location information for each IP address), signing the customer configuration file with a private key 6 associated with a certificate 7 stored on the secure element 5 thereby producing a signed customer configuration file 10a, and storing the signed customer configuration file 10a in the secure element 5. In practice, the secure element content (e.g. IP address, serial numbers, etc.) is packaged as a secure app (signed by a private key) only accessible to the secure element, and saved thereon.

[0062] Briefly, FIG 3A shows an exemplary signed configuration file 10a. This file includes a header section, a body, a public key, and a signature portion. The signature ensures that the HSM knows the secure element content within the file received off the trusted device (here seen as the smart card 5) was signed by the certificate holder. It provides proof of authenticity, data integrity and nonrepudiation of communications and transactions between the HSM and the trusted smart card 5 device. The signed file includes, but is not limited to, the HSM serial number (e.g., 123456), an object format type (e.g. JSON: a standard readable file format used to transmit data between a server and a web application), and the IP address (e.g. 10.0.10.6) to associate with the HSM. Other HSM specific related parameters may be included in the signed configuration script 10a, such as MAC addresses, gateway, masks, Ipv4, subnets and so on. In this embodiment, the signed configuration script 10a further includes authorized location information corresponding to the HSM Serial Number and/or IP address as shown under the column labeled as “Loc”.

[0063] FIG. 3A depicts an environment for onboarding the HSM with trusted devices used to configure the HSM for network communications in a secure manner. Notably, the onboarding effectively occurs after the trusted devices have been programmed with secure element content, as previously described in FIGS 2A-2B. Certificate-based smart cards with MFA, like that shown in FIG 3A, offer a single solution for strong authentication and applications access control, including remote access, network access, password management, and logon to the HSM 10. The secure element facilitates the generation and security of public key infrastructure (PKI) keys and certificates that are used to authenticate HSM operating systems and customer applications. This cryptographic module contains the critical public/private keys, which allows a user access on the critical data and infrastructure. [0064] As shown, the HSM 10 retrieves certificates, IP addresses, keys and info from signed configuration (config) file in secure element corresponding to HSM serial number(s) and configures HSM for network communications. Each HSM has its own specific serial number as well as other identifying information (e.g., MAC network card addresses, security processor with unique identifier). The HSM includes a smart card reader (shown), one or more USB ports, and optionally an NFC chip. The HSM 10 can further include a location tracker 9 such as a GNSS tracker that is embedded or otherwise connected to the HSM 10. Internal to the HSM is a trust model, comprising a certificate chain 13 typically ending on a self-signed root certificate 14. The certificates in the chain may be installed at different phases of the HSM manufacturing. For example, programming of a HSM factory image may include installation of one or more factory certificates; programming of a warranting image may include further installation of one or more warrant certificates, and programming of customer images or software upgrades may include installation of a customer certificate. The warrant certificates provide authenticity information about the HSM manufacturer and components therein. The self-signed root certificate is not necessarily signed by a CA- neither private nor public. Here, the certificate is signed with its own private key, securely stored deep in the HSM hardware, instead of requesting it from a public or a private CA. The HSM also provides APIs for generating, importing and exporting certificates and handling code signing requests. [0065] As noted earlier, the HSM 10 includes a local console that is serial connected over e.g., a USB-C interface. However, in the preferred embodiments of the embodiments, the serial interface communication for setting up network communication is replaced by way of the trusted device 5 to automatically configure the IP addresses. Upon detection of the trusted device 5 (here seen as a smart card), the HSM establishes a secure communication with the secure element on the smart card, and then executes the secure app on the smart card containing the customer configured secure element content (e.g. IP addresses, authorized location information, etc.), which then automatically configures the network device components within the HSM. To this point, as shown, the HSM include a colored light status indicator. As example, a white color blinking light means HSM is not connected to any network or not assigned an IP address. A solid green colored light means HSM is connected to a network over an assigned IP address. Understandably, other colors, light patterns and variations are contemplated as a function of the automatic IP address configuration stages, for example, based on time and function (success, failure, user input, progress, power, etc.) [0066] To this point, FIG. 3B illustrates a method 350 for onboarding an HSM with trusted devices used to configure the HSM for network communications in a secure manner in accordance with an embodiment. The method 350 may include more or less than the number of steps shown and is not limited to only these steps or the order shown. The method 350 is the second part required for securely configuring the HSM 10 in a protected onboarding environment initially without prior customer network configuration on that HSM. Reference will be made to FIG 3A and the components therein when describing the method 350.

[0067] The HSM 10 comprises one or more processors and memory coupled to the one or more processors, wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations of the method steps. At step 352, the HSM 10 detects a presence of the secure element in a vicinity of the HSM. When embedded in a smart card, the presence of the secure element 5 is detected when the smart card is inserted in its card reader port of the HSM. When embedded in a USBC e-Token, the presence of the secure element 5 is detected when the e-Token is inserted in its USB port of the HSM. When embedded in an NFC, the presence of the secure element 5 is detected when the NFC is in close proximity to the HSM 10. In one arrangement, the step of detecting a presence of the secure element 5 in a vicinity of the HSM 10 occurs automatically upon racking, stacking and onboarding multiple HSMs in the protected environment.

[0068] At step 354, the HSM 10 authenticates the secure element 5 as a trusted device to the HSM by way of the certificate 7 stored thereon. It is one-way because the HSM 10 needs only to authenticate the trusted device. In this illustration, the trusted device is the smart card. For the smart card authentication step, this particular certificate may have been issued by the HSM manufacturer. Once authenticated, the HSM creates a secure channel for communication between it and the smart card. This may include SSL/TLS and standard PKI mechanisms for key generation, exchange and session management. The step by the HSM for authenticating the secure element as a trusted device to the HSM by way of the certificate stored thereon, as seen in FIG 3A, further includes linking certificates through a chain of trust 13 down to a self-signed certificate 14 on the HSM to prove that a particular certificate in the chain originates from a trusted manufacturer source associated with the HSM 10.

[0069] At step 355 the HSM 10 authenticates the user of the secure element to the HSM. As previously mentioned in the method 250, user authentication may be performed by way of basic authentication or more sophisticated multi-factor authentication (MFA) approaches. The information to verify and validate the user’s identity and information is accessible to the smart card via the secure element.

[0070] At step 356, the HSM 10 retrieves the set of IP addresses (and corresponding authorized location information for use of the HSM) in the secure element 5 associated with the HSM custom network configuration responsive to authenticating the secure element and authenticating the user. This step may further include retrieving the signed customer configuration file 110a in the secure element 5, validating the signature of the signed customer configuration file with a public key 6 associated with the certificate 7 stored on the secure element 5, and retrieving the set of IP addresses from the signed customer configuration file 10a

[0071] The method 350 determines the physical location of the HSM (“HSM Location”) by extracting the location information from the location tracker or other location determining device such as GNSS tracker 9 shown in FIG. 3A. At decision block 358, the method 350 compares and determines whether the HSM Location is in an authorize location. If the HSM Location is not in an Authorized Location for the HSM at decision block 358, the HSM cannot be configured (359) and the method returns to the start of the onboarding process again.

[0072] If the HSM Location is within the Authorized Location(s) for use of the HSM, then the method 350 proceeds to step 360 where the HSM 10 configures an initial network state of the HSM (10) for external communication with the set of IP addresses. As seen in FIG 3A, the signed customer configuration file 10a in the secure element 5 includes a set of unique IP addresses (and corresponding authorize location information) specific to each of the multiple HSMs in the protected environment, whereby upon detection of the presence of the secure element 5, each of the multiple HSMs is automatically configured with a respective set of the unique IP addresses and corresponding authorized location information. Once the HSM 10 is set-up with the IP addresses and other information, it is visible on the network and may be accessed through its standard means, for example, over one or more of its Ethernet ports.

[0073] FIG. 4 depicts exemplary components of the Hardware Server Module (HSM) 10. The HSM 10 is a physical computing device that, among other capabilities, safeguards and manages digital keys, performs encryption and decryption functions for digital signatures, and provides for strong authentication and other cryptographic functions. As a security hardened unit, the HSM 10 records tamper evidence, such as visible signs of tampering or logging and alerting, and provides for tamper responsiveness such as deleting keys upon tamper detection. The HSM 10 contains one or more secure cryptoprocessor and sensor chips to prevent tampering and bus probing, or a combination of chips in a module that is protected by the tamper evident, tamper resistant, or tamper responsive packaging.

[0074] The HSM 10 is in effect a computer system comprising one or more processors 51 and memory 52 coupled to the one or more processors, wherein the memory 52 includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations of the methods described herein. The HSM may be connected over the network to other machines via the network communication device interface 53. In a networked deployment, the machine may operate in the capacity of a server or a client user machine in server-client user network environment, or as a peer machine in a peer-to-peer, or distributed, network environment. The HSM 10 further includes a location tracker 9 such as a GNSS tracking device. Other means of location determining can be employed within the embodiments including cell phone tower triangulation or beacons. Further note that the embodiments are not limited to use of any particular GNSS system, but can use any navigation and positioning system including, but not limited to one or more among positioning systems such as GPS (US), Galileo (owned by Europe), BeiDou/BDS (owned by China), GLONASS (owned by Russia), IRNSS/NavIC (owned by India) or QZSS (owned by Japan). Although used of GPS may be illustrated as an example in some embodiments, the contemplated scope of the claims is not limited to such. Some embodiments can even support multiple Navigation systems at once and hence not rely on any single service in the unlikely event of a system crash or denial of service of one service or another.

[0075] Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Applications that may include the apparatus and systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations.

[0076] In accordance with various embodiments of the present disclosure, the methods described herein are intended for operation as software programs running on a computer processor. Furthermore, software implementations can include, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.

[0077] While the machine-readable memory 52 is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "machine- readable medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure.

[0078] HSM types

[0079] A “general purpose” (GP) HSM is a hardened, tamper-resistant hardware device that strengthen encryption practices by generating keys, encrypting and decrypting data, and creating and verifying digital signatures. GP HSMs may be assembled in clusters and act as a single hardware Root of Trust. It is a critical component of public key infrastructures (PKIs) to generate and protect root and certificate authority keys; code signing to ensure software remains secure, unaltered and authentic; and creating digital certificates for credentialing and authenticating proprietary electronic devices for Internet of Things (loT) applications and other network deployments. A General Purpose HSM is flexible and can be used in any application that uses cryptographic keys which does not require the additional security controls and regulations imposed by a Payment HSM. Examples include management of the symmetric keys used for database encryption, and management and use of the asymmetric keys used for the creation of digital signatures and certificates to support PKI (Public Key Infrastructure) and crypto wallets.

[0080] A “payment” HSM is a hardened, tamper-resistant hardware device that is used primarily by the retail finance or banking industry to provide high levels of protection for cryptographic keys and customer PINs used during the issuance of magnetic stripe and EMV chip cards (and their mobile application equivalents) and the subsequent processing of credit and debit card payment transactions. Payment HSMs normally provide native cryptographic support for all the major card scheme payment applications and undergo rigorous independent hardware certification. Payment HSMs and management tools provide flexible, efficient transaction security for retail payment processing environments, internet payment applications, and web-based PIN delivery.

[0081] The main role of a payment HSM is to protect cryptographic keys and other security sensitive data in a highly secure manner, such that the integrity of the overall payment process is maintained, and provide audit and system logs of HSM usage. To that end, HSMs offer the highest level of security by always storing cryptographic keys in intrusionresistant hardware and providing up to date reporting of its operation. Commonly, HSMs are housed in a data center of a computing resource provider or any similar securely hosting area. More specifically, any HSM hosted in the data center may be attached directly to a server, for instance in a rack, and can be accessed on-site by an operator e.g., through console attach to the HSM via a universal serial bus (USB) connection implementing a USB- C interface, for example.

Other Embodiments

[0082] Operational use of the (GP or Payment) HSM 10 for establishing an End to End (E2E) trusted HSM setup using secure device as shown in FIG 3A is primarily by way of the components shown in the figure, but understandably, many more components, electronics, and modules are present in a typical HSM. Those components shown are those mostly related, and suitable for use, for implementing the foregoing inventive methods. Hardware (HW) components 11 represent general electronics for operating the HSM (e.g., processors, central processing units, security, sensors, memory, network devices, ports, power supply units (PSU), wires, keylocks, etc.). The Hardware also contains memory to run operating system and input-output (I/O) devices for interaction. It comprises different types of processors, such as a crypto processor, security processor, general processing unit (GPU), central processing unit (CPU) to assist in protection, management of keys and hardware acceleration with the operating system. The keys, or any other data, can be stored in the database for persistence. The hardware architecture is designed to protect and manage digital keys, and can perform encryption, decryption, digital signature generation and verification.

[0083] In one embodiment, the aforementioned (GP or Payment) HSM 10 functionality and methods for the End to End (E2E) trusted HSM setup using the trusted device 5 is configurable as a micro-service. The customer configuration file is exposed via a microservices API for End to End (E2E) trusted HSM setup using the trusted device.

[0084] Micro-services are independent and lightweight processes designed to perform specific tasks. They are typically handled and managed within the HSM by way of the OS 12. Micro-services 14 can communicate with each other and with external systems over specialized protocols and application programming interface (API) 16. Micro service are built using software libraries/packages 15, which are a self-contained set of independent and interchangeable software component that implement a specific functionality. Micro-services 14 and Processes 13 are built using these software libraries/packages 15. By way of these microservices, applications can implement a third-party Microservice provider’s generic API to a service to deliver Payment HSM capabilities. In this manner, for example, a 3 ^rd party customer by way of APIs can partition their workload to optimized payment HSMs for performing specific tasks (e.g. ECC/RSA key gen, PIN translations, etc.) according to their microservice model. As another example, a micro-service with a customer facing API for an End to End (E2E) trusted HSM setup using the trusted device is contemplated. The API can include options allowing the customer to configure trust anchors and certificate chain management for generating and programming the secure content (e.g. IP addresses for network configuration setup) on their workstations and HSM cluster within the protected environment.

[0085] The Operating System (OS) 12 is a software component that executes on top of hardware, for example, the general processor, to manage hardware resources and peripherals, run HSM jobs/processes, and help in execution of other processes 13. Ubuntu is an exemplary OS that provides an embedded Linux distribution with libraries and packages. Ubuntu (GNU I Linux) is a multitasking Operating System capable of executing several processes (tasks) simultaneously. Different processes 13 for performing the HSM functions (data protection, key management, pin translations, etc.) are scheduled by the operating system 12. A thread is the basic unit to which the operating system allocates processor time. A process 13 is an instance of a computer program that is executed by one or many threads in the GPU or CPU. One or more threads run in the context of the process. A thread can execute any part of the process code, including parts currently being executed by another thread.

[0086] In another embodiment, an API 16 is provided for End to End (E2E) trusted HSM setup using the trusted device 5 when configured as a micro-service. The API can be a RESTful API using HTTP requests to produce and consume data related to network config services via at least one of a GET, PUT, POST, PATCH and DELETE command type. The API includes a command set for each stage of warranting, commissioning, and provisioning the HSM during initial set-up and for life-cycle HSM management, including but not limited to certificate management at each stage.

[0087] The Applications Programming Interface (API) 16 provides a connection between computers or between computer programs/applications, and/or between computers and people. It is a type of software interface, offering a service to other pieces of software. The API provides a communication channel between HSM components, internal processes 13 and/or micro services 14. These APIs are exposed on top of input/output (I/O) 20 interfaces. External systems and/or people communicate with HSM via the I/O interfaces 20, such as a basic user interface (Ul) 21 , or more sophisticated graphical user interface (GUI) 24 The HSM can also communicate with external systems through hardware IO interfaces, such as the keyboard 22, serial port 23, smart card 25, Ethernet 26, optical ports, USB ports, etc. External systems (host computers in a data center) can also talk to HSM software interface via APIs exposed on top of individual hardware interfaces (e.g., network device driver, disk/memory management, etc.).

[0088] The HSM 10 includes a local console 23 that is serial connected over e.g., a USB- C interface. The serial interface can be used by operations personnel, namely operators, referred to as DCOps (standing for Data Center Operations), who have physical access to the HSM for manually issuing commands to the HSM. Such USB-C interface is used, for all configuration throughout the HSM service, including initial configuration and cumbersome provisioning processes. The HSM also includes managerial Graphical User Interface (GUI) 24 that over an Ethernet 26 connection allow for remote configuration of the HSM. Also, the I/O 20 can be used to configure network settings, SSH certificates, upgrades, licenses and devices (e.g. CPU, Disk, memory, etc.). Operator (Java) cards 25 also provide a means for provisioning and securing the HSM using key shares and key splits.

[0089] The HSM also includes services 30 by way of modules, processes and service managers. Some services may be internal to the HSM, and others may be selectively exposed via the API gateway 16 to external entities or services. Examples of services 30 include authentication 31 , authorization 32, session manager 33, enforcement 34, resource API manager 36, and quorum manager 37. Accordingly, service managers can be invoked/managed/configured remotely (external) via their APIs, for example, from a web based GUI (e.g. payShield Manager) via Internet connection over Ethernet to the HSM 10.

[0090] The HSM also includes (internal) resources 40 which can be externally configured via the normal I/O interfaces 20, and also, for some, (internally and externally) via any of the module/service managers 30 and their respective APIs. Examples of HSM resources include, but are not limited to, certificates, licenses, policies, device management, services, upgrades and so on. Each resource 40 has a respective API for software modules, processes or microservices to interact with the respective resource. The HSM offers access and services to each resource 40 via the resources API 36. Aside from payments HSM related tasks (e.g. encryption/decryption, key management, etc.), this includes: certificate/license management, SNMP, SSH, memory management/configuration, network management/configuration, upgrade installations/services, user resources, and so on.

[0091] The architectural style for APIs is typically categorized as either being SOAP (former acronym for “Simple Object Access Protocol”, but referring now to a “Service Oriented Architecture”, SOA for Web services) or REST (Representational State Transfer), and both are used to access Web services. While SOAP relies solely on XML to provide messaging services, REST offers a more lightweight method, using URLs in most cases to receive or send information. REST uses different HTTP 1.1 verbs, also known as access “methods” to perform tasks. These methods are GET, POST, PUT, and DELETE, which refers to the reading, updating, creating and deleting of operations concerning objects or resources, respectively. Unlike SOAP, REST does not have to use XML to provide the response. Some REST-based Web services output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The advantage with REST is that the output needed can be obtained in a form that is easy to parse within the language of the application specifically concerned.

[0092] In the embodiments presented herein, REST offers an alternative to, for instance,

SOAP as method of access to a web service. In order to be used in a REST-based application, a web service needs to meet certain constraints. Such a web service is called RESTful. A RESTful web service is required to provide an application access to its web resources in a textual representation and support reading and modification of them with a stateless protocol and a predefined set of operations. By being RESTful, web services provide interoperability between the computer systems on the internet that provide these services. RESTful APIs embody the rules, routines, commands, and protocols that integrate the individual microservices, so they function as a single application. In a RESTful web service, requests made to a resource's URL will elicit a response with a payload formatted in HTML, XML, JSON, or some other format. The response can confirm that some alteration has been made to the resource state, and the response can provide hypertext links to other related resources. When HTTP is used, the operations (HTTP methods) available can comprise: GET, POST, PUT, DELETE, PATCH, and/or OPTIONS.

[0093] In some embodiments, the HSM device on cloud is equipped with a GNSS tracker as the part of its hardware. The HSM user interface can be modified to implement the use cases of data sovereignty on the cloud using the output of the GNSS tracker, without disclosing the location of HSM and there-by the location of the Data Center where the HSM is housed.

[0094] In some embodiments as illustrated with the system 500 of FIG. 5, such system can include a plurality 504 of HSMs stacked in a datacenter 502 where each HSM 504a-f has its own respective GNSS tracker 505 such as a GPS tracker. A plurality of users 508 can communicate with and access the HSMs 504 via the cloud or Internet 506 as shown. In some embodiments, a system 600 can include just a single HSM 602 having a location or GNSS tracker 604 where a user 608 interacts with the HSM 602 in a secured and authenticated manner to make it functional only for a specific geographical location. Again, as noted above, the embodiments are not limited to use of a particular GNSS tracker or even use of a single particular GNSS tracker. Any combination of navigation and position system can be used including any number of the known GNSS tracker systems (e.g., GPS, Galileo, BeiDou, GLONASS, IRNSS, and/or QZSS, etc.). In some embodiments, using a GNSS system using a multi-frequency position system can help protect HSMs from GPS spoofing attacks.

[0095] In a first use case, a user can request processing on the basis of geolocation. The user of the HSM (which is hosted on a cloud) will be able to see an option on a user interface to input the location where the HSM should be to be functional and allowed to process the data. For example, the user can enter a country or list of countries or a region where there may be a data residency requirement for processing such data (see GDPR) or where there maybe data export restrictions and the data must be processed in a home or domestic country.

[0096] The HSM then compares the data of the GNSS attached to it, with the input of the user as noted above. If the HSM determines that GNSS data and user input data for location are the same, then the HSM processes the requests, otherwise it rejects them.

[0097] Alternatively, a user interface could also provide for an input entering countries or restricted countries where data must not be processed. In this scenario, if the HSM GNSS data is part of the inputted restricted countries list, then the HSM rejects the request and otherwise it will process the request.

[0098] In another example or use case, as shown in the system 900 of FIG. 9 and system 1000 of FIG. 10, if a user of hosted-HSM wants their HSM to be physically located in the US only then, the user enters the US as the expected or designated location of the HSM via a user interface of the HSM. If the HSM 902 is actually located in US as determined by a GNSS tracker 904 embedded at the HSM 902, then it will allow the processing of requests as shown in FIG. 9. Otherwise, it will reject the requests as illustrated by the system 1000 where the HSM 1002 is located outside the designated country as determined by the GNSS tracker 1004. See also system 500 of FIG. 5 and system 600 of FIG. 6.

[0099] In another use case, key usage is restricted to support residency laws. The user of the HSM can generate a key that supports residency laws by containing the information of the location where it can be used. See the system 700 with HSM 702 and embedded GNSS 704 (such as GPS) in FIG. 7 where a request is made to generate a key that can only be used in a home country (US), Canada and the UK and the HSM correspondingly generates the key that is made in the US and cannot be used outside of the US, Canada and the UK. In FIG. 8, a request is made of the HSM 802 in system 800 to import the key (that has country restrictions) generated in the system 700 of FIG. 7. The GNSS 804 embedded in the HSM 802 determines that the HSM 802 is in Russia or not one of the allowed countries specified by the key generated in system 700. Accordingly, the system 800 with HSM 802 and embedded GNSS 804 rejects the request and issues an error response since the HSM does not allow the key (generated in the US) to be imported anywhere other than the UK and Canada.

[00100] In yet another example, a key can be generated that contains the information that it can only be used in the US and India. If any Cloud HSM in any other territory tries to process this key, then the respective HSM with GNSS tracker would deny the key usage via the mechanism defined noted above. See again, the system 700 with HSM 702 and embedded GNSS 704 in FIG. 7 and system 800 with HSM 802 and embedded GNSS 804 in FIG. 8

[00101] In yet another example, a system can bind a key with a particular geolocation at the time of key generation. This can further ensure that the key cannot be used at any location other than the bound location.

[00102] In yet another example, a user can generate a key on an HSM located in US. The HSM generates the key containing the trusted meta data of location. If any Cloud HSM in any other territory tries to process this key as illustrated by step 1102 and 1103 of method 1100 of FIG. 11 , then the HSM obtains or receives the Authorized Location Information at 1103 and with GNSS tracker determines the HSM location at step 1104, compares the HSM location with the trusted meta data of location of the key at decision block 1106 and would deny the request at 1108 if the HSM location is not in an authorized location as determined from the key meta data. At step 1110, the key import request would be processed if the HSM location is in an authorized location as determined by comparison (1106) to the key meta data.

[00103] In some embodiments as illustrated by a number of figures including FIG.6, a system 600 supportive of data residency requirements includes a Hardware Security Module 602 (HSM) hosted on a cloud environment and a location tracker 604 embedded within or directly connected to the HSM to provide an HSM location, the HSM including one or more processors and memory coupled to the one or more processors, where the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations. The operations can include receiving a request for access to information over a network (such as step 1102 in method 1100 of FIG. 11), obtaining authorized location information where the HSM is authorized to process the request from a source (where the source can be inputted by a user, embedded in a secure element (see secure element 5 in FIG. 2A), embedded in a signed configuration file (see configuration file 10a in FIG. 3A) or embedded in a key) of the request for access, comparing the HSM location with the authorized location information from the source (as in decision block 1106), processing the request(at step 1110) for access if the HSM location is within the authorized location information and rejecting (at step 1108) the request if the HSM location is not within the authorized location information.

[00104] In some embodiments, the location tracker embedded within or directly connected to the HSM is a global navigation satellite system (GNSS) module.

[00105] In some embodiments, the system further includes computer instructions which causes the one or more processors to obtain the authorized location by generating a user interface in response to the receipt of the request which provides an option for a manual input of a location or locations where the HSM is authorized to process the request as the authorized location information.

[00106] In some embodiments, the system further includes computer instructions which causes the one or more processors to obtain authorized location information by receiving a key from the source, wherein the key contains the authorized location information from the source.

[00107] In some embodiments, the system further includes computer instructions, which causes the one or more processors to maintain the HSM location hidden from users.

[00108] In some embodiments as illustrated by FIG. 7, a system 700 further includes computer instructions, which causes the one or more processors to receive a request at the HSM 702 to generate a key that can only be used by HSMs in predetermined locations and responding with the transmission of a key that cannot be used with HSMs outside the predetermined locations.

[00109] In some embodiments as illustrated again by FIG. 7, the system 700 further includes computer instructions, which causes the one or more processors to receive a request to generate a key that can only be used in predetermined countries and responding with the transmission of a key that cannot be used outside the predetermined countries.

[00110] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to generate a key and responding with the transmission of a key that cannot be used outside the country of the HSM location as illustrated by an HSM 802 having GNSS tracker 804 in system 800 of FIG. 8.

[00111] In some embodiments, the system further includes computer instructions, which causes the one or more processors to receive a request to process a key containing meta data of the location information where the HSM is authorized and processing the key if the HSM location is within the meta data of the location information where the HSM is authorized. [00112] In some embodiments as illustrated by the flow chart 250 of FIG. 2B, the system further includes computer instructions, which causes the one or more processors to securely configure the HSM using a computer or mobile device within a protected environment for programming a secure element by detecting (at 252) a presence of the secure element in a vicinity of the HSM, authenticating (at 254) the secure element as a trusted device to the HSM by way of the certificate stored thereon, authenticating (at 256) a user of the secure element to the HSM (to establish a secure communication for programming the secure element at 258), retrieving (at 260) a set of IP addresses and authorized location information in the secure element associated with an HSM network configuration responsive to authenticating the secure element and authenticating the user, and configuring (at step 262) the secure element with an initial network state of the HSM for external communication with the set of IP addresses for authorized locations, where the external communication proceeds with an IP address if the HSM location is within the authorized location information associated with the IP address of the set of set of IP addresses. [00113] In some embodiments, the security element 5 as shown in FIG. 2A is one of: (a) embedded in a smart card having stored thereon a certificate for establishing the smart card as a trusted device, and the presence of the secure element is detected when the smart card is inserted; (b) embedded in a LISBC e-Token having stored thereon a certificate for establishing the LISBC e-Token as a trusted device, and the presence of the secure element is detected when the LISBC e-Token is inserted; or (c) embedded in a Near Field Communication (NFC) chip of a mobile device having stored thereon a certificate for establishing the NFC chip as a trusted device, and the presence of the secure element is detected when the NFC chip is in close proximity to the computer or mobile device.

[00114] In some embodiments as shown in FIG. 5, a system 500 supportive of data residency requirements can include a plurality 504 of Hardware Security Modules (HSMs) (504a-f) hosted on a cloud environment 506 and a location tracker 505 embedded within or directly connected to the plurality of HSMs in a protected environment to provide an HSM location, the plurality of HSMs. Note that in some embodiments, a location tracker 505 is embedded in each HSM of the plurality of HSMs. In other embodiments, at least one location tracker 505 is included among the plurality of HSMs. The plurality of HSMs can include one or more processors and memory coupled to the one or more processors, where the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform certain operations. The operations can include some of the method previously described such as receiving a request for access to information over a network at one of the HSMs among the plurality of HSMs, obtaining authorized location information where the HSM is authorized to process the request from a source of the request for access, comparing the HSM location with the authorized location information from the source, processing the request for access if the HSM location is within the authorized location information, and rejecting the request if the HSM location is not within the authorized location information.

[00115] In some embodiments, the method includes the steps of receiving a request for access to information over a network, obtaining or receiving authorized location information where the HSM is authorized to process the request from a source of the request for access, comparing the HSM location with the authorized location information from the source, and processing the request for access only if the HSM location is within the authorized location information.

[00116] In some embodiments, the method further includes the step of rejecting the request if the HSM location is not within the authorized location information.

[00117] In some embodiments, the method further obtains the authorized location by generating a user interface in response to the receipt of the request that provides an option for a manual input of a location or locations where the HSM is authorized to process the request as the authorized location information.

[00118] In some embodiments, the method further obtains the authorized location information by receiving a key from the source, wherein the key contains the authorized location information from the source.

[00119] In some embodiments, the method further receives a request to generate a key that can only be used by HSMs in predetermined locations or countries and responding with the transmission of a key that cannot be used with HSMs outside the predetermined locations or countries.

[00120] In some embodiments, the method further receives a request to generate a key and responding with the transmission of a key that cannot be used outside the country of the HSM location.

[00121] In some embodiments as illustrated by the system 300 of FIG. 3A, the HSM 10 in a secure configuring mode by a computer or mobile device 3 (see FIG. 2A) in the presence of a secure element 5 performs one of detecting insertion of a smart card embedded with the secure element, detecting insertion of a LISBC eToken embedded with the secure element, or detecting a near-field communication chip embedded with the secure element, where a step of authenticating a user of the secure element includes entry of a personal identification number (PIN) or multi-factor authentication (MFA) 8.

[00122] In some embodiments, a customer configuration file 10a (as shown FIG. 3A) in the secure element 5 includes a set of unique IP addresses and authorized locations specific to each HSM in a configuration of multiple HSMs in a protected environment, whereby upon detection of the presence of the secure element 5, each of the multiple HSMs is automatically configured with a respective set of the unique IP addresses and authorized locations.

[00123] The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. [00124] Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.