MPTCP(Multipath Transmission Control Protocol)는 두 호스트의 연결설정 시, 다수의 TCP 경로를 구성하여 동시에 데이터를 송수신할 수 있다. 따라서 MPTCP는 경로를 추가하려는 호스트의 유효성을 확인하기 위한 인증과정이 필요하기 때문에 초기 연결 설정 시, 키를 교환하여 인증용 토큰을 만든다. 하지만 기존 MPTCP의 토큰은 공개적으로 전송된 키를 그대로 사용하여 생성되기 때문에 MITM(Man In The Middle) 공격에 취약하다. 본 연구에서는 기존 MPTCP 키 교환방식에 ECDH(Elliptic Curve Diffie-Hellman) 키 교환 알고리즘을 적용시켜 기존의 키를 ECDH 공개키로 대체하고, 두 호스트만이 알 수 있는 비밀키를 생성하여 토큰을 만들기 위한 키로 사용하도록 하였다. 또한, 비밀키를 사용하여 데이터의 암호 및 복호화까지 지원하는 방법을 설계하고 구현함으로써 기존 MPTCP에 기밀성을 추가하였다.
MPTCP(Multipath Transmission Control Protocol)는 두 호스트의 연결설정 시, 다수의 TCP 경로를 구성하여 동시에 데이터를 송수신할 수 있다. 따라서 MPTCP는 경로를 추가하려는 호스트의 유효성을 확인하기 위한 인증과정이 필요하기 때문에 초기 연결 설정 시, 키를 교환하여 인증용 토큰을 만든다. 하지만 기존 MPTCP의 토큰은 공개적으로 전송된 키를 그대로 사용하여 생성되기 때문에 MITM(Man In The Middle) 공격에 취약하다. 본 연구에서는 기존 MPTCP 키 교환방식에 ECDH(Elliptic Curve Diffie-Hellman) 키 교환 알고리즘을 적용시켜 기존의 키를 ECDH 공개키로 대체하고, 두 호스트만이 알 수 있는 비밀키를 생성하여 토큰을 만들기 위한 키로 사용하도록 하였다. 또한, 비밀키를 사용하여 데이터의 암호 및 복호화까지 지원하는 방법을 설계하고 구현함으로써 기존 MPTCP에 기밀성을 추가하였다.
MPTCP(Multipath Transmission Control Protocol) is able to compose many TCP paths when two hosts connect and the data is able to be transported through these paths simultaneously. When a new path is added, the authentication between both hosts is necessary to check the validity of host. So, MPTCP exc...
MPTCP(Multipath Transmission Control Protocol) is able to compose many TCP paths when two hosts connect and the data is able to be transported through these paths simultaneously. When a new path is added, the authentication between both hosts is necessary to check the validity of host. So, MPTCP exchanges a key when initiating an connection and makes a token by using this key for authentication. However the original MPTCP is vulnerable to MITM(Man In The Middle) attacks because the key is transported in clear text. Therefore, we applied a ECDH(Elliptic Curve Diffie-Hellman) key exchange algorithm to original MPTCP and replaced the original key to the ECDH public key. And, by generating the secret key after the public key exchanges, only two hosts is able to make the token using the secret key to add new subflow. Also, we designed and implemented a method supporting encryption and decryption of data using a shared secret key to apply confidentiality to original MPTCP.
MPTCP(Multipath Transmission Control Protocol) is able to compose many TCP paths when two hosts connect and the data is able to be transported through these paths simultaneously. When a new path is added, the authentication between both hosts is necessary to check the validity of host. So, MPTCP exchanges a key when initiating an connection and makes a token by using this key for authentication. However the original MPTCP is vulnerable to MITM(Man In The Middle) attacks because the key is transported in clear text. Therefore, we applied a ECDH(Elliptic Curve Diffie-Hellman) key exchange algorithm to original MPTCP and replaced the original key to the ECDH public key. And, by generating the secret key after the public key exchanges, only two hosts is able to make the token using the secret key to add new subflow. Also, we designed and implemented a method supporting encryption and decryption of data using a shared secret key to apply confidentiality to original MPTCP.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
하지만 기존 MPTCP는 공개적으로 전송된 키를 그대로 사용하여 토큰을 생성하기 때문에, 중간에서 공격자가 호스트들의 키를 알게 된다면 서브플로우를 추가하기 위해 사용되는 인증용 토큰을 똑같이 만들어 낼 수 있다[6]. 따라서 본 연구에서는 기존 MPTCP의 키 교환 방식이 이러한 MITM 공격에 취약하다는 점을 보완하기 위해, ECDH 공개키 교환 알고리즘을 적용하여 기존의 키를 공개키로 대체 하였다. 그리고 두 호스트가 교환한 공개키와 각 호스트에서 갖고 있는 개인키로 만들어진 세션키는 토큰을 만들기 위한 비밀키로 사용되어짐으로써, 공개키를 교환한 두 호스트만이 인증을 위한 토큰을 만들 수 있도록 하였다[7].
본 연구에서는 MPTCP에서 초기 연결설정이 되어있는 두 호스트만이 서브플로우를 추가하기 위한 인증용 토큰을 생성할 수 있도록 ECDH를 적용하였다. 그림 5는 두 호스트가 ECDH 알고리즘을 사용하여 세션키를 공유하는 과정을 나타낸다.
마지막으로 두 호스트는 공개키 교환 후, 자신의 개인키와 상대방의 공개키를 곱함으로써 양측이 동일한 세션 키를 갖게 된다[10]. 본 연구에서는 생성된 세션키를 토큰을 생성하기 위한 비밀키로 사용해, 오직 두 호스트만이 토큰을 생성할 수 있도록 하여 기존 MPTCP의 인증과정을 더욱 안전하게 하였다. 그리고 공유된 비밀키를 사용해 MPTCP 데이터의 암호 및 복호를 할 수 있도록 하여 기존 MPTCP에 기밀성을 추가하였다.
가설 설정
현재 기존 리눅스에서 사용되고 있는 TCP 옵션의 크기는 최대 40바이트 중, MSS(Maximum segment size), TCP SACK Permitted, Timestamps, Window scale의 총 19바이트이다. 이에 따라, 본 연구에서 MP_CAPABLE 옵션이 가질 수 있는 공개키의 길이는 17바이트로 정하였다.
제안 방법
커널 영역에 저장된 비밀키는 서브플로우 추가 시, 토큰을 만들고 MPTCP 데이터를 암호 및 복호화 하는 과정에서 사용 된다. MPTCP 데이터의 암호화는 AES 블록 암호화 방식과 CTR 암호화 모드를 사용하였으며, 이는 커널 내에 있는 Crypto API를 사용하여 구현하였다.
본 연구에서는 생성된 세션키를 토큰을 생성하기 위한 비밀키로 사용해, 오직 두 호스트만이 토큰을 생성할 수 있도록 하여 기존 MPTCP의 인증과정을 더욱 안전하게 하였다. 그리고 공유된 비밀키를 사용해 MPTCP 데이터의 암호 및 복호를 할 수 있도록 하여 기존 MPTCP에 기밀성을 추가하였다.
그리고 SYN 또는 SYN/ACK에 포함되어진 키를 수신한 호스트는 비밀키를 받기위해 수신한 키와 자신의 키를 함께 유저 영역 으로 전송한다. 두 호스트의 키를 모두 받은 어플리케이션은 호스트 키와 관련된 파라메타를 찾는 과정을 거친 후, 세션키를 계산한다. 마지막으로 비밀키는 세션 키의 KDF(Key Derivation Function) 결과 값으로 생성 되어진 후에 커널 영역으로 전송된다.
하지만 본 연구에서 데이터의 암호 및 복호화는 커널 내에 있는 Crypto API로 구현되었기 때문에 데이터 패킷을 캡쳐하였을 때, 암호화된 데이터의 내용은 확인할수 있지만 실제 데이터의 암호 및 복호화 검증은 어플리케이션에서 수신한 데이터를 확인함으로써 이루어질수 있다. 따라서 본 논문에서는 암호 및 복호화에 대한 동작검증 대신 암호화된 데이터의 전송 RTT(Round Trip Time)를 기존에 데이터 암호화 기능이 없는 MPTCP와 비교하여 성능분석을 진행하였다.
그러나 실제 리눅스 커널의 MPTCP는 ACK를 수신하는 과정에서 포함된 두개의 키를 별도로 활용하지 않는다. 따라서 본 연구에서는 ACK에 포함되어지는 두 개의 키를 앞서 교환한 공개키의 각각 8바이트 값으로 대체 하였다.
하지만, 이 토큰은 MP_CAPABLE 옵션에서 공개적으로 전송되어진 키를 그대로 사용하여 만들어 지기 때문에, 초기 연결 설정시 공격자가 3-way handshakes 패킷에 포함된 키를 알게 되면, 인증수단으로 사용되는 토큰을 똑같이 만들어낼 수 있다. 따라서 본 연구에서는 MP_CAPABLE에 포함되어 전송된 키를 ECDH 공개키로 대체하고, 이후 양측에서 생성된 세션키가 토큰을 만들기 위한 비밀키로 사용되었다.
본 연구에서는 기존 MP_CAPABLE 옵션에 포함된 호스트들의 키를 ECDH의 공개키로 대체하여, 두 호스 트가 비밀키를 공유할 수 있도록 하였다. 따라서 초기 연결설정 이후 서브플로우를 추가하기 위한 인증 수단인 토큰을 공유된 비밀키로 생성함으로써, 오직 두 호스트만이 서브플로우를 추가할 수 있도록 기존 MPTCP 의 인증방식을 보완하였다.
그리고 두 호스트가 교환한 공개키와 각 호스트에서 갖고 있는 개인키로 만들어진 세션키는 토큰을 만들기 위한 비밀키로 사용되어짐으로써, 공개키를 교환한 두 호스트만이 인증을 위한 토큰을 만들 수 있도록 하였다[7]. 또한 데이터의 기밀성을 보장하기 위해, 공유된 비밀키로 데이터를 암호 및 복호화 할 수 있도록 설계하였고, 이를 리눅스 상에서 구현하고 성능을 분석하였다.
또한, MPTCP에 기밀성을 추가하기 위해 공유된 비밀키를 사용하여 데이터의 암호 및 복호화를 할 수 있도록 하였다. 이로 인해 초기 연결설정 과정과 데이터 전송속도의 시간이 기존 MPTCP보다 증가한 것을 확인할 수 있었다.
본 연구는 현재 리눅스 커널의 Crypto API에서 ECC를 지원하지 않는 이유로, 어플리케이션 계층에서 Openssl 라이브러리를 사용하여 ECDH 키 생성과 비밀키 계산을 위한 프로그램을 구현하였다[11]. 또한, 이를 Netlink 소켓 API를 사용하여 커널영역과 통신할 수 있도록 하였다. 다음 그림 6은 어플리케이션이 동작하는 유저영역과 커널 영역의 통신과정을 간략히 나타낸다.
본 논문에서는 MP_CAPABLE 옵션을 포함한 3-way handshakes에 소요된 시간과 암호화된 데이터를 전송후, ACK를 받는 RTT시간을 측정하였다. 시간을 측정 하기 위해 각각 1000번의 연결 설정과 데이터 전송을 로컬 네트워크 환경에서 실행 하였으며, 사용한 임베디드 보드의 규격은 표 2와 같다.
본 논문에서는 구현한 MPTCP를 임베디드 보드에 포팅한 후, 와이어 샤크로 패킷을 캡쳐하여 동작을 확인하였다. 그림 7은 MP_CAPABLE 옵션을 포함한 SYN 패킷의 캡처 화면이다.
본 연구는 현재 리눅스 커널의 Crypto API에서 ECC를 지원하지 않는 이유로, 어플리케이션 계층에서 Openssl 라이브러리를 사용하여 ECDH 키 생성과 비밀키 계산을 위한 프로그램을 구현하였다[11]. 또한, 이를 Netlink 소켓 API를 사용하여 커널영역과 통신할 수 있도록 하였다.
본 연구에서는 기존 MP_CAPABLE 옵션에 포함된 호스트들의 키를 ECDH의 공개키로 대체하여, 두 호스 트가 비밀키를 공유할 수 있도록 하였다. 따라서 초기 연결설정 이후 서브플로우를 추가하기 위한 인증 수단인 토큰을 공유된 비밀키로 생성함으로써, 오직 두 호스트만이 서브플로우를 추가할 수 있도록 기존 MPTCP 의 인증방식을 보완하였다.
본 연구에서는 이 공개키로 초기 연결 설정 시 MP_CAPABLE 옵션에 포함되는 키를 대체하였다. 마지막으로 두 호스트는 공개키 교환 후, 자신의 개인키와 상대방의 공개키를 곱함으로써 양측이 동일한 세션 키를 갖게 된다[10].
본 논문에서는 MP_CAPABLE 옵션을 포함한 3-way handshakes에 소요된 시간과 암호화된 데이터를 전송후, ACK를 받는 RTT시간을 측정하였다. 시간을 측정 하기 위해 각각 1000번의 연결 설정과 데이터 전송을 로컬 네트워크 환경에서 실행 하였으며, 사용한 임베디드 보드의 규격은 표 2와 같다.
대상 데이터
다음 그림 9는 데이터를 암호화 시켜 전송한 후, 이를 수신측에서 복호화 한 후 보낸 ACK를 수신 할 때까지의 RTT를 측정한 결과이다. 데이터는 본 논문에서 사용된 MSS인 1460바이트를 넘지 않도록 하여 16, 816, 1424바이트의 크기로 각각 1000번 전송하였다.
성능/효과
그림 9의 그래프에서 데이터 전송 RTT는 암호 및 복호화에서 소요되는 시간으로 인해 기존 MPTCP보다 증가한 것을 확인할 수 있다. 또한, 데이터의 암호 방식은 128비트 블록의 단위로 암호 하는 AES를 사용하였기 때문에 데이터의 크기가 커짐에 따라 AES 암호 블록의 개수가 각각 1, 51, 89개로 증가하면서 기존 MPTCP에서 소요된 시간과의 차이가 더 커진 것을 볼 수 있다.
본 논문에서 구현한 MPTCP는 유저 영역에서의 키생성 시간과 커널 영역과의 Netlink 통신으로 인한 지연으로, 기존 MPTCP의 연결 설정 시간과 약 7배의 속도 차이가 생긴 것을 확인할 수 있다.
또한, MPTCP에 기밀성을 추가하기 위해 공유된 비밀키를 사용하여 데이터의 암호 및 복호화를 할 수 있도록 하였다. 이로 인해 초기 연결설정 과정과 데이터 전송속도의 시간이 기존 MPTCP보다 증가한 것을 확인할 수 있었다.
후속연구
추후에는 기존 MPTCP에서 전체 서브플로우의 연결을 종료시키는 MP_FASTCLOSE 옵션이 포함하고 있는 키를 호스트가 공유한 비밀키로 서명함으로서 스푸핑 공격을 예방할 수 있는 방법을 적용시킬 계획이다.
질의응답
핵심어
질문
논문에서 추출한 답변
MPTCP는 무엇인가?
MPTCP(Multipath Transmission Control Protocol)는 두 호스트의 연결설정 시, 다수의 TCP 경로를 구성하여 동시에 데이터를 송수신할 수 있다. 따라서 MPTCP는 경로를 추가하려는 호스트의 유효성을 확인하기 위한 인증과정이 필요하기 때문에 초기 연결 설정 시, 키를 교환하여 인증용 토큰을 만든다.
기존 MPTCP의 문제점은 무엇인가?
따라서 MPTCP는 경로를 추가하려는 호스트의 유효성을 확인하기 위한 인증과정이 필요하기 때문에 초기 연결 설정 시, 키를 교환하여 인증용 토큰을 만든다. 하지만 기존 MPTCP의 토큰은 공개적으로 전송된 키를 그대로 사용하여 생성되기 때문에 MITM(Man In The Middle) 공격에 취약하다. 본 연구에서는 기존 MPTCP 키 교환방식에 ECDH(Elliptic Curve Diffie-Hellman) 키 교환 알고리즘을 적용시켜 기존의 키를 ECDH 공개키로 대체하고, 두 호스트만이 알 수 있는 비밀키를 생성하여 토큰을 만들기 위한 키로 사용하도록 하였다.
기존 MPTCP에 ECDH를 적용시키는 방법과 그에 따른 어떤 효과가 있는가?
본 연구에서는 기존 MP_CAPABLE 옵션에 포함된 호스트들의 키를 ECDH의 공개키로 대체하여, 두 호스 트가 비밀키를 공유할 수 있도록 하였다. 따라서 초기 연결설정 이후 서브플로우를 추가하기 위한 인증 수단인 토큰을 공유된 비밀키로 생성함으로써, 오직 두 호스트만이 서브플로우를 추가할 수 있도록 기존 MPTCP 의 인증방식을 보완하였다.
또한, MPTCP에 기밀성을 추가하기 위해 공유된 비밀키를 사용하여 데이터의 암호 및 복호화를 할 수 있도록 하였다. 이로 인해 초기 연결설정 과정과 데이터 전송속도의 시간이 기존 MPTCP보다 증가한 것을 확인할 수 있었다.
참고문헌 (11)
G. Huston, "IP Multi-Addressing and Multipath TCP," The Internet Protocol Journal, vol. 18, no. 2, pp. 2-12, June 2015.
H. E, Go, J. U. Lee, S. H. Back, and J. H. Hwang "Multipath TCP (MPTCP) standardization and technology development trends," Journal of The Korean Institute of Communication Sciences, vol. 31, no. 9, pp. 9-16, September 2014.
L. T. Tuan, K. S. Kim, J. K. Choe, and S. H. Ro, "A Study on Multi-Path TCP Mobility Management Protocol," Journal of KIIT, vol. 12, no. 6, pp. 109-117, June 2014.
A. Ford, C. Raiciu, M. Handley, TCP Extensions for Multipath Operation with Multipath Addresses, RFC 6824, IETF, 2013.
M. Bagnulo, Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses, RFC 6181, IETF, 2011.
S. H. Sun, E. G. Kim, "A study on the Key Exchange Using ECDH in MPTCP," in Proceeding of the 4th Annual Conference on Engineering and Information Technology, Kyoto, Japan, pp. 84-89, March 2016.
K. J. Ha, C. H. Seo, D. Y. Kim, "Design of Validation System for a Crypto-Algorithm Implementation," Journal of the Korea Information and Communication Society, vol. 39, no. 4, pp. 242-250, April 2014.
BlueKrypt. (2012). NIST Report on Cryptographic Key Length and Cryptoperiod [Internet]. Available: http://www.keylength.com/en/4/.
D. K. Too, S. J. Han, "A Study of Key Distribution for Security on VANET," Journal of the Korea Institute of Information and Communication Engineering, vol. 16, no. 10, pp. 2192-2198, October 2012.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.