US20030084296A1 - Access privilege authentication of client computer for services provided by sever computer - Google Patents
Access privilege authentication of client computer for services provided by sever computer Download PDFInfo
- Publication number
- US20030084296A1 US20030084296A1 US10/014,362 US1436201A US2003084296A1 US 20030084296 A1 US20030084296 A1 US 20030084296A1 US 1436201 A US1436201 A US 1436201A US 2003084296 A1 US2003084296 A1 US 2003084296A1
- Authority
- US
- United States
- Prior art keywords
- client
- server
- challenge
- response
- access privilege
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Abstract
Description
- 1. Field of the Invention
- The present invention relates to an authentication technology enabling a server to verify whether a client connected to the server via a network has valid authorization to access services on the server.
- 2. Description of the Related Art
- Most servers providing services to client computers that are connected there to via a network have a process for determining, prior to providing these services, whether the client has proper access privileges for the services or whether the client computer is currently being operated by a user having proper access privileges for the services. This process is called client authentication.
- Pages 353-359 of “Microsoft Internet Information Server Resource Kit” issued by Microsoft Corporation of the U.S. describe client authentication functions possessed by a Microsoft Internet Information Server (herein after abbreviated to IIS. “Microsoft” is a trademark of Microsoft Corporation). The IIS has a system for client authentication called Basic Authentication. In Basic Authentication, an account is assigned to the user who accesses a server using a client. The accounts of the users that are authorized to access files stored on the server are determined.
- When receiving a request from a client for a file on the server, the server requests the user to input a user ID and password. Based on the inputted user ID and password, the server identifies the user's account, determines whether the requested file can be accessed by that account, and provides the requested file to the client computer when access is authorized.
- Authentication methods such as Basic Authentication in IIS are extremely common. In fact, nearly all applications using the Web, whether via the Internet or an intranet, employ similar authentication methods with Basic Authentication for restricting user access.
- The following two problems exist in client authentication using user accounts, such as Basic Authentication in IIS.
- (1) Management of user accounts places heavy maintenance and operation cost on the server
- (2) User anonymity on the server end is not guaranteed
- Next, these problems will be described in greater detail.
- In client authorization using user accounts, it is essential that the server can identify the user's account. This means that the server must manage the user accounts. Accordingly, the server must have a database for managing the accounts. This database must be modified daily in response to the addition and deletion of accounts, resulting in considerable maintenance and operating costs.
- When many servers are performing the same client authorization process, a main server (account server) is provided for managing the user accounts. Each server refers to the main server for account information. This method requires increased communication costs and security problems between individual servers and the account server.
- In addition, users must reveal their accounts to the server. This means that the history of service usage by each user is exposed to the server. Considering the innumerable cases of abusing private data collected on servers in today's society, it is inevitable that this method poses a large risk for users.
- In actual fact, identifying user accounts is not essential for client authentication. The purpose of performing client authentication is simply to determine whether it is permissible to provide a service to the client requesting that service or to the user of that client. Identifying the user account is nothing more than a means to make that determination, not the objective.
- According to the present invention, public keys are assigned to services provided to the clients. In order to determine whether or not to supply a service to a client or to a user of that client, the server executes a challenge/response exchange using a public key assigned to the requested service.
- For example, when using the RSA (Rivest, Shamir, and Adleman) algorithm for public-key encryption a modulus n and public key e of the RSA key pair (public key e and private key d) are assigned to a service, and the private key d is distributed to all clients authorized to receive that service. When a client requests a service that has been assigned a modulus n and public key e, the server generates a random number C, called a challenge, and sends this value C to the client. The client uses the private key d it possesses to calculate a response according to Equation (1) and returns the result to the server. Here, either the server can transmit the modulus n to the client along with the challenge, or the modulus n can be distributed to the client along with the private key d. Since the modulus n is public data, this value can also be stored on a separate server accessible by anyone.
- R=C d mod n (1)
- After receiving a response, the server verifies whether Equation (2) is satisfied using the values for the challenge C sent to the client, the response R received from the client, and the modulus n and public key e assigned to the service.
- C≡R e mod n (2)
- If the relationship in Equation (2) holds, the service is provided to the client. If not, the service is not provided.
- In this method, the private key d serves as access privilege proving data to prove the access privileges of a client for the service assigned the modulus n and public key e. All users having the private key d can access services assigned the modulus n and public key e.
- The same private key can serve to enable use of a plurality of services assigned the same modulus and public key. These can be thought of as a group of services that can be used according to the same access privileges, whether they are on the same server or completely different servers. Conversely, a plurality of services, each assigned a different modulus and public key, can be thought to require different access privileges.
- With this method, the server need not identify the account of the user operating the client. A database for user accounts is unnecessary, and the server need not access an account server to identify a user account. Further, the user accounts are not made public to the server. In fact, in the challenge/response process, data identifying the user is never transmitted to the server side, thereby user's anonymity is completely protected.
- RSA is not the only public-key encryption algorithm that can be used in the above method. It is possible to apply a challenge/response method using a signature, such as DSA (Digital Signature Algorithm). Another possible algorithm is one that requires commitment transmissions prior to the challenge/response change, such as Schnorr Signature Authentication Algorithm.
- The problem with these methods is that the private key and modulus sent to the client as data for proving access privileges can be copied to another client, running the risk of the service being used dishonestly.
- To solve these problems, the present invention assigns unique operations to each client. Access privilege proving data is created using this unique operation and the private key corresponding to the modulus and public key assigned to the desired service.
- For example, access privilege proving data t is created as in Equation (3), where n is the modulus, e the public key, d the private key, and fU () denotes the unique operation possessed by the client U. The calculated value t is provided to the client U. Here, “|” denotes bit concatenation.
- t=d−f U(n|e) (3)
- When a request for a service assigned the modulus n and public key e is received from the client U, the server generates a challenge C and transmits this value to the client U. The client U calculates a response based on Equation (4) and returns this value to the server. Here, the server can transmit the modulus n and public key e to the client along with the challenge. The modulus n and public key can also be provided to the client in advance together with the access privilege proving data t. Since it is public, the modulus n and public key e can also be stored on a separate server accessible by anyone.
- R=C t C fU(n|e) (4)
- After receiving a response, the server verifies whether Equation (2) is satisfied using the values for the challenge C sent to the client, the response R received from the client, and the modulus n and public key e assigned to the service. If the relationship in Equation (2) holds, the service is provided to the client. If not, the service is not provided.
- This method achieves the same functions as the method described above because services are not provided to any computer other than those clients having access privilege proving data assigned to the services. An advantage of this method is that access privilege proving data for one service is different for each client. Therefore, this access privilege proving data cannot be used dishonestly, even if the data is copied, providing the results of the unique operation fU() are protected from accesses by the user of the client.
- In the above-described method, the client performs the operation using access privilege proving data. However, the same effects can be achieved by configuring the server to use the access privilege proving data. The procedure used for this method is described next.
- When a request for a service assigned the modulus n and public key e is received from the client U, the server generates a challenge C and transmits this value to the client U. The client U calculates a response based on Equation (5) and returns this value to the server along with the access privilege proving data t.
- R=C fU(n|e) (5)
- After receiving a response, the server verifies whether Equation (6) is satisfied using the values for the challenge C sent to the client, the response R and the access privilege proving data t received from the client, and the modulus n and public key e assigned to the service. If the relationship in Equation (6) holds, the service is provided to the client. If not, the service is not provided.
- C≡C t R mod n (6)
- One method for generating the unique operation is to assign a common cryptographic hash function f() to all clients (for example, SHA-1) and to assign a different data u for each client, then performing the operation shown in Equation (7).
- f U(x)=f(x|u) (7)
- It is also possible to use the client-specific data u itself as the result of the unique operation.
- When it is desirable that the use of services provided by the server be limited by specified conditions, data describing usage conditions (conditions-of-use data) is used. For example, when restricting the time period in which the services can be used, the starting and ending times of use are described in the conditions-of-use data.
- The access privilege proving data is then generated from a private key, a unique client-specific operation, and the conditions-of-use data. For example, if d is the private key, fU() the unique operation, and L the conditions-of-use data, the access privilege proving data t is calculated as shown in Equation (8).
- t=d−f U(n|e|L) (8)
- The access privilege proving data t and conditions-of-use data L are provided to the client in advance.
- When a request for a service assigned the modulus n and public key e is received from the client U, the server generates a challenge C and transmits this value to the client U. First, the client evaluates the conditions of use described by L. If those conditions have been met, the client calculates a response based on Equation (9) and returns this value to the server.
- R=C t C fU(n|e|L) (9)
- After receiving a response, the server verifies whether Equation (2) is satisfied using the values for the challenge C sent to the client, the response R received from the client, and the modulus n and public key e assigned to the service. If the relationship in Equation (2) holds, the service is provided to the client. If not, the service is not provided.
- Using this method, the value of the response R changes when the conditions of use described by L are modified. As a result, Equation (2) is not satisfied. Accordingly, the user of the client can no longer over write L for the user's own benefit.
- The methods described thus far assign a unique operation to the client. Since access privilege proving data is created based on this operation, different access privilege proving data is required for a different client, even when the user is the same. Further, it is difficult to control whether usage of services is permitted or not permitted among a plurality of users using the same client.
- With such methods that assign unique operations to clients, it is difficult to implement access privilege control that truly binds to users. The present invention solves this type of problem by implementing a unique operation unit with a portable device, such as a smart card (an IC card with a calculating capacity) The user carries this portable device around and connects the device to the client to be used. This method achieves access privilege control that binds only to the user, regardless what client is being used.
- The present invention can be implemented as a system or apparatus such as a server (server computer), a client, a computer system, and also implemented as a method. Obviously, at least a portion of this system can be implemented with a computer program. The client can be configured of a variety of data terminals, including a personal computer, workstation, portable terminal, set top box, home electric data appliance, and intelligent telephone (including portable telephones). The server can be a web server, FTP server, application server, or other server providing a variety of services.
- The server and clients can be connected via a wired or wireless network employing such configurations as an IP network, a telephone network, or a mobile communication network. The Internet, intranets, extranets, and the like can be applied to suit various environments of use. The system can also employ communication channels using short-range radio waves, as in the Bluetooth (trademark) method. A device using short-range radio waves can be used as a client in this case.
- A detailed description has been given above for the present invention, various aspects of which are described in the Claims. Next, preferred embodiments of the present invention will be described in detail.
- In the drawings:
- FIG. 1 is a block diagram showing the configuration of a web server according to a first embodiment of the present invention;
- FIG. 2 is a block diagram showing the configuration of a client according to the first embodiment;
- FIG. 3 is a flowchart illustrating the method of operations according to the first embodiment;
- FIG. 4 is a flowchart illustrating the method of operations according to the first embodiment;
- FIG. 5 is a block diagram showing a variation of the first embodiment;
- FIG. 6 is a block diagram showing the configuration of a web server according to a second embodiment of the present invention;
- FIG. 7 is a block diagram showing the configuration of a client according to the second embodiment;
- FIG. 8 is a flowchart illustrating the method of operations according to the second embodiment;
- FIG. 9 is a flowchart illustrating the method of operations according to the second embodiment; and
- FIG. 10 is a block diagram showing a variation of the second embodiment.
- An authentication technology according to preferred embodiments of the present invention will be described while referring to the accompanying drawings.
- First Embodiment
- The authentication technology of the first embodiment comprises a web server for providing web pages to clients and clients that receive web pages after requesting the web pages from the web server.
- The web server of the present embodiment has an access privilege authentication mechanism applying the present invention. An RSA modulus and a public key are assigned to web pages on the web server when necessary. Web pages not assigned with these values are accessible by any client.
- When a request is received from a client for a web page assigned an RSA modulus and public key, the web server executes a challenge/response exchange with the client to verify whether the client has access privileges for that page. The challenge/response is successful only when the client possesses access privilege proving data corresponding to the RSA modulus and public key that are assigned to the relevant web page. The requested web page is provided to the client only when this verification is successful.
- The method of assigning the RSA modulus and public key values to web pages has a number of possible variations. For example, it is possible to associate an RSA modulus and public key to each web page. It is also possible to associate an RSA modulus and public key to a group of web pages listed in a directory or the like. When a request for any web page contained in this group of web pages is received, a challenge/response exchange is executed using the RSA modulus and public key that binds this group.
- The clients of the present embodiment possess an access privilege proving mechanism applying the present invention. When a client receives a challenge from a web server in response to a web page request initiated by the client, the client can generate and return a response to the challenge.
- The clients in the present embodiment are each assigned unique data. Access privilege proving data giving specific clients access to a certain web page is created from a private key corresponding to the RSA modulus and public key assigned to that web page, the unique data assigned to the client, and conditions-of-use data describing conditions in which use of the web page is permitted to clients. The conditions-of-use data includes a description of the starting and ending time and date for a period in which the client can access the web page.
- As an example, let us say n and e are the RSA modulus and the public key assigned to the web page. d is the private key corresponding to n and e. u is the unique data assigned to the client, and L is the conditions-of-use data. In this example, the access privilege proving data t is calculated according to Equation (10) below.
- t=d−f(n|e|L|u) (10)
- Here, f() is a cryptographic hash function universally possessed by all clients.
- FIG. 1 shows the internal construction of a
web server 101 according to the first embodiment of the present invention. Theweb server 101 includes an input/output (I/O)controller 102, apage data manager 103, and anaccess privilege authenticator 104. - The I/
O controller 102 controls input received by theweb server 101 from a client via a network and output transmitted from theweb server 101 to a client via the network. - The
page data manager 103 manages web pages on the web server. Thepage data manager 103 includes a function for supplying a web page via the I/O controller 102 in response to a request for the page from a client. When necessary, thepage data manager 103 calls theaccess privilege authenticator 104 before supplying a web page in order to confirm whether the client has proper access privileges and can cancel provision of the web page when the client does not. - The
access privilege authenticator 104 determines whether a client has proper access privileges in response to a call from thepage data manager 103 and returns the result to thepage data manager 103. During the determination process, theaccess privilege authenticator 104 communicates with the client via the I/O controller 102. - The
access privilege authenticator 104 comprises an accessprivilege authentication controller 105, a publickey manager 106, achallenge generator 107, and anaccess privilege verifier 108. - The access
privilege authentication controller 105 controls the overall process for testing whether the client has proper user privileges. - The public
key manager 106 stores and manages the bindings between the web pages and their corresponding assigned RSA modulus and public key. - The legitimacy of the client's access privileges is determined according to a challenge/response exchange conducted between the web server and the client. The
challenge generator 107 generates a challenge that is transmitted to the client. - The
access privilege verifier 108 determines whether the response received from the client has a prescribed relationship with the challenge generated by thechallenge generator 107 and the RSA modulus and public key assigned to the web page that has been requested by the client. After this determination, theaccess privilege verifier 108 outputs the result of this determination. - FIG. 2 shows the internal configuration of a
client 201 according to the first embodiment of the present invention. Theclient 201 includes aweb browser 202 and anaccess privilege prover 204. - The
web browser 202 controls input to the client received from the web server via a network and output transmitted from the client to the web server via the network. Theweb browser 202 also serves to transmit requests for web pages to the web server and to process web pages received from the web server. - The
access privilege provor 204 proves for the web server that the client has access privileges for a certain web page. When a challenge is received from the web server via theweb browser 202 for verifying access privileges, theaccess privilege prover 204 calculates a response for proving its own access privileges and sends this response to the web server via theweb browser 202. - The
access privilege prover 204 comprises an accessprivilege proving controller 205, an access privilege provingdata storage unit 206, a conditions-of-use evaluator 207, aunique response generator 208, and aresponse generator 209. - The access
privilege proving controller 205 controls overall calculations of the response for proving access privileges of the client. - The access privilege proving
data storage unit 206 stores access privilege proving data for web pages and is capable of storing multiple access privilege proving data. Each separate access privilege proving data is stored along with its RSA modulus, public key, and conditions-of-use data used in generating the access privilege proving data. - The conditions-of-
use evaluator 207 determines whether or not the conditions of use described by the conditions-of-use data are met. The conditions-of-use data in the present embodiment describe the starting and ending time and date for a period in which the client can access the web page. The conditions-of-use evaluator 207 includes a function for determining whether the current time falls within the period during which the web page is accessible. - In the present embodiment, the generation of a response is divided into two stages: a calculation using unique data and a calculation using access privilege proving data. The
unique response generator 208 executes the calculation using unique data. - The
response generator 209 generates a response to be transmitted to theweb server 101. - The
unique response generator 208 comprises a uniquedata storage unit 210, aunique operation executor 211, and aunique response calculator 212. - The unique
data storage unit 210 stores unique data assigned to the client. - The
unique operation executor 211 is provided with a built-in cryptographic hash function f() possessed universally by all clients. Theunique operation executor 211 executes this hash operation using the unique data stored in the uniquedata storage unit 210. - The
unique response calculator 212 executes one stage of the response calculation for the response to be sent to theweb server 101 using the results from theunique operation executor 211. - When the
web server 101 receives a request for a web page from theclient 201, theweb server 101 transfers the request to thepage data manager 103 via the I/O controller 102. Thepage data manager 103 calls theaccess privilege authenticator 104 in order to confirm that theclient 201 has access privileges for the requested web page. When calling theaccess privilege authenticator 104, data such as a file name is transferred to theaccess privilege authenticator 104 in order to identify the requested web page. - The
access privilege authenticator 104 determines whether theclient 201 making the request possesses access privileges for the requested web page and transmits the results of this determination to thepage data manager 103. If it is confirmed that the client has proper access privileges, the web page is transmitted to theclient 201. If it is determined otherwise, an error message is returned to theclient 201. - FIG. 3 is a flowchart showing the operations performed in the
access privilege authenticator 104 when called by thepage data manager 103. The procedure for verifying access privileges executed by theaccess privilege authenticator 104 will be described with reference to this flowchart. - The access
privilege authentication controller 105 controls operations of theaccess privilege authenticator 104. The accessprivilege authentication controller 105 first calls the publickey manager 106 instep 301 to search for an RSA modulus and public key assigned to the web page requested by theclient 201. If an assigned RSA modulus and public key do not exist (No in 302), data indicating that access privileges have been successfully authenticated is output instep 307 and the process ends. - If an RSA modulus and public key have been assigned to the requested web page (Yes in302), the access
privilege authentication controller 105 calls thechallenge generator 107 to generate a challenge and transmits this challenge to theclient 201 via the I/O controller 102 instep 303. The accessprivilege authentication controller 105 also transmits the RSA modulus and public key assigned to the requested web page to theclient 201 along with the challenge. - Subsequently, the
access privilege authenticator 104 waits for a response from theclient 201 via the I/O controller 102. If no response has been received after a fixed interval has passed since the challenge was transmitted (No in 304), data indicating that authentication of access privileges has failed is output instep 308 and the process ends. - When a response is received from the client201 (Yes in 304), the access
privilege authentication controller 105 calls theaccess privilege verifier 108 instep 305 to verify whether the response is correct. Here, theaccess privilege verifier 108 verifies whether Equation (2) is satisfied when the challenge sent to theclient 201 instep 303 is C, the response received instep 304 is R, the RSA modulus assigned to the requested web page is n, and the public key is e. If Equation (2) is satisfied (Yes in 306), data indicating that access privileges have been successfully authenticated is output instep 307, and the process ends. If Equation (2) is not satisfied (No in 306), data indicating that verification of access privileges has failed is output instep 308, and the process ends. - Meanwhile, having received a challenge, RSA modulus, and public key from the
web server 101 via theweb browser 202, theclient 201 transfers this data to theaccess privilege prover 204 to generate a response, then sends the response to theweb server 101 via theweb browser 202. - FIG. 4 is a flowchart showing operations of the
access privilege prover 204 to which the challenge, RSA modulus, and public key are transferred. The procedure of generating a response that is executed by theaccess privilege prover 204 will be described with reference to this flowchart. - The access
privilege proving controller 205 controls the operations of theaccess privilege prover 204. Instep 401, the accessprivilege proving controller 205 searches the access privilege provingdata storage unit 206 for the conditions-of-use data and access privilege proving data corresponding to the RSA modulus and public key received from theweb server 101. A plurality of access privilege proving data with the RSA modulus, public key, and conditions-of-use data used in generating the access privilege proving data is stored in the access privilege provingdata storage unit 206. In this step, the accessprivilege proving controller 205 searches for access privilege proving data and conditions-of-use data bound to the same RSA modulus and public key as that received from theweb server 101. - If no access privilege proving data and conditions-of-use data corresponding to the data received from the
web server 101 exists (No in 402), the process ends. In this case, a response is not returned to theweb server 101. - If access privilege proving data and conditions-of-use data corresponding to the data received from the
web server 101 exists (Yes in 402), the conditions-of-use evaluator 207 is called to determine instep 403 whether the conditions of use listed in the conditions-of-use data found instep 401 are satisfied. - If the conditions of use are not satisfied (No in404), the process ends. In this case, a response is not returned to the
web server 101. If the conditions of use are satisfied (Yes in 404), a response is calculated and transmitted instep 405 to theweb server 101 via theweb browser 202, and the process ends. - In
step 405, theunique response generator 208 is called to calculate the response based on unique data assigned to the client. When calling theunique response generator 208, the challenge, RSA modulus, and public key transferred from theweb server 101 and the conditions-of-use data found instep 401 are transferred to theunique response generator 208. - In the
unique response generator 208, theunique response calculator 212 calls theunique operation executor 211 to obtain calculation results based on unique data stored in the uniquedata storage unit 210. Theunique operation executor 211 performs a prescribed operation based on the unique data stored in the uniquedata storage unit 210, the RSA modulus and public key received from theweb server 101, and the conditions-of-use data found instep 401. Theunique operation executor 211 performs the calculation shown in Equation (11), where n is the RSA modulus received from theweb server 101, e is the public key, L is the conditions-of-use data found instep 401, and u is the unique data stored in the uniquedata storage unit 210 to obtain the result F. - F=f(n|e|L|u) (11)
- Subsequently, the
unique response calculator 212 calculates R′ using Equation (12) from the result calculated by theunique operation executor 211, and the challenge C and RSA modulus n transferred from theweb server 101. - R′=C F mod n (12)
- After receiving the result R′ of the calculation from the
unique response generator 208, the accessprivilege proving controller 205 calls theresponse generator 209 to calculate the response R. This response is generated by executing the calculation shown in Equation (13) from the challenge C and RSA modulus n received from theweb server 101, the result R′ received from theunique response generator 208, and the access privilege proving data t found instep 401. - R=C t R′ mod n (13)
- In the present embodiment, the response check in
step 305 is successful if there is a correct combination of the RSA modulus n and public key e assigned to the requested web page, unique data u assigned to the client, and access privilege proving data t and conditions-of-use data L indicating access privileges of that client. As a result of the successful finding instep 305, data for the requested web page is transferred to the client. If any part of this data combination is different, the result instep 305 will not be successful, and the client will not be able to obtain data for the requested web page. - In the present embodiment, the access privilege proving data is defined by Equation (10). Accordingly, the ability of someone to analyze the contents of the
unique response generator 208 would create a security problem. If the result of Equation (11) were revealed, a third party could calculate the private key d corresponding to the RSA modulus n and the public key e. A third party learning the private key d could use the system dishonestly. Even without knowledge of Equation (11), disclosing the unique data u stored in the uniquedata storage unit 210 could lead anyone to calculate this Equation (11) and to ultimately calculate the private key d. To prevent this problem, measures must be taken to avoid a third party analysis of the calculation process and the internal memory of theunique response generator 208. It is necessary to take such measures as configuring theunique response generator 208 using tamper-resistant hardware or using software technology to make the analysis of programs and memory difficult, for example. - Since smart cards (IC cards possessing operating functions) are highly tamper-resistant hardware, configuring the
unique response generator 208 using smart cards is an effective method. In this case, unique data is assigned to the smart cards rather than to the client. By carrying the smart cards and connecting them to a client, the user can use any client and still exercise the same access privileges. This method is even more user-friendly if thestorage unit 206 is included in the smart card. - FIG. 5 shows an example configuration of the
client 201 when configuring theunique response generator 208 and access privilege provingdata storage unit 206 with smart cards. - For convenience of this description, parts in FIG. 5 having the same function as those in FIG. 2 are designated by the same reference numerals, while new numbers are assigned to new parts not appearing in FIG. 2.
- Unlike the configuration shown in FIG. 2, the
unique response generator 208 and access privilege provingdata storage unit 206 are included in asmart card 502 in the configuration of FIG. 5. Thesmart card 502 has an I/O controller 503 for controlling data input and output between thesmart card 502 andclient 201. Theclient 201 has asmart card connector 501 for connecting to thesmart card 502 and controlling data input and output with the smart card. Since the remaining configuration in FIG. 5 is the same as that shown in FIG. 2, a description of these parts has been omitted. - Second Embodiment
- The authentication technology according to a second embodiment of the present invention comprises a web server for providing web applications to clients, and clients using these web applications on the web server. Operations of the applications on the web server are controlled using script that is interpreted and executed on the server end.
- The web server in the present embodiment employs a mechanism for authenticating access privileges according to the present invention. The timing at which the mechanism of access privilege authentication is called can be described in script, along with the RSA modulus and public key used by this access privilege authentication mechanism. During the process of interpreting and executing this script, the mechanism for access privilege authentication is called to verify that the client has access privileges. Before providing the client with specific functions of a web application, for example, it is possible to perform access privilege authentication for those functions in order to provide relevant functions only to clients confirmed to have proper access privileges.
- When called, the mechanism of access privilege verification verifies whether the client has proper access privileges by performing a challenge/response exchange with the client. The challenge/response exchange is only successful when the client possesses access privilege proving data corresponding to an RSA modulus and public key specified for the access privilege authentication.
- In the present embodiment, the client has a mechanism for authenticating access privileges according to the present invention. When the client receives a challenge from the web server, the client can generate and return a response. Each client in the present embodiment is assigned unique data. Access privilege proving data for special clients is generated from the private key corresponding to the RSA modulus and public key, the unique data assigned to the client, and conditions-of-use data describing conditions in which use of functions on web application is allowed the client. The conditions-of-use data includes starting and ending times and dates for the valid time period of the client's access privileges.
- For example, an access privilege proving data t is generated according to Equation (10), where n is the RSA modulus, e the public key, d the private key corresponding to the n and e, u the unique data assigned to the client, and L the conditions-of-use data.
- FIG. 6 shows the internal construction of a
web server 601 according to the second embodiment of the present invention. Theweb server 601 includes an I/O controller 602, ascript interpreter 603, and anaccess privilege authenticator 604. - The I/
O controller 602 controls input received by theweb server 601 from a client via a network and output transmitted from theweb server 601 to a client via the network. - The
script interpreter 603 retains script configuring a web application that is provided by theweb server 601, interprets and executes the script in response to a request from a client, and provides results to the client via the I/O controller 602. When interpreting and executing the script, thescript interpreter 603 can call theaccess privilege authenticator 604 to verify whether the client has proper access privileges. - The
access privilege authenticator 604 determines whether a client has proper access privileges in response to a call from thescript interpreter 603 and returns the result to thescript interpreter 603. During the determination process, theaccess privilege authenticator 604 communicates with the client via the I/O controller 602. - The
access privilege authenticator 604 comprises an accessprivilege authentication controller 605, achallenge generator 606, and anaccess privilege verifier 607. - The access
privilege authentication controller 605 controls the overall process for testing whether the client has proper user privileges. - The access privilege
authentication control unit 605 determines whether the client has access privileges according to a challenge/response exchange conducted between the web server and the client. Thechallenge generator 606 generates a challenge that is transmitted to the client. - The
access privilege verifier 607 determines whether the response received from the client has a prescribed relationship with the challenge generated by thechallenge generator 606, the access privilege proving data transmitted by the client along with the response, and the RSA modulus and public key specified by thescript interpreter 603, and outputs the result of this determination. - FIG. 7 shows the internal configuration of a
client 701 according to the second embodiment of the present invention. Theclient 701 includes aweb browser 702 and anaccess privilege prover 704. - The
web browser 702 controls input to the client received from the web server via a network and output transmitted from the client to the web server via the network. Theweb browser 702 also serves to transmit requests for web applications to the web server and to process web pages received from the web server. - When a challenge is received from the
web server 601 via theweb browser 702 for authenticating access privileges, theaccess privilege prover 704 calculates a response for proving its own access privileges and sends this response to theweb server 601 via theweb browser 702, together with access privilege proving data. - The
access privilege prover 704 comprises an accessprivilege proving controller 705, an access privilege provingdata storage unit 706, a conditions-of-use evaluator 707, and aresponse generator 708. - The access
privilege proving controller 705 controls overall calculations of the response for proving access privileges of the client. - The access privilege proving
data storage unit 706 stores access privilege proving data possessed by the client and is capable of storing multiple access privilege proving data. Each separate access privilege proving data is stored along with its RSA modulus, public key, and conditions-of-use data used in generating access privilege proving data. - The conditions-of-
use evaluator 707 determines whether or not the conditions of use described by the conditions-of-use data are met. The conditions-of-use data in the present embodiment describe the starting and ending time and date for the valid period of the corresponding access privilege proving data. The conditions-of-use evaluator 707 includes a function for determining whether the current time falls with in this period. - The
response generator 708 generates a response to be transmitted to theweb server 601. - The
response generator 708 comprises a uniquedata storage unit 709, aunique operation executor 710, and aresponse calculator 711. - The unique
data storage unit 709 stores unique data assigned to the client. - The
unique operation executor 710 is provided with a built-in cryptographic hash function f() possessed universally by all clients. Theunique operation executor 710 executes this hash operation using the unique data stored in the uniquedata storage unit 709. - The
response calculator 711 calculates the response to be sent to theweb server 601 using the results from theunique operation executor 710. - Part of the script retained by the
web server 601 describes calling the mechanism for access privilege authentication. The RSA modulus and public key used for access privilege authentication are described in the script. When reaching the part of the script for calling the mechanism for access privilege authentication during the process of interpreting and executing the script, thescript interpreter 603 calls theaccess privilege authenticator 604 for confirming whether theclient 701 has access privileges corresponding to the RSA modulus and public key specified in the script. - The
access privilege authenticator 604 verifies whether theclient 701 has access privileges corresponding to the specified RSA modulus and public key and sends the result of this check to thescript interpreter 603. - FIG. 8 is a flowchart showing the operations performed in the
access privilege authenticator 604 when called by thescript interpreter 603. The procedure for verifying access privileges executed by theaccess privilege authenticator 604 will be described with reference to this flowchart. - The access
privilege authentication controller 605 controls operations of theaccess privilege authenticator 604. The accessprivilege authentication controller 605 first calls the challenge generator 606to generate a challenge and transmits this challenge to theclient 701 via the I/O controller 602 instep 801. The accessprivilege authentication controller 605 also transmits the RSA modulus and public key used for access privilege authentication to theclient 701 along with the challenge. - Subsequently, the
access privilege authenticator 604 waits for a response and access privilege proving data to be sent from theclient 701 via the I/O controller 602. If no response and access privilege proving data has been received when a fixed interval has passed since the challenge was transmitted (No in 802), data indicating that verification of access privileges has failed is output instep 806, and the process ends. - When a response and access privilege proving data is received from the client701 (Yes in 802), the access
privilege authentication controller 605 calls theaccess privilege verifier 607 instep 803 to verify whether the response is correct. Here, theaccess privilege verifier 607 verifies whether Equation (6) is satisfied when the challenge sent to theclient 701 instep 801 is C, the response received instep 802 is R, the access privilege proving data is t, and the RSA modulus used for access privilege authentication is n. If Equation (6) is satisfied (Yes in 804), data indicating that access privileges have been successfully authenticated is output instep 805, and the process ends. If Equation (6) is not satisfied (No in 804), data indicating that authentication of access privileges has failed is output instep 806, and the process ends. - Meanwhile, after receiving a challenge, RSA modulus, and public key from the
web server 601 via theweb browser 702, theclient 701 transfers this data to theaccess privilege prover 704 to generate a response, then sends the response to theweb server 601 via theweb browser 702, together with the access privilege proving data corresponding to the RSA modulus and public key. - FIG. 9 is a flowchart showing operations of the
access privilege prover 704, which generates a response after receiving the challenge, RSA modulus, and public key. The procedure of generating a response that is executed by theaccess privilege prover 704 will be described with reference to this flowchart. - The access
privilege proving controller 705 controls the operations of theaccess privilege prover 704. Instep 901, the accessprivilege proving controller 705 searches the access privilege provingdata storage unit 706 for the conditions-of-use data and access privilege proving data corresponding to the RSA modulus and public key received from theweb server 601. A plurality of access privilege proving data bound to the RSA modulus, public key, and conditions-of-use data used in generating the access privilege proving data is stored in the access privilege provingdata storage unit 706. In this step, the accessprivilege proving controller 705 searches for access privilege proving data and conditions-of-use data bound to the same RSA modulus and public key as that received from theweb server 601. - If no access privilege proving data and conditions-of-use data corresponding to the data received from the
web server 601 exists (No in 902), the process ends. In this case, a response is not returned to theweb server 601. - If access privilege proving data and conditions-of-use data corresponding to the data received from the
web server 601 exists (Yes in 902), the conditions-of-use evaluator 707 is called to determine instep 903 whether the conditions of use listed in the conditions-of-use data found instep 901 are satisfied. - If the conditions of use are not satisfied (No in904), the process ends. In this case, a response is not returned to the
web server 601. If the conditions of use are satisfied (Yes in 904), a response is calculated instep 905 and transmitted to theweb server 601 via theweb browser 702, along with the access privilege proving data found instep 901, and the process ends. - In
step 905, theresponse generator 708 is called to calculate the response based on unique data assigned to the client. When calling theresponse generator 708, the challenge, RSA modulus, and public key received from theweb server 601 are transferred to theresponse generator 708. - In the
response generator 708, theresponse calculator 711 calls theunique operation executor 710 to obtain calculation results based on unique data stored in the uniquedata storage unit 709. Theunique operation executor 710 performs a prescribed operation based on the unique data stored in the uniquedata storage unit 709 and the RSA modulus and public key received from theweb server 601. Theunique operation executor 710 performs the calculation shown in Equation (11) to obtain the result F, where n is the RSA modulus received from theweb server 601, e is the public key, L is the conditions-of-use data found instep 901, and u is the unique data stored in the uniquedata storage unit 709. - Subsequently, the
response calculator 711 calculates the response R using Equation (14) from the result found by theunique operation executor 710, and the challenge C and RSA modulus n transferred from theweb server 601. - R=C f mod n (14)
- In the present embodiment, the response check in
step 803 is successful if there is a correct combination of the RSA modulus n and public key e specified by thescript interpreter 603, unique data u assigned to the client, and access privilege proving data t and conditions-of-use data L indicating access privileges of that client. If any part of this data combination is different, the result instep 803 will not be successful. The results of the verification are returned to thescript interpreter 603. Operations of the web application can be modified according to these results. For example, it is possible to transmit different HTML (Hyper Text Markup Language) documents to the client when the access privilege authentication succeeds and when it fails. Further, various web languages, such as XML (Extensible Markup Language), can be used in place of HTML documents. - In the present embodiment, the access privilege proving data is defined by Equation (10). Accordingly, the ability to analyze the contents of the
response generator 708 would create a security problem. If the result of Equation (11) were revealed, a third party could calculate the private key d corresponding to the RSA modulus n and the public key e. A third party learning the private key d could use the system dishonestly. Even without knowledge of Equation (11), disclosing of the unique data u stored in the uniquedata storage unit 709 could lead anyone to calculate this Equation (11) and to ultimately calculate the private key d. To prevent this problem, measures must be taken to avoid a third party analysis of the calculation process and the internal memory in theresponse generator 708. It is necessary to take such measures as configuring theresponse generator 708 using tamper-resistant hardware or using software technology to make the analysis of programs and memory difficult, for example. - As in the first embodiment, it is preferable to implement the
response generator 708 using a smart card. - FIG. 10 shows an example configuration of the
client 701 when configuring theresponse generator 708 and access privilege provingdata storage unit 706 with a smart card. - For convenience of this description, parts in FIG. 10 having the same function as those in FIG. 7 are designated by the same reference numerals, while new numbers are assigned to new parts not appearing in FIG. 7.
- Unlike the configuration shown in FIG. 7, the
response generator 708 and access privilege provingdata storage unit 706 are included in asmart card 1002 in the configuration of FIG. 10. Thesmart card 1002 has an I/O controller 1003 for controlling data input and output between thesmart card 1002 andclient 701. Theclient 701 has asmart card connector 1001 for connecting to thesmart card 1002 and controlling data input and output with the smart card. Since the remaining configuration in FIG. 10 is the same as that shown in FIG. 7, a description of these parts has been omitted. - In the embodiments of the present invention described above, access privilege authentication is not performed using user account data. Therefore, there is no need to maintain user account data, thereby preventing the service history of users being known on the server end.
- As described above, clients are authenticated without using user accounts in the present invention, thereby reducing the cost of maintaining user accounts and protecting user privacy.
- While the invention has been described in detail with reference to specific embodiments thereof, it would be apparent to those skilled in the art that many modifications and variations may be made therein without departing from the spirit of the invention, the scope of which is defined by the attached claims.
Claims (21)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001003603A JP3593979B2 (en) | 2001-01-11 | 2001-01-11 | Server and client with usage right control, service providing method and usage right certifying method |
JPP2001-3603 | 2001-11-01 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20030084296A1 true US20030084296A1 (en) | 2003-05-01 |
US7165176B2 US7165176B2 (en) | 2007-01-16 |
Family
ID=18871923
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/014,362 Expired - Lifetime US7165176B2 (en) | 2001-01-11 | 2001-12-11 | Access privilege authentication of client computer for services provided by server computer |
Country Status (2)
Country | Link |
---|---|
US (1) | US7165176B2 (en) |
JP (1) | JP3593979B2 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020162002A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method and system for controlling access to services |
US20020162019A1 (en) * | 2001-04-25 | 2002-10-31 | Berry Michael C. | Method and system for managing access to services |
US20020162004A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method and system for managing access to services |
US20020158904A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method for automatically generating list of meeting participants and delegation permission |
US20030172299A1 (en) * | 2002-03-05 | 2003-09-11 | Gunter Carl A. | Method and system for maintaining secure access to web server services using permissions |
US20030172297A1 (en) * | 2002-03-05 | 2003-09-11 | Gunter Carl A. | Method and system for maintaining secure access to web server services using public keys |
US20030236977A1 (en) * | 2001-04-25 | 2003-12-25 | Levas Robert George | Method and system for providing secure access to applications |
US20050149758A1 (en) * | 2004-01-06 | 2005-07-07 | Samsung Electronics Co., Ltd. | Authentication apparatus and method for home network devices |
US20050188421A1 (en) * | 2004-02-24 | 2005-08-25 | Arbajian Pierre E. | System and method for providing data security |
US20050198348A1 (en) * | 2003-12-23 | 2005-09-08 | Microsoft Corporation | Methods and systems for providing secure access to a hosted service via a client application |
US20050210263A1 (en) * | 2001-04-25 | 2005-09-22 | Levas Robert G | Electronic form routing and data capture system and method |
US20060248310A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | System and method for monitoring interactions between application programs and data stores |
US20060282830A1 (en) * | 2005-06-13 | 2006-12-14 | Microsoft Corporation | Analysis of the impact of application programs on resources stored in data stores |
US7587594B1 (en) * | 2004-08-30 | 2009-09-08 | Microsoft Corporation | Dynamic out-of-process software components isolation for trustworthiness execution |
US20110167477A1 (en) * | 2010-01-07 | 2011-07-07 | Nicola Piccirillo | Method and apparatus for providing controlled access to a computer system/facility resource for remote equipment monitoring and diagnostics |
US20170048272A1 (en) * | 2014-04-25 | 2017-02-16 | Securebrain Corporation | Fraud detection network system and fraud detection method |
CN112995325A (en) * | 2021-03-10 | 2021-06-18 | 中国民航信息网络股份有限公司 | Service debugging method, debugging service, electronic device, and computer storage medium |
US11356439B2 (en) * | 2019-01-03 | 2022-06-07 | Capital One Services, Llc | Secure authentication of a user |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10135613B2 (en) | 2012-01-13 | 2018-11-20 | Qualcomm Incorporated | Method and apparatus for generating a privilege-based key |
KR102224974B1 (en) * | 2014-10-30 | 2021-03-08 | 에스케이텔레콤 주식회사 | Service server, and operating method thereof |
JP6647378B1 (en) * | 2018-12-14 | 2020-02-14 | 明雄 小田中 | Authentication system using digital tally method |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6085249A (en) * | 1997-10-24 | 2000-07-04 | Pictra, Inc. | Method and apparatuses for transferring data for multiple applications through a single communication link in response to authentication information |
US6199113B1 (en) * | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
US6304907B1 (en) * | 1997-08-08 | 2001-10-16 | Canon Kabushiki Kaisha | Network resource access method and apparatus |
US6487667B1 (en) * | 1996-06-03 | 2002-11-26 | Gary S. Brown | System for remote pass-phrase authentication |
US20030115452A1 (en) * | 2000-12-19 | 2003-06-19 | Ravi Sandhu | One time password entry to access multiple network sites |
US6690794B1 (en) * | 1997-07-14 | 2004-02-10 | Fuji Xerox Co., Ltd. | Electronic ticket system |
US6721886B1 (en) * | 1998-05-20 | 2004-04-13 | Nokia Corporation | Preventing unauthorized use of service |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11175474A (en) | 1997-12-10 | 1999-07-02 | Machine Contorol System Kk | Login manager for wave server |
JPH11234263A (en) | 1998-02-12 | 1999-08-27 | Fuji Xerox Co Ltd | Method and device for mutual authentication |
KR20010004791A (en) * | 1999-06-29 | 2001-01-15 | 윤종용 | Apparatus for securing user's informaton and method thereof in mobile communication system connecting with internet |
-
2001
- 2001-01-11 JP JP2001003603A patent/JP3593979B2/en not_active Expired - Fee Related
- 2001-12-11 US US10/014,362 patent/US7165176B2/en not_active Expired - Lifetime
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6487667B1 (en) * | 1996-06-03 | 2002-11-26 | Gary S. Brown | System for remote pass-phrase authentication |
US6690794B1 (en) * | 1997-07-14 | 2004-02-10 | Fuji Xerox Co., Ltd. | Electronic ticket system |
US6304907B1 (en) * | 1997-08-08 | 2001-10-16 | Canon Kabushiki Kaisha | Network resource access method and apparatus |
US6085249A (en) * | 1997-10-24 | 2000-07-04 | Pictra, Inc. | Method and apparatuses for transferring data for multiple applications through a single communication link in response to authentication information |
US6199113B1 (en) * | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
US6721886B1 (en) * | 1998-05-20 | 2004-04-13 | Nokia Corporation | Preventing unauthorized use of service |
US20030115452A1 (en) * | 2000-12-19 | 2003-06-19 | Ravi Sandhu | One time password entry to access multiple network sites |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050210263A1 (en) * | 2001-04-25 | 2005-09-22 | Levas Robert G | Electronic form routing and data capture system and method |
US20020162019A1 (en) * | 2001-04-25 | 2002-10-31 | Berry Michael C. | Method and system for managing access to services |
US20020162004A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method and system for managing access to services |
US20020158904A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method for automatically generating list of meeting participants and delegation permission |
US20030236977A1 (en) * | 2001-04-25 | 2003-12-25 | Levas Robert George | Method and system for providing secure access to applications |
US6885388B2 (en) | 2001-04-25 | 2005-04-26 | Probaris Technologies Inc. | Method for automatically generating list of meeting participants and delegation permission |
US20020162002A1 (en) * | 2001-04-25 | 2002-10-31 | Gunter Carl A. | Method and system for controlling access to services |
US20030172299A1 (en) * | 2002-03-05 | 2003-09-11 | Gunter Carl A. | Method and system for maintaining secure access to web server services using permissions |
US20030172297A1 (en) * | 2002-03-05 | 2003-09-11 | Gunter Carl A. | Method and system for maintaining secure access to web server services using public keys |
US8099503B2 (en) * | 2003-12-23 | 2012-01-17 | Microsoft Corporation | Methods and systems for providing secure access to a hosted service via a client application |
US10664820B2 (en) | 2003-12-23 | 2020-05-26 | Microsoft Technology Licensing, Llc | Methods and systems for providing secure access to a hosted service via a client application |
US9858562B2 (en) | 2003-12-23 | 2018-01-02 | Microsoft Technology Licensing, Llc | Methods and systems for providing secure access to a hosted service via a client application |
US20050198348A1 (en) * | 2003-12-23 | 2005-09-08 | Microsoft Corporation | Methods and systems for providing secure access to a hosted service via a client application |
US9258146B2 (en) | 2003-12-23 | 2016-02-09 | Microsoft Technology Licensing, Llc | Methods and systems for providing secure access to a hosted service via a client application |
US20050149758A1 (en) * | 2004-01-06 | 2005-07-07 | Samsung Electronics Co., Ltd. | Authentication apparatus and method for home network devices |
US7844818B2 (en) * | 2004-01-06 | 2010-11-30 | Samsung Electronics Co., Ltd. | Authentication apparatus and method for home network devices |
US20050188421A1 (en) * | 2004-02-24 | 2005-08-25 | Arbajian Pierre E. | System and method for providing data security |
US7587594B1 (en) * | 2004-08-30 | 2009-09-08 | Microsoft Corporation | Dynamic out-of-process software components isolation for trustworthiness execution |
US7665098B2 (en) | 2005-04-29 | 2010-02-16 | Microsoft Corporation | System and method for monitoring interactions between application programs and data stores |
US20060248310A1 (en) * | 2005-04-29 | 2006-11-02 | Microsoft Corporation | System and method for monitoring interactions between application programs and data stores |
US20060282830A1 (en) * | 2005-06-13 | 2006-12-14 | Microsoft Corporation | Analysis of the impact of application programs on resources stored in data stores |
US20110167477A1 (en) * | 2010-01-07 | 2011-07-07 | Nicola Piccirillo | Method and apparatus for providing controlled access to a computer system/facility resource for remote equipment monitoring and diagnostics |
US20170048272A1 (en) * | 2014-04-25 | 2017-02-16 | Securebrain Corporation | Fraud detection network system and fraud detection method |
US10469531B2 (en) * | 2014-04-25 | 2019-11-05 | SecureBrain Corporation & Hitachi Systems, Ltd. | Fraud detection network system and fraud detection method |
US11356439B2 (en) * | 2019-01-03 | 2022-06-07 | Capital One Services, Llc | Secure authentication of a user |
US11818122B2 (en) | 2019-01-03 | 2023-11-14 | Capital One Services, Llc | Secure authentication of a user |
CN112995325A (en) * | 2021-03-10 | 2021-06-18 | 中国民航信息网络股份有限公司 | Service debugging method, debugging service, electronic device, and computer storage medium |
Also Published As
Publication number | Publication date |
---|---|
JP2002207698A (en) | 2002-07-26 |
US7165176B2 (en) | 2007-01-16 |
JP3593979B2 (en) | 2004-11-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7165176B2 (en) | Access privilege authentication of client computer for services provided by server computer | |
US9397996B2 (en) | Establishing historical usage-based hardware trust | |
KR100786551B1 (en) | Method for registering and certificating user of one time password by a plurality of mode and computer-readable recording medium where program executing the same method is recorded | |
US7496751B2 (en) | Privacy and identification in a data communications network | |
US7085840B2 (en) | Enhanced quality of identification in a data communications network | |
US8352743B2 (en) | Client device, key device, service providing apparatus, user authentication system, user authentication method, program, and recording medium | |
US5742759A (en) | Method and system for facilitating access control to system resources in a distributed computer system | |
US7315943B2 (en) | Method and system for authenticating communication terminals | |
US20020002678A1 (en) | Internet authentication technology | |
US20130290719A1 (en) | System and method for accessing integrated applications in a single sign-on enabled enterprise solution | |
US20070028299A1 (en) | Client-based method, system and program to manage multiple authentication | |
JPH1141230A (en) | Method and system for authenticating user | |
CN109683936A (en) | Gray scale dissemination method and device, storage medium and electronic equipment | |
CN107872455A (en) | A kind of cross-domain single login system and its method | |
CN109873805A (en) | Cloud desktop login method, device, equipment and storage medium based on cloud security | |
CN110365684A (en) | Access control method, device and the electronic equipment of application cluster | |
CN111641615A (en) | Distributed identity authentication method and system based on certificate | |
CN112165448B (en) | Service processing method, device, system, computer equipment and storage medium | |
CN111566647A (en) | Identity recognition system based on block chain | |
CN109257381A (en) | A kind of key management method, system and electronic equipment | |
KR101769861B1 (en) | User biometric authentication method and system using HSM smart card without password exposure | |
GB2567715A (en) | Authentication system, method and program | |
JP5036500B2 (en) | Attribute certificate management method and apparatus | |
CN112994882B (en) | Authentication method, device, medium and equipment based on block chain | |
CN114238912A (en) | Digital certificate processing method and device, computer equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: KABUSHIKI KAISHA ACCESS TICKET SYSTEMS, JAPAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KYOJIMA, MASAKI;TAKEDA, KOJI;REEL/FRAME:012378/0941 Effective date: 20011203 |
|
AS | Assignment |
Owner name: FUJI XEROX CO., LTD., JAPAN Free format text: ASSIGNMENT OF ASSETS;ASSIGNOR:KABUSHIKI KAISHA ACCESS TICKET SYSTEMS;REEL/FRAME:015143/0741 Effective date: 20031111 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553) Year of fee payment: 12 |
|
AS | Assignment |
Owner name: FUJIFILM BUSINESS INNOVATION CORP., JAPAN Free format text: CHANGE OF NAME;ASSIGNOR:FUJI XEROX CO., LTD.;REEL/FRAME:058287/0056 Effective date: 20210401 |