Analysis of the IPsec Internet Key Exchange (IKE) Protocol

IPsec의 키 교환 방식에 대한 안전성 분석

Abstract

IPsec is a protocol suite to protect the data communication between computers on internet and many VPNs(Virtual Private Networks) use IPsec protocol. IKE protocol is used to exchange keys in IPsec. Formal analysis method is used increasingly in computer science to increase the reliability of a system. In this paper, the IKE protocol is analyzed formally. This paper shows that IKE with Authentication with Signature and Authentication with Pre-Shared Key is safe, but Authentication with Public Key Encryption and A Revised Method of Authentication with Public Key Encryption are safe only with the assumption that a participant has the correct public key of the correspondent. To make sure that a participant has the correct public key of the correspondent, the usage of certificate is recommended.

IPsec은 인터넷으로 연결된 컴퓨터 사이의 통신을 보호하기 위한 프로토콜로서 많은 가상 사설망 (VPN, Virtual Private Network)은 IPsec 프로토콜을 사용한다. IKE 프로토콜은 1Psec에서 키 교환을 위해 사용하는 프로토콜이다. 정형화된 분석 방법이 컴퓨터 공학 분야에서 많이 사용되고 있으며, 정형화된 분석 방법을 통하여 시스템의 안전성을 높일 수 있다. 본 연구에서는 IPsec의 키 교환 방식인 IKE 프로토콜을 정형화된 방법으로 분석하여 그 안전성을 파악하였다. 분석 결과에 의하면 전자 서명을 통하여 인증을 수행하는 IKE와 공유키를 이용하여 인증을 수행하는 IKE는 안전하게 키 교환을 할 수 있다. 그러나 공개키를 사용하여 인증하는 경우와 변경된 공개키를 사용하여 인증하는 경우에는 상대방의 공개키에 대한 확신이 필요하며 인증서를 사용함이 안전하다.

Ⅰ.서론

인터넷(internet)은 TCP/IP 프로토콜을 이용하여 통신하는 컴퓨터들이 어느 장소에서든지 네트웤을 이용하여 연결된 다른 컴퓨터와 통신할 수 있도록 해준다. 그러나 인터넷이라는 공중망(public network)을 통과하는 데이터는 공공에 노출되어있어 그 통신 내용에 기밀성이 없으며 침입자에 의해 통신 내용이 도중에 바뀔 수도 있다. 이에 대한 해결책으로 IPsec이 고안되었다. IPsec을 이용함으로써. 인증(authentication), 무-결성(integrity), 기밀성(confidentiality), 접근제어(access control). 그리고 재전송 공격 (replay attack)에 대한 보호 등의 보안 기능을 가질 수 있다(1).

IPsece IKE (Internet Key Exchange) 프로토콜(2)을 이용하여 교신하는 두 참가자 사이의 키와 필요한 정보를 교환한다. 따라서 IKE의 안전성은 IPsec의 안전성을 위하여 필수적이다. IKE는 두 단계로 나뉜다. 첫 단계는 ISAKMP SA라고 불리는 키와 정보를 교환하는 단계이며 첫 단계에서 교환된 키와 정보에 의해 암호화된 상태에서 두 번째 IKE 단계가 수행된다. 두 번째 IKE 단계에서 교환된 키와 정보에 의해 실제 교신되는 데이터가 보호된다.

정형적 분석 방법은 시스템의 안전성 분석을 위하여 그 사용이 증가되고 있다(3). 정형적인 방법을 통해 올바름이 증명된 시스템도 오류가 없다고 보장할 수는 없으나 그렇지 않은 시스템보다 안전도가 증가한다고 할 수는 있다. 정형적 방법은 보안프로토콜들의 안전성 분석을 위하여서도 사용될 수 있다. 실제 다양한 정형적 방법에 의하여 보안 프로토콜들이 분석되었다. BAN logic을 이용한 분석으로 CCITT X.509, Andrew RPC 등의 키교환의 오류가 발견되었다(4). Abstract State Machine를 이용하여 Kerberos가 분석되었으며⑸. Mur。를 이용하여 SSL 3.0이 분석되었다⑹. 또한 Denial of Service 공격 방지를 위한 프로토콜이 정형적인 방법으로 접근되었다⑺. 시스템의 안전성 분석과 마찬가지로, 이들 분석을 통하여 프로토콜의 안전성이 보장되는 것은 아니나 안전성을 증대시킬 수는 있다.

BAN logic(4)은 인증에 대한 logic으로 기본적인 키 교환의 안전성을 분석할 수 있다. IPsec의 IKE 프로토콜은 기본적인 BAN logic만을 이용하여 키교환의 안전성을 분석할 수는 없으나, BAN logic 을 확장하여 그 안전성을 분석할 수 있다. 본 고에서는 확장된 BAN logic을 이용하여 IPsec의 IKE 프로토콜의 안전성을 분석한다.

Ⅱ. IPsec의 IKE 프로토콜

I的는 크게 두 단계로 나뉜다. 첫 단계는 ISAKMP SA라고 불리는 키와 정보를 교환하는 단계이며 첫 단계에서 교환된 키와 정보에 의해 암호화된 상태에서 두 번째 IKE 단계가 수행된다. 첫 번째 단계는 인증 방법에 따라 네 가지의 방법이 있다. - 서명에 의한 인증(Authentication with Signature). 공개키에 의한 인증(Authentication with Public Key Encryption), 변경된 공개키에 의한 인증(A Revised Method of Authentication with Public Key Encryption), 그리고 공유키에 의한 인증(Authentication with Pre-Shared Key). 두 번째 IKE 단계에서 교환된 키와 정보에 의해 실제 교신되는 데이터가 보호된다. 각 키 교환 방법은 다음과 같다.

2.1 서명에 의한 인증

서명에 의한 인증 방법을 사용하는 1 단계 IKE 에서는 Diffie-Hellman 키 교환 방법'紛을 이용하여키 교환을 한다. 키 교환 후 올바른 상대방과 키를 성공적으로 교환하였음을 확인하기 위하여 교환된 정보에 전자 서명을 하여 이를 교환한다. 기본적인 프로토콜은 다음과 같다.

Initiator Responder 1： HDR. SA - 2： - 3： HDR, KE, Ni - HDR, SA 4： — 5： HDR *, IDii, - [CERTJ SIG_1 HDR, KE, Nr 6： - HDR *, IDir, [CERTJ SIG_R

여기에서 SIG_I와 SIG_Re 각각 HASHJ, HASH_R에 전자 서명⑼을 한 것이며 HASH」와 HASH_Re 각각 다음과 같이 생성된다.

SKEYID=prf(Ni_b 1 Nr.b, gxy)

HASH_I=prf(SKEYID, g"丨 g* 丨 CKY-I I CKY-R I SAi_b I IDiLb)

HASH_R=prf(SKEYID, gx, gx 1 I CKY-R I CKY-I I SAi_b I IDir_b)

2.2 공개키에 의한 인증

공개키를 사용하는 1 단계 IKE에서 키 교환은 Diffie-Hellman 키 교환 방법을 사용한다. 새로 생성된 난수가 상대방의 공개키에 의해 암호화되어 전달되며, 올바른 상대방과 성공적으로 키 교환을 하였음을 확인하기 위하여 교환된 난수를 기반으로 하여 생성된 키로 교환된 정보를 해 쉬하여 그 해쉬값을 교환한다. 다음은 공개키에 의한 인증 방법을 사용하는 1 단계 IKE의 프로토콜을 보여준다.

Initiaky Responder 1： HDR, SA —* 2： - HDR, SA 3： HDR, KE.〔HASH(1)J PubKey_r 4： -HDR, KE,

인증을 위해 사용되는 HASH」와 HASH_Re 다음과 같이 생성된다.

SKEYID = prf(hash(Ni_b I Nr_b). CKY-I I CKY-R) HASHJ=prf(SKEYID. gxi I gx, I CKY-I 丨 CKY-R SAi_b I IDii_b)

HASH_R=prf(SKEYID. gxr 丨 gxi I CKY-R ( CKY-I I SAi_b I IDir_b)

2.3 변경된 공개키에 의한 인중

변경된 공개키에 의한 인증 방법을 사용하는 1 단계 IKE에서 난수는 상대방의 공개키에 의해 암호화되어 전달된다. 키 교환은 Diffie-Hellman 키교환 방법을 사용하며, Diffie-Hellman의 공개정보는 이 난수로부터 생성된 키 (Ke_i. Ke_r)에 의해 암호화 되어 있다. 인증 방법은 공개키에 의한 인증 방법과 같다. 다음은 변경된 공개키에 의한 인증 방법을 사용하는 1 단계 IKE의 프로토콜을 보여준다.

Initiator Responder 1： HDR, SA - 2： - HDR, SA 3： HDR, [HASH(1)J - KeJ, KeJ, «Cert-I_b)Ke_i] 4： - HDR. PubKey_r. Kej\ Ke_r 5： HDR *. HASH_I - 6： - HDR *, HASH_R

다음은 인증을 위해 사용되는 HASH」와 HASH_R, 그리고 공개 정보 암호화에 사용되는 키 Ke_i와 Ke_r의 생성을 보여준다.

SKEYID=prf(hash(Ni_b I Neb). CKY-I [ CKY-R) HASH_I = prf(SKEYID, gxi I gxr I CKY-I 丨 CKY-R 1 SAi_b I IDii_b)

HASH_R=prf(SKEYID, gxr I gxi 丨 아CY-R 1 CKY-I SAi_b 丨 IDir_b)

Ne_i = prf(Ni_b, CKY-I) Ne_r = prf(Nr_b, CKY-R)

Ke_i, Ke_re NeJ, Ne_r로부터 필요한 부분을 취함으로 생성된다.

2.4 공유키에 의한 인증

공유키에 의한 인증 방법을 사용하는 1 단계 IKE 또한 Diffie-Hellman 키 교환 방법을 사용한다. 올바른 상대방과 키 교환이 정상적으로 되었음을 확인하기 위하여 공유키로부터 생성된 키로 교환된 정보를 해쉬하여 그 해쉬값을 교환한다. 다음은 공유키에 의한 인증 방법을 사용하는 1 단계 IKE의 프로토콜을 보여준다.

Initiator Responder 1： HDR, SA - 2： - HDR, SA 3： HDR. KE, Ni - 4： *- HDR. KE, Nr 5： HDR *, IDii, HASHJ - 6： L HDR *, IDir, HASH_R

인증을 위해 사용되는 HASH_I와 HASH_Re 다음과 같이 생성된다.

SKEYID=prf(pre-shared-key, Ni_b I Nr_b)

HASHJ=prf(SKEYID, gxi I gxr [ CKY-I I CKY-R I SAi_b ! IDii_b)

HASH_R=prf(SKEYID, gx, I gxl 丨 CKY-R I CKY-I I SAi_b I IDir_b)

2.5 2 단계 IKE

2 단계 IKE는 1 단계 I純에서 교환된 키와 정보에 의하여 보호된 상태에서 진행된다. 2 단계 IKE에 의해 생성된 키와 정보에 의해 실제 교환되는 데이터는 보호된다. 2 단계 IKE에서는 기본적으로 난수를 생성하여 교환하며 교환된 난수와 1 단계 IKE에서 생성된 키를 이용하여 실제 데이터 보호에 필요한 키를 생성한다. 올바른 상대방과 난수 교환이 정확히 이루어 졌음을 확인하기 위하여 해쉬 함수를 사용한다. 해쉬 함수에 사용되는 키는 1 단계 IKE 에 의해 생성된 공유키이匸" 다음은 2 단계 IKE의 프로토콜을 보여준다.

Initiator Responder 1： HDR *, HASH_1, SA, - Ni〔，KE〕L IDci, IDcr] 2： - HDR *. HASH_2, SA, Nr [.KE〕E, IDci, IDcrJ 3： HDR *. HASHJ -

인증을 위해 사용되는 해쉬 함수는 다음과 같이 구하여 진다. 해쉬 키인 SKEYID_a는 1 단계 IKE 에서 생성되어 공유된 값이다.

HASHMI =prf(SKEYlD_a. M~ID SA I Ni ( KE) ('IDci I IDcrJ )

HASH_2 = prf(SKEYID_a, MTD I Ni_b 丨 SA i Nr [| KEM I IDci I IDcr])

HASHJ = prf(SKEYID_a. 0 丨 M-ID 丨 Ni_b 丨 Nr_b)

Ⅲ. BAN logic

BAN logice 인증에 대한 logic으로. 이를 이용하여 기본적인 키 교환에 대한 안전성 분석을 할 수 있다. BAN logic의 기본적인 표기법은 다음과 같다. - believes(P. X) : P가 X를 신뢰한다. 참가자 P 가 X를 참(true)으로 여기고 행동한다.

- sees(P. X) : P가 X를 볼 수 있다. 참가자 P가 X를 포함한 메시지(X가 암호화된 경우 포함)를 받았을 때. P가 X를 판독할 수 있음(필요하면 복호화 한 후)을 의미한다.

- said(P, X) : P가 X를 말한 적 있다. 참가자 P가 메시지 X를 전송한 적이 있음을 의미한다. P가 언제 X를 말하였는지는 알 수 없으나 P가 X를 말 한 순간 P는 X를 신뢰했었음을 가정한다.

- controls(P, X) : P가 X를 관할한다. 예를 들어 한 참가자가 키를 생성할 경우 그 참가자는 그 키에 대한 관할을 한다.

- fresh(X): X가 새로 생성되었다. 즉 X가 프로토콜의 현재 사용을 위해 사용됨을 의미한다. 새로 생성된 난수가 새로움을 나타내기 위해 종종 사용된다.

- shared_key(P. Q, K): 두 참가자 P와 Q가 K 를 키(대칭키)로 공유한다. 이 경우 P와 Q 이외에는 K를 알 수 없다.

- public_key(P. K) : P가 K를 공개키로 가진다. 대응되는 비밀키(R)는 p만이 알 수 있다.

- shared_secret(P, Q. X): P와 Q가 X를 공유된 비밀정보로 가지고 있다. 이 경우 P와 Q 이외에는 X를 알 수 없다.

- {X}k: X가 키 K에 의하여 암호화되었다.

- <X)y: X가 Y와 결합되었음을 나타낸다. Y는 X 가 누구에 의하여 생성되었는지를 알리기 위해 주로 사용된다.

BAN logice 다음과 같은 법칙을 가지고 있다.

#(1)

즉. 만약 참가자 P가 K를 참가자 以와의 대칭 키로 신뢰하고. K에 의해 암호화된 메시지를 보면. P는 Q가 X를 말한 적이 있음을 믿는다.

#(2)

즉 참가자 P가 참가자 Q의 공개키를 신뢰하고 Q의 비밀키에 의해 암호화된 메시지를 보면, P는 Q가 X를 말한 적이 있음을 믿는다.

이 밖에도 다음과 같은 법 칙을 가지고 있다.

#(3)

#(4)

#(5)

#(6)

#(7)

#(8)

#(9)

#(10)

#(11)

Ⅳ. BAN logic의 확장

기존의 BAN logice 인증서와 전자 서명. 그리고 해쉬(keyed hash(MAC) 포함) 등에 대한 분석 방법을 지원하지 않는다. 따라서 이들을 지원하기 위하여 BAN logic을 확장할 필요가 있다. 본 연구에서는 이들을 지원하기 위하여 다음과 같이 BAN logic을 확장하였다. 확장된 BAN logice 인증서"“ 전자 서명门 그리고 해쉬 함수5"의 기본적인 성질을 정형화된 표기법으로 나타낸다. 다음은 확장된 BAN logic의 표기법이다.

- CERT(Q): Q의 인증서를 나타낸다. 이 인증서는 신뢰할 수 있는 인증 기관의 인증서임을 가정한다.

- signed(X)/1: X가 비밀키 K「'에 의하여 전자서명 되었음을 의미한다.

- HASH(X): X의 해쉬 (SHA, MD5 등)값을 말한다.

- MAC(X)k: X의 내용에서 키 K에 의하여 생성된 MAC을 의미한다.

- believedfP, X): P가 어느 순간 X를 신뢰했었다. 이는 said(P. X) 보나 약한 상태로 실제 X 를 전송하지는 않았으나 X에 대하여 신뢰는 하였음을 의미한다. 예를 들어 Y에 대한 전자 서명을 하여 전송한 경우. 실제 Y의 값을 전송하지는 않았으나 Y를 신뢰하였음을 알 수 있다.

또한 확장된 BAN logice 다음과 같은 법칙을 가지고 있다.

#(12)

P가 Q의 인증서筋를 받으면, A는 B의 공개키 (K)를 신뢰한다’

#(13)

#(14)

P가 Q의 공개키를 신뢰하고 Q로부터 전자 서명⑼ 된 X를 받은 경우. P는 X가 Q로부터 신뢰 되었음을 신뢰한다. Q가 해쉬한 후에 X에 전자 서명한 경우에도 같은 효과가 있다. 러나 이 경우 P는 Q가 X를 신뢰함을 신뢰하지는 못한다. 그 이유는 X는 언제 Q에 의해 서명되었는지 알 수 없기 때문이다. 또한 이 경우 Q가 X의 원문을 전송하지 않을 수도 있다.

#(15)

#(16)

P와 Q가 해쉬를 위한 키를 공유하고 P가 받은 X의 keyed hash(MAC)"' 의 값이 P가 획득한 평문(X)으로부터 생성한 keyed hash(MAC)의 값과 동일하면 P는 Q가 X를 신뢰함을 신뢰한다.

sees(P. X). sees(P, Y) - sees(P, (X. Y)) 는 성립하지 않는다. 이는 X와 Y가 독립적인 경우가 있기 때문이다. keyed hash의 경우. X와 Y가 함께 해쉬되었고 X와 Y가 독립적으로 획득되었을 경우. X와 Y가 동시에 전송되었음을 말한다. 실제 X만。로부터 전송되었고 Y는 P 자신에 의해 생성되었을지라도 Q는 X와 Y에 대한 신뢰를 한 적이있으므로 이 법칙은 본 논문의 범위 내에서는 안전하게 사용할 수 있다.

#(17)

#(18)

어떠한 값 X가 해쉬되었을 경우, 상대방이 HASH (Z에 대한 신뢰가 있음을 신뢰할 수 있으면, 상대방이 X를 신뢰함을 신뢰할 수 있다.

#(19)

#(20)

#(21)

#(22)

마찬가지 . 특수한 경우로, 상대방과의 MAC (Message Authentication Code)을 위한 공유키를 가지고 있으나 신뢰하지 못하는 경우(이 경우 MAC 키가 상대방에 의해 생성된 것임을 신뢰할 수 없으므로 MAC을 이용하여 인증할 수 없다.)에도, 상대방이 생성한 X의 MAC값에 대한 신뢰가 있으면예를 들어 전자 서명 된 경우) X에 대한 신뢰가 있다고 할 수 있다. 또한 이 경우에는 자신이 가지고 있는 공유키에 대한 신뢰를 할 수 있다.

이 밖에도,

#(23)

#(24)

도 성립한다.

v. IPsec의 분석

IKE의 5 가지 키 교환 방법을 BAN logic을 이용하여 분석하면 다음과 같다.

5.1 서명에 의한 인증

서명에 의한 인증을 사용하는 1 단계 IKE의 경우 분석에 필요한 메시지는 메시지 3. 4. 5, 6 이다. 이를 BAN logic을 위해 정형화하면 다음과 같다.

3. I - R: public_key(L Ki). N〔

4. R - I: public_key(R, KR). Nr

5. I - R: (IDi, [CERTJ SIG_I)k

6. R - I: (IDr, (CERTJ SIG_R}k

메시지 3과 4에서 Ki와 Kre Diffie-Hellman 키교환 방식⑻의 공개 정보이다. 이는 공개키 방식의 공개키에 대응되므로 자신의 공개키로 표현한다. 또한 메시지 5와 메시지 6의 암호화에 사용된 키 K 는 I와 日이 공유한 키(shared_key(I, R. K))로 I는 Ki. KF와 Kr을 이용하여 생성할 수 있으며. 日은 Kr, KG'와 Ki를 이용하여 생성할 수 있다. Kl 와 Kr을 이용하여 (Kr, KiL와 Ki를 이용하여) K를 생성함은 Diffie-Hellman 키교환 방식에 의한 공유키 생성으로 참가자 이외에는 K를 생성할 수 없음을 알 수 있다. 메시지 5와 6의 SIG_I와 SIG_Re 각각 자신의 서명용 비밀키로 HASH」와 HASH_R을 전자 서명한 것으로 그 서명용 비밀키에 대응되는 공개키는 CERT에 의해 확인 가능하다. HASH_I와 HASH_Re 각각 교환된 정보를 해쉬 (MAC)키 K로 해쉬한 것이다. 실제 사용된 해쉬키 K는 Diffie-Hellman 키교환 방식에 의해 생성된 공유키 P"메시지 5, 6의 암호화 키)와 상이하나 g"'로부터 생성되므로 편의를 위해 동일한 것으로 취급할 수 있다

키 교환이 안전하게 되었음을 알기 위하여 다음을 증명할 수 있어야 한다.

believesfl, shared_key(I, R, K)).

believestR, shared_key(I. R, K)),

believes(I, believes(R, shared-key(I, R, K))),

believes(R, believestl, shared_key(I, R, K)))

즉, 키 IKE에 의해 생성된 공유키를 자신이 신뢰해야 하며, 또한 상대방이 생성된 공개키에 대한 신뢰를 가지고 있음을 신뢰할 수 있어야 한다.

증명을 하기 위하여 몇 가지 가정이 필요하다. 이 가정은 합리적인 가정이어야 한다.

believestl, public„key(I, Ki)),

believes(R, public_key(R, Kr)),

believesfl, fresh(public_key(I. Ki))),

believesfR, fresh(public_key(R, Kr))),

believesfl. controls(R, public_key(R. Kr))).

believes(R. contiolsd. public_key(l. Ki)))

위의 가정이 의미하는 바는 다음과 같다. I와 R 모두 자신의 공개키 (Diffie-Helhnan의 공개 정보)에 대해 신뢰한다. 또한 I와 R 모두 현재의 공개 정보는 현재 세션에 생성되었음을 신뢰한다. 또한 I는 日이 日의 공개정보를 생성함을 신뢰하며 R 또한 I가 I 자신의 공개 정보를 생성함을 신뢰한다.

이러한 가정을 기반으로 다음과 같이 분석될 수 있다.

sees(R, (public_key(I, Ki), Ni))

이로부터 우리는 sees(R, public_key(I, Ki))를 얻을 수 있으며. 획득된 命와 자신의 Kr. KG'를 결합하여 shared_key(I, R, K)인 K를 생성할 수 있다.

sees(R, shared_key(I, R, K))

여기에서 shared_key(I. R, K)는 Initiator와 Responder의 공유정보이고 실제 공유키는 이 공유정보에서 생성되나 우리는 여기에서 이를 공유키로 단순화 한다.

동일한 방법으로 메시지 4에서 Initiator는 동일한아} ared_key(I, R, K)를 생성할 수 있다.

sees(I, shared_key(I, R, K))

메시지 3과 메시지 4 수행 후, sees(R. shared_key (I, R, K))와 sees(I, shared_key(I, R, K))는 얻을 수 있으나, believes(R, shared_key(I, R, K))와 believes(I. shared_key(I, R, K))는 얻지 못한다. 그러나 이 시점에 우리는 believes(R, shared_key(I. R, K))와 believes(I, shared_key (I, R. K))를 가정하여 암 . 복호화를 한다. 이 가정은 상대방의 인증을 위하여 사용될 수는 없다. (실제 키가 공유되었는 지 확인하지 못하였으므로 인증에 사용될 수는 없다. 그러나 단순한 암호화와 복호화를 위하여 사용하고 나중에 이들이 실제 공유키임을 증명할 수는 있다.)

메시지 5로부터 다음이 증명될 수 있다.

sees(R, {(ID, CERT(I), SIGJ)}K).

believes(R, shared_key(I, R. K)) -sees(R, (IDi, CERT(I), SIG_D)

sees(R, (IDi, CERT(I), SIG」))-* sees(R, IDO

sees(R, (ID, CERT(I), SIG_D) - sees(R, CERT(D) sees(R, (IDi, CERT(I). SIGJ)) - sees(R. SIG_I)

여기에서 인증서에 의한 효과에 의하여 다음을 얻을 수 있다.

sees(R, CERT(D) -* believesiR, public_key(I, Kis)) 여기에서 Kis는 I(hiitiator)의 서명을 위한 공개키이다.

SIG_I 는 Kis 를 공개키로하여 그에 대응되는 的疽을 이용한 HASH」에 대한 전자 서명이므로 법칙 (13)에 의하여 다음이 성립한다.

believes(R, public_key(I. Kis)). sees(R, SIGJ) t believes(R, believed(I. HASH」))

즉 상대방의 공개키를 신뢰하고 있으며, 그 공개키에 대응되는 비밀키에 의하여 전자 서명을 획득하면 전자 서명된 내용을 상대방이 신뢰한 적이 있음을 알 수 있다.

HASH_I는 (Ki. Kr) 등의 공유 정보를 shared, key(I, R, K)인 K를 키로 이용하여 해쉬한 값이므로, HASH」를 MAC (Ki, Kr)k 로 생각할 수 있다. 따라서 법칙 (21)에 의하여

sees(R, shared_key(I, R, K)),

believes(R. believedd, HASHJ)), sees(R, (Ki. Kr)) f believesfR. believed(I, (Ki, Ke)))

를 얻을 수 있다. 즉 공유된 MAC 키를 가지고 있고 현재 데이터에 대한 MAC을 상대방이 작성하였음을 신뢰하면. 상대방이 MAC을 작성할 당시 그 데이터를 신뢰하였음을 알 수 있다.

또한 법칙 (20)에 의하여

sees(R. shared_key(l, R. K)).

believes(R. believed(I, HASH」)), sees(R, (K, Kr)) t believes(R, 아iared_key(L R. K))

를 얻을 수 있다. 즉 공유된 MAC 키를 가지고 있고 현재 데이터에 대한 MAC을 상대방이 작성하였음을 신뢰하면. 공유된 MAC 키를 신뢰할 수 있다. 법칙 (11)에 의하여 다음이 성립한다.

believes(R. fresh(KQ) -» believes(R. fresh (Ki, Kr)) 즉 R。] Kr이 현 세션에 생성된 자신의 공개키임을 신뢰하므로 (Ki. Kr) 또한 현 세션에 사용되는 데이터임을 알 수 있다.

법칙 (25)에 의하여 다음을 얻을 수 있다. b이ieves(R believedfl, (Ki, Kr))), believes(R. fresh(Ki, Ku))

* b이ieves(R. believesd, (K:. Kr)))

즉. 상대방이 신뢰한 적이 있는 데이터가 현재 세션의 데이터이면 현재 세션에 상대방이 그 데이터를 신뢰하고 있음을 알 수 있다.

K" Kr. 그리고 K「로부터 shared_key(I, R. K) 가 생성되므로

believes(R, believes(I, (Ki. Ki;)))

—believes(R, believes(I. shared_key(I, R, K)J) 또한 성립한다.

우리는 메시지 5에서

believes(R, believesd, shared_key(I, R. K)))와

believes(R. shared_key(I. R. K))

를 증명하였다’ 동일한 방법으로 메시지 6로부터

believesfl. believes(R, shared key(I, R. K)))

와

believesd, shared_key(I. R. K)) 를 증명할 수 있다.

따라서 전자 서명에 의한 IKE 프로토콜은 인증서가 상대방의 공개키가 올바른 공개키임을 보장하면 안전한 키 교환 프로도콜이 됨을 알 수 있다.

5.2 공개키에 의한 인증

공개키에 의한 인증 방법을 사용하는 1 단계 IKE의 경우 분석에 필요한 메시지는 메시지 3. 4. 5. 6 이다’ 이를 BAN logic을 위해 정형화하면 다음과 같다.

3. 1 -» R: public_key(I, Ki). UDiIkhi\ INiIkki1

4. R -» 1: public_key(R. Ku), IIDi)k:i>. INi<Ik:i>

5. " R: IHASHJIk

6. R - I: (HASH_RIk

메시지 3과 4에서 Kj와 Kre Diffie-Hellman 키교환 방식의 공개 정보이다. 이는 공개키 방식의 공개키에 대응되므로 자신의 공개키로 표현한다. 또한 메시지 5와 메시지 6의 암호화에 사용된 키 K는 I 와 R이 공유한 키(shared_key(L R. K))로 I는 K" K「와 Kr을 이용하여 생성할 수 있으며. 日은 Kr. 와 Ki를 이용하여 생성할 수 있다. K, . K「와 Kr을 이용하여 (Kr. KrT와 Ki를 이용하여) K/를 생성함은 Diffie-Hellman 키 교환 방식에 의한 공유키 생성으로 참가자 이외에는 K를 생성할 수 없음을 간주할 수 있다. 메시지 5와 6에서 HASH」와 HASH_R에서 사용된 해쉬용 키는 암호화에 사용된 키 K와 상이하다. HASH」와 HASH_R에 사용된 키는 메시지3과 4에서 교환된 Ni와 Nr에 의해 공유된 비밀정보에 의해 생성된다’ 메시지 3과 4에서 Ni와 Nr는 각각 상대방의 공개키任Kip)에 의해 암호화되어 전송되므로 I와 R이 상대방의 올바른 공개키(공개키가 노출되지 않은 경우)를 가지고 있다는 보장이 있는 경우, I와 R만이 공유된 비밀정보 (해쉬용 키 Kh)를 가질 수 있다.

키 교환이 안전하게 되었음을 알기 위하여 다음을 증명할 수 있어야 한다.

believesd, shared_key(I. R. K)), believes(R, shared_key(I, R, K)).

believesd. believes(R, shared._key(l, R. K))). believes(R, believesd. shared_key(I. R, K))) 증명을 하기 위하여 몇 가지 가정이 필요하다.

believesd. public_key(I, Ki)).

believes(R. public_key(R. Kr)).

believesd. fresh(public_key(I, Ki))). believes(R. fresh(public_key(R, Kr))).

believesd, controls(R. public_key(I< KiJ)). believes(R. controls(丄 public_key(I. Ki)))

위의 가정이 의미하는 바는 다음과 같다. I와 R 모두 자신의 공개키 (Diffie-Hellman의 공개 정보) 에대해 신뢰한다. 또한 I와 R 모두 현재의 공개 정보는 현재 세션에서 생성되었음을 신뢰한다. I는 日이 日의 공개정보를 생성함을 신뢰하며 R 또한 I가 I 자신의 공개 정보를 생성함을 신로I한다. 위의 가정 외에도 공개키를 통하여 Ni와 Nr를 교환하기 위하여 다음과 같은 추가적인 가정이 필요하다’

believesd, public_key(R. Krp)).

believes(R, public_key(I. K「>))

이는 I는 日의 공개키 Kr”를 신뢰하며 Re I의 공개키 Km를 신뢰함을 의미한다. 이 가정 하에 메시지 3과 4에서 송신자는 상대방의 공개키로 암호화된 정보를 생성할 수 있다.

위와같은 가정하에 다음과 같은 증명을 할 수 있다.

메시지 3에서 Receiver(R)는 Initiator(I)의 공개키(Diffie-Hellman의 공개 정보)를 획득한다.

sees(R. (public_key(I, KD. N:))

이로부터 우리는 sees(R, public_key(I, Ki))를 얻을 수 있으며. 획득된 Ki와 자신의 Kh. 를 결합하여 shared_key(I. R. K)인 K를 생성할 수 있다.

sees(R, shared_key(I. R. K))

여기에서 shared_key(I. R, K)는 Initiator와 Responder의 공유정보이고 실제 공유키는 이 공유정보에서 생성되나 우리는 여기에서 이를 공유키로 여긴다.

메시지 3에서 Re 또한 IIDiIkrp. {NJkrp를 획득한다. 획득된 {NJkrp로부터 우리는 다음을 얻을 수 있다.

believes(R. public_key(R, Krp)), sees(R, {NiIkkiO -> sees(R. Ni)

그리고 획득된 Ni와 자신이 생성한 Nr를 이용하여 해쉬를 위한 공유키 shared_key(I, R, Kh)를 생성한다.

sees(R, shared_key(I, R. Kh))

이와 같은 방법으로 메시지 4에서 Initiator는 동일한 shared_key(I. R, K)를 생성할 수 있다.

sees(I, shared_key(I. R, K))

sees(I, shared_key(l. R. Kh))

메시지 3고]" 메시지 4 수행 후, sees(R, shared_key (I, R. K))와 seesd, shared_key(I, R, K))는 얻을 수 있으나. believes(R, shared_key(I, R, K)) 와 believesd, shared_key(I, R. K))는 얻지 못한다. 그러나 우리는 believestR. sharedekey (I. R, K))오]- believesd. shared_key(I. R. K)) 를 가정하여 암호화와 복호화를 한다, 이 가정은 인증을 위하여 사용될 수는 없다. 우리는 believes (I. public_key(R, Kpr))과 believes(R, public_ key(I, Kpi))라는 가정하에 (believes(R, shared_ key(I, R. Kh))와 believesd, shared_key(I. R, Kh))를 얻을 수 있으며, 실제 believesd, shared_ key(I, R, Kh))와 believesfR, 아iared_key(I, R, Kh))을 보장할 수는 없다. 하지만 I와 R이 각각 올바른 상대방의 공개키를 가지고 있다고 가정하면 I와 R외에는 공유된 Kh를 가질 수 없匸" 그리고 실제 해쉬가 검증되는 시점에서 해쉬가 검증되면 I와 R이 Kh를 공유한 것이며, 해쉬가 검증되지 않으면 Kh 를 공유하지 못하였거나 정보 교환이 올바로 되지 않은 것이다. 따라서 believesd, shared_key(I, R. Kh))와 believes(R, shared_key(I, R. Kh)) 을 가정할 수 있다.

메시지 5로부터 다음이 증명될 수 있다.

sees(R, (HASHJIk), believes(R, 아}ared_key(I, R, K)) sees(R, HASH」))

HASHJ 는 (Ki, Kr) 등의 교환된 정보를 shared. key(I, R, Kh)인 Kh를 키로 이용하여 해쉬한 값이므로, HASH」를 MAC(Ki, Kr)k로 생각할 수 있다. 따라서 법칙 (21)에 의하여 다음을 얻을 수 있다.

believes(R, shared_key(I, R, Kh)), sees(R, HASHJ), sees(R, (Ki, K曲) -* believes(R, believed(I, (Ki, Kr))) 법칙 (11)에 의하여 다음이 성립한다.

believesfR, fresh(Kn)) believes(R, fresh (Ki. Kr)) 즉 13] Kr이 현 세션에 생성된 자신의 공개키임을 신뢰하므로 (Kh Kr) 또한 현 세션에 사용되는 데이터임을 알 수 있다.

법칙 (25)에 의하여 다음을 얻을 수 있다. believes(R, believed(I, (K【, Kr))).

believes(R, fresh(Ki. Kr))

believes(R, believestl, (Ki, Kr))) -*

즉, 상대방이 신뢰한 적이 있는 데이터가 현재 세션의 데이터이면 현재 세션에 상대방이 그 데이터를 신뢰하고 있음을 알 수 있다.

Ki, Kr, 그리고 K「로부터 shared_key(I, R, K) 가 생성되므로, 다음을 얻을 수 있다.

believes(R, believestl, (Ki, Kr)))

believes(R, believes(I, shared_key(I, R, K)))

또한 상대방이 데이터를 신뢰하면, 그 데이터의 일부분을 신뢰함을 알 수 있다.

believes(R, believes(I, (Ki. Kr))) f believes(R, believes(I, Ki))

상대방이 Kr를 신뢰함을 알고 또한 상대방이 Ki를 생성하였음을 알 수 있으면, 법칙 (5)에 의하여 상대방이 Kr를 신뢰함을 알 수 있다. 따라서 다음을 얻을 수 있다.

believes(R, believes。, Ki)), believes(R, controls(I, Ki)) t believesfR. Ki)

Ki, Kr. 그리고 KE'로부터 shared_key(I, R. K) 가 생성되므로

believes(R, Ki). believes(R, Kr) —believes(R, shared_key(I, R, K)) 또한 성립한다.

우리는 메시지 5에서 believes(R, believesd, sharedekey(I, R, K))) believes(R, shared_key(I, R, K)) 를 증명하였다. 동일한 방법으로 메시지 6로부터

believesd. believes(R, shared_key(I, R, K)))

believes(I, shared_key(I, R, K))를 증명할 수 있다.

따라서 공개키에 의한 IKE 프로토콜은 Initiator 와 Responder가 각각 상대방의 올바른 공개키를 가지고 있다는 가정 하에 키 교환을 안전하게 할 수 있다. 그러나 일반적인 공개키 시스템에서 상대방의 올바른 공개키를 항상 가지고 있음을 보장하기에는 어려움이 있다. 이를 해결하기 위해서는 인증서를 이용함이 안전하다고 할 수 있다. 즉 메시지 1과 2 에서 필요한 경우 상대방에게 인증서를 보낼 수 있게 함으로써 키 교환의 안전도를 높일 수 있다.

5.3 변경된 공개키에 의한 인증

변경된 공개키에 의한 인증 방법을 사용하는 1 단계 IKE의 경우 분석에 필요한 메시지는 메시지 3, 4, 5. 6 이다. 이를 BAN logic을 위해 정형화하면 다음과 같다.

(Ni)krp. {public_key(I, Ki)}Kej. {IDiIkpj (Nr}kip. {public, key(R, KR)}Ke_r, {IDiJku {HASHJ} k

{HASH_R1k

3. I T R:

4. R - I: 5. I T R: 6. R - I:

메시지 3과 4에서 Ni와 Nr는 각각 상대방의 공개키(Krp. Kip)에 의해 암호화되어 전송된다. 이 경우 I 와 日이 상대방의 올바른 공개키(공개키가 노출되지 않은 경우)를 가지고 있다는 보장이 필요하다. Ki와 Kre Diffie-Hellman 키 교환 방식의 공개 정보이다. Diffie-Hellman의 공개정보인 public_key (I, Ki)와 public_key(R, Kr)은 대칭키 암호화 방식에 의해 암호화되어 전송된다. 실제 Diffie- Hellman 키 교환 방식은 안전하다고 간주하나 이 경우 추가적인 안전성을 주기 위해 암호화하였다. 암호화에 사용된 키는 각각 Ni와 Nr에 의해 생성된다. 또한 메시지 5와 메시지 6의 암호화에 사용된 키 K 는 I와 日이 공유한 키(shared_key(I. R, K))로 I는 Ki. 와 Kr을 이용하여 생성할 수 있으며, Re Kr, KG'와 Ki를 이용하여 생성할 수 있다. 메시지 5와 6에서 HASHJ4 HASH_R에서 사용된 해쉬용 키는 암호화에 사용된 키 K와 상이하다. HASH」와 HASH_R에 사용된 키는 메시지3과 4 에서 교환된 Ni와 Nr에 의해 공유된 비밀정보에 의해 생성된匸].. 메시지 3과 4에서 Ni와 Nr는 각각 상대방의 공개키(Krp, Kip)에 의해 암호화되어 전송되므로 I와 日이 상대방의 올바른 공개키(공개키가 노출되지 않은 경우)를 가지고 있다는 보장이 있는 경우. I와 R만이 공유된 비밀정보(해쉬용 키 Kh)를가질 수 있다.

이 경우의 분석은 공개키에 의한 인증의 경우와 동일하다.

5.4 공유키에 의한 인증

공유키에 의한 인증 방법을 사용하는 1 단계 IKE 의 경우 분석에 필요한 메시지는 메시지 3, 4. 5. 6 이다. 이를 BAN logic을 위해 정형화하면 다음과 같다.

3. I —> R: public_key(I, K【), Ni

4. R -t” I: public_key(R, Kr). Nr

5. I — R: {IDi, HASH J) k

6. R — I: (IDr, HASHER}k

메시지 3과 4에서 Ki와 Kre Diffie-Hellman 키교환 방식의 공개 정보이다. 이는 공개키 방식의 공개키에 대응되므로 자신의 공개키로 표현한다. 또한 메시지 5와 메시지 6의 암호화에 사용된 키 K는 I 와 日이 공유한 키(shared_key(I, R, K))로 I는 Ki. K「와 Kr을 이용하여 생성할 수 있으며. 日은 Kr. 와 Ki를 이용하여 생성할 수 있다. Ki, K「와 Kr을 이용하여( Kr, K「와 Ki를 이용하여) K를 생성함은 Diffie-Hellman 키 교환 방식에 의한 공유키 생성으로 참가자 이외에는 K를 생성할 수 없음을 간주할 수 있다. 메시지 5와 6에서 HASH_I와 HASH_R에서 사용된 해쉬용 키는 암호화에 사용된 키 K 와 상이하다. HASH」와 HASH_R에 사용된 키는 자신들이 공유하고 있는 공유키 Ks이다 (실제 공유키로 Ni. Nr을 해 쉬한 값이나 이를 공유키로 취급할 수 있다).

키 교환이 안전하게 되었음을 알기 위하여 다음을 증명할 수 있어야 한다.

believes(I. shared_key(I, R, K)), believes(R. shared_key(I. R, K)),

believes(I, believes(R, shared_key(I, R, K))), believes(R, believes(I, 아iared_key(I. R. K)))

증명을 하기 위하여 몇 가지 가정이 필요하다.

believes(I. public_key(I, Ki)),

believes(R, public_key(R. Kr)).

believes(I. fresh(public_key(I, Ki))),

believes(R, fresh(public_key(R. Kr))),

believes(I, controls(R, public_key(R, Kr))),

believes(R. controls(I, public_key(I, Ki)))

위의 가정이 의미하는 바는 다음과 같다. I와 R 모두 자신의 공개키(Diffie-Hellman의 공개 정보) 에대해 신뢰한다. 또한 I와 R 모두 현재의 공개키는 현재 세션에 생성되었음을 신뢰한다. I는 日이 日의 공개정보를 생성함을 신뢰하며 R 또한 I가 I 자신의 공개 정보를 생성함을 신뢰한다. 이 외에도 공유키를 신뢰한다는 다음의 가정이 필요하다.

believesd, shared_key(I. R. Ks),

believes(I. sharedekey(I, R, Ks)

메시지 3에서 Receiver(R)는 Initiator의 공개키(Dif而-버Elman의 공개 정보)를 획득한다.

sees(R, (public_key(I, Ki). Ni))

이로부터 우리는 sees(R, public_key(I, Ki))를얻을 수 있으며. 획득된 Ki와 자신의 Kr. K「를결합하여 shared_key(I. R. K)인 K를 생성할 수 있다.

sees(R. shared_key(I, R. K))

여기에서 shared_key(I. R. K)는 Initiator와 Responder의 공유정보이고 실제 공유키는 이 공유정보에서 생성되나 우리는 여기에서 이를 공유키로 여긴다. 이오 + 같은 방법으로 메시지 4에서 Initiator 는 동일한 shared_key(I. R. K)를 생성할 수 있다.

sees(I, shared_keyU, R, K))

메시지 3과 메시지 4 수행 후, sees(R. shared. key(I, R, K))와 seesd, shared_key(I, R. K)) 는 얻을 수 있으나, believes(R. shared_key(I, R, K))와 believesd, shared_key(I, R, K))는 얻지 못한다’ 그러나 이 시점에 우리는 believesfR, shared_key(I, R, K))오]" believesd, shared_key (I. R. K))를 가정하여 암호화와 복호화를 한다. 메시지 5로부터 다음이 증명될 수 있다.

sees(R. UDi.

b이ieves(R shared_key(L R, K)) -seesfR. HASHJ)

HASH」는 任“ Kr) 등 교환된 정보를 shared. key(I. R, Ks)인 給를 키로 이용하여 총!]쉬한 값이므로

believes(R, sharedekeyfl, R. K"), seesfR. HASH」)’ sees(R. (Kj. Kr)) -believes(R. believedd. (Ki. KiJ))

believes(R, freshiKiJ) b야ieves(R, fresh(K[, Kr)) believes(R. believedd, (Ki, K”))),

believes(R, fresh(Ki, Kr))

- believes(R, believesd. (K【, Ki;)))

가 성립함을 알 수 있다. (5.1 절 참조)

Ki, Kr, 그리고 K「'로부터 shared_key(L R. K) 가 생성되므로 다음이 성립한다.

believesfR. believesd, (Ki. Ku)))

t believesfR. believesd, shared_key(l. R. K))) 또한

believes(R. believesd, (Ki, Kh))) f believes(R, believesd, K;))

believes(R. believesd. Ki)), believes(R. controlsd. K:)) …believes(R, K))

또한 성립한다. (5.2절 참조)

Ki. Kr. 그리고 로부터 shared_key(L R. K)가 생성되므로

believes(R, Ki), believes(R, Kr)

t believesfR, shared_key(I. R. K)) 또한 성립한다.

우리는 메시지 5에서

believes(R, believesd, sharedekeyd, R, K))) believes(R, shared_key(I, R, K)) 를 증명하였다. 동일한 방법으로 메시지 6로부터

believesd, believes(R. shared_key(I, R, K)))

b이ieves(I. shared_key(I. R, K)) 를 증명할 수 있다.

따라서 공개키에 의한 IKE 프로토콜은 Initiator 와 Responder가 공유키를 안전하게 유지하면 안전하게 키 교환을 한다고 할 수 있다.

5.5 2 단계 IKE

2 단계 IKE의 경우 BAN logic으로 분석하기 위하여 정형화하면 다음과 같다.

1.I — R: SA. Ni)Ik

2. R - I: ((HASH_2. SA. Nr))k

3. 1 R: (HASH_3!k

2 단계의 모든 메시지는 1 단계에서 생성한 공유키 辭] 의하여 암호화 되어있다. HASH」은 Ni의 값을 공유키 K로 해쉬한 값이며 HASH_2는 Ni와 Nr의 값을 공유키 K로 해쉬한 값이며, HASH_3 도 Ni와 Nr의 값을 공유키 K로 해쉬한 값이다 (실제 조금의 변화가 있으나 그렇게 단순화 할 수 있다). 2 단계에서는 1 단계에 성공적으로 K를 공유 하였음을 가정한다. Ni와 Nr이 안전하게 교환되었음을 보이기 위해 우리는 다음을 증명하여야 한다.

believes(I. Ni), believesd. Nr).

believesd, believesfR. Ni)),

believesd, believesfR. Nr)),

believes(R, Nh).

b이ieves(R, Ni).

believes(R, believesd, Nr0),

b이ieves(R, believes(I. Ni))

우리는 다음의 가정을 할 수가 있다.

b시ieves(l, Ni),

believes(R, Nr).

believesfl, fresh(Nil). believes(R, f'resh(Ni{)).

believesd. shared_key(I. R. K)).

believesfR. shared_key(I. R, K)),

believesd. controls(R. Nr)),

believes(R, contr이s(I. N;))

위 가정에 의하여 다음과 같이 증명될 수 있다. 메시지 1에서 日은 {(HASH」. SA. IW)}k를 획득한다.

believes(R. shared_key(I, R. K)),

sees(R, {(HASH」, SA. N)}k)- sees(R. Ni) (believes(R, said(l. N, ))도 획득)

日은 Ni를 볼 수 있다. 이 시점에서 日은 Ni를 신뢰하는 것으로 가정한다. (후에 증명하여야 한다). 메시지 1에서 believes(R, N[)를 획득한다.

메시지 2에서 I는 f(HASH_2, SA, Nr)}k를 획득한다.

believesd, shared„key(I, R. K)).

seesd, !(HASHe2. SA, Nb)}k)— seead. HASH_2) believesd. shared_key(I, R, K)),

sees(I, l(HASH_2, SA. Nu)1k)seesfl. NG believesd. shared_key(I. R. K)).

sees(I. HASH_2). seesd. Nr), seesfl, Ni) —believesd, believecl(R. (N;, Nr)))

believesd. fresh(Ni)) — believesd, fresh(Ni, N代)) believesfl. believed(R. (Ni, Nr)), believesd, fresh(NO) -, believesd. believesfR. (Ni. Nr)))

believesd, believesfR. Ni. Nij)

— b이ieves(L believes나t. Nil) believesd, believesfR. Ni. NiJ) believesd, believes(R. NiJ)

believesd, believes(R. Nr)).

believesd. controls(R, Nr)) believesd. Nr)

메시지 3에서 Re {HASH_3}k들 획득하여 메시지 2에서와 같은 방법으로

believes(R. believesfl. Ni)) believes(R, believesd, 鬲)) believes(R, Ni)

를 얻을 수 있다. 따라서 1 단계 IKE가 안전하다고 가정하면, 2 단계 IKE는 안전하게 키 교환을 수행한다.

Ⅵ 결론

본 연구에서는 IPsec의 IKE 프로토콜을 BAN logic을 이용하여 정형적으로 분석하였다. IP sec 을 지원하기 위하여 BAN logice 인증서의 경우와 전자서명. 그리고 keyed-hash(MAC)의 경우를 지원하기 위하여 확장되었다. IPsec의 분석 결과 전자서명을 통하여 인증 하는 IKE 1 단계는 안전하게 키 교환을 한다. 공유키를 사용하여 인증 하는 경우에도 공유한 키가 침입자에게 노출되지 않는 경우 안전하게 키 교환을 할 수 있다. 공개키를 사용하여 인증을 수행하는 경우와 변경된 공개키를 사용하는 경우 상대방의 공개키에 대한 신뢰가 있는 경우에 안전하다. 일반적으로 상대방의 공개키에 대한 신뢰를 항상 할 수는 없으므로 공개키를 사용하여 인증 하는 경우와 변경된 공개키를 사용하여 인증 하는 경우 인증서를 사용함이 안전하다고 할 수 있다.

BAN logic을 이용한 분석은 참가자들 사이의 키 분배를 효율적으로 분석할 수 있으나, 기밀성, Denial of Service 공격 방지 등 그 외의 특성은 분석할 수 없다. 암호 알고리즘, 해쉬, 전자 서명 등의 안전성 또한 BAN logic의 분석 범위를 벗어난다. BAN logic으로 분석될 수 없는 부분은 그들 특성을 지원하는 분석 방법에 의하여 추가적인 분석이 필요하다. BAN logice 최근의 다양한 프로토콜을 지원하지 못한다. 본 연구에서는 BAN logic을 필요에 따라 확장하여 사용하였다. IPsec의 IKE 프로토콜뿐만 아니라 다양한 최근의 프로토콜을 지원하도록 BAN logic의 확장이 필요하다.

* 본 연구는 2000년도 한림대학교 학술연구조성비에 의하여 수행되었습니다.