Security system for hiding registration rules for dynamic client registration

Abstract

A method for facilitating granted access to protected resources associated with a service provider (SP). The method begins with the SP establishing a root of trust for a third party via a set of attribute-based encryption (ABE) master secret key and one or more common parameters. Once reviewed by the entity, the SP receives a binary object from the third party that encodes the policy as a cryptographic payload. When a client application desires to register with and interoperate with a service provider, the SP receives a request for credentials. The request has an associated (ABE) user key generated by a third party according to a policy. The service provider determines whether the binary object obtained during the initial review process can be decrypted using the ABE user key and the common parameter as well as the ABE user key. If so, and assuming that it has obtained any other necessary permission, the service provider issues the credential to the client application.

Description

Technical Field

[0001] The present disclosure relates generally to network security, and more particularly to a system that uses attribute-based encryption (ABE) as a mechanism for specifying trust between service providers that need to share client resources. Related technical background

[0002] User authentication and authorization are key components of network security. For example, authenticating a user's identity is the first step in providing control over a user's ability to access secure user accounts, perform secure transactions, access secure network resources, and so on. Authentication is the process of confirming 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, which is related to access control. Authorization is defined by an access control policy. During an authorization operation, a computer system uses an access control policy to determine whether a protected resource access request from an authenticated user is approved (i.e., granted access) or not approved (i.e., denied access). Network security includes these access control policies, which are employed to prevent and monitor unauthorized access, misuse, modification, or denial of access to network-accessible protected resources.

[0003] A common operational scenario in today's industry involves a service provider (SP) holding some data about a customer, and where the customer wants to share that data with another service provider for processing. It's assumed that appropriate network security mechanisms, such as those described above, are in place for at least some of the participants. In this scenario, the second service provider can be considered a client application (CA) of the first service provider. While these types of service provider-to-service provider interactions offer significant efficiencies for end users, client applications (CAs) operating in this manner require a robust way to register with the service provider (SP), who may not want to have any vetting process to ensure the service provider is a legitimate enterprise.

[0004] Systems capable of vetting service providers for certain purposes are known in the art. In one known vetting method, a cloud-based key management system is provided to store, retrieve, generate, and perform key operations. Companies use this system to manage, audit, and maintain control and security over their keys. The system includes an identity vetting service to verify the identity and / or authorization of key requesters, and the vetting may include accessing a policy engine to determine the requester's permissions. The level of vetting provided depends on the requester, the key's value, and the requested key functionality. In another known technique, the vetting service is protected by not allowing "relying" parties to write to the entire application screen, thereby enabling a security component to prevent "man-in-the-middle" attacks, which allow criminals to impersonate the actions of a legitimate system. This method is enabled by a security component associated with a network-enabled application. In operation, the security component initiates the display of an embedded area of ​​a window drawn based on 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 define this portion. The security component sends the relying party's address to a 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 reputable, the security component allows the network-enabled application to exchange information with the relying party.

[0005] While service provider vetting such as described above is known, there remains a need to provide improved techniques for ensuring that a given entity has been vetted by an identity provider that is trusted for vetting services. Summary of the Invention

[0006] According to the present disclosure, a method, apparatus, and computer program product are provided for facilitating permitted access to protected resources associated with a service provider (SP). The permitted access is defined by a security policy that includes one or more rules defining registration requirements for obtaining credentials required for accessing the protected resources.

[0007] In a representative embodiment, a method for granting such access is performed by a service provider. The method begins with the service provider establishing a root of trust with a third-party entity. This root of trust is represented by a set of one or more public parameters of an attribute-based encryption (ABE) master secret key and an associated ABE master public key, maintained by the third-party entity. The third-party entity provides a "vetting" service. Once the service provider is vetted, it receives a binary object from the third-party entity. The third-party generates the binary object as a cryptographic object by applying the ABE master public key to one or more rules (expressed as Boolean predicates) of a policy, thereby encoding the policy as a cryptographic payload. Subsequently, assume that a client application (e.g., another service provider) desires to register with and interoperate with the service provider. To this end, the service provider (directly or indirectly) receives a request for credentials from the client application. This request is associated with an attribute-based encryption user key, generated by the third-party entity in accordance with the policy and including one or more attributes required by the policy. The service provider then determines whether the binary object it obtained during the initial vetting process can be decrypted using the one or more public parameters and the ABE user key. If so, the service provider issues the credentials to the client application. The client application then uses the credentials to access the protected resource, but does so without ever receiving or having access to the service provider's security policy. The policy's registration rule or rules are always kept obfuscated by being encoded within the binary object's key payload.

[0008] The above summarizes some of the more relevant features of the disclosed subject matter. These features should be construed as merely illustrative. As will be described below, many other beneficial results can be obtained by applying the disclosed subject matter in different ways or by modifying the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a more complete understanding of the subject matter herein and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0010] Figure 1 depicts an exemplary block diagram of a data processing system in which exemplary aspects of the illustrative embodiments may be implemented;

[0011] Figure 2 Describes known techniques by which an attribute-based encryption mechanism may be used to facilitate access to protected resources in a computing system;

[0012] Figure 3 Depicts a representative process flow for a service provider to register with a Third Party Review Service (TPVS) in accordance with the present disclosure;

[0013] Figure 4 Depicting a first embodiment in which a client application interacts directly with a third-party vetting service to register and obtain credentials enabling interaction with a target service provider; and

[0014] Figure 5 A second embodiment is described in which a client application interacts with a third-party review service indirectly (eg, via SP redirection) to register and obtain credentials that enable interaction with a target service provider. DETAILED DESCRIPTION

[0015] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time, again depending on the technology involved.

[0016] Computer program product embodiments ("CPP embodiments" or "CPP") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, 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 disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. As the term is used in this disclosure, computer-readable storage media should not be construed as storing data in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses transmitted through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at certain occasional points during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but because the data is not transitory while it is stored, this does not make the storage device transitory.

[0017] The computing environment 100 includes an example of an environment for executing at least some of the computer code involved in performing the methods of the present invention, such as the attribute-based encryption registration and usage code 200 of the present disclosure, which facilitates the ability of a client application to register and interoperate with a target service provider without accessing one or more rules of the target service provider's access or other security policies. In addition to the box 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 group 110 (including processing circuitry 120 and cache 121), a communication fabric 111, volatile memory 112, a persistent storage device 113 (including an operating system 122 and the box 200, as described above), a peripheral device group 114 (including a user interface (UI) device group 123, a storage device 124, and an Internet of Things (IoT) sensor group 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 group 142 , a virtual machine group 143 , and a container group 144 .

[0018] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or across multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Although in Figure 1 1 is not shown in the cloud, but the computer 101 can be located in the cloud. On the other hand, the computer 101 need not be in the cloud except to any extent that can be positively indicated.

[0019] Processor complex 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, such as multiple cooperating integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located in the processor chip package and is typically used for data or code that should be quickly accessed by threads or cores running on processor complex 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuitry. Alternatively, some or all of the caches in the processor complex may be located "off-chip." In some computing environments, processor complex 110 may be designed to work with qubits and perform quantum computations.

[0020] Computer-readable program instructions are typically loaded onto the computer 101 to cause the processor group 110 of the computer 101 to execute a series of operating steps to implement a computer-implemented method, such that the instructions so executed can instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as the "inventive method"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor group 110 to control and direct the execution of the inventive method. In the computing environment 100, at least some of the instructions for performing the inventive method can be stored in the permanent storage device 113 in the block 200.

[0021] Communications fabric 111 is the signaling pathway that allows the various components of computer 101 to communicate with each other. Typically, the fabric is comprised of switches and conductive pathways, such as those that constitute a bus, a bridge, physical input / output ports, etc. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

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

[0023] Permanent storage device 113 is any form of non-volatile memory for computers now known or developed in the future. The non-volatility of this memory means that the stored data is retained regardless of whether power is supplied to computer 101 and / or directly to permanent storage device 113. Permanent storage device 113 can be a read-only memory (ROM), but typically at least a portion of a permanent storage device allows the writing, deletion, and rewriting of data. Some common forms of permanent storage devices include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, such as Linux, various known proprietary operating systems, or open source portable operating system interface type operating systems using a kernel. The code included in box 200 typically includes at least some computer code involved in performing the method of the present invention.

[0024] The peripheral device group 114 includes a group of peripheral devices of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection made by a cable (such as a universal serial bus (USB) type cable), a plug-in type connection (e.g., a secure digital (SD) card), a connection made through a local area communication network, and even a connection made through a wide area network such as the Internet. In various embodiments, the UI device group 123 may include components such as a display screen, a speaker, a microphone, a wearable device (such as goggles and a smart watch), a keyboard, a mouse, a printer, a touchpad, a game controller, and a tactile device. The storage device 124 is an external storage device, such as an external hard drive, or a plug-in storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where computer 101 requires a large amount of storage (e.g., where computer 101 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor group 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0025] The network module 115 is a collection of computer software, hardware, and firmware that allows 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 signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control function and the forwarding function of the network module 115 are executed on physically separate devices so that the control function manages several different network hardware devices. Computer-readable program instructions for executing the method of the present invention can typically be downloaded to the computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0026] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology now known or later developed for transmitting computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. A WAN and / or LAN typically includes computer hardware, such as copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0027] End-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the business operating computer 101), and can take any of the forms discussed above in connection with computer 101. EUD 103 typically receives helpful and useful data from the operation of computer 101. For example, in the hypothetical scenario where computer 101 is designed to provide recommendations to an end-user, the recommendations can typically be transmitted from network module 115 of computer 101 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 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, or the like.

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

[0029] 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 capabilities, particularly data storage (cloud storage) and computing power, without requiring direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 105 is performed by computer hardware and / or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented as virtual computing environments running on various computers comprising host physical machine group 142, which is the universe of physical computers in and / or available to public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine group 143 and / or containers from container group 144. It will be appreciated that these VCEs can be stored as images and transferred between various physical machine hosts either as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0030] Some further explanation of Virtualized Computing Environments (VCEs) will now be provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated userspace instances, called containers. From the perspective of the programs running in them, these isolated userspace instances typically appear to be actual computers. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0031] 105 . Private cloud 106 is similar to public cloud 105 , except that the computing resources are only available to a single enterprise. Although private cloud 106 is depicted as communicating with WAN 102 , in other embodiments, the private cloud can be completely disconnected 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), typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is tied together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple component clouds. In this embodiment, public cloud 105 and private cloud 106 are both part of a larger hybrid cloud.

[0032] Cybersecurity

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

[0034] Generally, network security includes access control policies that are employed to prevent and monitor unauthorized access, misuse, modification, or denial of access to network-accessible protected resources. Typically, a user selects or is assigned an identifier, such as a username, and a password or other authentication information that allows the user to access network-accessible protected resources within the user's authorized organization. For example, once authenticated, a firewall enforces the access control policies that define what protected resources on the network the corresponding user is allowed to access.

[0035] Attribute-based encryption

[0036] As mentioned above, today, the Internet is home to numerous computer systems that share protected resources (e.g., confidential data) between service providers and clients (i.e., resource users). A challenging issue with this provider / client model is user authentication and authorization. There are various approaches to implementing user authentication and authorization. However, some newer approaches allow for the protection of access control policies by encrypting both the access control policy and the protected data using functional encryption.

[0037] One of these newer approaches is attribute-based encryption, in which protected data is encrypted and available to any user, and the implementation relies on the cryptographic strength of the algorithm to obfuscate the protected data and the Boolean predicates (e.g., access control policies) encrypted within the ciphertext as protection against unauthorized user access to the protected data. Attribute-based encryption is a type of public key encryption (PKE) in which a user's secret encryption key and the ciphertext depend on attributes of the user, such as, for example, the geographic location where the user works, the user's job title, the user's job role, the resource groups of which the user is a member, the user's security level, etc. In attribute-based encryption, decryption of the ciphertext is possible only when a set of attributes of the user's 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.

[0038] Figure 2 A representative implementation of an ABE-based protection mechanism is depicted. In this example, a protected resource access manager 201 controls access to a set of protected resources 202 by a resource user. To this end, the protected resource access manager 201 utilizes an attribute-based encryption user key 204 as a secret encryption key to generate a key-hash message authentication code digital signature over a set of header fields of a protected resource access request made by a resource user 206 requesting access to a specific protected resource in the protected resource set. The protected resource access manager 201 compares the generated authentication code digital signature with an authentication code digital signature received in an embedded header field of the protected resource access request to authenticate the resource user 206. Upon authenticating the resource user 206 by determining that there is a match between the authentication code digital signatures, the protected resource access manager 201 decrypts the requested protected resource or metadata corresponding to the requested protected resource using the same attribute-based encryption user key 204 received in the embedded header field of the protected resource access request that was used to generate the authentication code digital signature. If decryption using the encrypted user key based on the specific attribute is successful, the protected resource access manager 201 determines that the resource user is authorized to access the specific protected resource and authorizes the access.

[0039] A secure system for hiding registration rules for dynamic client registrations

[0040] With the above as background, the technology of the present disclosure is now described. Figure 3 A representative operating environment for implementing the technology is shown. In this operating environment, it is assumed that some (first) service provider (SP) 300 (1) has some data of a customer 302, which the customer wants to share 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 is useful to think of the first service provider as the "target service provider". In this solution, a third party review service (TPVS) 304 is provided to enable the SP / CA 300 (2) to register with the service provider 300 (1). In one embodiment, the TPVS is operated as a network-accessible management service (e.g., as software as a service), although the TPVS can also be implemented as a software-based process associated with some other hardware-based security solution, system, device, apparatus or mechanism. In a representative implementation, in a system such as Figure 1 TPVS is implemented in the cloud-accessible computing system shown. More generally, TPVS 304 provides an audit service through which a CA registers with one or more service providers. Figure 3 As shown, there are typically multiple SPs (e.g., 300) (1-n) and a TPVS 304. Not all SPs 300 necessarily have the same security policy, and typically each SP has a different security policy. A given policy can be specific to a use case. Further generalizing, for the general case, a CA need not be an SP.

[0041] According to the present disclosure, TPVS 304 utilizes attribute-based encryption (ABE) 305 as a mechanism for specifying trust between service providers that need to share client resources, such as data that a client 302, hosted by or otherwise associated with a first service provider 300(1), desires to be processed by a second service provider 300(2). The preferred workflow begins with a service provider (who seeks to obtain the benefits of the audit service) registering with the service. This process is sometimes referred to herein as SP-initialized trust. To this end, as Figure 3 As shown, at step (1), TPVS 304 creates an ABE master secret key 306 and public parameters 308 for a root of trust in the system. ABE master secret key 306 is stored in a trusted data store such as hardware enclave 310. Now assume that an SP (e.g., SP 300(1)), (300(2)), or any other SP) wishes to enroll with TPVS 304.

[0042] Figure 3 The SP 300 is also depicted as registering as an SP with the TPVS 304 by performing the following sub-steps. In step (2a), the SP 300 and the TPVS 304 collaborate to create a policy that satisfies both of their requirements. Typically, a policy comprises a set of rules that can be specified in a configurable manner, such as a rule tree. The nature and syntax of a given rule (and therefore a policy) may vary depending on the implementation, and the nature and scope of the collaboration between the SP and the TPVS may also vary, but with the overall goal of the SP providing sufficient proof to the TPVS that it is operating in a manner that complies with one or more rules of the policy. Thus, in one example embodiment, the rules specify specific geographic, temporal, or other requirements that must be met, such as the SP providing proof that it operates within geographic boundaries, that it has been in business for a given period of time, that it has specific regulatory and compliance systems in place, etc. There is no limit to the one or more conditions that the SP is required to meet in order to be trusted.

[0043] Return Reference Figure 3 , and assuming that the registered SP 300 provides the TPVS with sufficient evidence that one or more rules required by the policy are satisfied, in step 2(b), the TPVS 304 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 blob (binary large object) 312. In this way, one or more rules of the policy are hidden (encoded) within the payload of the blob. In step (2c), the TPVS 304 transmits the encrypted blob 312 to the SP 300 over a secure channel. In step (2d), the TPVS 304 transmits the public parameters 308 of the ABE master secret key 306 to the SP over a secure channel. Steps (2c) and (2d) can be combined, and one or more secure channels can be used. This completes the admission (review) process for the SP. As the skilled person will understand, this review process is only used to identify that the SP 300 is a valid SP, and not some malicious entity attempting to breach the trust boundary of the SP; access to data owned by the SP (in Figure 3 In this case, SP 300 (1))) is still subject to standard access control mechanisms.

[0044] Figure 4 This paper describes a process flow for a system that uses ABE as a mechanism for establishing trust between first and second service providers that need to share client resources. In a representative use case, there is a client application 401 (associated with a second service provider) that identifies a first service provider 403. The CA wishes to register with the first service provider, for example, to gain access to data of a client associated with the first service provider. In this embodiment, the CA 401 is aware of the existence of the TPVS 405.

[0045] refer to Figure 4 , the process of requesting a client application 401 to obtain credentials begins at step (1) when the client application 401 logs into the TPVS 405 portal and identifies the SP with which it wishes to register. In a typical embodiment, this is accomplished via a user interface (UI) that includes a drop-down list of available SPs, although the specific nature of the portal is outside the scope of this disclosure. Programmatic interaction (e.g., via a suitable API) may be used for this purpose. In this exemplary embodiment, and upon input of the SP selection by the client application, at step (2) the TPVS 405 creates an ABE user key having one or more attributes required to satisfy the policy requirements of the SP (i.e., the one or more rules specified thereby). As described above, the nature of the rules required by the policy may be negotiated between the SP and the TPVS during the SP review process. At step (3), the TPVS 405 issues the ABE user key to the requesting client application 401. At step (4), the client presents the ABE user key to the SP 403. At step (5), the SP 403 attempts to register the ABE user key using the user key and public parameters provided by the client (in Figure 3 405). The client application 401 uses the user key (received in step 2(d) of step 6) to decrypt the encrypted blob obtained by SP 403 during its registration with TPVS 405. At step (6), if the user key combined with the public key parameters successfully decrypts the blob, SP 403 knows that the client application has obtained credentials from TPVS 405 that match the SP's policy; and therefore SP 403 can trust the client application. Therefore, and as step (7), the SP then issues any credentials required by client application 401 on SP 403, such as using an API or other programmatic mechanism, thereby enabling the CA to obtain data (or other resources) from the SP.

[0046] The above process ensures that the service provider does not allow the data owner to be deceived into believing that the CA is a legitimate service. However, before the service provider issues the credential (step (7)), the service provider must also obtain the data owner's consent to process the owner's data. Access control (for example, as done in OIDC) can be used to obtain this consent.

[0047] exist Figure 5In an alternative embodiment shown, the client application 501 is unaware of the TPVS and first interacts with a service provider 503. To this end, at step (1a), the client application 501 attempts to register with the SP 503, for example using a predefined or configured registration process. The nature of the registration is outside the scope of this disclosure; a representative registration may involve simply presenting a client identifier and password. At step (1b), as part of its response to the client application, the SP 503 redirects the client application (e.g., via HTTP 302 redirect) to the TPVS that the client must then use. The rest of the process is exactly as described. Figure 4 , and proceeds as described above. Thus, in step (2) TPVS 505 creates an ABE user key with one or more attributes required to satisfy the SP's policy requirements. In step (3), TPVS 505 issues the ABE user key to the requesting client application 501. In step (4), the client presents the ABE user key to SP 503. In step (5), SP 503 attempts to decrypt the encrypted blob obtained by SP 503 during its registration with TPVS 505 using the user key and public parameters presented by the client. In step (6), if the user key combined with the public key parameters successfully decrypts the blob, SP 503 knows that the client application obtained credentials from TPVS that match the SP's policy, and therefore SP 503 can trust the client application. Therefore, assuming again that the service provider also has the necessary permissions to process the owner data, the process continues in step (7). At this step, the SP then issues any credentials required by the client application 501 on the SP 503, such as using an API or other programmatic mechanism, again enabling the CA to obtain data (or other resources) from the SP.

[0048] The technology of the present disclosure provides significant advantages. As described above, attribute-based encryption is used as a preferred mechanism for specifying trust between service providers that need to share client resources. The ABE described and used herein enables participating service providers to hide and verify the policies used to register clients into services provided by third parties. By encapsulating the specific details of a given policy within the encrypted payload itself, the policy itself is never returned to the requesting client application, although the client application can dynamically register with the target service provider (and thereafter interact with it). This approach enables the rules of the target service provider's policy to be completely hidden, while still enabling seamless and dynamic provisioning of client applications seeking to interoperate with the service provider.

[0049] In summary, the methods according to the present disclosure can be implemented as standalone methods, such as software-based functions executed by a processor, or they can be available as managed services (including as web services via SOAP / XML interfaces). The specific hardware and software implementation details described herein are for illustrative purposes only and are not meant to limit the scope of the described subject matter.

[0050] More generally, computing devices in the context of the disclosed subject matter are each a data processing system including hardware and software (such as a Figure 1 ), and these entities communicate with each other over a network, such as the Internet, an intranet, an extranet, a private network, or any other communication medium or link. The application on the data processing system provides native support for Web and other known services and protocols, including but not limited to support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL. Information about SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information about HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0051] Likewise Figure 1 As shown, the mechanisms described herein can be implemented in or in conjunction with a variety of server-side architectures, including simple n-tier architectures, portals, federated systems, etc. The techniques herein can also be practiced in whole or in part in loosely coupled server (including "cloud-based") environments.

[0052] More generally, the subject matter described herein can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment comprising both hardware and software elements. In a preferred embodiment, the functionality is implemented in software, which includes, but is not limited to, firmware, resident software, microcode, and the like. In addition, as described above, the analysis engine functionality can take the form of a computer program product accessible from a computer-usable or computer-readable medium, which provides program code used by or in conjunction with a computer or any instruction execution system. For the purposes of this specification, a computer-usable or computer-readable medium can be any device capable of including or storing a program used by or in conjunction with an instruction execution system, device, or apparatus. The medium can be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), hard disk, and optical disk. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W), and DVD. Computer-readable media are tangible items.

[0053] In a representative embodiment, the audit system and attribute-based encrypted registration and usage code are implemented in a dedicated computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with the one or more processors, and the software can be implemented as one or more computer programs. Collectively, this dedicated hardware and software comprise the system described above.

[0054] Although a particular order of operations performed by certain embodiments of the disclosed subject matter is described above, it will be understood that such an order is exemplary, as alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic.

[0055] Finally, although given components of the systems are described separately, those skilled in the art will appreciate that some functionality may be combined or shared in a given instruction, program sequence, code portion, and the like.

[0056] The methods herein can be implemented in key-policy-based ABE, in ciphertext-policy-based ABE, in any other ABE derivative, or in any similar cryptographic mechanism.

[0057] In a variant embodiment, the roles of the SP and CA may be reversed with respect to the above operation; in this case, the TPVS provides the binary object to the CA, while the SP receives the ABE user key. The decryption function works in the same manner as previously described.

[0058] The techniques herein provide improvements to another technology or technical area, namely, provider-to-provider admission and access control systems, and improvements to the operational capabilities of such systems when used in the manner described.

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

[0060] Having described the subject matter, what is claimed is as follows.

Claims

1. A method for enabling permitted access to protected resources associated with a service provider (SP), wherein: The granted access is defined by a security policy, the security policy including one or more rules defining registration requirements for obtaining credentials required for accessing the protected resource, the method comprising: receiving a binary object generated by an entity applying an attribute-based encryption (ABE) key to the one or more rules of the policy, the binary object being expressed as a Boolean predicate; receiving a request for the credential, the request having associated therewith an ABE user key, the ABE user key generated by the entity in accordance with 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 When it is determined that the binary object can be decrypted, the certificate is issued.

2. The method according to claim 1, wherein The request for the 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: receiving a request from the client application to access the protected resource; as well as Returning the protected resource to the client application.

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

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

7. The method of claim 6, further comprising determining that the service provider has permission from a resource owner to access the protected resource before issuing the credential.

8. An apparatus associated with a service provider (SP), comprising: processor; a computer memory storing computer program instructions executable by the processor to implement permitted access to a protected resource associated with the SP, wherein permitted access is defined by a security policy including one or more rules defining registration requirements for obtaining credentials required for accessing the protected resource, the computer program instructions comprising program code configured to: receiving a binary object generated by an entity applying an attribute-based encryption (ABE) key to the one or more rules of the policy, the binary object being expressed as a Boolean predicate; receiving a request for the credential, the request having associated therewith an ABE user key, the ABE user key generated by the entity in accordance with 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 When it is determined that the binary object can be decrypted, the certificate is issued.

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

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

11. The device according to claim 10, wherein The program code is also configured to: receiving a request from the client application to access the protected resource; and Returning the protected resource to the client application.

12. The device according to claim 8, wherein Said entity is a third-party review service.

13. The device according to claim 8, wherein The program code is also configured to: A root of trust is established to the entity, the root of trust being represented by the ABE master secret key and the set of one or more public parameters.

14. The device according to claim 13, wherein The program code is further configured to determine that the service provider has permission from a resource owner to access the protected resource before issuing the credential.

15. A computer program product in a non-transitory computer-readable medium storing computer program instructions executable by a processor in a host processing system associated with a service provider (SP) to enable permitted access to protected resources associated with the SP, wherein: The granted access is defined by a security policy, the security policy including one or more rules defining registration requirements for obtaining credentials required for accessing the protected resource, the computer program instructions comprising program code configured to: receiving a binary object generated by an entity applying an attribute-based encryption (ABE) key to the one or more rules of the policy, the binary object being expressed as a Boolean predicate; receiving a request for the credential, the request having associated therewith an ABE user key, the ABE user key generated by the entity in accordance with 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; as well as When it is determined that the binary object can be decrypted, the certificate is issued.

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

17. The computer program product of claim 16, wherein: The client application is associated with a second service provider.

18. The computer program product of claim 17, wherein: The program code is also configured to: receiving a request from the client application to access the protected resource; and Returning the protected resource to the client application.

19. The computer program product of claim 15, wherein: The program code is also configured to: A root of trust is established to the entity, the root of trust being represented by the ABE master secret key and the set of one or more public parameters.

20. The computer program product of claim 19, wherein: The program code is further configured to determine that the service provider has permission from a resource owner to access the protected resource before issuing the credential.

Images