Distributed quorum authorization enforcement through an API gateway

In one embodiment a Hardware Server Module (HSM) (10) implementing a distributed quorum authentication enforcement is provided, whereby user access to a resource (40) on the device (10) is enforced via an API gateway (16). The HSM comprises one or more resources, a separate resource manager API for accessing the one or more resources, an enforcement module for enforcing access to the one or more resources via the API gateway according to a quorum policy, and a quorum manager for generating and storing a quorum request in a database. The API gateway (16) can be a RESTful API using HTTP requests to produce and consume data related to quorum services via at least one of a GET, PUT, POST, PATCH and DELETE command type. Other embodiments are disclosed.

TECHNICAL FIELD

The present invention relates generally to management and configuration of network devices, and more particularly, to Application Programming Interfaces (API) related to authorization services for configuring a Hardware Security Module (HSM) cryptographic unit.

BACKGROUND

A Hardware Security Module (HSM) is a dedicated crypto processing unit that is specifically designed for the hardware protection of the crypto key lifecycle. Hardware security modules act as trust anchors that protect the cryptographic 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.

HSM protect encryption 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. Authentication is the process of verifying a user's identity and their ability to access a requested account on the HSM. Authorization establishes which permissions the user has within the HSM.

In HSM products quorum (m-of-n) authorization is generally tied with the authentication session requiring all the authorized user parties to be available at same location to authenticate in same session before any operations requiring quorum can be performed. This form of HSM management is usually done through a user interface (UI) or console. PCI-HSM mandates any sensitive configuration change must be approved by at least two administrators. One limitation to this approach is that all users must be present at same location; thus, it cannot be performed in a distributed manner. Secondly, it does not provide for maintaining a state within an established session. Moreover, there is a need to provide a distributed solution that is more manageable that the current approach.

Shared Secret schemes such as the one proposed by Shamir A., (“How to Share a Secret,” Programming Techniques, Communication of the ACM, vol. 22, No. 11, November 1979) have been proposed as a solution for resolving the distributed key management problem. Such a scheme is used to distribute the secret to individual authorized users to provide the information to complete the secret and which can then be used for performing operations using that secret. The mathematical construct has been designed in such a way that it needs all the shares to be present for reconstructing the secret. This has been traditionally used by HSM's (Hardware Security Module) and other systems sharing secrets. With the progress of time, additional mandatory procedures (authorization and/or authentication of shareholders) were introduced for each shareholder (holder of a share/fragment) of the secret. But all these procedures required the presence of each shareholder at the location where the secret was to be punched in.

However, the shared secret key approach presents at least two risks: 1) there is no control of the shareholders once they have entered the secret and other shareholder going in to enter its own part of the secret. This leads to a scenario where the last shareholder of the share of the secret has access to the entire system and can engage the systems and resources without oversight at least for a time which become aware of only afterwards, and 2) there is no control over specific resources, and this may lead to complete unintentional or intentional sabotage of the system or another layer of secrets for each resource which would require additional shareholders and the presence of all these shareholders to the premise requiring one operational change to lead to a downtime or waste of resources for even the miniscule operations.

The combination of cloud based systems with security managed HSMs presents a complex issue from a cloud deployment perspective; namely, both must be managed and accessed securely, and each requires its own secure operational controls. Moreover, the HSMs are meant to manage the security and encryption throughout the network, including the cloud deployment and management control itself. Addressing this problem requires solving two inefficiencies in the earlier on-premise solution as well as stricter control over every configurational aspect. The two inefficiencies are: 1) remotely working in coherence with access only to a shared secret for any operational requirement, and 2) control over every resource defined by the system as operational configuration by every shareholder. Additionally, in earlier shared secret attempts, there was no scope for enforcing the order or constraints over some resource as well as allowing partial operations using authorization from only a subset of users.

A need therefore exists in a cloud based environment for overcoming these inefficiencies and improving the process by which HSM configurations are managed.

SUMMARY

In a first embodiment, a computer implemented method for distributed quorum authentication enforcement of a device through an API gateway. When a user attempts to access or configure a resource offered by the device, an inquiry will be made to assess whether a quorum is required to access or configure it. A quorum request is issued to configure the resource through the API gateway. Access to the resource is enforced onto the user via the API gateway based on a status of the quorum request.

In a second embodiment a Hardware Server Module (HSM) implementing a distributed quorum authentication enforcement is provided, whereby access to the resource is enforced by the HSM onto the user via the API gateway. The HSM comprises at least one or more resources, a resource manager API for accessing the one or more resources, an enforcement module for enforcing access to the one or more resources via the API gateway according to a quorum policy, and a quorum manager for generating and storing a quorum request in a database.

In a quorum creation event stage, the quorum request is created when an operation (use, modify, view, etc.) on the resource is attempted that requires quorum authorization. A quorum policy establishes if a quorum is required to access the resource. The quorum request is generated in accordance with the quorum policy and stored in a database, thereby attaching the quorum request to the resource. A quorum identifier (ID) is generated to associate to the resource, and is included in the quorum requst. Responsive to the creating of the quorum request, administrators are each informed and required to each provide an approval status for the quorum request via the API gateway, which will grant the user privileges to access the resource.

In a quorum data retrievel event stage any other user who has access to quorum request can get information about the quorum request by requesting it from HSM via the API gateway. If includes checking whether the user or an administrator is allowed to access the quorum id, and f so, associating the quorum id with the quorum request. Details of the quorum request are then provided to the use or administrator via the API.

In a quorum approval event stage, responsive to receiving the approval status from the administrators via the API, administrators are validated to ensure they are authorized to approve the quorum request. If validated, a voting count on the quorum request is updated in the database. The user is then informed via the API gateway the approval status. Access to the resource is enforced in accordance with both the quorum policy and updated quorum request. In its basic form, the quorum request includes the quorum ID, an approval threshold, a voting count, a quorum expiry, and an approval status. It may include other information related to the object and the quorum process.

In a quorum application event stage, a check is made to determine whether the administrator identified in the quorum request is allowed to access the quorum id. If so, the quorum id is associated with the quorum request, and details about the quorum request are retrieved. If an approval threshold is met in view of the voting count, and occurred within a quorum expiry period, the approval status is updated to indicate quorum is approved for the resource. The approval status is committed to the database for the quorum request.

Specific embodiments in this invention 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

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 (IaaS) models.

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 “provisioning” of a HSM refers to the process/procedure of managing the allocation of the hosted HSM allocation to a particular end-user. The “commissioning” is the process of changing from using the pre-placed HSM manufacturer's trust to the customer's trust by the end-user. The “warranting” is the process of establishing manufacturer's trust in the HSM (installed in the factory). 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 end-user of the hosted HSM's payment services.

The acronym “IP” designates any protocol of the Internet protocol suite for operation of network applications, such as, for instance:in the Application layer of the OSI model: the Hypertext Transfer Protocol (HTTP) or its secure version HTTPS, DHCP, SMTP, TLS/SSL, etc.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;in the Internet (Network) layer: Internet Protocol (IPv4 or IPv6), ICMP, IGMP, etc.

The term “Microservices” encompasses a software architectural design and approach for building a distributed application using containers. Microservices is a specialization of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. [5] The microservices approach is a first realization of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems. Whereas, microservice is an approach to building an application that breaks its functionality into modular components, APIs are part of an application that communicates with other applications.

An “Application Programming Interface” (API) is a program that allows two systems to communicate with one another. An API essentially provides the language and contract for how two systems interact. APIs work using ‘requests’ and ‘responses.’ When an API requests information from a web application or web server, it will receive a response. The place that APIs send requests and where the resource lives, is called an endpoint. An endpoint is one end of a communication channel. When an API interacts with another system, the touchpoints of this communication are considered endpoints. For APIs, an endpoint can include a URL of a server or service. Each endpoint is the location from which APIs can access the resources they need to carry out their function.

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 HSM10, for example, a system administrator having their own password and a separate device card (e.g. 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.

FIG.1depicts exemplary components of a Hardware Server Module (HSM)10. The HSM10is 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. It may exist in the form of a PCI plug-in card or an external hardware rack unit that attaches directly to a computer or network server within a data center. As a security hardened unit, the HSM10records 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 HSM10contains 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.

Briefly, 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.

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 intrusion-resistant 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.

Operational use of the HSM10is 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) components11represent 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.

The Operating System (OS)12is 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 processes13. Ubuntu is an exemplary OS that provides an embedded Linux distribution with libraries and packages. Ubuntu (GNU/Linux) is a multitasking Operating System capable of executing several processes (tasks) simultaneously. Different processes13for performing the HSM functions (data protection, key management, pin translations, etc.) are scheduled by the operating system12. A thread is the basic unit to which the operating system allocates processor time. A process13is 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.

Certain HSM functionality and capabilities are configured as micro-services. 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 OS12. Micro-services14can communicate with each other and with external systems over specialized protocols and application programming interface (API)16. Micro service are built using software libraries/packages15, which are a self-contained set of independent and interchangeable software component that implement a specific functionality. Micro-services14and Processes13are built using these software libraries/packages15. 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 3rdparty 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.

The Applications Programming Interface (API) gatewat16provides 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 processes13and/or micro services14. These APIs are exposed on top of input/output (I/O)20interfaces. External systems and/or people communicate with HSM via the I/O interfaces such as user interface (UI)21. The HSM can also communicate with external systems through hardware10interfaces, such as the keyboard22, serial port23, Ethernet, 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.).

The HSM10includes a local console23that 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, according to the standing state of the art, for all configuration throughout the HSM service, including initial configuration and cumbersome provisioning processes. The HSM also includes managerial Graphical User Interface (GUI)24that over an Ethernet26connection allow for remote configuration of the HSM. Also, the I/O20can be used to configure network settings, SSH certificates, upgrades, licenses and devices (e.g. CPU, Disk, memory, etc.). Operator (Java) cards25also provide a means for provisioning and securing the HSM using key shares and key splits.

The HSM also includes services30by way of modules, processes and service managers. Some services may be internal to the HSM, and others may be selectively exposed via the API gateway16to external entities or services. Examples of services30include authentication31, authorization32, session manager33, enforcement34, resource API manager36, and quorum manager37. 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 HSM10.

The HSM also includes (internal) resources40which can be externally configured via the normal I/O interfaces20, and also, for some, (internally and externally) via any of the module/service managers30and their respective APIs. Examples of HSM resources include, but are not limited to, certificates, licenses, policies, device management, services, upgrades and so on. Each resource40has a respective API for software modules, processes or microservices to interact with the respective resource. The HSM offers access and services to each resource40via the resources API36. 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.

Each resource40may be associated with a quorum policy51that defines how a resource object may be accessed, configured, updated, viewed and so on. For example, a network driver object is a resource that may have an attached quorum policy stating what users, or user roles, or other services can adjust or view the network settings (and which settings, and the extend of the setting changes and parameters) on the HSM. Whenever a user desires to configure a resource, the quorum policy51is inquired to determine access rights/permissions (e.g. view, change, delete, new, etc.). Each object/resource may also have a corresponding quorum request52to provide indication of a status of a configuration request change, for instance, allowing a user to modify a resource object. The request includes data about the object and quorum policy. For example, in the network device example, the quorum policy may state that three (3) authorized administrators are required for a configuration change request, with a threshold of 2 administrators giving approval. The quorum request52can provide a description of the policy, the related attributes, who is authorized, the reasons, resource expiration dates, the date/time, and so on. A quorum ID is associated with each resource for the quorum manager37to inquire as to the state/status of the quorum request52and any attached quorum policy51.

FIG.1Bdepicts an exemplary communication environment100for configuring an HSM10via quorum authorization services60in accordance with one embodiment. The quorum authorization services60via API can serve to configure other devices in the communication environment aside from only an HSM. The HSM10is configurable remotely via the API providing quorum authorization services60. In another embodiment, the HSM may also reside in a networked data center80for providing cloud HSM services. For example, a 3rdparty service70requests configuration controls to the HSM10, for instance, to configure it for client data protection and encryption services. Separately, three or more administrative users, by way of their communication device (e.g.,103,102), can then authorize the request for configuration of the HSM10for that party70via the quorum services API60. Responsive to receiving the quorum request from the 3rdparty service70, each administrative user can individually authorize, by way of their communication device103, the necessary authorization to allow that party70to remotely configure the HSM10. In practice, software on the user's communication implements the quorum services API60, which then, by way of the method300discussed ahead, authorizes the HSM10for configuration by the 3rdparty service70requestor.

Notably, the 3rdparty service provider70is not limited to functioning only as a cloud HSM service offering. It can represent any one, or multiple service offerings, for example, services for: authentication, authorization, attestation, attribute provisioning, credentials, certificate authority, trust, and cryptography. Accordingly, the quorum authorization service60via API can be used to authorize any 3rdparty services for the aforementioned services, for example, to enhance the trust in their private attestations, or others related to the HSM, for example, remotely authorizing one or more microservices via APIs on the HSM, and so on.

In a conventional remotely hosted payment infrastructure, one or more payment HSMs may be deployed in the data center80. The HSMs are used for real time authorization and authentication in critical infrastructure, and thus are typically engineered to support standard high availability models including clustering, automated failover, and redundant field-replaceable components. Each HSM may be allocated to end-user clients by a current process performed manually by an operator, on-site. Stated otherwise, an on-site manual access to the HSM server allows provisioning the hosted HSM to specific end-user client(s) during the deployment lifecycle of a payment system. Subsequently, and over the entire system's lifetime, end-user's payment applications may remotely access resources in the HSM using a conventionally known secure system's client/server architecture. Such remote access also allows for highly flexible HSM management by end-users via a secure management interface, for configuration of the HSM during the operation lifecycle, which meet the requirements of complex network infrastructures and demanding business environments. This supports multiple types of payment service offerings and offers more capabilities to run functions securely in a broader range of operating environments.

The communication environment100can include a telecommunication network113and an internet communication network (Internet)120. The telecommunication network113can provide a mobile communication link via base receiver110for wireless connectivity of a mobile device102from one or more cells107. In one arrangement, the mobile device102can communicate over a Radio Frequency (RF) link with the base receiver110using a standard communication protocol such as legacy 2G (CDMA, GSM) and 3G, or LTE 4G and 5G. The base receiver110, in turn, can connect the mobile device102to the Internet120over a packet switched link. The internet can support application services and application service layers150for providing media or content to the mobile device102. By way of the communication environment100, the mobile device102can establish connections with a server/service130on the network and with other mobile devices for exchanging information or providing services such as audio, text messaging, media, audio, video, interactive applications, and the like. The server130can have access to a database that is stored locally or remotely and which can contain profile data. The server can also host application services directly, or over the Internet120.

The mobile device102can also connect to the Internet over a Wi-Fi or WLAN 105. Wireless Local Access Networks (WLANs) provide wireless access to the mobile communication environment within a local geographical area. WLANs can also complement loading on a cellular system, so as to increase capacity. Wi-Fi is the wireless technology used to connect computers, tablets, smartphones and other devices to the internet. Wi-Fi is the radio signal sent from a wireless router to a nearby device, which translates the signal into data for the user of the mobile device102. Wi-Fi is a family of wireless network protocols, based on the IEEE 802.11 family of standards, which are commonly used for local area networking of devices. WLANs are typically composed of a cluster of Access Points (APs)104also known as base stations. The mobile communication device102can communicate with other WLAN stations such as a laptop103within the base station area105. In typical WLAN implementations, the physical layer uses a variety of technologies such as IEEE 802.11 technologies. The physical layer may use infrared, frequency hopping spread spectrum in the 2.4 GHz or 5 GHz Band, or sequence spread spectrum. The mobile device102can send and receive data to the server130or other remote servers on the mobile communication environment. In one example, the mobile device102can send and receive audio, video, or other multimedia content from the database through the server130.

FIG.2depicts a quorum authorization (or m-of-n) sequence200on HSM as it currently exists. Notably, there are three separate interaction events: Authentication of first user event (210), Authentication of second user event (220), and the actual configuration event change (230) for the HSM. In order to make any modifications on the HSM (aka, configuration event change, for example, to change access policies or adjust network settings) multiple users need to first authorize that change. Here we see that two users named Alice and Bob each have to separately authorize a change on HSM, and do so in a sequential order

Both Alice and Bob connect to HSM10using a user interface21rendered through a process running on HSM. Before authorization, the problem is that both users must physically meet at a same location so that they can access UI using the same computer for performing configuration setup steps201-204. That is, their physical attendance in front of the HSM is required to connect and enter their credentials (e.g. password, java cards), and in a specific order. Both will communicate to HSM10through UI21to input their credentials for authentication. The UI21maintains a session with the connection, which is managed by session manager33running on the HSM10. Session manager33can close the session in case of errors or timeouts. User credentials are verified by Authentication module31. For instance, once Alice and Bob have each logged into the HSM, inserted their JavaCards and entered their card passwords, the HSM will establish the session.

In the first user authentication event210, at step201, one of the users (in this example, Alice) begins the first formal interaction with the HSM for making a connection request for configuration changes. The UI21process connects to session manager33to create a session for this connection request shown as step202. Session manager generates a random session ID and returns it back to UI in step203. Since none of the users are currently authenticated this session is considered un-authenticated. Session ID returned from session manager33is tied with connection opened by Alice.

Alice starts the authentication sequence through UI21by sending authentication request in step211over the same session. UI21checks with session manager33if session is still valid or not at step212. Session manager33responds with a session still valid response at step213. UI21forwards the Authentication request to authentication module31in step214. Authentication module31initiates a challenge-response authentication sequence to authenticate Alice in step215by sending a challenge to Alice. Alice generates a response to that challenge in step216and responds in step217. Authentication module31validates the response218and returns authentication success in219. Session manager33updates session information to mark the session as authenticated for user Alice220and returns in step221. Once Alice has authenticated, Bob may begin his authentication sequence over the same session at step231.

In the second user authentication event220, at step231, that user (Bob) requests a configuration change. The UI21checks with session manager33if the session initiated by the first user (Alice) is still valid or not at step232. If so, session manager33responds with a session still valid response at step233. UI21forwards the second user's Authentication request to authentication module31in step234. Similarly, as was done with Alice, the Authentication module31initiates a challenge-response authentication sequence to authenticate Bob in step235by sending a separate challenge to Bob. Bob generates a response to that challenge in step236and responds in step237. Authentication module31validates the response238and returns authentication success in239. Session manager33updates session information to mark session as authenticate for user Bob at step240and returns in step241.

Once both the users have successfully authenticated over the same session, the HSM10permits them to make configuration changes. This is seen in the event change “Update Payshield”230, where Payshield is an exemplary product name of the HSM. In this state, Alice and Bob can then start a configuration change process, for example, to update the HSM configuration settings, depicted by steps251-258. Accordingly, at step251, configuration changes are sent through UI21to the HSM10, which it then processes to reconfigure itself in accordance with their changes. UI21checks with the session manager33to confirm the session is still valid at step252. Session manager33responds with a session still valid response at step253. Their configuration changes request is then sent to the enforcement module at step34.

This enforcement module34verifies the changes and validates if the users have authenticated on the same session, and ensures these users (Alice and Bob) are authorized to make requested changes in step255. Any configuration changes are passed to enforcement module34which validates that both users have authenticated on the same session and that they have permission to make requested changes. Enforcement module34returns a result of that verification and validation activity at step256. If result is true, UI commits changes to database17at step257and returns a success response to Alice and Bob at step258. That is, if Alice and Bob are authorized to make changes, changes are committed to configuration database17. Any departure from these specific events will not result in a successful authentication or a configuration change (e.g. update configuration settings of the HSM10).

FIGS.3A and3Bare consecutive sequence diagrams that provide an alternate method300of quorum authorization whereby users can configure a secure device remotely. Advantageously, it is not limited to the sequential order as required inFIG.2, and does not require that the users be present together to make configuration changes to HSM10. It also overcomes the inefficiencies of the quorum authorization (or m-of-n) sequence200described inFIG.2; namely, 1) remotely working in coherence with access only to a shared secret for any operational requirement, and 2) control over every resource defined by the system as operational configuration by every shareholder

In a preferred embodiment, the method300is implemented within the HSM10, but in practice, can operate on any other secure device configured for authentication and authorization needing simultaneous approval from multiple operators. Moreover, the modules by which the method300is implemented can be practiced from those within the HSM10(e.g. SW15, microservices14inFIG.1A), or service modules external to the HSM (e.g., other microservices provide via 3rdparty service provider70inFIG.1B). The method300is implemented in part, by way of the quorum authorization API400shown inFIG.4, described ahead. That is, some of the processes13, microservices14, and SW15inFIG.1, either implement or call the components of API400discussed ahead.

Briefly, there are four (4) main event categories for the method300shown inFIGS.3A-3B: Quorum creation (310), Quorum Data retrieval (320), Quorum Approval (330) and Quorum Application (340). Each of these is discussed in detail next. As a preliminary step, it should be noted that in this example, the two users Alice and Bob have already been authorized to make changes to a resource on the HSM, for instance, which can be configured by HSM administrator through quorum policies. Here, the HSM10can be configured to require a certain number “m” of users to approve changes on a resource.

It should also be noted that resources inside the HSM10are accessible, individually, or via the combination of API gateway16and Resources API36. To that point, each resource40(seeFIG.1A) has its own API specific to the use and configuration of that resource. For example, a network resource has its own network API, for instance, to configure capabilities of network drivers. As another example, a webserver resource may have its own webserver API to configure service capabilities, such as IP addresses, IP ranges, and so on. To keep track of the various resource APIs, the Resource Manager API36(seeFIG.1A) is provided for managing these individual API's at a higher level. In this manner, a service, by way of the Resource Manager API36can inquire as to capabilities, use and availability of the resources.

Understandably, when it is necessary to however access or use a resource on the HSM10via API gateway16, certain policies thereon may dictate what users can or cannot do with the resources40. In the cases where a quorum policy51requires a quorum approval for accessing/using a resource the quorum management module37is involved. The Quorum management module37maintains list of all pending, approved and expired quorum requests. In conjunction with this module, the Enforcement34module is responsible for enforcing quorum policies configured on the HSM10before any change is committed to database17.

The Quorum creation (310) event is represented by steps311-325, which together demonstrate creation of a new quorum request52. A new quorum request52is automatically created whenever a user tries to perform an operation on a resource on the HSM that requires approval from multiple users/administrators. Quorum request52is identified inside the HSM by a unique quorum identifier (id). The quorum request52stores information about a current state of quorum request52, for example, an expiration time, a required approval, received approvals and other information. In the present example, at step311, Bob requests configuration change on a resource by invoking HSM API gateway16along with an access token received after authentication. In practice, a POST resource access token can be sent. API gateway16sends access token (Get User) to Quorum management module37to validate the user is authentic and exists in the system (e.g. as a data center HSM customer, an HSM user, or administrator) in step312. Quorum management module37validates the user and sends the user identity (Bob) to API gateway16in step313. API gateway16checks internal rules (e.g. post resource access token; quorum policy) to determine to which resource manager API36micro-service to send the request in step314and invokes appropriate resource manager API36with name of user. Resource manager API36also consults enforcement module34to determine if Bob is authorized to perform requested operation, at step316.

Enforcement module34reads an internal authorization policy from database17. Enforcement module34determines from the quorum policy51whether the operation on the resource by the user requires a quorum before the configuration change is committed at step318. Resource manager API36prepares a quorum request52after step319and then sends request to Quorum management module37to generate a quorum for the request along with all required data, at step320. Quorum management module37then creates a quorum identifier (id)53for the request at step321and stores the data associated with the quorum request52(quorum request data) in the database17at step322. Quorum management module37returns the generated quorum identifier53to resource manager API36at step323. Resource manager API36returns the quorum identifier53to Bob through API gateway as steps324-325.

The Quorum Data Retrieval (330) event stage is represented by steps331-337. Here, any other user who has access to the quorum request can get information about the quorum request by requesting it from the HSM. For instance, at step331, Alice can now invoke HSM APIs to get details (see GET/quorum-id; see API400FIG.4) of the generated quorum request by sending quorum identifier53via the API gateway16. At step332, the API gateway16checks with Quorum management module37to determine if Alice is allowed to access quorum id53. Quorum management module37validates Alice and returns response at step333. API gateway16then forwards the quorum request52to Quorum management module to retrieve details of quorum at step334. Quorum management module37reads quorum information from database17at step335and returns a response back to API gateway at step336, which in turn sends response back to Alice at step337. After looking at quorum details, Alice can choose to approve or reject quorum request in the next event stage.

The Quorum Approval (340) event stage is represented by steps341-352. Briefly, the user can votes to approve or deny a quorum request52, but only if they are authorized. Here, in this example, steps341-352demonstrate quorum approval sequence by Alice. At step341, Alice sends API request to HSM to approve the quorum with quorum identifier53to approve and authorize the token. API gateway16forwards the request to quorum management module37to determine if Alice is allowed to invoke resource API36at step342. Quorum management module37responds with yes at step343if Alice is authorized. Otherwise, the response is a no if she is not authorized. API gateway16then forwards the request to quorum management module37at step344.

Quorum management module37reads details of the quorum request52from database17at step345. Quorum management module37then consults enforcement module34if Alice has permissions/authorization to approve the request at step346. Enforcement module34reads the authorization for the quorum policy51from database at step347and responds back to quorum management module at step348. If Alice is authorized, the Quorum management module37increases an approval count of the quorum request52by one, at step349and stores this new data and information entry in database17at step350. Quorum management module37responds back to Alice through API gateway16at steps351-352to confirm/deny her approval. Once required approval has been received, one of the approvers can invoke resources API36to apply changes to the resource on the HSM.

The Quorum Application (340) event is represented by steps361-374, which depicts the sequence when an approver initiates commitment of changes. Here, once the required number of approvals has been received as indicated in a quorum policy51, the configuration change can be committed to the database17. Changes can be committed automatically once required approvals are received or request can be initiated by one of the approvers. Notably, Authentication is considered independent from authorization process. It is assumed that users have already authenticated and received an authorization (Access) token which acts as proof of authentication and identity of user.

At step361, Alice invokes API Gateway16to apply an approved change on HSM10at step361. The API gateway16consults with quorum management module37if Alice may invoke the API gateway16at step362. Quorum management module37reads policy data from database17at step363and responds to API gateway16at step364. The API gateway16, at step365, invokes actual resource management API36that had created the original quorum request52. Resource manager API36then sends the request to Enforcement module34to determine if Alice is allowed to apply quorum operation at step366. The Enforcement module34reads policy data from database16at step367, checks if Alice can approve changes at step368, and then responds to resource manager API36at step369. If Alice is allowed to apply the configuration changes to the resource/object, resource management API36reads quorum details (e.g., object/resource info, date, time, details, list of authorized quorum participants, quorum threshold, type of quorum policy, etc.) of the requested change from Quorum management module37at step370. Resource manager API36checks if a required vote (threshold) has been received at step371, and, it commits the request to database17at step372. Resource manager API36then returns status (success/failure) to user through API gateway16as seen in steps373-374.

FIG.4depicts an exemplary quorum authorization API400. In a preferred embodiment, it is a RESTful API, which is an architectural style for an application program interface (API) that uses HTTP requests to access and use data. That data can be used to GET, PUT, POST, PATCH and DELETE command types, which refers to the reading, updating, creating and deleting of operations concerning resources. GET requests are used to retrieve data, and POST requests are used to create data (related to quorum and resources; also, to produce and consume the quorum services and data) with the REST API. REST is a logical choice for building APIs that allow users to connect to, manage and interact with cloud services flexibly in a distributed environment, and allows cloud consumers to expose and organize access to HSM based web services. Briefly, as previously mentioned, the method300ofFIG.3is provided in part from services or process that implement, or call, the quorum authorization API400. The API in practice includes more components/modules than those shown, and merely provides an example of the API type.

As see inFIG.4, in accordance with RESTful practice, there are GET methods for quorum details, quorum ID53, quorum request52, quorum policy51name, policy and data attachments. There are also corresponding PATCH, POST and DELETE methods for the quorum attributes associated with the resources40. Other methods and entries are also contemplated for alternate code practice (non-RESTful): isRequired( ) isRequiredToView( ) isRequiredToUpdate( ) setQuroumExpiryDate( ) getQuorumPolicy(resource ID), setQuorumPolicy(resource ID, policy), getQuorumID( ), isApproved(ID), approveQuorum(ID), getAuthorizedUsers( ) setAuthorizedUsers(list of names, quorum acceptance threshold), status=approve(ID,user), and so on.

All the method and actions seen in the flowchart500ofFIG.5have corresponding entries in the quorum authorization API400. For example, API entries exist for determining if an object/resource requires a quorum, whether a quorum policy is attached to an object, retrieving or storing quorum requests, getting/setting quorum thresholds/counts, viewing approval quorum status, and updating objects and policies, among others. Similarly, API entries for getting, putting, posting, deleting or patching any quorum related information are also included in the API. The quorum authorization API400supports various RESTful data formats: /json and/xml. The RESTful format is useful in cloud applications because the calls to the API are stateless, and can scale to accommodate load changes. Any RESTful request can be directed to any instance of a quorum related object or component.

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.

In the embodiments of the invention 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.

The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients and servers over the Internet. HTTP works as a request-response protocol between a client and a server. For example: a client (browser) sends an HTTP request to the server; then the server returns a response to the client. The response contains status information about the request and may also contain the requested content. The two most common HTTP methods are: GET and POST. The GET method is used to request data from a specified resource. Like the PUT method, the POST method is used to send data to a server to create/update a resource. The data sent to the server with POST is stored in the request body of the HTTP request. The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.

FIG.5depicts an exemplary flowchart500for quorum and non-quorum authorization as would be expected to occur in an HSM. As depicted, there are three (3) path flow types: i) quorum required flow (solid line), ii) quorum not required flow (dotted line), and iii) approval flow (bold line). The flowchart500shows multiple state operators, some of which correlated, or represent, components within the HSM ofFIG.1. For example, the resource manager55corresponds to resource API manager36; Quorum management57and quorum manager59relate to quorum37. Quorum policy enforcement56relates to enforcement module34. Resource “foo”58represents any of the resources40(e.g., network, CPU, memory, user, syslog, etc.). Here, it is assumed in the flowchart sequences that an “update” request on resource “foo” requires a quorum and “view” operation does not require a quorum. Understandably, depending on the resource object, and the quorum policy, the authorized operations will differ (e.g., view, update, delete, copy, modify, add, etc.)

Authorization without a Quorum

Steps158-160are directed to a VIEW operation, and demonstrate change of resource without requiring quorum authorization. Here, the user invokes a view API on the “foo” resource in step158. Resource manager32consults quorum enforcement module34to check if view requires quorum or not. Since no quorum is required enforcement module responds with no quorum required. Resource manager allows view request to proceed160and return success161to user.

Authorization with a Quorum

In contrast, steps151-157are directed to an UPDATE operation, and demonstrate creation of a new quorum requests whenever an operation is attempted that requires quorum authorization. Here, the resource requires a quorum and approval before configuration changes are permitted. With regards to the exemplary UPDATE operation, at step151an authorized user on HSM invokes API to update an example resource “foo”. This request lands in resource manager55responsible for managing resources. Resource manager55consults quorum enforcement56if a quorum is required to update foo, at step152. Because a quorum is required to update “foo”, the enforcement module56sends a request to quorum management module57in step153. Quorum management57generates a unique quorum id53and stores update foo parameters in the database17in step154. Quorum management module57then returns generated quorum id53to user in step156and157.

Steps162-165demonstrate voting for a pending quorum request by an authorized person. Here, another user can then cast a vote to approve or disapprove the change associated with quorum id53, steps162-165. For example, another user initiates request to approve the quorum request52, at step161. Quorum manager59API sends request to quorum management module57in step162. Quorum management module57validates if the another user is authorized to approve the quorum. If this user is allowed to approve the quorum, quorum management module57increases the approved voting count by one in database17at step163, and responds back to user in steps164-165.

FIG.6depicts an exemplary diagrammatic representation of a machine700and hardware platform suitable for use to perform the methods and steps exemplified inFIGS.2,3A-3B and4, and by components of the HSM10ofFIG.1A, in accordance with various embodiments. For example, the method200and300can be performed by a hardware processor of the machine700executing computer program code instructions from an electronic memory to execute at least the method steps201-258(FIG.2),311-374(FIGS.3A-3B) and151-164(FIG.5). At least one a hardware processor of machine700can execute computer program code instructions from an electronic memory to execute processes of at least one microservice (via API gateway16or Resources API36) running in an operating system of said HSM to support operation of said resources (40), resource manager API (36), said enforcement module (34), and said quorum manager (37).

The machine700is shown in the form of a computer system700, within which a set of instructions, when executed, may cause the machine to perform any one or more of the methodologies discussed above. In some embodiments, the machine operates as a standalone device, such as a computer, laptop, mobile device, remote control, or display. In some embodiments, the machine may be connected over the network to other machines. 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 computer system700may include a processor702(e.g., a central processing unit (CPU), a graphics processing unit (GPU, or both), a main memory704and a static memory706, which communicate with each other via a bus708. The computer system700may further include a video display unit710(e.g., a liquid crystal display or LCD), a flat panel, a solid state display, or a cathode ray tube (CRT)). The computer system700may include an input device712(e.g., a keyboard, touchless sensing unit110), a cursor control device714(e.g., a mouse, touchless sensing unit110), a disk drive unit716, a signal generation device718(e.g., a speaker or remote control) and a network interface device720.

The disk drive unit716may include a machine-readable medium722on which is stored one or more sets of instructions (e.g., software724) embodying any one or more of the methodologies or functions described herein, including those methods illustrated above. The instructions724may also reside, completely or at least partially, within the main memory704, the static memory706, and/or within the processor702during execution thereof by the computer system700. The main memory704and the processor702also may constitute machine-readable media.

The term “machine-readable medium” shall accordingly be taken to include, but not be limited to: solid-state memories such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; magneto-optical or optical medium such as a disk or tape; and carrier wave signals such as a signal embodying computer instructions in a transmission medium; and/or a digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a machine-readable medium or a distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.

Any combination of one or more computer readable media may be used. The computer readable media may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Scheme, Go, C++, C#, VB.NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Perl, PHP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, entirely on the remote computer or server, or within the Cloud or other computer network. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (SaaS), Platform as a Service (PaaS) for connecting mobile apps to cloud based services, and Security as a Service (SECaas).