Attribute-based cryptographic key as key material for keyed hash message authentication code user authentication and authorization

Abstract

Resource user authentication and authorization is provided, where an authentication code is generated based on using the obtained attribute-based encryption user key as a private key for a keyed-hash message authentication code digital signature on a set of header fields of a protected resource access request received from a client device of the resource user over a network. The generated authentication code is compared to an authentication code read within an embedded header field of the protected resource access request. It is determined whether a match exists between the generated authentication code and the authentication code read within the embedded header field. In response to determining that a match exists, the resource user is authenticated. In response to authenticating the resource user, decryption of an encrypted protected resource corresponding to the protected resource access request is performed using the obtained attribute-based encryption user key corresponding to the resource user.

Description

Technical Field

[0001] The present disclosure generally relates to user authentication and authorization, and more specifically, to using an attribute-based encrypted user key corresponding to a resource user as a secret key for a keyed hash message authentication code digital signature for a set of header fields of a protected resource access request made by the resource user for user authentication and authorization.

Background Art

[0002] User authentication and authorization are important components of network security. For example, authenticating a user's identity is the first step for controlling access to a secure user account by the user, executing secure transactions, accessing secure network resources, etc. Authentication means verifying the identity of the user, and authorization means granting permission to the user. That is, authentication is a process of verifying who the user is, and authorization is a process of verifying what the user can execute and access. Authorization is a function of specifying access rights or privileges to secure or protected resources and 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 an access request from an authenticated user to a protected resource is approved (i.e., access is permitted) or disapproved (i.e., access is denied). Protected resources can include, for example, data, files, documents, software applications and programs, storage, processors, memory, network resources, etc. that contain secret or confidential information. Logically, authentication precedes authorization.

[0003] Network security consists of access control policies employed to prevent and monitor unauthorized access, misuse, modification, or denial of protected resources accessible on the network. Typically, users choose or are assigned identifiers, such as usernames and passwords or other authentication credentials, which allow them to access protected resources accessible on the network within the user's privileges. For example, once authenticated, a firewall enforces access control policies that define which protected resources on the network each user can access. [Overview of the Initiative]

[0004] According to one exemplary embodiment, a computer implementation method for resource user authentication and authorization is provided. The computer generates an authentication code based on the use of an acquired attribute-based cryptographic user key as the secret key for a keyed hash message authentication code digital signature on a set of header fields of a protected resource access request received from a client device of a resource user over a network. The computer compares the generated authentication code with the authentication code read in the embedded header field of the protected resource access request. The computer determines whether a match exists between the generated authentication code and the authentication code read in the embedded header field. In response to the computer determining that a match exists between the generated authentication code and the authentication code read in the embedded header field, the computer authenticates the resource user. In response to the authentication of the resource user, the computer uses the acquired attribute-based cryptographic user key corresponding to the resource user to decrypt the encrypted and protected resource corresponding to the protected resource access request. According to another exemplary embodiment, a computer system and computer program product for resource user authentication and authorization are provided. [Brief explanation of the drawing]

[0005] [Figure 1] This is a diagram illustrating a network of a data processing system in which exemplary embodiments may be implemented. [Figure 2] This is a diagram of a data processing system in which exemplary embodiments may be implemented. [Figure 3] This diagram illustrates a cloud computing environment in which exemplary embodiments may be implemented. [Figure 4] This figure shows an example of an abstraction layer for a cloud computing environment according to an exemplary embodiment. [Figure 5] This figure shows an example of a protected resource access control system according to an exemplary embodiment. [Figure 6] This figure shows an example of a protected resource access request header according to an exemplary embodiment. [Figure 7] This figure shows an example of a protected resource access control process according to an exemplary embodiment. [Figure 8A] This is a flowchart showing the process of a resource server according to an exemplary embodiment. [Figure 8B] This is a flowchart showing the process of a resource server according to an exemplary embodiment. [Figure 9] This flowchart shows the processing of a client resource application according to an exemplary embodiment. [Modes for carrying out the invention]

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

[0007] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory stick, floppy disk, punch cards, or grooved raised structures, as well as mechanically encoded devices on which instructions are recorded, and suitable combinations thereof. Computer-readable storage devices as used herein should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0008] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network consists of copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on the computer-readable storage medium within each computing / processing device.

[0009] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++ and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions are executable as a standalone software package, either entirely on the user's computer or partially on the user's computer. Alternatively, they may be executable partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by personalizing them using state information of computer-readable program instructions in order to perform aspects of the present invention.

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

[0011] These computer-readable program instructions can be provided to a computer processor or other programmable data processing device to generate a machine, such that instructions executed via the processor of the computer or other programmable data processing device generate means for implementing functions / operations specified in one or more blocks of a flowchart or block diagram or both. These computer-readable program instructions can also be stored in a computer-readable storage medium that can be connected to a computer, a programmable data processing device, or other device or combination of devices that function in a particular way, such that the computer-readable program instructions on which the instructions are stored constitute one of the outputs containing instructions that implement a mode of function / operation specified in one or more blocks of a flowchart or block diagram or both.

[0012] Computer-readable program instructions, like instructions that perform a function / action specified in one or more blocks of a flowchart or block diagram or both on a computer, other programmable device, or other device, can also be loaded into a computer, other programmable data processing device, or other device and perform a series of operational steps on the computer, other programmable device, or other device to produce a computer-implemented process.

[0013] The flowcharts and block diagrams in the figures illustrate the configuration, function, and operation of executable implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction, which constitutes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions shown in the blocks may differ from the order shown in the figures. For example, two blocks shown consecutively may actually be achieved as a single step, executed simultaneously, substantially simultaneously, partially or entirely in overlapping time, or the blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram or flowchart diagram, or both, and any combination of blocks in a block diagram or flowchart diagram, or both, can be implemented by a special-purpose hardware-based system that performs a specified function or operation, or a combination of special-purpose hardware and computer instructions.

[0014] Referring here to the figures, and in particular to Figures 1-5, diagrams of data processing environments in which exemplary embodiments may be implemented are provided. It should be understood that Figures 1-5 are intended as examples only and are not intended to claim or imply any limitations regarding environments in which different embodiments may be implemented. Many modifications may be made to the depicted environments.

[0015] Figure 1 shows a diagram of a network of a data processing system in which an exemplary embodiment may be implemented. The network data processing system 100 is a network of computers, data processing systems, and other devices in which an exemplary embodiment may be implemented. The network data processing system 100 includes a network 102, which is a medium used to provide communication links between computers, data processing systems, and other devices connected together within the network data processing system 100. The network 102 may include connections such as wired communication links, wireless communication links, and fiber optic cables.

[0016] In the depicted example, servers 104 and 106 connect to network 102 along with storage 108. Servers 104 and 106 may be resource server computers having, for example, high-speed connectivity to network 102. Furthermore, servers 104 and 106 can provide access management services to client devices for protected resources 110. Protected resources 110 represent a set of protected resources hosted by servers 104 and 106. Protected resources 110 can represent any type of resource that is secure or protected from unauthorized user access. For example, protected resources 110 include at least one of restricted access data, files, documents, software applications and programs, processors, memory, storage, network resources, etc. Furthermore, protected resources 110 may be encrypted for enhanced security, or the metadata corresponding to protected resources 110 may be encrypted.

[0017] Furthermore, it should be noted that Server 104 and Server 106 may each represent multiple computing nodes in one or more cloud environments managed by a protected resource access management service provider. Alternatively, Server 104 and Server 106 may each represent a cluster of servers in one or more data centers hosting the service. In addition, Server 104 and Server 106 may provide information to client devices, such as applications, programs, software updates, software fixes, files, and data.

[0018] Clients 112, 114, and 116 also connect to network 102. Clients 112, 114, and 116 are client devices of servers 104 and 106. In this example, clients 112, 114, and 116 are shown as desktop or personal computers with wired communication links to network 102. However, it should be noted that clients 112, 114, and 116 are merely illustrative and could represent other types of data processing systems, such as laptop computers, handheld computers, smartphones, smartwatches, smart TVs, smart glasses, smart home appliances, and game consoles, with wired or wireless communication links to network 102. Users of clients 112, 114, and 116 can use clients 112, 114, and 116 to access and utilize the protected resources 110 when server 104 or server 106 or both authenticate the user and then determine whether the user is authorized to access the protected resources 110.

[0019] Storage 108 is a network storage device that can store any type of data in a structured format or an unstructured format. Further, storage 108 can represent a plurality of network storage devices. Further, storage 108 may store identifiers and network addresses of a plurality of different client devices, identifiers of a plurality of different resource users, access control policies for protected resources, and the like.

[0020] Note that the network data processing system 100 can further include any number of additional servers, clients, storage devices, and other devices not shown. The program code located in the network data processing system 100 is stored in a computer-readable storage medium and may be downloaded to a computer or other data processing device for use. For example, the program code may be stored in a computer-readable storage medium on server 104 and downloaded to client 112 via network 102 for use on client 112.

[0021] In the example depicted, the network data processing system 100 can be implemented as a number of different types of communication networks, such as, for example, the Internet, an intranet, a wide area network (WAN), a local area network (LAN), a telecommunications network, or any combination thereof. FIG. 1 is intended only as an illustration and is not intended as an architectural limitation for different exemplary embodiments.

[0022] As used herein, when used with respect to an item, "a number of" means one or more of the item. For example, "a number of different types of communication networks" means one or more different types of communication networks. Similarly, when used with respect to an item, "a set of" means one or more items.

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

[0024] For example, though not limited, "at least one of item A, item B, or item C" could include item A, item A and item B, or item B. This example could also include item A, item B, and item C, or item B and item C. Of course, any combination of these items is possible. In some exemplary examples, "at least one" could, for example, two items A, one item B, and ten items C, four items B and seven items C, or any other suitable combination.

[0025] Referring now to Figure 2, a diagram of a data processing system according to an exemplary embodiment is shown. The data processing system 200 is an example of a computer, such as the server 104 in Figure 1, and may contain computer-readable program code or instructions that implement the protected resource access management process of the exemplary embodiment. In this example, the data processing system 200 includes a processor unit 204, memory 206, persistent storage 208, a communication unit 210, an input / output (I / O) unit 212, and a communication fabric 202 that provides communication between the display 214.

[0026] The processor unit 204 is responsible for executing instructions for software applications and programs that can be loaded into memory 206. Depending on the specific implementation, the processor unit 204 may be a set of one or more hardware processor devices or a multi-core processor.

[0027] Memory 206 and persistent storage 208 are examples of storage devices 216. As used herein, a computer-readable storage device or computer-readable storage medium is any part of hardware that can store information, such as, for example, data, computer-readable program code in functional form, or other suitable information, or a combination thereof, on either a transient or persistent basis. Furthermore, computer-readable storage device or computer-readable storage medium excludes propagating media such as transient signals. In these examples, memory 206 may be, for example, random access memory (RAM), or any other suitable volatile or non-volatile storage device such as flash memory. Persistent storage 208 can take various forms depending on the particular implementation. For example, persistent storage 208 may include one or more devices. For example, persistent storage 208 may be a disk drive, a solid-state drive, a rewritable optical disk, a rewritable magnetic tape, or a combination of some of the above. The medium used by persistent storage 208 may be removable. For example, a removable hard drive may be used for persistent storage 208.

[0028] In this example, persistent storage 208 stores the protected resource access manager 218. However, it should be noted that, although the protected resource access manager 218 is illustrated to reside in persistent storage 208, in alternative exemplary embodiments, the protected resource access manager 218 may be another component of the data processing system 200. For example, the protected resource access manager 218 may be a hardware component coupled to the communication fabric 202, or a combination of hardware and software components. In another alternative exemplary embodiment, a first set of components of the protected resource access manager 218 may be located in the data processing system 200, and a second set of components of the protected resource access manager 218 may be located in a second data processing system, such as server 106 in Figure 1.

[0029] The protected resource access manager 218 controls resource user access to a set of protected resources, such as protected resource 110 in Figure 1. The protected resource access manager 218 uses an attribute-based cryptographic user key as a secret cryptographic key to generate a keyed hash message authentication code digital signature for a set of header fields of a protected resource access request made by a resource user requesting access to a specific protected resource within the set of protected resources. The protected resource access manager 218 compares the generated authentication code digital signature with the authentication code digital signature received in the embedded header field of the protected resource access request to authenticate the resource user. When authenticating the resource user by determining that a match exists between the authentication code digital signatures, the protected resource access manager 218 uses the same attribute-based cryptographic user key used to generate the authentication code digital signature received in the embedded header field of the protected resource access request to decrypt the requested protected resource or the metadata corresponding to the requested protected resource. If decryption is successful using the specific attribute-based encryption user key, the protected resource access manager 218 determines that the resource user has the right to access that particular protected resource and grants access.

[0030] As a result, the data processing system 200 operates as a special-purpose computer system in which the protected resource access manager 218 within the data processing system 200 enables improved access control and security levels for protected resources on the network. In particular, the protected resource access manager 218 transforms the data processing system 200 into a special-purpose computer system compared to a currently available general-purpose computer system that does not have the protected resource access manager 218.

[0031] In this example, the communication unit 210 provides communication with other computers, data processing systems, and devices via a network such as network 102 in Figure 1. The communication unit 210 can provide communication through the use of both physical communication links and wireless communication links. Physical communication links can utilize, for example, wires, cables, universal serial buses, or any other physical technology to establish a physical communication link with the data processing system 200. Wireless communication links can be established using, for example, shortwave, radio frequency, ultra-high frequency, microwave, Wireless Fidelity (Wi-Fi), Bluetooth® technology, GSM, Code Division Multiple Access (CDMA), 2G, 3G, 4G, 4G Long-Term Evolution (LTE), LTE Advanced, 5G, or any other wireless communication technology or standard to establish a wireless communication link with the data processing system 200.

[0032] The input / output unit 212 enables the input and output of data to and from other devices that may be connected to the data processing system 200. For example, the input / output unit 212 may provide a connection for user input via a keypad, keyboard, mouse, microphone, or any other suitable input device, or a combination thereof. The display 214 provides a mechanism for displaying information to the user and may include, for example, a touchscreen function to allow the user to make selections on the screen via a user interface or input data.

[0033] Instructions for an operating system, application, or program, or a combination thereof, may be located in a storage device 216 that communicates with the processor unit 204 via a communication fabric 202. In this exemplary example, the instructions are in a functional form on persistent storage 208. These instructions may be loaded into memory 206 for execution by the processor unit 204. Processes in different embodiments may be executed by the processor unit 204 using computer-implemented instructions that may be located in memory, such as memory 206. These program instructions are referred to as program code, computer-readable program code, or computer-readable program code that can be read and executed by a processor within the processor unit 204. In different embodiments, program instructions may be implemented on different physical computer-readable storage devices, such as memory 206 or persistent storage 208.

[0034] The program code 220 is selectively removable and is functionally arranged on a computer-readable medium 222 that can be loaded or transferred to a data processing system 200 for execution by a processor unit 204. The program code 220 and the computer-readable medium 222 form a computer program product 224. In one example, the computer-readable medium 222 may be a computer-readable storage medium 226 or a computer-readable signaling medium 228.

[0035] In these exemplary examples, the computer-readable storage medium 226 is not a medium for propagating or transmitting the program code 220, but rather a physical or tangible storage device used to store the program code 220. The computer-readable storage medium 226 may include, for example, an optical or magnetic disk inserted into or placed in a drive or other device that is part of the persistent storage 208 for transfer onto a storage device such as a hard drive that is part of the persistent storage 208. The computer-readable storage medium 226 may also take the form of persistent storage such as a hard drive, thumb drive, or flash memory connected to the data processing system 200.

[0036] Alternatively, the program code 220 may be transferred to the data processing system 200 using a computer-readable signal medium 228. The computer-readable signal medium 228 may be, for example, a propagating data signal containing the program code 220. For example, the computer-readable signal medium 228 may be an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted via a communication link, such as a wireless communication link, an optical fiber cable, a coaxial cable, a wire, or any other suitable type of communication link.

[0037] Furthermore, as used herein, “computer-readable medium 222” can be singular or plural. For example, program code 220 may be placed on computer-readable medium 222 in the form of a single storage device or system. In another example, program code 220 may be placed on computer-readable medium 222 distributed across multiple data processing systems. In other words, some instructions of program code 220 may be placed on one data processing system, while other instructions of program code 220 may be placed on one or more other data processing systems. For example, some of program code 220 may be placed on computer-readable medium 222 in a server computer, while other parts of program code 220 may be placed on computer-readable medium 222 distributed across a set of client computers.

[0038] The different components illustrated for the data processing system 200 do not imply any architectural limitations on how different embodiments may be implemented. In some exemplary examples, one or more components may be incorporated into or form part of another component. For example, memory 206, or part thereof, may be incorporated into processor unit 204 in some exemplary examples. Different exemplary embodiments may be implemented in a data processing system that includes components in addition to, or instead of, those illustrated for the data processing system 200. Other components shown in Figure 2 may be modified from the illustrated exemplary examples. Different embodiments may be implemented using any hardware device or system capable of executing program code 220.

[0039] In another example, a bus system could be used to implement the communication fabric 202, which could consist of one or more buses, such as a system bus or input / output buses. Of course, the bus system may be implemented using any suitable type of architecture that provides data transfer between different components or devices connected to the bus system.

[0040] This disclosure includes a detailed description of cloud computing, but the implementations of the teachings described herein are not limited to cloud computing environments. Rather, the embodiments described can be implemented with any other type of computer environment that is currently known or may be developed in the future. Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or minimal interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four implementation models.

[0041] These characteristics may include, for example, on-demand self-service, broad network access, resource pooling, rapid flexibility, and measurable services. On-demand self-service allows cloud consumers to unilaterally prepare computing power, such as server time and network storage, automatically as needed, without requiring human interaction with the service provider. Broad network access provides computing power that is available over the network and accessible through standard mechanisms, thereby facilitating use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, personal digital assistants). Resource pooling allows a provider's computing resources to be pooled and delivered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated as needed. Generally, consumers have a sense of location independence because they do not manage or know the exact location of the resources provided. However, consumers may be able to pinpoint the location at a higher level of abstraction (e.g., country, state, data center). Rapid elasticity provides computing power that can be prepared quickly and flexibly, sometimes automatically, instantly scaling out and rapidly releasing and instantly scaling in. To consumers, the computing power available for preparation often appears unlimited and can be purchased in any quantity at any time. Measurable services enable cloud systems to automatically control and optimize resource usage by leveraging metric capabilities at a certain level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both service providers and consumers.

[0042] Service models can include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Software as a Service is the functionality provided to consumers to use a provider's applications running on cloud infrastructure. These applications can be accessed from various client devices via thin client interfaces such as web browsers (e.g., webmail). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for configuring limited user-specific application configurations. Platform as a Service is the functionality provided to consumers to deploy applications they have created or acquired using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, and storage, but they can control the deployed applications and, in some cases, the configuration of their hosting environment. Infrastructure as a Service is the functionality provided to consumers to prepare processors, storage, networks, and other basic computing resources that enable consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they can control the operating system, storage, and deployed applications, and in some cases, partially control certain network components (e.g., host firewalls).

[0043] Deployment models can include, for example, private cloud, community cloud, public cloud, and hybrid cloud. A private cloud is a cloud infrastructure operated exclusively for a specific organization. A private cloud can be managed by that organization or a third party and can reside on-premises or off-premises. A community cloud is a cloud infrastructure shared by multiple organizations that supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance). A community cloud can be managed by that organization or a third party and can reside on-premises or off-premises. A public cloud is a cloud infrastructure provided to a large number of people or large industry groups and owned by an organization that sells cloud services. A hybrid cloud is a cloud infrastructure that combines two or more cloud models (private, community, or public). It retains the unique entities of each model but is bound by standards or individual technologies to achieve data and application portability (e.g., cloud bursting for load balancing between clouds).

[0044] Cloud computing environments are service-oriented environments that emphasize statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0045] Referring now to Figure 3, a diagram illustrating a cloud computing environment in which an exemplary embodiment may be implemented is shown. In this exemplary example, the cloud computing environment 300 includes one or more cloud computing nodes 310. Local computer devices used by cloud consumers (e.g., a personal digital assistant or mobile phone 320A, a desktop computer 320B, a laptop computer 320C, or an automotive computer system 320N, or a combination thereof) can communicate with these nodes. The cloud computing nodes 310 may be, for example, servers 104 and 106 in Figure 1. The local computer devices 320A to 320N may be, for example, clients 112 to 116 in Figure 1.

[0046] The cloud computing nodes 310 can communicate with each other and can be grouped physically or virtually in one or more networks, such as the private, community, public, or hybrid clouds or a combination thereof. This allows the cloud computing environment 300 to provide infrastructure, platforms, or software as a service, or a combination thereof, without requiring cloud consumers to maintain resources on local computer devices such as local computer devices 320A to 320N. Note that the types of local computer devices 320A to 320N are merely examples, and it should be understood that the cloud computing nodes 310 and the cloud computing environment 300 can communicate with any type of electronic device via any type of network or network addressable connection (e.g., using a web browser) or both.

[0047] Referring to Figure 4, an exemplary abstraction model layer according to an exemplary embodiment is shown. The set of functional abstraction layers shown in this exemplary example may be provided by a cloud computing environment such as the cloud computing environment 300 in Figure 3. It should be understood in advance that the components, layers, and functions shown in Figure 4 are illustrative only, and embodiments of the present invention are not limited to these. As illustrated, the following layers and corresponding functions are provided.

[0048] The abstraction layer 400 of the cloud computing environment includes the hardware and software layer 402, the virtualization layer 404, the management layer 406, and the workload layer 408. The hardware and software layer 402 includes the hardware and software components of the cloud computing environment. Examples of hardware components include the mainframe 410, the reduced instruction set computer (RISC) architecture-based server 412, server 414, blade server 416, storage 418, and the network and network components 420. In some exemplary embodiments, the software components include network application server software 422 and database software 424.

[0049] The virtualization layer 404 provides an abstraction layer. From this layer, for example, the following virtual entities can be provided: a virtual server 426, virtual storage 428, a virtual network 430 including a virtual private network, a virtual application and operating system 432, and a virtual client 434.

[0050] As an example, the management layer 406 can provide the following functions: Resource preparation 436 enables the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 438 enables cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. As an example, these resources may include licenses for application software. Security enables not only protection of data and other resources but also identification and verification of cloud consumers and tasks. The user portal 440 provides consumers and system administrators with access to the cloud computing environment. Service level management 442 enables the allocation and management of cloud computing resources to ensure that requested service levels are met. Service Level Agreement (SLA) planning and execution 444 enables the pre-arrangement and procurement of cloud computing resources that are expected to be needed in the future in accordance with the SLA.

[0051] Workload layer 408 provides examples of the capabilities available to the cloud computing environment. Examples of workloads and capabilities available from workload layer 408 include mapping and navigation 446, software development and lifecycle management 448, virtual classroom education delivery 450, data analytics processing 452, transaction processing 454, and protected resource access management 456.

[0052] Numerous computer systems exist on today's internet that share protected resources, such as confidential data, between service providers and customers (i.e., resource users). One of the challenging problems in this provider / customer model is user authentication and authorization. There are many ways to implement user authentication and authorization. However, some newer methods enable implementations that protect access control policies by encrypting the access control policies along with the protected data using functional encryption.

[0053] One of these new methods is attribute-based encryption, where protected data is encrypted and made available to any user. The implementation relies on the cryptographic strength of an algorithm that obfuscates the encrypted protected data and Boolean predicates (e.g., access control policies) within the ciphertext as protection against unauthorized user access to the protected data. Attribute-based encryption is a type of public-key cryptography where the user's secret encryption key and ciphertext depend on user attributes, such as the user's geographical location, job title, job responsibilities, resource group to which the user belongs, and security level. In attribute-based encryption, decryption of the ciphertext is only possible if the user key's attribute set 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.

[0054] However, much of the network security industry demands more control over protected resources, even in encrypted form. In their view, protected resources, whether encrypted or not, should be inaccessible to anyone who is not authorized to access and use that particular protected resource. An exemplary embodiment would ensure that protected resources are inaccessible to anyone who is not authorized to use those protected resources.

[0055] To prevent unauthorized users from accessing protected resources in any form, resource users are required to present credentials to the resource server hosting those protected resources. Specifically, users must present credentials that prove they are granted the right to access certain protected resources. The need to prove that resource users are authorized to access and use given protected resources presents many challenges. An exemplary embodiment considers and addresses how to securely present resource user credentials to a resource server in order to control access to protected resources on a network.

[0056] For example, consider the many existing authentication methods used in the past, such as basic authentication and OAuth. These existing authentication methods require the user's credentials to be passed over the network in order to initiate a network session. As a result, these existing authentication methods expose the user's credentials to the network every time a network session is initiated by the user.

[0057] However, to protect this credential exchange over the network, numerous other methods have been developed, such as Transport Layer Security. In systems that use attribute-based encryption for access control, a user can simply pass on a user key in one of several different ways, and a resource server attempts to use that user key to unlock a particular protected resource. If the resource server is able to unlock (e.g., decrypt) the protected resource using that particular user key, the resource server can know that the user possesses the credentials to grant access to that particular protected resource. However, attribute-based encryption has a major drawback. With attribute-based encryption, the user key is exposed to the network for each network session. For example, if the Transport Layer Security protocol fails, the user key will be exposed to the network and could subsequently be exploited by an unauthorized user.

[0058] Other existing methods for proving that a resource user possesses credentials to access a protected resource do not require the protected resource to be passed over the network at the start of a network session. One such method is keyed hash message authentication code. Keyed hash message authentication code (also called hash-based message authentication code) is a specific type of message authentication code that involves a cryptographic hash function and a secret cryptographic key. Keyed hash message authentication code can be used to simultaneously verify the integrity and authenticity of the data in a message. Any cryptographic hash function can be used to compute a keyed hash message authentication code, such as Secure Hash Algorithm 2 or Secure Hash Algorithm 3. Keyed hash message authentication code allows a resource server, which also possesses the secret key, to detect any changes to the message content. In other words, a keyed hash message authentication code provides a resource server hosting one or more protected resources with a means to verify whether a resource user possesses credentials (i.e., a user key) by having the resource application corresponding to the resource user compute a keyed hash message authentication code for a set of network header fields in a protected resource access request and including that keyed hash message authentication code (i.e., an encrypted digital signature) in an embedded field within the header of the protected resource access request.

[0059] When a resource server receives a protected resource access request from a resource user, it can use the same user key as the resource user's resource application to compute the same keyed hash message authentication code for the same set of header fields in the protected resource access request. If the two keyed hash message authentication codes (i.e., cryptographic digital signatures) match, the resource server cryptographically proves that the user possesses the user key (i.e., has valid user credentials) and grants access to the protected resource.

[0060] Therefore, the exemplary embodiment utilizes the attribute-based cryptographic user key as the secret key for the keyed hash message authentication code encrypted digital signature against the same set of header fields of the protected resource access request to prove to the resource server that the resource user possesses a pre-shared attribute-based cryptographic user key. Note that the exemplary embodiment can utilize any form of attribute-based cryptography, such as keyed policy attribute-based cryptography or ciphertext policy attribute-based cryptography.

[0061] An exemplary embodiment issues an attribute-based cryptographic user key to a resource user, along with a unique user key identifier corresponding to that particular user key, out of band. The exemplary embodiment also provides the same attribute-based cryptographic user key and unique user key identifier on the resource server. Note that the exemplary embodiment may utilize any type of out-of-band cryptographic key sharing technique. Out-of-band cryptographic key sharing occurs when the cryptographic secret key is delivered by means that are inaccessible from within the network in which the cryptographic secret key is used. In other words, out-of-band cryptographic key sharing means sending the cryptographic secret key by means of communication separate from the means of communication used to exchange ciphertext.

[0062] In an exemplary embodiment, after sharing an attribute-based encryption user key and a corresponding unique user key identifier with the resource user and the resource server, the exemplary embodiment uses standard attribute-based encryption capabilities to encrypt the protected resource or resource metadata along with the access control policy embedded in the ciphertext and located on the resource server. When the resource server authenticates (i.e., verifies) the user corresponding to the protected resource access request using a keyed hash message authentication code, the resource server attempts to decrypt the protected resource or the metadata corresponding to the protected resource using the corresponding attribute-based encryption user key. If decryption is successful using that attribute-based encryption user key, the resource server can know that the user who requested access to the protected resource possesses an attribute-based encryption user key that grants the user permission to access that particular protected resource.

[0063] Accordingly, the exemplary embodiments provide one or more technical solutions that overcome the technical problem of securely presenting resource user credentials to a resource server to control access to protected resources on a network. As a result, these one or more technical solutions provide technical benefits and practical applications in the field of network security.

[0064] Referring now to Figure 5, a diagram is shown illustrating an example of a protected resource access control system according to an exemplary embodiment. The protected resource access control system 500 may be implemented in a network of data processing systems, such as the network data processing system 100 in Figure 1, or in a cloud computing environment, such as the cloud computing environment 300 in Figure 3. The protected resource access control system 500 is a system of hardware and software components for controlling access to protected resources 502. Protected resources 502 represent a set of protected resources, which may be, for example, protected resources 110 in Figure 1.

[0065] In this example, the protected resource access control system 500 includes a resource server 504 and a client device 506. The resource server 504 may be, for example, the server 104 in Figure 1, the data processing system 200 in Figure 2, or the cloud computing node 310 in Figure 3. The client device 506 may be, for example, the client 112 in Figure 1, or the local computer device 320B in Figure 3. However, it should be noted that the protected resource access control system 500 is intended to be illustrative only and not intended to be a limitation of exemplary embodiments. In other words, the protected resource access control system 500 may include any number of protected resources, resource servers, client devices, and other devices and components not shown.

[0066] The user key provisioning system 500 also illustrates a set of possible provisioning entities and a workflow that enables keyed hash message authentication codes that allow controlled and protected resource access using attribute-based encrypted user keys. However, it should be noted that the exemplary embodiment in Figure 5 is not intended to illustrate all ways in which user key sharing is possible. In other words, alternative exemplary embodiments may utilize other user key sharing methodologies.

[0067] In this example, the resource server 504 includes a protected resource access manager 505, such as the protected resource access manager 218 in Figure 2. The protected resource access manager 505 controls user access to the protected resources 502 hosted by the resource server 504. The client device 506 includes a client resource application 507. A resource user 508 uses the client resource application 507 to access and utilize one or more of the protected resources 502.

[0068] Resource administrator 510 is responsible for administratively managing access to protected resource 502. In 512, resource administrator 510 creates access control policy definitions that define which resource users or groups of resource users can access which specific protected resources of protected resource 502. Furthermore, resource administrator 510 encrypts protected resource 502 or the metadata corresponding to protected resource 502 using one of the attribute-based encryption protocols to securely control access to protected resource 502. Furthermore, in 514, resource administrator 510 generates an attribute-based encryption user key for resource user 508, which resource user 508 uses to access one or more protected resources 502. Furthermore, resource administrator 510 generates a unique user key identifier that uniquely identifies the attribute-based encryption user key corresponding to resource user 508.

[0069] The resource administrator 510 sends the attribute-based encrypted user key and unique user key identifier corresponding to the resource user 508 to the authentication and user key provisioning service 516. Also, at 518, the resource administrator 510 prepares the attribute-based encrypted user key and unique user key identifier in the key store 520 of the protected resource access manager 505 on the resource server 504 in order to verify the keyed hash message authentication code digital signature embedded in the header field of the protected resource access request.

[0070] In step 522, resource user 508 requests an attribute-based encrypted user key and a unique user key identifier from authentication and user key provisioning service 516. In step 524, in response to receiving the request, authentication and user key provisioning service 516 sends the attribute-based encrypted user key and a unique user key identifier to resource user 508 out of band. In step 526, resource user 508 prepares the attribute-based encrypted user key and a unique user key identifier in the key store 528 of the client resource application 507 on client device 506.

[0071] In step 530, the resource user 508 inputs a protected resource access request to the client resource application 507, requesting access to one or more of the protected resources 502. In response to receiving the input of the protected resource access request, the client resource application 507 uses the attribute-based cryptographic user key and unique user key identifier prepared in the key store 528 to generate a protected resource access request that includes a keyed hash message authentication code and a unique user key identifier. In step 532, the client resource application 507 sends the protected resource access request, including the keyed hash message authentication code and a unique key identifier, to the resource server 504.

[0072] Subsequently, the protected resource access manager 505 of the resource server 504 uses a unique user key identifier included in the protected resource access request to retrieve a pre-shared attribute-based cryptographic user key from the protected resource access manager 505's key store 520. The protected resource access manager 505 uses that attribute-based cryptographic user key retrieved from the key store 520 to generate its own keyed hash message authentication code for the same set of header fields in the protected resource access request. The protected resource access manager 505 then compares the keyed hash message authentication code generated by the protected resource access manager 505 with the keyed hash message authentication code included in the protected resource access request sent by the client resource application 507.

[0073] If the keyed hash message authentication codes do not match, the protected resource access manager 505 denies resource user 508 access to one or more requested protected resources of protected resource 502. If both keyed hash message authentication codes match, the protected resource access manager 505 authenticates resource user 508. After the protected resource access manager 505 authenticates resource user 508, the protected resource access manager 505 attempts to decrypt one or more protected resources of protected resource 502 corresponding to resource user 508's protected resource access request using an attribute-based cryptographic user key. If the protected resource access manager 505 can decrypt one or more protected resources using the attribute-based cryptographic user key, the protected resource access manager 505 determines that resource user 508 is permitted to access one or more protected resources and grants access. If the protected resource access manager 505 is unable to decrypt one or more protected resources, the protected resource access manager 505 determines that the resource user 508 is not authorized to access those one or more protected resources and denies access.

[0074] Referring now to Figure 6, a diagram is shown illustrating an example of a protected resource access request header according to an exemplary embodiment. The protected resource access request header 600 shows embedded fields of a protected resource access request that a protected resource access manager, such as the protected resource access manager 218 in Figure 2 or the protected resource access manager 505 in Figure 5, reads in order to obtain an attribute-based cryptographic user key 602 and generate a keyed hash message authentication code digital signature 604 on a set of header fields that do not include the authentication code and digital signature of the protected resource access request.

[0075] However, it should be noted that the protected resource access request header 600 is intended for illustrative purposes only. In other words, the protected resource access request header 600 does not illustrate all header fields, such as fields that suppress malicious user behavior (e.g., replay attacks). This set of other header fields not illustrated does not adversely affect the functionality of the protected resource access manager in the exemplary embodiment. In addition to the embedded header fields, this set of other header fields is implied by the dotted line below the user key identifier field 606. Furthermore, the names of the header fields are not important; only the content of the fields matters.

[0076] The protected resource access manager obtains the attribute-based encrypted user key 602 using the unique identifier 608 contained in the user key identifier field 606. The attribute-based encrypted user key 602 corresponds to the resource user making the protected resource access request (e.g., resource user 508 in Figure 5) and is prepared by a resource administrator, such as resource administrator 510 in Figure 5, in a key store, such as the key store 520 in Figure 5 of the protected resource access manager. The unique identifier 608 uniquely identifies the attribute-based encrypted user key 602 in the key store. To authenticate the resource user, the protected resource access manager compares the generated keyed hash message authentication code digital signature 604 with a Base64 encoded byte array 610 having the digital signature contained in the authentication code field 612.

[0077] Referring now to Figure 7, a diagram is shown illustrating an example of a protected resource access control process according to an exemplary embodiment. The protected resource access control process 700 includes a resource server 702 and a client resource application 704. The resource server 702 may be, for example, the resource server 504 in Figure 5. The client resource application 704 may be, for example, the client resource application 507 loaded on the client device 506 in Figure 5.

[0078] The protected resource access control process 700 is initiated when a resource user, such as resource user 508 in Figure 5, prepares an attribute-based encrypted user key and a unique user key identifier in a key store of the client resource application 704, such as key store 528 in Figure 5. Subsequently, the client resource application 704 receives a protected resource access request from a resource user requesting access to a protected resource hosted by the resource server 702. In response, 706, the client resource application 704 embeds the user key identifier field and the authentication code field into the header of the protected resource access request, such as the user key identifier field 606 and the authentication code field 612 embedded in the protected resource access request header 600 in Figure 6.

[0079] Furthermore, in 708, the client resource application 704 retrieves the attribute-based encryption key and the unique user key identifier from the client resource application 704's key store. In 710, the client resource application 704 generates an authentication code based on the use of the attribute-based encryption key as the secret key for the keyed hash message authentication code digital signature for the set of header fields of the protected resource access request. The client resource application 704 then inserts the authentication code into the authentication code field of the protected resource access request header and the unique user key identifier into the user key identifier field. Note that in an alternative exemplary embodiment, the unique user key identifier may also be placed in the digitally signed header field. This would protect the unique user key identifier and cause the authentication code to fail if the unique user key identifier is not included in the header field that is not digitally signed. In 712, the client resource application 704 sends the protected resource access request containing the authentication code and the unique user key identifier to the resource server 702.

[0080] In 714, in response to the resource server 702 receiving a protected resource access request, the resource server 702 scans the header fields to find a unique user key identifier corresponding to the attribute-based cryptographic user key. In 716, the resource server 702 uses the unique user key identifier to retrieve the pre-shared attribute-based cryptographic user key from the resource server 702's key storage, such as the key storage 520 in Figure 5. In 718, the resource server 702 uses the pre-shared attribute-based cryptographic user key as the secret key for its own key hash message authentication code digital signature against the same set of header fields of the protected resource access request that the client resource application 704 used to generate its authentication code.

[0081] In step 720, the resource server 702 compares the authentication code generated by the resource server 702 with the authentication code read from the header field of the protected resource access request sent by the client resource application 704. If the authentication codes match, the resource server 702 learns that the resource user possesses the same attribute-based cryptographic user key stored in the resource server 702's key store. After the resource server 702 authenticates the resource user by determining that the authentication codes match, in step 722, the resource server 702 attempts to decrypt the protected resource or protected resource metadata corresponding to the protected resource access request using the attribute-based cryptographic user key. If the resource server 702 is able to decrypt the protected resource or protected resource metadata, the resource server 702 learns that the resource user is authorized to access the protected resource and is granted access in step 724.

[0082] It should be noted that the protected resource access control process 700 prevents attribute-based encrypted user keys from being exposed to the network and provides the resource server 702 with means to authorize the use of protected resources. The protected resource access control process 700 may also provide means to control protected resource access, which includes both authorization for downloading and encryption for viewing.

[0083] Referring here to Figures 8A-8B, flowcharts illustrating the processes of a resource server according to an exemplary embodiment are shown. The processes shown in Figures 8A-8B can be implemented in computers such as, for example, the server 104 in Figure 1, the data processing system 200 in Figure 2, the cloud computing node 310 in Figure 3, or the resource server 504 in Figure 5. For example, the processes shown in Figures 8A-8B can be implemented in the protected resource access manager 218 in Figure 2 or Figure 2. 5 Protected Resource Access Manager505 It can be implemented in [location].

[0084] The process begins when the computer receives a protected resource access request over the network from a client resource application on a client device corresponding to a resource user, which has a header field containing an authentication code and a user key identifier (step 802). The protected resource access request requests access to an encrypted and protected resource hosted by the computer. In response to receiving the protected resource access request, the computer reads the header field containing the authentication code and user key identifier within the protected resource access request (step 804).

[0085] The computer then uses the user key identifier read in the header field of the protected resource access request to retrieve the attribute-based cryptographic user key corresponding to the resource user from the computer's key store (step 806). Furthermore, the computer generates an authentication code based on the use of the retrieved attribute-based cryptographic user key as the secret key for the keyed hash message authentication code digital signature for the header field of the protected resource access request (step 808). The computer compares the generated authentication code with the authentication code read in the header field of the protected resource access request (step 810).

[0086] The computer then determines whether there is a match between the generated authentication code and the authentication code read in the header field (step 812). If the computer determines that there is no match between the generated authentication code and the authentication code read in the header field, it outputs NO in step 812, and the computer does not authenticate the resource user and denies the resource user access to the encrypted and protected resource (step 814). The process then terminates. If the computer determines that there is a match between the generated authentication code and the authentication code read in the header field, it outputs YES in step 812, and the computer then authenticates the resource user (step 816).

[0087] Subsequently, the computer, in response to the authentication of the resource user, performs decryption of the encrypted and protected resource using the retrieved attribute-based encryption user key corresponding to the resource user (step 818). The computer determines whether the decryption of the encrypted and protected resource was successful in order to form the decrypted and protected resource using the retrieved attribute-based encryption user key (step 820). If the computer determines that the decryption of the encrypted and protected resource using the retrieved attribute-based encryption user key failed, it outputs NO in step 820, and the process returns to step 814, where the computer determines that the resource user is not authorized and denies the resource user access to the encrypted and protected resource. If the computer determines that the decryption of the encrypted and protected resource was successful in forming the decrypted and protected resource using the retrieved attribute-based encryption user key, it outputs YES in step 820, where the computer determines that the resource user is authorized and grants the resource user access to the decrypted and protected resource (step 822). The process then terminates.

[0088] Referring now to Figure 9, a flowchart is shown illustrating the process of a client resource application according to an exemplary embodiment. The process shown in Figure 9 is, for example, the client resource application in Figure 5. 507 Alternatively, it may be implemented in a client resource application such as the client resource application 704 in Figure 7. The client resource application is, for example, in Figure 1 Client 112 or the local computer device in Figure 3 320A This may be implemented in a client device such as the following.

[0089] The process begins when the client device receives input from the resource user to prepare the attribute-based encryption user key and user key identifier in the keystore of the client resource application loaded onto the client device corresponding to the resource user (step 902). The attribute-based encryption user key corresponds to the resource user, and the user key identifier uniquely identifies the attribute-based encryption user key.

[0090] Subsequently, the client device receives input from the resource user to send a protected resource access request requesting access to a protected resource hosted by the resource server, using the client resource application (step 904). In response to receiving the input to send the protected resource access request, the client device uses the client resource application to embed the authentication code field and the user key identifier field into the header fields of the protected resource access request (step 906). Furthermore, the client device uses the client resource application to retrieve the attribute-based cryptographic user key and user key identifier from the client resource application's key store (step 908).

[0091] Subsequently, the client device uses the client resource application to generate an authentication code based on the use of the acquired attribute-based cryptographic user key as the secret key for the keyed hash message authentication code digital signature in the header field of the protected resource access request (step 910). Furthermore, the client device uses the client resource application to insert the generated authentication code into the authentication code field and the user key identifier into the user key identifier field embedded in the header field of the protected resource access request (step 912).

[0092] The client device uses the client resource application to send a protected resource access request, including the generated authentication code and user key identifier, to the resource server over the network and access the protected resource hosted by the resource server (step 914). The client device then uses the client resource application to receive a response from the resource server regarding whether access to the protected resource is permitted or denied (step 916). The process then terminates.

[0093] Accordingly, exemplary embodiments of the present invention provide computer implementations, computer systems, and computer program products for using attribute-based cryptographic user keys corresponding to resource users as secret keys for keyed hash message authentication code digital signatures on a set of header fields of protected resource access requests made by resource users for user authentication and authorization. The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or to limit the embodiments disclosed. It will be apparent to those skilled in the art that many modifications and changes are possible without departing from the scope of the embodiments described. The terms used herein have been selected to best describe the principles of the embodiments, their actual application to the technology found in the market or technical improvements, or to enable those skilled in the art to understand the embodiments described herein.

Claims

1. A computer implementation method for resource user authentication and authorization, wherein the computer implementation method is The computer generates an authentication code based on the use of an acquired attribute-based cryptographic user key as the secret key for a keyed hash message authentication code digital signature on a set of header fields of a protected resource access request received from a resource user's client device over the network, The computer compares the generated authentication code with the authentication code read in the embedded header field of the protected resource access request. The computer determines whether there is a match between the generated authentication code and the authentication code read in the embedded header field. In response to the computer determining that there is a match between the generated authentication code and the authentication code read in the embedded header field, the computer authenticates the resource user. The computer, in response to authentication of the resource user, decrypts the encrypted and protected resource corresponding to the protected resource access request using the acquired attribute-based encryption user key corresponding to the resource user. Using the attribute-based encryption user key obtained, the computer determines whether the decryption of the encrypted and protected resource was successful in order to form a decrypted and protected resource. Using the attribute-based encryption user key obtained, in order to form a decrypted and protected resource, the computer determines that the decryption of the encrypted and protected resource has been successful, and in response, the computer determines that the resource user has the right to access the decrypted and protected resource and grants access; In response to the computer determining that the decryption of the encrypted and protected resource has failed using the attribute-based encryption user key obtained, the computer determines that the resource user does not have permission to access the encrypted and protected resource and denies access. Computer implementation methods including

2. The computer receives the protected resource access request, which includes the set of header fields, an embedded authentication code field containing the authentication code, and an embedded user key identifier field containing the user key identifier, from the client device corresponding to the resource user via the network, The computer reads, in the protected resource access request, the embedded authentication code field containing the authentication code and the embedded user key identifier field containing the user key identifier. The computer retrieves an attribute-based encryption user key from its key store in order to form the retrieved attribute-based encryption user key using the user key identifier read in the embedded user key identifier field of the protected resource access request, wherein the user key identifier uniquely identifies the attribute-based encryption user key in the key store. The computer implementation method according to claim 1, further comprising:

3. The client resource application of the client device embeds the embedded authentication code field and the embedded user key identifier field into the protected resource access request, in addition to the set of header fields; the client resource application inserts the authentication code into the embedded authentication code field and the user key identifier into the embedded user key identifier field before sending the protected resource access request to the computer; and the client resource application utilizes the encrypted and protected resource after the computer has successfully decrypted it. The computer implementation method according to claim 2.

4. The computer implementation method according to claim 1, wherein the protected resource access request requests access to the encrypted and protected resource hosted by the computer.

5. The computer implementation method according to claim 1, wherein the acquired attribute-based encryption user key corresponds to the resource user.

6. In response to the computer determining that there is no match between the generated authentication code and the authentication code read in the embedded header field, the computer determines that the resource user is not authenticated and denies the resource user access to the encrypted and protected resource. The computer implementation method according to claim 1, further comprising:

7. A computer system for resource user authentication and authorization, wherein the computer system is Bus system and, A storage device connected to the bus system, wherein the storage device stores program instructions, The bus system includes a processor connected to the bus system, and the processor is The process involves generating an authentication code based on using the acquired attribute-based cryptographic user key as the secret key for the digital signature of the keyed hash message authentication code against a set of header fields of a protected resource access request received from the resource user's client device via the network, and The generated authentication code is compared with the authentication code read in the embedded header field of the protected resource access request. The process involves determining whether there is a match between the generated authentication code and the authentication code read within the embedded header field. In response to determining that a match exists between the generated authentication code and the authentication code read in the embedded header field, the resource user is authenticated. In response to the authentication of the resource user, the system decrypts the encrypted and protected resource corresponding to the protected resource access request using the obtained attribute-based encryption user key corresponding to the resource user. Using the attribute-based encryption user key obtained, determine whether the decryption of the encrypted and protected resource was successful in order to form a decrypted and protected resource. In order to form the decrypted and protected resource using the attribute-based encryption user key obtained, in response to determining that the decryption of the encrypted and protected resource was successful, it is determined that the resource user has the right to access the decrypted and protected resource and that access is permitted. In response to determining that the decryption of the encrypted and protected resource has failed using the attribute-based encryption user key obtained, it is determined that the resource user does not have permission to access the encrypted and protected resource, and access is denied. Execute the program instruction that performs the above action. Computer system.

8. The aforementioned processor further, Receiving the protected resource access request, which includes the set of header fields, an embedded authentication code field containing the authentication code, and an embedded user key identifier field containing the user key identifier, from the client device corresponding to the resource user via the network, In the protected resource access request, the embedded authentication code field containing the authentication code and the embedded user key identifier field containing the user key identifier are read. Retrieving an attribute-based cryptographic user key from the computer system's key store in order to form the retrieved attribute-based cryptographic user key using the user key identifier read in the embedded user key identifier field of the protected resource access request, wherein the user key identifier uniquely identifies the attribute-based cryptographic user key in the key store; The computer system according to claim 7, which executes the program instructions that perform the above.

9. The computer system according to claim 8, wherein the client resource application of the client device embeds the embedded authentication code field and the embedded user key identifier field in the protected resource access request in addition to the set of header fields, the client resource application inserts the authentication code into the embedded authentication code field and the user key identifier into the embedded user key identifier field before sending the protected resource access request to the computer system, and the client resource application utilizes the encrypted and protected resource after the computer system has successfully decrypted it.

10. The computer system according to claim 7, wherein the protected resource access request requests access to the encrypted and protected resource hosted by the computer system.

11. The computer system according to claim 7, wherein the acquired attribute-based encrypted user key corresponds to the resource user.

12. A computer program for resource user authentication and authorization, wherein the computer program includes program instructions, the program instructions are executable by a computer, and the computer, The computer generates an authentication code based on the use of an acquired attribute-based cryptographic user key as the secret key for a keyed hash message authentication code digital signature on a set of header fields of a protected resource access request received from a resource user's client device over the network, The computer compares the generated authentication code with the authentication code read in the embedded header field of the protected resource access request. The computer determines whether there is a match between the generated authentication code and the authentication code read in the embedded header field. In response to the computer determining that there is a match between the generated authentication code and the authentication code read in the embedded header field, the computer authenticates the resource user. The computer, in response to authentication of the resource user, decrypts the encrypted and protected resource corresponding to the protected resource access request using the acquired attribute-based encryption user key corresponding to the resource user. Using the attribute-based encryption user key obtained, the computer determines whether the decryption of the encrypted and protected resource was successful in order to form a decrypted and protected resource. Using the attribute-based encryption user key obtained, in order to form a decrypted and protected resource, the computer determines that the decryption of the encrypted and protected resource has been successful, and in response, the computer determines that the resource user has the right to access the decrypted and protected resource and grants access; In response to the computer determining that the decryption of the encrypted and protected resource has failed using the attribute-based encryption user key obtained, the computer determines that the resource user does not have permission to access the encrypted and protected resource and denies access. A computer program that causes a computer to perform a method that includes such a method.

13. The computer receives the protected resource access request, which includes the set of header fields, an embedded authentication code field containing the authentication code, and an embedded user key identifier field containing the user key identifier, from the client device corresponding to the resource user via the network, The computer reads, in the protected resource access request, the embedded authentication code field containing the authentication code and the embedded user key identifier field containing the user key identifier. The computer retrieves an attribute-based encryption user key from its key store in order to form the retrieved attribute-based encryption user key using the user key identifier read in the embedded user key identifier field of the protected resource access request, wherein the user key identifier uniquely identifies the attribute-based encryption user key in the key store. The computer program according to claim 12, further comprising:

14. The computer program according to claim 13, wherein the client resource application of the client device embeds the embedded authentication code field and the embedded user key identifier field in the protected resource access request in addition to the set of header fields, the client resource application inserts the authentication code into the embedded authentication code field and the user key identifier into the embedded user key identifier field before sending the protected resource access request to the computer, and the client resource application utilizes the encrypted and protected resource after the computer has successfully decrypted it.

15. The computer program according to claim 12, wherein the protected resource access request requests access to the encrypted and protected resource hosted by the computer.

16. The acquired attribute-based encryption user key corresponds to the resource user in the computer program according to claim 12.

17. In response to the computer determining that there is no match between the generated authentication code and the authentication code read in the embedded header field, the computer determines that the resource user is not authenticated and denies the resource user access to the encrypted and protected resource. The computer program according to claim 12, further comprising:

Images