KR100964350B1 - ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템 - Google Patents

ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템 Download PDF

Info

Publication number
KR100964350B1
KR100964350B1 KR1020070093807A KR20070093807A KR100964350B1 KR 100964350 B1 KR100964350 B1 KR 100964350B1 KR 1020070093807 A KR1020070093807 A KR 1020070093807A KR 20070093807 A KR20070093807 A KR 20070093807A KR 100964350 B1 KR100964350 B1 KR 100964350B1
Authority
KR
South Korea
Prior art keywords
block
authentication
ipsec
address
host
Prior art date
Application number
KR1020070093807A
Other languages
English (en)
Other versions
KR20090028310A (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 KR1020070093807A priority Critical patent/KR100964350B1/ko
Priority to US12/040,355 priority patent/US8819790B2/en
Publication of KR20090028310A publication Critical patent/KR20090028310A/ko
Application granted granted Critical
Publication of KR100964350B1 publication Critical patent/KR100964350B1/ko

Links

Images

Classifications

    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—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)
  • Small-Scale Networks (AREA)

Abstract

본 발명은 IPv6환경에서 SEND 블록과 IPSec 블록 간의 협업 시스템 구현 방법에 관한 것이다. 본 발명에 따른 IPv6환경에서 SEND 블록과 IPSec 블록 간의 협업 시스템 구현 방법은 상기 SEND 블록에 의해 인증 완료된 호스트의 제1 IP 주소를 포함하는 인증 완료 보고 메시지를 수신하는 단계; 상기 호스트에 대한 인증 정보가 소정의 임시 기록 영역에 존재하지 않는 경우, 상기 호스트에 상응하는 새로운 인증 정보를 생성하여 상기 임시 기록 영역에 저장하는 단계-여기서, 인증 정보는 상기 제1 IP 주소를 포함함-; 및 상기 IPSec 블록으로부터 제2 IP 주소를 포함하는 인증 검사 요구 메시지를 수신하는 경우, 상기 제2 IP 주소가 상기 임시 기록 영역에 존재하는지 여부를 확인하고, 상기 확인 결과를 상기 IPSec 블록으로 송신하는 단계를 포함하는 것을 특징으로 한다. 따라서, 본 발명은 네트워크 접속이 빈번한 모바일 환경에서 SEND 블록과 IPSec 블록 간에 인증 정보를 공유함으로써, 보다 적은 비용으로 IPSec 보안 통신을 수행하는 것이 가능한 IPv6환경에서의 SEND 블록과 IPSec 블록 간의 협업 방법을 제공하는 장점이 있다.
Figure R1020070093807
IPv6, IPSec, SEND, 인증, 보안, 공개키

Description

ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및 시스템{Cooperation Method and System between the SEND mechanism and the IPSec Protocol in IPv6 Environments}
본 발명은 모바일 환경에서의 보안 및 인증 방법에 관한 것으로서, 좀 더 상세하게는, 모바일 IPv6 환경에서 SEND 프로토콜과 IPSec 프로토콜 간의 협업 체계를 구축함으로써 보다 강력하고, 효율적인 인증 절차를 제공하는 것이 가능한 IPv6 환경에서의 인증 및 보안 방법에 관한 것이다.
특히, 본 발명은 네트워크 진출입이 빈번한 모바일 환경에서 SEND 프로토콜과 IPSec 프로토콜 간에 인증 정보를 공유함으로써, 비용 효율적으로 IPSec 보안 통신을 수행하는 것이 가능한 IPv6 환경에서의 인증 및 보안 시스템에 관한 것이다.
최근들어 유선망에 고정된 호스트들이 연결되던 고전적 형태의 인터넷은 유선망과 무선망이 연동되고 노드가 망 사이를 옮겨 다니며 통신을 수행하는 이동 노드를 지원할 수 있도록 진화하고 있다.
인터넷에서 이러한 단말의 이동성을 지원하기 위해서 개발된 프로토콜이 Mobile IP이다.
특히, Mobile IPv6 기술은 IP 계층 상위의 프로토콜에 투명하게 동작하며, 활성화된 TCP 연결과 UDP 포트 바인딩을 끊김이 없도록 유지함으로써, IPv6 호스트의 이동성을 제공하는 기술이다.
특히, 현재 이동 통신의 양대 표준 기구인 3GPP(3rd Generation Partnership Project)와 3GPP2의 표준에서는 이동 인터넷 환경의 표준으로 Mobile IPv6를 채택하였다.
이는 Mobile IPv6 기술이 이동 통신의 최대 단점이라고 할 수 있는 정보 보호 기능을 안정적으로 제공하고, 충분한 주소 공간의 확보로 인한 각종 전자 제품의 효율적인 네트워크화를 가능하게 하며, 플러그&플레이 방식의 자동 네트워킹 방식 지원 및 최적화된 라우팅 패스 설정을 통한 효율적인 네트워킹 방법 등을 제공할 수 있기 때문이다.
IPv6 프로토콜에서는 IP 통신의 보안을 위하여 IP Security(IPSec) 프로토콜을 기본 보안 메커니즘으로 포함하고 있다. 또한 IPv6 프로토콜에서는 네트워크에 진입하거나, 라우터를 찾고, 이웃의 다른 호스트를 찾기 위해 사용되는 Neighbor Discovery(ND) 프로토콜의 보안을 위하여 Secure ND(SEND) 프로토콜을 정의하였다.
현재 Mobile IPv6와 관련된 주요 해결 과제는 보안 문제에 집중되고 있으며, 이에 따라 많은 문제점들이 해결되고 있는 상황이다.
하지만, 종래에는 두 보안 메커니즘-즉, IPSec 프로토콜 및 SEND 프로토콜을 의미함-이 동시에 사용될 경우, 동일한 호스트에 대하여 인증을 중복으로 수행하는 문제가 발생했다.
또한, SEND 프로토콜에서는 보안을 위해 사용하는 IP 주소를 주기적으로 바꿀 수 있으며, 이런 특성에 따라 SEND 프로토콜을 이용하여 통신하는 환경에서는 기존의 IPSec 블록을 그대로 사용하면 주소가 변경될 때마다 보안 협약을 다시 수행해야 하는 단점이 있었다.
상기와 같은 종래 기술의 문제점을 해결하기 위한 본 발명의 목적은 SEND 블록과 IPSec 블록이 모두 사용되는 IPv6 환경에서 SEND 프로토콜에 의해 생성된 인증 정보를 IPSec 프로토콜과 공유하고, IPSec 블록에서는 공개키를 이용하여 상대 호스트를 인식하는 것이 가능한 모바일 인터넷 환경에서의 사용자 인증 방법 및 그 시스템을 제공하는 것이다.
본 발명의 다른 목적은 모바일 인터넷 환경에서 SEND 블록과 IPSec 블록의 협업에 따른 불필요한 인증 절차를 제거함으로써, 보다 빠르고 효율적인 인증 방법 및 그 시스템을 제공하는 것이다.
본 발명의 다른 목적은 SEND 블록과 IPSec 블록 간의 협업 기법이 적용된 호스트와 적용되지 않은 호스트가 공존하는 네트워크 환경에서도 호스트 간 인증이 가능한 협업 시스템을 제공하는 것이다.
본 발명의 다른 목적들은 이하의 실시예에 대한 설명을 통해 쉽게 이해될 수 있을 것이다.
본 발명의 일 실시예에 따르면, IPv6 환경에서 SEND 블록과 IPSec 블록 사이의 협업 방법이 제공된다.
본 발명의 일 실시예에 따른 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법은 상기 SEND 블록에 의해 인증 완료된 호스트의 제1 IP 주소를 포함하는 인증 완료 보고 메시지를 수신하는 단계; 상기 호스트에 대한 인증 정보가 소정의 임시 기록 영역에 존재하지 않는 경우, 상기 호스트에 상응하는 새로운 인증 정보를 생성하여 상기 임시 기록 영역에 저장하는 단계-여기서, 인증 정보는 상기 제1 IP 주소를 포함함-; 및 상기 IPSec 블록으로부터 제2 IP 주소를 포함하는 인증 검사 요구 메시지를 수신하는 경우, 상기 제2 IP 주소가 상기 임시 기록 영역에 존재하는지 여부를 확인하고, 상기 확인 결과를 상기 IPSec 블록으로 송신하는 단계를 포함할 수 있다.
본 발명의 다른 실시예에 따르면, IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템이 개시된다.
본 발명에 따른 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템은 인증 완료된 호스트의 인증 정보를 임시 저장하는 인증 캐시; 상대 호스트에 대한 사용자 인증을 수행하고, 인증에 성공한 상대 호스트의 IP 주소를 인증 캐시 관리 모듈에 전송하는 SEND 블록; 상기 SEND 블록으로부터 인증 완료된 호스트의 IP 주소를 수신하는 경우, 해당 IP 주소를 상기 인증 캐시에 저장하거나, IPSec 블록으로부터의 인증 검사 요청에 따라 해당 IP 주소의 인증 여부를 상기 인증 캐시를 참조하여 확인하는 인증 캐시 블록; 및 상기 인증 캐시 블록에 인증해야 할 호스트의 IP 주소를 포함하는 인증 검사 요구 메시지를 송신하고, 상기 인증 캐시 블록으로부터 수신된 인증 검사 결과에 따라, 해당 호스트에 대한 사용자 인증 여부를 결정하는 IPSec 블록을 포함할 수 있다.
본 발명은 SEND 블록과 IPSec 블록의 협업 환경에서 SEND 프로토콜에 의해 생성된 인증 정보를 IPSec 프로토콜과 공유하고, IPSec 블록에서는 공개키를 이용하여 상대 호스트를 인식하는 것이 가능한 모바일 인터넷 환경에서의 인증 방법 및 그 시스템을 제공하는 장점이 있다.
또한, 본 발명은 모바일 인터넷 환경에서 SEND 블록과 IPSec 블록의 협업에 따른 불필요한 인증 절차를 제거함으로써, 보다 빠르고 효율적인 인증 방법 및 그 시스템을 제공하는 장점이 있다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2, 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다.
및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다. 본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
본 출원에서, "포함하는" 또는 "탑재된" "장착된" 등의 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
전술한 것 외의 다른 측면, 특징, 이점이 이하의 도면, 특허청구범위 및 발명의 상세한 설명으로부터 명확해질 것이다.
상술한 목적, 특징들 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이다. 우선 각 도면의 구성요소들에 참조 번호를 부가함에 있어서, 동일한 구성요소들에 한해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 번호를 가지도록 하고 있음에 유의하여야 한다.
본 발명의 설명에 앞서, 본 발명이 개시한 사상의 기초가 되는 IPv6 프로토콜에서 보안을 위해 사용하는 SEND (Secure Neighbor Discovery) 프로토콜과 IPSec (Internet Protocol Security) 프로토콜에 대하여 간단하게 소개하고, 두 보안 프로토콜이 동시에 사용될 때, 즉 SEND 블록과 IPSec 블록 협업 환경에서 발생할 수 있는 문제점을 살펴보기로 한다.
IPSec 블록은 IP 계층과 전송 계층 사이에서 IP 주소와 데이터의 기밀성과 무결성을 제공하며, 호스트 간 보안 통신을 가능하도록 하는 보안 프로토콜이다.
일반적으로 IPSec 블록에 의해 제공되는 보안 서비스로는 접근 제어(access control), 기밀성(confidentiality), 비연결형 무결성(connectionless integrity), 재현 공격 방지(anti-replay service), 원적지 인증(data origin authentication) 그리고 제한된 트래픽 흐름 기밀성(limited flow confidentiality) 등이 있다
IPSec 보안 통신을 원하는 호스트들은 인터넷 키 교환(Internet Key Exchange:IKE)-이하, 'IKE'이라 함-을 통하여 키 교환과 보안 협약을 설정한다.
도 1은 일반적인 IPSec 블록 구조를 도시한 블록도이다.
도 1에 도시된 바와 같이, IKE는 키 분배와 보안 협약을 설정하는 ISAKMP로 구성된다. 먼저 키를 분배하는 과정에서 양단간 사용자 인증이 수행되며, 사용자 인증이 성공한 경우에 한하여, 정상적으로 키가 분배된다.
여기서, 키는 보안 키, 암호화 키 및 인증 키 등을 포함할 수 있다.
이후 보안 협약 내용을 암호화하여 해당 호스트에 전송할 수 있으며 협약이 성공하면 이후부터 호스트 양단간 전송 데이터의 기밀성과 무결성을 제공할 수 있다.
SEND 프로토콜은 인접 탐색 프로토콜(Neighbor Discovering Protocol, 이하, 'ND'이라 칭함)에 보안 기능을 지원하기 위하여 개발되었으며, IPSec 블록과 같은 보안 인프라가 존재하지 않는 환경에서도 자체적으로 ND 메시지를 보호할 수 있다.
도 2는 본 발명에 따른 IPv6에서의 IP 주소 체계를 설명하기 위한 도면이다
SEND 블록을 사용하는 호스트는 먼저 공개키/개인키 쌍을 미리 할당 받아 소정의 기록영역에 유지하여야 한다. 여기서 할당된 공개키는 도 2에 도시된 바와 같이 Cryptographically Generated Address(CGA) 보안 모듈에 의해 IP 주소를 생성하는데 사용된다.
도 2를 참조하면, IPv6 환경에서 사용되는 IP 주소(200)는 총 128비트(Bits)의 크기를 가지며, 각각 64비트(Bits)의 길이를 갖는 서브넷 프레픽스(Subnet Prefix, 210)와 인터페이스 식별자(Interface Identifier, 220)로 구성된다.
여기서, 인터페이스 식별자(220)는 서브넷 프레픽스(210), 공개키(Public Key) 및 보안 파라메터(Security Parameters)를 이용하여 생성될 수 있다.
이후, 특정 호스트는 통신을 하는 상대 호스트에게 주소를 검증할 자료-예를 들면, 서브넷 프레픽스(210) 및 인터페이스 식별자(220)를 포함함-와 자료에 대한 전자 서명 및 공개키를 함께 전송함으로써 주소를 생성한 호스트를 인증하고 주소에 대한 소유권을 증명할 수 있다
이하의 설명에서는 SEND 블록이 적용된 네트워크 환경에서의 통신이 수행되는 절차를 상세히 설명하기로 한다.
기본적으로 TCP/IP 통신은 통신 시작 단계에서 IP 주소를 물리 계층 주소로 변환하는 단계가 필수적이다. 이러한 특징은 IPv6 환경에서도 동일하게 적용되며 ND 메커니즘의 주소 변환(Address resolution) 기능이 이를 담당하고 있다.
SEND 블록이 적용된 환경에서 IPSec 블록을 수행할 경우 IKE에서는 IPSec 보안 통신을 수행할 호스트의 IP 주소를 목적지로 하여 IPSec 블록 연결 요청 메시지를 전송한다.
일반적으로, 어플리케이션 계층으로부터 수신된 메시지가 IP 계층으로 전달되면 메시지 헤더에 IP 주소가 설정되며, 해당 메시지가 IP 계층에서 물리 계층으로 전달될 경우에는 IP 주소에 대한 물리 주소가 설정한다.
이때 상대 호스트의 물리 주소는 소정의 주소 변환 프로토콜(Address Resolution Protocol)을 통해 획득될 수 있다.
IPv6에서의 주소 변환(Address Resolution)은 ND 메시지를 이용하여 수행되며, ND 메시지의 보호를 위하여 SEND 블록을 이용한 통신이 수행된다.
SEND 블록이 적용된 ND 메시지를 수신한 호스트는 메시지를 보낸 호스트의 주소에 대한 소유권을 인증하고, 만약 소유권 인증이 성공한 경우, 주소 변환이 정상적으로 종료된다. 이후, 두 호스트 간의 통신이 정상적으로 수행될 수 있다.
다음으로 IPSec 블록은 IKE를 이용하여 키-여기서, 키는 IPSec 비밀 통신에 사용할 비밀키로서 대칭키를 포함함-를 분배하고 보안 협약을 수행하여 IPSec 통신을 수행하게 된다. 즉 IPSec 블록이 수행되기 위해서는 통신 시작 단계에서 SEND 블록을 통한 사용자 인증 절차가 선행되어야 한다.
하지만 위와 같은 과정에서 SEND 블록과 IPSec 블록은 동일한 호스트에 대하여 각각 별도로 인증 절차를 수행한다. 동일한 호스트에 대한 중복된 인증은 SEND 블록의 처리 과정을 거쳐서 IPSec 블록이 설정되기까지 아래 표 1과 같은 처리 비용을 발생시킨다.
<표 1> SEND 블록과 IPSec 블록 동시 사용 시 요구되는 처리 비용
구분 처리 비용
SEND 블록 2CHash + 2CSig
IPSec 블록 2CDH + 2CSK + CSig
모두 수행할 경우 2CHash +3CSig +2CDH +2CSK
*C Hash : 해쉬 함수 처리 비용
*C SK : 대칭키 암호 처리 비용
*C Sig : 전자서명 처리 비용
*C DH : 키분배 처리 비용
상기한 표 1에 도시된 바와 같이, SEND 처리 과정에 소요되는 비용은 2회의 해쉬 함수 처리 비용(2 C Hash ), 및 2회의 전자 서명 처리 비용(2 C Sig )의 합으로 정의될 수 있다.
반면, IPSec 처리 과정에 소요되는 비용은 2회의 키 분배 처리 비용(2CDH ), 2회의 대칭키 암호 처리 비용(2CSK ) 및 전자 서명 처리 비용(CSig )의 합으로 정의될 수 있다.
이때, SEND 처리 과정 및 IPSec 처리 과정은 공통적으로 전자 서명 처리 비용(CSig )이 소요된다. 즉, SEND 블록 및 IPSec 블록의 협업 시스템에서는 전자 서명 처리 비용(CSig )이 중복으로 소요되는 것을 알 수 있다.
IPv6 환경에서는 이동에 의한 주소 변경이나, 보안을 위하여 사용하는 주소가 주기적으로 변경될 수 있다. 이러한 특징에 따라 주소가 정적인 IPv4 환경에 비하여 IPv6 환경에서는 고정 할당 주소보다는 주소 자동 설정을 통한 자동으로 할당되는 주소가 더욱 많이 사용될 것으로 예상된다.
따라서 IPv6 환경에서 사용되는 IPSec 프로토콜은 기존의 IPv4 환경에서 사용되던 IP 주소를 이용한 종단 호스트 인식 방법을 그대로 사용하는 경우, IP 주소가 변경될 때마다 새로운 세션을 맺어야 하는 비효율적인 동작을 수행할 뿐만 아니라 이에 따라 인증 절차도 다시 수행해야 하는 문제점이 존재할 수 있다.
이하의 설명에서는 SEND 블록과 IPSec 블록 협업 기법에 대해 설명하기로 한다.
도 3은 본 발명의 일 실시예에 따른 SEND 블록과 IPSec 블록 협업을 위한 시스템 구조도이다.
좀 더 상세하게는, 도 3은 종래의 SEND 블록과 IPSec 블록의 협업 환경에서 나타날 수 있는 중복된 인증 처리 문제를 해결하기 위하여, SEND 블록과 IPSec 블록 사이에서 인증 정보를 공유하고, IPSec 블록에서는 공개키를 이용하여 상대 호스트를 인식하는 것이 가능한 SEND 블록과 IPSec 블록 협업을 위한 시스템 구조도이다.
일반적으로, IPv6 환경에서 SEND 블록이 적용된 호스트는 공개키/개인키를 소유한다. 이러한 특징을 이용하여 두 기술간 사용자 인증 정보가 공유될 수 있으며, 이를 통해 IPSec 블록의 처리 속도가 향상될 수 있다.
도 3에 도시된 바와 같이, 본 발명의 일 실시예에 따른 협업 시스템은 패킷 필터링 블록(Packet Filtering Block, 310), IPSec 블록(IPSec Block, 320), SEND 블록(SEND Block, 330), 인증 캐시 블록(Authentication Cache Block, 340), 공개키/개인키 저장소(Public/Private Key Repository, 350), 인증 캐시(Authentication Cache, 360), 공개키 보안 협약 데이터베이스(Public key Security Agreement Database:P-SAD, 370) 및 공개키 보안 정책 데이터베이스(Public key Security Policy Database:P-SPD, 380)을 포함할 수 있다.
패킷 필터링 블록(310)은 확장 헤더 처리 모듈(Extension Header Handling Module, 311) 및 패킷 필터 모듈(Packet Filter Module, 312)로 구성될 수 있다.
여기서, 확장 헤더 처리 모듈(311)은 수신된 패킷의 확장 헤더를 분석하여 해당 블록 또는 모듈로 수신된 패킷을 전달하는 기능을 수행할 수 있다. 즉, 확장 헤더 처리 모듈(311)은 패킷 라우터로서의 기능을 수행할 수 있다.
예를 들면, 확장 헤더 처리 모듈(311)은 확장 헤더의 분석을 통해 IPSec 블록 관련된 패킷은 IPSec 블록(320)으로, SEND 블록 또는 ND 메시지와 관련된 패킷은 패킷 필터 모듈(312)로 전달할 수 있다.
패킷 필터 모듈(312)은 입력 패킷과 출력 패킷 중 ND 메시지에 대한 필터링을 수행한다.
IPSec 블록(320)은 입출력 패킷에 대한 IPSec 처리를 수행하는 IPSec 모듈(IPSec Module, 321), 호스트 양단간 보안 협상 및 공개키 또는 인증 캐시를 이용한 사용자 인증을 수행하는 호스트 인증 모듈(Host Authentication Mudule, 322) 및 세션의 관리 및 세션 정보를 수정하는 세션 관리 모듈(Session Management Module, 323)을 포함할 수 있다.
SEND 블록(330)은 입출력 ND 패킷에 대하여 SEND 처리를 수행하며, 인증 완료된 호스트에 할당된 IP 주소 정보를 인증 캐시 관리 모듈(342)에 전달한다. 이때, SEND 블록(330)과 인증 캐시 관리 모듈(342) 사이의 통신은 공유 메모리를 이용한 프로세스간 통신이 바람직하다.
도 3을 참조하면, 인증 캐시 블록(Authentication Cache block, 320)은 인증 캐시 관리 모듈(Authentication Cache Management Module, 342), 키 관리 모듈(Key Management Module, 341)를 포함할 수 있다.
인증 캐시 관리 모듈(342)은 ND 패킷에 대하여 사용자 인증에 성공한 경우 인증 정보를 인증 캐시에 저장하고, 인접 캐시(Neighbor Cache)의 상태를 참조하여 인증 캐시를 관리하는 기능을 수행한다.
예를 들면, 인증 캐시 관리 모듈(342)은 SEND 블록(330)로부터 수신된 IP 주소 정보를 인증 캐시에 저장한다. 이때, IP 주소 정보는 연결 리스트(Linked List)의 형태로 인증 캐시에 저장되는 것이 바람직하다.
또한, 인증 캐시 관리 모듈(342)은 IPSec 블록(320)으로부터 특정 호스트의 인증 검사를 위해 IP 주소를 포함하는 소정의 제어 신호를 수신하는 경우, 해당 IP 주소가 인증 캐시(360)에 존재하는지 여부를 확인하고, 확인 결과를 소정의 제어 신호를 이용하여 IPSec 블록(320)에 제공할 수 있다.
즉, 인증 캐시 관리 모듈(342)는 인증 캐시(360)상에 수신한 IP 주소가 존재하는 경우, 인증 검사에 성공한 것으로 판단한다. 반면, 인증 캐시 관리 모듈(342)은 인증 캐시(360)상에 수신된 IP 주소가 존재하지 않는 경우, 인증 검사에 실패한 것으로 판단한다.
키 관리 모듈(341)은 공개키와 개인키를 생성하여 공개키/개인키 저장소(350)에 저장한다. 이때, 사용자 별 할당된 공개키 및 개인키에 대한 정보는 소정의 파일 형태로 공개키/개인키 저장소(350)에 저장되는 것이 바람직하다.
인증 캐시(360)는 사용자 인증 정보의 임시 저장소로서, 인증 캐시 관리 모듈(342)에 의해 관리될 수 있다.
공개키/개인키 저장소(350)는 SEND 블록과 IPSec 블록에서 사용할 공개키와 개인키를 저장하는 기록 매체로서, 키 관리 모듈(341)에 의해 관리된다.
P-SAD(370)는 기존의 보안 협약 데이터베이스에 각 호스트에 할당된 공개키를 함께 저장하는 데이터베이스이며, P-SPD(380)는 기존의 보안 정책 데이터베이스 에 각 호스트에 할당된 공개키를 함께 저장하는 데이터베이스이다.
본 발명에 따른 SEND 블록과 IPSec 블록 협업 시스템은 종래의 시스템 구성에 비해 인증 정보의 공유를 위한 인증 캐시(360), 인증 캐시 관리 모듈(342), 키 관리 모듈(341) 및 공개키/개인키 저장소(350)가 새롭게 구현될 수 있으며, SEND 블록과 IPSec 블록의 일부 처리 절차가 수정될 수 있다.
본 발명에 따른 인증 캐시(360)는 IPv6 주소를 저장할 수 있는 형태의 자료 구조로 이루어질 수 있으며, 인증 캐시 관리 모듈(342)에 의해 생성 및 관리될 수 있다.
이하의 설명에서는 관련 도면(도 4 내지 도 5)을 참조하여, 인증 캐시 관리 모듈(342)의 처리 흐름을 상세히 설명하기로 한다.
도 4는 본 발명의 일 실시예에 따른 인증 캐시 관리 모듈의 처리 흐름도이다.
도 4를 참조하면, 인증 캐시 관리 모듈(342)은 별도의 데몬 형태로 동작되며, 초기화 과정(S410)에서 인증 캐시(360)를 생성하고, SEND 블록(330) 및 IPSec 블록(320)과의 자료 교환을 위한 통신 채널을 설정한다.
인증 캐시 관리 모듈(342)은 초기화가 완료되면, 외부로부터의 제어 패킷의 수신을 대기한다(S420). 여기서, 외부로부터 수신되는 제어 패킷은 SEND 블록(330)에 의해 인증 완료된 호스트의 IP 주소 정보를 포함하는 인증 완료 보고 패킷 및 인증 검사를 위해 IPSec 블록(320)으로부터 수신되는 인증 검사 요구 패킷-여기서, 인증 검사 요구 패킷은 검사 대상인 IP 주소를 포함할 수 있음-을 포함할 수 있다.
본 발명의 다른 일 실시예에 따르면, 인증 캐시 관리 모듈(342)은 미리 정의된 호출 함수 및 공유 메모리를 이용한 프로세서간 통신 방식을 이용함으로써, SEND 블록(330) 및 IPSec 블록(320)와의 특정 제어 신호를 송수신할 수도 있음을 주의해야 한다.
인증 캐시 관리 모듈(342)은 외부로부터 제어 패킷을 수신하는 경우, 수신된 제어 패킷의 헤더 정보를 통해 패킷의 타입을 확인한다(S430).
확인 결과, 인증 캐시 관리 모듈(342)이 SEND 블록(330)로부터 인증 완료된 호스트의 IP 주소 정보를 포함하는 인증 완료 보고 패킷을 수신하는 경우(S440), 해당 IP 주소 정보가 인증 캐시(360)에 존재하는지 여부를 판단한다(S450)
즉, 본 발명에 따른 SEND 블록(330)은 NIC(Network Interface Card)로 입출력되는 ND 메시지에 대한 SEND 처리를 수행한다. 여기서, SEND 처리는 상대 호스트에 대한 인증 절차-즉, 사용자 인증 절차-를 포함할 수 있다.
SEND 블록(330)은 상대 호스트에 대한 인증에 성공한 경우, 인증된 상태 호스트의 IP 주소를 상기한 초기화 과정(S410)에서 설정된 통신 채널을 통해 인증 캐시 관리 모듈(342)에 전송한다.
상기한 450 단계에서, 만약, 인증 캐시(360)에 수신된 IP 주소 정보를 포함하는 엔트리가 존재하는 경우, 인증 캐시 관리 모듈(342)은 해당 엔트리에 포함된 IP 주소를 수신된 IP 주소로 갱신한다(S460).
상기한 450 단계에서, 만약, 인증 캐시(360)에 수신된 IP 주소 정보를 포함 하는 엔트리가 존재하지 않는 경우, 인증 캐시 관리 모듈(342)은 수신된 IP 주소를 포함하는 새로운 엔트리를 생성하여 인증 캐시(360)에 저장한다(S470).
상기한 430 단계에서, 확인 결과, IP 주소를 포함하는 인증 검사 요구 패킷이 IPSec 모듈(321)로부터 수신되는 경우(S480), 인증 캐시 관리 모듈(342)은 수신된 IP 주소가 인증 캐시(360)상에 존재하는지 여부를 확인한다(S490).
확인 결과, 수신된 IP 주소가 인증 캐시(360)에 존재하는 경우, 즉 SEND 블록(330)에 의해 이미 사용자 인증이 완료된 IP 주소인 경우, 인증 캐시 관리 모듈(342)은 소정의 인증 검사 성공 메시지를 IPSec 모듈(321)에 전송한다(S491).
상기한 490 단계에서, 만약, 수신된 IP 주소가 인증 캐시(360)에 존재하지 않는 경우, 인증 캐시 관리 모듈(342)은 소정의 인증 검사 실패 메시지를 메시지를 IPSec 모듈(321)에 전송한다(S492).
상기한 460 단계, 470 단계, 491 단계, 492 단계 중 어느 하나의 단계가 수행된 후, 인증 캐시 관리 모듈(342)은 상기한 420 단계로 회귀한다.
IPSec 모듈(321)은 인증 검사 실패 패킷을 수신하면, 전자 서명과 공개키를 이용하여 해당 호스트에 대한 인증을 시도한다. 즉, IPSec 블록(320)에 구비된 호스트 인증 모듈(322)은 IPSec 모듈(321)의 제어 신호-여기서, 제어 신호는 인증 검사 실패를 지시하는 제어 신호임-에 따라 공개키를 이용한 사용자 인증을 수행한다.
여기서, 공개키를 이용한 사용자 인증은 종래의 IPSec 블록에서 사용하는 Security Association Database(SAD)와 Security Policy Database(SPD)에 호스트의 공개키를 저장할 수 있는 필드를 추가한 Public key-SAD(P-SAD)와 Public key-SPD(P-SPD)를 생성하는 절차를 포함할 수 있다.
본 발명에 따른 세션 관리 모듈(323)은 생성된 P-SAD(380)와 P-SPD(390)를 이용하여 세션의 유지 및 관리 기능을 수행한다.
모바일 IPv6 환경에서는 호스트의 이동에 따라 IP 주소가 수시로 바뀔 수 있으며, 이에 따라, IP 주소가 상대 호스트를 인식하는 고유한 정보로 사용되기 어려운 문제점이 있다.
따라서, 본 발명에 따른 IPSec 블록(320)은 상기한 문제점을 해결하기 위해 사용자에 대하여 고유한 정보가 될 수 있는 공개키를 이용하여 사용자 인증 및 세션 관리를 수행함으로써, 사용자의 이동성을 보장할 뿐만 아니라 보다 안전하게 세션을 유지할 수 있다.
도 5는 IEEE RFC2461에 정의된 인접 캐시(Neighbor Cache) 엔트리(Entry) 상태 천이도이다.
도 5를 참조하면, 인접 캐시 엔트리 상태 천이도는 인접 노드로의 접근가능성을 구분하기 위한 상태 정보로서, NO ENTRY EXISTS(510), INCOMPLETE(520), REACHABLE(530), STALE(540), DELAY(550), PROBE(560) 상태를 포함할 수 있다.
NO ENTRY EXISTS(510) 상태는 특정 노드에 대한 엔트리-인증 정보-가 인증 캐시에 존재하지 않음을 지시하는 상태이다.
INCOMPLETE(520) 상태는 해당 엔트리에 대한 주소 변환(Address Resolution) 이 완료되었음을 지시하는 상태이다.
REACHABLE(530) 상태는 인접 노드로의 패킷 전달 경로가 적절히 동작하고 있음을 지시하는 상태로서, 본 발명에 따른 인증 캐시 관리 모듈(342)은 미리 정의된 접근가능확인주기(ReachableTime milliseconds) 내에 해당 인접 노드로의 통신 경로가 정상적임을 지시하는 소정의 제어 신호-이하, 'Positive Confirm'이라 함-를 수신하는 경우, 해당 엔트리의 상태를 REACHABLE(530) 상태로 천이할 수 있다.
STALE(540) 상태는 마지막으로 Positive Confirm을 수신한 후, 접근가능확인주기가 경과할 때까지 Positive Confirm을 수신하지 못한 경우에 천이되는 상태이다. STALE(540) 상태에서는 패킷이 전송될 때까지 어떠한 동작도 발생하지 않는다.
본 발명에 따른 인증 캐시 관리 모듈(342)은 인증 캐시에 저장된 링크 계층(link-layer) 주소를 갱신하기 위한 소정의 제어 신호를 수신하는 경우, 해당 엔트리의 상태를 STALE(540) 상태로 천이시킬 수 있다.
즉, STALE(540) 상태는 해당 인접 노드로의 접근가능성(Reachability)을 보장하지 않는다.
DELAY(550) 상태는 마지막으로 Positive Confirm을 수신한 후, 접근가능확인주기가 경과할 때까지 Positive Confirm을 수신하지 못하고, 패킷이 최근의 DELAY_FIRST_PROBE_TIME 내에 전송된 경우에 천이하는 상태이다.
만약, 본 발명에 따른 인증 캐시 관리 모듈(342)은 DELAY_FIRST_PROBE_TIME 내에 접근가능성 확인 메시지(reachability confirmation message)가 수신되지 못하는 경우, 인접간청메시지(Neighbor Solicitation message)를 송신하고, 해당 엔 트리의 상태를 PROBE(560) 상태로 천이한다.
PROBE(560) 상태에서는 접근가능성 확인 메시지가 수신될 때까지 매 재전송 주기마다 인접간청메시지를 재전송함으로써, 접근가능성 확인 절차가 능동적으로 수행될 수 있다.
도6은 본 발명의 일 실시예에 따른 SEND 블록과 IPSec 블록의 협업 시스템의 블록 구성도이며, 표 2는 협업 시스템의 각 블록 별 기능에 대한 상세 설명이다.
도 6를 참조하면, 본 발명의 일 실시예에 따른 협업 시스템은 크게 SEND 블록(610), IPSec 블록(620), 관리 블록(630) 및 인증 캐시(640)로 구성될 수 있다.
여기서, SEND 블록(610), IPSec 블록(620) 및 인증 캐시(640)는 각각 상기한 도 3 내지 도5에서 상술한 SEND 블록(330), IPSec 블록(320) 및 인증 캐시(360)의 기능을 모두 포함하므로 본 도면의 설명에서는 해당 구성 요소에 대한 설명을 생략하기로 한다.
하기의 표 2를 참조하면, SEND 블록(610)은 무결성 검증(Integrity Check), 소유권 검증(Property Check), 사용자 인증(User Authentication) 및 사용자 정보 저장(Save User Information) 등의 기능을 수행할 수 있다.
IPSec 블록(620)은 세션 생성(Session Generation), 세션 관리(Session Management), 사용자 인증(User Authentication), 사용자 검사(User Check), 데이터베이스 갱신(Database Update), 세션 수정(Session Revision) 등의 기능을 수행할 수 있다.
관리 블록(630)은 패킷 분석(Packet Analysis), 인증 관리(Authentication Management) 등의 기능을 수행할 수 있다.
상기한 블록 별 수행되는 기능에 대한 설명은 하기의 표 2에 포함된 상세 기능 설명으로 대신하기로 한다.
<표 2> 협업 시스템의 블록 별 기능
블록 기능 상세 기능 설명
SEND 무결성 검증 SEND 패킷 정보에 대한 무결성 검증 수행
소유권 검증 호스트에 대한 주소 소유권 검증 수행
사용자 인증 사용자 인증 수행
사용자 정보 저장 인증 캐시에 인증 정보 저장
IPSec 세션 생성 IPSec 세션 설정 수행
세션 관리 세션의 수정 및 유지 수행
사용자 인증 새로운 사용자에 대한 인증
사용자 검사 세션에 대한 사용자의 정당성 검증 수행
데이터베이스 갱신 데이터베이스 생성
세션수정 데이터베이스의 해당 세션정보 수정
데이터베이스 세션 정보 저장
관리 패킷 분석 SEND 블록과 IPSec 블록 패킷에 대한 분석 처리 수행
인증 관리 공개키/개인키 생성 및 관리 수행
이하의 설명에서는 네트워크 환경에 따라 본 발명에 따른 SEND 블록과 IPSec 블록의 협업 기법에 대한 적용 예를 관련 도면(도 7 내지 도 9)을 참조하여 상세히 설명하기로 한다.
표 3은 본 발명에 따른 협업 시스템이 적용될 수 있는 네트워크 환경을 정리한 표이다.
<표 3> 협업 시스템의 동작 환경
환경 구분 협업 가능 여부
동일 네트워크 환경(시나리오 1) O
서로 다른 네트워크 환경 IPSec 터널 모드(시나리오 2) O
IPSec 전송 모드(시나리오 3) X
SEND 블록과 IPSec 블록이 동시에 사용되는 환경은 상기한 표 3에 도시된 바와 같이, 세 가지로 구분할 수 있으며, 그 중 협업이 가능한 환경은 두 환경-즉, 시나리오 1 및 시나리오 2-에서만 가능하다.
도 7은 본 발명의 일 실시예에 따른 동일 네트워크 환경에서의 협업 시나리오를 도시한 도면이다.
도 7에 도시된 시나리오 1은 가장 기본이 되는 네트워크 환경이며, 최초 호스트가 네트워크에 참여하는 경우, 기본적으로 속하게 되는 네트워크 환경일 수 있다.
본 발명의 일 실시예에 따른 협업 시스템은 두 호스트-호스트 A(710) 및 호스트 B(720)-에 대해 최초 통신에서 SEND 프로토콜을 통해 무결성 검증, 소유권 검증 및 사용자 인증 단계를 수행하고, 인증에 성공하였을 경우 해당 호스트에 할당된 IP 주소를 인증 캐시(360)에 저장하는 사용자 정보 저장 단계를 수행할 수 있다.
이어서, 본 발명에 따른 협업 시스템은 두 호스트에 대한 IPSec 보안 협약 과정에서 세션 생성, 사용자 인증 및 데이터베이스 생성 단계를 수행함으로써 두 호스트 사이의 IPSec 통신을 제공할 수 있다.
특히, 본 발명에 따른 협업 시스템은 사용자 인증 단계에서 인증 캐시(260)에 상대 호스트 정보-예를 들면, 상대 호스트의 IP 주소를 포함함-의 존재 유무에 따라 상대 호스트가 SEND 절차를 통해 이미 인증이 완료되었는지 여부를 판별할 수 있다.
여기서. 상대 호스트 정보는 미리 설정된 주기 마다 확인되며, 협업 시스템은 상기한 도 5에 도시된 인접 캐시 상태 천이도(Neighbor Cache State Transition Diagram)를 기반으로 해당 호스트가 더 이상 네트워크에 존재하지 않는 것으로 판단될 경우 해당 상대 호스트 정보를 인증 캐시(360)로부터 삭제할 수 있다.
도 8은 본 발명의 일 실시예에 따른 서로 다른 네트워크 환경에서의 보안 게이트웨이를 이용한 협업 시스템의 동작 과정을 설명하기 위한 도면이다.
도 8을 참조하면, 본 발명에 따른 보안 게이트웨이(810)는 서로 다른 네트워크 각각에 존재하며, 타 네트워크로의 관문 역할 및 보안 게이트웨이 사이에서의 보안 통신을 제공하는 기능을 수행한다.
또한, 보안 게이트웨이(810)는 자신의 네트워크에 속해있는 호스트들에 대한 인증을 수행하며, 정상적으로 인증된 호스트의 정보만이 해당 보안 게이트웨이를 통과할 수 있도록 제어하는 기능을 수행한다.
도 8에 도시된 바와 같이, 인증 호스트(820)와 보안 게이트웨이(810) 간의 통신은 SEND 프로토콜을 통해 수행되며, 이종 망간의 통신-즉, 보안 게이트웨이 간의 통신-은 IPSec 프로토콜을 통해 수행된다.
이하의 설명에서는 상기한 도 8에 도시된 망 구성을 통해 이루지는 통신 모드를 IPSec 터널 모드라 명하기로 한다.
이러한 IPSec 터널 모드는 각 네트워크에 검증되지 않은 호스트가 참여할 경우 다른 네트워크까지 공격 대상이 될 수 있기 때문에 참여 호스트들에 대한 보안 및 인증 관리가 필요한 환경이다.
호스트가 네트워크에 참여하기 위해서는 라우터 정보가 필요하다. 여기서. 라우터 정보는 호스트의 요청에 의해서만 제공되도록 설정되며, 라우터 정보 요청은 SEND 블록을 이용하게 수행된다.
이 과정에서 보안 게이트웨이(810)는 해당 호스트에 대한 사용자 인증을 수행한다. 여기서, 사용자 인증 과정에 대한 설명은 상기한 시나리오 1에서의 수행 절차와 동일하므로 생략하기로 한다.
만약, 특정 호스트의 사용자 인증이 성공하여 인증 캐시(360)상에 해당 호스트의 사용자 인증 정보가 존재하는 경우, 보안 게이트웨이(810)는 해당 호스트로부터 수신되는 패킷을 다른 네트워크에 접속된 호스트로 전송하거나, 해당 호스트에 할당된 IP 주소를 목적지 주소로 하는 패킷을 다른 네트워크로부터 수신하여 해당 호스트에 전송할 수 있다.
도 9는 본 발명의 일 실시예에 따른 서로 다른 네트워크 환경에 속해 있는 호스트들 사이의 보안 통신을 연결하는 방법을 설명하기 위한 도면이다.
도 9를 참조하면, 본 발명의 일 실시예에 따른 시나리오 3는 제1 네트워크(910) 및 제2 네트워크(920)를 포함하는 광역 네트워크(900)에서 제1 네트워크(930)에 속한 호스트A(930)와 제2 네트워크(920)에 속한 호스트B(940)가 보안 통신을 수행하는 것으로 가정한다.
이때, 제1 네트워크(910) 및 제2 네트워크(920)는 해당 망에 접속된 호스트 들에 대한 인증 서비스를 제공하는 제1인증서버(950) 및 제2인증서버(960)를 각각 포함한다.
여기서, 동일 네트워크에 속한 인증 서버 및 호스트는 SEND 블록을 통해 인증 절차가 수행되며, 서로 다른 인증 서버간에는 사용자 인증 정보를 공유할 수 없다.
특히, 시나리오 3에서는 제1 인증서버(950)에 의해 인증된 호스트A(930)과 제2 인증서버(960)에 인증된 호스트B(940)가 직접 IPSec 통신을 수행한다.
앞서 설명한 바와 같이, SEND 메커니즘은 동일한 네트워크 내부에서만 동작하기 때문에 상이한 네트워크에 속한 호스트의 인증 정보를 저장할 수 없다.
따라서, 서로 다른 네트워크간 사용자 인증 정보를 공유할 수 없는 네트워크 환경에서는 본 발명에 따른 SEND 블록과 IPSec 블록 사이의 협업 방법이 동일 네트워크 내부에서만 적용될 수 있다.
하지만, IPv6 환경에서는 서브넷(Subnet)이 최대 264의 크기를 가질 수 있으며, IPv4 환경에서의 서브넷은 최대 232의 크기를 가질 수 있다. 즉, IPv6를 이용한 네트워크가 IPv4를 이용하는 네트워크에 비해 보다 큰 네트워크를 형성될 수 있다.
따라서, 본 발명에 따른 SEND 블록과 IPSec 블록 사이의 협업 시스템이 동일 네트워크 환경에서만 사용할 수 있다 하더라도 네트워크의 크기가 크기 때문에 유용하게 사용될 수 있다.
SEND 블록을 이용하는 네트워크에서 보안을 강화하기 위해 호스트에 할당되는 IP 주소를 주기적으로 변경하거나, 호스트의 이동에 따라 접속 네트워크가 변경되는 경우, 해당 호스트에 대한 IP 주소는 변경될 수 있다.
본 발명에 따른 협업 시스템에서의 IPSec 블록은 보안키-예를 들면, 공개키-를 이용하여 세션을 유지할 수 있다. 만약, 특정 호스트에 할당된 IP 주소가 변경되는 경우, IP 주소가 변경된 호스트-이하, '제1호스트'이라 함-는 기존의 세션 정보 및 보안키 정보를 새롭게 할당된 IP 주소를 이용하여 상대 호스트-이하, '제2호스트'이라 함-에 전송할 수 있다.
제2호스트는 수신된 세션 정보에 포함된 세션 식별자에 상응하는 세션이 기 설정된 세션인지 여부를 P-SAD(370)를 검색하여 확인한다.
확인 결과, 해당 세션 식별자에 상응하는 세션이 존재하는 경우, 제2호스트는 수신된 세션 정보 및 보안키 정보가 기 저장된 세션 정보 및 보안키 정보와 일치하는지 여부를 판단한다.
판단 결과, 일치하는 경우, 제2호스트는 공개키를 이용하여 사용자를 검사하고, P-SAD(370)에 저장된 제1호스트의 IP 주소를 새롭게 할당된 IP 주소로 갱신한다. 이후, 제1호스트와 제2호스트는 갱신된 P-SAD(370)을 이용하여 IPSec 보안 통신을 수행한다.
상기한 본 발명의 바람직한 실시예는 예시의 목적을 위해 개시된 것이고, 본 발명에 대해 통상의 지식을 가진 당업자라면 본 발명의 사상과 범위 안에서 다양한 수정, 변경, 부가가 가능할 것이며, 이러한 수정, 변경 및 부가는 하기의 특허청구범위에 속하는 것으로 보아야 할 것이다.
도 1은 일반적인 IPSec 블록 구조를 도시한 블록도.
도 2는 본 발명에 따른 IPv6에서의 IP 주소 체계를 설명하기 위한 도면.
도 3은 본 발명의 일 실시예에 따른 SEND 블록과 IPSec 블록 협업을 위한 시스템 구조도.
도 4는 본 발명의 일 실시예에 따른 인증 캐시 관리 모듈의 처리 순서도.
도 5는 IEEE RFC2461에 정의된 인접 캐시(Neighbor Cache) 엔트리(Entry) 상태 천이도.
도6은 본 발명의 일 실시예에 따른 SEND 블록과 IPSec 블록의 협업 시스템의 블록도.
도 7은 본 발명의 일 실시예에 따른 동일 네트워크 환경에서의 협업 시나리오를 도시한 도면.
도 8은 본 발명의 일 실시예에 따른 서로 다른 네트워크 환경에서의 보안 게이트웨이를 이용한 협업 시스템의 동작 과정을 설명하기 위한 도면.
도 9는 본 발명의 일 실시예에 따른 서로 다른 네트워크 환경에 속해 있는 호스트들 사이의 보안 통신을 연결하는 방법을 설명하기 위한 도면.
*주요 도면 부호
310 : 패킷 필터릴 블록(packet filtering block)
320 : IPSec 블록(IP Security Block)
321 : IPSec 모듈(IP Security Module)
330 : SEND 블록(Security Neighbor Discovery Block)
342 : 인증 캐시 관리 모듈(Authentication Cache Management Module)
342 : 키 관리 모듈(Key Management Module)
360 : 인증 캐시(Authentication Cache)

Claims (13)

  1. IPv6(Internet Protocol version 6) 환경에서 SEND(Secure Neighbor Discovery) 블록과 IPSec(Internet Protocol Security) 블록 사이의 협업 방법에 있어서,
    상기 SEND 블록에 의해 인증 완료된 호스트의 제1 IP 주소를 포함하는 인증 완료 보고 메시지를 수신하는 단계;
    상기 호스트에 대한 인증 정보가 소정의 임시 기록 영역에 존재하지 않는 경우, 상기 호스트에 상응하는 새로운 인증 정보를 생성하여 상기 임시 기록 영역에 저장하는 단계-여기서, 인증 정보는 상기 제1 IP 주소를 포함함-; 및
    상기 IPSec 블록으로부터 제2 IP 주소를 포함하는 인증 검사 요구 메시지를 수신하는 경우, 상기 제2 IP 주소가 상기 임시 기록 영역에 존재하는지 여부를 확인하고, 상기 확인 결과를 상기 IPSec 블록으로 송신하는 단계를 포함하되,
    상기 인증 완료 보고 메시지 수신 시 상기 호스트에 상응하는 인증 정보가 상기 임시 기록 영역에 이미 존재하는 경우, 해당 인증 정보에 포함된 기존 IP 주소를 상기 제1 IP 주소로 갱신하는 단계를 더 포함하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  2. 제 1항에 있어서,
    상기 제2 IP 주소가 상기 임시 기록 영역에 존재하는 경우, 상기 제2 IP 주소에 상응하는 호스트에 대한 인증이 이미 완료된 것으로 판단하고, 소정의 인증 검사 성공 메시지를 상기 IPSec 블록에 전송하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  3. 제 2항에 있어서,
    상기 IPSec 블록이 상기 인증 검사 성공 메시지를 수신하는 경우, 해당 호스트에 대한 별도의 IPSec 인증 절차가 수행되지 않는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  4. 제 1항에 있어서,
    상기 제2 IP 주소가 상기 임시 기록 영역에 존재하지 않는 경우, 상기 제2 IP 주소에 상응하는 호스트에 대한 인증 정보가 존재하지 않음을 지시하는 소정의 인증 검사 실패 메시지를 상기 IPSec 블록에 전송하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  5. 제 4항에 있어서,
    상기 IPSec 블록이 상기 인증 검사 실패 메시지를 수신하는 경우, 해당 호스트에 상응하여 미리 할당된 전자서명과 공개키를 이용하여 해당 호스트에 대한 사용자 인증을 시도하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  6. 삭제
  7. 제 1항에 있어서,
    상기 갱신된 IP 주소를 이용하여 상기 호스트와 세션을 맺고 있는 상대 호스트에 상기 갱신된 IP 주소를 이용하여 기존 세션정보 및 공개키를 전송하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  8. 제 7항에 있어서,
    상기 상대 호스트가 상기 기존 세션정보 및 공개키와 일치하는 정보가 소정의 공개키 보안 협약 데이터베이스에 존재하는 경우, 해당 세션에 상응하는 기존 IP 주소를 상기 갱신된 IP 주소로 변경하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 방법.
  9. 제 1항 내지 제 8항 중 어느 한 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체.
  10. 인증 완료된 호스트의 인증 정보-여기서, 인증 정보는 상기 인증 완료된 호스트의 IP 주소를 포함함-를 임시 저장하는 인증 캐시;
    상대 호스트에 대한 사용자 인증을 수행하고, 인증에 성공한 상대 호스트의 IP 주소를 인증 캐시 관리 모듈에 전송하는 SEND(Secure Neighbor Discovery) 블록;
    상기 SEND 블록으로부터 인증 완료된 호스트의 IP 주소를 수신하는 경우, 해당 IP 주소를 상기 인증 캐시에 저장하거나, IPSec(Internet Protocol Security) 블록으로부터의 인증 검사 요청에 따라 해당 IP 주소의 인증 여부를 상기 인증 캐시를 참조하여 확인하는 인증 캐시 관리 모듈; 및
    상기 인증 캐시 관리 모듈에 인증해야 할 호스트의 IP 주소를 포함하는 인증 검사 요구 메시지를 송신하고, 상기 인증 캐시 관리 모듈로부터 수신된 인증 검사 결과에 따라, 해당 호스트에 대한 사용자 인증 여부를 결정하는 IPSec 블록을 포함하되,
    상기 IPSec 블록은 상기 인증 완료된 호스트의 IP 주소를 수신 시 상기 호스트에 상응하는 인증 정보가 저장되어 있는 경우, 해당 인증 정보에 포함된 기존 IP 주소를 상기 인증 완료된 호스트의 IP 주소로 갱신하는 것을 특징으로 하는 IPv6(Internet Protocol version 6) 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템.
  11. 제10항에 있어서,
    수신된 트래픽의 확장 헤더를 분석하여 상기 트래픽을 수신할 블록으로 해당 트래픽을 전송하고, ND(Neighbor Discovery) 메시지에 대한 필터링을 수행하는 패킷 필터링 블록을 더 포함하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템.
  12. 제10항에 있어서,
    상기 인증 캐시 관리 모듈은
    상기 인증 검사 요청된 IP 주소가 상기 인증 캐시에 존재하는 경우, 상기 SEND 블록에 의해 이미 사용자 인증이 완료되었음을 지시하는 소정의 인증 검사 성공 메시지를 상기 IPSec 블록에 전송하는 수단; 및
    상기 인증 검사 요청된 IP 주소가 상기 인증 캐시에 존재하지 않는 경우, 해당 IP 주소에 대한 인증 정보가 존재하지 않음을 지시하는 소정의 인증 검사 실패 메시지를 상기 IPSec 블록에 전송하는 수단
    을 포함하는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템.
  13. 제12항에 있어서,
    상기 IPSec 블록이 상기 인증 검사 성공 메시지를 수신하는 경우, 상기 인증 검사 요청된 IP 주소에 대한 사용자 인증 절차를 수행하지 않는 것을 특징으로 하는 IPv6 환경에서의 SEND 블록과 IPSec 블록 사이의 협업 시스템.
KR1020070093807A 2007-09-14 2007-09-14 ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템 KR100964350B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020070093807A KR100964350B1 (ko) 2007-09-14 2007-09-14 ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템
US12/040,355 US8819790B2 (en) 2007-09-14 2008-02-29 Cooperation method and system between send mechanism and IPSec protocol in IPV6 environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020070093807A KR100964350B1 (ko) 2007-09-14 2007-09-14 ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템

Publications (2)

Publication Number Publication Date
KR20090028310A KR20090028310A (ko) 2009-03-18
KR100964350B1 true KR100964350B1 (ko) 2010-06-17

Family

ID=40456004

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020070093807A KR100964350B1 (ko) 2007-09-14 2007-09-14 ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템

Country Status (2)

Country Link
US (1) US8819790B2 (ko)
KR (1) KR100964350B1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI449373B (zh) * 2008-06-11 2014-08-11 Asustek Comp Inc 區域網路的管理方法及其裝置
CN101950261B (zh) * 2010-09-09 2013-12-04 中兴通讯股份有限公司 数据存储与鉴权并行的处理方法和终端
JP5342020B2 (ja) * 2011-09-27 2013-11-13 株式会社野村総合研究所 グループ定義管理システム
US20160149711A1 (en) * 2014-11-24 2016-05-26 Wyzr Limited Distributed identification system for peer to peer message transmission
US10680898B2 (en) * 2018-03-06 2020-06-09 At&T Intellectual Property I, L.P. Mini-cloud deployment system
JP2023039218A (ja) 2021-09-08 2023-03-20 キオクシア株式会社 計算機および制御方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046585A1 (en) 2001-09-06 2003-03-06 Linden Minnick Techniques for offloading cryptographic processing for multiple network traffic streams
KR20060125372A (ko) * 2005-06-02 2006-12-06 삼성전자주식회사 다중 영구가상회선 접속환경을 위한 중간 인증관리 시스템및 그 방법

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020157024A1 (en) * 2001-04-06 2002-10-24 Aki Yokote Intelligent security association management server for mobile IP networks
US7203837B2 (en) * 2001-04-12 2007-04-10 Microsoft Corporation Methods and systems for unilateral authentication of messages
US20040240669A1 (en) * 2002-02-19 2004-12-02 James Kempf Securing neighbor discovery using address based keys
US8261062B2 (en) * 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
US7624264B2 (en) * 2003-03-27 2009-11-24 Microsoft Corporation Using time to determine a hash extension
GB0312681D0 (en) * 2003-06-03 2003-07-09 Ericsson Telefon Ab L M IP mobility
US7860978B2 (en) * 2004-01-22 2010-12-28 Toshiba America Research, Inc. Establishing a secure tunnel to access router
EP1739893A1 (en) * 2005-06-30 2007-01-03 Matsushita Electric Industrial Co., Ltd. Optimized reverse tunnelling for packet switched mobile communication systems
US20090327721A1 (en) * 2006-04-25 2009-12-31 Jari Arkko Method and Apparatuses for Securing Communications Between a User Terminal and a SIP Proxy Using IPSEC Security Association
US8356171B2 (en) * 2006-04-26 2013-01-15 Cisco Technology, Inc. System and method for implementing fast reauthentication
US8213394B2 (en) * 2006-10-16 2012-07-03 Motorola Mobility, Inc. Method and apparatus for management of inactive connections for service continuity in an agnostic access internet protocol multimedia communication
US8219800B2 (en) * 2007-06-06 2012-07-10 Cisco Technology, Inc. Secure neighbor discovery router for defending host nodes from rogue routers

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030046585A1 (en) 2001-09-06 2003-03-06 Linden Minnick Techniques for offloading cryptographic processing for multiple network traffic streams
KR20060125372A (ko) * 2005-06-02 2006-12-06 삼성전자주식회사 다중 영구가상회선 접속환경을 위한 중간 인증관리 시스템및 그 방법

Also Published As

Publication number Publication date
US8819790B2 (en) 2014-08-26
KR20090028310A (ko) 2009-03-18
US20090077642A1 (en) 2009-03-19

Similar Documents

Publication Publication Date Title
EP1340337B1 (en) Location-independent packet routing and secure access in a short-range wireless networking environment
FI105965B (fi) Autentikointi tietoliikenneverkosssa
JP4579934B2 (ja) レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
US8437345B2 (en) Terminal and communication system
JP4755203B2 (ja) ホスト・アイデンティティ・プロトコルの方法および装置
EP2033400A1 (en) Method and arrangement for assuring prefix consistency among multiple mobile routers.
AU2001288394A1 (en) Location-independent packet routing and secure access in a short-range wireless networking environment
JP2008537398A (ja) モバイルインターネットプロトコル鍵配布のためのジェネリック認証アーキテクチャの利用
US20130188651A1 (en) Mobility in ip without mobile ip
García-Martínez et al. The Shim6 architecture for IPv6 multihoming
US20090327730A1 (en) Apparatus and method for encrypted communication processing
KR100964350B1 (ko) ＩＰｖ６ 환경에서의 ＳＥＮＤ와 ＩＰＳｅｃ 협업 기법 및시스템
Henderson et al. Experience with the host identity protocol for secure host mobility and multihoming
JP2009501454A (ja) リンク管理システム
Bless et al. The underlay abstraction in the spontaneous virtual networks (SpoVNet) architecture
JP4305087B2 (ja) 通信ネットワークシステム及びそのセキュリティ自動設定方法
KR20030035587A (ko) 이동통신에서의 인터넷 프로토콜 가상 사설망 서비스처리장치 및 방법
JPWO2008114496A1 (ja) パケット通信装置
Li et al. Mobile IPv6: protocols and implementation
Sadio et al. Improving security and mobility for remote access: a wireless sensor network case
Abley et al. Considerations on the application of the level 3 multihoming shim protocol for ipv6 (shim6)
Xenakis et al. Alternative Schemes for Dynamic Secure VPN Deployment in UMTS
Abley et al. RFC 6629: Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
Mattsson Mobile Data Communication based on Host Identity Protocol (HIP)
Cabellos-Aparicio et al. Mobility Agents: Avoiding the Route Optimization Signaling on Large Servers

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130409

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20140402

Year of fee payment: 5

LAPS Lapse due to unpaid annual fee