KR102476159B1 - Ｎｉｃ로의 보안연결 설정기능 이양방법 및 이를 이용한 ｎｉｃ, 그리고 컴퓨터 판독 가능 기록매체 - Google Patents

Abstract

본 발명에 따른 NIC(Network Interface Card))는 클라이언트와의 데이터 송수신을 위한 포트부, 호스트와의 데이터 송수신을 위한 호스트 인터페이스부 및 상기 호스트 장치와 클라이언트 간의 보안 연결 설정을 수행하기 위한 암호화 가속기를 포함한다. 본 발명은 보안 연결 설정으로 인한 부담을 덜기 위하여 보안 연결을 지원하는, 혹은 지원하고자 하는 웹서버 전반에 적용이 가능하다. 특히, CPU 자원을 보다 복잡한 작업에 집중시켜야 하는 데이터센터나 클라우드 컴퓨팅과 같은 규모가 큰 네트워크 시스템에 적용하면 성능 향상을 기대할 수 있다. 나아가 본 발명은 연산 능력이 상대적으로 부족한 소규모 서버에도 보안 연결로 인한 성능 저하를 막을 수 있다.

Description

ＮＩＣ로의 보안연결 설정기능 이양방법 및 이를 이용한 ＮＩＣ, 그리고 컴퓨터 판독 가능 기록매체{METHOD FOR OFFLOADING SECURE CONNECTION SETUP INTO NETWORK INTERFACE CARD, AND A NETWORK INTERFACE CARD, AND A COMPUTER-READABLE RECORDING MEDIUM}

본 발명은 웹 서버가 클라이언트와 보안 연결을 설정할 때 핸드셰이크 과정을 호스트에서 네트워크 인터페이스 카드로 동적 이양하는 방법 및 이를 이용한 NIC, 그리고 컴퓨터 판독 가능 기록매체에 관한 것이다.

TLS(Transport Layer Security)는 현대 인터넷에서 사설 네트워크 통신을 위한 핵심 구성 요소가 되었다. 최근 CPU의 발전으로 데이터 암호화 성능이 크게 향상되었지만 TLS 키 교환은 여전히 단기 트랜잭션의 병목 현상을 유지하고 있다. 전용 하드웨어 암호화 가속기(crypto accelerators)는 우수한 성능을 약속하지만, 비동기 처리의 고유한 아키텍처로 인해 애플리케이션의 침습적인 수정이 필요한 경우가 많다.

인터넷에서는 인터넷 트래픽의 70% 이상이 TLS로 암호화되는 반면 상위 100개 웹사이트 중 96개가 HTTPS를 기본 프로토콜로 제시하는 등 TLS가 점점 인기를 끌고 있다. TLS는 HTTP/2에서 기본적으로 사용될 뿐만 아니라 QUIC, CoAP, Skype, 온라인 회의 서비스 등과 같은 다양한 전송 또는 애플리케이션 계층 프로토콜에서도 사용된다.

TLS 운영은 크게 키 교환(key exchange)과 암호화된 데이터 전송으로 나뉘며, 상대적인 성능 오버헤드는 전달된 데이터의 크기에 따라 달라진다. 웹 브라우징과 같은 짧은 메시지의 경우, 일반적으로 키 교환을 위한 공개키 암호화에 병목 현상이 존재한다. 반대로 대칭키 암호화 및 무결성을 위한 콘텐츠 해싱(content hashing)은 온라인 비디오 전송과 같은 대용량 메시지의 주요 병목 현상이다.

다행히 최근 AES-NI가 도입되면서 후자의 성능이 크게 향상된 바 있다. 단일 CPU 코어도 현재 Galois/Counter Mode(AES-GCM)에서 AES에 대해 20Gbps 이상의 성능을 달성한다. 그러나 동일한 CPU 코어가 2048비트 RSA로 초당 1500개 이상의 작업을 처리하는 것만큼 공개키 암호화의 성능은 향상되지 않았으며, 이는 짧은 연결의 HTTPS 성능을 일반 텍스트 전송의 HTTPS 성능보다 최대 33배까지 저하시킨다.

본 발명의 목적은 보안 연결이 인터넷의 표준으로 부상한 상황에서 웹서버를 호스팅하는 모든 산업분야에 적용될 수 있는 신규한 보안연결 설정방법 및 NIC를 제공함에 있다. 특히, 본 발명의 목적은 보안 연결 설정에 의한 성능 감소를 막을 수 있고, 보안 연결 과정에서 발생할 수 있는 치명적인 오류나 취약점 공격이 호스트에 미치는 영향을 최소화하며, 시스템 아키텍처를 크게 바꾸지 않으면서도 안정성과 경제성을 도모할 수 있는 보안연결 설정기능 이양방법 및 이를 이용한 네트워크 어댑터를 제공함에 있다.

본 발명에 따른 NIC(Network Interface Card))는 클라이언트와의 데이터 송수신을 위한 포트부; 호스트와의 데이터 송수신을 위한 호스트 인터페이스부; 및 상기 호스트 장치와 클라이언트 간의 보안 연결 설정을 수행하기 위한 암호화 가속기;를 포함한다.

그리고, 상기 보안 연결 설정은 TCP 연결 설정 및 TLS 핸드셰이크를 포함할 수 있다.

또한, 상기 TLS 핸드셰이크는 서버 인증 및 키 교환을 포함하고, 상기 암호화 가속기는 비대칭 암호화 알고리즘을 수행하여 상기 키 교환을 수행할 수 있다.

그리고, 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함할 수 있다.

또한, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않을 수 있다.

한편, 본 발명에 따른 보안연결 설정기능 이양방법은, 호스트가 사전 보안연결을 위해 NIC에 전자증명서를 전달하고, 서버 인증 과정을 수행하는 단계; NIC(Network Interface Card)가 웹 서버로 보내진 데이터를 지속적으로 모니터링하여 보안 연결이 필요하다고 판단되는 연결을 탐색하는 단계; 및 상기 NIC에 내장된 암호화 가속기(crypto accelerator)가 비대칭 암호화 알고리즘을 수행하여 클라이언트와 키 교환을 수행하는 단계;를 포함한다.

그리고, 상기 NIC가, 보안 연결 설정 완료 후 상기 클라이언트와 교환한 공유 키와 보안 연결 정보를 상기 호스트에 전달하는 단계; 및 상기 호스트가, 연결 초기화 절차를 생략하고, 보안 연결을 이어가며 웹 서버 기능을 수행하는 단계;를 더 포함할 수 있다.

또한, 상기 호스트가, 보안 연결 종료 후 상기 NIC에게 종료 상태 정보를 전달하는 단계; 및 상기 NIC가, 동일한 클라이언트 IP 주소와 포트 번호에 대해 핸드셰이크 과정을 재개하는 단계;를 더 포함할 수 있다.

그리고, 상기 NIC는 상기 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함할 수 있다.

또한, 상기 서버 인증 이후, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않을 수 있다.

한편, 상기 목적을 달성하기 위한 본 발명에 따른 컴퓨터 판독 가능 기록매체는 상술한 방법 중 어느 하나의 보안연결 설정기능 이양방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한다.

본 발명은 보안 연결 설정으로 인한 부담을 덜기 위하여 보안 연결을 지원하는, 혹은 지원하고자 하는 웹서버 전반에 적용이 가능하다. 특히, CPU 자원을 보다 복잡한 작업에 집중시켜야 하는 데이터센터나 클라우드 컴퓨팅과 같은 규모가 큰 네트워크 시스템에 적용하면 성능 향상을 기대할 수 있다. 나아가 본 발명은 연산 능력이 상대적으로 부족한 소규모 서버에도 보안 연결로 인한 성능 저하를 막을 수 있다. 특히, 본 발명을 통해 기대할 수 있는 효과는 다음과 같다.

(1) 보안 연결 설정에 의한 성능 감소를 막아 웹 서버 능력을 향상시킨다.

(2) 보안 연결 설정을 네트워크 어댑터가 독립적으로 담당하면서 호스트가 완전히 설정 완료된 연결만을 다룬다. 보안 연결 과정에서 발생할 수 있는 치명적인 오류나 취약점 공격이 호스트에 미치는 영향을 막을 수 있다.

(3) 보안 연결 프록시나 전용 하드웨어 가속기와 달리 시스템 아키텍처를 크게 바꾸지 않는다. 이는 안정성과 경제성의 측면에서 이점을 가진다.

보안 연결이 인터넷의 표준으로 부상한 상황에서, 본 발명은 웹서버를 호스팅하는 모든 산업분야에 적용될 수 있다.

도 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) 사이에서의 통신 방법을 설명하기 위한 구성도이다.

이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시 예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시 예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시 예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

본 발명은 하드웨어 암호화 가속기를 사용하여 TLS 핸드셰이크(handshake)를 네트워크 인터페이스 카드(Network Interface Card; NIC)로 오프로드할 수 있는 가능성을 제시한다. CPU 기반 호스트 스택에서 나머지 작업을 수행하면서 NIC에서 TCP 연결 설정 및 TLS 핸드셰이크를 처리하는 TCP용 분할 TLS 처리 아키텍처(split TLS processing architecture)를 구현한다. 기존 SmartNIC에 대한 개념 증명 구현은 단일 CPU 코어보다 5배 향상된 처리량을 제공하므로 유망한 결과를 보여준다.

본 발명은 웹 서버가 클라이언트와 보안 연결을 맺을 시에 서버 인증 및 키 교환 과정을 포함한 연결 설정, 즉 핸드셰이크 과정을 호스트에서 네트워크 어댑터로 동적 이양하는 방법에 관한 것이다. 구체적인 방법은 다음과 같다.

첫번째로 프로그래머블 네트워크 어댑터(SmartNIC)에서는 웹 서버로 보내진 데이터를 지속적으로 모니터링하며, 보안 연결이 필요하다고 판단되는 연결을 찾아 보안 연결 설정을 진행한다. 보안연결을 위해 사전에 호스트는 네트워크 어댑터에게 전자증명서를 전달한 상태이며, 이 정보를 이용해 서버 인증 과정을 거친다. 이후 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘을 수행하기 위해 네트워크 어댑터는 내장된 암호화 가속기(crypto accelerator)를 사용한다. 이 과정에서 어댑터는 능동적으로 패킷을 읽고 클라이언트에게 응답하지만, 패킷 손실 탐지, 재전송, 혼잡 제어 등 복잡한 기저 프로토콜 기능은 수행하지 않는다.

다음 단계로, 연결 설정이 완료되었을 때 네트워크 어댑터는 클라이언트와 교환한 공유 키와 보안 연결 정보를 호스트에 전달한다. 해당 연결에 대해, 네트워크 어댑터는 모든 이후의 데이터를 처리하지 않고 호스트에게 그대로 전달한다. 주어진 정보를 받은 호스트는 연결 초기화 절차를 생략하고 곧바로 보안 연결을 이어가며 일반적인 웹 서버 기능을 수행한다. 이때 호스트 네트워크 스택은 기존과 유사한 API를 어플리케이션에 제공하기 때문에 현존하는 웹 서버 어플리케이션을 큰 수정 없이 곧바로 사용할 수 있다.

마지막으로, 보안 연결이 종료되면, 호스트는 네트워크 어댑터에게 이를 알려 같은 클라이언트 IP 주소와 포트 번호에 대해 다시 처음부터 핸드셰이크 과정을 진행할 수 있도록 한다. 즉, 호스트는 보안 연결 종료 상태 정보를 NIC에게 전송하고, NIC는, 동일한 클라이언트 IP 주소와 포트 번호에 대해서 핸드셰이크 과정을 재개할 수 있다.

위의 설명에 있어서, 비대칭 암호화 알고리즘에 대해서 간략히 설명하기로 한다. 아래의 설명은 비대칭 암호화 알고리즘의 실시예일뿐이고, 다양한 종류의 알고리즘을 이용할 수 있음은 당업자에 자명하다. 아울러, 본 발명의 권리범위는 비대칭 암호화와 관련한 특정 알고리즘에 한정되지 않는다.

공개키 암호 알고리즘으로도 불리는 비대칭 암호화는 암호화에 쓰이는 키값과 복호화에 쓰이는 키값을 서로 상이하게 하여 보안을 수행하는 것으로 대표적으로 아래와 같은 알고리즘이 존재한다.

(1) RSA(Rivest, Shamir and Adleman): 현재 사용되는 공개키 암호 알고리즘 중 가장 대표적인 것으로 암호화와 인증에 사용된다.

(2) ElGamal: 이산 대수 문제의 어려움에 기반을 둔 최초의 공개키 암호 알고리즘이다.

(3) ECC(Elliptic Curve Cryptosystem): 타원곡선(Elliptic Curve)의 수학적 원리를 이용한 차세대 공개키 암호 알고리즘이다.

(4) DSA(SEED): 전자상거래, 금융, 무선통신 등에서 전송되는 개인정보와 같은 중요한 정보의 보안을 이루기 위한 128-비트 블록암호 알고리즘이다.

비대칭키 암호화는 양방향 암호화로써 복호화가 가능한 암호 알고리즘으로 한 쌍의 키가 존재하며, 하나는 특정 사람만이 가지는 개인키(또는 비밀키)이고 다른 하나는 누구나 가질 수 있는 공개키에 해당한다. 공개키 암호화 방식은 암호학적으로 연관된 두 개의 키(개인키/공개키)를 이용하며, 개인키로 암호화 한 정보는 그 쌍이 되는 공개키로만 복호화가 가능하고, 공개키로 암호화한 정보는 그 쌍이 되는 개인키로만 복호화가 가능한 구조를 갖는다. 개인간 비밀통신은 대칭키 암호화로 가능하지만, 다수의 통신이 이루어지는 네트워크에서는 키의 개수가 급증하기 때문에 비대칭키 암호화 알고리즘이 필요하며, 이를 통해 보안성이 향상된 안전한 통신을 이룰 수 있게 된다.

본 발명의 가장 큰 특징은 호스트는 보안 연결이 완전히 설정되기 전까지 그 과정에 전혀 관여하지 않는다는 것이다. 이는 호스트 CPU의 부담을 줄일 뿐만 아니라 네트워크 어댑터에 내장된 암호화 가속기(crypto accelerator)를 사용하여 기존 시스템에 비해 성능을 향상시킨다.

호스트 CPU에서 나머지 작업을 수행하는 동안 TCP의 TLS 핸드셰이크를 SmartNIC로 오프로드하는 설계 영역을 탐색했다. 높은 처리량의 데이터 암호화 및 복호화를 위해 CPU에서 AES-NI를 활용하면서 확장 가능한 TLS 키 교환을 위해 NIC에 하드웨어 공개키 가속기를 배치하는 것이 이로운지를 살펴보았고, SmartTLS라고하는 분할 아키텍처는 아래와 같은 많은 이점을 제공한다.

첫째, TCP 연결 설정 및 CPU에서 TLS 키 교환의 부담을 크게 완화한다. 절약된 오버헤드에는 NIC와 호스트 메모리 사이의 작은 패킷에 대한 흐름별 상태 추적 및 DMA 작업이 포함되며, 이는 동시 연결이 많은 경우 큰 의미를 갖는다.

둘째, NIC에서 TLS 키 교환을 수행하려면 GPU 또는 ASIC 기반 암호화 가속기와 같은 전용 하드웨어를 사용하는 대체 설계와 달리 애플리케이션의 수정이 거의 또는 전혀 필요하지 않다. 전용 가속기는 일반적으로 높은 처리량을 위해 여러 암호화 작업의 비동기 또는 일괄 처리가 필요하므로 애플리케이션 아키텍처 업데이트가 불가피하다. 반대로 SmartTLS는 애플리케이션에 투명하므로 동기식 암호화 라이브러리 API를 계속 사용할 수 있다. 도 1은 SmartTLS에서 호스트 CPU와 SmartNIC로 나누어진 워크로드를 요약한 도면이다.

위에서 언급한 장점에도 불구하고, SmartTLS는 일련의 새로운 과제를 제시한다.

첫째, NIC는 TCP 연결 설정 및 TLS 키 교환 중에 교환된 패킷의 안정적인 전송을 보장해야 한다. 안정적인 데이터 전달을 구현하려면 패킷 손실 유추, 타이머 구현 및 패킷 재전송이 필요하기 때문에 복잡하고 오류가 발생하기 쉽다. 이는 일반적인 SmartNIC가 CPU만큼 많은 컴퓨팅 용량을 가지고 있지 않기 때문에 과도한 오버헤드를 야기한다. 이 문제를 해결하기 위한 본 발명은 NIC의 기능을 가능한 상태 비저장으로 구현한다. AccelTCP에서와 같이 SYN 쿠키를 사용하여 상태 비저장 TCP 연결 설정을 구현하고 클라이언트 측을 이용하여 패킷 재전송을 시작한다. 이는 NIC에서의 구현을 크게 단순화하고 평균적인 사례에서 우수한 성능을 보장한다.

둘째, TLS 핸드셰이크 후 NIC는 수신 패킷을 호스트 CPU 측으로 효율적으로 전달해야 한다. 그러나 TLS 핸드셰이크가 수행되었는지 확인하기 위해 NIC에서 패킷의 4개의 튜플을 확인하는 것조차도 비용이 많이 들고 성능이 저하될 수 있다. 오버헤드를 방지하기 위해 회선 속도 패킷 전달 성능을 보장하는 NIC의 하드웨어 패킷 분류를 활용한다. NIC의 하드웨어 스위치에서 개별 규칙을 설정하기 위한 지연 시간이 현재로서는 다소 높아 보이지만 향후에는 해결될 것으로 보인다.

셋째, NIC 자체가 너무 많은 TLS 핸드셰이크로 인해 오버로드되어 전체 시스템의 성능이 저하될 수 있다. 이 문제를 해결하기 위해 우리는 NIC가 오버로드된 경우 새 연결에 대해 TLS 오프 로딩을 비활성화하는 기회적 오프 로딩을 시행한다. Mellanox Bluefield SmartNIC로 SmartTLS 프로토 타입을 구현한다. 예비 평가 결과 TLS 핸드셰이크 오프로딩의 분명한 이점을 보여주었다. SmartTLS는 8코어 CPU 서버에서 2048비트-RSA로 초당 13K TLS 연결을 달성한다. 이는 CPU 전용 접근 방식에 비해 1.7배 향상되었다. NIC가 최첨단 암호화 가속기를 사용하면 훨씬 더 높은 성능을 기대할 수 있다. SmartTLS는 비용 효율적인 방식으로 최신 TLS 트래픽을 처리하는 실용적인 설계 방식을 제공한다.

TLS 핸드셰이크의 오프로딩(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 레코드 생성시 오버헤드가 크게 줄어든다.

[표 1]은 OpenSSL 1.1.1f 1로 측정한 최근 CPU(2.6GHz에서 Intel Xeon E5-2640 v3)에서 AES의 성능을 보여준다.

AES mode	1 core	2 cores	4 cores	8 cores
CBC (w/o NI)	2.02	4.05	7.37	13.62
CBC (w/NI)	4.36	8.50	15.55	28.90
GCM (w/o NI)	1.28	2.52	4.61	8.50
GCM (w/ NI)	20.74	40.90	75.10	138.98

256비트 키를 사용하고, AES-NI를 사용하거나 사용하지 않은 CBC 및 GCM 모드의 성능을 비교한다. [표 1]을 참조하면, (1) AES-NI가 두 모드의 성능을 크게 향상(CBC 및 GCM의 경우 각각 최대 2.2배 및 16.2배까지)시켰고 (2) AES-NI가 활성화 된 경우 GCM 모드가 CBC 모드보다 10.2배 성능이 뛰어나다는 사실을 알 수 있다.

일반적으로 GCM은 명령 파이프 라인을 효과적으로 활용하면서 병렬로 작동할 수 있으므로 더욱 효율적으로 구현할 수 있다. 반대로 CBC 모드의 암호화는 각 블록 암호화가 완전히 직렬화되므로 파이프 라인 중단이 발생한다. 단일 CPU 코어조차도 AES-GCM으로 20Gbps 이상을 달성하고 옥타 코어 CPU는 데이터 암호화를 위해 100Gbps에 도달하기에 충분하다.

[표 2]는 하드웨어 공개키 가속기(Public Key Accelerator; PKA)가 장착된 Mellanox Bluefield SmartNIC 뿐 아니라 동일한 CPU에서 RSA 개인 키 작업의 성능을 보여준다.

Key size	1 core	2 cores	4 cores	8 cores	PKA
1024-bit	7900	15273	28411	52581	30986
2048-bit	1591	3115	5722	10554	5239
4096-bit	152	296	537	993	743

측정 결과에 따르면 하나의 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 코어를 절약할 수 있음을 보여준다.

요약하면, 최신 CPU는 TLS 핸드셰이크를 수행하는 것보다 TLS 데이터 패킷을 암호화하는 데 상대적으로 더 높은 용량을 가지고 있다. TLS 핸드셰이크를 SmartNIC로 오프로드할 수 있다면 더 높은 TLS 성능을 위해 AES 및 SHA 작업에 더 많은 CPU 주기를 사용할 수 있다. 다행히 일부 SmartNIC에는 이미 하드웨어 PKA 모듈이 있으므로 TLS 핸드셰이크 오프로딩에 이를 활용할 수 있다.

그러나 이것이 기존 SmartNIC가 TLS 핸드셰이크를 위한 충분한 용량을 가지고 있음을 의미하지는 않는다. 대신 Smart-NIC가 TLS 트래픽의 인라인 가속화를 위한 하드웨어 PKA의 적합한 장소라고 말할 수 있다. 최근 하드웨어 가속기가 2048비트 RSA에 대해 초당 120K 작업을 달성한다는 점을 감안할 때 SmartNIC에서 공개키 암호화의 성능을 더욱 향상시킬 수 있다.

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

NIC에서 TLS 핸드셰이크를 수행하려면 TCP 연결 설정 및 TLS 키 교환 중에 복잡한 상태 추적이 필요하므로 리소스가 제한된 SmartNIC에 심각한 오버헤드가 발생한다. 안정적인 패킷 전달을 보장하려면 패킷 손실 유추, 중복 ACK 감지, 타이머 구현 등이 필요하며, 이는 상당한 컴퓨팅 사이클을 소비하게 된다. 이 오버헤드는 SmartNIC에서 하드웨어 가속 공개키 암호화의 이점을 무효화하기에 충분히 클 수 있다.

최소 퍼-플로우 스테이트(minimal per-flow state)를 유지하는 것은 TLS 핸드셰이크 중 복잡성을 해결하는 핵심이다. 이 목표를 달성하기 위해 Smart-TLS는 TLS 핸드셰이크 프로세스를 두 단계로 나눈다.

첫째, 최근 작업에서 볼 수 있듯이 SYN 쿠키를 사용하여 상태 비저장 TCP 연결 설정을 보장한다. 이것은 본질적으로 타이머 기반 패킷 재전송과 반 개방 연결(half-opened connection)에 대한 상태 유지의 필요성을 제거한다.

둘째, SmartTLS는 키 교환 단계에서 패킷 손실 및 재전송을 추론하기 위해 TLS 클라이언트를 이용한다.

도 2에 도시된 바와 같이, 서버가 해야 할 일은 TLS 핸드셰이크 동안 클라이언트 측 패킷에 수동적으로 응답하는 것이다. 도 2는 2048 비트 RSA와의 키 교환을 위한 SmartTLS에서의 TLS(v1.2) 연결의 데이터 흐름을 나타낸다. 괄호의 값들은 각 레코드에 필요한 바이트 수를 나타낸다. SmartTLS는 핸드셰이크 도중 각 화살표에 있는 모든 TLS 레코드를 단일 패킷으로 병합한다.

SmartTLS는 마지막으로 전송된 시퀀스 번호와 마지막으로 수신된 ACK를 추적해야 하지만 클라이언트가 서버에서 패킷을 수신하지 않으면 이전 패킷을 재전송하므로 서버는 자체 패킷의 손실을 유추할 필요가 없다. 필요한 경우, 서버는 클라이언트 측 패킷에 대한 응답으로 패킷을 재전송한다.

이러한 설계는 패킷 손실이 드물게 발생하는 실제 세계에서 일반적으로 최적화된다. 이를 통해 마지막 시퀀스/ACK 번호와의 연결의 네 가지 튜플, 무결성 계산 및 재전송을 위한 캐시된 TLS 패킷, 그리고 보안 매개변수(의사 난수 및 프리 마스터(pre-master)/마스터 시크릿(master secret))를 최소 상태로 유지할 수 있는 흐름별 타이머와 패킷 손실 추적을 없앨 수 있다. 키 교환 중에 클라이언트를 사용할 수 없게 되는 예외적인 경우를 방지하기 위해, 이 단계에서 몇 초 동안 멈춘 부실 연결을 주기적으로 제거하는 NIC에 코스 그레인드 글로벌 타이머(coarse-grained global timer)를 구현한다.

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

SmartNIC에 내장된 가속기를 활용하려면 패킷을 NIC의 내장형 시스템으로 전달해야 한다. Mellanox Bluefield와 같은 SmartNIC의 임베디드 시스템은 16GB 메모리가있는 16코어 ARMv8 프로세서를 사용하지만, Intel DPDK와 같은 확장 가능한 패킷 I/O 라이브러리를 사용하더라도 일반 CPU 기반 시스템에 비해 패킷 처리 성능이 상당히 제한된다. 임베디드 시스템을 통해 모든 패킷을 전달하면 지연 시간이 증가 할뿐만 아니라 전체 처리량이 저하된다.

다른 모든 패킷은 SmartNIC 시스템을 우회하면서 TLS 핸드셰이크에 필요한 패킷만 임베디드 시스템으로 전달하는 것이 이상적이다. 이 목표를 위해 SmartNIC에서 하드웨어 패킷 스위치를 활용하는 아이디어를 탐구한다. Bluefield NIC는 NIC 내장 시스템이 트래픽 제어(TC) 규칙을 추가하여 패킷을 호스트 시스템으로 직접 전달할 수 있도록 하는 ASAP2 OvS 오프로드를 지원한다. 두 가지 경우에 TC 규칙을 사용한다. 먼저, 초기화시 관련 TLS 패킷(예: 일치하는 대상 포트 번호 포함)만 임베디드 시스템에 전달하는 규칙을 설치한다. 그런 다음 다른 모든 패킷은 호스트로 직접 전달된다. 둘째, 흐름에 대한 TLS 핸드셰이크가 완료될 때마다 SmartTLS는 흐름의 모든 향후 패킷이 임베디드 시스템을 우회하도록 4개의 튜플이 포함된 새 TC 규칙을 삽입한다. 연결이 종료되면 하드웨어 스위치에서 TC 규칙을 제거할 수 있다. 설치된 TC 규칙은 호스트 시스템으로의 회선 속도 패킷 전달을 약속한다.

현재 시스템(즉, Bluefield NIC)은 많은 설치된 규칙으로 빠른 규칙 설정/제거 또는 높은 처리량을 달성하지 못한다. Bluefiled NIC에서 TC 규칙을 설치하거나 제거하는 데 1밀리 초 이상이 걸린다. 또한 최대 40K TC 규칙을 지원하지만 설치된 규칙의 수가 증가함에 따라 패킷 전달 속도는 점차 감소하여, 40K TC 규칙에서는 회선 속도의 절반으로 떨어진다. 장기적으로는 하드웨어 스위치 성능이 향상되기를 바라지만 그 동안 장기 실행 TLS 연결에 대해서만 TC 규칙을 설치할 수 있다.

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

TLS 핸드셰이크를 오프로딩하면 호스트 CPU의 계산 부담이 줄어들지만, 너무 많은 동시 TLS 핸드셰이크가 호스트 CPU가 유휴상태인 동안 NIC에 과부하가 걸릴 수 있다. 호스트 CPU와 SmartNIC간에 TLS로드 밸런싱을 유지하는 것이 바람직하지만 대부분의 연결이 수명이 짧은 경우 달성하기 어렵다.

두 컴퓨팅 리소스를 균형 있게 사용하기 위해 TLS 핸드셰이크의 기회적 오프 로딩을 고려한다. 아이디어는 매우 간단하다. NIC에 대한 로드가 "높음" 임계값을 초과하면 NIC는 호스트 CPU에 TLS 핸드셰이크를 계속하도록 요청하는 동안 TCP 연결 설정만 수행한다. 이를 위해 SmartNIC는 암호화 가속기에 대한 로드를 반영하는 간단한 카운터를 유지한다(예: 암호화 작업이 발송될 때 증가하고 출력이 생성될 때 감소함). TCP 연결 설정은 상태 비저장 특성이 높은 부하에서도 높은 처리량을 보장하므로 NIC에서 계속 수행된다. 부하가 "낮은" 임계값 아래로 내려 가면 SmartTLS는 TLS 핸드셰이크 오프로딩을 다시 활성화한다. 즉, 카운터는 암호화 가속기에 대한 로드를 측정하고, 해당 측정값은 임계값과 비교된다.

본 발명은 오프로딩 단위가 개별 작업이 아니라 전체 TLS 핸드셰이크라는 점에서 종래 기술과 차별점이 있다. 이 설계적 선택은 호스트와 NIC TLS 스택 간의 상태 공유를 최소화하여 구현을 단순화한다. 완전히 투명한 기능이므로 응용 프로그램을 수정할 필요가 없다.

구현(IMPLEMENTATION)

도 3은 상술한 설계 선택 사항을 반영하는 SmartTLS NIC 스택의 전체 아키텍처를 보여준다. 새 패킷이 도착하면 NIC의 하드웨어 패킷 분류기(hardware packet classifier)는 패킷이 설치된 TC 규칙을 사용하여 호스트로 직접 전달되어야 하는지 여부를 결정한다.

규칙과 일치하지 않는 경우, 패킷은 NIC의 내장형 시스템으로 전달된다. 그런 다음 시스템은 흐름표(flow table)에서 패킷의 연결 상태를 조회한다. 흐름을 찾을 수 없는 SYN 패킷인 경우 시스템은 SYN 쿠키를 사용하여 TCP 연결 설정으로 들어간다. 일치하는 흐름 항목이 발견되면 시스템은 항목의 "onload" 플래그를 확인하여 흐름의 패킷을 호스트로 전달해야 하는지 여부를 표시한다. 플래그가 꺼져 있으면(예: 도면에서 F2), 시스템은 패킷과 TLS 핸드셰이크를 수행한다. 흐름은 일반적으로 TLS 핸드셰이크가 끝나면 온로드되지만 NIC가 과부하 상태인 경우 TCP 연결 설정 직후에 플래그를 설정할 수 있다(예: 도면의 F4).

NIC는 흐름을 호스트로 온로드할 때 TLS 메타 데이터를 전달한다. TLS 메타 데이터에는 흐름의 튜플 4개와 세션에 대한 TLS 매개 변수(예 : TLS 버전 및 세션 키)가 포함된다. 그런 다음 호스트는 메타 데이터에 따라 TLS 세션으로 TCP/TLS 흐름 상태를 생성하고 동일한 흐름에 속하는 모든 후속 패킷을 처리한다. NIC가 부하를 호스트 측으로 오프로드하기로 결정한 경우 호스트는 자체적으로 TLS 핸드셰이크를 처리할 수 있어야 한다. 호스트 TLS 스택은 일관된 API를 애플리케이션 계층에 노출하여 내부적으로 이 두 개의 개별 경로를 관리한다. 애플리케이션은 TLS 핸드셰이크가 수행되는 위치를 신경 쓸 필요가 없다.

본 발명은 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를 구현할 수 있다.

평가(EVALUATION)

TLS 핸드셰이크를 Smart로 오프로드할 때의 효과를 평가한다. SmartTLS 위에 간단한 HTTPS 웹 서버를 구현하고 Linux TCP 스택(커널 버전 3.10) 및 OpenSSL 1.0.2를 사용하는 mTCP 사용자 수준 스택에서 TLS 성능을 nginx와 비교한다. SmartTLS는 OpenSSL과 유사한 동기 암호화 API를 제공하므로 기존 애플리케이션을 SmartTLS를 사용하도록 마이그레이션하는 것은 비교적 간단해야 한다.

(실험 설정) 4개의 클라이언트로 하나의 서버의 성능을 측정한다. 모든 컴퓨터에는 32GB DRAM이 포함된 Intel Xeon CPU E5-2640 v3@2.60GHz(8 코어)가 있다. 서버는 ARMv8 A72(16 코어) 및 16GB DRAM이있는 듀얼 포트 25G Mellanox BlueField NIC로 구성되어 있지만 평가에는 포트 중 하나만 사용된다. 모든 클라이언트는 Intel XL710 40GbE NIC로 구성된다. Linux 및 mTCP 스택에서의 실험을 위해 모든 패킷을 호스트 측으로 직접 전달하도록 서버의 SmartNIC를 구성한다. SmartTLS 실험의 경우 호스트 CPU에서 TLS 핸드셰이크를 기회적으로 오프로드한다.

(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의 로드가 균형을 이루는지 확인할 수 있다.

도 5는 단일 CPU 코어를 사용하여 HTTPS에서 1바이트 파일을 다운로드하는 99%의 꼬리 응답 시간(tail latency)을 비교하는 그래프이다. 동시 연결 수가 적을 때 CPU 전용 접근 방식은 SmartNIC의 임베디드 시스템에서 패킷 처리 지연으로 인해 더 나은 대기 시간을 보여준다. 그러나 동시성이 2개의 흐름을 초과하면 Linux 스택의 꼬리 지연 시간이 16개의 흐름에서 SmartTLS의 지연 시간보다 두 배 이상 빠르게 증가한다. 이는 호스트 CPU가 TLS 핸드셰이크의 병목 현상이 쉽게 발생하여 적은 수의 동시 흐름에도 처리 대기 시간을 증가시킬 수 있음을 나타낸다.

(혼합된 워크로드 성능) 단기 연결이 TLS에서 대용량 파일 전송 성능을 방해할 수 있는지 조사한다. NIC 대역폭을 채우는 HTTPS에서 대용량 파일(4GB)을 전송하는 몇 가지 흐름을 설정했다. 그런 다음 1바이트 파일을 반복적으로 다운로드하는 몇 가지 단기 연결을 추가하기 시작한다. 키 교환에는 2048 비트 RSA를 사용하고 데이터 암호화 및 무결성에는 SHA384와 함께 AES-GCM 256 비트 키를 사용한다. 이 실험에서는 주어진 TLS 암호 그룹으로 25Gbps의 NIC 대역폭을 포화시키기에 충분한 4개의 CPU 코어를 사용한다.

도 6은 단기 흐름의 수가 증가함에 따라 대용량 파일 트래픽의 처리량이 감소함을 보여주는 그래프이다. 16개의 동시 흐름만으로 처리량 손실이 40%까지 관찰된다. 이는 AES-GCM 및 RSA 작업에 대한 호스트 CPU의 과도한 경합 때문이다. 대조적으로, SmartTLS를 사용할 때 단기 흐름의 TLS 핸드셰이크가 NIC의 암호화 가속기로 효과적으로 오프로드되므로 대용량 파일 트래픽에서 성능 저하가 거의 또는 전혀 발생하지 않는다.

관련 작업(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 성능이 이러한 가속기의 성능과 비슷하거나 더 우수하므로 성능 이점은 대부분 공개키 작업으로 제한된다.

(데이터 암호화 및 무결성 계산 오프로드) 일부 NIC는 호스트 CPU와 TLS 핸드셰이크를 수행하는 동안 CPU에서 하드웨어 가속기로의 AES 및 SHA 작업 오프로드를 지원한다. 이 접근 방식은 SmartTLS의 접근 방식과 정반대이지만 워크로드가 주로 큰 메시지를 처리할 때 유용할 수 있다. 그러나 AES-NI가 최신 CPU에 도입됨에 따라 데이터 암호화 오프로딩의 효율성이 상대적으로 감소했다고 생각한다. AES-GCM은 인증 된 데이터 무결성을 포함하고, 이에 대한 CPU 오버 헤드가 요즘 상당히 낮기 때문에 특히 워크로드가 크고 작은 전송이 혼합 된 경우 TLS 키 교환을 오프 로딩하는 것이 더 비용 효율적이다.

TLS 핸드셰이크의 NIC 오프 로딩은 최신 TLS 트래픽을 처리할 때 잠재적으로 많은 양의 CPU주기를 줄일 수 있는 실행 가능한 옵션임을 보여주었다. SmartNIC로 프로토 타입 시스템을 구축하고 HTTPS 트래픽으로 성능 이점을 확인했다.

현재 인터넷 트래픽의 70퍼센트 이상이 암호화되어있으며, 규모가 큰 주요 웹 사이트 대부분이 보안 연결을 기본으로 설정되어있다. 따라서, 본 발명의 적용 가능 범위는 대부분의 웹사이트 호스팅에 해당하며 전자메일, 소셜네트워크서비스, 전자상거래 등의 어플리케이션도 포함한다. 특히 다수의 짧은 보안 연결이 맺어지며 이로 인해 암호화 알고리즘 처리에 병목이 형성될 우려가 있을 때, 본 발명을 적용함으로써 문제를 해결할 수 있다. 또한 발명을 적용한 후에도 기존의 어플리케이션을 큰 수정없이 유지할 수 있으므로 더 쉽게 사용될 수 있다. 이러한 점에서 본 발명의 시장성은 매우 높다고 할 수 있다.

본 발명은 기존에 존재하는 프로그래머블 네트워크 어댑터를 사용하며 본 발명만을 위한 맞춤형 하드웨어 장비를 사용하지 않는 소프트웨어로써의 시스템 솔루션으로 제공될 수 있다. 때문에 기술사업화에 있어 인프라 구축에 큰 비용을 필요로 하지 않을 것으로 기대된다. 또한, 널리 사용되는 리눅스 기반 서버 전반에 적용 가능하므로 범용성 또한 높기에 기술사업화 전망이 충분히 있다.

도 7은 본 발명에 따른 보안연결 설정기능 이양방법을 수행하기 위한 네트워크 어댑터(200)의 호스트(300) 및 클라이언트(100) 사이에서의 통신 방법을 설명하기 위한 구성도이다.

네트워크 어댑터(200)는 호스트(300) 및 클라이언트(100) 사이에서의 데이터 송수신을 중개한다. 네트워크 어댑터(200)는 포트부(210), 프로세서(220), 호스트 인터페이스부(230), 메모리부(240) 및 암호화 가속기(250)를 포함한다.

포트부(210)는 클라이언트(100)를 포함한 외부 디바이스와 네트워크 커넥터(200) 사이의 데이터 송수신을 중개한다. 포트부(210)는 네트워크 케이블을 통해 외부 네트워크와 연결 가능하며, 유/무선 통신을 수행할 수 있다.

프로세서(220)는 네트워크 커넥터(200)의 각 구성요소들 사이에서의 데이터 처리를 전반적으로 제어할 수 있다. 프로세서(220)는 네트워크 커넥터(200)의 클라이언트(100) 및/또는 호스트(300)와의 데이터 송수신과 관련된 패킷들을 생성, 전송, 수신할 수 있다. 프로세서(220)는 호스트 인터페이스부(230)로부터 TCP 연결 종료 패킷을 전송받아 처리할 수 있다. 프로세서(220)는 포트부(210)로부터 TCP 연결 요청 패킷을 전송받아 처리할 수 있다.

프로세서(220)는 포트부(210) 및/또는 호스트 인터페이스부(230)와의 데이터 송수신, 데이터 처리 등에 대한 정보를 메모리부(240)로 저장할 수 있고, 메모리부(240)에 기 저장된 정보를 독출할 수도 있다.

호스트 인터페이스부(230)는 호스트(300)와의 통신을 위한 인터페이스로 PCI(peripheral component interconnect)등을 포함하여 유/무선 통신을 수행할 수 있다.

메모리부(240)는 프로세서(220)의 데이터 처리 결과를 저장할 수 있다. 메모리부(240)는 포트부(210)를 통해 프로세서(220)에 도착한 패킷 정보들을 저장하거나, 패킷 처리 및/또는 TCP 연산 처리 과정에서 필요한 메타데이터들을 저장할 수 있으며, SRAM 및/또는 DRAM을 포함할 수 있다.

암호화 가속기(250)는 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘을 수행한다. 즉, 키 교환 과정에서 쓰이는 비대칭 암호화 알고리즘은 암호화 가속기(250)에 의해서 수행된다. 이 과정에서 네트워크 어댑터(200)는 능동적으로 패킷을 읽고 클라이언트에게 응답하지만, 패킷 손실 탐지, 재전송, 혼잡 제어 등 복잡한 기저 프로토콜 기능은 수행하지 않는다. 암호화 가속기(250)의 구체적인 기능 및 동작방식과 관련해서는 위에서 상세히 설명한 바, 중복 설명은 생략하기로 한다.

위에서 설명한 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 기록 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상에서 실시예들에 설명된 특징, 구조, 효과 등은 본 발명의 하나 의 실시예에 포함되며, 반드시 하나의 실시예에만 한정되는 것은 아니다. 나아가, 각 실시예에서 예시된 특징, 구조, 효과 등은 실시예들이 속하는 분야의 통상의 지식을 가지는 자에 의해 다른 실시예들에 대해서도 조합 또는 변형되어 실시 가능하다. 따라서 이러한 조합과 변형에 관계된 내용들은 본 발명의 범위에 포함되는 것으로 해석되어야 할 것이다.

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

Claims (11)

1. NIC에 있어서,
   클라이언트와의 데이터 송수신을 위한 포트부;
   호스트와의 데이터 송수신을 위한 호스트 인터페이스부; 및
   상기 호스트 장치와 클라이언트 간의 보안 연결 설정을 수행하기 위한 암호화 가속기;를 포함하고,
   상기 NIC가 보안 연결 설정 완료 후 상기 클라이언트와 교환한 공유 키와 보안 연결 정보를 상기 호스트에 전달하고, 상기 호스트는 연결 초기화 절차를 생략하고 보안 연결을 이어가며 웹 서버 기능을 수행하는 NIC(Network Interface Card).
2. 제1항에 있어서,
   상기 보안 연결 설정은 TCP 연결 설정 및 TLS 핸드셰이크를 포함하는 NIC(Network Interface Card).
3. 제2항에 있어서,
   상기 TLS 핸드셰이크는 서버 인증 및 키 교환을 포함하고
   상기 암호화 가속기는 비대칭 암호화 알고리즘을 수행하여 상기 키 교환을 수행하는 NIC(Network Interface Card).
4. 제1항에 있어서,
   암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며, 상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함하는 NIC(Network Interface Card).
5. 제1항에 있어서,
   상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않는 NIC(Network Interface Card).
6. 호스트가 사전 보안연결을 위해 NIC(Network Interface Card))에 전자증명서를 전달하고, 서버 인증 과정을 수행하는 단계;
   상기 NIC가 웹 서버로 보내진 데이터를 지속적으로 모니터링하여 보안 연결이 필요하다고 판단되는 연결을 탐색하는 단계;
   상기 NIC에 내장된 암호화 가속기(crypto accelerator)가 비대칭 암호화 알고리즘을 수행하여 클라이언트와 키 교환을 수행하는 단계;
   상기 NIC가, 보안 연결 설정 완료 후 상기 클라이언트와 교환한 공유 키와 보안 연결 정보를 상기 호스트에 전달하는 단계; 및
   상기 호스트가, 연결 초기화 절차를 생략하고, 보안 연결을 이어가며 웹 서버 기능을 수행하는 단계;를 포함하는 보안연결 설정기능 이양방법.
7. 삭제
8. 제6항에 있어서,
   상기 호스트가, 보안 연결 종료 후 상기 NIC에게 종료 상태 정보를 전달하는 단계; 및
   상기 NIC가, 동일한 클라이언트 IP 주소와 포트 번호에 대해 핸드셰이크 과정을 재개하는 단계;를 더 포함하는 보안연결 설정기능 이양방법.
9. 제6항에 있어서,
   상기 NIC는 상기 암호화 가속기가 비대칭 암호화 알고리즘 수행하는 경우 기저 프로토콜 기능을 수행하지 않으며,
   상기 기저 프로토콜 기능은 패킷 손실 탐지, 재전송 및 혼잡 제어 중 어느 하나를 포함하는 보안연결 설정기능 이양방법.
10. 제6항에 있어서,
    상기 서버 인증 이후, 상기 호스트는 상기 보안 연결이 완료될 때까지 상기 보안 연결 설정 과정에 관여하지 않는 보안연결 설정기능 이양방법.
11. 제6항, 제8항 내지 제10항 중 어느 한 항에 기재된 보안연결 설정기능 이양방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터 판독 가능 기록매체.

Images