초록이 없습니다.

AI 본문요약

엑셀 다운로드 AI-Helper

* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.

• 연구 주제
• 연구 방법
• 연구 결과

문제 정의

• 모바일 IP는 IETF(Intemet Engineering Task Force) 의 mobileip(IP Routing for Wireless/Mobile Hosts) 작업반에 의해 개발된 프로토콜로서, 위치를 이동하여 인터넷 접속점을. 변경하는 노드가 인터넷상의 다른 노드들과의 통신을 계속할 수 있도록 지원하는 것을 목표로 하고 있다. 이러한 이동은 한 장소에서 인터넷에 연결되어 통신을 하다가 모든 접속을 종료한 후 새로운 장소에서 다시 인터넷에 연결되는 일반 노트북 사용자의 경우와는 다르며, 모든 접속 환경의 변화와 동적인 연결 유지가 자동적으로 이루어져야 한다.
• IPv6에서의 라우팅 헤더 옵션(RHOpt; Routir吗 Header Option)과 Wv访를 위한 홈 어드레스 옵션 (HAOpt; Home Address Option)은 MIPv6의 지원에 있어 중요한 기능들인데, 이들의 사용이 제약되지 않을 경우 방화벽의 보안 기능을 우회하거나 공격 행위에 대한 패킷 역추적을 방해하는 등의 보안 문제를 발생시킬 수 있다. 이 절에서는 Savoia가 제출한 인터넷 드래프트[1기의 내용을 중심으로 관련 보안 문제들과 해결 방안을 살펴본다.

가설 설정

• RR 방식의 메커니즘 중의 하나인 BAKE(Binding Authentication Key Establishment)는 그림 3과 같은 3개의 메시지를 이용하여 BU 인증에 사용될 암호키를 확립하는데, HA와 MN 사이에 보안을 위한 SA가 확립되어 있다고 가정하며 이를 활용한다.

제안 방법

• BU/BA 보호를 위해 제안된 보안 메커니즘은 기본적으로 BUI 보내기에 앞서 BU를 보호하기 위한 키 또는 SA를 확립하는 절차를 두고, MN과 CN 사이에 확립된 공유 비밀키를 사용하여 BU를 보호하는 방식을 사용한다. 보호의 내용은 송신자 인증, 데이터 무결성, 재전송 방지 등이며 기밀성 제공도 가 능하지만 현재 기밀성 추가의 이점은 명확하게 밝혀져 있지 않다.
• 본 고에서는 먼저 바인딩 갱신과 관련 보안 문제, 그리고 해결 방안으로서의 바인딩 갱신 인증을 위한 제안들을 살펴보고, 다음에 라우팅 헤더와 홈 어드레스 옵션에 관한 보안 문제를 논의한다.
• 제안된 대책은 RH 옵션 처리 기능을 제한적으로 사용하는 것인데, 트래픽 엔지니어링을 위한 RH 옵션 처리 기능은 라우터만이 필요로 한다. 그런데, MIP出는 모든 노드에 RH 옵션 처리 기능을 요구하는 것이 문제이지만, MIPv6의 경우 경유지 노드는 1개만이 필요하므로 경유지 목록 크기가 1보다 큰 경우 패킷을 폐기하는 방법이 적용될 수 있다.
• 제안된 대책은 홈 어드레스 옵션을 포함하여 패킷이 인증되어 있는 경우와 (CoA, HoA어】 대한 인증 된 바인딩이 존재하는 노드에서만 홈 어드레스 옵션을 처리하도록 제한하여 조작된 홈 어드레스 옵션의 사용을 방지하는 방법이다.
• 그리고, 이들 제안들은 BU 메시지를 송신하는 MN에 대한 실체 인증은 하지 않고 있다. 현재 제안되어 있는 8개의 BU 보안 메커니즘은 표 1에서와같이 크게 3종류로 구분될 수 있으며, 이들을 차례대로 살펴보자.

대상 데이터

• 현재 IETF mobileip 작업반에서 토의되고 있는 공 식 작업반 인터넷 드래프트에는 18개 문서가 있으며, 이들 외에도 개인적으로 제안된 8개 문서가 있다. 이들 중 가장 핵심적인 문서가 “Mobility Support in IPv6(draft-ietf-mobileip-ipv6T5.

이론/모형

• 이것은 PBK의 EID 전달 방식에 비교할 때, MN이 해당 공개키의 소유주 임을 MN과의 모든 메시지 교환에서 확인할 수 있다는 점과 또 그 값이 주소에 포함되어 있어 별도의 대역폭을 차지하지 않는다는 장점을 제공한다. SUCV 는 BU 보호를 위한 비밀키는 Diffie-Hellman 키 교환 방식을 사용해서 생성하며, CN이 Diffie-Hellman 키 교환 상대에 대한 인증을 위해 MN이 만들어 보낸 공개키 서명을 확인하는 방식을 사용하며, 또한 CN이 MN에게 보내는 Diffie-Hellman 공개 값은 HA를 경유하게 함으로써 부분적인 경로 검증까지 사용한다. 그리고, BU 보호는 IPsec ESP(Encap- sulating Security Payload) 방식을 사용한다.
• SUCV 는 BU 보호를 위한 비밀키는 Diffie-Hellman 키 교환 방식을 사용해서 생성하며, CN이 Diffie-Hellman 키 교환 상대에 대한 인증을 위해 MN이 만들어 보낸 공개키 서명을 확인하는 방식을 사용하며, 또한 CN이 MN에게 보내는 Diffie-Hellman 공개 값은 HA를 경유하게 함으로써 부분적인 경로 검증까지 사용한다. 그리고, BU 보호는 IPsec ESP(Encap- sulating Security Payload) 방식을 사용한다.
• 세 번째 유형의 BU 보안 메커니즘에서는 BU 보호를 위해 Diffie-Hellman 키 교환 방식을 통해 확립된 암호키를 사용한다. DHMIPv6(Diffie-Hellman based key distribution for MIPvS)에서는 MN과 CN이 각각 Diffie-Hellman 공개 값을 상대방에게 전달하는데, MN에게 보내는 메시지는 HA를 경유하여 전달된다’ 이 방식은 공개키 서명과 공개키 해쉬 값을 이용한 MN의 주소 지정 등을 제외하면 앞 절의 SUCV 와 유사하다.

성능/효과

• MN이 다음 접속 지로 이동한 후 등을면, CNe EID 에 해당하는 공개키를 사용하여 서명을 확인할 수 있으며, 따라서 BU 메시 지를 보낸 노드가 이전에 EID를 보냈던 그 노드임을 확인할 수 있다.
• 또한, 메 시지 ③에 포함된 토큰 TO는 이 메시지를 보내는 MN이 메시지 ①을 보낸 MN과 동일한 노드라는 사실을 확인 시켜 준다. 이를 요약하면, 위의 프로토콜을 통해 CNe HA7} 그 정체를 보장하는 MN과 통신하고 있음을 확인할 수 있다는 것이다. BU 보호에 사용될 암호키 BK(BU Key)는 해쉬 알고리즘 MD5를 사용하여 다음과 같이 계산된다.

후속연구

• PBK는 BU 메시지를 보낸 노드의 실체에 대해서는 전혀 확인할 수 없지만, 이전에 HoA라는 홈 어드레스를 갖는 것으로 알고 있던 노드에서 메시지가 왔다고 믿는다는 것이 그 원리이다. 그리고, EID를 여러 번 보냄으로써 EID 의 손실이나 EID 조작 공격을 막는 효과를 기대한다. 그러나, PBK는 현재 접속지에서 CN과 MN 사이의 신뢰를 가정하는데, 최초의 접속 시에는 사전 신뢰를 확보하는 방법이 명시되어 있지 않으며, MN과 HA 사이에 사전 확립된 SA를 활용하지 않는다는 단점도 있다.
• 그리고, 라우팅 헤더 옵션과 홈 어드레스 옵션 등이 초래하는 보안 문제에 대해서도 여러 다른 대책이 검토되고 있으며, 다른 파생 문제들이 더 나타날지는 좀 더 시간을 두고 분석되어야 할 것으로 평가된다. 무엇보다도 는 아직 본격적으로 배치되어 검 증된 것이 아니어서 또 다른 형태의 결정적인 보안 취약점이 새로 나타날 가능성을 배제할 수 없다.

본문요약 정보가 도움이 되었나요? 예 아니오 제출

이 논문을 인용한 문헌

더보기

저자의 다른 논문 :

이광수 (5)