KR20220071859A - Method for offloading secure connection setup into network interface card, and a network interface card, and a computer-readable recording medium - Google Patents

Abstract

The present invention relates to a network interface card (NIC), which comprises: a port unit for transceiving data with a client; a host interface unit for transceiving the data with a host; and an encryption accelerator for setting a secure connection between a host device and the client. The NIC of the present invention can be applied to the overall web servers that support or intend to support a secure connection in order to reduce the burden of setting the secure connection. In particular, when the NIC of the present invention is applied to a large network system such as a data center or cloud computing in which a CPU resource should be concentrated on more complex tasks, the performance improvement can be expected. Furthermore, the performance deterioration due to a secure connection can be prevented even in a case of a small server having relatively low operation capability.

Description

ＮＩＣ로의 보안연결 설정기능 이양방법 및 이를 이용한 ＮＩＣ, 그리고 컴퓨터 판독 가능 기록매체{METHOD FOR OFFLOADING SECURE CONNECTION SETUP INTO NETWORK INTERFACE CARD, AND A NETWORK INTERFACE CARD, AND A COMPUTER-READABLE RECORDING MEDIUM}A method for transferring a secure connection setting function to an NIC, a NIC using the same, and a computer-readable recording medium

본 발명은 웹 서버가 클라이언트와 보안 연결을 설정할 때 핸드셰이크 과정을 호스트에서 네트워크 인터페이스 카드로 동적 이양하는 방법 및 이를 이용한 NIC, 그리고 컴퓨터 판독 가능 기록매체에 관한 것이다.The present invention relates to a method for dynamically transferring a handshake process from a host to a network interface card when a web server establishes a secure connection with a client, a NIC using the same, and a computer-readable recording medium.

TLS(Transport Layer Security)는 현대 인터넷에서 사설 네트워크 통신을 위한 핵심 구성 요소가 되었다. 최근 CPU의 발전으로 데이터 암호화 성능이 크게 향상되었지만 TLS 키 교환은 여전히 단기 트랜잭션의 병목 현상을 유지하고 있다. 전용 하드웨어 암호화 가속기(crypto accelerators)는 우수한 성능을 약속하지만, 비동기 처리의 고유한 아키텍처로 인해 애플리케이션의 침습적인 수정이 필요한 경우가 많다.Transport Layer Security (TLS) has become a key component for private network communication in the modern Internet. Although the recent CPU advances have significantly improved data encryption performance, TLS key exchange still remains a bottleneck for short-term transactions. Dedicated hardware crypto accelerators promise great performance, but the unique architecture of asynchronous processing often requires invasive modification of applications.

인터넷에서는 인터넷 트래픽의 70% 이상이 TLS로 암호화되는 반면 상위 100개 웹사이트 중 96개가 HTTPS를 기본 프로토콜로 제시하는 등 TLS가 점점 인기를 끌고 있다. TLS는 HTTP/2에서 기본적으로 사용될 뿐만 아니라 QUIC, CoAP, Skype, 온라인 회의 서비스 등과 같은 다양한 전송 또는 애플리케이션 계층 프로토콜에서도 사용된다.On the Internet, TLS is becoming increasingly popular, with more than 70% of Internet traffic being encrypted with TLS, while 96 of the top 100 websites offer HTTPS as their default protocol. TLS is not only used natively in HTTP/2, but also in various transport or application layer protocols such as QUIC, CoAP, Skype, and online conferencing services.

TLS 운영은 크게 키 교환(key exchange)과 암호화된 데이터 전송으로 나뉘며, 상대적인 성능 오버헤드는 전달된 데이터의 크기에 따라 달라진다. 웹 브라우징과 같은 짧은 메시지의 경우, 일반적으로 키 교환을 위한 공개키 암호화에 병목 현상이 존재한다. 반대로 대칭키 암호화 및 무결성을 위한 콘텐츠 해싱(content hashing)은 온라인 비디오 전송과 같은 대용량 메시지의 주요 병목 현상이다. TLS operation is largely divided into key exchange and encrypted data transmission, and the relative performance overhead varies depending on the size of the transmitted data. For short messages such as web browsing, there is usually a bottleneck in public key encryption for key exchange. Conversely, symmetric key encryption and content hashing for integrity are major bottlenecks for large messages such as online video transmission.

다행히 최근 AES-NI가 도입되면서 후자의 성능이 크게 향상된 바 있다. 단일 CPU 코어도 현재 Galois/Counter Mode(AES-GCM)에서 AES에 대해 20Gbps 이상의 성능을 달성한다. 그러나 동일한 CPU 코어가 2048비트 RSA로 초당 1500개 이상의 작업을 처리하는 것만큼 공개키 암호화의 성능은 향상되지 않았으며, 이는 짧은 연결의 HTTPS 성능을 일반 텍스트 전송의 HTTPS 성능보다 최대 33배까지 저하시킨다.Fortunately, with the recent introduction of AES-NI, the performance of the latter has been greatly improved. Even a single CPU core now achieves over 20Gbps of performance for AES in Galois/Counter Mode (AES-GCM). However, the performance of public key cryptography does not improve as much as the same CPU core can process more than 1500 operations per second with 2048-bit RSA, which degrades HTTPS performance for short connections by up to 33 times that of HTTPS performance for plaintext transfers. .

본 발명의 목적은 보안 연결이 인터넷의 표준으로 부상한 상황에서 웹서버를 호스팅하는 모든 산업분야에 적용될 수 있는 신규한 보안연결 설정방법 및 NIC를 제공함에 있다. 특히, 본 발명의 목적은 보안 연결 설정에 의한 성능 감소를 막을 수 있고, 보안 연결 과정에서 발생할 수 있는 치명적인 오류나 취약점 공격이 호스트에 미치는 영향을 최소화하며, 시스템 아키텍처를 크게 바꾸지 않으면서도 안정성과 경제성을 도모할 수 있는 보안연결 설정기능 이양방법 및 이를 이용한 네트워크 어댑터를 제공함에 있다.It is an object of the present invention to provide a novel secure connection setting method and NIC that can be applied to all industrial fields hosting web servers in a situation where secure connection has emerged as the standard of the Internet. In particular, an object of the present invention is to prevent performance reduction due to secure connection establishment, minimize the impact of fatal errors or vulnerability attacks that may occur in the secure connection process on the host, and improve stability and economy without significantly changing the system architecture. It is to provide a method for transferring a secure connection setting function that can be achieved and a network adapter using the same.

본 발명에 따른 NIC(Network Interface Card))는 클라이언트와의 데이터 송수신을 위한 포트부; 호스트와의 데이터 송수신을 위한 호스트 인터페이스부; 및 상기 호스트 장치와 클라이언트 간의 보안 연결 설정을 수행하기 위한 암호화 가속기;를 포함한다.A NIC (Network Interface Card) according to the present invention includes a port unit for transmitting and receiving data with a client; a host interface unit for data transmission/reception with a host; and a cryptographic accelerator for establishing a secure connection between the host device and the client.

그리고, 상기 보안 연결 설정은 TCP 연결 설정 및 TLS 핸드셰이크를 포함할 수 있다.In addition, the secure connection establishment may include a TCP connection establishment and a TLS handshake.

또한, 상기 TLS 핸드셰이크는 서버 인증 및 키 교환을 포함하고, 상기 암호화 가속기는 비대칭 암호화 알고리즘을 수행하여 상기 키 교환을 수행할 수 있다.In addition, the TLS handshake may include server authentication and key exchange, and the cryptographic accelerator may perform an asymmetric cryptographic algorithm to perform the key exchange.

그리고, 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함할 수 있다.In addition, when the cryptographic accelerator performs an asymmetric encryption algorithm, the base protocol function is not performed, and the base protocol function may include any one of packet loss detection, retransmission, and congestion control.

또한, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않을 수 있다.Also, the host may not participate in the secure connection establishment process until the secure connection is completed.

한편, 본 발명에 따른 보안연결 설정기능 이양방법은, 호스트가 사전 보안연결을 위해 NIC에 전자증명서를 전달하고, 서버 인증 과정을 수행하는 단계; NIC(Network Interface Card)가 웹 서버로 보내진 데이터를 지속적으로 모니터링하여 보안 연결이 필요하다고 판단되는 연결을 탐색하는 단계; 및 상기 NIC에 내장된 암호화 가속기(crypto accelerator)가 비대칭 암호화 알고리즘을 수행하여 클라이언트와 키 교환을 수행하는 단계;를 포함한다.On the other hand, the secure connection setting function transfer method according to the present invention, the host transmits the electronic certificate to the NIC for a pre-secure connection, and performing a server authentication process; continuously monitoring data sent to a web server by a network interface card (NIC) to discover a connection that is determined to require a secure connection; and performing, by a crypto accelerator built into the NIC, an asymmetric encryption algorithm to exchange a key with a client.

그리고, 상기 NIC가, 보안 연결 설정 완료 후 상기 클라이언트와 교환한 공유 키와 보안 연결 정보를 상기 호스트에 전달하는 단계; 및 상기 호스트가, 연결 초기화 절차를 생략하고, 보안 연결을 이어가며 웹 서버 기능을 수행하는 단계;를 더 포함할 수 있다.and transmitting, by the NIC, the shared key exchanged with the client and secure connection information to the host after completing the secure connection establishment; and performing, by the host, a web server function while omitting a connection initialization procedure and continuing a secure connection.

또한, 상기 호스트가, 보안 연결 종료 후 상기 NIC에게 종료 상태 정보를 전달하는 단계; 및 상기 NIC가, 동일한 클라이언트 IP 주소와 포트 번호에 대해 핸드셰이크 과정을 재개하는 단계;를 더 포함할 수 있다.In addition, the step of transmitting, by the host, termination status information to the NIC after the secure connection is terminated; and resuming, by the NIC, the handshake process for the same client IP address and port number.

그리고, 상기 NIC는 상기 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함할 수 있다.In addition, the NIC does not perform a base protocol function when the encryption accelerator performs an asymmetric encryption algorithm, and the base protocol function may include any one of packet loss detection, retransmission, and congestion control.

또한, 상기 서버 인증 이후, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않을 수 있다.Also, after the server authentication, the host may not participate in the secure connection establishment process until the secure connection is completed.

한편, 상기 목적을 달성하기 위한 본 발명에 따른 컴퓨터 판독 가능 기록매체는 상술한 방법 중 어느 하나의 보안연결 설정기능 이양방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한다.On the other hand, the computer-readable recording medium according to the present invention for achieving the above object records a program for executing the method for transferring a secure connection setting function of any one of the above-described methods in a computer.

본 발명은 보안 연결 설정으로 인한 부담을 덜기 위하여 보안 연결을 지원하는, 혹은 지원하고자 하는 웹서버 전반에 적용이 가능하다. 특히, CPU 자원을 보다 복잡한 작업에 집중시켜야 하는 데이터센터나 클라우드 컴퓨팅과 같은 규모가 큰 네트워크 시스템에 적용하면 성능 향상을 기대할 수 있다. 나아가 본 발명은 연산 능력이 상대적으로 부족한 소규모 서버에도 보안 연결로 인한 성능 저하를 막을 수 있다. 특히, 본 발명을 통해 기대할 수 있는 효과는 다음과 같다.The present invention can be applied to all web servers that support or want to support a secure connection in order to reduce the burden of establishing a secure connection. In particular, performance improvement can be expected when applied to large-scale network systems such as data centers or cloud computing where CPU resources need to be concentrated on more complex tasks. Furthermore, the present invention can prevent performance degradation due to secure connection even in a small server with relatively insufficient computing power. In particular, the effects that can be expected through the present invention are as follows.

(1) 보안 연결 설정에 의한 성능 감소를 막아 웹 서버 능력을 향상시킨다.(1) Improves web server capability by preventing performance decrease due to secure connection setup.

(2) 보안 연결 설정을 네트워크 어댑터가 독립적으로 담당하면서 호스트가 완전히 설정 완료된 연결만을 다룬다. 보안 연결 과정에서 발생할 수 있는 치명적인 오류나 취약점 공격이 호스트에 미치는 영향을 막을 수 있다.(2) The network adapter is independently responsible for establishing a secure connection and only handles connections that have been fully established by the host. It can prevent fatal errors or vulnerability attacks that may occur during the secure connection process from affecting the host.

(3) 보안 연결 프록시나 전용 하드웨어 가속기와 달리 시스템 아키텍처를 크게 바꾸지 않는다. 이는 안정성과 경제성의 측면에서 이점을 가진다.(3) It does not significantly change the system architecture, unlike secure connection proxies or dedicated hardware accelerators. This has advantages in terms of stability and economy.

보안 연결이 인터넷의 표준으로 부상한 상황에서, 본 발명은 웹서버를 호스팅하는 모든 산업분야에 적용될 수 있다.In a situation where a secure connection has emerged as a standard of the Internet, the present invention can be applied to any industrial field hosting a web server.

도 1은 SmartTLS에서 호스트 CPU와 SmartNIC로 나누어진 워크로드를 요약한 것이다.
도 2는 2048 비트 RSA와의 키 교환을 위한 SmartTLS에서의 TLS(v1.2) 연결의 데이터 흐름을 나타낸다.
도 3은 SmartTLS NIC 스택의 전체 아키텍처를 보여준다.
도 4는 다양한 CPU 코어 수에 대한 TLS 연결 설정의 처리량을 비교하는 실험 결과를 나타내는 그래프이다.
도 5는 단일 CPU 코어를 사용하여 HTTPS에서 1바이트 파일을 다운로드하는 99%의 꼬리 응답 시간(tail latency)을 비교하는 그래프이다.
도 6은 단기 흐름의 수가 증가함에 따라 대용량 파일 트래픽의 처리량이 감소함을 보여주는 그래프이다.
도 7은 본 발명에 따른 보안연결 설정기능 이양방법을 수행하기 위한 네트워크 어댑터(200)의 호스트(300) 및 클라이언트(100) 사이에서의 통신 방법을 설명하기 위한 구성도이다.Figure 1 summarizes the workload divided into host CPU and SmartNIC in SmartTLS.
Figure 2 shows the data flow of a TLS (v1.2) connection in SmartTLS for key exchange with 2048-bit RSA.
3 shows the overall architecture of the SmartTLS NIC stack.
4 is a graph showing experimental results comparing the throughput of TLS connection establishment for various CPU core numbers.
5 is a graph comparing the tail latency of 99% for downloading a 1-byte file from HTTPS using a single CPU core.
6 is a graph showing that the throughput of large file traffic decreases as the number of short-term flows increases.
7 is a configuration diagram for explaining a communication method between the host 300 and the client 100 of the network adapter 200 for performing the secure connection establishment function transfer method according to the present invention.

이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.Hereinafter, the embodiments disclosed in the present specification will be described in detail with reference to the accompanying drawings, but the same or similar components are assigned the same reference numbers regardless of reference numerals, and redundant description thereof will be omitted. The suffix "part" for the components used in the following description is given or mixed in consideration of only the ease of writing the specification, and does not have a meaning or role distinct from each other by itself. In addition, in describing the embodiments disclosed in the present specification, if it is determined that detailed descriptions of related known technologies may obscure the gist of the embodiments disclosed in the present specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in the present specification, and the technical idea disclosed herein is not limited by the accompanying drawings, and all changes included in the spirit and scope of the present invention , should be understood to include equivalents or substitutes.

본 발명은 하드웨어 암호화 가속기를 사용하여 TLS 핸드셰이크(handshake)를 네트워크 인터페이스 카드(Network Interface Card; NIC)로 오프로드할 수 있는 가능성을 제시한다. CPU 기반 호스트 스택에서 나머지 작업을 수행하면서 NIC에서 TCP 연결 설정 및 TLS 핸드셰이크를 처리하는 TCP용 분할 TLS 처리 아키텍처(split TLS processing architecture)를 구현한다. 기존 SmartNIC에 대한 개념 증명 구현은 단일 CPU 코어보다 5배 향상된 처리량을 제공하므로 유망한 결과를 보여준다.The present invention proposes the possibility of offloading the TLS handshake to a Network Interface Card (NIC) using a hardware cryptographic accelerator. Implements a split TLS processing architecture for TCP where the NIC handles TCP connection establishment and TLS handshake while the CPU-based host stack does the rest. A proof-of-concept implementation for an existing SmartNIC shows promising results as it provides a throughput of 5x better than a single CPU core.

본 발명은 웹 서버가 클라이언트와 보안 연결을 맺을 시에 서버 인증 및 키 교환 과정을 포함한 연결 설정, 즉 핸드셰이크 과정을 호스트에서 네트워크 어댑터로 동적 이양하는 방법에 관한 것이다. 구체적인 방법은 다음과 같다.The present invention relates to a method for dynamically transferring a connection establishment, ie, a handshake process, including a process of server authentication and key exchange, from a host to a network adapter when a web server establishes a secure connection with a client. The specific method is as follows.

첫번째로 프로그래머블 네트워크 어댑터(SmartNIC)에서는 웹 서버로 보내진 데이터를 지속적으로 모니터링하며, 보안 연결이 필요하다고 판단되는 연결을 찾아 보안 연결 설정을 진행한다. 보안연결을 위해 사전에 호스트는 네트워크 어댑터에게 전자증명서를 전달한 상태이며, 이 정보를 이용해 서버 인증 과정을 거친다. 이후 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘을 수행하기 위해 네트워크 어댑터는 내장된 암호화 가속기(crypto accelerator)를 사용한다. 이 과정에서 어댑터는 능동적으로 패킷을 읽고 클라이언트에게 응답하지만, 패킷 손실 탐지, 재전송, 혼잡 제어 등 복잡한 기저 프로토콜 기능은 수행하지 않는다.First, the programmable network adapter (SmartNIC) continuously monitors the data sent to the web server, finds a connection that requires a secure connection, and establishes a secure connection. For secure connection, the host has delivered the electronic certificate to the network adapter in advance, and uses this information to go through the server authentication process. In order to perform the asymmetric encryption algorithm used in the subsequent key exchange process, the network adapter uses a built-in crypto accelerator. In this process, the adapter actively reads packets and responds to the client, but does not perform complex underlying protocol functions such as packet loss detection, retransmission, and congestion control.

다음 단계로, 연결 설정이 완료되었을 때 네트워크 어댑터는 클라이언트와 교환한 공유 키와 보안 연결 정보를 호스트에 전달한다. 해당 연결에 대해, 네트워크 어댑터는 모든 이후의 데이터를 처리하지 않고 호스트에게 그대로 전달한다. 주어진 정보를 받은 호스트는 연결 초기화 절차를 생략하고 곧바로 보안 연결을 이어가며 일반적인 웹 서버 기능을 수행한다. 이때 호스트 네트워크 스택은 기존과 유사한 API를 어플리케이션에 제공하기 때문에 현존하는 웹 서버 어플리케이션을 큰 수정 없이 곧바로 사용할 수 있다.In the next step, when the connection establishment is completed, the network adapter sends the shared key exchanged with the client and the secure connection information to the host. For that connection, the network adapter passes all subsequent data as-is to the host without processing. The host that has received the given information skips the connection initialization procedure and immediately continues the secure connection and performs general web server functions. In this case, since the host network stack provides an API similar to the existing one to the application, the existing web server application can be used immediately without major modifications.

마지막으로, 보안 연결이 종료되면, 호스트는 네트워크 어댑터에게 이를 알려 같은 클라이언트 IP 주소와 포트 번호에 대해 다시 처음부터 핸드셰이크 과정을 진행할 수 있도록 한다. 즉, 호스트는 보안 연결 종료 상태 정보를 NIC에게 전송하고, NIC는, 동일한 클라이언트 IP 주소와 포트 번호에 대해서 핸드셰이크 과정을 재개할 수 있다.Finally, when the secure connection is terminated, the host notifies the network adapter so that the handshake process can begin again for the same client IP address and port number. That is, the host transmits the secure connection termination status information to the NIC, and the NIC may resume the handshake process for the same client IP address and port number.

위의 설명에 있어서, 비대칭 암호화 알고리즘에 대해서 간략히 설명하기로 한다. 아래의 설명은 비대칭 암호화 알고리즘의 실시예일뿐이고, 다양한 종류의 알고리즘을 이용할 수 있음은 당업자에 자명하다. 아울러, 본 발명의 권리범위는 비대칭 암호화와 관련한 특정 알고리즘에 한정되지 않는다.In the above description, an asymmetric encryption algorithm will be briefly described. The following description is only an example of an asymmetric encryption algorithm, and it is apparent to those skilled in the art that various types of algorithms may be used. In addition, the scope of the present invention is not limited to a specific algorithm related to asymmetric encryption.

공개키 암호 알고리즘으로도 불리는 비대칭 암호화는 암호화에 쓰이는 키값과 복호화에 쓰이는 키값을 서로 상이하게 하여 보안을 수행하는 것으로 대표적으로 아래와 같은 알고리즘이 존재한다.Asymmetric encryption, also called public key encryption algorithm, performs security by differentiating the key value used for encryption and the key value used for decryption.

(1) RSA(Rivest, Shamir and Adleman): 현재 사용되는 공개키 암호 알고리즘 중 가장 대표적인 것으로 암호화와 인증에 사용된다.(1) RSA (Rivest, Shamir and Adleman): It is the most representative of the currently used public key encryption algorithms and is used for encryption and authentication.

(2) ElGamal: 이산 대수 문제의 어려움에 기반을 둔 최초의 공개키 암호 알고리즘이다.(2) ElGamal: The first public key cryptographic algorithm based on the difficulty of the discrete algebra problem.

(3) ECC(Elliptic Curve Cryptosystem): 타원곡선(Elliptic Curve)의 수학적 원리를 이용한 차세대 공개키 암호 알고리즘이다.(3) ECC (Elliptic Curve Cryptosystem): A next-generation public key cryptographic algorithm using the mathematical principle of the elliptic curve.

(4) DSA(SEED): 전자상거래, 금융, 무선통신 등에서 전송되는 개인정보와 같은 중요한 정보의 보안을 이루기 위한 128-비트 블록암호 알고리즘이다.(4) DSA (SEED): A 128-bit block encryption algorithm for securing important information such as personal information transmitted in e-commerce, finance, and wireless communication.

비대칭키 암호화는 양방향 암호화로써 복호화가 가능한 암호 알고리즘으로 한 쌍의 키가 존재하며, 하나는 특정 사람만이 가지는 개인키(또는 비밀키)이고 다른 하나는 누구나 가질 수 있는 공개키에 해당한다. 공개키 암호화 방식은 암호학적으로 연관된 두 개의 키(개인키/공개키)를 이용하며, 개인키로 암호화 한 정보는 그 쌍이 되는 공개키로만 복호화가 가능하고, 공개키로 암호화한 정보는 그 쌍이 되는 개인키로만 복호화가 가능한 구조를 갖는다. 개인간 비밀통신은 대칭키 암호화로 가능하지만, 다수의 통신이 이루어지는 네트워크에서는 키의 개수가 급증하기 때문에 비대칭키 암호화 알고리즘이 필요하며, 이를 통해 보안성이 향상된 안전한 통신을 이룰 수 있게 된다.Asymmetric key encryption is a two-way encryption encryption algorithm that can be decrypted. A pair of keys exist. One is a private key (or private key) that only a specific person has, and the other corresponds to a public key that anyone can have. The public key encryption method uses two cryptographically related keys (private key/public key). Information encrypted with the private key can be decrypted only with the paired public key, and information encrypted with the public key is encrypted with the pair. It has a structure that can only be decrypted with a key. Although private communication between individuals is possible with symmetric key encryption, an asymmetric key encryption algorithm is required because the number of keys increases rapidly in a network in which multiple communication is performed, and through this, secure communication with improved security can be achieved.

본 발명의 가장 큰 특징은 호스트는 보안 연결이 완전히 설정되기 전까지 그 과정에 전혀 관여하지 않는다는 것이다. 이는 호스트 CPU의 부담을 줄일 뿐만 아니라 네트워크 어댑터에 내장된 암호화 가속기(crypto accelerator)를 사용하여 기존 시스템에 비해 성능을 향상시킨다.The greatest feature of the present invention is that the host does not participate in the process at all until the secure connection is fully established. This not only reduces the load on the host CPU, but also uses a crypto accelerator built into the network adapter to improve performance compared to conventional systems.

호스트 CPU에서 나머지 작업을 수행하는 동안 TCP의 TLS 핸드셰이크를 SmartNIC로 오프로드하는 설계 영역을 탐색했다. 높은 처리량의 데이터 암호화 및 복호화를 위해 CPU에서 AES-NI를 활용하면서 확장 가능한 TLS 키 교환을 위해 NIC에 하드웨어 공개키 가속기를 배치하는 것이 이로운지를 살펴보았고, SmartTLS라고하는 분할 아키텍처는 아래와 같은 많은 이점을 제공한다. We explored a design area that offloads TCP's TLS handshake to the SmartNIC while the host CPU does the rest. We looked at the benefits of deploying a hardware public key accelerator on the NIC for scalable TLS key exchange while leveraging AES-NI on the CPU for high-throughput data encryption and decryption. to provide.

첫째, TCP 연결 설정 및 CPU에서 TLS 키 교환의 부담을 크게 완화한다. 절약된 오버헤드에는 NIC와 호스트 메모리 사이의 작은 패킷에 대한 흐름별 상태 추적 및 DMA 작업이 포함되며, 이는 동시 연결이 많은 경우 큰 의미를 갖는다. First, it greatly relieves the burden of establishing a TCP connection and exchanging TLS keys on the CPU. The overhead saved includes per-flow state tracking and DMA operations for small packets between the NIC and host memory, which is significant when there are many simultaneous connections.

둘째, NIC에서 TLS 키 교환을 수행하려면 GPU 또는 ASIC 기반 암호화 가속기와 같은 전용 하드웨어를 사용하는 대체 설계와 달리 애플리케이션의 수정이 거의 또는 전혀 필요하지 않다. 전용 가속기는 일반적으로 높은 처리량을 위해 여러 암호화 작업의 비동기 또는 일괄 처리가 필요하므로 애플리케이션 아키텍처 업데이트가 불가피하다. 반대로 SmartTLS는 애플리케이션에 투명하므로 동기식 암호화 라이브러리 API를 계속 사용할 수 있다. 도 1은 SmartTLS에서 호스트 CPU와 SmartNIC로 나누어진 워크로드를 요약한 도면이다.Second, performing TLS key exchange on the NIC requires little or no application modification, unlike alternative designs that use dedicated hardware such as GPUs or ASIC-based cryptographic accelerators. Dedicated accelerators typically require asynchronous or batch processing of multiple cryptographic operations for high throughput, necessitating application architecture updates. Conversely, SmartTLS is transparent to the application, so you can still use the synchronous encryption library API. 1 is a diagram summarizing the workload divided into a host CPU and SmartNIC in SmartTLS.

위에서 언급한 장점에도 불구하고, SmartTLS는 일련의 새로운 과제를 제시한다. Despite the advantages mentioned above, SmartTLS presents a set of new challenges.

첫째, NIC는 TCP 연결 설정 및 TLS 키 교환 중에 교환된 패킷의 안정적인 전송을 보장해야 한다. 안정적인 데이터 전달을 구현하려면 패킷 손실 유추, 타이머 구현 및 패킷 재전송이 필요하기 때문에 복잡하고 오류가 발생하기 쉽다. 이는 일반적인 SmartNIC가 CPU만큼 많은 컴퓨팅 용량을 가지고 있지 않기 때문에 과도한 오버헤드를 야기한다. 이 문제를 해결하기 위한 본 발명은 NIC의 기능을 가능한 상태 비저장으로 구현한다. AccelTCP에서와 같이 SYN 쿠키를 사용하여 상태 비저장 TCP 연결 설정을 구현하고 클라이언트 측을 이용하여 패킷 재전송을 시작한다. 이는 NIC에서의 구현을 크게 단순화하고 평균적인 사례에서 우수한 성능을 보장한다. First, the NIC must ensure reliable transmission of packets exchanged during TCP connection establishment and TLS key exchange. Implementing reliable data delivery is complex and error-prone because packet loss inference, timer implementation, and packet retransmission are required. This causes excessive overhead because typical SmartNICs do not have as much computing capacity as CPUs. The present invention to solve this problem implements the function of the NIC as stateless as possible. As in AccelTCP, it uses SYN cookies to implement stateless TCP connection establishment and uses the client side to initiate packet retransmission. This greatly simplifies the implementation on the NIC and ensures good performance in the average case.

둘째, TLS 핸드셰이크 후 NIC는 수신 패킷을 호스트 CPU 측으로 효율적으로 전달해야 한다. 그러나 TLS 핸드셰이크가 수행되었는지 확인하기 위해 NIC에서 패킷의 4개의 튜플을 확인하는 것조차도 비용이 많이 들고 성능이 저하될 수 있다. 오버헤드를 방지하기 위해 회선 속도 패킷 전달 성능을 보장하는 NIC의 하드웨어 패킷 분류를 활용한다. NIC의 하드웨어 스위치에서 개별 규칙을 설정하기 위한 지연 시간이 현재로서는 다소 높아 보이지만 향후에는 해결될 것으로 보인다.Second, after the TLS handshake, the NIC must efficiently forward the incoming packet to the host CPU side. However, even checking the 4-tuple of a packet on the NIC to verify that the TLS handshake has been performed is expensive and can degrade performance. To avoid overhead, it utilizes the NIC's hardware packet classification to ensure wire-rate packet forwarding performance. The latency for setting individual rules on the NIC's hardware switch seems a bit high at the moment, but it should be addressed in the future.

셋째, NIC 자체가 너무 많은 TLS 핸드셰이크로 인해 오버로드되어 전체 시스템의 성능이 저하될 수 있다. 이 문제를 해결하기 위해 우리는 NIC가 오버로드된 경우 새 연결에 대해 TLS 오프 로딩을 비활성화하는 기회적 오프 로딩을 시행한다. Mellanox Bluefield SmartNIC로 SmartTLS 프로토 타입을 구현한다. 예비 평가 결과 TLS 핸드셰이크 오프로딩의 분명한 이점을 보여주었다. SmartTLS는 8코어 CPU 서버에서 2048비트-RSA로 초당 13K TLS 연결을 달성한다. 이는 CPU 전용 접근 방식에 비해 1.7배 향상되었다. NIC가 최첨단 암호화 가속기를 사용하면 훨씬 더 높은 성능을 기대할 수 있다. SmartTLS는 비용 효율적인 방식으로 최신 TLS 트래픽을 처리하는 실용적인 설계 방식을 제공한다.Third, the NIC itself can be overloaded with too many TLS handshakes, which can degrade the overall system's performance. To solve this problem, we enforce opportunistic offloading which disables TLS offloading for new connections if the NIC is overloaded. Implementation of SmartTLS prototype with Mellanox Bluefield SmartNIC. Preliminary evaluations showed clear benefits of TLS handshake offloading. SmartTLS achieves 13K TLS connections per second with 2048-bit-RSA on an 8-core CPU server. This is a 1.7x improvement over the CPU-only approach. If the NIC uses a state-of-the-art cryptographic accelerator, much higher performance can be expected. SmartTLS provides a practical design approach to handling modern TLS traffic in a cost-effective manner.

TLS 핸드셰이크의 오프로딩(Offloading TLS Handshake)Offloading TLS Handshake

ECDHE-RSA-AES-GCM-SHA는 현재 Alexa Top 100만 사이트에서 사용하는 가장 지배적인 TLS 암호 모음이다. ECDHE-RSA는 RSA 개인키로 서명된 Elliptic-curve Diffie-Hellman 알고리즘을 기반으로 하는 임시 키 교환을 나타낸다. 각 TLS 트랜잭션 후 폐기되는 일회성 키를 사용하므로 TLS 트래픽이 향후에도 해독될 수 없도록 완벽한 순방향 비밀성을 보장한다. Elliptic-curve 알고리즘은 동일한 보안 수준에 대해 RSA보다 훨씬 작은 키를 사용하므로 RSA 서명은 이 키교환 알고리즘에서 가장 무거운 작업으로 남아 있다. AESGCM-SHA는 인증된 데이터 암호화/복호화에 AES-GCM을 사용하고 키 교환 프로세스의 무결성을 확인하기 위해 SHA를 각각 사용하는 것을 의미한다. CBC (Cipher Blocking Chaining) 모드의 AES와 달리 AES-GCM은 패킷 데이터 무결성을 위해 SHA 기반 HMAC를 필요로하지 않으므로 애플리케이션 데이터의 TLS 레코드 생성시 오버헤드가 크게 줄어든다.ECDHE-RSA-AES-GCM-SHA is currently the most dominant TLS cipher suite used by Alexa Top 1 million sites. ECDHE-RSA stands for ephemeral key exchange based on the Elliptic-curve Diffie-Hellman algorithm signed with the RSA private key. It uses a one-time key that is discarded after each TLS transaction, ensuring perfect forward secrecy so that TLS traffic cannot be decrypted in the future. Since the elliptic-curve algorithm uses much smaller keys than RSA for the same level of security, RSA signing remains the heaviest task in this key exchange algorithm. AESGCM-SHA means using AES-GCM for authenticated data encryption/decryption and using SHA to verify the integrity of the key exchange process, respectively. Unlike AES in Cipher Blocking Chaining (CBC) mode, AES-GCM does not require SHA-based HMAC for packet data integrity, which greatly reduces the overhead in creating TLS records of application data.

[표 1]은 OpenSSL 1.1.1f 1로 측정한 최근 CPU(2.6GHz에서 Intel Xeon E5-2640 v3)에서 AES의 성능을 보여준다.[Table 1] shows the performance of AES on a recent CPU (Intel Xeon E5-2640 v3 at 2.6GHz) measured with OpenSSL 1.1.1f 1.

AES modeAES mode 1 core1 core 2 cores2 cores 4 cores4 cores 8 cores8 cores CBC (w/o NI)CBC (w/o NI) 2.022.02 4.054.05 7.377.37 13.6213.62 CBC (w/NI)CBC (w/NI) 4.364.36 8.508.50 15.5515.55 28.9028.90 GCM (w/o NI)GCM (w/o NI) 1.281.28 2.522.52 4.614.61 8.508.50 GCM (w/ NI)GCM (w/NI) 20.7420.74 40.9040.90 75.1075.10 138.98138.98

256비트 키를 사용하고, AES-NI를 사용하거나 사용하지 않은 CBC 및 GCM 모드의 성능을 비교한다. [표 1]을 참조하면, (1) AES-NI가 두 모드의 성능을 크게 향상(CBC 및 GCM의 경우 각각 최대 2.2배 및 16.2배까지)시켰고 (2) AES-NI가 활성화 된 경우 GCM 모드가 CBC 모드보다 10.2배 성능이 뛰어나다는 사실을 알 수 있다.Compare the performance of CBC and GCM modes with and without AES-NI using a 256-bit key. Referring to [Table 1], (1) AES-NI significantly improved the performance of both modes (up to 2.2 times and 16.2 times for CBC and GCM, respectively) and (2) GCM mode when AES-NI was activated It can be seen that is 10.2 times better performance than CBC mode.

일반적으로 GCM은 명령 파이프 라인을 효과적으로 활용하면서 병렬로 작동할 수 있으므로 더욱 효율적으로 구현할 수 있다. 반대로 CBC 모드의 암호화는 각 블록 암호화가 완전히 직렬화되므로 파이프 라인 중단이 발생한다. 단일 CPU 코어조차도 AES-GCM으로 20Gbps 이상을 달성하고 옥타 코어 CPU는 데이터 암호화를 위해 100Gbps에 도달하기에 충분하다.In general, GCM can be implemented more efficiently because it can operate in parallel while effectively utilizing the instruction pipeline. Conversely, encryption in CBC mode causes pipeline disruption as each block encryption is fully serialized. Even a single CPU core achieves over 20Gbps with AES-GCM, and an octa-core CPU is enough to reach 100Gbps for data encryption.

[표 2]는 하드웨어 공개키 가속기(Public Key Accelerator; PKA)가 장착된 Mellanox Bluefield SmartNIC 뿐 아니라 동일한 CPU에서 RSA 개인 키 작업의 성능을 보여준다. Table 2 shows the performance of RSA private key operation on the same CPU as well as a Mellanox Bluefield SmartNIC equipped with a hardware Public Key Accelerator (PKA).

Key sizekey size 1 core1 core 2 cores2 cores 4 cores4 cores 8 cores8 cores PKAPKA 1024-bit1024-bit 79007900 1527315273 2841128411 5258152581 3098630986 2048-bit2048-bit 15911591 31153115 57225722 1055410554 52395239 4096-bit4096-bit 152152 296296 537537 993993 743743

측정 결과에 따르면 하나의 CPU 코어가 2048비트 키를 사용하여 초당 1500개 이상의 작업을 처리할 수 있지만, 키 크기를 두 배로 늘리면 성능이 훨씬 떨어진다. NIST는 현재 RSA 키 크기를 2048비트 키로 권장하지만, 2030년 이후 보안이 필요한 경우 3072+ 비트를 권장한다. 또한, 4096비트 RSA를 채택하는 사이트의 수가 빠르게 증가하고 있어 TLS 키 교환을 위한 CPU 성능이 가까운 장래에 불충분할 것임을 시사한다. 반면 PKA는 2048비트 및 4096비트 RSA에 대해 각각 단일 CPU 코어보다 3.3배 및 4.8배 우수한 성능을 보이고 있다. 이는 NIC가 TLS 핸드셰이크 처리를 위해 3.3 또는 4.8 CPU 코어를 절약할 수 있음을 보여준다.Measurements show that one CPU core can handle more than 1500 operations per second with a 2048-bit key, but doubling the key size degrades performance significantly. NIST currently recommends a 2048-bit key size for RSA keys, but recommends 3072+ bits for security after 2030. Additionally, the number of sites adopting 4096-bit RSA is growing rapidly, suggesting that CPU performance for TLS key exchange will be insufficient in the near future. On the other hand, PKA outperforms a single CPU core by 3.3x and 4.8x for 2048-bit and 4096-bit RSA, respectively. This shows that the NIC can save either 3.3 or 4.8 CPU cores for handling the TLS handshake.

요약하면, 최신 CPU는 TLS 핸드셰이크를 수행하는 것보다 TLS 데이터 패킷을 암호화하는 데 상대적으로 더 높은 용량을 가지고 있다. TLS 핸드셰이크를 SmartNIC로 오프로드할 수 있다면 더 높은 TLS 성능을 위해 AES 및 SHA 작업에 더 많은 CPU 주기를 사용할 수 있다. 다행히 일부 SmartNIC에는 이미 하드웨어 PKA 모듈이 있으므로 TLS 핸드셰이크 오프로딩에 이를 활용할 수 있다. In summary, modern CPUs have a relatively higher capacity for encrypting TLS data packets than performing TLS handshakes. If the TLS handshake can be offloaded to the SmartNIC, more CPU cycles can be used for AES and SHA operations for higher TLS performance. Fortunately, some SmartNICs already have a hardware PKA module, which can be leveraged for TLS handshake offloading.

그러나 이것이 기존 SmartNIC가 TLS 핸드셰이크를 위한 충분한 용량을 가지고 있음을 의미하지는 않는다. 대신 Smart-NIC가 TLS 트래픽의 인라인 가속화를 위한 하드웨어 PKA의 적합한 장소라고 말할 수 있다. 최근 하드웨어 가속기가 2048비트 RSA에 대해 초당 120K 작업을 달성한다는 점을 감안할 때 SmartNIC에서 공개키 암호화의 성능을 더욱 향상시킬 수 있다. However, this does not mean that existing SmartNICs have sufficient capacity for TLS handshake. Instead, it can be said that Smart-NIC is a suitable place for hardware PKA for inline acceleration of TLS traffic. Given that recent hardware accelerators achieve 120K operations per second for 2048-bit RSA, the performance of public key cryptography on SmartNICs can be further improved.

핸드셰이크 복잡성 관리(Managing Handshake Complexity)Managing Handshake Complexity

NIC에서 TLS 핸드셰이크를 수행하려면 TCP 연결 설정 및 TLS 키 교환 중에 복잡한 상태 추적이 필요하므로 리소스가 제한된 SmartNIC에 심각한 오버헤드가 발생한다. 안정적인 패킷 전달을 보장하려면 패킷 손실 유추, 중복 ACK 감지, 타이머 구현 등이 필요하며, 이는 상당한 컴퓨팅 사이클을 소비하게 된다. 이 오버헤드는 SmartNIC에서 하드웨어 가속 공개키 암호화의 이점을 무효화하기에 충분히 클 수 있다.Performing the TLS handshake on the NIC imposes significant overhead on resource-constrained SmartNICs as it requires complex state tracking during TCP connection establishment and TLS key exchange. Ensuring reliable packet delivery requires inferring packet loss, detecting duplicate ACKs, and implementing timers, which consume significant computing cycles. This overhead can be large enough to negate the benefits of hardware accelerated public key encryption on SmartNICs.

최소 퍼-플로우 스테이트(minimal per-flow state)를 유지하는 것은 TLS 핸드셰이크 중 복잡성을 해결하는 핵심이다. 이 목표를 달성하기 위해 Smart-TLS는 TLS 핸드셰이크 프로세스를 두 단계로 나눈다. Maintaining a minimal per-flow state is key to solving the complexity during the TLS handshake. To achieve this goal, Smart-TLS divides the TLS handshake process into two steps.

첫째, 최근 작업에서 볼 수 있듯이 SYN 쿠키를 사용하여 상태 비저장 TCP 연결 설정을 보장한다. 이것은 본질적으로 타이머 기반 패킷 재전송과 반 개방 연결(half-opened connection)에 대한 상태 유지의 필요성을 제거한다. First, as seen in recent work, it uses a SYN cookie to ensure stateless TCP connection establishment. This essentially eliminates the need for timer-based packet retransmissions and state maintenance for half-opened connections.

둘째, SmartTLS는 키 교환 단계에서 패킷 손실 및 재전송을 추론하기 위해 TLS 클라이언트를 이용한다. Second, SmartTLS uses a TLS client to infer packet loss and retransmission in the key exchange phase.

도 2에 도시된 바와 같이, 서버가 해야 할 일은 TLS 핸드셰이크 동안 클라이언트 측 패킷에 수동적으로 응답하는 것이다. 도 2는 2048 비트 RSA와의 키 교환을 위한 SmartTLS에서의 TLS(v1.2) 연결의 데이터 흐름을 나타낸다. 괄호의 값들은 각 레코드에 필요한 바이트 수를 나타낸다. SmartTLS는 핸드셰이크 도중 각 화살표에 있는 모든 TLS 레코드를 단일 패킷으로 병합한다.As shown in Figure 2, what the server has to do is to passively respond to client-side packets during the TLS handshake. Figure 2 shows the data flow of a TLS (v1.2) connection in SmartTLS for key exchange with 2048-bit RSA. The values in parentheses indicate the number of bytes required for each record. SmartTLS merges all TLS records on each arrow during the handshake into a single packet.

SmartTLS는 마지막으로 전송된 시퀀스 번호와 마지막으로 수신된 ACK를 추적해야 하지만 클라이언트가 서버에서 패킷을 수신하지 않으면 이전 패킷을 재전송하므로 서버는 자체 패킷의 손실을 유추할 필요가 없다. 필요한 경우, 서버는 클라이언트 측 패킷에 대한 응답으로 패킷을 재전송한다.SmartTLS must keep track of the last transmitted sequence number and the last ACK received, but if the client does not receive a packet from the server, it retransmits the previous packet, so the server does not need to infer the loss of its own packet. If necessary, the server retransmits the packet in response to the client-side packet.

이러한 설계는 패킷 손실이 드물게 발생하는 실제 세계에서 일반적으로 최적화된다. 이를 통해 마지막 시퀀스/ACK 번호와의 연결의 네 가지 튜플, 무결성 계산 및 재전송을 위한 캐시된 TLS 패킷, 그리고 보안 매개변수(의사 난수 및 프리 마스터(pre-master)/마스터 시크릿(master secret))를 최소 상태로 유지할 수 있는 흐름별 타이머와 패킷 손실 추적을 없앨 수 있다. 키 교환 중에 클라이언트를 사용할 수 없게 되는 예외적인 경우를 방지하기 위해, 이 단계에서 몇 초 동안 멈춘 부실 연결을 주기적으로 제거하는 NIC에 코스 그레인드 글로벌 타이머(coarse-grained global timer)를 구현한다.This design is usually optimized in the real world where packet loss is rare. This allows four tuples of the connection with the last sequence/ACK number, cached TLS packets for integrity calculation and retransmission, and security parameters (pseudo-random number and pre-master/master secret). You can eliminate per-flow timers and packet loss tracking that can be kept to a minimum. To avoid exceptional cases where the client becomes unavailable during key exchange, implement a coarse-grained global timer on the NIC that periodically removes stale connections that have stalled for a few seconds at this stage.

NIC 내장형 시스템 바이패스(Bypassing Embedded System on NIC)Bypassing Embedded System on NIC

SmartNIC에 내장된 가속기를 활용하려면 패킷을 NIC의 내장형 시스템으로 전달해야 한다. Mellanox Bluefield와 같은 SmartNIC의 임베디드 시스템은 16GB 메모리가있는 16코어 ARMv8 프로세서를 사용하지만, Intel DPDK와 같은 확장 가능한 패킷 I/O 라이브러리를 사용하더라도 일반 CPU 기반 시스템에 비해 패킷 처리 성능이 상당히 제한된다. 임베디드 시스템을 통해 모든 패킷을 전달하면 지연 시간이 증가 할뿐만 아니라 전체 처리량이 저하된다.To utilize the accelerator built into the SmartNIC, the packet must be forwarded to the NIC's built-in system. SmartNIC's embedded systems, such as Mellanox Bluefield, use a 16-core ARMv8 processor with 16GB of memory, but even with scalable packet I/O libraries such as Intel DPDK, packet processing performance is significantly limited compared to typical CPU-based systems. Passing every packet through an embedded system not only increases latency, but also degrades overall throughput.

다른 모든 패킷은 SmartNIC 시스템을 우회하면서 TLS 핸드셰이크에 필요한 패킷만 임베디드 시스템으로 전달하는 것이 이상적이다. 이 목표를 위해 SmartNIC에서 하드웨어 패킷 스위치를 활용하는 아이디어를 탐구한다. Bluefield NIC는 NIC 내장 시스템이 트래픽 제어(TC) 규칙을 추가하여 패킷을 호스트 시스템으로 직접 전달할 수 있도록 하는 ASAP2 OvS 오프로드를 지원한다. 두 가지 경우에 TC 규칙을 사용한다. 먼저, 초기화시 관련 TLS 패킷(예: 일치하는 대상 포트 번호 포함)만 임베디드 시스템에 전달하는 규칙을 설치한다. 그런 다음 다른 모든 패킷은 호스트로 직접 전달된다. 둘째, 흐름에 대한 TLS 핸드셰이크가 완료될 때마다 SmartTLS는 흐름의 모든 향후 패킷이 임베디드 시스템을 우회하도록 4개의 튜플이 포함된 새 TC 규칙을 삽입한다. 연결이 종료되면 하드웨어 스위치에서 TC 규칙을 제거할 수 있다. 설치된 TC 규칙은 호스트 시스템으로의 회선 속도 패킷 전달을 약속한다.Ideally, only those packets needed for the TLS handshake should be forwarded to the embedded system, bypassing the SmartNIC system for all other packets. To this end, we explore the idea of utilizing hardware packet switches in SmartNICs. Bluefield NICs support ASAP2 OvS offload, which allows the NIC embedded system to forward packets directly to the host system by adding traffic control (TC) rules. The TC rule is used in two cases. First, install a rule that only forwards relevant TLS packets (eg, with a matching destination port number) to the embedded system upon initialization. All other packets are then passed directly to the host. Second, whenever the TLS handshake for a flow is complete, SmartTLS inserts a new TC rule with a 4 tuple to ensure that all future packets in the flow bypass the embedded system. The TC rule can be removed from the hardware switch once the connection is closed. The installed TC rules promise to forward line-rate packets to the host system.

현재 시스템(즉, Bluefield NIC)은 많은 설치된 규칙으로 빠른 규칙 설정/제거 또는 높은 처리량을 달성하지 못한다. Bluefiled NIC에서 TC 규칙을 설치하거나 제거하는 데 1밀리 초 이상이 걸린다. 또한 최대 40K TC 규칙을 지원하지만 설치된 규칙의 수가 증가함에 따라 패킷 전달 속도는 점차 감소하여, 40K TC 규칙에서는 회선 속도의 절반으로 떨어진다. 장기적으로는 하드웨어 스위치 성능이 향상되기를 바라지만 그 동안 장기 실행 TLS 연결에 대해서만 TC 규칙을 설치할 수 있다.Current systems (ie Bluefield NICs) do not achieve fast rule set/remove or high throughput with many installed rules. Installing or removing TC rules from Bluefiled NIC takes more than 1 millisecond. It also supports up to 40K TC rules, but the packet forwarding rate gradually decreases as the number of installed rules increases, dropping to half the line rate in 40K TC rules. In the long run, we hope to improve hardware switch performance, but in the meantime we can only install TC rules for long running TLS connections.

SmartNIC 오버로드 방지(Preventing SmartNIC Overload)Preventing SmartNIC Overload

TLS 핸드셰이크를 오프로딩하면 호스트 CPU의 계산 부담이 줄어들지만, 너무 많은 동시 TLS 핸드셰이크가 호스트 CPU가 유휴상태인 동안 NIC에 과부하가 걸릴 수 있다. 호스트 CPU와 SmartNIC간에 TLS로드 밸런싱을 유지하는 것이 바람직하지만 대부분의 연결이 수명이 짧은 경우 달성하기 어렵다.Offloading the TLS handshake reduces the computational burden on the host CPU, but too many concurrent TLS handshakes can overload the NIC while the host CPU is idle. It is desirable to have TLS load balancing between the host CPU and SmartNIC, but difficult to achieve if most connections are short-lived.

두 컴퓨팅 리소스를 균형 있게 사용하기 위해 TLS 핸드셰이크의 기회적 오프 로딩을 고려한다. 아이디어는 매우 간단하다. NIC에 대한 로드가 "높음" 임계값을 초과하면 NIC는 호스트 CPU에 TLS 핸드셰이크를 계속하도록 요청하는 동안 TCP 연결 설정만 수행한다. 이를 위해 SmartNIC는 암호화 가속기에 대한 로드를 반영하는 간단한 카운터를 유지한다(예: 암호화 작업이 발송될 때 증가하고 출력이 생성될 때 감소함). TCP 연결 설정은 상태 비저장 특성이 높은 부하에서도 높은 처리량을 보장하므로 NIC에서 계속 수행된다. 부하가 "낮은" 임계값 아래로 내려 가면 SmartTLS는 TLS 핸드셰이크 오프로딩을 다시 활성화한다. 즉, 카운터는 암호화 가속기에 대한 로드를 측정하고, 해당 측정값은 임계값과 비교된다.Consider the opportunistic offloading of the TLS handshake to balance the use of both computing resources. The idea is very simple. When the load on the NIC exceeds the "high" threshold, the NIC only performs TCP connection establishment while requesting the host CPU to continue the TLS handshake. To this end, the SmartNIC maintains a simple counter that reflects the load on the cryptographic accelerator (eg increment when a cryptographic operation is sent and decrement when an output is generated). TCP connection establishment is performed continuously on the NIC because stateless nature guarantees high throughput even under high load. When the load drops below the "low" threshold, SmartTLS re-enables TLS handshake offloading. That is, the counter measures the load on the crypto accelerator, and that measurement is compared to a threshold.

본 발명은 오프로딩 단위가 개별 작업이 아니라 전체 TLS 핸드셰이크라는 점에서 종래 기술과 차별점이 있다. 이 설계적 선택은 호스트와 NIC TLS 스택 간의 상태 공유를 최소화하여 구현을 단순화한다. 완전히 투명한 기능이므로 응용 프로그램을 수정할 필요가 없다.The present invention is different from the prior art in that the offloading unit is an entire TLS handshake rather than an individual operation. This design choice simplifies implementation by minimizing state sharing between the host and the NIC TLS stack. Since it is a completely transparent feature, there is no need to modify the application.

구현(IMPLEMENTATION)IMPLEMENTATION

도 3은 상술한 설계 선택 사항을 반영하는 SmartTLS NIC 스택의 전체 아키텍처를 보여준다. 새 패킷이 도착하면 NIC의 하드웨어 패킷 분류기(hardware packet classifier)는 패킷이 설치된 TC 규칙을 사용하여 호스트로 직접 전달되어야 하는지 여부를 결정한다. 3 shows the overall architecture of the SmartTLS NIC stack reflecting the design choices described above. When a new packet arrives, the NIC's hardware packet classifier determines whether the packet should be forwarded directly to the host using the installed TC rules.

규칙과 일치하지 않는 경우, 패킷은 NIC의 내장형 시스템으로 전달된다. 그런 다음 시스템은 흐름표(flow table)에서 패킷의 연결 상태를 조회한다. 흐름을 찾을 수 없는 SYN 패킷인 경우 시스템은 SYN 쿠키를 사용하여 TCP 연결 설정으로 들어간다. 일치하는 흐름 항목이 발견되면 시스템은 항목의 "onload" 플래그를 확인하여 흐름의 패킷을 호스트로 전달해야 하는지 여부를 표시한다. 플래그가 꺼져 있으면(예: 도면에서 F2), 시스템은 패킷과 TLS 핸드셰이크를 수행한다. 흐름은 일반적으로 TLS 핸드셰이크가 끝나면 온로드되지만 NIC가 과부하 상태인 경우 TCP 연결 설정 직후에 플래그를 설정할 수 있다(예: 도면의 F4).If no rules are matched, the packet is forwarded to the NIC's embedded system. Then, the system looks up the connection status of the packet in the flow table. For SYN packets with no flow found, the system uses a SYN cookie to enter TCP connection establishment. When a matching flow entry is found, the system checks the entry's "onload" flag to indicate whether the flow's packets should be forwarded to the host. If the flag is off (eg F2 in the figure), the system performs a TLS handshake with the packet. Flows are usually onloaded at the end of the TLS handshake, but if the NIC is overloaded, you can set a flag right after TCP connection establishment (eg F4 in the figure).

NIC는 흐름을 호스트로 온로드할 때 TLS 메타 데이터를 전달한다. TLS 메타 데이터에는 흐름의 튜플 4개와 세션에 대한 TLS 매개 변수(예 : TLS 버전 및 세션 키)가 포함된다. 그런 다음 호스트는 메타 데이터에 따라 TLS 세션으로 TCP/TLS 흐름 상태를 생성하고 동일한 흐름에 속하는 모든 후속 패킷을 처리한다. NIC가 부하를 호스트 측으로 오프로드하기로 결정한 경우 호스트는 자체적으로 TLS 핸드셰이크를 처리할 수 있어야 한다. 호스트 TLS 스택은 일관된 API를 애플리케이션 계층에 노출하여 내부적으로 이 두 개의 개별 경로를 관리한다. 애플리케이션은 TLS 핸드셰이크가 수행되는 위치를 신경 쓸 필요가 없다.The NIC carries TLS metadata when onloading the flow to the host. The TLS metadata contains 4 tuples of the flow and the TLS parameters for the session (eg TLS version and session key). The host then creates a TCP/TLS flow state with the TLS session according to the metadata and processes all subsequent packets belonging to the same flow. If the NIC decides to offload the load to the host side, the host should be able to handle the TLS handshake on its own. The host TLS stack manages these two separate routes internally by exposing a consistent API to the application layer. Applications do not need to care where the TLS handshake is performed.

본 발명은 Mellanox Bluefield NIC로 프로토 타입을 구현한다. NIC 스택에는 DPDK를 사용한 패킷 I/O, TCP/TLS 흐름 관리 및 PKA 모듈을 사용한 암호화 가속을 위한 6,942라인의 C코드(LoC)가 포함되어 있다. mTCP 사용자 수준 TCP 스택 위에 호스트 스택을 구축하고 TLS 1.2 작업을 준수하기 위해 4,486 LoC를 작성한다. TLS 사이퍼스위트(ciphersuite)의 경우 현재 TLS_RSA_AES_256_GCM_SHA384 및 TLS_RSA_AES_256_CBC_SHA를 구현할 수 있다.The present invention implements a prototype with a Mellanox Bluefield NIC. The NIC stack contains 6,942 lines of C code (LoC) for packet I/O using DPDK, TCP/TLS flow management, and cryptographic acceleration using the PKA module. It builds the host stack on top of the mTCP user-level TCP stack and writes 4,486 LoCs to comply with TLS 1.2 operations. For the TLS ciphersuite, TLS_RSA_AES_256_GCM_SHA384 and TLS_RSA_AES_256_CBC_SHA may be implemented.

평가(EVALUATION)EVALUATION

TLS 핸드셰이크를 Smart로 오프로드할 때의 효과를 평가한다. SmartTLS 위에 간단한 HTTPS 웹 서버를 구현하고 Linux TCP 스택(커널 버전 3.10) 및 OpenSSL 1.0.2를 사용하는 mTCP 사용자 수준 스택에서 TLS 성능을 nginx와 비교한다. SmartTLS는 OpenSSL과 유사한 동기 암호화 API를 제공하므로 기존 애플리케이션을 SmartTLS를 사용하도록 마이그레이션하는 것은 비교적 간단해야 한다.Evaluate the effect of offloading the TLS handshake to Smart. Implementing a simple HTTPS web server on top of SmartTLS and comparing TLS performance with nginx on mTCP user-level stack using Linux TCP stack (kernel version 3.10) and OpenSSL 1.0.2. SmartTLS provides a synchronous encryption API similar to OpenSSL, so migrating existing applications to use SmartTLS should be relatively straightforward.

(실험 설정) 4개의 클라이언트로 하나의 서버의 성능을 측정한다. 모든 컴퓨터에는 32GB DRAM이 포함된 Intel Xeon CPU E5-2640 [email protected](8 코어)가 있다. 서버는 ARMv8 A72(16 코어) 및 16GB DRAM이있는 듀얼 포트 25G Mellanox BlueField NIC로 구성되어 있지만 평가에는 포트 중 하나만 사용된다. 모든 클라이언트는 Intel XL710 40GbE NIC로 구성된다. Linux 및 mTCP 스택에서의 실험을 위해 모든 패킷을 호스트 측으로 직접 전달하도록 서버의 SmartNIC를 구성한다. SmartTLS 실험의 경우 호스트 CPU에서 TLS 핸드셰이크를 기회적으로 오프로드한다. (Experimental setup) Measure the performance of one server with 4 clients. All computers have Intel Xeon CPU E5-2640 [email protected] (8 cores) with 32GB DRAM. The server is configured with an ARMv8 A72 (16 cores) and a dual port 25G Mellanox BlueField NIC with 16GB DRAM, but only one of the ports is used for evaluation. All clients are configured with Intel XL710 40GbE NICs. Configure the server's SmartNIC to forward all packets directly to the host side for experiments on Linux and mTCP stacks. For SmartTLS experiments, we opportunistically offload the TLS handshake from the host CPU.

(TLS 핸드셰이크 성능) 도 4는 다양한 CPU 코어 수에 대한 TLS 연결 설정의 처리량을 비교하는 실험 결과를 나타내는 그래프이다. 이 실험은 2048 비트 RSA 작업으로 TLS 키 교환을 사용하여 단위 시간에 생성할 수 있는 TLS 연결 수를 보여준다. 단일 CPU 코어를 사용하는 Linux SSL 스택은 초당 1000 개 이상의 연결을 처리하며 처리량이 CPU 코어 수에 비례하여 증가하는 것을 관찰한다. 사용자 수준 TCP 스택으로 전환하면 작은 패킷 처리 효율성이 높아져 성능이 약 8~26 % 향상된다. SmartTLS는 초당 6.3K ~ 13.3K TLS 연결 설정을 달성하여 Linux 스택에 비해 1.7~5.9배 향상된다. 이를 통해 NIC의 하드웨어 PKA 모듈이 많은 RSA 작업을 효과적으로 오프로드하는 동시에 기회주의적 오프로드로 NIC와 호스트 CPU의 로드가 균형을 이루는지 확인할 수 있다. (TLS Handshake Performance) FIG. 4 is a graph showing experimental results comparing the throughput of TLS connection establishment for various number of CPU cores. This experiment shows the number of TLS connections that can be created per unit time using TLS key exchange with a 2048-bit RSA operation. The Linux SSL stack with a single CPU core handles over 1000 connections per second and we observe that throughput increases proportionally with the number of CPU cores. Switching to a user-level TCP stack increases the efficiency of small packet processing, resulting in a performance improvement of about 8-26%. SmartTLS achieves 6.3K to 13.3K TLS connection establishments per second, a 1.7 to 5.9x improvement over the Linux stack. This allows the NIC's hardware PKA module to effectively offload many RSA tasks while ensuring that the load on the NIC and host CPU is balanced with opportunistic offloading.

도 5는 단일 CPU 코어를 사용하여 HTTPS에서 1바이트 파일을 다운로드하는 99%의 꼬리 응답 시간(tail latency)을 비교하는 그래프이다. 동시 연결 수가 적을 때 CPU 전용 접근 방식은 SmartNIC의 임베디드 시스템에서 패킷 처리 지연으로 인해 더 나은 대기 시간을 보여준다. 그러나 동시성이 2개의 흐름을 초과하면 Linux 스택의 꼬리 지연 시간이 16개의 흐름에서 SmartTLS의 지연 시간보다 두 배 이상 빠르게 증가한다. 이는 호스트 CPU가 TLS 핸드셰이크의 병목 현상이 쉽게 발생하여 적은 수의 동시 흐름에도 처리 대기 시간을 증가시킬 수 있음을 나타낸다.5 is a graph comparing the tail latency of 99% for downloading a 1-byte file from HTTPS using a single CPU core. When the number of simultaneous connections is small, the CPU-only approach shows better latency due to packet processing delay in SmartNIC's embedded system. However, when the concurrency exceeds 2 flows, the tail latency of the Linux stack grows more than twice as fast as the latency of SmartTLS at 16 flows. This indicates that the host CPU can easily bottleneck the TLS handshake, increasing processing latency even with a small number of concurrent flows.

(혼합된 워크로드 성능) 단기 연결이 TLS에서 대용량 파일 전송 성능을 방해할 수 있는지 조사한다. NIC 대역폭을 채우는 HTTPS에서 대용량 파일(4GB)을 전송하는 몇 가지 흐름을 설정했다. 그런 다음 1바이트 파일을 반복적으로 다운로드하는 몇 가지 단기 연결을 추가하기 시작한다. 키 교환에는 2048 비트 RSA를 사용하고 데이터 암호화 및 무결성에는 SHA384와 함께 AES-GCM 256 비트 키를 사용한다. 이 실험에서는 주어진 TLS 암호 그룹으로 25Gbps의 NIC 대역폭을 포화시키기에 충분한 4개의 CPU 코어를 사용한다. (Mixed workload performance) Investigate whether short-lived connections can interfere with large file transfer performance over TLS. I've set up a few flows to transfer large files (4 GB) over HTTPS that fill the NIC's bandwidth. Then I start adding a few short-lived connections that repeatedly download single-byte files. It uses 2048-bit RSA for key exchange and AES-GCM 256-bit keys with SHA384 for data encryption and integrity. In this experiment, we use 4 CPU cores, sufficient to saturate the NIC bandwidth of 25 Gbps with a given TLS cipher suite.

도 6은 단기 흐름의 수가 증가함에 따라 대용량 파일 트래픽의 처리량이 감소함을 보여주는 그래프이다. 16개의 동시 흐름만으로 처리량 손실이 40%까지 관찰된다. 이는 AES-GCM 및 RSA 작업에 대한 호스트 CPU의 과도한 경합 때문이다. 대조적으로, SmartTLS를 사용할 때 단기 흐름의 TLS 핸드셰이크가 NIC의 암호화 가속기로 효과적으로 오프로드되므로 대용량 파일 트래픽에서 성능 저하가 거의 또는 전혀 발생하지 않는다.6 is a graph showing that the throughput of large file traffic decreases as the number of short-term flows increases. With only 16 simultaneous flows, a throughput loss of up to 40% is observed. This is due to excessive contention of the host CPU for AES-GCM and RSA tasks. In contrast, when using SmartTLS, the short-lived TLS handshake is effectively offloaded to the NIC's cryptographic accelerator with little or no performance penalty for large file traffic.

관련 작업(Related Work)Related Work

(PCIe 기반 암호화 가속기) 하드웨어 암호화 가속기는 오랫동안 TLS 트래픽을 처리하기 위해 CPU를 보완하는 데 사용되어 왔다. 이는 GPU 또는 FGPA와 같은 범용 프로세서 또는 Intel QAT(QuickAssist Technology) 또는 Marvel Nitrox 보안 프로세서와 같은 전용 장치를 기반으로 할 수 있다. 사실 최근 액셀러레이터의 성능이 인상적이다. 예를 들어 QTLS는 IntelQAT 어댑터를 사용하는 2048비트 RSA로 초당 90K 이상의 TLS 핸드셰이크를 보고하는 반면 Nitrox V는 더 나은 성능(2048 비트 RSA의 경우 120K/초)을 달성한다. 분명히 우리는 SmartTLS 프로토 타입이 이러한 가속기를 능가한다고 주장하지 않는다. 반대로, 우리의 주요 주장은 TLS 전용 가속기를 사용하는 것보다 고성능 PKA 모듈을 NIC에 배치하는 것이 더 간단하고 잠재적으로 비용 효율적이라는 것이다. 이는 PCIe 기반 암호화 가속기를 사용하는 것이 고성능을 위해 암호화 작업의 비동기/일괄 처리가 필요하기 때문에 종종 복잡하기 때문이다. 또한 AES-NI를 사용하는 최신 CPU의 AES 성능이 이러한 가속기의 성능과 비슷하거나 더 우수하므로 성능 이점은 대부분 공개키 작업으로 제한된다. (PCIe-based Cryptographic Accelerator) Hardware cryptographic accelerators have long been used to supplement CPUs to handle TLS traffic. It can be based on a general-purpose processor such as a GPU or FGPA, or a dedicated device such as an Intel QuickAssist Technology (QAT) or Marvel Nitrox security processor. In fact, the recent accelerator performance is impressive. For example, QTLS reports over 90K TLS handshakes per second with 2048-bit RSA using the IntelQAT adapter, while Nitrox V achieves better performance (120K/sec with 2048-bit RSA). Obviously, we are not claiming that the SmartTLS prototype outperforms these accelerators. Conversely, our main argument is that it is simpler and potentially cost-effective to deploy a high-performance PKA module on a NIC than to use a TLS-only accelerator. This is because using PCIe-based cryptographic accelerators is often complex as it requires asynchronous/batch processing of cryptographic operations for high performance. Also, because AES performance of modern CPUs using AES-NI is comparable to or better than that of these accelerators, the performance benefits are mostly limited to public key operations.

(데이터 암호화 및 무결성 계산 오프로드) 일부 NIC는 호스트 CPU와 TLS 핸드셰이크를 수행하는 동안 CPU에서 하드웨어 가속기로의 AES 및 SHA 작업 오프로드를 지원한다. 이 접근 방식은 SmartTLS의 접근 방식과 정반대이지만 워크로드가 주로 큰 메시지를 처리할 때 유용할 수 있다. 그러나 AES-NI가 최신 CPU에 도입됨에 따라 데이터 암호화 오프로딩의 효율성이 상대적으로 감소했다고 생각한다. AES-GCM은 인증 된 데이터 무결성을 포함하고, 이에 대한 CPU 오버 헤드가 요즘 상당히 낮기 때문에 특히 워크로드가 크고 작은 전송이 혼합 된 경우 TLS 키 교환을 오프 로딩하는 것이 더 비용 효율적이다. (Data encryption and integrity computation offload) Some NICs support offloading AES and SHA operations from the CPU to the hardware accelerator while performing a TLS handshake with the host CPU. This approach is the exact opposite of SmartTLS's approach, but can be useful when the workload is primarily processing large messages. However, I think that the efficiency of data encryption offloading has decreased relatively as AES-NI is introduced in modern CPUs. Because AES-GCM includes authenticated data integrity, and the CPU overhead for it is quite low these days, it is more cost-effective to offload the TLS key exchange, especially if the workload is a mix of large and small transports.

TLS 핸드셰이크의 NIC 오프 로딩은 최신 TLS 트래픽을 처리할 때 잠재적으로 많은 양의 CPU주기를 줄일 수 있는 실행 가능한 옵션임을 보여주었다. SmartNIC로 프로토 타입 시스템을 구축하고 HTTPS 트래픽으로 성능 이점을 확인했다.NIC offloading of the TLS handshake has been shown to be a viable option to potentially reduce a large amount of CPU cycles when handling modern TLS traffic. We built a prototype system with SmartNIC and saw performance benefits with HTTPS traffic.

현재 인터넷 트래픽의 70퍼센트 이상이 암호화되어있으며, 규모가 큰 주요 웹 사이트 대부분이 보안 연결을 기본으로 설정되어있다. 따라서, 본 발명의 적용 가능 범위는 대부분의 웹사이트 호스팅에 해당하며 전자메일, 소셜네트워크서비스, 전자상거래 등의 어플리케이션도 포함한다. 특히 다수의 짧은 보안 연결이 맺어지며 이로 인해 암호화 알고리즘 처리에 병목이 형성될 우려가 있을 때, 본 발명을 적용함으로써 문제를 해결할 수 있다. 또한 발명을 적용한 후에도 기존의 어플리케이션을 큰 수정없이 유지할 수 있으므로 더 쉽게 사용될 수 있다. 이러한 점에서 본 발명의 시장성은 매우 높다고 할 수 있다.Today, more than 70 percent of Internet traffic is encrypted, and most of the largest and most popular websites have secure connections by default. Accordingly, the scope of application of the present invention corresponds to most website hosting and includes applications such as e-mail, social network service, and e-commerce. In particular, when a large number of short secure connections are established and there is a concern that a bottleneck may be formed in processing an encryption algorithm, the problem can be solved by applying the present invention. In addition, even after applying the invention, the existing application can be maintained without major modifications, so that it can be used more easily. In this respect, it can be said that the marketability of the present invention is very high.

본 발명은 기존에 존재하는 프로그래머블 네트워크 어댑터를 사용하며 본 발명만을 위한 맞춤형 하드웨어 장비를 사용하지 않는 소프트웨어로써의 시스템 솔루션으로 제공될 수 있다. 때문에 기술사업화에 있어 인프라 구축에 큰 비용을 필요로 하지 않을 것으로 기대된다. 또한, 널리 사용되는 리눅스 기반 서버 전반에 적용 가능하므로 범용성 또한 높기에 기술사업화 전망이 충분히 있다.The present invention can be provided as a system solution as software that uses an existing programmable network adapter and does not use hardware equipment customized only for the present invention. Therefore, it is expected that the technology commercialization will not require large costs for infrastructure construction. In addition, as it can be applied to all widely used Linux-based servers, the versatility is also high, so there is a sufficient prospect for technology commercialization.

도 7은 본 발명에 따른 보안연결 설정기능 이양방법을 수행하기 위한 네트워크 어댑터(200)의 호스트(300) 및 클라이언트(100) 사이에서의 통신 방법을 설명하기 위한 구성도이다.7 is a configuration diagram for explaining a communication method between the host 300 and the client 100 of the network adapter 200 for performing the secure connection establishment function transfer method according to the present invention.

네트워크 어댑터(200)는 호스트(300) 및 클라이언트(100) 사이에서의 데이터 송수신을 중개한다. 네트워크 어댑터(200)는 포트부(210), 프로세서(220), 호스트 인터페이스부(230), 메모리부(240) 및 암호화 가속기(250)를 포함한다.The network adapter 200 mediates data transmission/reception between the host 300 and the client 100 . The network adapter 200 includes a port unit 210 , a processor 220 , a host interface unit 230 , a memory unit 240 , and an encryption accelerator 250 .

포트부(210)는 클라이언트(100)를 포함한 외부 디바이스와 네트워크 커넥터(200) 사이의 데이터 송수신을 중개한다. 포트부(210)는 네트워크 케이블을 통해 외부 네트워크와 연결 가능하며, 유/무선 통신을 수행할 수 있다.The port unit 210 mediates data transmission/reception between an external device including the client 100 and the network connector 200 . The port unit 210 can be connected to an external network through a network cable, and can perform wired/wireless communication.

프로세서(220)는 네트워크 커넥터(200)의 각 구성요소들 사이에서의 데이터 처리를 전반적으로 제어할 수 있다. 프로세서(220)는 네트워크 커넥터(200)의 클라이언트(100) 및/또는 호스트(300)와의 데이터 송수신과 관련된 패킷들을 생성, 전송, 수신할 수 있다. 프로세서(220)는 호스트 인터페이스부(230)로부터 TCP 연결 종료 패킷을 전송받아 처리할 수 있다. 프로세서(220)는 포트부(210)로부터 TCP 연결 요청 패킷을 전송받아 처리할 수 있다. The processor 220 may control overall data processing between each component of the network connector 200 . The processor 220 may generate, transmit, and receive packets related to data transmission/reception with the client 100 and/or the host 300 of the network connector 200 . The processor 220 may receive and process the TCP connection termination packet from the host interface unit 230 . The processor 220 may receive and process the TCP connection request packet from the port unit 210 .

프로세서(220)는 포트부(210) 및/또는 호스트 인터페이스부(230)와의 데이터 송수신, 데이터 처리 등에 대한 정보를 메모리부(240)로 저장할 수 있고, 메모리부(240)에 기 저장된 정보를 독출할 수도 있다.The processor 220 may store information on data transmission/reception and data processing with the port unit 210 and/or the host interface unit 230 in the memory unit 240 , and read information previously stored in the memory unit 240 . may go out

호스트 인터페이스부(230)는 호스트(300)와의 통신을 위한 인터페이스로 PCI(peripheral component interconnect)등을 포함하여 유/무선 통신을 수행할 수 있다. The host interface unit 230 is an interface for communication with the host 300 and may perform wired/wireless communication including peripheral component interconnect (PCI).

메모리부(240)는 프로세서(220)의 데이터 처리 결과를 저장할 수 있다. 메모리부(240)는 포트부(210)를 통해 프로세서(220)에 도착한 패킷 정보들을 저장하거나, 패킷 처리 및/또는 TCP 연산 처리 과정에서 필요한 메타데이터들을 저장할 수 있으며, SRAM 및/또는 DRAM을 포함할 수 있다.The memory unit 240 may store the data processing result of the processor 220 . The memory unit 240 may store packet information that arrives at the processor 220 through the port unit 210 or may store metadata necessary for packet processing and/or TCP operation processing, and includes SRAM and/or DRAM. can do.

암호화 가속기(250)는 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘을 수행한다. 즉, 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘은 암호화 가속기(250)에 의해서 수행된다. 이 과정에서 네트워크 어댑터(200)는 능동적으로 패킷을 읽고 클라이언트에게 응답하지만, 패킷 손실 탐지, 재전송, 혼잡 제어 등 복잡한 기저 프로토콜 기능은 수행하지 않는다. 암호화 가속기(250)의 구체적인 기능 및 동작방식과 관련해서는 위에서 상세히 설명한 바, 중복 설명은 생략하기로 한다.The encryption accelerator 250 performs an asymmetric encryption algorithm used in the key exchange process. That is, the asymmetric encryption algorithm used in the key exchange process is performed by the encryption accelerator 250 . In this process, the network adapter 200 actively reads packets and responds to the client, but does not perform complex underlying protocol functions such as packet loss detection, retransmission, and congestion control. As detailed functions and operation methods of the cryptographic accelerator 250 have been described in detail above, redundant descriptions will be omitted.

위에서 설명한 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 기록 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.The method described above may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable recording medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the present invention, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic such as floppy disks. - includes magneto-optical media, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

이상에서 실시예들에 설명된 특징, 구조, 효과 등은 본 발명의 하나 의 실시예에 포함되며, 반드시 하나의 실시예에만 한정되는 것은 아니다. 나아가, 각 실시예에서 예시된 특징, 구조, 효과 등은 실시예들이 속하는 분야의 통상의 지식을 가지는 자에 의해 다른 실시예들에 대해서도 조합 또는 변형되어 실시 가능하다. 따라서 이러한 조합과 변형에 관계된 내용들은 본 발명의 범위에 포함되는 것으로 해석되어야 할 것이다.Features, structures, effects, etc. described in the above embodiments are included in one embodiment of the present invention, and are not necessarily limited to one embodiment. Furthermore, features, structures, effects, etc. illustrated in each embodiment can be combined or modified for other embodiments by those of ordinary skill in the art to which the embodiments belong. Accordingly, the contents related to such combinations and modifications should be interpreted as being included in the scope of the present invention.

100: 클라이언트(Client)
200: 네트워크 인터페이스 카드(Network Interface Card; NIC)
210: 포트부
220: 프로세서
230: 호스트 인터페이스부
240: 메모리부
250: 암호화 가속기
300: 호스트(Host)100: Client
200: Network Interface Card (NIC)
210: port unit
220: processor
230: host interface unit
240: memory unit
250: crypto accelerator
300: Host

Claims (11)

클라이언트와의 데이터 송수신을 위한 포트부;
호스트와의 데이터 송수신을 위한 호스트 인터페이스부; 및
상기 호스트 장치와 클라이언트 간의 보안 연결 설정을 수행하기 위한 암호화 가속기;를 포함하는 NIC(Network Interface Card).a port unit for transmitting and receiving data with a client;
a host interface unit for data transmission/reception with a host; and
NIC (Network Interface Card) comprising a; cryptographic accelerator for establishing a secure connection between the host device and the client. 제1항에 있어서,
상기 보안 연결 설정은 TCP 연결 설정 및 TLS 핸드셰이크를 포함하는 NIC(Network Interface Card).According to claim 1,
The secure connection establishment is a NIC (Network Interface Card) including TCP connection establishment and TLS handshake. 제2항에 있어서,
상기 TLS 핸드셰이크는 서버 인증 및 키 교환을 포함하고
상기 암호화 가속기는 비대칭 암호화 알고리즘을 수행하여 상기 키 교환을 수행하는 NIC(Network Interface Card).3. The method of claim 2,
The TLS handshake includes server authentication and key exchange;
The encryption accelerator is a NIC (Network Interface Card) for performing the key exchange by performing an asymmetric encryption algorithm. 제1항에 있어서,
암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함하는 NIC(Network Interface Card).According to claim 1,
When the cryptographic accelerator performs an asymmetric encryption algorithm, the base protocol function is not performed, and the base protocol function is a NIC (Network Interface Card) including any one of packet loss detection, retransmission, and congestion control. 제1항에 있어서,
상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않는 NIC(Network Interface Card).According to claim 1,
The host is a NIC (Network Interface Card) that does not participate in the secure connection establishment process until the secure connection is completed. 호스트가 사전 보안연결을 위해 NIC(Network Interface Card))에 전자증명서를 전달하고, 서버 인증 과정을 수행하는 단계;
상기 NIC가 웹 서버로 보내진 데이터를 지속적으로 모니터링하여 보안 연결이 필요하다고 판단되는 연결을 탐색하는 단계; 및
상기 NIC에 내장된 암호화 가속기(crypto accelerator)가 비대칭 암호화 알고리즘을 수행하여 클라이언트와 키 교환을 수행하는 단계;를 포함하는 보안연결 설정기능 이양방법.transmitting, by the host, an electronic certificate to a network interface card (NIC) for pre-secure connection, and performing a server authentication process;
continuously monitoring, by the NIC, data sent to a web server to discover a connection that is determined to require a secure connection; and
A secure connection establishment function transfer method comprising the step of performing, by a crypto accelerator built into the NIC, an asymmetric encryption algorithm to exchange a key with a client. 제6항에 있어서,
상기 NIC가, 보안 연결 설정 완료 후 상기 클라이언트와 교환한 공유 키와 보안 연결 정보를 상기 호스트에 전달하는 단계; 및
상기 호스트가, 연결 초기화 절차를 생략하고, 보안 연결을 이어가며 웹 서버 기능을 수행하는 단계;를 더 포함하는 보안연결 설정기능 이양방법.7. The method of claim 6,
transmitting, by the NIC, the shared key exchanged with the client and secure connection information to the host after completing secure connection establishment; and
The method of transferring a secure connection setting function further comprising the step of the host performing a web server function while omitting the connection initialization procedure and continuing the secure connection. 제7항에 있어서,
상기 호스트가, 보안 연결 종료 후 상기 NIC에게 종료 상태 정보를 전달하는 단계; 및
상기 NIC가, 동일한 클라이언트 IP 주소와 포트 번호에 대해 핸드셰이크 과정을 재개하는 단계;를 더 포함하는 보안연결 설정기능 이양방법.8. The method of claim 7,
transmitting, by the host, termination status information to the NIC after the secure connection is terminated; and
Resuming, by the NIC, the handshake process for the same client IP address and port number; Secure connection establishment function transfer method further comprising a. 제6항에 있어서,
상기 NIC는 상기 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며,
상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함하는 보안연결 설정기능 이양방법.7. The method of claim 6,
The NIC does not perform an underlying protocol function when the encryption accelerator performs an asymmetric encryption algorithm;
Wherein the base protocol function includes any one of packet loss detection, retransmission, and congestion control. 제6항에 있어서,
상기 서버 인증 이후, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않는 보안연결 설정기능 이양방법.7. The method of claim 6,
After the server authentication, the host does not participate in the secure connection establishment process until the secure connection is completed. 제6항 내지 제10항 중 어느 한 항에 기재된 보안연결 설정기능 이양방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터 판독 가능 기록매체.A computer-readable recording medium recording a program for executing the method of transferring a secure connection setting function according to any one of claims 6 to 10 in a computer.

Images