A secure system to conceal registration rules for dynamic client registration.

Abstract

A method for facilitating authorized access to protected resources associated with a service provider (SP). The method begins with the SP establishing a root of trust with a third party via an attribute-based encryption (ABE) master secret key and a set of one or more public parameters. Once the entity's review is complete, the SP receives a binary object from the third party that encodes the policy as an encrypted payload. If a client application wishes to enroll in the service provider and interoperate, the SP receives a request for credentials. The request has an associated (ABE) user key generated by the third party in accordance with the policy. The service provider determines whether the binary object obtained during the initial review process can be decrypted using the ABE user key and public parameters. If it can be decrypted, and if any other necessary permissions have been obtained, the service provider issues credentials to the client application.

Description

Technical Field

[0001] This disclosure generally relates to network security, and more particularly to a system that uses Attribute - Based Encryption (ABE) as a mechanism for specifying trust among service providers that need to share client resources.

Background Art

[0002] User authentication and authorization are important components of network security. For example, authenticating a user's identity is the first step in providing secure access to a user account by the user, executing secure transactions, accessing secure network resources, and controlling the same. Authentication is the process of verifying a user's identity, while authorization is the process of granting permissions to a user. Authorization is the function of specifying access rights or privileges to secure or protected resources related to access control. Authorization is defined by an access control policy. During the authorization operation, the computer system uses the access control policy to determine whether a protected resource access request from an authenticated user is approved (i.e., access is permitted) or not approved (i.e., access is denied). Network security consists of these access control policies adopted to prevent and monitor unauthorized access, abuse, modification, or denial of access to protected resources accessible on the network.

[0003] A common operational scenario in today's industry is that a service provider (SP) owns some of a customer's data, and the customer wants to share that data with another service provider for processing. We assume that appropriate network security mechanisms, as described above, are in place for at least some of the parties involved. In this scenario, the second service provider can be considered a client application (CA) of the first service provider. While interactions between these types of service providers offer significant efficiency for the end user, a client application (CA) operating in this manner needs a good way to enroll with service providers (SPs) who may not want to have any arbitrary screening processes to verify that the service provider is a legitimate business.

[0004] Systems that enable the screening of service providers for specific purposes are known in the art. One known screening technique provides a cloud-based key management system for storing, retrieving, generating, and executing key operations. Enterprises use this system to manage, audit, and maintain control and security over keys. The system includes an identity screening service to verify the identity and / or authorization of the key requester, and the screening may also include access to a policy engine to determine the requester's rights. The level of screening provided depends on the requester, the key value, and the function of the requested key. In another known technique, the screening service is protected by not allowing the “relying” party to write the entire screen of the application, thereby enabling the security component to prevent a “man-in-the-middle” attack, i.e., an attack where the perpetrator can simulate the operation of a genuine system. This technique is enabled by a security component associated with a network-enabled application. During operation, the security component begins to display an embedded area of ​​a window that is drawn according to the display information received from the relying party. The security component defines at least a portion of the appearance of the embedded area, but the relying party may not be able to define this portion. The security component sends the address of the relying party to the reputation service and queries the reputation service for the relying party's reputation. The reputation service then returns reputation information about the relying party. If the reputation information indicates that the relying party is trustworthy, the security component allows the network-enabled application to exchange information with the relying party.

[0005] While the service provider screening described above is well-known, there is still a need to provide improved techniques to ensure that identity providers can assure a given entity that has been screened by a trusted screening service. [Overview of the project]

[0006] This disclosure provides methods, apparatus, and computer program products that facilitate authorized access to protected resources associated with a service provider (SP). Authorized access is defined by a security policy that includes one or more rules defining registration requirements for obtaining credentials, which must be used to access the protected resources.

[0007] In a typical embodiment, the method for granting such access is performed by the service provider. The method begins with the service provider establishing a root of trust with a third-party authority, represented by an attribute-based cryptography (ABE) master private key and a set of one or more public parameters of the associated ABE master public key, which are held by the third-party authority. This third-party authority provides a "vetting" service. Once the service provider has been vetting, it receives a binary object from the third-party authority. The third party generates the binary object as an encrypted object by applying the ABE master public key to one or more rules (expressed as Boolean predicates) of the policy, thereby encoding the policy as an encrypted payload. Suppose a client application (e.g., another service provider) then wishes to enroll in and interoperate with the service provider. For this purpose, the service provider receives a request for credentials from the client application (directly or indirectly). The request is associated with an attribute-based cryptography user key, the ABE user key containing one or more attributes generated by the third-party authority according to the policy and required by the policy. Next, the service provider determines whether the binary object obtained during the initial review process can be decrypted using one or more public parameters and an ABE user key. If it can be decrypted, the service provider issues credentials to the client application. The client application then uses the credentials to access the protected resource, but does not receive or access the service provider's security policy. At all times, one or more registration rules of that policy remain obfuscated by being encoded within the encrypted payload of the binary object.

[0008] The above outlines some of the more relevant features of the disclosed subject matter. These features should be interpreted as illustrative only. Many other beneficial results can be achieved by applying the disclosed subject matter in different ways or by modifying the subject matter, as will be explained below. [Brief explanation of the drawing]

[0009] Herein, in order to fully understand the subject matter and merits of this specification, refer to the following description in conjunction with the attached drawings.

[0010] [Figure 1] An exemplary block diagram of a data processing system in which exemplary embodiments of exemplary embodiments may be implemented is shown. [Figure 2] This document presents known techniques that can facilitate access to protected resources within a computing system using attribute-based encryption mechanisms. [Figure 3] This disclosure outlines a typical process flow for a service provider to enroll in a Third-Party Vetting Service (TPVS). [Figure 4] This describes a first embodiment in which a client application directly interacts with a third-party auditing service to enroll and obtain credentials that enable interaction with the target service provider. [Figure 5] This leads to a second embodiment in which the client application interacts indirectly with a third-party review service (for example, via SP redirection) to enroll and obtain credentials that enable interaction with the target service provider. [Modes for carrying out the invention]

[0011] Various aspects of this disclosure are illustrated by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of mechanical logic included in embodiments of Computer Program Product (CPP). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, also depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial time overlap.

[0012] Computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media ("mediums") that collectively comprise a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media include, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any of the foregoing. Any suitable combination may be used. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be construed as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals transmitted through wires, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, since data is not transient while it is stored, this does not mean that the storage device is transient.

[0013] The computing environment 100 includes an example of an environment that runs at least some of the computer code necessary to perform the methods of the present invention, including the attribute-based cryptographic enrollment and utilization code 200 of this disclosure, which facilitates the ability of client applications to enroll in and interoperate with the target service provider without accessing one or more rules of the target service provider's access policy or other security policy. In addition to block 200, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including processing circuits 120 and a cache 121), a communication fabric 111, volatile memory 112, persistent storage 113 (including the operating system 122 and blocks 200 as identified above), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0014] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device currently known or to be developed in the future that is capable of running programs, accessing networks, or querying databases such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation may be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 100, in order to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in the cloud in Figure 1, it may be located in the cloud. On the other hand, computer 101 is not required to be located in the cloud, except to any extent that can be definitively shown.

[0015] The processor set 110 includes one or more computer processors of any type currently known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, for example, multiple coordinated integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. The cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 110. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 110 may be designed to operate in qubits and perform quantum computing.

[0016] Computer-readable program instructions are typically loaded onto computer 101 to implement a computer implementation method by having the processor set 110 of computer 101 execute a series of operational steps, and as a result, the instructions thus executed instantiate the methods specified in the flowcharts and / or descriptions of the computer implementation methods contained herein (collectively referred to as the “Methods of the Invention”). These computer-readable program instructions are stored in various types of computer-readable storage media, such as the cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the Methods of the Invention. In the computing environment 100, at least some of the instructions for executing the Methods of the Invention may be stored in blocks 200 in persistent storage 113.

[0017] The communication fabric 111 is a signal conduction path that enables various components of the computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths, such as optical fiber communication paths and / or wireless communication paths, may be used.

[0018] The volatile memory 112 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random-access memory (RAM) or static RAM. Typically, the volatile memory 112 is characterized by random access, but this is not required unless explicitly stated. In computer 101, the volatile memory 112 is located in a single package and resides inside computer 101, but alternatively or additionally, the volatile memory may be distributed across multiple packages and / or located externally to computer 101.

[0019] The persistent storage 113 is any form of non-volatile storage for a computer, currently known or to be developed in the future. Non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied directly to the computer 101 and / or to the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 can take several forms, such as Linux employing a kernel, various known proprietary operating systems, or open-source portable operating system interface type operating systems. The code contained in block 200 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0020] The peripheral device set 114 includes a set of peripheral devices for the computer 101. Data communication connections between the computer 101's peripheral devices and other components may be implemented in various ways, such as Bluetooth® connections, near-field communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), insert-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 123 may include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, computer 101 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0021] The network module 115 is an aggregate of computer software, hardware, and firmware that enables the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi (registered trademark) signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data via the Internet. In some embodiments, the network control function and the network transfer function of the network module 115 are executed on the same physical hardware device. In other embodiments (for example, embodiments that utilize Software-Defined Networking (SDN)), the control function and the transfer function of the network module 115 are executed on physically separate devices such that the control function manages a plurality of different network hardware devices. The computer-readable program instructions for implementing the method of the present invention are usually downloaded to the computer 101 from an external computer or an external storage device through the network adapter card or network interface included in the network module 115. It can be downloaded to the computer 101 through the network adapter card or network interface included in the network module 115.

[0022] The WAN 102 is any wide area network (for example, the Internet) that is currently known or will be developed in the future and enables the exchange of computer data between remote locations by any technology for exchanging computer data. In some embodiments, the WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to exchange data between devices located in a local area, such as a Wi-Fi network. The WAN and / or LAN typically includes computer hardware such as copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0023] An end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 101) and can take any of the forms discussed above in relation to computer 101. EUD 103 typically receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to an end-user, these recommendations would typically be communicated from computer 101's network module 115 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, desktop computer, and similar.

[0024] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0025] The public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functions, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically exploits resource sharing to achieve consistency and economies of scale. The direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments that run on various computers that make up the host physical machine set 142, which is the universe of physical computers within and / or available in the public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It is understood that these VCEs can be stored as images and transferred either as images or after instantiation of the VCE, within and among various physical machine hosts. The cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages the active instantiation of VCE deployments. The gateway 140 is an aggregation of computer software, hardware, and firmware that enables the public cloud 105 to communicate through the WAN 102.

[0026] Here, we offer some further explanation of virtual computing environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature in which the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running in them. Computer programs running on a normal operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0027] The private cloud 106 is similar to the public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown as being in communication with the WAN 102, in other embodiments, the private cloud may be completely isolated from the internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0028] Network Security As further background, as explained above, user authentication and authorization are important components of network security. For example, authenticating a user's identity is the first step in providing users with control over secure user accounts, secure transactions, secure access to network resources, and the like. Authentication is the process of verifying a user's identity, while authorization is the process of granting privileges to a user. In other words, authentication is the process of verifying who a user is, while authorization is the process of verifying what a user can do or what they can access. Authorization is the function of specifying access rights or privileges to secure or protected resources, related to access control. Authorization is defined by access control policies. During an authorization operation, the computer system uses the access control policy to determine whether a request for access to a protected resource from an authenticated user is approved (i.e., access is permitted) or not approved (i.e., access is denied). Protected resources may include, for example, data, files, documents, software applications and programs containing confidential or sensitive information, storage, processors, memory, network resources, and the like. Logically, authentication precedes authorization.

[0029] Generally speaking, network security consists of access control policies employed to prevent and monitor unauthorized access, misuse, modification, or denial of network-accessible protected resources. Typically, users choose or are assigned identifiers such as usernames and passwords or other authentication information that permit user access to network-accessible protected resources within the user's authority. For example, once authenticated, a firewall applies access control policies that define which protected resources on the network each user can access.

[0030] Attribute-Based Encryption As mentioned above, there are many computer systems on today's internet where service providers and customers (i.e., resource users) share protected resources such as confidential data. One of the challenging problems in this provider / customer model is user authentication and authorization. There are several ways to implement user authentication and authorization. However, some of the latest methods enable implementations to protect access control policies by encrypting the access control policy along with the protected data using functional cryptography.

[0031] One of these modern methods is attribute-based encryption, where protected data is encrypted and made available to any user. The implementation relies on the cryptographic strength of the algorithm for obfuscating the encrypted Boolean predicates (e.g., access control policies) within the ciphertext as protection against the protected data and unauthorized user access to it. Attribute-based encryption is a type of public-key encryption (PKE) where the user's secret encryption key and ciphertext depend on user attributes such as the geographical location where the user works, the user's job title, the user's duties, the resource group the user belongs to, the user's security level, and so on. In attribute-based encryption, the ciphertext can only be decrypted if the attribute set of the user key matches the attributes of the ciphertext. There are two main types of attribute-based encryption techniques: (1) key-policy attribute-based encryption; and (2) ciphertext-policy attribute-based encryption.

[0032] Figure 2 shows a typical implementation of an ABE-based protection mechanism. In this example, a protected resource access manager 201 controls resource user access to a protected resource set 202. For this purpose, the protected resource access manager 201 uses an attribute-based cryptographic user key 204 as a secret cryptographic key and generates a key hash message authentication code digital signature for a set of header fields of a protected resource access request made by a resource user 206 requesting access to a specific protected resource within the protected resource set. The protected resource access manager 201 authenticates resource user 206 by comparing the generated authentication code digital signature with the authentication code digital signature received in the embedded header field of the protected resource access request. Once resource user 206 is authenticated by determining that a match exists between the authentication code digital signatures, the protected resource access manager 201 uses the same attribute-based cryptographic user key 204 used to generate the authentication code digital signature received in the embedded header field of the protected resource access request to access the requested protected resource or It decrypts the metadata corresponding to the requested protected resource. If decryption is successful using a specific attribute-based encryption user key, the protected resource access manager 201 determines that the resource user has permission to access that particular protected resource and grants access.

[0033] A Secure System for Concealing Registration Rules for Dynamic Client Enrollment The technique of this disclosure is described below against this background. A typical operating environment in which this technique is practiced is shown in Figure 3. In this operating environment, it is assumed that a (first) service provider (SP) 300(1) possesses some data of customer 302, and the customer wishes to share that data with another (second) service provider 300(2) for processing. The second service provider 300(2) can be considered a client application (CA) of the first service provider 300(1), in which case it may be useful to consider the first service provider as the “target service provider”. In this solution, a third-party review service (TPVS) 304 is provided so that the SP / CA 300(2) can enroll in service provider 300(1). In one embodiment, the TPVS operates as a network-accessible managed service (e.g., as software as a service), but the TPVS can also be implemented as a software-based process associated with some other hardware-based security solution, system, device, equipment, or mechanism. In a typical implementation, TPVS is implemented in a cloud-accessible computing system as shown in Figure 1. More generally, TPVS304 provides a screening service for a CA to enroll in one or more service providers. Thus, as shown in Figure 3, there are usually multiple SPs (e.g., 300)(1-n) and TPVS304. Not all SP300s need to have the same security policy; typically, each SP has a different security policy. A given policy will be specific to the use case. More generally, in typical cases, the CA does not need to be an SP.

[0034] According to this disclosure, TPVS304 utilizes attribute-based cryptography (ABE)305 as a mechanism used to specify trust between service providers that need to share client resources, such as data, hosted by a first service provider 300(1) that a customer 302 wishes to have processed by a second service provider 300(2), or otherwise associated with the first service provider 300(1). A preferred workflow begins with a service provider (seeking to benefit from the review service) enrolling in the service. This process is sometimes referred to herein as SP initialization trust. For this purpose, as shown in Figure 3, in step (1) TPVS304 creates an ABE master secret key 306 and public parameters 308 for the root of the system trust. The ABE master secret key 306 is stored in a trusted data store, such as a hardware enclave 310. Now, assume that an SP (e.g., SP300(1), 300(2), or any other SP) wishes to enroll in TPVS304.

[0035] Figure 3 also shows how SP300 enrolls as an SP in TPVS304 by performing the following substeps. In step (2a), SP300 and TPVS304 work together to create a policy that satisfies the requirements of both. Typically, a policy consists of a set of rules that can be specified in a configurable way, such as a rule tree. The nature and syntax of a given set of rules (and therefore the policy) may vary depending on the implementation, and the nature and scope of the cooperation between the SP and TPVS may also vary, but the overall goal is to provide TPVS with sufficient evidence that the SP is operating in a manner compliant with one or more rules of the policy. Thus, in one exemplary embodiment, the rules specify certain geographical, temporal, or other requirements that must be met, such as providing proof that the SP operates within a geographical boundary, has been in business for a given period of time, and has certain regulations and compliance systems in place. There is no limit to the one or more conditions that an SP must meet to be trusted.

[0036] Referring again to Figure 3, assuming that the enrolled SP300 has submitted sufficient evidence to TPVS that one or more rules required by the policy are met, in step 2(b), TPVS304 encodes one or more attributes of the policy using ABE Boolean logic and applies the ABE master public key to the result to generate an encrypted blob312. In this way, one or more rules of the policy are concealed (encoded) within the payload of the blob. In step (2c), TPVS304 sends the encrypted blob312 to SP300 via the secure channel. In step (2d), TPVS304 sends the public parameter 308 of the ABE master private key 306 to the SP via the secure channel. Steps (2c) and (2d) may be combined and may use one or more secure channels. This completes the onboarding process for the SP. As those skilled in the art will understand, this review process is used solely to identify that SP300 is a valid SP, and not to detect any malicious entities attempting to infiltrate the SP's trust boundary; access to data owned by the SP (which is SP300(1) in Figure 3) remains subject to standard access control mechanisms.

[0037] Figure 4 illustrates the process flow in which the system uses ABE as a mechanism for specifying trust between first and second service providers that need to share client resources. In a typical use case, a client application 401 identifies a first service provider 403 that it wishes to enroll in order to gain access to customer data associated with the first service provider, and there is a CA (associated with the second service provider). In this embodiment, the CA 401 is aware of the existence of TPVS 405.

[0038] Referring to Figure 4, the process for the requesting client application 401 to obtain credentials begins with step (1) the client application 401 logging into the TPVS405 portal and identifying the SP that it wishes to enroll. In a typical embodiment, this is accomplished via a User Interface (UI) containing a dropdown list of available SPs, although the specific nature of the portal is outside the scope of this disclosure. For this purpose, programmatic interaction (e.g., via a preferred API) may be used. In this exemplary embodiment, once the client application has entered the SP selection, in step (2) the TPVS405 creates an ABE user key having one or more attributes necessary to satisfy the SP's policy request (i.e., one or more rules specified thereby). As mentioned above, the nature of the rules required by the policy is negotiated between the SP and TPVS during the SP review process. In step (3), the TPVS405 issues the ABE user key to the requesting client application 401. In step (4), the client presents this ABE user key to SP403. In step (5), SP403 attempts to decrypt the encrypted blob obtained by SP403 during enrollment to TPVS405 using the user key and public parameters (received in step 2(d) in Figure 3) presented by the client. In step (6), if the user key combined with the public key parameters successfully decrypts the blob, SP403 recognizes that the client application has obtained credentials from TPVS405 that match the SP's policy; and as a result, SP403 trusts the client application. Therefore, in step (7), SP issues any necessary credentials on SP403 to the client application 401, for example, to use an API or other programmatic mechanism, thereby enabling the CA to obtain data (or other resources) from SP.

[0039] The process flow described above ensures that the service provider is not allowed to deceive data owners into believing that the CA is providing a legitimate service. However, before the service provider issues credentials (step (7)), the service provider must also obtain the data owner's consent to process their data. This consent can be obtained using access control (e.g., that which is done by OIDC).

[0040] In the alternative embodiment shown in Figure 5, the client application 501 is unaware of TPVS and instead interacts with the service provider 503 first. For this purpose, in step (1a), the client application 501 attempts to register with SP 503 using, for example, a predetermined or configured registration procedure. The nature of the registration is outside the scope of this disclosure; a typical registration may simply require the presentation of a client identifier and password. In step (1b), SP 503, as part of its response to the client application, redirects the client application to the TPVS that the client must use (for example, via an HTTP 302 redirect). The remaining flow is shown in Figure 4 and proceeds in exactly the same way as the target flow described above. Thus, in step (2), TPVS 505 creates an ABE user key having one or more attributes necessary to satisfy the SP's policy request, and in step (3), TPVS 505 issues the ABE user key to the requesting client application 501. In step (4), the client presents this ABE user key to SP 503. In step (5), SP503 attempts to decrypt the encrypted blob obtained by SP503 during enrollment to TPVS505 using the user key and public parameters presented by the client. In step (6), if the user key combined with the public key parameter successfully decrypts the blob, SP503 recognizes that the client application has obtained credentials from TPVS that match the SP's policy, and as a result, SP503 trusts the client application. Therefore, assuming again that the service provider also has the necessary authority to process the owner's data, the flow proceeds to step (7). In this step, the SP issues any necessary credentials on SP503 to the client application 501, for example, to use an API or other programmatic mechanism, and again allows the CA to obtain data (or other resources) from the SP.

[0041] The techniques described herein offer numerous advantages. As stated above, attribute-based cryptography is used as a preferred mechanism for specifying trust between service providers that need to share client resources. The ABEs described and utilized herein enable participating service providers to verify and conceal their policies for enrolling clients in third-party services. Given By encapsulating specific policy details within the encrypted payload itself, client applications can dynamically register with (and subsequently interact with) a target service provider, but the policy itself is never returned to the requesting client application. This approach allows for complete concealment of the target service provider's policy rules while still enabling seamless and dynamic provisioning of client applications aiming for interoperability with the service provider.

[0042] Generally speaking, the methods described herein may be implemented as standalone methods, for example, as software-based functions executed by a processor, or they may be available as managed services (including web services via SOAP / XML interfaces). Details of specific hardware and software implementations described herein are for illustrative purposes only and do not limit the scope of the subject matter described.

[0043] More generally, each computing device within the context of the disclosed subject is a data processing system (as shown in Figure 1) including hardware and software, and these entities communicate with each other over networks such as the Internet, intranet, extranet, private network, or any other medium of communication or link. Applications on data processing systems provide native support for the Web and other known services and protocols, including, but not limited to, HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL. Information on SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for the development and maintenance of these standards; detailed information on HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0044] As shown in Figure 1, the methods described herein can be implemented within or in conjunction with various server-side architectures, including simple n-tier architectures, web portals, federation systems, and similar structures. The techniques described herein can also be practiced entirely or partially in loosely coupled server (including "cloud" based) environments.

[0045] More generally, the subject matter described herein may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments including both hardware and software elements. In preferred embodiments, the functionality is implemented in software, including, but not limited to, firmware, resident software, microcode, and the like. Furthermore, as stated above, the analysis engine functionality may take the form of a computer program product accessible from a computer-enabled or computer-readable medium that provides program code used by or in connection with a computer or any instruction execution system. For the purposes of this specification, a computer-enabled or computer-readable medium may be any device that may contain or store programs used by or in connection with an instruction execution system, apparatus, or device. The medium may be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems (or apparatus or devices). Examples of computer-readable mediums include semiconductor memory or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical discs include Compact Disc - Read-Only Memory (CD-ROM), Compact Disc - Read / Write (CD-R / W), and DVD. Computer-readable media are tangible items.

[0046] In a typical embodiment, the verification system and attribute-based cryptographic enrollment and utilization codes are implemented as software running on a dedicated computer, preferably one or more processors. The software is stored in one or more datastores or memories associated with one or more processors, and the software may be implemented as one or more computer programs. This collection of dedicated hardware and software constitutes the system described above.

[0047] The above describes a specific sequence of operations performed by a particular embodiment of the disclosed subject matter, but please understand that such a sequence is illustrative, as alternative embodiments may perform operations in a different order, combine certain operations, superimpose certain operations, or do similar things. References to given embodiments in this specification indicate that the described embodiments may include certain features, structures, or characteristics, but not all embodiments may necessarily include certain features, structures, or characteristics.

[0048] Finally, although the given components of the system are described individually, those skilled in the art will understand that some functions may be combined or shared with given instructions, program sequences, code portions, and similar elements.

[0049] The methods described herein may be implemented as key policy-based ABEs, ciphertext policy-based ABEs, any other ABE derivations, or any similar cryptographic scheme.

[0050] In another embodiment, the roles of the SP and CA can be reversed with respect to the operation described above; in this case, the TPVS provides the CA with the binary object, while the SP receives the ABE user key. The decryption function operates in the same manner as described above.

[0051] The techniques described herein provide for another technical field, namely, improvements to onboarding and access control systems between providers, and improvements to the operational capabilities of such systems when used in the manner described herein.

[0052] The nature of the data accessed by the client application, and the specific way in which the client application interoperates with the service provider after receiving credentials, are implementation-specific and are not limitations of this disclosure.

[0053] Having explained the subject matter, the claims are as follows:

Claims

1. A method for enabling authorized access to a protected resource associated with a service provider (SP), wherein the authorized access is defined by a security policy which includes one or more rules defining registration requirements for obtaining credentials, the credentials must be used to access the protected resource, and the method comprises: receiving a binary object, the binary object being generated by an entity which applies an attribute-based encryption (ABE) key to the one or more rules of the policy expressed as a Boolean predicate; receiving a request for the credentials, the request being associated with an ABE user key, the ABE user key including one or more attributes generated by the entity in accordance with the policy and required by the policy; determining whether the binary object can be decrypted using the ABE key and one or more public parameters; and if it is determined that the binary object can be decrypted, issuing the credentials.

2. The method according to claim 1, wherein the request for the aforementioned credentials is received from a client application.

3. The method according to claim 2, wherein the client application is associated with a second service provider.

4. The method according to claim 3, further comprising the steps of: receiving a request from the client application to access the protected resource; and returning the protected resource to the client application.

5. The method according to claim 1, wherein the entity is a third-party examination service.

6. The method according to claim 1, further comprising the step of establishing a route of trust to the entity, wherein the route of trust is represented by an ABE master secret key and the set of one or more public parameters.

7. The method according to claim 6, further comprising the step of determining whether the service provider has obtained permission from the resource owner to access the protected resource before issuing the credentials.

8. Device associated with a service provider (SP), comprising: a processor; computer memory holding computer program instructions to be executed by the processor to enable authorized access to a protected resource associated with the SP, wherein authorized access is defined by a security policy having one or more rules defining registration requirements for obtaining credentials, the credentials to be used to access the protected resource, and the computer program instructions are: receiving a binary object, the binary object being generated by an entity applying an attribute-based encryption (ABE) key to the one or more rules of the policy expressed as a Boolean predicate; receiving a request for the credentials, the request being associated with an ABE user key, the ABE user key being generated by the entity according to the policy and including one or more attributes required by the policy; determining whether the binary object can be decrypted using the ABE user key and one or more public parameters; and having program code configured to issue the credentials if it is determined that the binary object can be decrypted.

9. The apparatus according to claim 8, wherein the request for the aforementioned credentials is received from a client application.

10. The apparatus according to claim 9, wherein the client application is associated with a second service provider.

11. The apparatus according to claim 10, wherein the program code is further configured to receive a request for access to the protected resource from the client application; and to return the protected resource to the client application.

12. The apparatus according to claim 8, wherein the entity is a third-party examination service.

13. The apparatus according to claim 8, wherein the program code is further configured to establish a trust route to the entity, the trust route being represented by an ABE master secret key and the set of one or more public parameters.

14. The apparatus according to claim 13, wherein the program code is further configured to determine whether the service provider has obtained permission from the resource owner to access the protected resource before issuing the credentials.

15. A computer program product in a non-temporary computer-readable medium, wherein the computer program product is executed by a processor in a host processing system associated with a service provider (SP) to enable authorized access to protected resources associated with the SP. A computer program product having program code that holds computer program instructions, authorized access is defined by a security policy having one or more rules defining registration requirements for obtaining credentials, said credentials must be used to access said protected resources, said computer program instructions receive a binary object, said binary object is generated by an entity applying an attribute-based encryption (ABE) key to the one or more rules of the policy expressed as Boolean predicates; receives a request for said credentials, said request is associated with an ABE user key, said ABE user key is generated by the entity in accordance with the policy and includes one or more attributes required by the policy; determines whether the binary object can be decrypted using the ABE user key and one or more public parameters; and if it is determined that the binary object can be decrypted, issues said credentials.

16. The computer program product according to claim 15, wherein the request for the aforementioned credentials is received from a client application.

17. The computer program product according to claim 16, wherein the client application is associated with a second service provider.

18. The computer program product according to claim 17, wherein the program code is further configured to receive a request for access to the protected resource from the client application; and to return the protected resource to the client application.

19. The computer program product according to claim 15, wherein the program code is further configured to establish a route of trust to the entity, the route of trust being represented by the ABE master secret key and the set of one or more public parameters.

20. The computer program product according to claim 19, wherein the program code is further configured to determine whether the service provider has obtained permission from the resource owner to access the protected resource before issuing the credentials.

Images