KR20010097608A - 웹 보안 프로토콜을 이용한 통신방법 - Google Patents

Abstract

본 발명은 TCP/IP와 같은 연결지향적인 네트워크 계층과 HTTP와 같은 어플리케이션 프로토콜 계층 사이에 위치하는 프로토콜 계층에 사용되는 보안프로토콜에 관한 것으로, 상호 인증, 무결성을 위한 전자서명의 사용, 프라이버시를 위한 암호화 등을 이용하여 클라이언트와 서버간의 안전한 통신을 제공하는 웹 보안 프로토콜을 이용한 통신 방법에 관한 것이다.

Description

웹 보안 프로토콜을 이용한 통신방법{Communicating Method Using Web Security Protocol}

본 발명은 웹 보안 프로토콜을 이용한 통신방법에 관한 것이다.

상기 웹 보안 프로토콜은 인터넷 통신 상에서 TCP/IP와 같은 연결 지향적인 네트워크 계층과 HTTP와 같은 어플리케이션 프로토콜 계층 사이에 위치하는 프로토콜 계층으로 상호 인증, 무결성을 위한 전자서명의 사용, 프라이버시를 위한 암호화 등을 이용하여 클라이언트와 서버간의 안전한 통신을 제공함으로써 원치 않는 제3자가 통신의 내용을 누출하여 가로챌 수 없도록 하며, 또한 믿을 수 없는 통신상의 양자에 대한 상호 인증 기능을 제공함으로써 네트워크 상의 양자가 서로 믿고 통신할 수 있도록 하는 것이다.

현재 전 세계적으로 실질적인 표준으로 사용하고 있는 웹 보안 프로토콜은 네스케이프(Netscape)사의 SSL(Secure Socket Layer, 이하 SSL) 및 TLS(Transport Layer Security, 이하 TLS) 프로토콜이며, 현재까지 발표되어 있는 SSL 프로토콜은 표1과 같다.

버젼	소오스	설 명
SSL v2.0	Vendor Standard(from Netscape Corp.)[SSL2]	실제로 구현이 이루어진 첫번째 SSL 프로토콜
SSL v3.0	Expored Internet Draft(from Netscape Corp.)[SSL3]	기존 SSL v2.0 프로토콜에 몇가지 특정 보안 공격을 막기 위한 개선, RSA 이외의 암호기능의 추가, 인증서 체인 기능의 추가 등이 이루어짐
TLS v1.0	Proposed InternetStandard (from IETF)[TLS1]	SSL v3.0의 버전기존의 SSL v3.0에서 MAC 계층을 HMAC으로 변경, 블럭패딩 추가, 다양한 경고 메시지 추가 등이 이루어짐

상술한 SSL 프로토콜의 구현 목표를 간단히 설명하면, SSL은 두 통신 주체간의 안전한 연결을 성립시키기 위해 사용되는 암호학적인 보안과, 서로 독립적인 프로그래머들이 서로의 코드에 대하여 아무것도 알 수 없는 상태에서도 암호학적인 매개변수를 성공적으로 교환할 수 있는 SSL 어플리케이션을 작성할 수 있도록 하는상호조작 가능성과, 필요에 따라 새로운 공개키와 새로운 암호기법을 적용할 수 있는 구조를 제공하며, 이러한 구조를 제공함으로써 새로운 공개키나 암호 기법을 적용 할 또 다른 새로운 프로토콜을 설계하거나 새로운 보안 라이브러리를 구현하지 않도록 해주는 확장성과, CPU의 점유율이 높은 암호화 연산을 위해 부가적인 세션 캐싱(session caching) 구조를 제공하여 성립되어야 할 커넥션의 수와 네트워크 점유율을 줄여주는 상대 능률 등을 구현하는 것을 목표로 한다.

도1은 상기 SSL 프로토콜의 계층 모델을 나타낸 것으로, SSL 프로토콜은 웹을 위한 HTTP 뿐만 아니라 텔넷(Telnet), FTP 등과 같은 다른 어플리케이션 프로토콜에서의 암호화 통신에도 적용 가능하다.

상기 SSL 프로토콜은 암호화, 다이제스트, 서명을 위해 사용되는 알고리즘을 선택할 수도 있도록 디자인 되어 있다. 이것은 특정 웹 서버에서 암호 알고리즘을 선택할 때 법적인 문제나 수출법과 같은 문제를 고려하여 선택할 수 있도록 해준다. 사용할 알고리즘의 선택은 SSL 프로토콜 세션이 시작될 때 핸드쉐이크(Handshake) 과정을 통하여 클라이언트와 서버 간의 협상에 의해 선택하게 된다.

도2는 웹상에서 구현된 SSL 프로토콜의 동작모델을 나나탠 것으로, SSL의 동작 개념은 통신하고자 하는 응용 실체 사이에 특별히 설계된 소켓 루틴들을 사용하여 먼저 안전한 통신 채널을 확립한 다음, 확립된 안전한 통신 채널을 통하여 정보를 교환할 수 있도록 하는 것이다. 상기 안전한 채널을 확립하기 위해 소켓 루틴은 공개키 암호화를 이용하여 통신 양자에 대한 인증과 세션키 교환 과정을 수행하며, 키 교환 과정을 통해 공유되는 세션키를 이용하여 대칭키 암호통신을 하게 한다. 웹 클라이언트와 서버 사이에서는 정규 HTTP 프로토콜에 의한 접속이 이루어지며, 이 HTTP 메시지는 통신망을 경유하여 전달될 때 하위 SSL 계층의 암호화 통신에 의해 암호화되어 보호되게 된다.

상술한 SSL 프로토콜의 구성 요소들은 세션 생성, 키 교환 방법(Key Exchange Method), 데이터 전송을 위한 암호화, 다이제스트 함수, 레코드 프로토콜 등로 구성된다.

상기 세션 생성에서 SSL 세션은 도3과 같이 클라이언트와 서버 간의 핸드쉐이크 과정에 따라 이루어진다. 상기 핸드쉐이크 과정은 서버가 서버 인증서를 제공하느냐, 또는 클라이언트 인증서를 요구하는가에 따라 잘라질 수 있으며, 암호 정보의 관리를 위해 부가적인 핸드쉐이크 과정이 요구되는 경우도 있다. 일단 이루어진 SSL 세션은 다시 재사용 할 수 있으며, 이로 인하여 세션을 시작하기 위해 필요한 많은 단계들을 반복함으로써 발생하는 퍼포먼스 하락을 피할 수 있다. 재사용 기능을 위하여 서버는 각 SSL 세션마다 유일한 세션 구분자를 할당하며, 이 구분자는 서버에 저장되어서 이후에 클라이언트가 다시 연결할 때 이를 사용하게 된다. 상기 핸드쉐아크 과정의 각 단계는 데이터 전송을 사용할 칩퍼 슈트(Cipher Suite)를 형상하는 단계와, 클라이언트와 서버간의 세션키를 교환하는 단계와, 부가적으로 서버간의 세션키를 인증하는 단계와, 부가적으로 서버가 클라이언트를 인정하는 단계로 이루어진다.

다음에 키 교환방법은 어플리케이션 데이터의 전송에 사용할 공유 비밀키를 어떻게 클라이언트와 서버간에 공유할 것인가를 정의한다. 표1의 SSL 2.0은 RSA 키 교환만을 지원하지만 SSL 3.0은 두가지 키 교환 알고리즘(RSA 키 교환, Diffie-Hellman 키 교환)중 선택할 수 있도록 지원한다. RSA 키 교환은 인증서가 사용되는 경우에 선택되며, Diffie-Hellman 키 교환은 인증서가 없고 클라이언트와 서버간의 통신이 이전에 한번도 없는 경우에 선택한다.

다음에 상기 데이터 전송을 위한 암호화는 SSL 대칭형 암호화를 사용하며, 암호화의 방법은 암호화를 하지 않는 경우를 포함해서 모두 9가지의 선택이 가능하다. 그 9가지는 아래 나타낸 바와 같다.

·암호화 하지 않음

·스트림 암호화

- 40비트 키를 가지는 RC4

- 128비트 키를 가지는 RC4

·CBC 블록 암호화

- 40비트 키를 가지는 RC2

- 40비트 키를 가지는 DES

- 54비트 키를 가지는 DES

- 168비트 키를 가지는 3중 DES

- 128비트 키를 가지는 IDEA

- 96비트 키를 가지는 Fortezza

다음에 메시지 다이제스트 함수는 데이터로부터 다이제스트가 생성되는 방법을 결정하며, SSL은 다이제스트 적용 안함(Null shoice); 128비트 해쉬(Hash) 값으로 생성한 MD5; 160비트 해쉬 값으로 생성한 SHA-1과 같은 다이제스트 함수들을 지원한다. 메시지 다이제스트는 MAC(Message Authentication Code)를 생서하는데 사용된다. MAC은 메시지와 함께 암호화됨으로써 메시지의 무결성을 제공하며 또한 릴레이 공격(replay attack)을 막아준다.

다음에 SSL 레코드 프로토콜은 도4에 도시된 바와 같이 어플리케이션 데이터와 SSL 관련 데이터를 작은 조각으로 쪼개거나, 혹은 상위 계층의 프로토콜 데이터 메시지를 하나의 유니트(unit)로 결합하여 클라이언트와 서버 간에 전송하는 역할을 한다.

상술한 바와 같은 SSL 프로토콜은 미국에서 구현된 웹 보안 프로토콜로서 미국의 수출 제한법으로 인하여 SSL 프로토콜을 적용한 암호 제품 중 국내에 수입될 수 있는 것은 낮은 암호 수준을 가지는 제품들 뿐이며, 또한 핵심 암호 기술에 대한 규제로 인하여 국내에서 개발한 암호 알고리즘 등의 암호 기술을 종래 SSL 프로토콜을 채택하거나 이용할 수 있는 방법이 없다는 문제점이 있었다.

따라서, 현재 웹 보안에 주로 사용되는 보안 프로토콜인 SSL/SHTTP 프로토콜이 주로 외국산 암호화 알고리즘을 이용하여 보안 통신을 구현하고 있으므로 인해 국가적인 정보 보안의 취약성 요인이 되고 국가적 정보 경쟁력 향상을 위해 이를 국산 암호 알고리즘으로 대체하여야 할 필요가 있다.

또한, 일반적으로 종래의 SSL 알고리즘는 대부분 8바이트의 IV(Initial Vector)를 사용한다. 하지만 국산 알고리즘인 SEED는 16 바이트의 IV를 사용하기 때문에 SEED를 적용하기 위해서는 SSL의 IV 사이즈를 16 바이트로 확장할 필요가 있다.

SSL 프로토콜에서 클라이언트가 생성한 pre_master_secret으로부터 비밀키, IV 등을 생성하기 위한 Master_secret을 생성하는 과정은

master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('BB' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('CCC' + pre_master_secret +

ClientHello.random + ServerHello.random));

이다.

상기와 같이 생성된 Master_secret는

key_block = MD5(master_secret + SHA('A' + master_secret +

ServerHello.random + ClientHello.random)) +

MD5(master_secret + SHA('BB' + master_secret +

ServerHello.random + ClientHello.random)) +

MD5(master_secret + SHA('CCC' + master_secret +

ServerHello.random + ClientHello.random));

과정을 통하여 48 바이트의 key_block을 생성하게 된다.

여기서 MD5는 128비트, 즉 16바이트의 결과를 내므로 key_block은 48 바이트가 된다. 이렇게 생성된 key-block은 client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key, client_write_IV , server_write_IV 등 여섯개의 값으로 나눠진다.

여기서 48 바이트의 key_block을 6개의 값으로 나눔에 따라 SSL에서의 IV의 사이즈는 8바이트가 된다. 그러나 SEED의 경우 16 바이트의 IV를 사용하므로 SSL에 적용할 수 없다. 따라서 본 발명에 따른 웹 보안 프로토콜에서는 IV 벡터 필드의 사이즈를 16 바이트로 확장함으로써 SEED 알고리즘을 적용할 수 있도록 한다.

따라서 본 발명은 종래의 SSL 프로토콜에 국산화 알고리즘을 적용하여 종래 SSL 프로토콜과 호환가능한 국산 웹 보안 프로토콜을 구현하는 것을 목적으로 한다.

상기 목적을 달성하기 하기 위하여 본 발명은 암호화 알고리즘을 포함하여 클라이언트와 서버간의 비밀을 유지하기 위한 통신방법에 있어서, 클라이언트가 서버에게 '클라이언트 헬로(Client Hello)' 메시지를 전송하는 단계와; 상기 메시지를 전송받은 서버가 '클라이언트 헬로' 메시지에 포함된 세션 아이디를 세션 캐쉬(cache)에서 찾는 단계와; 상기 세션 아이디가 세션 캐쉬에 없으면 서버에서세션 아이디를 새로이 생성하여 클라이언트에게 '서버 헬로(Sever Hello)' 메시지를 전송하고, 세션 아이디가 세션 캐쉬에 있으면 바로 '서버 헬로' 메세지를 전송하고 자신의 인증서(certificate)를 전송하는 단계와; 서버로부터 전송된 인증서를 확인하여 서버가 비익명성(non-anonymous) 서버인지를 판단하는 단계와; 상기 서버가 비익명이라면 서버는 클라이언트에게 'Certificate Request' 메시지를 보낸 다음 '서버 헬로 Done' 메시지를 전송하고, 서버가 비익명이 아니라면 바로 클라이언트에게 '서버 헬로 Done' 메시지를 전송하는 단계와; 상기 서버가 클라이언트에게 인증서를 요구하였는가를 판단하여, 요구하였다면 클라이언트는 서버가 자신의 인증서를 전송한 후, '클라이언트 키 익스체인지(Client Key Exchange)' 메시지를 보내고, 요구하지 않았다면 클라이언트는 서버에게 바로 '클라이언트 키 익스체인지' 메시지를 전송하고 이어서 'Chahge CipherSpec' 메시지와 'Finished' 메시지를 전송하는 단계와; 상기 클라이언트로부터 'Finished' 메시지를 전송받은 서버도 클라이언트에게 'Finished' 메시지를 전송하는 단계와; 상기 서버는 클라이언트로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 받았다면 클라이언트도 서버로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 수신하였다면 클라이언트와 서버간에 암호화된 어플리케이션 데이터를 주고받는 단계를 포함하는 것을 웹 보안 프로토콜을 이용한 통신방법을 특징으로 한다.

도1은 종래의 웹 보안 프로토콜인 에스에스엘(SSL) 계층 모델을 나타낸 도면.

도2는 웹 상에서 구현된 종래의 웹보안 프로토콜인 SSL 프로토콜의 동작 모델을 도식화한 도면.

도3은 종래의 웹 보안 프로토콜인 SSL 프로토콜의 핸드쉐이크(Handshake)과정을 나타낸 도면.

도4는 종래의 SSL 레코드 프로토콜을 나타낸 도면.

도5는 본 발명에 따른 웹 보안 프로토콜인 케이에스에스엘(KSSL) 프로토콜을 이용한 통신방법의 흐름을 나탄낸 도면.

본 발명은 종래의 SSL 프로토콜과 완벽하게 호환되면서 정보통신부가 발표한국산 블록 암호 알고리즘인 SEED와 국산 스트림 암호 알고리즘인 EGIS 등의 국산 암호 알고리즘을 쉽게 적용할 수 있는 개방형 구조의 프로토콜이며, 미국의 암호 규제법의 영향을 받지 않는 높은 암호수준의 웹 보안 프로토콜로서, 본 발명에서는 KSSL이라 명명한다.

이하, 첨부된 도면을 참조로하여 본 발명을 상세히 설명하기로 한다.

도2와 도3은 본 발명에 따른 KSSL 프로토콜이 실제로 동작하는 과정을 나타낸 것으로, 먼저 클라이언트가 서버에게 '클라이언트 헬로' 메시지를 전송한 다음, 상기 메시지를 전송받은 서버가 '클라이언트 헬로' 메시지에 포함된 세션 아이디를 세션 캐쉬에서 찾는다. 다음에 상기 세션 아이디가 세션 캐쉬에 없으면 서버에서 세션 아이디를 새로이 생성하여 클라이언트에게 '서버 헬로' 메시지를 전송하고, 세션 아이디가 세션 캐쉬에 있으면 바로 '서버 헬로' 메세지를 전송하며 자신의 인증서를 전송하고, 상기 서버로부터 전송된 인증서를 확인하여 서버가 비익명인지를 판단한다. 다음에 상기 서버가 비익명이라면 서버는 클라이언트에게 인증서를 요청한 다음 '서버 헬로 Done' 메시지를 전송하고, 서버가 비익명이 아니라면 바로 클라이언트에게 '서버 헬로 Done' 메시지를 전송한 다음, 상기 서버가 클라이언트에게 인증서를 요구하였는가를 판단하여, 요구하였다면 클라이언트는 서버가 자신의 인증서를 전송한 후, '클라이언트 키 익스체인지' 메시지를 보내고, 요구하지 않았다면 클라이언트는 서버에게 바로 '클라이언트 키 익스체인지' 메시지를 전송하고 이어서 'Change CipherSpec' 메시지와 'Finished' 메시지를 전송한다. 다음에 상기 클라이언트로부터 'Finished' 메시지를 전송받은 서버도 클라이언트에게'Finished' 메시지를 전송하고, 상기 서버는 클라이언트로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 받았다면 클라이언트도 서버로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 수신하였다면 클라이언트와 서버간에 암호화된 어플리케이션 데이터를 주고받게 된다.

상기 각 과정을 좀더 상세히 설명하면, 먼저 'Client Hello' 과정으로 SSL 세션을 시작하기 위해 클라이언트가 서버에게 'Client Hello' 메시지를 전송하는데, 이때 프로토콜 버전, 인증에 사용하기 위해 클라이언크가 생성한 랜덤 구조체, 세션을 구분하기 위한 세션 ID, 클라이언트가 지원하는 암호 규격들을 정의하는 암호화규격(CipherSuite), 클라이언트가 지원하는 압축방법들을 정의하는 압축방법 (Compression Method) 등의 암호 속성들에 대한 정보를 포함하여 서버로 전송한다. 이때, KSSL은 서버로 전송하는 암호화규격에 'SEED-CS|BC-SHA', 'SEED-CBC-MD5', 'EGIS-SHA', 'EGIS-MD5'의 네가지 암호화규격를 추가하여 전송한다. 상기와 같이 'Client Hello' 메시지를 보낸 후 클라이언트는 'Server Hello' 메시지를 받을 때까지 기다린다.

상기와 같이 클라이언트로부터 서버로 'Client Hello' 메시지를 보내면 서버로부터 클라이언트에게 'Server Hello' 메시지를 전송한다. 이때, 전송 메시지는 프로토콜 버전, 서버가 생성한 앤덤 구조체, 세션 ID, 암호화규격, 압축방법 등의 암호 속성들에 대한 정보를 포함하게 된다. 이때, 클라이언트가 서버로 전송한 세션 ID가 서버의 세션 캐쉬에 존재하는 경우는 이 세션이 재사용되어야 하는 세션임을 나타내며, 이때 서버는 클라이언트가 보낸 값과 동일한 값을 돌려주고, 세션 캐쉬에 없는 경우에는 새로운 세션 ID를 생성하여 클라이언트에게 돌려준다. 또한, 암호화규격과 압축방법은 클라이언트가 보낸 값들 중에 서버가 지원할 수 있는 하나를 선택하여 클라이언트에게 돌려주게 된다.

다음으로 'Server Certificates' 과정으로 일반적인 경우에는 클라이언트에게 서버의 신원을 확인할 필요가 있으며, 이를 위하여 서버는 클라이언트에게 자신의 인증서를 전송한다. 상기 인증서의 형식은 상기 'Client Hello'와 'Server Hello' 과정에서 선택된 암호화규격에 의해 결정되며 일잔적으로 X.509.v3형식이 된다.

다음으로 'Certificate Request' 과정으로 공개적인 서버가 아닌 비익명 서버의 경우 서버는 클라이언트의 신원을 확인하기 위해서 클라이언트에게 인증서를 제출해 줄 것을 요구할 수 있으며, 이 메시지는 서버가 요구하는 인증서 형식과 서버가 받아들일 수 있는 인증기관(Certificate Authority, CA)들의 DN(Distinguish Name)들로 이루어진다.

다음으로 'Server Hello Done' 과정으로 서버로부터 'Server Hello'와 관련된 메시지들이 모두 끝났음을 알리기 위하여 클라이언트에게 'Server Hello Done' 메시지를 전송한다.

다음으로 'Client Certificate' 과정으로 서버가 클라이언트에게 인증서를 요구한 경우 클라이언트는 서버에게 자신의 인증서를 전송한다. 만약 클라이언트에게 적절한 인증서가 없는 경우 클라이언트는 서버에게 'no certificate' 메시지를 전송한다.

다음으로 'Client Key Exchange' 과정으로 MAC, KEY, IV 등을 생성하는데 사용되는 Master_scret을 공유하기 위한 메시지로 클라이언트가 48바이트의 pre_master-secret를 생성하여 서버의 인증서에 있는 서버 공개키로 암호화하여 서버에게 전송하고, 서버는 암호화 되어 있는 pre_master_secret를 자신의 개인키로 복호화한다. 이때, 클라이언트와 서버는

master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('BB' + pre_master_secret +

ClientHello.random + ServerHello.random)) +

MD5(pre_master_secret + SHA('CCC' + pre_master_secret +

ClientHello.random + ServerHello.random));와 같은 방법으로 master_secret를 생성하여 공유한다. 이와 같이 생성된 master_secret로부터 클라이언트와 서버가 실제 암호화에 사용할 대칭 암호 Key, IV, MAC Key 등을 생성함으로써 암호 통신을 위한 비밀정보(Key 등의)를 서로 고유하게 된다.

다음으로 'Change Cipher Spec' 과정으로 서버와 클라이언트가 실제로 암호화 통신에 사용하게 될 암호 알고리즘, MAC 알고리즘, 암호키 등을 공유하기 위한 메시지로서, 핸드쉐이크 프로토콜에 속하는 메시지가 아니라 'Change Cipher Spec' 프로토콜에 속하는 메시지이다. 클라이언트와 서버는 각각 자신의 'Change Cipher Spec' 메시지를 상대방에게 전송한 후 곧바로 'Finished' 메시지를 전송하게 된다.

다음으로 'Finished' 과정으로 서버와 클라이언트는 키 교환과 인증 과정이성공적으로 이루어졌음을 증명하기 위하여 'Change Cipher Specs' 메시지 후 즉시 'Finished' 메시지를 상대방으로 보낸다. 상기 'Finished' 메시지는 위에서 협상된 알고리즘들과 키들로 보호되어지는 첫번째 메시지이다. 상기 서버와 클라이언트는 각자 자신의 'Finished' 메시지를 보낸 즉시 암호화된 데이터를 보내기 시작하며 상대방은 'Finished' 메시지를 받기 이전에 수신된 암호화된 데이터는 무시한다.

다음로 'Application Data Transfer' 과정으로 상술한 핸드쉐이크 과정이 끝난 후 서버와 클라이언트는 확보된 SSL 채널을 통하여 암호화된 어플리케이션 데이터를 주고 받기 시작한다.

일반적으로 웹 보안 프로토콜은 현재 인터넷의 급속한 확장에 의해 가장 활발히 이용되는 웹 기술에 사용되는 핵심 기술이다. 또한, 암호 기술이 인터넷 환경에서 핵심적인 요소로 부각되고 있는 상황에서 국산기술로 개발된 암호 알고리즘과 보안 프로토콜의 개발은 국가 보안 기술 및 정보화 경쟁력 향상을 위해 반드시 필요하다.

현재 SSL이 웹 보안 프로토콜에 있어서 실질적인 표준으로 사용되고 있지만 국내에서는 이에 대한 원천 기술의 확보가 아직 미흡한 상태이며, 이로 인하여 국내에서 인증되어진 국산 암호 알고리즘이 구현되더라도 이를 SSL 프로토콜과 완벽하게 호환되면서 새로운 알고리즘을 추가할 수 있는 개방형 구조를 가짐으로써 국산 알고리즘인 SEED, KCDSA, EGIS 등의 알고리즘을 SSL 암호화에 실제로 적용할 수있는 프로토콜이다. 이러한 개방형 구조를 사용함으로써 이후 외국의 암호 알고리즘을 대체할 수 있는 새로운 국산 암호 알고리즘이 개발되었을때 해당 알고리즘을 쉽게 적용함으로써 국산 암호 개발 기술의 활성화를 촉진하는 효과를 가져올 수 있다.

또한, 본 발명의 KSSL 프로토콜을 웹 서버 및 브라우저 보안 시스템에 적용함으로써 웹 보안 시스템을 필요로하는 쇼핑몰 등 전자상거래 업체들이 외국의 프로토콜을 이용한 외국 제품들을 구입 및 유지하는데 사용되는 막대한 외화 비용의 유출을 국내로 환원하는 효과를 기대할 수 있다.

Claims (6)

1. 암호화 알고리즘을 포함하여 클라이언트와 서버간의 비밀을 유지하기 위한 통신방법에 있어서,

   클라이언트가 서버에게 '클라이언트 헬로' 메시지를 전송하는 단계와;

   상기 메시지를 전송받은 서버가 '클라이언트 헬로' 메시지에 포함된 세션 아이디를 세션 캐쉬에서 찾는 단계와;

   상기 세션 아이디가 세션 캐쉬에 없으면 서버에서 세션 아이디를 새로이 생성하여 클라이언트에게 '서버 헬로' 메시지를 전송하고, 세션 아이디가 세션 캐쉬에 있으면 바로 '서버 헬로' 메세지를 전송하고 자신의 인증서를 전송하는 단계와;

   서버로부터 전송된 인증서를 확인하여 서버가 비익명인지를 판단하는 단계와;

   상기 서버가 비익명이라면 서버는 클라이언트에게 'Certificate Request'를 요청한 다음, '서버 헬로 Done' 메시지를 전송하고, 서버가 비익명이 아니라면 바로 클라이언트에게 '서버 헬로 Done' 메시지를 전송하는 단계와;

   상기 서버가 클라이언트에게 인증서를 요구하였는가를 판단하여, 요구하였다면 클라이언트는 서버가 자신의 인증서를 전송한 후, '클라이언트 키 익스체인지' 메시지를 보내고, 요구하지 않았다면 클라이언트는 서버에게 바로 '클라이언트 키 익스체인지' 메시지를 전송하고 이어서 'Change CipherSpec' 메시지와 'Finished' 메시지를 전송하는 단계와;

   상기 클라이언트로부터 'Finished' 메시지를 전송받은 서버도 클라이언트에게 'Finished' 메시지를 전송하는 단계와;

   상기 서버는 클라이언트로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 받았다면 클라이언트도 서버로부터 전송된 'Finished' 메시지를 수신할 때까지 기다린 후 메시지를 수신하였다면 클라이언트와 서버간에 암호화된 어플리케이션 데이터를 주고받는 단계를 포함하는 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법.
2. 제 1 항에 있어서,

   상기 '클라이언트 헬로' 메시지는 프로토콜 버전, 인증에 사용하기 위해 클라이언트가 생성한 랜덤 구조체, 세션을 구분하기 위한 세션 아이디, 클라이언트가 지원하는 암호 규격들을 정의하는 암호화규격, 클라이언트가 지원하는 압축방법을포함하는 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법
3. 제 1 항에 있어서,

   상기 '서버 헬로' 메시지는 프로토콜 버전, 서버가 생성한 구조체, 세션 아이디, 암호화규격, 압축방법을 갖는 암호 속성들에 대한 정보를 포함하는 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법.
4. 제 1 항에 있어서,

   상기 '클라이언트 키 익스체인지' 메시지는 MAC, KEY, IV를 생성하는데 사용되는 Master_secret를 공유하기 위한 메시지인 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법.
5. 제 4 항에 있어서,

   상기 Master_secret를 서버가 생성하는 방법은

   master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret +

   ClientHello.random + ServerHello.random)) +

   MD5(pre_master_secret + SHA('BB' + pre_master_secret +

   ClientHello.random + ServerHello.random)) +

   MD5(pre_master_secret + SHA('CCC' + pre_master_secret +

   ClientHello.random + ServerHello.random));

   인 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법.
6. 제 1 항에 있어서,

   상기 'Change Cipher Spec' 메시지는 서버와 클라이언트간의 암호화 통신에 사용하게될 암호 알고리즘, MAC 알고리즘, 암호키를 공유하기 위한 메시지 인 것을 특징으로 하는 웹 보안 프로토콜을 이용한 통신방법.