Tls-based authentication method without the intervention of a certification authority

Abstract

A TLS-based authentication method according to the present invention comprises the steps of: obtaining a certificate for TLS authentication from a certification authority at a web server; transmitting a delegation request to a delegation entity at the web server; receiving, at the web server, a public key among a public key-private key pair generated by the delegation entity in response to the delegation request; generating delegation data based on the public key at the web server; generating delegation proof data of the same version as the delegation data at the web server; storing the delegation proof data in a delegation proof data repository at the web server; and transmitting the certificate and delegation data to the delegation entity at the web server.

Description

Technology Field

[0001] The present invention relates to a TLS-based authentication method without the intervention of a certification authority. Background Technology

[0002] Figure 1 is a diagram illustrating the TLS protocol in the prior art.

[0003] The Transport Layer Security (TLS) protocol on the web is an end-to-end protocol that provides encrypted communication between a browser (120) and a web server (110) (client and server). This means that communication between the browser (120) and the web server (110) takes place directly without any intervention in between, and the content of the communication is protected so that it cannot be viewed from the outside.

[0004] However, in today's web, there is an intermediate entity (or authority delegation entity) such as a Content Delivery Network (CDN) between the browser (120) and the web server (110), and it is rare for TLS communication to be performed simply between the browser (120) and the web server (110).

[0005] In this case, there are concerns regarding data security and compliance due to the intervention of intermediary entities such as CDNs, and in the case of sensitive data, there is an issue that these problems must be additionally considered. Prior art literature

[0006] Published Patent Application No. 10-2014-0076125 (June 20, 2014) The problem to be solved

[0007] The problem that the present invention aims to solve is to provide a TLS-based authentication method without the intervention of a certification authority, which enables an authentication subject to manage (add, delegate, and revoke) TLS authentication keys without the intervention of a certification authority.

[0008] However, the problems that the present invention aims to solve are not limited to those described above, and other problems may exist. means of solving the problem

[0009] A TLS-based authentication method according to a first aspect of the present invention for solving the aforementioned problem comprises: a step of obtaining a certificate for TLS authentication from a certification authority at a web server; a step of transmitting a delegation request to a delegation entity at the web server; a step of receiving a public key among a public key-private key pair generated by the delegation entity in response to the delegation request at the web server; a step of generating delegation data based on the public key at the web server; a step of generating delegation proof data of the same version as the delegation data at the web server; a step of storing the delegation proof data in a delegation proof data repository at the web server; and a step of transmitting the certificate and delegation data to the delegation entity at the web server.

[0010] Additionally, a TLS-based authentication method according to a second aspect of the present invention comprises: a step of requesting authorization proof data from a web server in a browser; a step of receiving the requested authorization proof data from an authorization proof data repository of the web server in the browser; a step of sending a client hello message to an authorization entity in the browser; a step of receiving a server hello message from the authorization entity in response to the client hello message in the browser; a step of verifying whether the authorization entity has received authentication authority based on the server hello message in the browser; and a step of exchanging a symmetric key for encryption with the authorization entity in the browser as the verification is completed.

[0011] A computer program according to another aspect of the present invention for solving the above-mentioned problem is combined with a computer, which is hardware, to execute a TLS-based authentication method without the intervention of a certification authority, and is stored on a computer-readable recording medium.

[0012] Other specific details of the present invention are included in the detailed description and drawings. Effects of the invention

[0013] According to one embodiment of the present invention described above, through an improved TLS protocol authentication data model for authentication key management without the intervention of an authentication authority and a data structure capable of adding, delegating, or revoking authentication keys, it is possible to securely add, delegate, or revoke authentication keys having X.509 authentication authority to a third party.

[0014] In addition, X.509 authentication principals, such as web service operators, can securely delegate X.509 authentication keys to third parties, such as CDNs, and revoke the securely delegated authentication keys.

[0015] The effects of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by a person skilled in the art from the description below. Brief explanation of the drawing

[0016] Figure 1 is a diagram illustrating the TLS protocol in the prior art. Figure 2 is a diagram illustrating TLS communication in which an authority delegation entity exists in the prior art. Figure 3 is a diagram illustrating an example of the operation process of a conventional SSL Splitting method. Figure 4 is a diagram illustrating an example of the operation process of a conventional Keyless SSL method. Figure 5 is a diagram illustrating the existing TLS authentication data model. FIG. 6 is a diagram illustrating a TLS data model proposed in one embodiment of the present invention. FIG. 7 is a flowchart illustrating an authentication authority delegation method among TLS-based authentication methods according to an embodiment of the present invention. FIG. 8 is a flowchart for explaining a TLS authentication scenario among TLS-based authentication methods according to an embodiment of the present invention. Specific details for implementing the invention

[0017] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the present invention, and the present invention is defined only by the scope of the claims.

[0018] The terms used in this specification are for describing embodiments and are not intended to limit the invention. In this specification, the singular form includes the plural form unless specifically stated otherwise in the text. The terms "comprises" and / or "comprising" used in this specification do not exclude the presence or addition of one or more other components in addition to the components mentioned. Throughout the specification, the same reference numerals refer to the same components, and "and / or" includes each of the mentioned components and all combinations of one or more. Although terms such as "first," "second," etc., are used to describe various components, these components are not limited by these terms. These terms are used merely to distinguish one component from another. Therefore, the first component mentioned below may be the second component within the technical scope of the invention.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) may be used in a meaning commonly understood by those skilled in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0020] In the following, the background of the conception of the present invention will be explained first to aid the understanding of a person skilled in the art, and then the present invention will be described in detail.

[0021] First, I will explain the details regarding X.509 certificates.

[0022] Currently, authentication on the web is performed through X.509 certificates issued by a Certificate Authority (CA) after verifying the identity of the subject. The process by which a Certificate Authority issues an X.509 certificate to a subject is as follows.

[0023] ① First, the certifying entity, such as a website, individual, or company, submits its identity information and the public key to be used in the subsequent certification process to the certification authority.

[0024] ② Next, the certification authority verifies the submitted information through an identity verification process. This process can be performed in various ways. For example, verification is possible through diverse methods, such as written verification involving the submission and confirmation of documents; email verification where a verification link is sent to a specific email address and the subject clicks the link to confirm; telephone verification; and web process verification, which confirms the subject's information through web-based forms.

[0025] ③ Next, once verification is complete, the Certification Authority signs an X.509 certificate containing the certification subject's identity information and public key with the Certification Authority's private key and issues it to the certification subject.

[0026] In this case, the private key paired with the public key included in the X.509 certificate is possessed only by the certifying subject. Subsequently, the certifying subject can prove that the identity specified in the X.509 certificate represents them by proving ownership of the said private key.

[0027] Next, I will explain the details regarding the TLS protocol.

[0028] The TLS protocol is currently widely used as a method for exchanging encrypted packets over networks. In particular, it is frequently used to protect passwords, financial information, and other sensitive data from external attacks during communication between browsers and web servers. The TLS protocol performs two main processes: authentication and encryption. The communication process via TLS can be summarized as follows.

[0029] ① First, when a user enters the address of the website they wish to access into the browser, the browser begins communicating with the web server hosting that website.

[0030] ② Next, the web server generates the X.509 certificate previously issued by the Certificate Authority and proof of ownership data for the private key corresponding to the X.509 certificate's public key, and transmits them to the browser. At this time, the X.509 certificate includes the website address and the web server's public key.

[0031] ③ Next, after receiving the response from the web server, the browser authenticates the web server through the following process.

[0032] ③-1) The browser checks whether the website address specified in the X.509 certificate provided by the web server matches the address it accessed.

[0033] ③-2) Verify whether the private key ownership proof data provided by the web server can be verified with the web server's public key included in the X.509 certificate.

[0034] ③-3) Verify whether the signature of the X.509 certificate can be verified using the public key of a certificate authority trusted by the browser. At this time, the browser has all the public keys of the certificate authorities it trusts in advance.

[0035] ④ Next, when authentication is successfully completed, the browser and the web server exchange a secret key for encryption.

[0036] Subsequently, encrypted communication begins, and data is transmitted in an encrypted state. Meanwhile, since the encryption process is not a technical feature intended by the present invention, a detailed description thereof will be omitted below.

[0037] Next, we will explain the problems with the conventional TLS protocol.

[0038] The TLS protocol on the web is an end-to-end protocol that provides encrypted communication between a browser and a web server. However, in today's web, an authorization delegation entity called a CDN exists between the browser and the web server, making it very rare to perform TLS communication simply between the browser and the web server.

[0039] Figure 2 is a diagram illustrating TLS communication in which an authority delegation entity exists in the prior art.

[0040] Today, most web service providers use servers of CDN providers (230) installed around the world to provide web services, instead of using the web service provider's servers (210) to provide seamless services throughout the world. In this way, for web service providers (210) to provide services through the CDN (230), they must delegate authentication authority to the CDN (230) to provide services on their behalf.

[0041] However, since the TLS protocol is an end-to-end protocol that does not account for an intermediate entity such as a CDN (230) between a browser (220) and a web server (210), the TLS protocol standard does not specify a method to delegate authentication authority to a CDN (230). Thus, authentication authority is delegated in an abnormal way on the web today, the most representative method being the sharing of the web server's (210) X.509 certificate secret key. This violates the most basic rule of cryptography, which states that "only the owner of the secret key should know the secret key." Furthermore, delegating the secret key, which holds all authentication authority for the web service, to a third party, such as a CDN (230), can lead to significant risks.

[0042] Furthermore, nowadays, a small number of CDN providers manage the certificate secret keys of numerous web service providers, which can become a Single Point of Failure (SPoF) where malicious attackers can inflict massive damage by attacking a single system.

[0043] In situations where a certificate's private key has been shared with a CDN, reliable certificate revocation is essential to discontinue use of the CDN or to revoke delegated authority due to a problem with the CDN. If certificate revocation is not performed properly, a CDN or an attacker possessing the revoked certificate and private key can still impersonate the website and gain authentication. However, due to the centralized X.509 certificate management structure, reliable X.509 certificate revocation is extremely difficult.

[0044] The revocation of X.509 certificates, which include the certificate subject's authentication key, is possible only through a Certificate Authority, and currently on the web, only a few dozen trusted Certificate Authorities manage billions of X.509 certificates. Since Certificate Revocation Lists (CRLs) for billions of X.509 certificates must be managed by only a few dozen Certificate Authorities, under this structure, the size of a CRL can reach up to approximately 100MB. This size is unrealistic for periodically distributing to all browsers worldwide.

[0045] Therefore, each browser summarizes and uses CRLs in its own way. For example, Google's Chrome includes less than 1% of major certificates in its CRL (CRLSet) for verification. In other words, for certificates not included in the 1%, the authentication process is performed without verifying whether they have been revoked. Not only Chrome, but also Mozilla's Firefox and Apple's Safari browsers use this method to verify revocation.

[0046] The main categories of methods for resolving such X.509 certificate authority delegation issues are SSL Splitting and Keyless SSL.

[0047] Figure 3 is a diagram illustrating an example of the operation process of a conventional SSL Splitting method.

[0048] As illustrated in FIG. 3, the SSL splitting method is a protocol in which a web service provider (310) issues a custom certificate (301) to an agent (330), such as a CDN, through a connection with a certification authority, and the agent relays traffic after establishing separate TLS handshakes between the service user and the provider.

[0049] However, this SSL splitting method is a structure in which the CDN (330) acts as an intermediary between the service user (320) and the provider (310), which does not align with the purpose of the CDN used for performance improvement or security.

[0050] In addition, direct intervention by the certification authority (340) may be required during the process of issuing a delegated authority certificate to the CDN (330), and it does not provide a guarantee of transparency regarding whether the user (320) communicates with the CDN (330) or directly with the web service provider (310). Although research improving SSL Splitting is continuously being published in academia, it is understood that the SSL Splitting method is not widely used in the current CDN market because it has not completely overcome the aforementioned limitations.

[0051] Figure 4 is a diagram illustrating an example of the operation process of a conventional Keyless SSL method.

[0052] As illustrated in FIG. 4, the Keyless SSL method is a technology in which a private key is securely stored in a key server (450) managed by a web service provider (410), and when a CDN (430) requests the key server (450) to perform a decryption operation that is required only once during the handshake process with a user (420), the key server (450) decrypts the data and returns it to the CDN (430). Subsequently, the CDN (430) can securely provide services by exchanging a symmetric key with the user (420) based on the decrypted data.

[0053] However, in the case of Keyless SSL, the web service provider (410) has the burden of managing a key server (450) that requires high availability, and due to this system operation structure, the web service provider often does not manage the key server (450) but rather the CDN (430) manages it. Therefore, the Keyless SSL method can be seen as a structure that still violates the fundamental law of PKI that “private keys must be managed by the private key owner.”

[0054] To resolve the X.509 delegation of authority issues discussed so far, the following requirements must be satisfied: delegation of authority without exposing the X.509 certificate private key, revocation of the delegated key, and the self-management of both delegation and key revocation without intervention from the Certificate Authority.

[0055] To resolve these issues, a TLS-based authentication method according to one embodiment of the present invention provides a method that enables an authentication subject to manage (add, delegate, and revoke) TLS authentication keys without the intervention of a certification authority. To this end, an improved TLS protocol authentication data model is proposed for managing authentication keys without the intervention of a certification authority. Additionally, a data structure is proposed that allows for the addition, delegation, and revocation of authentication keys possessing X.509 certificate authentication authority without the intervention of a certification authority. Furthermore, a TLS authentication procedure using authentication keys managed without the intervention of a certification authority is proposed.

[0056] Before describing the specific invention, a general overview of the conventional TLS authentication data model will be provided.

[0057] Figure 5 is a diagram illustrating the existing TLS authentication data model.

[0058] Figure 5 shows a data model for the generation and verification of a TLS handshake message used in the TLS authentication process. The TLS handshake message (500) consists of a Certificate (510) message and a Certificate Verify (520) message.

[0059] First, the components of the authentication information message include an X.509 certificate containing the web server's URL and public key, and an X.509 certificate containing the identity information of the CA that issued the certificate to the web server (x509Chain, 511). It also includes a private key paired with the X.509 certificate public key of the authentication subject (PrivateKey, 512).

[0060] The authentication verification information message contains the value (521) of the TLS handshake message signed with the PrivateKey.

[0061] Referring to Figure 5, the existing TLS handshake authentication process is summarized as follows.

[0062] ① First, the browser connects to the web server pointed to by the URL and sends a ClientHello message.

[0063] ② Next, the web server generates a TLS handshake message and sends it to the browser.

[0064] ②-1) At this time, the web server generates data to be included in the x509Certificate message and other TLS handshake messages as shown in FIG. 5.

[0065] ②-2) Sign the message generated in ② with a private key paired with the web server's X.509 certificate public key, and then generate a certificate verification information message containing the signature.

[0066] ②-3) Generate a TLS handshake message using the message generated in ②2) and send it to the browser.

[0067] ③ Next, the browser verifies the TLS handshake message received from the web server. At this point, the following items relate to the verification method and are irrelevant to the verification order.

[0068] ③-1) Verify the certificate verification information message using the web server's X.509 certificate public key included in the x509Certificate message.

[0069] ③-2) Verify whether the web server X.509 certificate was issued by a trusted certificate authority.

[0070] ③-3) Verify that the URL specified in the web server X.509 certificate matches the URL you accessed.

[0071] Hereinafter, a TLS-based authentication method without the intervention of a certification authority according to an embodiment of the present invention will be described in detail with reference to FIGS. 6 to 8.

[0072] FIG. 6 is a diagram illustrating a TLS data model proposed in one embodiment of the present invention.

[0073] Referring to FIG. 6, the present invention constructs a TLS data model (600) by adding delegation of authority data (DDC, 613) and delegation of authority proof data (DDCProof, 630), unlike the existing data model. In the existing X509 structure, the X.509 certificate of the certification authority and the web server, and a private key paired with the web server's X.509 public key were included. Accordingly, the public key and private key of the web server's X.509 certificate were used during the TLS handshake process and data signing.

[0074] However, the TLS data model (600) according to one improved embodiment of the present invention includes data (authorization data, DDC, 613) containing information about the delegated authority delegation entity and the set of public keys used by the authority delegation entity, and a private key (PrivateKey, 612) paired with one of the public keys included in the authority delegation data. That is, when verifying or signing the TLS handshake message (600), one embodiment of the present invention does not use the public key and private key of the X.509 certificate, but uses the public key specified in the authority delegation data (613) and the private key paired with that public key. Furthermore, during the TLS authentication process, the private key of the web server X.509 certificate is not used at all, but is used only when generating or updating the authority delegation data (613) and the authority delegation proof data (630).

[0075] The following Tables 1 and 2 show authority delegation data and authority delegation proof data according to an embodiment of the present invention.

[0076] DDC data structure Serial Serial number of the X.509 certificate to which authentication authority has been delegated Version A number that increases by 1 each time the DDC changes, starting from the initial value. Expiration date DDC expiration date CDNs Entity ID An ID used to identify a specific CDN among multiple CDNs delegated through the DDC. It uses a unique value within the DDC. Delegated key ID An ID used to identify a specific TLS authentication key among multiple TLS authentication keys existing within the DDC's Delegated Keys. It uses a unique value within the DDC. Description Description representing information about the object Since CDNs is an array with Entity ID, Delegated key ID, and Description datasets, authentication key delegation to multiple CDNs is possible through the CDNs item. X.509 subject Entity ID When web service operators perform TLS authentication through DDC, they can specify the authentication key they will use, just like CDNs. They use a unique value within the DDC. Delegated key ID Description Delegated keys Delegated key ID The Delegated keys item contains public keys used for multiple TLS authentications, and is an ID used to identify a specific public key. It uses a unique value within the DDC. Delegated key Public key used for TLS authentication Metadata Public key and authentication metadata used for TLS authentication (algorithm, cipher suites used for TLS, etc.) Delegated keys is an array containing a Delegated key ID and a Delegated key Metadata dataset, so multiple public keys used for TLS authentication can be specified through the Delegated keys item. Signature DDC data signed with the private key of a web server X.509 certificate

[0077] DDCProof data structure Serial Serial number of the X.509 certificate to which authentication authority has been delegated Version A number synchronized with the DDC version. Expiration date DDCProof expiration date Signature DDCProof data signed with the private key of a web server X.509 certificate

[0078] FIG. 7 is a flowchart illustrating a method for delegating authentication authority among TLS-based authentication methods according to an embodiment of the present invention. First, after the web server obtains a certificate for TLS authentication from a certification authority (S701), it transmits a request to use a CDN service provided by the delegation entity (CDN service) to the delegation entity. In this case, a request for delegation of authority is also transmitted together (S702).

[0079] Next, the delegation entity securely generates a secret key and public key pair to be delegated X.509 authentication authority for the web server on the delegation entity's local system (S703) and transmits the public key to the web server (S704).

[0080] Next, the web server generates authorization delegation data based on the public key (S705).

[0081] In one embodiment, the web server assigns a Delegated Key ID for identifying the public key to the Delegated Key item that constitutes the delegated authority data. Then, the public key of the delegated entity is added to the assigned Delegated Key item. Additionally, delegated authority data can be generated by adding the public key and authentication-related metadata to the Delegated Key item.

[0082] In one embodiment, a web server may generate delegation data by assigning a delegation entity ID to a delegation entity item that constitutes the delegation data to identify the delegation entity, and adding the public key ID (Delegated key ID) of the delegation entity to the delegation entity item. Additionally, if necessary, delegation entity information may be specified in a Description item.

[0083] In one embodiment, when a web server adds a public key while the delegation data is already created, it may increase the count of the version item of the delegation data. Also, when the delegation data is initially created, it may assign an initial value to the version item of the delegation data. That is, when a public key is added to already created delegation data (DDC), 1 is added to the existing version value, and when delegation data is newly created and a public key is added, an initial value for version may be entered.

[0084] In addition, as an example, a value signed with authorization delegation data generated by a web server X.509 certificate secret key can be configured as a Signature item.

[0085] Next, the web server generates authorization proof data having the same version value as the authorization data (S706).

[0086] Next, the web server stores the authorization proof data in the authorization proof data repository (S707). At this time, the authorization proof data repository must be accessible to the browser to retrieve the authorization proof data during the subsequent TLS authentication process. The authorization proof data repository can be any repository that securely stores the authorization proof data and allows the browser to freely access and obtain the data later, such as an Authoritative DNS, a decentralized repository, or a centralized server.

[0087] Next, the web server passes the web server X.509 certificate and authorization delegation data to the authorization delegation entity (S708).

[0088] FIG. 8 is a flowchart for explaining a TLS authentication scenario among TLS-based authentication methods according to an embodiment of the present invention.

[0089] First, the browser requests the authorization certificate data from the web server (S801). That is, the browser requests the authorization certificate data stored in the web server's authorization certificate data repository, and accordingly receives the authorization certificate data stored in the authorization certificate data repository (S802).

[0090] At this point, the location of the delegation of authority data repository can be verified in various ways. For example, if the delegation of authority data is registered as a record in the DNS server used by the web server, the data can be naturally obtained during the DNS query process. In addition, there are methods such as the web server informing the browser of the location of the delegation of authority data repository during the TLS handshake process.

[0091] Next, the browser sends a Client Hello message to the authorization entity (S803). This Client Hello message contains information (DDCExtension) that TLS authentication is possible through the authorization data and authorization proof data in the browser.

[0092] Next, the delegated entity sends a Server Hello message to the browser in response to the Client Hello message (S804). At this time, the Server Hello message may include not only a TLS handshake message containing a web server certificate, but also a Delegated Entity ID for identifying the delegated entity through the delegation data, and a Delegated Key ID pointing to the location of the public key for verifying the TLS handshake message sent by the delegated entity. Meanwhile, the browser can sign the Certificate Verify information included in the TLS handshake message using a secret key paired with the public key pointed to by the Delegated Key ID.

[0093] Next, the browser verifies whether the authorization delegation entity has received authentication authority from the web server based on the server hello message (S805).

[0094] In one embodiment, a browser can verify an X.509 certificate chain in the same manner as before. That is, it can verify a CertificateVerify message using an X.509 certificate containing the web server's URL and public key, or check whether the URL specified in the X.509 certificate matches the URL it accessed. Alternatively, it can verify whether the certificate was issued by a trusted certificate authority based on an X.509 certificate containing the identity information of the certificate authority that issued the certificate to the web server.

[0095] In one embodiment, the browser can verify the signatures of the authorization data and the authorization proof data based on the public key of the web server certificate included in the TLS handshake message.

[0096] In one embodiment, the browser compares the values ​​of the version items of the authorization delegation data and the authorization proof data. If the comparison result shows that the two version values ​​are identical, the browser can determine that the authorization delegation data is valid.

[0097] Furthermore, the browser may determine that the authorization data is valid if, as a result of the comparison, the value of the version item in the authorization proof data differs from the value of the authorization data version item within a pre-configured range. In other words, considering cases where synchronization between the authorization data and the authorization proof data versions is delayed due to reasons such as network latency, the authorization data may be determined to be valid even if the version of the authorization proof data is smaller than the version of the authorization data by a specific value set by the web server. In all other cases, the authorization data is determined to be invalid.

[0098] In one embodiment, a browser can verify the signature of the certificate verification information included in a TLS handshake message based on the public key of the delegation entity included in the delegation data. In this case, the public key capable of verifying the certificate verification information signature (CertificateVerify) within the delegation data can verify the signature of the certificate verification information through the public key existing in the array element of the delegation keys where the delegation key ID exists by searching for the array element of the delegation key item (Delegated keys).

[0099] Next, as verification is complete, the browser exchanges a symmetric key for encryption with the authorization delegation entity (S806).

[0100] Meanwhile, in the above description, steps S701 to S806 may be further divided into additional steps or combined into fewer steps according to an embodiment of the present invention. Additionally, some steps may be omitted as necessary, and the order between steps may be changed.

[0101] Meanwhile, in one embodiment of the present invention, a terminal on which a web server or browser operates may be configured to include a communication module, memory, and a processor.

[0102] The communication module may include both a wired communication module and a wireless communication module. The wired communication module may be implemented as a power line communication device, a telephone line communication device, a cable home (MoCA), Ethernet, IEEE1294, an integrated wired home network, and an RS-485 control device. Additionally, the wireless communication module may be composed of modules for implementing functions such as WLAN (wireless LAN), Bluetooth, HDR WPAN, UWB, ZigBee, Impulse Radio, 60GHz WPAN, Binary-CDMA, wireless USB technology and wireless HDMI technology, as well as 5G (5th generation communication), LTE-A (long term evolution-advanced), LTE (long term evolution), and Wi-Fi (wireless fidelity).

[0103] Memory stores programs that are operated by a processor. Here, memory is a collective term for non-volatile storage devices and volatile storage devices that retain stored information even when power is not supplied. For example, memory may include NAND flash memory such as compact flash (CF) cards, SD (secure digital) cards, memory sticks, solid-state drives (SSDs), and micro SD cards; magnetic computer memory devices such as hard disk drives (HDDs); and optical disc drives such as CD-ROMs and DVD-ROMs.

[0104] The processor can execute software, such as a program, to control at least one other component (e.g., hardware or software component) related to the web server or browser, and can perform various data processing or operations.

[0105] One embodiment of the present invention described above may be implemented as a program (or application) and stored on a medium to be executed in combination with a computer, which is hardware.

[0106] The aforementioned program may include code encoded in computer languages ​​such as C, C++, JAVA, Ruby, and machine language, which can be read by the computer's processor (CPU) through the computer's device interface, in order for the computer to read the program and execute the methods implemented in the program. Such code may include functional code related to functions that define the necessary functions for executing the methods, and may include control code related to execution procedures necessary for the computer's processor to execute the functions according to a predetermined procedure. Additionally, such code may further include memory reference code regarding where (address) additional information or media necessary for the computer's processor to execute the functions should be referenced in the computer's internal or external memory. In addition, if the processor of the computer needs to communicate with any other computer or server located remotely in order to execute the above functions, the code may further include communication-related code regarding how to communicate with any other computer or server located remotely using the communication module of the computer, and what information or media to transmit or receive during communication.

[0107] The above-mentioned storage medium refers to a medium that stores data semi-permanently and is readable by a device, rather than a medium that stores data for a short period of time, such as a register, cache, or memory. Specifically, examples of the above-mentioned storage medium include, but are not limited to, ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage device. That is, the above-mentioned program may be stored on various recording media on various servers that the computer can access, or on various recording media on the user's computer. Additionally, the above-mentioned medium may be distributed across networked computer systems, and computer-readable code may be stored in a distributed manner.

[0108] The foregoing description of the present invention is for illustrative purposes only, and those skilled in the art will understand that other specific forms can be easily modified without altering the technical spirit or essential features of the present invention. Therefore, the embodiments described above should be understood as illustrative in all respects and not restrictive. For example, each component described as a single unit may be implemented in a distributed manner, and components described as distributed may likewise be implemented in a combined form.

[0109] The scope of the present invention is defined by the claims set forth below rather than by the detailed description above, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof should be interpreted as being included within the scope of the present invention.

Claims

Claim 1 A TLS-based authentication method comprising: a step of obtaining a certificate for TLS authentication from a certification authority at a web server; a step of transmitting an authorization request to an authorization entity at the web server; a step of receiving the public key among a public key-private key pair generated by the authorization entity in response to the authorization request at the web server; a step of generating authorization data based on the public key at the web server; a step of generating authorization proof data of the same version as the authorization data at the web server; a step of storing the authorization proof data in an authorization proof data repository at the web server; and a step of transmitting the certificate and authorization data to the authorization entity at the web server, wherein the step of generating authorization data based on the public key at the web server includes: a step of assigning an authorization key ID for identifying the public key to an authorization key item constituting the authorization data; and a step of adding the public key and authentication-related metadata to the authorization key item. Claim 2 delete Claim 3 A TLS-based authentication method according to claim 1, wherein the step of generating authorization delegation data based on the public key in the web server comprises: a step of assigning an authorization delegation entity ID to an authorization delegation entity item constituting the authorization delegation data to identify the authorization delegation entity; and a step of adding the public key ID of the authorization delegation entity to the authorization delegation entity item. Claim 4 A TLS-based authentication method according to claim 1, wherein the step of generating authorization delegation data based on the public key in the web server includes the step of increasing the count of the version item of the authorization delegation data when the public key is added while the authorization delegation data is already generated. Claim 5 A TLS-based authentication method according to claim 1, wherein the step of generating authorization delegation data based on the public key in the web server includes the step of assigning an initial value to the version item of the authorization delegation data when the authorization delegation data is initially generated. Claim 6 A TLS-based authentication method according to claim 1, wherein the step of generating authorization delegation data based on the public key in the web server comprises the step of configuring a value signed with the secret key for the authorization delegation data as a signature item for the authorization delegation data. Claim 7 A TLS-based authentication method according to claim 1, further comprising: a step of requesting authorization proof data from a web server in a browser; a step of receiving the requested authorization proof data from an authorization proof data repository of the web server in the browser; a step of sending a client hello message to an authorization entity in the browser; a step of receiving a server hello message from the authorization entity in response to the client hello message in the browser; a step of verifying whether the authorization entity has received authentication authority based on the server hello message in the browser; and a step of exchanging a symmetric key for encryption with the authorization entity in the browser as the verification is completed. Claim 8 In claim 7, the step of sending a client hello message from the browser to the authorization entity is to send a client hello message from the browser to the authorization entity indicating that TLS authentication based on authorization data and authorization proof data is possible, a TLS-based authentication method. Claim 9 A TLS-based authentication method according to claim 7, wherein the step of receiving a server hello message from the authorization delegation entity in response to the client hello message in the browser is to receive a server hello message including a TLS handshake message containing the certificate, an authorization delegation entity ID for identifying the authorization delegation entity, and an authorization delegation key ID pointing to a public key location for verifying the TLS handshake message. Claim 10 A TLS-based authentication method according to claim 9, wherein the authentication verification information included in the above TLS handshake message is signed through a secret key paired with the public key pointed to by the above authorization delegation key ID. Claim 11 A TLS-based authentication method according to claim 9, wherein the step of receiving a server hello message from the authorization delegation entity in response to the client hello message in the browser is to receive the server hello message which further includes location information of the authorization proof data store. Claim 12 In claim 9, the step of verifying whether the authorization delegation entity has received authentication authority based on the server hello message in the browser includes the step of verifying the signatures of the authorization delegation data and the authorization proof data based on the public key of the certificate included in the TLS handshake message, a TLS-based authentication method. Claim 13 In claim 9, the step of verifying whether the authorization delegation entity has received authentication authority based on the server hello message in the browser comprises: a step of comparing the value of a version item of the authorization delegation data and the authorization delegation proof data; and a step of determining that the authorization delegation data is valid if the comparison result is the same. Claim 14 In claim 13, the step of determining that the authorization delegation data is valid when the comparison result is identical is to determine that the authorization delegation data is valid when the value of the version item of the authorization certificate data differs from the value of the version item of the authorization delegation data within a preset range, in a TLS-based authentication method. Claim 15 A TLS-based authentication method according to claim 9, wherein the step of verifying whether the authorization delegation entity has received authentication authority based on the server hello message in the browser includes the step of verifying the signature of the authentication verification information included in the TLS handshake message based on the public key of the authorization delegation entity included in the authorization data. Claim 16 A step of requesting authorization proof data from a web server in a browser; a step of receiving the authorization proof data from the authorization proof data repository of the web server in the browser; a step of sending a client hello message to an authorization delegation entity in the browser; a step of receiving a server hello message from the authorization delegation entity in response to the client hello message in the browser; a step of verifying whether the authorization delegation entity has received authentication authority based on the server hello message in the browser; A TLS-based authentication method comprising the step of exchanging a symmetric key for encryption with the authorization entity as the verification is completed in the browser, wherein the authorization proof data includes a version value synchronized with a version of the authorization data generated by the web server based on the public key of the authorization entity, wherein the authorization data is data received by the authorization entity from the web server, and wherein the authorization key item constituting the authorization data includes an authorization key ID for identifying the public key, the public key, and authentication-related metadata, and wherein the client hello message includes a message indicating that the browser can authenticate the authorization entity through the authorization data and the authorization proof data.

Images