KR20070110344A

KR20070110344A - 비양립성 전송에 대한 보안 프로토콜들

Info

Publication number: KR20070110344A
Application number: KR1020077020592A
Authority: KR
Inventors: 호르무즈드 코스라비
Original assignee: 인텔 코오퍼레이션
Priority date: 2005-03-10
Filing date: 2006-03-08
Publication date: 2007-11-16
Also published as: CN101138218B; CN101138218A; JP2008538266A; KR100943551B1; US20060206705A1; US7743245B2; EP1856887A1; WO2006099200A1; JP4712861B2

Abstract

"정직함"은 좋은 단어이다. 불행히도, 이 세상의 일부 사람들은 정직하지 않다. 점점 더해가는 유선화된 세상 속에서, 정직하지 못한 사람들은 한 사람의 비밀스러운 데이터를 불법적으로 습득하고, 예를 들어, 당신이 무엇을 하고, 무엇을 다운로딩 하고, 무엇을 액세스 하는지를 모니터하는 것과 같이, 한 사람의 네트워킹 활동들을 모니터링 및/또는 방해하고, 전화통신 제어와 음성 데이터 혹은 당신의 네트워크 상의 다른 프로토콜 등을 도청하거나 가로채는 무수한 기회들을 찾아왔다. 이러한 위험에 대처하기 위해서, SSL, TLS와 같은 전형적으로 보안화된 통신 프로토콜이 통신을 보호하기 위해 활용된다. 공교롭게도, TSL, SSL 그리고 많은 다른 보안 환경들은 하위 통신 프로토콜이 TCP/IP가 되기를 요구한다. 반면에, VoIP, RTP, SNMP 등과 같은 통신 보호를 필요로 하는 일부 프로토콜들은 TCP/IP가 아닌 UDP상에서만 동작한다. 그러므로, 본 명세서에 개시된 네트워크 심 혹은 다른 실시예들은 이러한 UDP 기반 어플리케이션 프로그램들 및 프로토콜들이 TCP/IP 타입 전송을 요구하는 보안 환경들을 이용하도록 하는데 이용되도록 할 수 있다.

통신, 보안, 프로토콜, TCP/IP, USP

Description

비양립성 전송에 대한 보안 프로토콜들 {SECURITY PROTOCOLS ON INCOMPATIBLE TRANSPORTS}

본 발명은 일반적으로 보안화된 네트워킹을 가능하게 하는 것에 관한 것이며, 보다 구체적으로는 전송계층 보안과 양립할 수 없는 전송에 대해 전송계층 보안을 지원하는 것에 관한 것이다.

불행히도, 이 세상의 일부 사람들은 정직하지 않다. 점점 더해가는 유선화된 세상 속에서, 정직하지 못한 사람들은, 예를 들어, 당신이 무엇을 하고, 무엇을 다운로딩 하고, 무엇을 보며, 무엇을 액세스 하는지를 모니터하는지 등과 같이, 네트워크상의 활동을 모니터하고, 당신의 전화통신(예를들어, VoIP 및 등가물들) 제어와 음성 데이터를 모니터링 하며, SNMP(Simple Network Management Protocol) 명령, RTP(Real Time Transport Protocol) 데이터 등을 방해하는 것과 같이, 당신의 네트워크상의 프로토콜들을 모니터링 및/또는 방해하는 등, 한 사람의 개인적이거나 비밀스러운 데이터를 기웃거리거나 그렇지 않으면 불법적으로 습득하는 무수한 기회들을 찾아왔다.

다른 사람의 부정행위에 대한 위험에 대처하기 위해서, SSL(Secured Socket Layer), TLS(Transport Layer Security)와 같은 전형적으로 보안화된 통신 프로토 콜 등이 한 사람의 데이터에 대한 하나의 통신을 보호하기 위해 활용된다. TLS에 관한 보다 많은 정보를 위해서는, 예를 들어, Internet RFCs(Request for Comments) 2246 (The TLS Protocol Version 1.0), 2712 (Addition for Kerberos Cipher Suites to TLS), 2817 (Upgrading to TLS Within HTTP/1.1), 2818 (HTTP Over TLS), 3268 (AES Ciphersuites for TLS), 3546 (TLS Extensions) 그리고 3749 (Protocol Compression Methods)를 참조한다. 본 명세서에 언급된 모든 RFCs는 인터넷 URL www:ietf:org/rfc에서 이용 가능하다는 것을 주목해야 한다. 또한, URL www:gnu:org/software/gnutls에서 상기 GNU TLS Library[Overview]를 참조한다.( 부주의한 하이퍼링크를 방지하기 위해서 본 명세서에 언급된 URL들의 종결은 콜론으로 되어 있음에 주의해야 한다.)

공교롭게도, TLS, SSL 그리고 많은 다른 보안 환경들은 하위(underlying) 통신 프로토콜이 TCP/IP(Transport Control Protocol/ Internet Protocol)로 되기를 기대한다. 공교롭게도, VoIP, RTP, SNMP 등과 같은 일부 프로토콜들과 어플리케이션 프로그램들은, TLS, SSL 등에 의해 지원받지 못하는 UDP(User Datagram Protocol)와 같은, 신뢰 불가능한 통신 전송으로만 동작한다. UDP와 같은 신뢰 불가능한 전송에 대해 보안, 예를 들어, IPSec(IP Security) 프로토콜 또는 프로토콜 특정 보안을 제공하는 SNMPv3를 제공하려는 시도들도 있어왔다. IPSec에 관한 더욱 많은 정보를 위해서, www:ietf:org/html:charters/ipsec-charter:html에서 이용 가능한 관련된 RFCs를 참조한다. 공교롭게도, 이러한 해결 시도들은 보안 특징들을 사용하기 위하여 SNMP(Simple Network Management Protocol)과 같은 프로토콜을 SNMPv3로 재작성해야 하는 것과 같은, 프로토콜-특정 제한들 뿐만 아니라 부하, 복잡성을 겪는다. 그 밖의 제한들은 이러한 프로토콜들에 대한 사유, 비표준 보안 해결방법을 사용하기 때문에 예를 들어, 상호 운용성과 배치(deployment) 이슈를 포함한다.

본 발명의 특징과 장점은 다음의 본 발명에 대한 상세 설명으로부터 명확하게 될 것이다.

도 1은 일 실시예에 따른, 비양립성의 신뢰 불가능한 전송에 대하여 전송계층 보안을 이용한 일반적 개요를 나타낸 도면.

도 2는 일 실시예에 따른, 도 1에 부합하는 특정 기반 구현을 나타낸 도면.

도 3은 TLS와 같은 전송계층 보안 프로토콜들에 필요한 신뢰성 요구사항을 만족하기 위해서 UDP 네트워크 트래픽에 추가될 수 있는 일 실시예에 따른 예시의 프로토콜 계층화를 나타낸 도면.

도 4는 일 실시예에 따른 예시의 네트워크 프로토콜 스택을 나타낸 도면.

도 5는 본 발명의 특정 양상이 구현될 수 있는 적절한 컴퓨팅 환경을 나타낸 도면.

다음의 상세 설명은 UDP(User Datagram Protocol)와 같은, 신뢰 불가능한 전송에 대해 TLS(Transport Layer Security) 또는 상기 SSL 프로토콜과 같은, 보안 전송을 이용하기 위한 다양한 실시예를 기술한다. 설명적 편의성을 위해서, 논의 는, 신뢰 가능한 인-시퀀스(in-sequence) 데이터 전달을 제공하는 바이트 스트림(byte-stream) 지향 전송 상에서 실행하도록 디자인된 전송계층인, TLS에 초점을 맞출 것이다. 그러나, TLS와 SSL이 밀접하게 관련되어 있다는 것은 자명할 것이며, 당업자라면 TLS에 관련된 논의들을 어떻게 SSL과 다른 보안 전송에 적용하는지 이해할 것이다. 보안 옵션들은 UDP 하의 IPSec와 같이, 신뢰 불가능한 전송을 위해 존재한다는 점을 주목해야 한다. 그러나, IPSec는 복잡한 프로토콜이고 많은 오버헤드를 가진 자원 집약적인 프로토콜(resource intensive protocol)이다. TLS의 사용은 상기 프로토콜이 광범위하게 배치되어 있고 좋은 수행 특성을 가지며, 단순 프로토콜 메카니즘, 빌트인 키 교환, 소프트웨어 설치 및 관리의 용이성, 비교적 저 가격 등과 같은, IPSec 에 대한 이점이 있기 때문에 다수의 환경에서 더욱 편리하다.

그러나, TLS의 중대한 한계는, TLS가, 메세지 지향 어플리케이션들을 위한 범용 전송이고, 때때로 전화통신 어플리케이션에 사용되는 TCP와 SCTP(Stream Control Transmission Protocol)과 같은, 신뢰 가능한 하위 전송(underlying transport)을 요구한다는 것이다.(SCTP에 대한 보다 많은 정보를 위해, RFCs 2960과 3436을 참조한다.) 그러나, 신뢰성 요건을 제외하면, 상기 TLS 프로토콜은 그것의 전송에 영향을 받지 않는다. 다음의 논의는, 비접속 UDP 전송과 같은, 신뢰 불가능한 전송에 관한 TLS 사용이 용이하도록 하는 다양한 실시예를 기술한다. 이것은 TLS를 이용하여 SNMP, RTP, VolP, Radius(Remote Authentication Dial In User Service) 등과 같은 프로토콜들에 보안을 제공하는 것을 차례로 용이하게 한 다.(Radius에 대한 더욱 많은 정보를 위해서, RFC 2865를 참조한다.) 이러한 프로토콜들은 현재 그들 자신의 복잡한 사유 보안 머신들을 정의하거나 또는 전혀 보안 머신을 갖지 않는다(예를 들어, RTP). 신뢰 불가능한 전송에 대해 TLS를 이용 가능하게 함으로써, 이러한 프로토콜들은 알려진 표준 보안 전송 환경을 채택할 수 있고, 따라서 그들의 디자인 및 관리를 단순화한다.

도 1은, 일 실시예에 따른, 예를 들면, 웹 브라우저 또는 네트워크 어플리케이션 프로그램을 동작하는 다른 머신과 같은 클라이언트(102)와 예를 들면, 웹 서버, 또는 네트워크 액세스 가능한 데이터 또는 다른 자원을 제공하는 다른 머신과 같은 서버(104) 사이에서 보안화된 통신을 수립하기 위해서 비양립성의 신뢰 불가능한 전송에 대하여 신뢰 가능한 전송과 양립할 수 있는 전송계층 보안을 활용하기 위한 일반적인 개요(100)를 나타낸다.

예를 들면, TLS, SSL, OpenSSL, Virtual Private Network(VPN) 등과 같은 전송계층 보안이, 상기 논의된 바 처럼, 하위 전송이 신뢰 가능한 것을 요구하고, 우리가 이를 UDP와 같은 신뢰 불가능한 전송에 대해 사용하고자 한다면, 하위 전송은 "비양립성"인 것으로 간주 된다. 전형적으로, 상기 TLS, SSL 등의 신뢰성 요건은, 하위 전송이 신뢰 가능한 프로토콜인, TCP/IP가 되도록 요구함으로써 만족된다. 공교롭게도, TCP/IP는 신뢰성을 제공하는 반면, 그것은 또한 중요한 프로세싱 부하와 복잡성을 유발한다. 그러므로, 신뢰 불가능한 전송이 신뢰 가능하게 여겨지도록 함으로써, SSL과 같은 전송계층 보안을 신뢰 불가능한 전송과 인터페이스 하는 "RDL(reliability delivery layer)"이 개시된다.

하나의 실시예에서, RDL(도4 참조)은, 상기 전송계층 보안에 의해 요구된 TCP/IP와 같은 신뢰 가능한 전송에 대한 적어도 최소한의 요구되는 신뢰성 특성들을 추가하고, 신뢰 불가능한 전송의 비양립성을 인지하는 것으로부터 전송계층 보안을 보호하도록, 상기 신뢰 불가능한 전송에 대한 인터페이스(혹은 프로토콜 래퍼(wrapper))를 제공한다. 예를 들어, TLS는 데이터 손상(corruption) 감지와 데이터 손실 감지를 포함하는 최소한의 신뢰성 특성을 요구한다. 상기 RDL은 요구되는 양립성 특성들을 제공하기 위해서 알려진 기술들에 부합하는 신뢰 불가능한 프로토콜을 래핑하거나 그렇지 않으면 인터페이스하는 것으로 간주된다.

RDL은 다양한 방법, 예를 들면, 프로토콜 래퍼, 터널, 네트워크 스택 심(shim), 기존의 프로토콜로의 가상 프로토콜 인터페이스 등에 의해, 다양한 방법으로 구현된다. 그 결과, RDL과 신뢰 불가능한 전송의 조합이 양립 가능한 전송이 되도록 RDL이 비양립적인 신뢰 불가능한 전송에 적어도 최소한의 신뢰성 기능을 추가한다. 일 실시예에서, RDL에 의해 제공된 기능성과 TCP의 기능성 간의 차이점은 RDL은 TLS 및 SSL이 요구하지 않기 때문에 정체 제어를 제공하지 않고, 이미 TLS/SSL의 일부이기 때문에 접속 수립 메카니즘을 가지지 않으며, 복잡한 TCP 상태 머신을 요구하지 않는다는 것이다. RDL은 또한, 보안 위험을 야기하는 프로토콜 특성과 같은, 하위 프로토콜에 대한 원하지 않는 특성을 제거할 수 있다는 점이 이해될 것이다.

실례로써, 한 사람이 전송계층 보안을 수립하기 전에, 예를 들면, UDP 기반 통신 세션과 같은, 하위 신뢰 불가능한 통신 전송을 수립(106)할 필요가 있다. 실 시예에서, 상기 하위 통신 세션은 요구되는 전송계층 보안에 의해 이용되는 통신 포트를 사용하여 수립된다. 판독기(reader)는, 패킷 기반 네트워크 통신에 정통하고, 여기서 데이터는 하나의 패킷(클라이언트(102))에 대한 발신지 네트워크 주소, 그 패킷에 대한 수신지 네트워크 주소(서버(104)) 및 통신 세션에 대한 통신 포트(예를들면, 송신기에 대한 특정 방송 채널을 선택하는 것과 유사함)와 같은 다양한 헤더 영역 및 데이터 페이로드(payload)를 가진 패킷으로 나누어진다고 가정된다.

일단 상기 신뢰 불가능한 통신 전송이 수립되면, 다음 동작은(도시되지 않은 개입되거나 병렬 동작이 있을 수 있음을 주의한다), 예를 들면, 클라이언트(102)와 서버(104) 간의 초기 핸드세이크(handshake) 시퀀스에 관여하여, 데이터 전송, 세션 키 설정, 인증서 교환 혹은 점검 동안 이용될 특정 암호체계의 암호(cryptographic cipher)를 교섭하는(negotiate)(108), 신뢰 불가능한 전송에 대한 보안 통신을 설치하는 것이다. 상기 보안 통신을 설정하는 것은 상기 RDL(Reliability Data Layer)이 상기 비양립성의 신뢰 불가능한 전송을 전송계층 보안과 양립하게 여겨지도록 만드는 것으로 가정한다.

일단 신뢰 불가능한 전송에 대한 보안 통신의 기본 암호체계 특징이 교섭되면(108), 다음의 동작은 신뢰 불가능한 전송에 대해 보안화된 통신을 수립하는 것(110), 즉, 보안 전송계층 설정을 완료하는 것이다. 상기 설정교섭(108)과 접속 수립(110)이 완료되자마자, 데이터는 상기 신뢰 불가능한 전송에 대해 이제 안전하게 교환될 수 있다(112). TLS와 SSL은 빌트인 키 교환 프로토콜을 가지고 있으므로, 모바일 장치에 동적 사용 모델로 매우 적당하다는 것에 주의한다. 그리고, TLS 와 SSL은 상기 전송계층에서 암호화를 제공하기 때문에, 상기 전송계층에서 트래픽 차이를 허용한다. 그 전송계층은 (예를 들면, 전송 포트수 뿐만 아니라 발원지/도착지 IP 주소에 기초하여) 미세 단위(fine granularity)에서 어플리케이션 간의 보안 조직을 설정할 능력을 제공한다.

도 2는 일 실시예에 따른, 예를 들면, TLS 클라이언트(202)와 같은 클라이언트와 예를 들면, TLS 서버(204)와 같은 서버 사이의 보안화된 통신을 수립하기 위하여 비양립성의 신뢰 불가능한 전송에 대하여 전송계층 보안을 활용하는 도 1 실시예의 TLS 기반 버전(200)을 나타낸다.

상기 예시된 실시예에서, 전송계층 보안이 수립되기 전에, 하위 신뢰 불가능한 UDP 전송이 수립된다(206). 상기 UDP 전송은 통신 포트(443)을 이용하여 수립되고, 여기서 통신 포트는 전송계층 보안을 교섭할 때 이용되리라 예상하는 포트 SSL이다. 그러나, 예를 들면, IETF(Internet Engineering Task Force)에 의해 할당된 혹은 장기 존속(long-standing) 규약(convention)에서 이용되는 것과 같은, "공지된", 즉, 예상되는 많은 통신 포트들이 있지만, UDP에 대하여 TLS용으로 임의의 포트 수를 사용할 수 있다는 것이 이해될 것이다. 일단 신뢰 불가능 UDP 전송이 수립되면(206), 다음의 동작은 신뢰 불가능 전송에 대한 보안 통신을 설정하는 것이다. 도 1에 따라서, 설정은 데이터 전송 동안 이용되는 보호를 위한 하위 암호 체계를 교섭하기(208) 위해서 상기 클라이언트(202)와 상기 서버(204) 간에 초기 핸드세이크 시퀀스를 포함한다. 도시된 실시예에서, TLS 세션을 수립하기 위해서 교섭(208)은 TLS 키 교환에 관여하는 것을 포함한다. 보안 핸드세이크는 임의의 추가의 메세지 교환이 발생하기 전에 서로 통신 종단점을 인증할 필요가 있다.

일단 키가 교환되고, 클라이언트(202)와 서버(204)에 의해 암호체계 특징이 일치된다면, 다음의 동작은 신뢰 불가능 전송에 대한 보안화된 통신 수립을 완료 하는 것이다(210). 도시된 실시예에서, 통신 수립을 완료하는 것은, 예를 들어, 대등 인증(peer authentication) 등과 같은, TLS 결합 수립을 포함한다. 설정 교섭(208)과 접속 수립(210)이 완료되자마자, 데이터는 상기 신뢰 불가능 UDP 전송에 대해 이제 안전하게 교환될 수 있다.

도 3은 일 실시예에 따른, TLS와 같은, 전송계층 보안 프로토콜에 의해 필요로 되는 신뢰성 요건을 만족하는 UDP 네트워크 트래픽에 추가될 수 있는, 예시적인 프로토콜 계층화(300)이다. 예시된 실시예에서, RDL(Reliability Delivery Layer) 헤더(302)는 종래의 UDP 헤더와 페이로드(304)의 위에 놓인다. 즉, 래핑하거나 인터페이스 한다. 상기 논의된 바와 같이, RDL은 시퀀스 송달에서 데이터 손상, 데이터 손실 감지 및 재전송 없이, TLS 혹은 다른 보안 전송계층들에 의해 요구되는 최소한의 신뢰성을 제공하기 위해 이용될 수 있다. TLS 프로토콜은 RDL을 활용할 수 있도록 구성된다고 가정된다. 예를 들면, TCP/IP 사용에 구속되는 것처럼 RDL에 구속된 것으로 가정된다.

예시된 실시예에서, RDL 헤더(302)는 16비트 체크섬(checksum)(308), 32비트 일련 번호(312), 32비트 확인 번호(312) 및 16비트 플래그(306)을 포함하는 고정 길이의 12 바이트 헤더를 갖는다. 도시된 실시예에서, RDL 체크섬(308)은 TCP 체크섬에 대응하고, 전송 동안 데이터 손상을 막기위해 헤더와 데이터를 확인하는데 이용될 수 있다. 이것은 UDP 체크섬이 선택적이기 때문에 필요하다. 일 실시예에서, 만일 UDP 체크섬이 사용된다면, 중복을 피하기 위해서, UDP 체크섬은 UDP 네트워크 트래픽에서 제거되고, 대신 RDL 체크섬이 이용된다. 일 실시예에서, 일련 번호(310)과 확인 번호(312)는 데이터 손실이 감지되고 수정되며, 순서대로 전달 데이터가 제공되기 위해서 타임아웃 및 재전송에 연관된다. RDL 헤더는 단편화(fragmentation)/TLS의 재조립(reassembly) 요건을 위해 제공할 것이다.

예시된 실시예에서, 16 비트 버전/플레그 필드(306)는 UDP와 같은 신뢰 불가능 프로토콜을 래핑하거나 그렇지 않으면 인터페이스 하도록 사용되는 RDL 버전을 지정하기 위한 2비트와, ACK(acknowledgement) 플래그로 이용될 수 있는 1 비트를 포함한다. 나머지 13비트는 다른 목적으로 사용될 수 있다. 이러한 비트 중 일부는, 예를 들어, 단편화/ 재조립 기능을 제공하기 위해 이용될 수 있다. 예시된 실시예에서, RDL이, TCP와 같은 헤비 프로토콜(heavier protocol)에서 유효한 것과 같은, 접속 수립 메카니즘을 제공하기를 기대하지 않는다. 그러나, TLS에 의해 요구되지 않는 반면, 상기 플래그들(306)은, TCP에 의해 이용되는 3-웨이 핸드세이크 혹은 SCTP에 대한 4-웨이 핸드세이크와 같은, 접속 지향 행위를 구현하거나혹은 TCP 유사 윈도우 기반 플로우 관리 스킴을 구현하기 위해 이용될 수 있다는 점이 인식될 것이다.

RDL 헤더에 대한 예시된 실시예에서, RDL 헤더는 고정 길이이고, UDP 헤더는 그것의 패킷의 길이를 명기하기 때문에, 길이 필드는 없다. 그러나, 필요하다면,버전/플레그 비트들이 길이 필드를 구현하도록 사용될 수 있다는 점이 이해될 것이 다. 일련 번호(310)은 특정한 수립된(110, 210) 통신 세션에 대한 RDL 메세지들을 고유하게 식별한다. 그것의 초기값은 임의로 선택되고, 연속적인 메세지들에 대하여 증가될 수 있다. 일 실시예에서, 통신 세션에 대한 불법 간섭을 방지하기 위하여, 초기 일련 번호는 통신 종단점 중 하나와 연관된 식별자의 부호화에 기초하고, 그 후 예측 가능한 방식으로 증가한다. 적절하게 부호화된 일련 번호가 결여된 송신된 네트워크 트래픽은 폐기될 수 있다. TCP에 대하여, 확인 번호(312)는 수신한 메세지의 마지막 일련 번호를 나타내기 위해 사용되고, ACK 메세지로 보내진다. ACK 메세지는 데이터를 포함하는 각각의 성공적인 수신 메세지를 위해 전달된다.

RDL의 이용은 TLS 프로토콜 또는 UDP에 어떠한 변경도 요구하지 않는다. 그러나, TLS가 RDL에 대해 상기 상술된, 신뢰성 지원를 추가하기 위하여 변경될 수는 있음을 이해해야 한다. 그러므로 상기 언급된 바와 같이, TLS가 UDP를 래핑하더나 그렇지 않으면 인터페이스 할 필요없이 UDP상에 직접적으로 동작하도록 한다는 점을 이해해야 한다.

도 4는 어플리케이션(402)에 의한 이용을 위한 일 실시예에 따른, 예시적인 네트워크 프로토콜 스택(400)을 나타낸다. 어플리케이션은 스트리밍 미디어에 사용되는 RTP(Real Time Transport Protocol), SNMP(Simple Network Management Protocol), Radius 프로토콜, SMTP(Simple Mail Transper Protocol), 또는 웹 브라우저, 데이터 전송 프로그램 등과 같은, 네트워크와 통신 가능하게 결합된 임의의어플리케이션 프로토콜 또는 프로그램임을 이해할 것이다. 이해되는 것 처럼, 어플리케이션(402)으로부터의 데이터 및 제어는 하나의 계층으로부터 그 다음으로 계 층들(404-410)을 통하여 상부로부터 하부로 이동한다. 데이터가 스택 하부로 이동함에 따라, 각 계층은 (만일, 적용할 수 있다면) 다른 헤더 데이터로 전해진 데이터를 래핑하고, 역시 (필요하다면) 데이터 중 임의의 것을 변경할 수 있다.

예를 들어, TLS 계층을 이용하기 위해서, 어플리케이션(402)은, OpenSSL 라이브러리(URL www:OppenSSL:org를 참조한다)와 같은, TLS를 지원하는 라이브러리 또는 API(Appication Program Interface)에 적합한 호들(calls)을 만들고, 운영 시스템의 네트워킹 컴포넌트는 프로세싱을 위해서 그러한 어플리케이션 호들을 TLS 계층에 라우팅한다. 현재 TLS를 지원하지 않는 RTTP(Real Time Transport Protocol)과 같은 어플리케이션을 위해서, 어플리케이션 소스 코드는 적합한 TLS 호들을 실행하도록 수정될 수 있고, TLS 호들은 특정 컨텍스트(contexts)에서 사소할지도 모른다. 예를 들어, 어플리케이션이 TLS와 SSL 모두를 지원하는 OpenSSL 라이브러리의 이용을 위해서, 예를 들어, 네트워크 소켓 개방, 판독, 기입, 폐쇄 등과 같은, 네트워크 액세스를 위한 표준 리눅스형태의 소켓 호들을 사용한다고 가정한다면, 어플리케이션의 소켓 호들은 TLS 혹은 SSL을 지원하는 어플리케이션을 위한 각 호들 앞에 "SSL_"을 붙이도록(pre-paid) 수정될 필요가 있다.

소스 코드로의 액세스를 요구하지 않는 대안적 접근은 TLS 또는 SSL을 지원하도록 쓰여진 표준 네트워크 액세스 기능들을 가지는 커스텀 라이브러리에 대한 컴파일러로부터의 중간 객체 파일 또는 이진수 출력물을 연결하는 것이다. 또 다른 옵션은 직접적으로 실행가능한 파일을 수정하거나, 또는 TLS 또는 SSL을 지원하도록 재연결될 수 있게 하기 위해 중간 상태로 역으로 컴파일 하는 것이다. 또 다 른 옵션은 가상 환경 또는 종래의 네트워크 호들을 차단하도록 구성된 가상 머신에서 전송계층 보안을 지원하지 않는 어플리케이션을 운영하고 그들을 전송계층 보안의 사용을 위하여 대응하는 호들로 교체하는 것이다.

그러므로, 어플리케이션(402)이 TLS를 지원하고, TLS 세션이 이미 수립되어 있다고 가정하면, 어플리케이션은 적합한 TLS 헤더로 데이터를 래핑하는 TLS계층 (404)에 의해 수신되는 데이터를 보낼 것이고, 그 다음 그것을 RDL(Raliability Delivery Layer)(406)에 넘겨줄 것이다. 상술된 바와 같이, TLS 및 다른 전송계층 보안 프로토콜들은 신뢰 가능한 하위 전송을 필요로 하므로, 도 3에 대해 상술한 바와 같이, TLS 데이터는 적합한 RDL 헤더로 래핑되고, 신뢰 불가능 UDP로 넘겨진다. 상술한 바와 같이, TLS 또는 UDP 프로토콜들 모두 본 명세서에 개시된 다양한 실시예를 지원하기 위하여 수정을 요구하지 않는다. 따라서, UDP는 RDL로부터 수신된 데이터에 대해 그것의 종래의 헤더를 단순히 래핑하고, 예를 들어, NIC(wired network interface), 무선 NIC 등의, 물리적 네트워크 인터페이스상의 전달을 위해서 IP(Internet Protocol) 계층(410)에 제출한다.

어플리케이션(402)을 구현하는 머신에 의한 또는 TLS 통신 세션으로의 다른 종단점에 의한 데이터 수신을 위해서, 이러한 도해는 단순하게 역으로 동작한다. NIC로부터 수신된 데이터는 IP 계층(410)까지 통과된다. IP 계층(410)은 그 래퍼를 처리하여 제거하고 나머지 데이터를 UDP계층(408)까지 전달하고, UDP계층(408)은 또한 그 래퍼를 처리하여 제거하고 나머지 데이터를 RDL(406)까지 전달한다. UDP는 신뢰성을 시도하지 않는 반면, 상술된 바 대로, 일부 신뢰성을 제공하는 라이트 웨이트(light weight) 프로트콜인 RDL은 손상을 결정하거나 혹은 분실 패킷들을 식별하기 위한 상기 패킷들을 검사할 수 있고, 불량 패킷들, 분실 패킷들 등의 패킷들의 재전송을 위해 요청을 다른 종단점에 적절하게 보낼 수 있다. RDL이 데이터에서 문제를 식별하지 않는다고 가정한다면, 그 래퍼를 제거하고 나머지 데이터를 TSL 계층(404)까지 전달하고, TSL 계층(404)은 수신된 보안화된 데이터를 처리하고, 데이터를 어플리케이션(402)에 전달하기 위해 일반적으로 동작한다. 적합한 헤더를 가진 데이터 래핑 또는 언래핑에 대한 상기의 참조는 다른 네트워크 스택계층으로부터 수신된 데이터에 대한 수정 및/또는 트랜스코딩(transcoding) 부문들을 포함할 수 있다는 점이 주목된다.

도 5와 다음의 설명은 예시된 발명의 특정 양태가 구현될 수 있는 적절한 환경에 대한 간단하고, 일반적인 설명을 의도한다. 본 명세서 하기에 사용되는 것에 따르면, "머신"이란 용어는 하나의 머신 또는 통신 가능하게 결합된 머신들 또는 함께 동작하는 장치들의 시스템을 폭넙게 포함하도록 의도된다. 예시적인 머신들은, 개인 또는 공공 운송, 예를 들어, 자동차, 기차, 택시 등과 같은 운송 장치들 뿐만 아니라, 개인 컴퓨터들, 워크스테이션들, 서버들, 휴대용 컴퓨터들, 핸드헬드 장치들, 예를 들어, PDA(Personal Digital Assistant), 전화, 테블릿들(tablets) 등과 같은 컴퓨팅 장치들을 포함한다.

전형적으로, 환경은, 프로세서(504) 예를 들어, RAM(random access memory), ROM(read-only memory) 또는 다른 상태 보존 매체와 같은 메모리(506), 저장 장치들(508), 비디오 인터페이스(510) 및 입/출력 인터페이스 포트(512)에 부착된 시스 템 버스(502)를 포함하는 머신(500)을 포함한다. 머신은 또 다른 머신, 가상 현실(virtual reality, VR) 환경과의 상호작용, 생체 피드백, 또는 다른 입력 소스 혹은 신호로부터 수신된 지시뿐만 아니라, 키보드들, 마이크 등과 같은, 일반적인 입력 장치들로부터의 입력에 의해 적어도 부분적으로 제어될 수 있다.

머신은, 프로그램 가능한 또는 프로그램 가능하지 않은 로직 장치들 또는 어레이들, ASIC(Application Specific Intergrated Circuits), 내장된 컴퓨터들, 스마트 카드들 등과 같은, 내장된 컨트롤러들을 포함할 수 있다. 머신은 네트워크 인터페이스(518), 모뎀(520) 또는 다른 통신 커플링을 통하는 것과 같은, 하나 이상의 원격 머신들(514, 515)로의 하나 이상의 접속들을 이용할 수 있다. 머신들은 도 1의 네트워크(112), 인트라넷, 인터넷, 근거리 네트워크(522), 광역 네트워크와 같은 물리적 및/또는 논리적 네트워크(522)에 의해서 서로 연결될 수 있다. 당업자라면 네트워크(522)에 의한 통신이 무선 주파수(RF), 위성, 마이크로파, IEEE(Institute of Electrical and Electronics Engineers) 802.11, 블루투스, 광학, 적외선, 케이블, 레이저 등을 포함하여, 다양한 유선 및/또는 무선 단거리 또는 장거리 캐리어들 및 프로토콜들을 이용할 수 있다는 점을 이해할 것이다.

본 발명은, 머신에 의해 액세스될 때, 머신이 일을 수행하거나 요약 데이터 형태들 혹은 저-레벨 하드웨어 컨텍스트를 정의하게 하는, 기능, 절차, 데이터 구조, 어플리케이션 프로그램, 명령 등과 같은 연관된 데이터를 참조하여 또는 관련하여 기술될 수 있다. 연관된 데이터는, 예를 들어, 휘발성 및/또는 비휘발성 메모리(506)에, 또는 하드 드라이브들, 플로피 디스크들, 광스토리지, 데이프들, 플 래쉬메모리, 메모리 스틱들, 디지털 비디오 디스크들, 머신 액세스 가능 생물학적 근간의 상태 보존 매체들과 같은 생물학적 메모리 장치들 등을 포함하는 저장 장치(508) 및 관련된 저장 매체에 저장될 수 있다. 연관된 데이터는 패킷들, 직렬 데이터, 병렬 데이터, 전파된 신호들 등의 형태로 네트워크(522)를 포함하는 전송 환경들을 통해 전달될 수 있고, 압축되거나 암호화된 포맷으로 사용된다. 연관된 데이터는 분산된 환경에서 사용되고, 단일 혹은 멀티 프로세서 머신들에 의한 액세스를 위해 국부적 및/또는 원격으로 저장될 수 있다. 연관된 데이터는 내장된 컨트롤러에 의해 또는 관련하여 사용될 수 있다. 다음의 청구항에서, "논리(logic)"의 용어는 일반적으로 연관된 데이터 및/또는 내장된 컨트롤러들과 가능한 조합을 지칭하는 것으로 의도된다.

그러므로, 예를 들어, 예시된 실시예들에 대해서, 머신(500)이 도 2의 TLS 클라이언트(202)를 구현한다고 가정하면, 그때 원격 머신(514, 515) 중 하나는 도 2의 TLS 서버(204)가 될 수 있다. 원격 머신들(514, 515)이 머신(500)과 같이 구성되고, 그러므로, 머신에 대해 기술된 많은 또는 모든 구성요소를 포함하는 점이 이해될 것이다.

예시된 실시예들을 참조하여 본 발명의 원리를 설명하고 예시하였지만, 본 발명의 원리를 벗어나지 않고도 예시된 실시예는 배치 및 상세에서 수정될 수 있다는 점이 이해될 것이다. 그리고, 전술한 설명은 특정 실시예들에 한정되지 않고도 다른 구성이 고려될 수 있다. 특히, "일 실시예"," 또 다른 실 실시예" 등과 같은 표현이 본 명세서에서 사용되더라도, 이러한 구문은 일반적인 참조 실시예 구성이 가능함을 의미하는 것이고, 본 발명이 특정 실시예 구성으로 한정된다는 의미는 아니다. 본 명세서에 사용된 바와 같이, 이러한 용어들은 다른 실시예들과 조합할 수 있는 동일한 또는 다른 실시예를 참조할 수 있다.

결론적으로, 본 명세서에 기술된 실시예들의 변경에 대한 폭넓은 다양성의 관점에서, 이러한 구체적인 기술은 단지 예시로 의도되며, 본 발명의 범위를 제한하지 않는 것으로 간주되지 않아야 한다. 따라서, 본 발명의 특허청구범위는 다음의 특허청구범위와 그의 등가물의 범위 및 사상에 입각한 모든 수정들을 포함한다.

Claims

사용자 데이터그램 프로토콜(User Datagram Protocol,UDP)을 이용하여 제1 및 제2 머신 사이에 통신하는 방법으로서,

RDL(reliability delivery layer) 인터페이스를 상기 UDP에 제공하는 단계;

상기 제1 및 제2 머신 사이에 UDP 접속을 수립하는 단계; 및

상기 UDP로의 상기 RDL 인터페이스에 대하여 전송계층 보안을 수립하는 단계를 포함하며,

상기 전송계층 보안은 UDP와 비양립성(incimpatible)인 방법.
제1항에 있어서,

상기 전송계층 보안은 TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer) 프로토콜 중 선택된 프로토콜에 따라 동작하는 방법.
제1항 또는 제2항에 있어서,

상기 RDL은 상기 전송계층 보안에 통합되는 방법.
제1항에 있어서,

상기 제1 및 제2 머신 사이의 통신을 위해서 상기 UDP를 이용하도록 기술된 어플리케이션 프로그램용 객체 파일을 제공하는 단계;

네트워크 통신에 관여하기 위해서 네트워킹 호들을 이용하도록 준비된 링크 라이브러리(link library)를 상기 전송계층 보안으로 제공하는 단계;

상기 링크 라이브러리로 이진수의 상기 객체 파일을 적어도 부분적으로 연결하는 것에 기초하는 상기 어플리케이션 프로그램을 위한 실행 가능한 이진수를 만드는 단계

를 더 포함하는 방법.
제1항에 있어서,

상기 RDL은 데이터 손상 감지/수정, 데이터 손실 감지/수정 및 단편화/재조립 기능을 상기 UDP에 제공하는 방법.
제5항에 있어서,

상기 RDL은 데이터 손상 수정, 데이터 손실 수정 혹은 데이터 단편화 재조립 중 선택된 하나를 상기 UDP에 더 제공하는 방법.
비양립성의 신뢰 불가능한 전송에 대하여 신뢰 가능한 전송을 양립할 수 있는 전송계층 보안을 이용하는 방법으로서,

상기 신뢰 불가능한 전송에 RDL(reliability delivery layer) 인터페이스를 제공하는 단계 - 상기 RDL은 상기 신뢰 불가능한 전송에 데이터 손상 감지 및 데이 터 손실 감지 중 선택된 하나를 부가하고, 상기 신뢰 불가능한 전송의 비양립성을 마스킹(masking)함 - ;

상기 신뢰 불가능한 전송을 사용하여 통신 세션을 수립하는 단계; 및

상기 RDL 인터페이스에 대하여 상기 전송계층 보안을 이용하여 보안 통신 세션을 수립하는 단계

를 포함하는 방법.
제7항에 있어서,

상기 신뢰 가능한 전송과 양립할 수 없지만, 상기 신뢰 불가능한 전송과는 양립할 수 있는 어플리케이션 프로그램을 실행하는 단계;

상기 신뢰 불가능한 전송으로의 가상 실행 환경 매핑 네트워킹 호들을 상기 RDL 인터페이스로의 호들에 제공하는 단계

를 포함하는 방법.
제7항 또는 제8항에 있어서,

상기 신뢰 불가능한 전송은 UDP(User Datagram Protocol)인 방법.
제7항에 있어서,

상기 전송계층 보안은 TLS(Transport Layer Security) 혹은 SSL(Secure Sockets Layer) 중 선택된 하나인 방법.
제7항에 있어서,

상기 신뢰 불가능한 전송은 인-시퀀스 데이터 전달이 결여되고, 상기 RDL은 인-시퀀스 데이터 전달을 상기 제2 전송에 제공하는 방법.
제7항에 있어서,

상기 RDL은 상기 신뢰 불가능한 전송(UTP)을 위한 프로토콜 래퍼(wrapper)를 포함하는 방법.
비양립성의 신뢰 불가능한 전송에 대한 전송계층 보안을 이용하기 위한 방법으로서,

상기 네트워크 어플리케이션 프로그램에서 상기 신뢰 불가능한 전송으로의 선택된 네트워킹 호들을 상기 전송계층 보안으로의 네트워킹 호들로 대체하도록 네트워크 어플리케이션 프로그램을 수정하는 단계;

상기 신뢰 불가능한 전송을 상기 전송계층 보안과 양립할 수 있는 신뢰 가능한 전송으로 가장하기 위해서 네트워크 스택에서 상기 신뢰 불가능한 전송 위에 RDL(reliability dilibery layer)를 설치하는 단계; 및

상기 RDL을 이용하도록 상기 전송계층 보안을 구성하는 단계

를 포함하는 방법.
제13항에 있어서,

상기 네트워크 어플리케이션 프로그램을 수정하는 단계는 내부의 네크워킹 호들을 상기 전송계층 보안으로의 대응하는 호들로 교체하기 위하여 상기 네트워크 어플리케이션 프로그램의 소스 코드를 수정하는 단계를 포함하는 방법.
제13항에 있어서,

상기 신뢰 불가능한 전송을 상기 전송계층 보안과 양립할 수 있는 것으로 가장하는 상기 RDL에 대하여 상기 네트워크 어플리케이션 프로그램으로부터의 보안 통신 세션을 수립하는 단계를 더 포함하는 방법.
UDP를 사용하는 제1 및 제2 머신 사이의 통신을 위해서 하나 이상의 연관된 명령들을 갖는 머신-액세스 가능 매체를 포함하는 물품으로서,

상기 하나 이상의 명령들은, 실행된다면, 머신으로 하여금,

RDL 인터페이스를 상기 UDP에 제공하는 단계;

상기 제1 및 제2 머신 사이에 UDP 접속을 수립하는 단계; 및

상기 UDP로의 상기 RDL 인터페이스에 대하여 전송계층 보안을 수립하는 단계

를 수행하도록 하며,

상기 전송계층 보안은 상기 UDP와 양립할 수 없는 물품.
제16항에 있어서,

상기 전송계층 보안을 위한 상기 연관된 명령들은, 실행된다면, 상기 전송계층 보안이 TLS(Transport Layer Security) 혹은 SSL(Secure Sockets Layer) 프로토콜 중 선택된 하나에 따라 동작하도록 하는 명령들을 더 포함하는 물품.
제16항에 있어서,

상기 연관된 명령들은, 실행된다면, 상기 머신으로 하여금,

상기 제1 및 제2 머신 사이의 통신을 위해 상기 UDP를 이용하도록 기술된 어플리케이션 프로그램용 객체 파일을 제공하는 단계;

네트워크 통신에 관여되기 위해서 네트워킹 호들을 이용하도록 준비된 링크 라이브러리를 상기 전송계층 보안에 제공하는 단계; 및

상기 링크 라이브러리로 이진수의 상기 객체 파일을 적어도 부분적으로 연결하는 것에 기초하는 상기 어플리케이션 프로그램을 위한 실행 가능한 이진수를 만드는 단계

를 수행하도록 하는 명령들을 더 포함하는 물품.
비양립성의 신뢰 불가능한 전송에 대한 신뢰 가능한 전송과 양립할 수 있는 전송계층 보안을 이용하기 위해 하나 이상의 연관된 명령들을 갖는 머신-액세스 가능한 매체을 포함하는 물품으로서,

상기 하나 이상의 명령들은, 실행된다면, 머신으로 하여금,

상기 신뢰 불가능한 전송에 RDL(reliability delivery layer) 인터페이스를 제공하는 단계 - 상기 RDL은 상기 신뢰 불가능한 전송에 데이터 손상 감지 및 데이터 손실 감지 중 선택된 하나를 부가하고, 상기 신뢰 불가능한 전송의 비양립성을 마스킹(masking)함 - ;

상기 신뢰 불가능한 전송을 사용하여 통신 세션을 수립하는 단계;

상기 RDL 인터페이스에 대하여 상기 전송계층 보안을 사용하는 보안 통신 세션을 수립하는 단계

를 수행하도록 하는 물품.
제19항에 있어서,

상기 연관된 명령들은, 실행된다면, 상기 머신으로 하여금,

상기 신뢰 가능한 전송과 양립할 수 없지만, 상기 신뢰 불가능한 전송과는 양립할 수 있는 어플리케이션 프로그램을 실행하는 단계; 및

상기 신뢰 불가능한 전송으로의 가상 실행 환경 매핑 네트워킹 호들을 상기 RDL 인터페이스로의 호들에 제공하는 단계

를 수행하도록 하는 명령들을 더 포함하는 물품.
비양립성의 신뢰할 수 없는 전송에 대한 전송계층 보안을 이용하기 위해서 하나 이상의 연관된 명령들을 갖는 머신-액세스 가능한 매체를 포함하는 물품으로서,

상기 하나 이상의 명령들은, 실행된다면, 머신으로 하여금,

상기 네트워크 어플리케이션 프로그램에서 상기 신뢰 불가능한 전송으로의 선택된 네트워킹 호들을 상기 전송계층 보안으로의 네트워킹 호들로 대체하도록 네트워크 어플리케이션 프로그램을 수정하는 단계;

상기 신뢰 불가능한 전송을 상기 전송계층 보안과 양립할 수 있는 신뢰 가능한 전송으로 가장하기 위해서 네트워크 스택에서 상기 신뢰 불가능한 전송 위에 RDL(reliability dilibery layer)을 설치하는 단계; 및

상기 RDL을 이용하도록 상기 전송계층 보안을 구성하는 단계

를 수행하도록 하는 물품.
제21항에 있어서,

상기 연관된 명령들은, 실행된다면, 상기 머신으로 하여금,

상기 신뢰 불가능한 전송을 상기 전송계층 보안과 양립할 수 있는 것으로 가장하는 상기 RDL에 대하여 상기 네트워크 어플리케이션 프로그램으로부터의 보안 통신 세션을 수립하는 단계

를 수행하도록 하는 명령들을 더 포함하는 물품.