TWI322609B - System and method for authenticating clients in a client-server environment - Google Patents

Abstract

The idea of the present invention is to replace the existing password/user ID based authentication process by a new digital signature authentication process in which preferably the first HTTP-request header is extended by the client authentication information independently of the authentication process used by the destination server and without server requesting authentication information. The authentication information preferably includes the client certificate containing the client public key, signed by certification authority, and preferably a hash value calculated over the HTTP-request header data being sent in the request, and encrypted with the Client's private key. The certificate and digital signature may be added during the creation of the HTTP-request header in the client system itself, or may be added later in a server acting as a gateway, proxy, or tunnel. A destination server that does not support the new digital signature authentication process will simply ignore the certificate and digital signature in the HTTP-request header and will automatically initiate its own authentication process. The present invention simplifies the existing digital signature authentication process and concurrently allows the coexistence of different authentication processes without changing the HTTP-protocol or causing unnecessary network traffic.

Description

1322609

_,. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ User authentication related. [Prior Art] A testimony is a procedure that determines whether a person or something is actually the person or thing that it is declared. Authentication on a private or public computer network is usually enforced by the use of a login password. In general, each server maintains the stability of its own data to store authentication data. Therefore, the password used by the user in the -Taiwan service may have been locked by another user in another. This increases the number of different authentication settings that users must remember and maintain. In the application of a plurality of user authentication systems (for example, accessing an application through an entry word server, the portal feeder uses its own user database), the user must log in— More than once. . Allowing a single signed work area includes, for example, storing login data for an application server on an inlet feeder, or centralized user data such as Micr〇s〇ft, s® net pas邛 (4) (httP://www.passport_com) The use of the library, or the method of the franchise from the licensed application (http://www.projectliberty〇rg). Along with this approach, users are willing to store their personal data and all data security issues at third-party outlets. Similarly, if the authentication service (Passp〇rtservice) is lost, even if the outlet that someone wants to use is available, the person cannot log in to the service they need.

5 Setting up authentication with a user ID/password also has the disadvantage that it will cause additional network congestion. For the user request, the listener has to respond to the client by asking for the login /:. The initial requested information will only be sent back to the client after it has been provided (see also Figure 7A below). Finally, fee codes are often easily stolen, accidentally exposed, or easily forgotten. 〇 For these reasons, Internet transactions and many other things require a more rigorous compliance process. The digital certificate published and verified by the Certificate Authority (CA) is considered part of the public keying infrastructure and is considered the standard method of performing authentication on the Internet. The digital signature enables the receiving end (server) to identify the physical injury of the sender (the client) and the integrity of its source and file. The digital signature is based on an asymmetric cryptographic algorithm. The document has the sender's private key sign. The receiving end can obtain the public opinion of the transmitting end, and it is provided to the receiving end by the second party to be served, and verifies the integrity of the received file. A digital signature program on the server side and the client side performs a change in the system that already has password registration, for example, an additional item card machine with a special security application. So, with the result that only the new client-side server-side structure is suitable for using digital signature programs, the execution of such a class has caused a lot of effort in terms of cost and time. There are two authentication procedures in the client-side device environment; the F-system and the user have to verify whether the target server supports the dense brown registration or digital signature program. Depending on the above results, the client will use the authentication required program supported by the H-end. Since the application of the server is the most n · ·, and the type of the application itself, this leads to unnecessary network 1322609 blocking at the user end and the server side. Further, the existing digital signature authentication program has a disadvantage. Several screens between the client and the server have to be switched between the client and the server until the user is able to provide their authentication information. This also caused a lot of unnecessary network congestion. SUMMARY OF THE INVENTION Starting from this, it is an object of the present invention to provide a method and system for authenticating a client in a client-server loop and avoiding the disadvantages of the prior art mentioned above. The concept of the present invention replaces the existing password/user identity based on the authentication program with a new digital signature authentication program. In the digital signature authentication program, the first Ηττρ request title is preferably extended by the client authentication information. It is not subject to the authentication procedure used by the destination server and does not require the server to request authentication information. Preferably, the authentication information includes a client-side credential signed by the credential institution including the public key of the client, and a hash value calculated by requesting the receipt of the request (four), and is private to the client. The keys are encrypted together. The credential and digital signature are incremented when the 标题ττρ-request header is established in the client system itself, or may be added later as a gateway, proxy or channel in the server. A destination server that does not support the new digital signature authentication program will easily ignore the credentials and digital signatures in the HTTP-request header and automatically launch its own credentials. This release date simplifies the existing digital signature authentication program and allows different authentication procedures to coexist without changing the HTTP protocol or causing unnecessary network congestion. 7 1322609 [Embodiment] With regard to Figs. 1A and 1B, a user-server end environment in which the present invention can be preferably used is described. However, it should be noted that the present invention can be used in every communication protocol client-side environment that allows for header extensions and does not violate common protocol usage. Therefore, Benfing and its preferred embodiments can be described and explained in most currently known HTTP-Agreement Orders. The HTTP-Protocol (Hyper File Transfer Protocol) is an application layer protocol for distributed systems. It is a set of rules for exchanging files (text, pictures, images, sounds, videos, and other multimedia files). Any web server 3 contains an HTTP-mail transceiver or so-called HTTP-server 4, a program designed to wait for HTTP-requests and process such requests when they arrive. Further, each of the client machines 1 includes a web browser or so-called τττρ_user 2 to send a request to the web server 3. When the browser user enters a request by opening a web file (type a uniform resource location) or clicking a hyperlink, the browser will create an HTTP request and send it to the internet protocol bit displayed in the URL. site. The HTTP-server 4 in the target server.3 receives the request and after processing, the request file is returned. In another client-server environment, the client communicates with the server 3 via a gateway, channel or proxy server 5 (see Figure 1B). Usually HTTP occurs on TCP/IP (Transmission Control Protocol/Network Protocol), whereas HTTP does not rely on TCP/IP. TCP defines a set of rules for exchanging information with other network nodes at the packet level. IP defines a set of rules for sending and receiving information at the Internet address layer.

- HTTP-request header contains Ηττρ method (GET , head, p〇ST

[s] 8 1322609 etc.), Universal Resource Identification (URI), protocol translation and optional additional information. An HTTP-response contains a status line that indicates the success or failure of the request, a description of the information in the response (after the message), and the actual information request. As for Figure 2, this is a description of the basic architecture of a prior art HTTP-request header. Every HTTP-request must contain at least one title. Only HTTP-mail requests contain titles and lots of material. The information below is appropriately included in the HTTP-title: Resources accessed by HTTP-requests (eg, files, servos, etc.) 4 hostname of the server (eg, www.ibm.com) Browser name and version (for example, Netscape Version 7.1) Client operating system (for example, Windows XP) Feature settings that can be understood by the browser (for example, ISO-8859-1) Each HTTP-title can include no HTTP-protocol Defined, supplemental information that does not conflict with existing applications that use the HTTP-protocol. This means that an application that uses the HTTP-protocol and is not set to process supplemental information can simply ignore the supplemental information and not bother its execution. As for the third figure, the 11-butyl is described in accordance with the present invention. - Request a rich creative structure of the title. In accordance with the present invention, the additional information described below must be included in the HTTP-Request header: The client credential includes the public key and is signed by a credential authority, and the digital signature is in the HTTP-Request header and if there is an HTTP-Principal (Post) ) is calculated. Credentials and digital signatures can be processed by specific tools on the server. A client credential is a file assigned by a trusted third party organization that combines a public key with a specific person. The trusted organization will ensure that the information contained in the certificate in accordance with 9 1322609 is valid and correct. The voucher is standardized by 5〇9. They should include the digital signature of the third-party organization, the name of the person who owns the public key, and the public key itself. With respect to Figures 4A through 4C, there is a preferred embodiment described herein for inserting client credentials and digital signatures into the Ηττρ_ request header. With respect to Figure 4A, the first embodiment of the present invention is described herein as inserting the client credential 16 along with the digit signature 18 into the HTTPjt request header 12. The client system 1 includes a browser 2 with signature capabilities. The browser 2 generates an HTTPS 'question header 12, accesses the private key of the client stored securely in the local file system, encrypts a messy signal value generated by the HTTP-request header and if present, along with the The private key leads to a digital signature of 18. The digital signature 18 is inserted in the Ηττρ_ request header 12 along with the client credential 16 containing the public key. The extended HTTP-request header 14 is sent to the Ηττρ_ server 4 of the initialization authentication program. The client credential information 16 can be verified from the HTTP-Request header as part of the HTTP-server or as an authentication element 6 of the independently-existing component. The verification work can be performed by checking the voucher signature of the voucher authority or by comparing it with the known voucher included in the voucher repository 9. Using the public key contained in the client credential 16, the digit signature 18 contained in the Ηττρ request header 12 is interpreted as a hash value calculated by the client system 丨. Using the same hash value algorithm, the hash value is calculated in 11 Ding 1 > request header 12 and if present. If the hash value match authentication is completed and the authentication is successful, access to an application 8 is granted. With regard to FIG. 4B, the second embodiment of the present invention describes the insertion of the client credential 18 along with the digital signature 16 into the HTTP request header 12. Now the liu

[SI 10 1322609 See 2 has the function of communicating with the smart card 10 through a smart card reader 10. The browser 2 generates - Ηττρ_ request title 'establishing communication with the smart card 1' in its female full module containing - private key and client side credentials of the smart card 10 interpreted in the HTTP-title and if it exists The hash value generated on the body, along with the private key (digital signature) 'a digital signature 18 along with the client credential 16 is returned to the browser 2β. The digital signature 18 containing the public key is inserted in the HTTP along with the client credential 16 - Request header 12. The extended HTTP-request header 14 is sent to the HTTP-server 4 that initializes the authentication program by using an authentication element (see description of Figure 4a). With respect to FIG. 4C, the third embodiment of the present invention describes the insertion of the client credential 16 together with the digital signature 18 into the HTTP-request header 12. In a third embodiment, the client system includes a signature component 2 owned by itself. The role of the component acting as a proxy server runs on the client system 1 that is co-located with the browser 2. The browser 2 is configured to use the proxy server 2〇. From this, the viewer 2 sends a regular HTTP-request header 12 to the signature component 20, and then the signature component 20 inserts the similarity of the credential 16 and the digital signature 18 into the embodiment described above. . By using an authentication element (see description of Fig. 4A), the extended HTTP-eyes are sent to the ηττρ_ server 4 of the initialization authentication program. Regarding the 4D FIGURE, a fourth embodiment of the present invention is described herein for inserting the client credential 18 along with the digit signature 16 into the HTTP-request header 12. In this embodiment, the client-request (la/2a; lb/2b) is sent via a proxy server 22 having an interleave element 2〇. The plug-in component 20 is in the same conversation with the encoding hardware 24 containing the private key and its signed credentials, which will be encrypted with a private transmission (digital signature) by the HTTp-request header 12 and its generated body if present. The hash value is returned to the plug-in element 20 along with the client credential 16 by inserting it into the HTTPjf for the title. The extended HTTP-request flag s 14 is sent to the Ηττρ server 4 which initializes the authentication program by using the authentication element (see the description of Fig. 4A). In summary, because the present invention describes additional header data in the Ηττρ protocol, all existing components of the server and client that are capable of processing additional data in the header can work together. If one of the systems is unable to process additional information, all things will work as they are known today. In order to maintain the existing foundation of hundreds of millions of installed client browsers, an additional signature software can handle HTTP extensions by acting as a proxy component on the local client machine (see Figure 4C). In the company's network (such as the corporate intranet), this can even be handled by a central proxy server (4th: Figure). This functionality can be fixed in future web browser versions (Figure 4A) The transition to the new paradigm in this way can occur over time. Digital signatures can be created using a signed smart card or any other signature hardware. Similarly, one is stored on the client computer. A pure software solution for the coded key is also possible. Figure 5 shows an example of a server-side call environment using the present invention. In this example, it is assumed that an application 5 is stored via an entry server 3. In this state of the art, the situation is obtained by storing the authentication data of the client on the server accessible by the portal server 3 and the application server 5 (for example, Microsoft Corporation's .NET passport) or The authentication information of the application server needs

[S 12 1322609 is stored in the manner of being stored on the portal server 3. Both methods require the user to store his/her data on a third-party organization system that is subject to many security protocols. As explained in Figures 4A through 4D, the digital signature requires that no one serving a person needs to store user data. The portal word processor 3 can check the identity of the requester against its user database 4 and pass the request to the application server 5'. The application server can use its user database 6 to do the same thing. The client 1 accesses the application server 5 through the portal server 3 and the client lb can directly access the application server 5. The application server 5 can use its own user database 6 to retrieve the wheel information for the user. Since the application server 5 may only want to process requests through the portal server 3, this method even provides higher security. In this case, the portal server 3 transmits the request and also signs it. This causes the application server to check both sets of signatures to allow or deny access to their services. The client la will gain access to the application server 5 and the client lb will not be served because his request did not pass through the portal server. 3» Regarding Figure 6, a data identification is identified in accordance with the present invention. Process. The client browser is ready to request the server 10. In a suitable embodiment of the invention it will be checked if the signature of the HTTP-Request header is translated in 2〇. If not, the user browser will send a request that is not signed to the server 4 and the server will check if the sign 50 is needed. The server can send an error message to the client 50 if the signature is needed. If no signing is required, the server will provide access to the required information 60. If the signature is converted on the client browser, the credential and digital signature will be inserted into the HTTP. request header and the Ηττρ request header will be sent to the server 13 ί S1 1322609 30. By setting the search path of the special domain to the HTTP request header, the server can re-discover the identity of the requester from the credential (authentication) 35. The client's credentials contain the requester's name and public key. Because it is signed by a trusted authority, the server can check that it is a valid credential issued by a trusted authority. It is possible to confirm that the information is indeed sent by the certificate owner, since only the owner of the private key belonging to the voucher can generate a digital signature value in the HTTP-request header, which can be above the HTTP-request header data. It is calculated and can be recognized by the use of the public key contained in the voucher. If the authentication is successful, the server will provide access to the requested material 60. With regard to Figures 7A and 7B, it is described herein that the inventive authentication procedure is used to exchange information between a web browser (client) and a web server (server segment) using prior art authentication procedures. Specific episode. For example, during a transaction, the client accepts/sends the material (eg, a series of text or hypertext language pages or a formatted data section such as xml) from/to the online shopping system, until The order is confirmed by a special data transfer operation (such as HTTP mail). In today's application, during this process, the server issues a request to obtain the user's identity and password from the client. The user has to manually provide this information before it is sent to the server by the client application (see Figure 7A). In an application corresponding to the present invention (see Figure 7B), the UE signs the HTTP-Request header data sent to the server by means of a digital signature. The server can easily identify the client by signing. Since each transmitted data item is related to the identity of the user, there is no need to request or provide the user ί S] 14 1322609 identity and password. The server can retrieve the stored information of the client and use the information to prepare the data (personalization, profile page) to be transmitted to the client. Examples of data used to represent personalization are the user's address (where the ordered item is sent), the user's shopping history, the user's shopping cart, the web page accessed by the last call, etc. . By checking the identity of the user (can be executed at any time in the process), the server can find that the user has not accessed the URL before. The server can then send a message containing a request specifying a user's preferences and detailed user profiles (contour pages). The user provides the information, and the client application sends it to the service and the ship n stores the data for setting it in the material. Since each data transmission is signed, the user identity of the client will be known to the player as soon as possible on the first page of the website. Personalization can occur earlier throughout the process. When the user chooses to turn off the signing server to recognize this fact and send - a page containing (not shown) indicating the opening or signing of a particular episode using the traditional user identity/password. BRIEF DESCRIPTION OF THE DRAWINGS [0009] The above-mentioned additional objects, features and advantageous factors will be apparent from the detailed description below. The novel features of the present invention will be set forth in the scope of the appended (four) patent application. When the invention is read in conjunction with the accompanying schema, the invention itself, and with a preferred mode of use, a more advanced goal and advantageous factors for it will be implemented by reference to the following The detailed description of the examples is fully understood, wherein: 15 called 2609, summer diagram A/B shows the prior art in the HTTP-client_word server environment, where the invention is suitably used; The figure shows the basic structure of a typical prior art in the HTTP-title; the third circle shows the creative structure of the Ηττρ header with the voucher and the digital signature; the 4A-4D shows the insertion of the voucher along with the digital signature into Ηττρ The preferred embodiment of the header t results in an inventive structure for the HTTP-request header; Figure 5 shows an example of a server-client communication environment using the present invention; Figure 6 shows a client-server interface In the environment, according to Figure A, the use of HTTP to identify the creative structure of the authentication data flow - the selected embodiment; and the 7A, 7B figure shows - based on the previous online shopping transaction program example of prior art recognition The present invention and comparative procedures inventive full authentication procedure. [Main component symbol description] 2 HTTP-client 4 HTTP-server 6 user database 9 authentication database 12 HTTP-request header 16 client certificate 20 signature component 24 encoding hardware 1 client machine 3 network server 5 Proxy Server 8 Application 1 〇 Smart Card Reader 14 Extended HTTP-Request Title 18 Digital Signature 22 Proxy Server 60 Requested Information 16

Claims (1)

1322609 I 十χ 1 Patent Application: Scope 1. A method for authenticating a client in a client-server environment, wherein the client-server environment uses a communication protocol that allows for not violating the The extension of the header request is performed under the communication protocol, wherein the client includes the following steps: forming a title request (10) inserting the client authentication information into the title request, so that the extended request for seeking (20) is not affected by the servo The authentication process used by the device is now governed and does not require the vocabulary to request authentication information, wherein the authentication information includes a client-side name and a public-side public key: one of the client-side credentials' and one of the header requests formed in the title a one-digit signature on the value, and the header request includes a client credential using the private key of the client, sending the extended header request to a server (3〇), and if the authentication is successful (35, 60), from the The server receives the information. 2. The method of claim 2, wherein the communication protocol is an HTTP-agreement. The method of claim 1, wherein the authentication information is included in a first header request for establishing a call with the server. The method of claim 2, wherein the authentication information is automatically inserted into the title request by a browser of the user. The method of claim 4, wherein the client browser receives the authentication information from a smart card (1) via a smart card reader. The method of claim 1, wherein the authentication information is automatically inserted into the title request by a client signature component (20), and the client signature component is via a smart card The reader receives the authentication information from a smart card (1〇). 7. A method for authenticating a client (la, lb) in a client-server environment, wherein the client-server environment uses a communication protocol that allows for not violating the protocol An extension of the header request is performed, wherein a system (22) establishes communication between the client (la, lb) and the server (3), wherein the system (22) comprises the following steps: from the client ( La, lb) receives a header request, inserts authentication information into the header request, such that an extended title request (20) is not subject to the authentication procedure used by the server, and the server is not required to request authentication information. The authentication information includes a client credential having a client name and a public key of the client, and a digit signature formed on a hash value of the title request, and the header request includes a client credential using the private key of the client, and the sending The expanded title request is sent to a serving device (3), and if the authentication is successful 'receives information from the server (3). 8. The method of claim 7, wherein the system (20) can be a proxy server, a gateway or a channel. 9. The method of claim 7, wherein the communication protocol is an HTTP- 18 1322609 protocol, the title request is an HTTP header request, and the authentication information is automatically borrowed by an insert component (20) Inserted into the HTTP header request, the plug-in component can receive the authentication information from a signature component (24). 10. A method for authenticating a client in a client-server environment, wherein the client-server environment uses a protocol that allows a header request to be extended without violating the protocol, wherein the server The method comprises the steps of: receiving a client header request containing authentication information, wherein the authentication information comprises a client credential having a client name and a public key of the client, and requesting the title using the private key of the client A digital signature generated on the entire content, the authentication information included in the header request is verified by a server authentication component, and if the authentication is successful, information is provided to the client. 11. The method of claim 10, wherein the communication protocol is an HTTP-agreement, the header request is an HTTP header request, and the authentication component performs the following steps: accessing the credentials included in the client a public key in which the public key is used to interpret the digital signature contained in the HTTP header request to cause a hash value, applying the same hash algorithm used by the client to the HTTP header request, and if Matching the hash values is considered successful. 19 1322609 12. A server system (3) for authenticating a client (1) in a client-server environment, wherein the client-server environment uses a communication protocol, the protocol allows Violating the extension of the header request under the communication protocol, wherein the client (1) provides authentication information to the server system in the header request, wherein the server system (3) comprises: an authentication component (4) 'the authentication The component has a function of reading the authentication information included in the incoming user title request, wherein the authentication information includes a client credential having a client name and a public key of the client, and a one generated on the entire content of the title request A digital signature that includes a client credential that uses the private key of the client, and verifies the authentication information without requesting the authentication information from the client. 13. A client system that is to be authenticated by a server system in a client-server environment, wherein the client-server environment uses a protocol that allows for headings without violating the protocol An extension of the request, wherein the client system comprises: a browser (2), and a component for inserting the user's soul information into the title request, independent of the authentication program used by the word server And the server does not need to request authentication information, wherein the authentication information includes one of a client-side name and a client-side public key of the client-side public key and a hash value of one of the contents of the title request using the private key of the user-side. Digital signature. 14. The client system of claim 13, further comprising [S] 20 1322609 - a smart card reader (1), and a smart card having a private ride - a security module and a client-side credential containing a client name and a private item, wherein the smart card provides the voucher along with a digital signature to the plug-in component, wherein the digital signature is a result of a hashed request for the encrypted title request, the title The request contains the voucher information obtained by the private key. 15. 15. - a proxy feeder system (22) for providing a client authentication information server system (3) λ, the proxy servo system (22) has a client system (1) called and a feeding device The communication connection of (3), wherein the communication protocol for the systems allows the title request to be extended without violating the communication protocol, which causes the proxy server system (22) to include: 20), which is used for inserting the client credential and the digital signature into the title request received by the client, the foregoing action is not supported by the authentication program used by the feeder, and the device is not provided. End requesting authentication information, and a signature component (24) for establishing a digital signature and for providing it with the client credentials to the proxy insertion component (2). A computer program product in the internal memory of a digital computer, if the production is executed on the computer, it includes a part of the software code to perform the method according to any one of claims 1 to 11. 21