차세대 신뢰통신 연구동향

Trends in Trustworthy Communication for the Next-Generation

저자
김태환, 홍정하, 정희영 / ID통신연구실
권호
30권 4호 (통권 154)
논문구분
일반 논문
페이지
129-139
발행일자
2015.08.01
DOI
10.22648/ETRI.2015.J.300414
초록
현재의 인터넷은 40여 년 전에 신뢰할 수 있는 호스트 간의 통신을 기반으로 설계되어 식별성(Identity)과 기밀성(Privacy)등의 보안성에 대한 특별한 요구사항이 없었다. 추후 인터넷이 전 세계적으로 확장함에 따라 신뢰할 수 없는 호스트가 통신에 참여하게 되었고 이에 대한 보안 요구사항이 새롭게 등장하였다. 이러한 요구사항을 만족시키기 위한 인터넷의 보안 기술은 키(Key)에 매우 의존적으로 발전하여 현재 모든 인증 관련 기술과 보안 기술들은 공개키 기반 구조(Public Key Infrastructure: PKI)와 같이 키를 기반으로 하고 있다. 이러한 연구 동향은 미래인터넷의 보안 연구에서도 여전히 반영되어 미국에서 진행 중인 eXpressive Internet Architecture(XIA)나 다른 미래 인터넷 프로젝트에서도 키 기반의 보안기술 연구를 진행하고 있다. 하지만 모든 통신을 의심하고 이를 감시하기 위한 기존의 인터넷 보안 기술과 달리 미래인터넷 보안 연구는 상호 신뢰를 기반으로 네트워크에 대한 공격 자체를 원천적으로 차단할 수 있는 신뢰통신(Trustworthy communication)을 목적으로 하고 있으며 이에 대한 새로운 연구 결과가 등장하고 있다. 본고에서는 차세대 보안연구 분야인 신뢰통신의 연구동향과 성과를 소개하고 장단점을 분석한다. 특히 미래인터넷의 신뢰통신 연구 중 대중적으로 인정받고 있는 공개키를 이용한 자가인증(Self-certifying)과 이를 뒷받침하기 위한 공개키 검증 시스템 연구 및 신뢰경로 구축 연구를 중심으로 미래인터넷의 신뢰통신 연구가 진행된 과정을 중점적으로 소개한다.
   3035 Downloaded 3032 Viewed
목록

Ⅰ. 서론

1969년, 미국 국방부 산하의 고등연구계획국(Advanced Research Project Agency)은 컴퓨터들을 직접 연결하는 회선 교환 방식 대신, 대규모의 기간 통신망을 구축해 이에 연결된 컴퓨터끼리 자유롭게 데이터를 주고받을 수 있는 백본(backbone) 방식의 ARPANET을 구축하였다. 첫 기동 당시 ARPANET은 UCLA를 중심으로 스탠퍼드 대학교 등 4개의 대학 연구소가 참여하였다. 이후 참여 기관이 늘어나고 월드와이드웹(World Wide Web: WWW)이 성공을 거두며 인터넷은 눈부신 성장을 거듭했다. 하지만 인터넷의 폭발적인 성장과 동반하여 예상치 못했던 문제들이 드러나기 시작했는데 대표적인 문제가 보안 문제이다.

인터넷의 초기 설계 환경은 서로 잘 알고 있는 몇 개의 호스트들로 이루어진 작고 신뢰할 수 있는 환경(small and trustworthy environment)이었으나 대규모 네트워크로 확장되고 신뢰할 수 없는 호스트들이 참여하는 환경(global and trustless environment)으로 점차 변모하였다. 이에 따라 인터넷이 가진 구조적 불완전성으로 인해 점차 많은 보안 위협이 드러나게 되었는데 이는 네트워크 구조, 주소체계, 라우팅 프로토콜 등의 인터넷을 구성하는 핵심 기반 기술들이 최소화하여 설계되었기 때문이다. 즉, 현재의 IP계층은 패킷의 전달 기능만 담당하고 사용자 인증 및 전달되는 데이터의 무결성, 데이터 보호를 위한 암호화 기능은 응용 영역에서 수행하도록 설계되었다. 이러한 설계 구조에서 인터넷의 보안 기술은 스팸, 웜, DDoS 공격 등의 새로운 보안 위협이 발생할 때마다 응용 영역에서 시그니처 및 소프트웨어 패치 형식으로 시스템에 추가되는 형태로 발전했다. 이러한 기술의 한계를 근본적으로 극복하기 위해 네트워크 구조 자체를 새로이 설계하자는 미래인터넷 연구가 시작되었고 보안 기능을 네트워크에서 원천적으로 지원하기 위한 신뢰통신 연구가 요구되고 있으며 현재 다양한 분야에서 연구가 진행 중이다. 이를 위해 International Telecommunication Union Telecommunication Standardization Sector(ITU-T)에서는 미래인터넷에서 고려하여야 할 신뢰통신과 관련된 요구사항을 규정하였는데 주요 내용은 다음과 같다[1].

  • •  Authentication

    사용자, 디바이스, 네트워크 요소 등에 대해서 인 증이 가능한 인프라를 보유해야 함.

  • •  Access Control

    인증된 사용자에게만 접속을 허용하여야 한다. 인증된 사용자로 위장하여 침입하는 것에 대한 적절한 방어책을 가지고 있어야 함.

  • •  Data Confidentiality

    암호나 다른 수단에 의해서 사용자의 데이터에 대해 기밀성을 제공할 수 있어야 함.

  • •  Data integrity

    암호나 다른 수단에 의해서 사용자의 데이터에 대해 무결성을 제공할 수 있어야 함.

  • •  Availability

    서비스거부공격, 바이러스 및 웜 등과 같은 악성 코드의 공격을 차단하거나 방어할 수 있는 능력을 제공하여야 한다. 내부 네트워크 요소들은 바이러스, 웜, 기타 다른 공격 들을 신속하게 탐지하고 보안 정책에 위반되는 패킷이나 트래픽을 필터링할 수 있어야 함.

본고에서는 이러한 요구사항을 만족시키기 위한 차세대 신뢰통신에 관한 연구 중 인증 분야에서 널리 인정받고 있는 자가인증(Self-certifying)을 소개하고, 자가인증주소(Self-certifying address)를 응용하고 있는 Accountable Internet Protocol(AIP)에 대해 기술한다. 또한, 자가인증을 실행하기 위해 반드시 필요한 공개키 검증에 대한 연구와 신뢰 도메인 기반 네트워크 구조에서의 신뢰경로 구축에 관한 내용도 소개한다.

Ⅱ. 자가인증

미래인터넷에 대한 연구는 주소체계에 대한 고찰에서부터 시작했다. 현재 인터넷의 주소체계는 설계 시 잘못된 정의로 IP주소가 식별자(ID)와 위치자(Locator) 역할을 동시에 담당하게 되면서 이동성과(Mobility)과 확장성(Scalability)과 같은 문제를 야기했다. 그뿐만 아니라 식별자나 주소에 보안을 지원할 수 있는 기능을 전혀 내재하지 않아 위변조할 수 있어져 인증을 위한 추가적인 인프라가 필요하게 되었다.

주소체계에 대한 연구는 네트워크를 이루는 개체의 식별을 위한 식별자(ID)와 네이밍(naming)에 대한 연구와 그에 따른 어드레싱(addressing)에 대한 연구 등이 진행되어 왔다. 또한, 보안성을 내재하기 위해 주소체계나 식별자에 자가인증을 적용하려는 연구가 활발하게 이루어져 왔다. 본 장에서는 주소체계에서 자가인증의 의미와 역할에 대해 알아보고 이를 활용한 AIP를 소개한다.

1. 자가인증의 의미와 역할

자가인증(Self-certifying)이란 용어는 파일시스템에서 내부적인 키 관리 시스템 없이 키와 파일 이름을 맵핑할 수 있는 ‘self-certifying pathname’이 제안되면서 처음 사용되었다[2]. AIP에서는 같은 개념을 인터넷에 도입, 공개키를 인터넷 개체의 주소로 사용하면서 제3자의 도움 없이 자신을 인증할 수 있는 self-certifying address를 제안하였다[3]. 이후 식별자 기반 네트워크[4]에서는 자가인증식별자(Self-certifying ID), 콘텐츠 중심 네트워크[5]에서는 자가인증이름(Self-certifying name)으로 적용되는 등 인터넷의 다양한 분야에서 자가인증 메커니즘을 활용한 연구가 시도되고 있다.

콘텐츠 중심 네트워크(Content Oriented Network: CON)에서의 콘텐츠 명명법(naming)에 대한 연구[5]에서는 hierarchial/human-readable과 flat/self-certifying한 구조로 나누고 이들을 보안성과 확장성 측면에서 분석했다. 이를 위해 먼저 네이밍을 위한 다음과 같이 세 가지 오브젝트(Object)와 이들의 관계에 대해 정의했다.

- Real World Identity(RWI): 콘텐츠의 생성자(출판인 혹은 조직)

- Name: 콘텐츠의 이름

- Public Key: 콘텐츠 생성자의 공개키

특정 콘텐츠를 식별하기 위해서 위의 세 개체가 모두 서로 바인딩되어야 하고 이를 위하여 최소 두 개의 바인딩이 필요하다고 주장한다. (그림 1)은 이 세 가지 개체 간의 바인딩 관계를 나타낸 것이다. Human-readable name은 Name과 RWI 사이를 바인딩하고 나머지 Public Key와 이름과의 바인딩(점선 2)은 외부 메커니즘이 필요하다. Self-certifying name은 Name과 공개키의 ‘strong binding’ 관계를 나타내고 나머지 RWI와 Public Key 사이의 바인딩(점선 1)을 위해서는 또 다른 메커니즘이 필요하다고 제시했다. 이를 토대로 내린 결론은 다음과 같다.

(그림 1)

명명법에서의 세 가지 오브젝트와 바인딩 관계[5]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f001.jpg

첫째, 자가인증이름은 콘텐츠에 대한 인증을 가능하게 함으로써 콘텐츠 기반 서비스거부(Denial of Service: DoS)에 대한 대응방안을 마련할 수 있게 한다. 특정 이름에 개체(혹은 콘텐츠)가 적절하게 바인딩 되기 위해서는 반드시 키와 이름 사이에 바인딩이 이루어져야 하는데 자가인증식별자는 내재적(intrinsic)으로 이 둘 사이의 ‘strong binding’기능을 수행한다.

둘째, 확장성(scalability) 보장을 위해서 이름은 어떤 식으로든 통합(aggregation)이 되어야 하는데 내재적으로 구조를 갖는 hierarchical name보다는 flat name이 통합에 있어서 더 유연(flexible)하다고 주장했다. 그 예로 ‘P:L’ 형식의 자가인증이름구조(naming format)를 이용하여 몇 개의 네임을 concatenation하는 통합 방법을 제시했다. 여기서, P는 콘텐츠 생성자(출판자)의 공개키이고 L은 그 생성자가 게시한 콘텐츠의 라벨(Label)이다.

이를 토대로 여러 명명법 중에 자가인증이름이 보안성, 확장성, 및 유연성 측면에서 더 좋은 선택이라고 주장했고, 이러한 주장은 CON뿐만 아니라 다른 네트워크 구조[4][6]에서도 상당히 설득력을 얻고 있다.

2. Accountable Internet Protocol

AIP[3]는 자가인증주소(Self-certifying address)를 이용하여 호스트의 주소를 제3자의 도움 없이 인증할 수 있는 프로토콜을 제공한다. 이를 통해 호스트의 네트워킹 행위에 대해 차후 책임을 물을 수 있는 미래인터넷 구조이다. 이것은 인증기능을 지원하지 않아 IP주소의 위변조가 가능하여 보안사고의 책임을 물을 수 없는 현재 인터넷과는 상당히 대조적이다.

AIP 네트워크 구조는 호스트와 호스트로 이루어진 도메인으로 구성되는데 각각 별도의 공개키/개인키 쌍이 할당되며, 공개키에 대한 해쉬 값이 호스트와 도메인의 식별자로 사용된다. (그림 2)는 AIP의 네트워크 구조와 주소체계를 나타내고 있다. 여기에서 Autonomous Domain(AD)는 호스트가 속해 있는 자치 도메인을 나타내는 식별자이며 해당 도메인 공개키의 해쉬 결과이다. Endpoint Identifier(EID)는 전역적으로 유일한 호스트 식별자이며 호스트의 공개키에 대한 해쉬 값으로 결정된다. 이를 토대로 호스트는 AD와 EID의 식별자로 이루어진 AD:EID 형태의 자가인증주소를 가지며 이러한 주소체계는 다른 인증 기관의 도움 없이 주소의 진위를 검증할 수 있다.

(그림 2)

AIP 네트워크 구조와 주소체계[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f002.jpg

AIP의 패킷 근원지 검증(source verification)은 EID 검증과 AD 검증, 두 부분에서 수행한다. 먼저 EID 검증은 (그림 3)과 같이 호스트에서 외부 네트워크로 나가는 첫 번째 홉 라우터 R에서 수행한다. 또한, 검증 효율을 높이기 위해 R은 자신이 이전에 검증한 호스트 목록을 캐쉬로 저장하여 검증된 호스트에서 발신한 패킷은 검증절차 없이 다음 홉으로 포워딩한다. EID검증절차는 다음과 같다.

(그림 3)

EID 검증 과정[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f003.jpg

(1) R이 검증하지 않은 호스트로부터 전송되는 패킷 P를 수신하면, 수신한 패킷을 폐기하고 검증패킷(verification packet) V를 해당 호스트에게 전송한다. 검증패킷 V에는 R이 소스 호스트로부터 수신하여 폐기한 패킷 P의 소스와 목적지의 주소, 패킷의 해쉬 값, 그리고 패킷을 수신한 R의 인터페이스 정보가 포함된다. R은 V를 자신의 개인키로 서명하여 자신이 보낸 것을 인증한다.

(2) V를 수신한 호스트는 소스 호스트의 공개키와 V의 정보를 자신의 개인 키를 이용하여 서명하고 라우터 R에게 자신이 EID의 소유자임을 증명한다.

(3) R은 호스트로부터 수신한 서명이 유효하다고 판단되면, 호스트에 대한 정보를 등록하고 이 이후부터 소스 호스트로부터 전송되는 패킷을 다음 홉으로 전송한다.

(4) 호스트는 R이 폐기한 패킷을 재전송한다.

AD검증은 소스 호스트로부터 전송된 패킷이 AD의 경계를 지나는 경우 수행된다. 만일 패킷을 전달받은 AD가 전달한 AD를 신뢰하는 경우 바로 패킷을 포워딩하지만 그렇지 않은 경우, 일차적으로 ‘역 경로’ 인터페이스가 같은지를 판단하여 unicast Reverse Path Forwarding(uRPF) 포워딩 여부를 결정하고, 비대칭 경로라고 판단한 경우 EID 검증과 같은 방법을 이용하여 수신한 패킷에 대해 검증한다[(그림 4) 참조].

(그림 4)

AD 검증 과정[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f004.jpg

AIP의 자가인증주소는 호스트 또는 도메인 주소의 위변조를 막고 제3자의 도움 없이 인증할 수 있는 프로토콜을 가능하게 했다. 이 프로토콜은 라우터에서 유입되는 패킷의 근원지를 검증하여 검증된 패킷만 다음 홉으로 포워딩함으로써 근원지 주소가 위조된 패킷의 유통을 원천적으로 차단한다. 이것은 기존 IP네트워크에서 스푸핑(spoofing)을 방지하고 패킷의 근원지 주소를 역추적하기 위해 제시된 패킷마킹(packet marking)[7]이나 path fingerprint[8]와 같은 방식에 비해 훨씬 효율적이고 네트워크에 내재적인 메커니즘이다. AIP는 이러한 특성을 기반으로 Shut Off Protocol(SOP)와 같은 추가적인 보안 메커니즘을 제안하였다. SOP는 특정 DoS 공격에 대한 대응책으로, 호스트나 서버는 SOP를 이용하여 원치 않는 트래픽을 제어할 수 있다. 프로토콜 동작은 (그림 5)와 같다.

(그림 5)

Shut-off 프로토콜[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f005.jpg

(1) 좀비 C는 호스트 A로 공격패킷 P를 발송한다.

(2) 호스트 A는 이를 감지하고 C로 SOP 패킷을 전송한다. SOP 패킷에는 C가 발송한 공격패킷 P의 해쉬, TTL값이 호스트의 개인키로 서명되어 전송된다.

(3) SOP 패킷을 받은 C는 A의 서명을 통해 호스트 A가 보낸 패킷임을 검증하고 A가 요청한 TTL 시간 동안 패킷을 보내지 않는다.

SOP는 AIP의 자가인증주소와 주소위변조방지(anti-spoofing) 기능을 결합한 메커니즘으로 이를 통해 다음 두 가지 사실을 반증한다. 첫째, 공격패킷 P는 좀비 C에게서 발송된 것이다. AIP에서는 주소의 위변조가 불가능함으로 위 사실을 확인할 수 있다. 둘째, 좀비 C가 수신한 SOP 패킷은 공격받은 호스트 A가 발송한 것이다. 호스트 A가 발송한 SOP 패킷은 개인키로 서명되어 있으므로 이를 증명할 수 있다.

SOP는 추가적인 인프라 없이 이 두 가지 사실을 증명함으로써 DoS 공격을 차단하는 메커니즘을 제공한다. 하지만 SOP는 아주 특정한 DoS 공격에 극히 부분적으로 적용할 수 있는 한계를 가지고 있다.

첫째, 공격 중에 호스트가 SOP 패킷을 보낼 수 있는 여력이 있어야 한다. DoS 공격을 탐지하고도 부하로 인해 SOP 패킷을 좀비에게 보낼 여력이 없으면 SOP가 동작할 수 없기 때문이다.

둘째, SOP 패킷을 받았음에도 불구하고 공격을 멈출 것인지 지속할 것인지는 전적으로 좀비에 달려 있으므로 ‘well-intentioned host’ 즉, 의도를 가지고 공격을 수행하는 좀비는 얼마든지 SOP 패킷을 무시하고 공격을 지속할 수 있다.

셋째, 호스트는 DoS 공격을 탐지하고 어느 소스에서 발송된 패킷이 DoS 공격패킷인지 구분할 수 있어야 한다. DoS 공격을 탐지하는 메커니즘은 매우 많이 연구되었지만 DoS 패킷을 식별하는 문제는 정상 패킷과 구분이 매우 힘들다는 점에서 받아들이기 쉽지 않은 가정이다. 결론적으로, AIP가 사용자 인증에 대해 자가인증주소를 사용함으로써 추가적인 인프라 없이 수행할 수 있다는 것은 분명하나, 인증 이외의 SOP가 가져다주는 보안 효과는 크지 않다.

Ⅲ. 공개키 검증

AIP가 자가인증주소를 사용해서 인증에 대한 문제를 해결했지만, AIP가 동작하기 위해 가정하고 있는 호스트의 자가인증주소 또는 자가인증주소로 사용되는 공개키가 호스트 것인지 확인할 수 있는 메커니즘은 제공하지 않는다. 따라서 호스트 A의 공개키를 호스트 B가 자신의 자가인증주소로 사용하여 A로 위장이 얼마든지 가능하다(이는 Man in the Middle(MitM) 공격과 같은 보안상 심각한 위협이 된다). AIP와 같은 공개키 기반의 자가인증주소를 사용하기 위해서는 이와 같은 취약성은 반드시 해결해야 하는 문제이다. 현재 인터넷에서는 Public Key Infrastructure(PKI)를 기반의 공인된 Certificate Authority(CA)가 발행한 인증서를 통해 공개키의 소유자를 인증함으로써 이러한 취약성에 대한 대응방안을 제공한다. 하지만 공개키 기반구조에서 완전하게 신뢰할 수 있다고 가정해야만 하는 CA 자체에 취약성이 존재하여 끊이질 않고 보안사고가 발생하고 있다[9]. PKI는 크게 세 가지의 취약성을 가지고 있다.

(1) 사용자가 너무 많은 CA를 신뢰한다. 일반적으로 브라우저가 신뢰하는 CA의 수가 많아질수록 인증서에 대한 보안위협도 함께 증가한다. 이는 하나의 CA가 보안성을 상실하게 되면 그 CA가 발급한 인증서를 사용하는 모든 사용자는 물론이고 해당 CA를 신뢰하는 사용자의 보안성이 위협받기 때문이다.

(2) 잘못 발행된 인증서는 MitM 공격에 이용될 수 있다. CA가 과실로 사용자 A에게 사용자 B의 인증서를 발행하거나 공격자의 의도로 다른 사람의 인증서를 발급하게 되면 B의 인증서를 발급받은 공격자 A는 B와의 통신을 원하는 다른 사용자에게 B의 행세를 할 수 있게 된다.

(3) 인증서의 발급과 관리에 대한 모든 책임을 지고 있는 CA 보안 능력이 부족하다. CA의 비밀키가 탈취되면 공격자의 의도대로 잘못된 인증서를 신규로 발급하거나 기존의 정상적인 인증서를 폐기, 재발급할 수 있다. 이는 현재 인터넷에 인증체계의 근간을 흔들 수 있는 심각한 보안 위협이다.

이러한 인증서, 즉 공개키에 대한 인증서의 보안위협은 현재 인터넷은 물론이고 공개키를 자가인증주소로 사용하는 AIP와 같은 많은 미래인터넷 구조에도 존재한다. 본 장에서는 위와 같은 위협에 대응하기 위한 공개키 검증 시스템에 대한 연구들을 소개하고 각각의 장단점을 분석한다.

1. AKI

Accountable Key Infrastructure(AKI)[10]는 AIP의 주소체계를 활용하는 Scalability, Control, and Iso-lation On Next-generation networks(SCION)[6]의 하위 프로젝트로 공개키 검증을 위한 새로운 인프라를 제안했다. AKI는 기존 PKI의 취약성인 ‘single point failure’ 즉, CA가 침해당하면 인증서 전체가 위협받는 단점을 극복하기 위한 인프라이다. AKI는 CA의 역할을 분산시키기 위해 기존의 CA 이외의 Integrity Log Server(ILS)와 Validator라는 시스템을 추가적으로 구성하였으며 구성요소 간의 발생하는 비정상적인 인증서 트랜잭션에 대한 감시 체계를 마련했다. 이로써 CA가 가지고 있었던 취약성에 ‘check and balance’의 대응 수단을 제시했다. 아래는 AKI를 구성하는 개체들에 대한 정의이다.

  • •  Client(browser)

    서버 혹은 도메인에 접속하여 서비스를 이용하려는 개체

  • •  Domain(server)

    client가 Transport Layer Security(TLS) 컨넥션을 맺고 궁극적으로 통신하려는 개체

  • •  Certificate Agency(CA)

    기존의 인증기관(Certificate Authority)과 유사하다. 인증서를 발급하지만 인증서에 관련된 모든 권한을 가지지는 않음.

  • •  ILS

    Domain이 CA로부터 발급받은 인증서를 검증하여 AKI 인증서를 발급, 보관하고 관련 연산에 대한 모든 로그 정보들을 기록하고 관리하는 시스템

  • •  Validator

    ILS에서 수행하는 모든 인증서의 발급, 폐기, 갱신 등의 연산들을 모니터링하는 시스템

(그림 6)은 A.com 도메인이 AKI 인증서를 발급받는 과정을 나타낸다. 인증서 발급과정은 다음과 같다.

(그림 6)

AKI의 구조와 인증서 발급과정[10]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f006.jpg

(1) 정책수립: AKI인증서는 X.509 인증서를 기본으로 다음과 같은 추가적인 확장자를 정의한다.

CA_LIST: trusted CAs for creating a new certificate

ILS_LIST: trusted ILSs where the certificate is registered

ILS_TIMEOUT: ILS validation proof timeout (varies from one hour to one day)

CA_MIN: minimum number of CAs to generate an AKI certificate (typically set to 1 or 2)

CA_TH: threshold number of CAs for certificate re-establishment (set CA_TH=CA_MIN+1)

(2) CA인증서 획득: AKI 인증서에 명시된 CA_LIST에 중 CA_MIN 이상의 CA에게 A.com 도메인의 공개키에 대한 인증서를 발급받고 AKI인증서를 작성한다(CertAKI={Cert1║Cert2║…║Certn}).

(3) ILS 등록: AKI 인증서를 신뢰하는 하나 이상의 ILS에 등록한다. ILS는 A.com 도메인이 작성한 AKI인증서의 정책과 파라메터들을 확인한 후 이상이 없으면 자신의 인증서 데이터 구조(integrity tree)에 저장한다.

(4) AKI인증서 획득: ILS는 AKI인증서에 대한 확인과 저장이 완료되면 Integrity Tree의 root값과 AKI인증서에 자신의 개인키로 서명하고 도메인에게 전달한다. Validator는 위의 모든 과정을 모니터링하고 비정상적인 트랜잭션이 발생하는지 감시한다.

(5) 브라우저가 A.com에게 TLS 컨넥션을 요청한다.

(6) A.com은 도메인에게 ILS로부터 받은 AKI 인증서와 root값을 브라우저로 전송한다.

(7) 브라우저는 Validator에게 A.com으로 받은 root값이 맞는지 확인함으로써 A.com의 인증서를 검증한다.

AKI는 CA가 발급한 인증서 여러 개를 합친 AKI 인증서를 제시함으로써 하나의 CA가 침해 당하더라도 AKI 인증서를 위협할 수 없도록 하였다. 또한, AKI 인증서 관련 모든 트랜잭션은 전자서명을 요구하고, Validator에 의해 모니터링됨으로 위협에 즉각적인 대응을 가능하게 했다.

AKI의 또 다른 특징 중 하나는 ILS 내의 AKI인증서가 저장되는 데이터 저장 구조이다[(그림 7) 참조]. 이진 해쉬트리 기반의 Integrity tree구조는 최하단의 리프노드에 AKI인증서 데이터를 저장하고 그 상위 노드는 아래의 자식노드 데이터의 해쉬값으로 결정되는 방식이다. 따라서 최상위 root값만을 확인함으로써 해쉬트리에 저장된 모든 데이터에 대한 검증을 가능하게 한다. 또한, root값이 바뀌어 데이터 변조가 확인된 경우에는 해당 데이터의 상위 노드들 즉, 총 데이터 개수(n)의 로그(logn)만큼의 데이터 확인만으로 어느 데이터 블록이 변조되었는지를 확인할 수 있다. 이러한 해쉬트리 기반의 데이터 구조는 대규모 인증서 관리에 대한 매우 효율적인 방법을 제공하고 데이터 변조에 대해 빠르게 대처할 수 있게 한다.

(그림 7)

ILS의 AKI 인증서 저장구조[10]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f007.jpg

AKI는 분산 구조를 통해 공격자가 AKI를 구성하는 특정 개체의 개인키나 권한을 불법적으로 확보하더라도 인증서 자체에 대한 신뢰성을 유지시키는 인프라이다. PKI에서 단순히 CA의 권한을 잠시 확보하는 것으로 인증서 전체에 대한 위협이 가능했던 반면, 같은 위협을 가하기 위해서 AKI에서는 구성하는 모든 개체의 권한을 얻지 않고서는 불가능하다. 하지만 인증서 관련 모든 트랜잭션에 전자서명이 필요하고 각각의 개체들이 서로를 모니터링해야 하는 오버헤드는 AKI가 안고 있는 단점이다.

2. DANE

DNS based Authentication of Named Entities(DANE)은 DNS 시스템을 기반으로 하는 공개키 검증 메커니즘이다. 도메인은 사전에 자신의 인증서 정보를 DNS에 TLSA record 형태로 등록하고 클라이언트가 해당 도메인에 대한 DNS 질의가 오면 IP주소와 함께TLSA record를 제공하여 인증서를 검증하는 방식이다. 또한, TLSA record에 대한 무결성 검증을 위해 Domain Name System Security Extension(DNSSEC)을 이용한다. (그림 8)에서 클라이언트는 DNS에게 ‘www.example. com’에 대한 질의를 보내고 DNS는 해당 도메인의 IP주소와 www.example.com에 대한 인증서 정보인 TLSA record도 함께 전송한다. 그 후 클라이언트는 도메인과의 TLS 컨넥션을 맺을 때 도메인의 인증서를 DNS에게 받은 TLSA record와 비교함으로써 인증서를 검증하는 방식이다.

(그림 8)

DANE에서의 TLS 인증절차[11]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f008.jpg

DANE은 AKI와 달리 인증서 검증 즉, 공개키 검증에서 추가적인 인프라를 도입하는 대신 이미 존재하고 있는 DNS에 도메인에 대한 인증서 정보를 추가함으로써 이를 해결했다. 현재 DANE은 IETF에서 표준화 작업이 진행 중이다[11].

Ⅳ. 신뢰경로

SCION[6]은 네트워크를 서로 독립적인 신뢰 도메인 Trust Domain(TD)으로 구성하고 이것을 통하여 종단 간(end to end) 통신 체계에서 ① 루트 제어(route control), ② 실패고립(failure isolation), ③ 경로에 대한 명시적 신뢰 정보(explicit trust information)를 제공하기 위하여 디자인된 최초의 인터넷 아키텍처이다. 이러한 SCION의 세 가지 디자인 목적은 패치 온(patch on) 형태의 어떠한 보안 메커니즘 없이 네트워크의 구조를 통하여 회복력(resilience), 보안성(security), 및 신뢰성(reliability)을 내재적으로 제공하기 위함이다.

SCION에서 신뢰 도메인은 서로 신뢰할 수 있는 개체인 AD들로 구성되는데 이들은 그 도메인만의 공통된 정책을 가진다. 또한, (그림 9)와 같이 하나의 신뢰 도메인 내에는 또 다른 하위 신뢰 도메인을 가질 수 있는 계층적 구조로 이루어진다.

(그림 9)

SCION의 신뢰 도메인 구조[6]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f009.jpg

신뢰 도메인을 구성하는 AD들 중 다른 신뢰 도메인들과의 인터페이스 역할을 하는 AD들을 TD Core(검정색 노드)로 지정하고 이를 통해서 도메인 내의 통신과 다른 도메인과의 통신을 수행한다. 이러한 신뢰 도메인 기반의 네트워크 구조는 신뢰할 수 없는 개체들이 다른 도메인으로 분리되기 때문에 신뢰 도메인 외부의 개체들이 도메인 안으로 허가되지 않은 어떠한 행위도 할 수 없게 된다.

SCION 구조의 또 다른 특징 중 하나는 소스 라우팅을 기반으로 하는 신뢰경로 구축이다. 신뢰경로는 Path Construction Beacons(PCB)에 의해 구축되는데 이것들은 하나의 도메인 내에서 TD Core부터 시작하여 1홉씩 전달되어 도메인 내의 모든 AD들에게 전달된다. 각각의 AD들은 PCB를 수신하면 소정의 인증 절차를 거쳐서 PCB에 자신의 인증 정보를 포함시킨 후 다음 AD에게 전달한다. 이를 통해 도메인 내의 모든 AD 대한 인증을 수행하고 이 정보를 기반으로 각각의 AD는 TD Core로부터 자신까지의 모든 경로 정보를 획득할 수 있다. AD로부터 TD Core로의 경로(up-path)는 각각의 AD가 저장하고 AD가 패킷을 발송할 때 여러 up-path 중에서 하나를 선택하여 사용할 수 있다. 즉, AD는 자신의 up-path 경로 중 원하지 않는 AD가 포함된 경로를 배제하여 선택할 수 있다. TD Core에서 AD로의 경로(down-path)는 패킷을 수신할 경로로 사용되며, down-path는 TD core의 패스 서버(path server)에 저장된다. 또한, 각각의 AD들은 PCB에 의하여 생성된 자신과 TD core 사이의 경로 중, 몇 개의 up-paths/ down-paths를 독립적인 세트로 선택하고 관리한다. 이를 바탕으로 AD가 소스 라우팅을 하는 방식은 다음과 같다.

ADS가 ADD로 패킷을 전송할 때 ADS는 먼저 자신의 up-path set에서 하나를 택하고 name 또는 address lookup을 통하여 ADD의 down-path set를 얻게 된다. 그 중에서 ADS는 하나만 선택을 하여 완전한 종단 간 패스를 형성하게 된다. 만일 도메인 내의 통신인 경우에 ADS는 up-path와 down-path를 합치기 전에 두 패스가 공통으로 가지는 AD가 있는지를 먼저 확인하여 shortcut이 있는지를 확인한다. (그림 9)의 AD1과 AD2 사이의 shortcut이 한 예이다. 반대로, ADD가 ADS로 패킷을 보낼 때, ADD는 ADS가 전송한 경로의 reverse 경로를 이용하거나 ADS가 수행한 경로 설정 과정을 똑같이 수행하여 또 다른 패스를 형성할 수도 있다. 따라서, SCION에서는 패킷 전송 전에 신뢰경로를 설정하고 경로 정보가 모두 패킷 헤더에 삽입되기 때문에 라우팅과 포워딩 테이블이 요구되지 않는다.

이러한 SCION의 신뢰 도메인을 기반으로 하는 네트워크의 구조적 특징과 발신지에서 자신이 전송할 패킷의 전체 경로를 설정할 수 있는 신뢰경로 구축을 통해 네트워크 내의 신뢰성을 향상시켰다.

Ⅴ. 결론

본고에서는 미래인터넷 분야에서 신뢰통신에 대한 연구동향을 살펴보고 몇몇 대표적 연구성과에 대해 분석하였다. 인터넷에 신뢰통신을 구현하기 위한 첫 번째 단계로 인증 문제를 들 수 있는데 AIP는 자가인증주소를 이용하여 인증 구조를 네트워크에 내재시켰다는 점에서 그 의미와 성과가 매우 크다. 현재 진행 중인 많은 미래인터넷 프로젝트에서 인증에 대한 문제는 AIP를 도입하여 해결하고 있다.

미래인터넷의 인증 문제를 해결할 방법의 하나인 AIP의 자가인증 메커니즘에는 공개키와 공개키 소유자 사이의 관계에 대한 검증이 필수적이다. 이에 대한 연구는 공개키 검증 시스템이라는 주제로 연구되고 있으며 본고에서는 새로운 공개키 검증 인프라를 제안한 AKI와 기존 DNS 인프라를 활용한 DANE을 소개하였다. 또한, 네트워크 구조를 신뢰 도메인이라는 개념을 도입하여 신뢰경로를 구축하고 소스 라우팅 기법을 제안한 SCION에 대해서도 알아보았다.

미래인터넷의 신뢰통신을 위한 보안 기능은 기존의 네트워크 위에 별도로 추가되는 형태가 아니라, 반드시 네트워크 자체에서 내재된 형태로 제공되어야 한다. 이러한 관점에서 AIP나 SCION과 같은 연구는 각각 인증과 신뢰경로 구축이라는 보안 기능을 네트워크에서 구조적으로 제공할 수 있는 아키텍처라고 평가받는다. 차세대 신뢰통신을 위한 연구는 이러한 접근 방식을 통해 문제를 해결해 나가야 할 것이며 앞으로도 이러한 접근 방식을 통한 창의적인 연구 성과가 요구된다.

약어 정리

AD

Autonomous Domain

AIP

Accountable Internet Protocol

AKI

Accountable Key Infrastructure

CA

Certificate Authority

CON

Content Oriented Network

DANE

DNS based Authentication of Named Entities

DNSSEC

Domain Name System Security Extension

DoS

Denial of Service

EID

Endpoint Identifier

ILS

Integrity Log Server

ITU-T

International Telecommunication Union Telecommunication Standardization Sector

MitM

Man in the Middle

PCB

Path Construction Beacons

PKI

Public key Infrastructure

RWI

Real World Identity

SCION

Scalability, Control, and Isolation On Next-generation networks

SOP

Shut Off Protocol

TD

Trust Domain

TLS

Transport Layer Security

uRPF

unicast Reverse Path Forwarding

ToS

Type of Service

XIA

eXpressive Internet Architecture

[1] 

ITU-T Y.2701, “Security Requirements for NGN Release 1,” 2008.

[2] 

D. Mazières et al, “Separating Key Management from File System Security,”Operating Systems Review, vol. 34, no. 5, Dec. 1999, pp.124-139.

[3] 

D.G. Andersen et al, “Accountable Internet Protocol,”ACM SIGCOMM, 2008.

[4] 

A. Anand et al, “XIA: An Architecture for an Evolvable and Trustworthy Internet,” Proc. 10th ACM Workshop on Hot Topics in Networks, 2011.

[5] 

A. Ghodsi et al, “Naming in Content-Oriented Architectures,” Proc. ACM SIGCOMM, 2011.

[6] 

X. Zhang et al, “SCION: Scalability, Control, and Isolation on Next-Generation Networks,” IEEE Security Privacy, 2011.

[7] 

R. Chen et al, “Thwarting Distributed Denial of Service Attacks,” IEEE Trans. Parallel Distrib. Syst., vol. 18, no. 5, 2007.

[8] 

F.-Y. Lee and S. Shieh, “Defending Against Spoofed DDoS Attacks with Path Fingerprint,” Computers & Security, vol. 24, no. 7, 2005.

[9] 

N. Gruschka, L.L. Lacono, and C. Sorge, “Analysis of the Current State in Website Certificate Validation,” Security and Communication Networks, vol. 7, no. 5, 2014, pp. 865-877.

[10] 

T. Kim et al, “Accountable Key Infrastructure (AKI): A Proposal for a Public-Key Validation Infrastructure,” Proc. 22nd International World Wide Web Conference, 2013.

[11] 

T. Jämsä, “DNS-Based Authentication of Named Entities,” 2013, https://dspace.cc.tut.fi/dpub/bitstream/ handle/123456789/22253/Jamsa.pdf

(그림 1)

명명법에서의 세 가지 오브젝트와 바인딩 관계[5]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f001.jpg
(그림 2)

AIP 네트워크 구조와 주소체계[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f002.jpg
(그림 3)

EID 검증 과정[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f003.jpg
(그림 4)

AD 검증 과정[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f004.jpg
(그림 5)

Shut-off 프로토콜[3]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f005.jpg
(그림 6)

AKI의 구조와 인증서 발급과정[10]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f006.jpg
(그림 7)

ILS의 AKI 인증서 저장구조[10]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f007.jpg
(그림 8)

DANE에서의 TLS 인증절차[11]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f008.jpg
(그림 9)

SCION의 신뢰 도메인 구조[6]

images_1/2015/v30n4/ETRI_J003_2015_v30n4_129_f009.jpg
Sign Up
전자통신동향분석 이메일 전자저널 구독을 원하시는 경우 정확한 이메일 주소를 입력하시기 바랍니다.