MyData Services and mTLS

1. Mutual Trust: mTLS (Mutual TLS)

"Trust," defined in the dictionary as "believing in and relying on someone firmly," is a critical value for two or more stakeholders engaging in economic activities such as transactions, investments, and business. As we entered an era where transactions occur and important information is exchanged via the web, the value of this trust has been recognized as equally important in the web environment. 

Furthermore, due to the nature of the web environment where various threats such as phishing, malicious attacks, and information leaks are constantly present, the concept of trust has expanded to become more closely related to security than the traditional concept. 

This expansion of the concept provided the justification for many companies and institutions to conduct research and technology development to strengthen web environment security through trust. As a result, we are now using the encrypted communication standard known as SSL/TLS (hereinafter referred to as TLS). 

Let's briefly look at the TLS Handshake process for encrypted communication:

This method has been the standard session connection method for encrypted communication on the web that we generally use. 

However, with the recent emphasis on Zero Trust environments and the increasing use of APIs to handle sensitive information (personal information, financial information, etc.), the concept of mTLS (mutual TLS), where the client must also prove that they are a verified user, is being highlighted. 

mTLS is a concept where the client authentication procedure—which is generally omitted in the standard TLS Handshake process—is performed. In this scenario, not only the server but also the client proves their identity via a certificate, allowing communication within a relationship of mutual trust. 

The text below refers to a diagram comparing the session connection process of standard TLS and mTLS, and a packet capture showing how packets appear when mTLS is actually applied. 

<Figure 1> TLS and mTLS Handshake Process

2. Financial MyData and mTLS

Let's look at where and how mTLS is being used. First, if a company is building a Zero Trust security environment, it is likely configuring its system so that only clients authenticated using mTLS can access it. However, since these cases are configured according to each company's specific environment, it is difficult to secure standardized guides or data, making it limited to apply to other cases. 

So, what is a more general example? A representative example of mTLS usage is the Financial MyData service. The Financial MyData service, which went into effect on January 5, 2022, is a system that uses APIs as a standard for encrypted communication when providing services related to personal information. 

APIs also use TLS for encrypted communication. For safe personal information and data transmission, the Financial Security Institute has outlined considerations for using TLS, as shown in the context of MyData services. These considerations include mTLS. 

As such, the application of mTLS is necessary for Financial MyData services. However, for companies that have only used standard TLS encrypted communication until now, applying mTLS might seem daunting. Let's look at what points need to be considered. 

3. Applying mTLS

There are two main topics to cover in this guideline. First, let's look at the process of establishing a session by applying mTLS.
 

① Before looking at how to establish a session, the first thing to do is to check the equipment and solutions responsible for TLS communication in the current system. In most environments, a Web Application Firewall (WAF) acting as a proxy in front of the server is likely responsible for TLS communication. 

② Once the equipment is identified, you must understand how the session establishment process differs between TLS and mTLS. As mentioned earlier, mTLS adds client authentication to the existing TLS Handshake process. However, the actual addition of the client authentication process is not as simple as one might think. 

②-① First, the biggest difference is that while standard TLS required only one CA certificate (for the server) to establish a session, mTLS requires three certificates. Most people might be puzzled as to why three certificates are needed instead of two. To give the conclusion first: two certificates are needed to establish a session on the Client Side, and two certificates are needed to establish a session on the Server Side. In this scenario, because the Server's CA certificate is used on both sides, a total of three distinct certificates are required. Let's examine how the session is established on each side. 

②-② First, let's look at the session connection on the Client Side. In standard TLS, when the WAF sends the server's CA certificate to the client, the client checks the CA list stored on the device to verify if the certificate is authorized, and then proceeds with the session connection process. However, in mTLS, after the client verifies the server certificate, an additional procedure is required where the WAF verifies the client's certificate. 

What is important here is that the reason the server verifies the client's certificate is different from why the client verifies the server's certificate. Since the server usually uses a certificate issued by a CA, the client uses the CA list stored on the device to verify if the server is trustworthy.  

However, the server verifies the client's certificate using certificate information it already possesses to validate whether the client is an allowed client. In other words, the client verifies the certificate to ensure integrity (that the server is a trustworthy, normal server), while the server verifies the certificate to maintain confidentiality (validating that this client is authorized to access and receive information). 

②-③ Next, let's look at the session connection on the Server Side. Unlike the Client Side, for Server Side TLS session connection, the WAF (acting as the server's proxy) already trusts the server.  

Therefore, it does not perform a separate verification of the CA certificate received from the server (though if a company is building a Zero Trust environment, the WAF should also verify the server's CA certificate). It establishes a session by performing symmetric key generation and encryption. 

How does this change if mTLS is applied here? If mTLS is applied to the Server Side, just like on the Client Side, the server requests a certificate from the WAF trying to establish a session with it. The WAF then delivers the private certificate prepared for the session to the server.  

At this time, the server must also have a certificate list and certificate information to verify whether the certificate is allowed. Thus, to establish a session using mTLS, a process for verifying the client must be added on each side. 

Because of this connection process, a consideration arises, which is the second topic we will cover. Some of you may have asked, "Looking at the connection process above, how can the server identify the client?" Correct. When a session is connected through the above method, the server cannot distinguish the client because it does not receive client information directly (since the connection is terminated at the WAF).  

Particularly in the case of MyData services, both the institution and the company using the service must register TLS certificate information containing a SERIALNUMBER (Business Registration Number) with the MyData Comprehensive Portal for mutual authentication. Based on this information, the information provider confirms whether the client requesting information is a business operator registered with the MyData Comprehensive Portal. 

Ultimately, for MyData services, it is necessary to pass the client certificate information obtained on the Client Side to the server. In other words, as shown in the figure below, when proxying a client request from the WAF to the server, the client certificate information obtained from the Client Side must be included in the request header and delivered to the server so that the server can distinguish the client. 

If the client's certificate information is included in the header in this way, the server can identify the client, verify if they are a registered business operator in the MyData Comprehensive Portal, and extract or index client information if necessary. 

So far, we have looked at the considerations for applying mTLS. Of course, there may be more considerations, but the two points above are considered the representative issues that many managers worry about and find difficult when actually applying mTLS. 

In addition to this, PIOLINK has various references gained by solving problems with many customers who were considering mTLS application for MyData services. If you have any concerns related to mTLS, please feel free to consult with PIOLINK's experts to solve your problems at any time.