KR101989147B1 - 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법 - Google Patents

비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법 Download PDF

Info

Publication number
KR101989147B1
KR101989147B1 KR1020170074121A KR20170074121A KR101989147B1 KR 101989147 B1 KR101989147 B1 KR 101989147B1 KR 1020170074121 A KR1020170074121 A KR 1020170074121A KR 20170074121 A KR20170074121 A KR 20170074121A KR 101989147 B1 KR101989147 B1 KR 101989147B1
Authority
KR
South Korea
Prior art keywords
host
mptcp
handshake
token
elliptic curve
Prior art date
Application number
KR1020170074121A
Other languages
English (en)
Other versions
KR20180136021A (ko
Inventor
최형기
김동용
이효석
김이진
김호준
김동성
양지연
장도균
Original Assignee
성균관대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 성균관대학교산학협력단 filed Critical 성균관대학교산학협력단
Priority to KR1020170074121A priority Critical patent/KR101989147B1/ko
Publication of KR20180136021A publication Critical patent/KR20180136021A/ko
Application granted granted Critical
Publication of KR101989147B1 publication Critical patent/KR101989147B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

비대칭 키 교환을 이용한 MPTCP의 핸드 셰이크 방법이 개시된다.
MPTCP의 핸드 셰이크 방법은 호스트 A가, 호스트 B와 연결을 생성하면서, 타원 곡선 디피-헬만 키 교환 방법을 이용하여 비대칭 키를 교환하는 단계; 및 상기 호스트 A가, 상기 호스트 B와 보조 경로를 추가하면서, 상기 비대칭 키를 이용하여 서로를 인증하는 단계를 포함할 수 있다.

Description

비대칭 키 교환을 이용한 MPTCP의 핸드 셰이크 방법 {Method for handshake of MPTCP using asymmetric key exchange}
본 발명은 비대칭 키 교환을 이용한 MPTCP의 핸드 셰이크 방법에 관한 것이다. 보다 자세하게는 MPTCP의 연결을 생성할 때, 비대칭 키 교환을 통해 보안을 강화하는 핸드 셰이크 방법에 관한 것이다.
LTE의 상용화 이후 LTE-Advanced에 이르기까지 셀룰러 통신 망은 나날이 발전을 거듭하고 있으며, 그 규모 또한 확장되고 있는 추세이다. 이러한 셀룰러 통신망뿐만 아니라 와이파이(Wi-Fi) 망도 여러 종류의 휴대 기기의 보급으로 인해 그 범위가 확대되고 있다.
Multipath TCP(MPTCP)는 이러한 여러 이종망 사이의 핸드 오버 솔루션 중의 하나로 손꼽힌다. 기존의 TCP 를 사용하는 경우, 셀룰러 망에서 와이파이(Wi-Fi) 망으로 단말이 이동하게 되면, 셀룰러 망의 커버리지를 벗어난 후, 와이파이(Wi-Fi) 망에서 아이피(IP) 주소를 할당 받고, TCP 연결을 재설정하게 된다.
이 때 사용자는 추가적으로 발생되는 지연으로 인해 이용 중인 서비스가 순간적으로 끊기는 것을 경험하게 된다. 하지만 동일한 조건에서 MPTCP를 사용하는 경우, 단말은 셀룰러 망과 와이파이(Wi-Fi) 망이 중첩되는 지역에서 이미 와이파이(Wi-Fi) 망의 아이피 주소를 할당 받게 된다.
이후 셀룰러 망의 커버리지를 벗어나더라도, 사용자는 추가적인 지연 없이 끊김 없는 서비스를 받을 수 있게 된다. 이처럼 MPTCP는 기존의 TCP를 확장하는 개념으로 서버나 단말이 가지고 있는 여러 개의 네트워크 인터페이스를 동시에 사용할 수 있게 해준다. 연결을 할 때, 호스트들은 MPTCP 사용 여부에 대해 알려주어, 하나의 연결에 대해 여러 개의 아이피 주소를 사용하는 여러 개의 서브 플로우(subflow)를 생성하게 된다.
이러한 서브 플로우를 생성할 때, MPTCP는 핸드셰이크(Handshake) 중에 키를 교환하여 보안을 제공하고 있다. 이러한 키들은 다른 호스트들을 인증하기 위한 해시 기반 메시지 인증 코드(HMAC, Hash-based Message Authentication)을 생성하는데 사용된다. 하지만 MPTCP는 최초 핸드셰이크 중에 키를 평문으로 교환하고 있어, 이는 보안 관점에서 매우 취약하다.
최초 핸드셰이크의 도청자는 평문으로 교환되는 키를 중간에 도청할 수 있고, 키를 탈취한 뒤에는 도청자는 경로 상에 존재하지 않아도 MPTCP 세션을 탈취할 수 있다. 예를 들면, 보조 경로에서의 능동적인 공격자는 "보조 경로 추가" 요청을 가로채서, "보조 경로 추가" 요청에서 획득한 값을 이용하여 자신의 경로를 추가할 수 있다.
이와 같은 위협들의 근원적인 문제점은 공격자가 인증 값들을 공유된 키의 노출 여부에 상관없이 이용할 수 있다는 점이다. 즉, 경로가 생성된 뒤에도 공격자가 공격을 수행할 수 있다. 이는 종래의 MPTCP가 평문으로 대칭 키를 교환하고 있기 때문이며, 이러한 핸드셰이크 방법은 보안에 매우 취약한 문제점이 있다.
이에 MPTCP 연결을 생성하는 핸드셰이크 과정에서 보안을 강화할 수 있는 비대칭 키 교환 방법에 대한 필요성이 점점 커지고 있다.
10-2015-0113625 A "멀티 패스 트랜스포트 제어 프로토콜을 지원하는 통신 네트워크에서 서비스 제공 장치 및 방법" (2015.10.08)
Ceritcom research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography 2 (SEC 2), January 2010.
본 발명이 해결하고자 하는 기술적 과제는 비대칭 키 교환을 이용한 MPTCP의 핸드 셰이크 방법을 제공하는 것이다.
본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 MPTCP의 핸드 셰이크 방법은 호스트 A가, 호스트 B와 연결을 생성하면서, 타원 곡선 디피-헬만 키 교환 방법을 이용하여 비대칭 키를 교환하는 단계; 및 상기 호스트 A가, 상기 호스트 B와 보조 경로를 추가하면서, 상기 비대칭 키를 이용하여 서로를 인증하는 단계를 포함할 수 있다.
바람직하게는, 상기 타원 곡선 디피-헬만 키 교환 방법을 이용하여 비대칭 키를 교환하는 단계는, 4방향 핸드셰이크를 이용하여 상기 비대칭 키를 교환하는 단계를 포함할 수 있다.
바람직하게는, 상기 4방향 핸드셰이크를 이용하여 상기 비대칭 키를 교환하는 단계는, 상기 호스트 A가, 상기 호스트 B로 SYN와 함께 MP_CAPABLE 옵션 포함된 상기 호스트 A의 타원 곡선의 X 좌표를 송신하는 단계; 상기 호스트 A가, 상기 호스트 B로부터 ACK와 함께 상기 호스트 B의 타원 곡선의 X 좌표를 수신하는 단계; 상기 호스트 A가, 상기 호스트 B로부터 SYN와 함께 MP_CAPABLE 옵션에 포함된 상기 호스트 B의 타원 곡선의 Y 좌표를 수신하는 단계; 및 상기 호스트 A가, 상기 호스트 B로 ACK와 함께 상기 호스트 A의 타원 곡선의 Y 좌표를 송신하는 단계를 포함할 수 있다.
바람직하게는, 상기 MP_CAPABLE 옵션 포함된 상기 호스트 A의 타원 곡선의 X 좌표는, 상기 MP_CAPABLE 옵션의 C 내지 G 플래그 중에 어느 하나를 사용하는 것이다.
바람직하게는, 상기 MP_CAPABLE 옵션 포함된 상기 호스트 B의 타원 곡선의 Y 좌표는, 상기 MP_CAPABLE 옵션의 C 내지 G 플래그 중에 어느 하나를 사용하는 것이다.
바람직하게는, 상기 비대칭 키를 이용하여 서로를 인증하는 단계는, 상기 보조 경로의 식별자인 Address ID를 더 이용하여 서로를 인증하는 단계를 포함할 수 있다.
바람직하게는, 상기 보조 경로의 식별자인 Address ID를 더 이용하여 서로를 인증하는 단계는, 상기 호스트 A가, 상기 호스트 B로 SYN와 함께 TokenB, HMACToken, RA를 송신하는 단계; 상기 호스트 A가, 상기 호스트 B로부터 SYN/ACK와 함께 AuthB, RB를 수신하는 단계; 상기 호스트 A가, 상기 호스트 B로 ACK와 함께 AuthA를 송신하는 단계; 및 상기 호스트 A가, 상기 호스트 B로부터 ACK를 수신하는 단계를 포함하되, K는 Hash(XAB||YAB)이고, TokenB는 lsb32(Hash(XB||YB))이고, HMACToken은 lsb32(HMAC(K, TokenB||Address ID||RA))이고, AuthB는 msb64(HMAC(K, RB||RA))이고, AuthA는 HMAC(K, RA||RB)이고, RA는 상기 호스트 A에서 생성한 난수값이고, RB는 상기 호스트 B에서 생성한 난수값이고, XA는 상기 호스트 A의 타원 곡선의 X 좌표이고, YA는 상기 호스트 A의 타원 곡선의 Y 좌표이고, XB는 상기 호스트 B의 타원 곡선의 X 좌표이고, YB는 상기 호스트 B의 타원 곡선의 Y 좌표이고, XAB는 상기 XA와 상기 XB를 이용하여 연산된 값이고, YAB는 상기 XA와 상기 XB를 이용하여 연산된 값이다.
바람직하게는, 상기 XAB, YAB, TokenB 및 K는 상기 보조 경로 추가 이전에 연산된 것이다.
바람직하게는, 상기 호스트 B가, 상기 HMACToken을 이용하여 MP_JOIN 상의 DoS 방식의 공격자의 접근을 차단하는 단계를 더 포함할 수 있다.
바람직하게는, 상기 호스트 B가, 상기 Address ID를 이용하여 잉여 주소 광고(ADD_ADDR) 방식의 공격자의 접근을 차단하는 단계를 더 포함할 수 있다.
본 발명에 따른 효과는 다음과 같다.
본 발명에서 제안하는 비대칭 키 교환을 이용한 핸드셰이크 방법을 이용하면, 종래의 대칭 키를 이용한 핸드셰이크 방법과는 다르게 비대칭 키를 이용하여 서로를 인증한다. 이 과정에서 공개키의 길이를 줄이기 위해 타원 곡선 암호와 디피-헬만 키 교환 방법을 이용한다.
또한, 이를 구현하기 위해 경로를 시작하는 과정과 보조 경로를 추가하는 과정의 파라미터를 종래의 3방향 핸드셰이크 방법과는 다르게 4방향 핸드셰이크 방법을 이용하여 변경하였다. 이를 통해 MPTCP에서만 발생할 수 있는 보안상의 위협을 제거할 수 있다.
도 1은 종래의 MPTCP의 핸드 셰이크 방법을 설명하기 위한 신호 흐름도이다.
도 2는 본 발명에서 제안하는 MPTCP의 핸드 셰이크 방법을 설명하기 위한 신호 흐름도이다.
도 3은 새로운 MP_CAPABLE의 포맷을 설명하기 위한 도면이다.
도 4는 본 발명에서 제안하는 핸드셰이크 방법의 성능을 설명하기 위한 도면이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
도 1은 종래의 MPTCP의 핸드 셰이크 방법을 설명하기 위한 신호 흐름도이다.
TCP는 현재 연결 당 하나의 경로를 사용하도록 제한되어 있다. 그러나 대부분의 최신 기기들은 다양한 네트워크 인터페이스를 사용할 수 있다. Multipath TCP(MPTCP)는 호스트가 하나의 연결에 대해 다양한 네트워크 인터페이스를 사용하여, 복수의 경로를 통해 동시에 데이터를 전송하는 것을 가능하게 하는 TCP 확장이다. 다양한 보조 경로를 통한 동시 전송은 네트워크 자원의 사용율과 성능을 증가시킨다.
즉 MPTCP는 복수의 경로를 동시에 사용할 수 있게 해주는 일반 TCP의 확장이다. 수신자는 어플리케이션 데이터를 분리하여 다른 경로를 통해 각각의 패킷을 전송한다. 보조 경로(subflow)라고 칭해지는 각 경로들은 개별로 볼 경우 네 개의 튜플(tuple)로 구분되는 일반적인 TCP이다. 송신자는 수집된 데이터를 재조립하여 하나의 바이트 스트림으로 만든다.
도 1을 참고하면 호스트 A(100)와 호스트 B(200) 사이에 2개의 경로가 생성된 것을 볼 수 있다. 호스트 A(100)는 Address A1, Address A2와 같이 2개의 아이피 주소를 가지고 있다. 예를 들면, 호스트 A(100)는 스마트폰이고, Address A1는 LTE 망을 이용하는 아이피 주소이고, Address A2는 와이파이 망을 이용하는 아이피 주소이다.
도 1에서도 볼 수 있듯이 종래의 MPTCP는 3방향 핸드셰이크(3 Way Handshake)를 이용하여 연결을 생성한다. 이는 TCP의 3방향 핸드셰이크와 유사하며, RFC 6824에 정의되어 있다. 종래의 MPTCP에서 수행하는 3방향 핸드셰이크 방법을 살펴보면 크게 2개의 과정으로 나뉜다.
우선 경로를 시작하는 과정에 대해서 먼저 살펴보자. MPTCP의 경로 시작은 핸드셰이크 패킷인 SYN, SYN/ACK 그리고 ACK 패킷에 MP_CAPABLE 옵션을 포함하는 것을 제외하면 일반 TCP와 동일하게 진행된다. MP_CAPABLE 옵션을 이용하여 다른 호스트들의 MPTCP 지원 여부를 확인하고 '보조 경로 추가' 단계에서 인증을 위해 사용되는 키 KeyA, KeyB를 교환한다.
도 1은 호스트 A(100)가 송신자이고 호스트 B(200)가 수신자일 경우일 때, MP_CAPABLE 핸드셰이크를 설명한 것이다. 호스트 A(100)는 Address A1이 사용할 제1 경로를 생성하기 위해, A로 태그 된 패킷들에 MP_CAPABLE 옵션을 포함하여 평문으로 호스트 B(200)와 통신한다.
우선, 호스트 A(100)는 SYN 패킷에 64비트의 KeyA를 전송한다(S1100). 만약 호스트 B(200)가 MPTCP를 지원하지 않으면, 호스트 B(200)는 KeyA의 패킷을 버린다. 그러면 호스트 A(100)는 후방향 지원성(Backward compatibility)를 위해서, MPTCP가 아닌 일반적인 TCP로 돌아가서 연결을 진행한다.
만약 호스트 B(200)가 MPTCP를 지원한다면 호스트 B(200)는 64 비트의 KeyB를 SYN/ACK 패킷에 포함하여 전송한다(S1200). 키 교환의 무결성 확인을 위해, 마지막으로 호스트 A(100)는 교환된 두 개의 키 KeyA와 KeyB를 ACK 패킷에 포함하여 전송한다(S1300). 이와 같은 과정을 통해 제1 경로를 생성한다.
다음으로 보조 경로를 추가하는 과정을 살펴보자. 호스트 A(100)는 Address A2가 사용할 제2 경로를 추가하기 위해, B로 태그 된 패킷들에 MP_JOIN 옵션을 포함하여 평문으로 호스트 B(200)와 통신한다. 여기서 제1 경로를 생성할 때 서로 교환한 키(KeyA, KeyB)를 이용하여 서로를 인증한다.
보조 경로 추가 단계에서는 MP_JOIN 옵션이 각 패킷에 추가되는 것을 빼면 일반적인 TCP 연결과 동일하다. 호스트 A(100)는 호스트 B(200)와 제1 경로로 연결되어 있는 상태이고 여분의 네트워크 주소 Address A2를 가지고 있다. 호스트 A(100)는 자신이 현재 사용하지 않는 여분의 주소 Address A2를 호스트 B(200)의 주소와 연결하고 싶어한다.
이 때, 새롭게 생성되는 보조 경로인 제2 경로는 기존에 존재하는 MPTCP 세션과 병합되기 전에 인증을 먼저 수행해야 한다. 서로가 인증을 수행할 권한을 가지고 있다고 하더라도, 각 호스트 별로 허용된 보조 경로의 수의 제한에 의해 연결이 거절될 수 있다.
이때 토큰 TokenB는 보조 경로가 추가될 MPTCP 세션을 식별한다. 호스트 A(100)는 KeyB를 메시지로 SHA1을 사용하여 TokenB를 생성하고 이를 전송한다. TCP 옵션의 공간 제약 때문에, 호스트 A(100)는 160 비트의 결과값에서 상위 32비트 값을 잘라내어 사용한다. 이 때, MPTCP 세션은 각자 고유한 키를 소유한다.
호스트 B(200)는 저장된 KeyB를 이용하여 해시를 생성해 해당하는 MPTCP 세션을 선택한다. 인증 뒤에는, 새로운 보조 경로인 제2 경로가 성공적으로 기존의 제1 경로의 세션에 합류한다. 해시의 일방향성(One-way property) 덕분에 정당한 사용자만이 TokenB를 생성할 수 있다.
만약, 수신된 토큰이 유효하지 않으면, 호스트 B(200)가 보조 경로를 거절하고 TCP RST으로 응답하여 연결을 종료한다. 이때, 토큰 TokenB는 식별자로서 보조 경로가 병합될 MPTCP 세션을 결정한다. 다만, 토큰 TokenB는 하나의 고유한 MPTCP 세션에서 보조 경로가 추가될 때마다 재사용되기 때문에 암호학적 안전함을 보장하지는 않는다.
호스트 인증은 HMAC에 기반한다. 호스트 A(100)과 호스트 B(200)는 RA과 RB를 교환한다. 호스트 B(200)는 교환된 키들을 이용하여 KeyB||KeyA를 생성하여 HMAC의 키로 사용하고 RB||RA를 메시지로 사용하여 HMACB를 생성한다. 호스트 A(100)는 결합 연산의 순서를 반대로 한다. 즉 호스트 A1(100)는 KeyA||KeyB를 키로 사용하고, RA||RB를 메시지로 사용하여 HMACA를 생성한다.
HMAC 중에 HMACB는 상위 64비트를 잘라서 사용하고 HMACA는 160비트를 전부 사용한다. 오직 KeyA와 KeyB 두 개의 키를 소유한 정당한 사용자만이 유효한 HMACA와 HMACB를 만들 수 있다. 유효하지 않은 HMAC는 인증에 실패하고, TCP RST을 통해 보조 경로를 종료한다.
MPTCP 세션은 성능 상의 이유로 묶여 있는 다른 보조 경로를 종료 시킬 수 있다. 따라서, MPTCP는 종료 시킬 보조 경로를 정확히 식별할 수 있어야 한다. 만약, IP 주소가 식별자로 사용된다면, NAT와 같이 호스트 사이에서 IP 헤더를 임의로 변경하는 미들박스(Middlebox)가 IP 주소를 변경하기 때문에 정확히 보조 경로를 식별할 수 없다. 이런 상황을 피하기 위해서, MPTCP는 미들박스의 영향을 받지 않는 새로운 식별자가 필요하다. 그래서 MP_JOIN은 하나의 보조 경로를 의미하는 한 바이트의 Address ID를 포함한다.
도 1에서 B로 태그 된 패킷들은 MP_JOIN 핸드셰이크를 설명한 것이다. 호스트 A(100)는 Address ID, TokenB와 RA를 SYN 패킷에 동봉하여 전송한다(S1400). 호스트 B(200)는 토큰 TokenB을 확인하고, HMACB와 RB를 SYN/ACK에 포함하여 전송한다(S1500).
호스트 A(100)는 인증 값을 확인하고, 상대방이 정당한 사용자임을 확인한다. 이제 호스트 A(100)는 이번 요청이 유효한 요청임을 신뢰할 수 있다. 그러나 호스트 B(200)는 아직 이번 연결에 대한 확신이 없다. TokenB는 난수값을 이용하지 않고 단순히 SHA1으로 생성된 식별자이기 때문에 공격자가 쉽게 악용할 수 있어서 인증값으로 사용되면 안된다.
호스트 A(100)는 임의의 난수가 포함된 인증 값으로 자신의 권한을 증명해야 한다. 호스트 A(100)는 HMACA를 생성하여 호스트 B(200)에게 보낸다(S1600). 비록 HMACA가 160 비트이지만, 이를 전송할 수 있는 충분한 공간이 있기 때문에 HMACA는 절단되지 않는다.
호스트 A(100)와 호스트 B(200)가 보조 경로를 생성하기 위해 주고 받는 파라미터를 정리하면 다음의 표 1과 같다.
Notations Values
TokenB lsb32(Hash(KeyB))
HMACB msb64(HMAC(KeyB||KeyA, RB||RA))
HMACA HMAC(KeyA||KeyB, RA||RB)
이상으로 MPTCP에서 2개의 호스트가 경로를 시작하고 보조 경로를 추가하는 과정을 살펴보았다. 하지만, 호스트 A(100)와 호스트 B(200)가 MPTCP로 연결을 생성하는 과정에는 보안상의 취약점이 여러 군데 존재한다. 대표적인 예로 잉여 주소 광고가 있다.
호스트들은 MP_JOIN 옵션을 사용하여 자신이 직접 보조 경로를 생성할 수 있다. 또한, 자신의 잉여 네트워크 주소를 광고하여 다른 호스트가 광고 받은 주소를 목적지로 보조 경로 연결을 시작하도록 유도하여 새로운 보조 경로를 생성할 수도 있다.
잉여 주소 광고(Address Advertisement, ADD_ADDR) 연산은 오직 클라이언트의 요청만 허용되는 클라이언트-서버 방식에서 유용하다. 클라이언트-서버 방식에서 서버는 자신의 잉여 네트워크 주소를 (Address ID, IP 주소, 포트 번호) 형식으로 광고한다. 그런 다음, 클라이언트는 광고 받은 주소로 보조 경로 형성을 시작한다.
이때, ADD_ADDR를 이용한 공격이 가능하다. 보조 경로 추가는 HMAC을 포함한다. 공격자는 HMAC을 획득하기 위해 자신이 서버인 척 위장하여 클라이언트에게 보조 경로를 시작하도록 유도한다. HMAC의 생성은 앞서 보조 경로 추가 과정에서 설명한 것처럼 사용하고, 메시지는 (Address ID, IP 주소, 포트 번호)이다. 이를 통해 공격자는 MPTCP의 세션을 가로챌 수 있다.
이와 같은 MPCTP의 보안상의 위협에 대해서 보다 자세하게 살펴보자. MPTCP의 기초적인 목표는 TCP보다 나쁘지 않은 보안을 제공하는 것이다. IETF 문서에서는 TCP와 MPTCP 모두 적용되는 보안 위협들에 대해서는 고려하지 않고 있다. 당연하게도, TCP에 적용되는 위협은 일반 TCP의 확장인 MPTCP에도 그대로 영향을 미친다.
IETF 문서에서는 TCP 상에서는 안전하지만 오직 MPTCP 상에서만 취약한 공격에 대해서만 고려한다. 보안을 강화하기 위해서, MPTCP는 경로 시작 과정과 보조 경로 추가 과정에서 설명한 HMAC 기반의 핸드셰이크를 도입했다. 이때, MPTCP에 관한 기존 연구들은 현재 구현된 MPTCP가 최소한의 TCP 수준의 보안을 제공할 수 있는지 검증하는데 주력하였다. 이러한 기존 연구들은 크게 공격자 모델을 그들의 위치를 기반으로 분류하였다.
위치 1) 경로 외의 공격자는 MPTCP 세션에 포함된 어떤 보조 경로 상에도 존재하지 않는다. 경로 외의 공격자는 MPTCP 세션에서 사용되는 패킷을 도청할 수 없다.
위치 2) 경로 상의 공격자는 MPTCP 세션에 포함된 세션 중 최소한 하나의 보조 경로 상에 존재해야 한다.
위치 1의 경우인 경로 외의 공격자는 도청을 통해 공격을 위한 어떤 정보도 획득할 수 없기 때문에 공격하기에 가장 제한적인 모델이다. 달리 말하면, 경로 외의 공격자 모델에서 할 수 있는 공격들은 어떤 공격자 모델에서도 공격이 가능하기 때문에 해당 조건 하에 존재하는 취약점은 가장 큰 영향을 가진다고 할 수 있다.
반대로, 위치 2의 경우인 경로 상의 공격자는 보조 경로를 통해 전송되는 모든 정보를 획득할 수 있기 때문에 보안을 제공하는 것은 다른 모델에 비해 어렵다. 기존 연구에서는 MPTCP 상에 존재하는 주요 위협과 부가적인 위협에 대해 정리하였다. 이러한 보안상의 위협에 대해서 크게 3가지의 유형으로 살펴보면 다음과 같다.
첫번째 공격 유형으로 최초 핸드셰이크 상의 도청자가 있을 수 있다. 공격자는 최초 3방향 핸드셰이크에서 교환되는 두 개의 MPTCP 키 KeyA, KeyB를 도청할 수 있다. MPTCP 상에서, 정당한 사용자는 최초 핸드셰이크를 통해서 공유된 키를 소유하고 있는 개체들이다.
최초 핸드셰이크 상의 도청자는 도청을 통해 공유된 두 개의 키를 소유하고 있으므로 정당한 사용자와 똑같은 권한을 가진다. 이를 막기 위해 가능한 해결책들이 존재한다. 최초 핸드셰이크 상의 도청자 모델은 MPTCP 상에서 가장 강력한 공격자 모델이다.
MPTCP 상의 최초 3방향 혹은 4방향 핸드셰이크는 일반적인 TCP 핸드셰이크를 계승한다. 최초 핸드셰이크를 조작하는 것은 일반적인 TCP 핸드셰이크를 조작하는 것이고, 만약 일반적인 TCP 핸드셰이크를 조작한다면, 이는 TCP 상에 적용되는 위협이지 MPTCP 상의 고유한 위협이 아니다.
이는 본 발명에서 해결하고자 하는 MPTCP에 고유한 보안상의 위협은 아니므로 논외로 한다. 즉, MPTCP 상의 위협으로 인정받기 위해서는 MPTCP로 인해 추가적으로 발생하는 연산에 의한 것이어야 한다. 따라서, 최초 핸드셰이크의 무결성은 보장되어야 한다.
두번째 공격 유형으로 MP_JOIN을 이용한 DoS(Denial of Service) 공격이 있다. SYN+MP_JOIN 패킷 안에 유효한 토큰을 포함하여 상대방 호스트에게 전송하면(S1400), 상대방을 수신 상태(receiving state)로 변경시킨다. 상대방은 HMAC을 검증하기 위해서 두 개의 32 비트의 난수를 저장하고 있어야 한다.
만약 공격자가 3방향 핸드셰이크 중 세 번째 패킷을 응답하지 않는다면, 상대방은 세 번째 ACK 패킷이 올 때까지(S1600), 반쯤 열린 상태(half-open state)를 유지한다. 만약, 하나의 MPTCP 세션에 대해 반쯤 열린 상태 연결에 대해 개수 제한이 있다면, 공격자는 개수 제한을 우회하여 상대방 호스트의 자원을 고갈시키기 위해서 단순히 MP_JOIN 옵션을 보낼 사용하는 네 가지 튜플을 변경하여 전송하면 된다.
이 공격을 위해서 공격자는 토큰이 필요하다. 토큰은 암호학적 안전성을 보장하기 위해서가 아니라 MPTCP 세션을 식별하기 위해 존재하므로 평문으로 전송된다. 따라서, 공격자는 토큰을 쉽게 탈취할 수 있다. 일부분 동안(partial time) 경로 상에 존재하는 공격자 모델에서 MP_JOIN 3방향 핸드셰이크를 주시하다 유효한 토큰을 포함한 MP_JOIN 패킷을 획득하여, 이를 이용하여 DoS 공격을 수행할 수 있다. 즉 일시적으로 토큰을 탈취하는 것만으로 DoS 공격이 가능하다. 토큰은 보조 경로를 생성하는 과정에서 계속해서 동일한 값으로 재사용되기 때문이다.
세번째 공격 유형으로 앞서 잠시 설명한 잉여 주소 광고를 통한 공격(ADD_ADDR attack)이 있다. ADD_ADDR 공격은 man-in-the-middle(MitM)을 이용한 MPTCP 세션 탈취 공격이다. 경로 외의 공격자는 ADD_ADDR 공격을 수행할 수 있다. 공격자는 호스트들 사이의 경로에 존재하지 않아도 ADD_ADDR 옵션을 이용해 중간자로 끼어들어 MitM 환경을 구성할 수 있다.
해당 공격을 막기 위해서 최신 MPTCP RFC 문서에는, ADD_ADDR 옵션에서 HMAC을 포함하도록 수정되었다. 그러나, 최초 핸드셰이크 상의 도청자 모델에서는 공유된 키를 알고 있어 유효한 HMAC을 생성할 수 있기 때문에, 여전히 ADD_ADDR 공격에 취약하다. 우선 수정되기 전의 ADD_ADDR 옵션에 대해 살펴보고 그 다음에 수정된 ADD_ADDR에 대해 살펴보기로 한다.
호스트 A(100)와 호스트 B(200)가 안전한 MPTCP 세션을 가지고 있다고 가정하자. 공격자는 호스트 A(100)에게 보조 경로를 추가하려고 한다. 공격자는 자신의 IP 주소와 Address ID를 호스트 B(200)에게 ADD_ADDR 옵션을 통해 전송한다. 호스트 B(200)는 공격자의 요청을 호스트 A(100)의 잉여 주소 광고로 생각하고 MP_JOIN 핸드셰이크를 통해서 광고 받은 공격자의 IP 주소로 연결을 요청한다.
호스트 B(200)는 호스트 A(100)를 위한 토큰인 TokenA를 생성할 수 있는 정당한 사용자이다. 호스트 B(200)는 공격자를 호스트 A(100)로 착각하여 난수 RB와 TokenA를 생성하여 공격자에게 보낸다. 공격자는 받은 값들을 호스트 B(200)에게 전달한다. 즉 공격자는 중간에서 호스트 A(100)에서 오는 패킷과 호스트 B(200)에서 오는 패킷들을 가로채서 이를 다시 전달한다. 마지막으로, 호스트 B(200)는 HMACA를 공격자에게 전달한다. 공격자는 HMACA을 이용하여 인증을 마무리한다.
ADD_ADDR 공격은 공격자가 원할 때, 두 호스트의 경로 사이로 침입하여 전형적인 MitM 환경을 만드는 공격이다. ADD_ADDR 옵션을 이용한 연결 요청은 이미 보조 경로에 할당된 Address ID를 사용할 경우, 충돌이 발생하여 거절될 수 있다. 일반적인 네트워크 환경을 고려하면 장비의 네트워크 인터페이스가 부족하기 때문에 MPTCP에서 보조 경로의 수가 적게 제한되어 있다.
현재 MPTCP 구현의 보조 경로 수 제한은 기본 설정이 두 개다. 보조 경로 수가 제한되어 있어, 할당되는 Address ID가 적기 때문에 Address ID의 충돌은 고려하지 않아도 될만큼 미미하다. ADD_ADDR 공격의 근원적인 원인은 ADD_ADDR 요청에는 인증값이 없다는 것이다.
인증값이 없어 공격자는 쉽게 호스트 A(100)나 호스트 B(200)로 위장하여 ADD_ADDR 연산을 시작할 수 있다. 최근 MPTCP 구현은 잘린 HMAC을 추가하여 오직 정당한 사용자만 IP 주소를 광고할 수 있게 변경하였다. 그러나, 최초 핸드셰이크 상의 도청자는 잘린 HMAC을 생성할 수 있는 키를 모두 소유하고 있으므로, 여전히 ADD_ADDR 공격을 수행할 수 있다. 심지어 공격자는 ADD_ADDR 공격을 이용한 릴레이 방식이 아닌 HMAC을 계산하여 직접 MitM 환경을 구성할 수도 있다.
이처럼 광고 주소 홍보를 이용한 공격은 공격자가 경로 상에 존재하지 않더라도 공격이 가능하다는 점에서 앞서 설명한 경로 외의 공격자의 유형에 해당한다. 그러므로 MPTCP를 이용한 핸드셰이크 과정에서 광고 주소 홍보를 이용한 공격에 대한 방어가 필요하다.
이상으로 도 1과 함께 종래의 MPTCP에서의 핸드셰이크 과정과 그 과정에서 발생할 수 있는 보안상의 위협에 대해서 3가지 유형으로 살펴보았다. 이러한 종래의 MPTCP의 보안상의 문제점을 해결하기 위해 본 발명에서 제안하는 핸드셰이크 방법을 살펴보기로 한다.
도 2는 본 발명에서 제안하는 MPTCP의 핸드 셰이크 방법을 설명하기 위한 신호 흐름도이다. 또한, 도 3은 새로운 MP_CAPABLE의 포맷을 설명하기 위한 도면이다.
앞서 살펴본 것처럼 MPTCP만의 보안상의 문제점이 발생할 수 있는 근본적인 원인은 KeyA와 KeyB가 평문으로 교환된다는 점이다. 이처럼 키 교환이 평문으로 이루어지기 때문에, 최초 핸드셰이크 단계에서 도청자는 두 개의 키를 모두 알 수 있고, 공격자는 정당한 사용자의 권한을 얻을 수 있다. 그리고, 최초 핸드셰이크가 끝나기 전에는 호스트 A와 호스트 B는 서로를 알 수 없기 때문에, 알 수 없는 개체 간의 비밀을 안전하게 공유하는 것은 어렵다.
이러한 문제점을 해결하기 위해서 본 발명에서는 비대칭 키 교환을 이용한 핸드셰이크 방법을 제안한다. 비대칭 암호학의 특성을 이용하면, 알 수 없는 개체 간에 키 노출 없이 안전하게 키를 교환할 수 있다. 다만, MPTCP에 비대칭 암호화를 적용하기 위해서는 두 가지의 문제점을 해결해야 한다.
첫째는 TCP 옵션에 공간 제약이다. MPTCP는 TCP 옵션을 이용하여 설계되었다. TCP 옵션의 최대 크기는 40 바이트이며 이 중, 4 바이트는 MPTCP 옵션 헤더가 차지한다. 실질적으로 가용한 공간은 36바이트이며, 이는 비대칭 암호학 매개변수가 포함되기에는 작은 공간이므로, TCP 페이로드를 사용하지 않고 TCP 옵션만으로 구현하기에는 매우 힘들다.
SYN 플래그가 포함된 패킷은 최초 시퀀스 번호(sequence number)를 협상하기 위해서 데이터를 포함할 수 없다. TCP 핸드셰이크에서 최소 패킷 두 개는 데이터를 전송하는데 사용할 수 없고 이는 공개 매개변수를 교환하기 위해 추가적인 패킷이 필요하게 되는 결과를 초래한다.
둘째는 비대칭 암호학 계산의 비용이다. MPTCP 보조 경로의 짧은 연결은 전체적인 TCP 성능을 감소시킨다. 모든 MPTCP 세션이 많은 양의 데이터를 전송하지는 않는다. 그들 중 몇몇은 데이터를 전송할 양이 적기 때문에 연결이 맺어지거나 바로 직후에 연결을 종료한다.
MPTCP 보조 경로의 짧은 연결이 발생하면, 불필요한 보조 경로 추가 연산이 수행되기 때문에 전체적인 TCP 성능을 감소시킨다. 그러나, 전송 계층은 어플리케이션 데이터의 양을 측정할 수 없기 때문에 연결이 수행되기 전 보조 경로가 필요한지 아닌지 예측하는 것은 어렵다.
종래에는 보조 경로가 생성되는 시간을 지연시키는 방법으로 짧은 연결 문제의 손실을 감소시킬 수 있었다. 보조 경로가 생성되는 시간이 늦어졌기 때문에, 적은 양의 데이터를 전송하는 경우, 보조 경로가 생성되지 않는다. 대신 많은 양의 데이터를 전송하는 긴 수명을 지닌 연결만 보조 경로를 생성하게 되어 불필요한 보조 경로 추가 연산과 보조 경로가 생성되지 않는다.
그러나 이러한 방법을 적용한다고 하여도, 최초 핸드셰이크의 연산 비용은 피할 수 없다. 최초 핸드셰이크의 비용은 매 연결 시 적용되기 때문에 전체적인 네트워크에 큰 영향을 미친다. 더군다나 현재 구현은 최초 핸드셰이크 상의 도청자 모델에 대해 안전하지 않음에도 불구하고, 핸드셰이크를 최소화하기 위해서 키 교환을 평문으로 수행하고 있다.
이처럼 단순하게 비대칭 키를 핸드셰이크 과정에 적용하게 되면 앞서 설명한 것처럼 최초 핸드셰이크의 비용을 증가시켜서 추가적인 패킷을 필요로 하는 문제점이 있다. 이를 해결하기 위해서 본 발명에서는 비대칭 키를 공개 매개변수에 최적화하여 통신을 수행하는 방법을 제안한다.
본 발명에서 제안하는 최적화된 매개 변수는 TCP 옵션 안에 포함될 수 있어 4방향 핸드셰이크를 제외한 추가적인 패킷을 필요로 하지 않는다. SSL/TLS을 고려하면 일반적으로 공개 매개변수는 TCP 옵션에 포함되기에는 매우 크다. MPTCP는 상대방의 실제 신원 정보를 고려하지 않는 약한 인증을 사용한다.
본 발명에서 제안하는 방법은 인증서 교환을 생략했다. 공개키를 보증할 수 없으나 보조 경로가 MPTCP 세션의 올바른 소유자로부터 시작되었다는 것은 보장한다. 인증서 교환을 생략하여 패킷 크기를 줄였지만, 여전히 공개키의 크기는 TCP 옵션에 포함되기에는 크다. 이를 해결하기 위해 추가적으로 타원 곡선 암호와 타원 곡선 암호에 디피-헬만 키 교환을 적용하여 공개키의 크기를 최소화 할 수 있다.
타원 곡선 암호는 타원 곡선 이론에 기반한 공개 키 암호 방식이다. 줄여서 ECC라고 쓰기도 한다. 타원 곡선을 이용한 암호 방식은 닐 코블리츠와 빅터 밀러가 1985년에 각각 독립적으로 제안했다. 타원 곡선 암호가 RSA나 ElGamal과 같은 기존 공개 키 암호 방식에 비하여 갖는 가장 대표적인 장점은 보다 짧은 키를 사용하면서도 그와 비슷한 수준의 안전성을 제공한다는 것이다.
디피-헬만 키 교환(Diffie-Hellman key exchange)은 암호 키를 교환하는 하나의 방법으로, 두 사람이 암호화되지 않은 통신망을 통해 공통의 비밀 키를 공유할 수 있도록 한다. 휫필드 디피와 마틴 헬만이 1976년에 발표하였다. 이에 관한 보다 자세한 설명은 "https://ko.wikipedia.org/wiki/디피-헬만_키_교환" 웹 페이지에서 확인할 수 있다.
도 2를 참고하면, 도 1과는 다르게 A로 태그 된 경로를 시작하는 과정이 4방향 핸드셰이크인 것을 확인할 수 있다. 타원 곡선의 매개 변수는 비특허문헌 0001에 정의된 명명된 곡선(named curve) 중 하나를 사용한다. X 좌표와 Y 좌표의 길이는 타원 곡선의 유형에 따라 다르다.
수정된 MP_CAPABLE은 4방향 핸드셰이크를 필요로 한다. SYN 패킷에는 데이터를 포함할 수 없지만, ACK 패킷에는 데이터를 포함할 수 있다는 점을 이용하여 전송할 수 있는 공간을 확보한다.
호스트 A(100)는 SYN 패킷과 함께 호스트 A(100)의 X 좌표를 MP_CAPABLE 옵션 중에 사용하지 않는 비트 중 하나를 채워서 전송한다(S2100). 호스트 B(200)는 호스트 B(200)의 X 좌표와 함께 ACK 패킷으로 응답한다(S2200). 다시 호스트 B(200)는 SYN 패킷에 호스트 B(200)의 Y 좌표를 포함하여 전송한다(S2300). 마지막으로 호스트 A(100)는 ACK 패킷에 호스트 A(100)의 Y 좌표를 포함하여 전송한다(S2400).
도 3은 새로운 MP_CAPABLE의 포맷을 보여준다. 현재 MPTCP의 구현에서는 플래그 중 'A'와 'H' 플래그를 사용 중이며 'B' 플래그는 추후 확장을 위해 의도적으로 사용하고 있다. 'C'-'G' 플래그는 암호학적 협상을 위해 남겨져 있다.
본 발명에서 제안하는 방법은 사용되지 않는 플래그인 C'-'G'중 하나를 제안된 프로토콜을 표기하기 위해 사용한다. 이하 이해의 편의를 돕기 위해 'C' 플래그를 사용하는 것을 기준으로 설명을 계속하기로 한다.
또한 본 발명에서 제안하는 핸드셰이크 방법은 후방향 지원성을 제공한다. 즉 본 발명에서 제안하는 방법을 지원하는 수신자가 성능 상의 이유로 비대칭 암호화를 사용하고 싶지 않은 경우, 자연스럽게 HMAC 기반의 보안을 적용한 일반적인 MPTCP 동작으로 돌아가서 통신을 수행할 수 있다.
즉 수신자는 'C' 플래그를 채워 응답하는 것이 아닌 일반적인 MPTCP 구현을 의미하는 'H' 플래그와 64 비트의 KeyB를 채워 ACK 패킷에 포함하여 응답한다. 또한 수신자가 비대칭 암호화를 사용하지 않는다고 해서, 'C' 플래그로 채워진 요청 패킷을 버리는 것이 아니라, 요청 패킷 중 수신자의 X 좌표 중 상위 64 비트를 잘라 사용한다. 호스트 A(100)의 X 좌표 역시 임의의 난수로 생성되므로 KeyA의 임의성(randomness) 역시 보장된다.
이상으로 본 발명에서 제안하는 경로를 시작하는 과정을 살펴보았다. 관련해서 보조 경로를 추가하는 과정 역시 종래의 도 1에 비해서 파라미터가 변경되어 있다. 이에 대해서 설명을 계속하기로 한다.
32비트 토큰 TokenB는 새로운 보조 경로가 합류하고 싶은 MPTCP 세션을 식별한다. 만약 송신자가 토큰 재사용을 막기 위해서, 토큰을 생성할 때 임의의 난수 값을 포함한다고 가정해보자. 이러한 가정은 수신자가 어떤 MPTCP 세션을 요청 받았는지 파악하기 어렵게 한다.
수신자는 새로운 보조 경로가 포함되고 싶은 MPTCP 세션을 파악하기 위해서 요청 패킷에 있는 임의의 난수값을 이용하여 저장된 모든 MPTCP 식별자의 해시를 생성하여 토큰을 생성한다. 그 뒤, 새롭게 생성된 토큰과 요청 패킷에 있는 토큰과 비교해야 한다. 수신자는 어떤 MPTCP 세션을 요청 받았는지 알 수가 없기 때문에, 존재하는 MPTCP 세션에 대해서 모두 토큰을 생성해야 한다. 현존하는 MPTCP 세션의 수에 비례하여 TCP 성능을 저하시킨다.
그러므로 보안성을 높이기 위해서 토큰에 난수값을 포함시키는 방법은 성능의 저하를 야기하므로 적절한 해결 방법이 아니다. 본 발명에서는 이를 해결하기 위해 대신에 (토큰, Address ID, 난수값)을 메시지로 이용하는 HMAC을 생성하여 토큰을 보호한다.
Address ID는 보조 경로 별로 다르다. 공격자가 자신의 IP 주소로 보조 경로를 생성하고 싶을 때, 새로운 Address ID에 대한 토큰이 필요하다. 이 때, 공격자는 키를 소유하고 있지 않기 때문에 유효한 토큰을 생성할 수 없다. 덕분에 공격자가 기존에 사용된 유효한 토큰을 알게 되더라도, 새로운 보조 경로에 대한 토큰을 생성할 수 없기 때문에 공격을 실행할 수 없게 된다.
즉 종래의 S1400 단계와 본 발명에서 제안하는 S2500 단계를 비교해보면, 본 발명에서는 HMACToken이 파라미터로 추가되었고, 이는 (토큰, Address ID, 난수값)를 메시지로 이용하기 때문에 Address ID를 생성할 수 없는 공격자로부터 세션을 보호할 수 있다.
다시 도 2를 참고하면, (XA, YA)과 (XB, YB)으로부터 타원 곡선 디피-헬만 키 교환을 이용하여 (XAB, YAB)을 계산한다. 그리고 양 호스트는 (XAB, YAB)를 이용하여 TokenB와 K을 계산한다. 위의 두 계산은 MP_JOIN이 시작되기 전, MP_CAPABLE 핸드셰이크가 끝난 이후에 미리 수행될 수 있다.
MP_JOIN 핸드셰이크 중 호스트 A(100)는 TokenB, HMACToekn, 난수값 RA을 SYN에 추가하여 보낸다(S2500). 호스트 B(200)는 Address ID의 충돌이 없는지 확인하고 HMACToken을 검증한다. 호스트 B(200)는 SYN/ACK에 RB, RA, XAB를 이용하여 도출되는 AuthB를 포함하여 전송한다(S2600). 오직 미리 공유한 비밀 값을 알고 있는 정당한 사용자만이 올바른 인증값을 생성할 수 있다. 마지막으로 호스트 A(100)는 RA, RB, XAB 그리고 YAB으로 AuthA를 생성하여 ACK 패킷에 포함하여 전송한다(S2700).
본 발명에서 제안하는 방법에 의해 호스트 A(100)와 호스트 B(200)가 보조 경로를 생성하기 위해 주고 받는 파라미터를 정리하면 다음의 표 2과 같다.
Notations Values
K Hash(XAB||YAB)
TokenB lsb32(Hash(XB||YB))
HMACToken lsb32(HMAC(K, TokenB||Address ID||RA))
AuthB msb64(HMAC(K, RB||RA))
AuthA HMAC(K, RA||RB)
이렇게 보조 경로를 추가하는 과정의 파라미터를 변경하여 인증을 수행하면 앞서 설명한 잉여 주소 광고에 의한 공격으로부터 세션을 안전하게 보호할 수 있다. 예를 들어, 본 발명에서 제안하는 방법에서도 ADD_ADDR 연산이 취약하다고 가정하자.
공격자는 앞서 설명한 잉여 주소 광고 공격을 통해서 공유된 키를 모른 채로 공격이 가능하다. 현재 MPTCP 구현은 송신자의 IP 주소가 ADD_ADDR 옵션에 포함된 HMAC을 만들 때 사용된 IP 주소와 다를 경우 연결을 거부할 수 있다. 하지만 최초 핸드셰이크 상의 도청자는 양쪽 키를 알고 있기 때문에 자신의 IP 주소를 메시지로 새로운 MAC을 생성할 수 있다.
이에 비해 본 발명에서 제안하는 핸드셰이크 방법에서는 비대칭 키를 사용하므로, 도청자는 공유된 키를 획득할 수 없다. 따라서 제안된 방법에서는 기존의 ADD_ADDR 포맷을 변경하지 않고 최초 핸드셰이크 상의 공격자 모델에 의한 ADD_ADDR 공격에 안전하다.
이상으로 본 발명에서 제안하는 MPTCP의 핸드셰이크 과정을 살펴보았다. 본 발명에서는 종래의 대칭 키와는 다르게 비대칭 키를 이용하여 서로를 인증한다. 이 과정에서 공개키의 길이를 줄이기 위해 타원 곡선 암호와 디피-헬만 키 교환 방법을 이용한다.
또한, 이를 구현하기 위해 경로를 시작하는 과정과 보조 경로를 추가하는 과정의 파라미터를 4방향 핸드셰이크를 이용하는 방법으로 변경하였다. 이를 통해 MPTCP에서만 발생할 수 있는 보안상의 위협을 제거할 수 있다. 다음으로 본 발명에서 제안하는 핸드셰이크 방법의 성능을 종래의 핸드셰이크 방법의 성능과 비교해보자.
도 4는 본 발명에서 제안하는 핸드셰이크 방법의 성능을 설명하기 위한 도면이다.
기존의 MPTLS와 SMPTCP는 최초 핸드셰이크를 통해 키 교환을 끝낸 직후 인증을 위한 공유된 키를 계산한다. 공유된 키를 계산하는 것은 MPTCP 세션이 형성될 때마다 발생하고 이는 네트워크의 전체적인 비용을 증가시킨다. 이런 계산 비용은 최초 핸드셰이크의 비용을 최소화하지 못한다는 단점이 있다.
이에 비해 본 발명에서 제안하는 방법은 최초 핸드셰이크 상에서 공개키를 교환하지만, 전체적인 네트워크 비용을 줄이기 위해서 보조 경로 추가 연산에서 키를 계산한다. 짧은 연결 문제에서, 제안하는 프로토콜은 MP_JOIN이 발생하지 않으면 공유된 키를 계산하지 않는다. 본 발명에서 제안하는 방법은 MPTCP의 특성을 고려하여 설계되어 계산 비용을 최적화했을 뿐 아니라, 공간 및 시간 비용 역시 최소화하였다.
원칙적으로 비대칭 키 교환 방법은 공개되는 정보의 크기 때문에 '바이트'로 표현되는 높은 공간 비용을 지닌다. 이를 해결하기 위해 본 발명에서 제안된 비대칭 암호화 방법은 키 교환을 위한 다른 핸드셰이크를 가진다. 도 4에서는 명확한 비교를 위해서 공간 소모 비용을 바이트의 총합으로 표현하지 않고, 패킷 당 바이트 수를 계산하여 수식 형태로 표현하였다.
수식 중 덧셈 연산의 연산자들은 핸드세이크를 구성하는 각 패킷들의 크기이다. 본 발명에서 제안한 방법은 공개 키 방법 중 MP_CAPABLE 측면에서 가장 적은 공간 비용을 가진다. 또한 MP_JOIN 상에서 DoS 공격을 방어하기 위해서, 제안하는 프로토콜은 토큰을 평문으로 사용하고 토큰을 보호하기 위해서 토큰의 HMAC, HMACToken을 MPTCP 세션을 식별하기 위해 사용한다.
추가적인 HMAC은 다른 방법에 비해 4 바이트 큰 공간 비용을 발생시킨다. 프로토콜의 시간 비용은 일방향 메시지 지연시간(one-way message latency)를 의미하는 RTT/2의 수로 표현된다. 비록 제안하는 프로토콜이 MP_CAPABLE의 4방향 핸드셰이크가 필요하다고 하더라도, 두 번째 ACK 패킷과 세 번째 SYN 패킷은 동시에 전송할 수 있기 때문에 추가적인 시간이 필요하지 않아 RTT/2의 수는 세 개다.
MPTLS은 TLS 핸드셰이크에 기반하기 때문에 큰 공간 비용 및 시간 비용을 지닌다. MP_JOIN 핸드셰이크는 모든 방법에 대해서 필요한 RTT/2가 세 개로 똑같기 때문에, 성능 평가 면에서 의미 있는 값이 아니어서 도 4에서는 의도적으로 생략되었다.
비대칭 키 교환을 이용하는 방법은 최초 핸드셰이크 상의 도청자에 대해서 안전하다. 추가적으로, 키 교환이 키 노출 없이 이루어지기 때문에 데이터 암호화가 가능하다. 해시 체인은 비대칭 방법과 같은 최초 핸드셰이크 상의 도청자 공격 모델을 대처하기 위한 연구이다.
하지만, 해시 체인 방식은 보조 경로의 경로 상의 능동적인 공격자 모델에 대해 안전하지 않다. 공격자는 정당한 사용자의 MP_JOIN 요청을 버리고 획득한 패킷에서 필요한 해시 값들을 포함하여 공격자의 MP_JOIN 요청을 생성할 수 있다. 또한 해시 체인 방식은 ADD_ADDR 공격에 대한 방어책이 존재하지 않는다.
해시 체인 방식은 최초 핸드셰이크 상의 도청자 모델에 대해 ADD_ADDR 공격에 여전히 취약하다. 하지만, 해시 체인 방식이 MPTCP 드래프트에서 제안된 수정된 ADD_ADDR 포맷을 사용한다면, ADD_ADDR 공격에 대해 안전할 수 있기 때문에 도 4에서 '안전함'으로 변경될 수 있다.
본 발명에서 제안한 프로토콜을 다른 비대칭 방식의 프로토콜과 비교하였을 때, 명확한 차이를 보이는 것은 MP_JOIN 상에서의 DoS 공격이다. 다른 비대칭 암호학 방식은 공격자가 유효한 토큰을 통해서 공격이 가능했다. 그러나 제안하는 프로토콜에서는 공격자가 유효한 토큰을 알아도, 공유된 키를 알지 못해서 HMACToken을 생성할 수 없기 때문에 공격자는 DoS 공격을 수행할 수 없다.
만약 공격자가 새로운 HMACToken을 생성하는 것이 아니라 기존 난수값을 재사용하여 HMACToken을 재사용하면, 수신자는 Address ID의 충돌을 검사하여 DoS 공격을 방어할 수 있다.
이상 첨부된 도면을 참조하여 본 발명의 실시 예들을 설명하였지만, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시 예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.
100: 호스트 A
200: 호스트 B

Claims (10)

  1. 호스트 A가, 호스트 B와 연결을 생성하면서, 타원 곡선 디피-헬만 키 교환 방법을 이용하여 비대칭 키를 교환하는 단계; 및
    상기 호스트 A가, 상기 호스트 B와 보조 경로를 추가하면서, 상기 비대칭 키를 이용하여 서로를 인증하는 단계를 포함하고,
    상기 비대칭 키를 이용하여 서로를 인증하는 단계는,
    상기 보조 경로의 식별자인 Address ID를 더 이용하여 서로를 인증하는 단계를 포함하며,
    상기 보조 경로의 식별자인 Address ID를 더 이용하여 서로를 인증하는 단계는,
    상기 호스트 A가, 상기 호스트 B로 SYN와 함께 TokenB, HMACToken, RA를 송신하는 단계;
    상기 호스트 A가, 상기 호스트 B로부터 SYN/ACK와 함께 AuthB, RB를 수신하는 단계;
    상기 호스트 A가, 상기 호스트 B로 ACK와 함께 AuthA를 송신하는 단계; 및
    상기 호스트 A가, 상기 호스트 B로부터 ACK를 수신하는 단계를 포함하되,
    K는 Hash(XAB||YAB)이고,
    TokenB는 lsb32(Hash(XB||YB))이고,
    HMACToken은 lsb32(HMAC(K, TokenB||Address ID||RA))이고,
    AuthB는 msb64(HMAC(K, RB||RA))이고,
    AuthA는 HMAC(K, RA||RB)이고,
    RA는 상기 호스트 A에서 생성한 난수값이고,
    RB는 상기 호스트 B에서 생성한 난수값이고,
    XA는 상기 호스트 A의 타원 곡선의 X 좌표이고,
    YA는 상기 호스트 A의 타원 곡선의 Y 좌표이고,
    XB는 상기 호스트 B의 타원 곡선의 X 좌표이고,
    YB는 상기 호스트 B의 타원 곡선의 Y 좌표이고,
    XAB는 상기 XA와 상기 XB를 이용하여 연산된 값이고,
    YAB는 상기 XA와 상기 XB를 이용하여 연산된 값인,
    MPTCP의 핸드 셰이크 방법.
  2. 제1항에 있어서,
    상기 타원 곡선 디피-헬만 키 교환 방법을 이용하여 비대칭 키를 교환하는 단계는,
    4방향 핸드셰이크를 이용하여 상기 비대칭 키를 교환하는 단계를 포함하는,
    MPTCP의 핸드 셰이크 방법.
  3. 제2항에 있어서,
    상기 4방향 핸드셰이크를 이용하여 상기 비대칭 키를 교환하는 단계는,
    상기 호스트 A가, 상기 호스트 B로 SYN와 함께 MP_CAPABLE 옵션 포함된 상기 호스트 A의 타원 곡선의 X 좌표를 송신하는 단계;
    상기 호스트 A가, 상기 호스트 B로부터 ACK와 함께 상기 호스트 B의 타원 곡선의 X 좌표를 수신하는 단계;
    상기 호스트 A가, 상기 호스트 B로부터 SYN와 함께 MP_CAPABLE 옵션에 포함된 상기 호스트 B의 타원 곡선의 Y 좌표를 수신하는 단계; 및
    상기 호스트 A가, 상기 호스트 B로 ACK와 함께 상기 호스트 A의 타원 곡선의 Y 좌표를 송신하는 단계를 포함하는,
    MPTCP의 핸드 셰이크 방법.
  4. 제3항에 있어서,
    상기 MP_CAPABLE 옵션 포함된 상기 호스트 A의 타원 곡선의 X 좌표는,
    상기 MP_CAPABLE 옵션의 C 내지 G 플래그 중에 어느 하나를 사용하는 것인,
    MPTCP의 핸드 셰이크 방법.
  5. 제3항에 있어서,
    상기 MP_CAPABLE 옵션 포함된 상기 호스트 B의 타원 곡선의 Y 좌표는,
    상기 MP_CAPABLE 옵션의 C 내지 G 플래그 중에 어느 하나를 사용하는 것인,
    MPTCP의 핸드 셰이크 방법.
  6. 삭제
  7. 삭제
  8. 제1항에 있어서,
    상기 XAB, YAB, TokenB 및 K는 상기 보조 경로 추가 이전에 연산된 것인,
    MPTCP의 핸드 셰이크 방법.
  9. 제1항에 있어서,
    상기 호스트 B가, 상기 HMACToken을 이용하여 MP_JOIN 상의 DoS 방식의 공격자의 접근을 차단하는 단계를 더 포함하는,
    MPTCP의 핸드 셰이크 방법.
  10. 제1항에 있어서,
    상기 호스트 B가, 상기 Address ID를 이용하여 잉여 주소 광고(ADD_ADDR) 방식의 공격자의 접근을 차단하는 단계를 더 포함하는,
    MPTCP의 핸드 셰이크 방법.
KR1020170074121A 2017-06-13 2017-06-13 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법 KR101989147B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170074121A KR101989147B1 (ko) 2017-06-13 2017-06-13 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170074121A KR101989147B1 (ko) 2017-06-13 2017-06-13 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법

Publications (2)

Publication Number Publication Date
KR20180136021A KR20180136021A (ko) 2018-12-24
KR101989147B1 true KR101989147B1 (ko) 2019-06-14

Family

ID=65010005

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170074121A KR101989147B1 (ko) 2017-06-13 2017-06-13 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법

Country Status (1)

Country Link
KR (1) KR101989147B1 (ko)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102259652B1 (ko) 2014-03-31 2021-06-02 삼성전자주식회사 멀티 패스 트랜스포트 제어 프로토콜을 지원하는 통신 네트워크에서 서비스 제공 장치 및 방법
KR101975684B1 (ko) * 2014-07-21 2019-05-07 후아웨이 테크놀러지 컴퍼니 리미티드 링크 제어 노드, 링크 제어 방법 및 통신 시스템

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Elliptic Curves in Transport Layer Security (TLS) - A Presentation Tutorial(2006.5월)
SEC 2: Recommended Elliptic Curve Domain Parameters(2010년)

Also Published As

Publication number Publication date
KR20180136021A (ko) 2018-12-24

Similar Documents

Publication Publication Date Title
Donenfeld WireGuard: Next Generation Kernel Network Tunnel.
Glissa et al. 6LowPSec: An end-to-end security protocol for 6LoWPAN
US10097525B2 (en) System, apparatus and method for generating dynamic IPV6 addresses for secure authentication
JP6508688B2 (ja) エンドツーエンドサービス層認証
Shen et al. Secure device-to-device communications over WiFi direct
Arbaugh et al. Your 80211 wireless network has no clothes
Tsay et al. A vulnerability in the umts and lte authentication and key agreement protocols
Petullo et al. MinimaLT: minimal-latency networking through better security
JP2011139457A (ja) 無線通信装置とサーバとの間でデータを安全にトランザクション処理する方法及びシステム
Pérez et al. Application layer key establishment for end-to-end security in IoT
Modares et al. A survey of secure protocols in mobile IPv6
CN101110672A (zh) 通信系统中建立esp安全联盟的方法和系统
EP3231151B1 (en) Commissioning of devices in a network
KR100948604B1 (ko) 서버 기반 이동 인터넷 프로토콜 시스템에 있어서 보안방법
Chaturvedi et al. Multipath TCP security over different attacks
Taha et al. A link-layer authentication and key agreement scheme for mobile public hotspots in NEMO based VANET
KR101989147B1 (ko) 비대칭 키 교환을 이용한 mptcp의 핸드 셰이크 방법
US8359470B1 (en) Increased security during network entry of wireless communication devices
Cao et al. Unified handover authentication between heterogeneous access systems in LTE networks
Manulis et al. Authenticated wireless roaming via tunnels: Making mobile guests feel at home
Sen Secure and privacy-preserving authentication protocols for wireless mesh networks
Pellikka et al. Lightweight host and user authentication protocol for All-IP telecom networks
Fan et al. On the security of password-based pairing protocol in bluetooth
KR101222619B1 (ko) 무선 메쉬 네트워크의 데이터 인증 방법 및 장치
KR102300487B1 (ko) Mptcp의 서브플로우 보안 연결 방법 및 이를 위한 클라우드 서버, 호스트

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right