KR20090098542A - 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법 - Google Patents

프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법 Download PDF

Info

Publication number
KR20090098542A
KR20090098542A KR1020080023997A KR20080023997A KR20090098542A KR 20090098542 A KR20090098542 A KR 20090098542A KR 1020080023997 A KR1020080023997 A KR 1020080023997A KR 20080023997 A KR20080023997 A KR 20080023997A KR 20090098542 A KR20090098542 A KR 20090098542A
Authority
KR
South Korea
Prior art keywords
server
data
proxy
client
data communication
Prior art date
Application number
KR1020080023997A
Other languages
English (en)
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 KR1020080023997A priority Critical patent/KR20090098542A/ko
Publication of KR20090098542A publication Critical patent/KR20090098542A/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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/166—Implementing security features at a particular protocol layer at the transport 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms

Abstract

본 발명은 프록시를 이용한 암호화 데이터 통신시스템 및 암호화 데이터 통신방법에 관한 것으로, 본 발명에 따른 웹 보안 프로토콜을 이용한 암호화 데이터 통신시스템은, 서버인증서를 제공하고, 데이터 통신시 제1세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 서버와; 제공되는 프록시 인증서를 검증하고, 데이터 통신시 제2세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 클라이언트와; 상기 서버로부터 전송되는 상기 서버인증서를 검증하고 상기 서버와 상기 제1세션키를 교환하여 상기 제1세션키를 이용한 데이터 암호화 및 복호화를 통한 상기 서버와의 데이터 통신을 수행하고, 상기 클라이언트에 제공하기 위한 프록시 인증서를 생성하고 상기 클라이언트와는 상기 제2세션키를 교환하여 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통한 상기 클라이언트와의 데이터 통신을 수행하여, 상기 서버와 상기 클라이언트 간의 데이터 통신 및 인증동작을 중개하는 프록시를 구비한다. 본 발명에 따르면, 프록시를 이용하여 서버와 클라이언트의 암호화 데이터의 전송을 중개함에 의해, 암호화 데이터 전송과정에서의 기밀유출이나 바이러스 유입 등에 효과적으로 대응할 수 있게 된다.
서버, 클라이언트, 프록시, 암호화, 세션키, 필터링, 로깅

Description

프록시를 이용한 암호화 데이터 통신시스템 및 암호화 데이터 통신방법{Encryption data communication system using proxy and method for encryption data communication thereof}
본 발명은 프록시를 이용한 암호화 데이터 통신시스템 및 암호화 데이터 통신방법에 관한 것으로, 더욱 구체적으로는, 암호화된 데이터의 필터링 및 로깅을 수행할 수 있는 프록시를 이용한 암호화 데이터 통신시스템 및 암호화 데이터 통신방법에 관한 것이다.
일반적으로 네트워크 상에서 클라이언트(client)와 서버 간의 중요 데이터 전송은 암호화를 통해 이루어진다. 즉 클라이언트와 서버간의 통신에서 일반텍스트를 이용하는 대신에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜 등의 웹 보안 프로토콜을 통해 데이터를 암호화함으로써, 전송도중에 해킹을 통해 데이터가 유출되더라고 데이터의 내용을 보호할 수 있게 된다.
암호화(Encryption)는 데이터를 보호하는 기술로서, 암호화 알고리즘은 입력 된 일반 텍스트 데이터에 암호화 키(encryption key)를 수학적으로 결합시켜서 암호화된 데이터를 만들어낸다.
전통적인 대칭키(또는 비밀키) 암호화의 경우에는 메시지를 암호화하고 해독하는데 사용되는 대칭키를 만들고, 상기 대칭키를 공유하는 일들이 행해진다. 암호화 및 해독키가 동일하기 때문에, 대칭키를 공유해야 한다. 따라서 대칭키 암호화를 이용해 정보를 전달하려고 하는 당사자들은 암호화 및 해독을 위한 대칭키를 먼저 안전하게 교환해야만 암호화된 데이터를 교환할 수 있다.
이러한 방식에 의한 시스템은, 만약 그 대칭키를 다른 사람들이 알게 되거나 도중에 가로채어질 경우, 메시지가 쉽게 해독될 수 있다는 치명적인 약점을 가지고 있다. 따라서 공개키 기반구조(Public Key Infrastructure)에 바탕을 둔 공개키 암호화 방식이 제안되었다.
공개키 암호화 방식에서, 공개키(public key)와 개인키(private key)는 인증기관에 의해 동일한 알고리즘을 사용하여 동시에 만들어진다. 개인키는 사용자 개인에게만 주어지며, 공개키는 모든 사람이 접근할 수 있는 디렉토리에 디지털 인증서의 일부로서 공개된다. 개인키는 절대로 다른 사람과 공유되거나 인터넷을 통해 전송되지 않는다.
사용자는 누군가가 공개 디렉토리에서 찾은 자신의 공개키를 이용해 암호화한 텍스트를 해독하기 위하여 개인키를 사용한다. 따라서, 만약 자신이 누구에겐가 어떤 메시지를 보낸다면, 우선 수신자의 공개키를 인증기관을 통해 찾은 후, 상기 공개키를 사용하여 메시지를 암호화하여 보낸다. 상기 암호화된 메시지를 수신한 사람은 그것을 자신의 개인키를 이용하여 해독한다. 메시지를 암호화하는 것 외에도, 송신자는 자신의 개인키를 사용하여 디지털 인증서를 암호화하여 함께 보냄으로써, 메시지를 보낸 사람이 틀림없이 송신자 본인이라는 것을 알 수 있게 한다. 즉, 암호화된 메시지를 송신하기 위해서는 수신자의 공개키를 사용하고, 상기 암호화된 메시지를 해독하기 위해서는 수신자의 개인키를 사용한다. 또한, 암호화된 서명을 송신하기 위해서는 송신자의 개인키를 사용하고, 상기 암호화된 서명을 해독하여 송신자를 인증하기 위해서는 송신자의 공개키를 사용한다.
공개키 암호화 방식을 이용하여 공개키와 개인키를 분리하는 방법으로 인하여 많은 새로운 기술이 개발되었다. 이러한 기술 중 중요한 것들로는 디지털 서명, 분산 인증, 공개키를 통한 대칭키 합의, 대칭키 사전 공유 없이 대량의 데이터 암호화 등이 있다.
또한, 공개키 암호화 방식을 수행하기 위한 공개키 암호화 알고리즘이 개발되었다. 예컨대, RSA(Rivest-Shamir-Adleman) 또는 ECC(Elliptic Curve Cryptography: 타원 곡선 암호 방식)와 같은 알고리즘은 공개키 암호화 방식과 관련된 작업을 모두 지원할 수 있다는 점에서 범용 알고리즘에 속한다.
한편, 상기 웹 보안 프로토콜은 인터넷 통신 상에서 TCP/IP와 같은 연결 지향적인 네트워크(network) 계층과 HTTP와 같은 어플리케이션(application) 프로토콜 계층 사이에 위치하는 프로토콜 계층으로, 상호 인증, 무결성을 위한 전자서명의 사용, 프라이버시를 위한 암호화 등을 이용하여 클라이언트(Client)와 서버(Server)(또는 웹서버) 간의 안전한 통신을 제공한다. 따라서, 원치 않는 제3자 가 통신의 내용을 누출하여 가로챌 수 없도록 하며, 또한 믿을 수 없는 통신상의 양자에 대한 상호 인증 기능을 제공함으로써 네트워크 상의 양자가 서로 믿고 통신할 수 있도록 하는 것이다.
현재 전 세계적으로 실질적인 표준으로 사용하고 있는 웹 보안 프로토콜은 네스케이프(Netscape)사의 SSL(Secure Socket Layer, 이하 SSL) 및 TLS(Transport Layer Security, 이하 TLS) 프로토콜이며, 상기 웹 보안 프로토콜 중 SSL/TLS 프로토콜의 구조가 도 1에 도시되어 있다.
도 1에 도시된 바와 같이, 상기 SSL 프로토콜은 웹을 위한 HTTP 뿐만 아니라 텔넷(Telnet), FTP, SSL VPN 등과 같은 다른 어플리케이션 프로토콜에서의 암호화 통신에도 적용 가능하다.
상기 SSL 프로토콜은 암호화, 다이제스트, 서명을 위해 사용되는 알고리즘을 선택할 수도 있도록 디자인 되어 있다. 이것은 특정 웹 서버에서 암호 알고리즘을 선택할 때 법적인 문제나 수출법과 같은 문제를 고려하여 선택할 수 있도록 해준다. 사용할 알고리즘의 선택은 SSL 프로토콜 세션이 시작될 때 핸드쉐이크(handshake) 과정을 통하여 클라이언트와 서버 간의 협상에 의해 선택하게 된다.
SSL 프로토콜은 크게 SSL핸드쉐이크 프로토콜(SSL handshake protocol), SSL 얼럿 프로토콜(SSL alert protocol), 및 SSL 레코드 프로토콜(SSL recode protocol)로 구분된다.
상기 SSL 핸드쉐이크 프로토콜(SSL handshake protocol)은 클라이언트와 서버간에 인증서 교환 및 상호 신원확인, 암호화에 사용될 대칭키(또는 세션 키(session key)(이하 '세션키'라 함)를 교환하는 과정을 수행한다.
상기 SSL 얼럿 프로토콜은 SSL 레코드 프로토콜 계층에서 제공되는 컨텐츠 타입 중 하나이며, 압축 및 암호화 오류, MAC(Message Authentication Code) 오류, 핸드쉐이크 프로토콜 실패, 및 인증서 오류 등에 대한 메시지와 설명을 전송한다.
상기 SSL 레코드 프로토콜은 핸드쉐이크 과정에서 교환된 세션키를 가지고 암호화된 소켓(socket)을 이용하여 데이터를 주고받는 과정을 수행한다.
도 2는 종래의 암호화 데이터 통신 시스템에서 클라이언트와 서버 간의 핸드쉐이크 과정 및 데이터 통신과정을 포함하는 SSL 프로토콜 동작 예를 나타낸 것이다.
도 2에 도시된 바와 같이, 종래의 암호화 데이터 통신 시스템은 이미 잘 알려진 바와 같이, 클라이언트(10)와 서버(30)로 구성된다. 상기 클라이언트(10)와 상기 서버(30) 간의 통신과정은 다음과 같다.
우선 클라이언트(10)는 서버에 처음으로 접속을 시도할 때 'Client Hello' 메시지를 상기 서버(30)에 전송한다. 'Client Hello' 메시지에는, 클라이언트 SSL 버전, 클라이언트에서 생성한 임의의 난수, 세션 식별자, 사이퍼 슈트(Cipher Suit)리스트, 압축방법 리스트 등의 정보가 포함된다(단계1).
다음으로 서버(30)는 'Client Hello' 메시지를 처리한 후 'Server Hello' 메시지를 상기 클라이언트(10)에 전송한다. 'Server Hello' 메시지에는 서버의 SSL버젼, 서버에서 생성한 임의의 난수, 세션 식별자, 클라이언트가 보낸 사이퍼 슈트(Cipher Suit) 리스트 중에서 선택한 하나의 사이퍼 슈트(Cipher Suit), 클라이 언트 압축 방법 리스트에서 선택한 압축 방법 등의 정보가 포함된다(단계2).
다음으로 상기 서버(30)의 인증을 위한 자신의 공개키 인증서를 'Server Certificate' 메시지를 통해 클라이언트로 전송한다. 인증서의 형식은 'Client Hello' 메시지와 'Server Hello'메시지 처리 과정에서 선택된 암호화 규격에 의해 결정되며, 일반적으로 X.509 인증서를 사용한다. 만약, 인증서가 없거나 서명용으로만 사용할 수 있다면 'Server Key Exchange'메시지를 전송한다(단계3).
다음으로 상기 서버(30)에서'Certificate Request' 메시지 전송은 선택적으로 수행되는 것으로, 상기 서버(30)는 클라이언트(10)의 인증서를 요구하여 신뢰할 수 있는 클라이언트 인지 확인할 수 있다(단계4).
다음으로 서버(30)는 'Sever Hello Done' 메시지를 송신하여, 서버에서 보낼 메시지를 모두 보냈음을 상기 클라이언트(10)에게 알리게 된다. 따라서, 'Sever HelloDone' 메시지를 받은 클라이언트(10)는 서버로부터 더 이상의 메시지 전송이 없음을 알 수 있게 됩니다(단계5).
다음으로 단계4에서, 상기 서버(30)로부터 클라이언트 인증서 요청이 있을 경우 상기 클라이언트(10)는 자신의 인증서를 보내거나, 인증서가 없다면 'No Certificate Alert' 메시지를 보낸다(단계6). 만약 단계4의 과정이 없다면 단계6의 과정도 수행되지 않는다.
다음으로, 상기 클라이언트(10)는 'Client Key Exchange' 메시지를 통하여, 세션키를 생성하는데 이용되는 임의의 비밀정보인 48 바이트 'pre_master_secret'를 생성하고(세션키를 생성하고), 서버의 인증서에 포함되어 있는 공개키로 암호화 하여 상기 서버(30)에 전송한다(단계7). 즉 상기 서버(30)와 상기 클라이언트(10)가 세션키를 교환하게 된다.
다음은, 'Certificate Verify' 과정으로 선택적으로 수행되는 과정이다. 상기 서버(30)는 클라이언트 인증서에 포함된 공개키가 유효한지 확인하여 클라이언트 인증을 마치게 된다(단계8).
다음으로, 상기 클라이언트(10)는 'Change Cipher Specs' 메시지를 상기 서버(30)에 전송하여 이후에 전송되는 모든 메시지는 협상된 알고리즘과 키를 이용할 것임을 알리게 된다(단계9). 이는 핸트쉐이크 프로토콜에 속하는 메시지는 아니며, 도 1의 SSL 체인지 사이퍼 스펙(SSL Change Cipher Spec) 프로토콜에 속하는 메시지이다.
다음으로 상기 클라이언트(10)는 상기 서버(30)와 협상된 알고리즘 및 세션키가 처음으로 적용된 'Finished' 메시지를 상기 서버(30)에 전송한다(단계10).
이후 상기 서버(30)는 상기 클라이언트(10)가 보낸 모든 메시지를 확인한 후, 'Change Cipher Specs' 메시지를 상기 클라이언트(10)에게 보낸다(단계11). 그리고, 상기 서버(30)는 'Finished' 메시지를 생성하여 상기 클라이언트(10)에 전송한다(단계12). 이로써 SSL 핸드쉐이크 프로토콜 단계를 종료하게 된다.
상술한 SSL 핸드쉐이크 과정이 끝난 후 서버(30)와 클라이언트(10)는 확보된 SSL 채널을 통하여 교환된 세션키로 암호화된 데이터를 송수신하는 과정을 수행하게 된다.
상술한 바와 같은, 종래의 암호화 데이터 통신시스템에서의 핸드쉐이크 과정 및 데이터 통신은, 송수신되는 데이터의 보안성 유지 측면에서는 우수한 장점이 있다. 그러나, 클라이언트와 서버사이에서 송수신되는 데이터의 내용을 데이터 전송과정에서 알 수 없는 단점이 있다. 예를 들어, 임의의 클라이언트가 회사의 허락없이 기밀(비밀) 내용을 외부에 유출하는 경우 또는 첨부파일이 바이러스 등에 감염된 경우에, 중간에서 데이터의 내용을 파악하여 데이터의 송수신을 차단하거나 제한할 수 있어야 한다.
그러나 이러한 종래의 암호화 데이터 통신시스템에서는 서버와 클라이언트 외에는 암호화 데이터를 암호화 또는 복호화할 수 있는 세션키를 갖지 못하기 때문에 데이터의 내용파악을 통한 데이터의 송수신 차단 또는 제한이 불가능하다. 이는 사내보안이나 기밀유지에 많은 문제점을 야기하게 된다. 특히 불법적인 기술유출이 현실화되고 있는 시점에서, 기술력을 인정받고 있는 기업이나 국가의 입장을 대변하여 암호화 통신의 경우에도 기술유출을 방지하고 보안을 강화할 필요성이 제기된다.
따라서, 본 발명의 목적은 상기한 종래의 문제점을 극복할 수 있는 암호화 데이터 통신시스템 및 암호화 데이터 통신방법을 제공하는 데 있다.
본 발명의 다른 목적은 프록시를 이용하여 암호화 데이터 통신을 수행할 수 있는 암호화 데이터 통신시스템 및 암호화 데이터 통신방법을 제공하는 데 있다.
본 발명의 또 다른 목적은, 암호화 데이터 통신을 수행하면서도 전송되는 데이터의 내용을 파악하여, 전송되는 데이터의 차단이나 제한을 수행할 수 있는 암호화 데이터 통신시스템 및 암호화 데이터 통신방법을 제공하는 데 있다.
본 발명의 또 다른 목적은, 클라이언트와 서버를 중개하며 데이터의 필터링 및 로깅을 수행할 수 있는 프록시를 이용하여 암호화 데이터 통신을 수행하는 암호화 데이터 통신시스템 및 암호화 데이터 통신방법을 제공하는 데 있다.
본 발명의 또 다른 목적은 기밀유출의 방지 또는 최소화, 바이러스의 차단 등을 수행할 수 있는 암호화 데이터 통신시스템 및 암호화 데이터 통신방법을 제공하는 데 있다.
상기한 기술적 과제들의 일부를 달성하기 위한 본 발명의 구체화에 따라, 본 발명에 따른 웹 보안 프로토콜을 이용한 암호화 데이터 통신시스템은, 서버인증서를 제공하고, 데이터 통신시 제1세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 서버와; 제공되는 프록시 인증서를 검증하고, 데이터 통신시 제2세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 클라이언트와; 상기 서버로부터 전송되는 상기 서버인증서를 검증하고 상기 서버와 상기 제1세션키를 교환하여 상기 제1세션키를 이용한 데이터 암호화 및 복호화를 통한 상기 서버와의 데이터 통신을 수행하고, 상기 클라이언트에 제공하기 위한 프록시 인증서를 생성하고 상기 클라이언트와는 상기 제2세션키를 교환하여 상기 제2세션키를 이용한 데이터의 암 호화 및 복호화를 통한 상기 클라이언트와의 데이터 통신을 수행하여, 상기 서버와 상기 클라이언트 간의 데이터 통신 및 인증동작을 중개하는 프록시를 구비한다.
상기 프록시는 상기 클라이언트에 대해서는 상기 서버로 인식되고, 상기 서버에 대해서는 상기 클라이언트로 인식되는 구조를 가질 수 있다.
상기 제1세션키는 상기 프록시에서 생성되어 상기 서버인증서에 포함된 공개키를 이용하여 암호화되어 상기 서버로 전송되고, 상기 제2세션키는 상기 클라이언트에서 생성되어 상기 프록시인증서에 포함된 공개키를 이용하여 암호화되어 상기 프록시에 전송되는 구조를 가질 수 있다.
상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가질 수 있다.
상기 프록시는 상기 서버 또는 상기 클라이언트에서 전송된 데이터의 복호화를 통하여 데이터 필터링 또는 데이터 로깅 동작을 수행할 수 있다.
상기 데이터 필터링 동작은 세션검사, 첨부파일검사, 및 본문검사를 포함하는 복수의 데이터 검사동작을 통하여 데이터의 종류 또는 상태를 판별하고, 데이터의 종류 또는 상태에 따라 데이터 전송 여부를 결정하는 동작일 수 있다.
상기 웹보안 프로토콜은 SSL(Secure Sockets Layer) 프로토콜을 포함할 수 있다.
상기한 기술적 과제들의 일부를 달성하기 위한 본 발명의 다른 구체화에 따라, 본 발명에 따른 클라이언트와 서버를 중개하여 데이터 통신을 수행하는 프록시는, 상기 클라이언트의 접속요청을 상기 서버에 전달하고, 상기 서버에 대해서는 상기 클라이언트로 인식되도록 상기 서버로부터 전송되는 서버인증서를 검증하고, 상기 서버와의 제1세션키 교환을 통해 상기 서버와의 제1데이터 통신채널을 형성하며, 상기 클라이언트에 대해서는 상기 서버로 인식되도록 프록시 인증서를 생성하여 상기 클라이언트에 전송하고 상기 클라이언트에서의 상기 프록시 인증서 검증 후에, 상기 클라이언트와의 제2세션키 교환을 통하여 상기 클라이언트와의 제2데이터 통신채널을 형성하며, 상기 제2데이터 통신채널을 통한 상기 클라이언트와의 데이터 통신은 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하고, 상기 제1데이터 통신채널을 통한 상기 서버와의 데이터 통신은 상기 제1세션키를 이용한 데이터의 암호화 및 복호화를 통하여, 암호화 데이터 통신을 수행하는 것을 특징으로 한다.
상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가질 수 있다.
상기 프록시는 상기 서버 또는 상기 클라이언트에서 전송된 데이터의 복호화를 통하여 데이터 필터링 또는 데이터 로깅 동작을 수행할 수 있다.
상기한 기술적 과제들의 일부를 달성하기 위한 본 발명의 또 다른 구체화에 따라, 본 발명에 따른 클라이언트와 서버를 중개하는 프록시를 이용한 암호화 데이터 통신방법은, 상기 클라이언트의 접속요청에 응답하여 상기 서버로부터 상기 프록시로 제공되는 서버인증서의 검증 및 상기 프록시와 상기 서버 간의 제1세션키 교환을 통해 상기 서버와 상기 프록시 간의 제1데이터 통신채널을 형성하는 단계와; 상기 프록시에서 생성되어 상기 클라이언트로 제공되는 프록시 인증서의 검증 및 상기 프록시와 상기 클라이언트 간의 제2세션키 교환을 통해, 상기 프록시와 상기 클라이언트 간의 제2데이터 통신 채널을 형성하는 단계와; 상기 제1데이터 통신 채널 및 상기 제2데이터 통신채널을 통하여 암호화 데이터 통신을 수행하되, 상기 클라이언트와 상기 프록시 간의 데이터 통신은 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하고, 상기 서버와 상기 프록시 간의 데이터 통신은 상기 제1세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하는 데이터 통신 단계를 구비한다.
상기 서버는 상기 프록시를 상기 클라이언트로 인식하며, 상기 클라이언트는 상기 프록시를 상기 서버로 인식할 수 있다.
상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가질 수 있다.
상기 데이터 통신 단계는 상기 서버 또는 상기 클라이언트에서 상기 프록시로 전송된 데이터의 복호화 이후에, 복호화된 데이터에 대한 데이터 필터링 또는 데이터 로깅 동작을 상기 프록시에서 수행하는 단계를 포함할 수 있다.
상기 데이터 필터링 또는 데이터 로깅 동작의 수행이후에, 상기 프록시에서 상기 데이터의 전송여부를 결정하고 데이터 전송을 허용하거나 차단하는 단계를 더 포함할 수 있다.
상기 데이터 통신은 SSL(Secure Sockets Layer) 프로토콜을 포함하는 웹보안프로토콜을 이용하여 수행될 수 있다.
상기한 구성에 따르면, 클라이언트와 서버간의 암호화 데이터 통신을 중개하는 프록시를 통해, 전송되는 데이터의 필터링 또는 로깅을 수행하여 기밀유출방지 및 바이러스의 유입을 차단할 수 있으며, 보안 유지가 가능한 효과가 있다.
이하에서는 본 발명의 바람직한 실시예가, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 본 발명의 철저한 이해를 제공할 의도 외에는 다른 의도 없이, 첨부한 도면들을 참조로 하여 상세히 설명될 것이다.
도 3은 본 발명의 일 실시예에 따른 암호화 데이터 통신시스템의 블록도이다.
도 3에 도시된 바와 같이, 본 발명의 일 실시예에 따른 암호화 데이터 통신시스템(500)은, 클라이언트(100), 서버(또는 웹서버)(300), 및 프록시(200)를 구비한다.
상기 클라이언트(100)는 상기 프록시(200)에서 제공되는 프록시 인증서를 검증한다. 그리고 상기 프록시(200)와 제2세션키를 교환하고, 데이터 통신시 제2세션키를 이용하여 데이터의 암호화 및 복호화를 수행한다.
상기 서버(300)는 데이터 통신 및 인증을 위해 상기 프록시(200)에 서버인증서를 제공한다. 그리고, 상기 프록시(200)와 제1세션키를 교환하고, 데이터 통신시 제1세션키를 이용하여 데이터의 암호화 및 복호화를 수행한다.
상기 프록시(200)는 상기 서버(300)와 상기 클라이언트(100)의 데이터 통신 및 인증동작을 중개한다.
우선 상기 서버(300)와의 관계에서는, 접속요청에 응답하여 상기 서버(300)로부터 전송되는 상기 서버인증서를 검증하고 상기 서버(300)와 상기 제1세션키를 교환한다. 그리고 상기 제1세션키를 이용한 데이터의 암호화 및 복호화를 통해 상기 서버(300)와의 데이터 통신을 수행하게 된다.
다음으로 상기 클라이언트(100)와의 관계에서는 상기 클라이언트(100)에 제공하기 위한 프록시 인증서를 생성하여 상기 클라이언트(100)에 제공한다. 그리고, 상기 클라이언트와 상기 제2세션키를 교환한다. 이후 상기 제2세션키를 통한 데이터의 암호화 및 복호화를 통하여 상기 클라이언트(100)와의 데이터 통신을 수행하게 된다.
상기 암호화 통신 시스템(500)에서 상기 프록시(200)는 상기 클라이언트(100)에 대해서는 상기 서버(300)로 인식되고, 상기 서버(300)에 대해서는 상기 클라이언트(100)로 인식되게 된다. 즉 상기 클라이언트(100)는 상기 프록시(200)가 중간에 개입되어 있다는 사실을 알지 못하고 상기 서버(300)와 통신하고 있다고 인식하며, 상기 서버(300)는 상기 프록시(200)가 중간에 개입되어 있다는 사실을 알지 못하고 상기 클라이언트(100)와 직접 통신하고 있다고 인식하도록 시스템이 구성되게 된다. 물론, 상기 프록시(200) 존재의 인식이 필요한 경우, 또는 필요에 따라 상기 서버(300)와 상기 클라이언트(100)가 상기 프록시(200)의 존재를 인식할 수 있도록 할 수도 있다.
여기서, 상기 제1세션키는 상기 프록시(200)에서 생성되며, 상기 제1세션키는 상기 서버(300)에서 전송된 서버인증서에 포함된 공개키를 이용하여 암호화되어 상기 서버(300)로 전송되는 구조를 가질 수 있다. 또한 상기 제2세션키는 상기 클라이언트(100)에서 생성되며, 상기 프록시인증서에 포함된 공개키를 이용하여 암호화하여 상기 프록시(200)에 전송되는 구조를 가질 수 있다.
상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Number)를 가질 수 있다. 일반적으로 인증서는 디지털 인증서라고도 하며, 신뢰할 수 있는 인증기관에서 발급하는 것이 일반적이다. 인증서에는 버전(version)정보, 시리얼 넘버(serial number), 디스팅귀시드 네임(Distinguished Names(DNs)), 유효기간(Validity), 인증서 폐지목록(CRL) 등이 포함된다. 상기 디스팅귀시드 네임(Distinguished Names(DNs))에는 인증서의 발급주체정보(Subject)와 발급자(Issuer) 정보를 포함하며, 기본적으로 'Country(C)','Organization(O)', 'Organizational Unit(OU)', 및 'Common Name(CN)' 으로 구성될 수 있다. 여기서 상기 인증서가 'HTTPS' 프로토콜에서 사용되는 경우, 상기 인증서의 'Common Name(CN)'는 사이트의 호스트 네임(Host Name) 일 수 있다.
상기 서버인증서와 상기 프록시 인증서가 동일한 CN(Common Name)를 가짐에 따라, 상기 클라이언트(100)는 상기 프록시 인증서를 상기 서버(300)의 인증서로 인식할 수 있게 된다. 상기 클라이언트(100)가 상기 프록시 인증서를 상기 서버의 인증서로 인식할 수 있도록 하는 다른 방법이 있거나, 상기 프록시 인증서와 상기 서버인증서가 상기 CN(Common Name) 외에 동일한 호스트 네임에 대한 정보를 가지 고 있으면, 상기 프록시 인증서와 상시 서버인증서의 CN(Common Name)이 동일하지 않을 수도 있다.
상기 프록시(200)에서는 상기 클라이언트(100)에서 전송되는 암호화 데이터, 또는 상기 서버(300)에서 전송되는 암호화 데이터를 복호화하여 데이터의 필터링(filtering) 또는 데이터 로깅(logging) 동작을 수행한다. 상기 프록시(200)에서는 상기 데이터 필터링 또는 데이터 로깅 동작을 통하여 데이터를 판별하여 차단 또는 허용 여부를 결정하게 된다.
상기 데이터에 대한 허용이 결정된 경우에는 상기 프록시(200)는 제1세션키 또는 상기 제2세션키를 이용한 데이터의 암호화를 통해 상기 서버(300) 또는 상기 클라이언트(100)에 데이터를 전송하게 된다.
상기 데이터 필터링은 암호화된 데이터를 평문으로 복호화하여 종류에 따라 차단, 허용 등의 판단을 행하는 동작이다. 상기 데이터 필터링에는 세션검사, 첨부파일 검사, 본문검사 등이 포함될 수 있다. 이외에도 전송되는 데이터에 대해 요구되거나 가능할 수 있는 모든 검사가 포함될 수 있다.
상기 세션검사는 데이터의 소스아이피(SRC(Source) IP), 목적아이피(Dest(Destination) IP), URL(Uniform Resource Locator) 정보 등의 검사를 말한다. 또한, 상기 첨부파일 검사는 첨부파일의 유무를 검사하고, 첨부파일이 있을 경우 파일의 종류, 사이즈 검사, 키워드 검사, 및 바이러스 검사 등을 포함할 수 있다. 그리고, 상기 본문검사는 본문의 사이즈검사, 키워드 검사, 바이러스 검사 등을 포함할 수 있다.
상기 데이터 필터링은 세션검사, 첨부파일 검사, 본문검사 등 모든 가능한 검사를 포함하여 한꺼번에 수행될 수도 있고, 세션검사, 첨부파일검사, 및 본문검사 중에서 일부만을 선택하여 선택적으로 수행될 수도 있다.
상기 데이터 로깅동작은 암호화된 데이터를 평문으로 변환하여 저장하는 동작을 말한다.
여기서, 상기 데이터의 필터링 동작 및 로깅동작은 함께 수행될 수도 있고, 선택적으로 필요에 따라 상기 데이터의 필터링 동작만 수행될 수도 있고, 상기 데이터 로깅동작만 수행될 수도 있다.
상기 프록시(200)는 하나의 클라이언트(100)와 하나의 서버(300)와의 사이에 연결될 수도 있고, 복수의 클라이언트들(100)과 하나의 서버(300)와의 사이에 연결될 수도 있다. 또한 복수의 클라이언트들(100) 및 복수의 서버들(300)의 사이에 연결될 수 있다. 이는 본 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 필요에 따라 적절하게 선택가능 할 것이다.
상기 서버(300)와 상기 프록시(200)의 핸드쉐이크 과정 및 데이터 통신, 및 상기 클라이언트(100)와 상기 프록시(200)의 핸드쉐이크 과정 및 데이터 통신 과정은 HTTPS(Secure Hypertext Transfer Protocol), SSL 프로토콜 등의 웹 보안 프로토콜을 이용해서 수행될 수 있다.
도 4는 상기 클라이언트(100)와 상기 프록시(200), 상기 프록시(200)와 상기 서버(300) 간의 핸드쉐이크 과정 및 데이터 통신과정을 나타낸 것이다.
도 4에 도시된 바와 같이, 우선 상기 클라이언트(100)에서 SSL 접 속(TCP_connect, SSL_connect)을 요청한다. 상기 프록시(200)에서는 상기 클라이언트(100)의 접속요청을 상기 서버(300)에 전달한다. 이와 달리, 상기 프록시(200)에서는 상기 클라이언트(100)의 접속요청을 상기 서버(300)에 전달하는 것이 아니라, 상기 클라이언트(100)에서 접속요청이 있을 경우에, 이에 응답하여 상기 서버(300)에의 접속요청을 별도로 진행할 수도 있다. 과정면에서는 다를 수 있으나, 전체적인 결과면에서 상기 클라이언트(100)의 접속요청이 상기 프록시(200)를 경유함이 없이 상기 서버(300)에 직접 전달되는 효과를 가져온다.
상기 클라이언트(100)의 접속요청이 있으면, 상기 서버(300)에서는 'Server Certificate' 과정을 통해 서버 인증서를 상기 프록시(200)에 전송한다. 상기 서버인증서는 상기 프록시(200)로 전달되나, 상기 서버(300)에서는 상기 클라이언트(100)로 상기 서버인증서가 전송된 것으로 인식하게 된다.
상기 프록시(200)에서는 상기 서버(300)로부터 전송된 서버인증서를 검증하고, 상기 서버(300)와의 통신시에 사용할 제1세션키를 생성한다(S202). 이후 상기 제1세션키를 상기 서버인증서에 포함되어 있는 공개키로 암호화하여 상기 서버(300)에 전송함에 의하여, 상기 서버(300)와 상기 프록시(200) 간의 제1세션키 교환과정이 수행되게 된다. 이때 상기 서버(300)는 상기 제1세션키가 상기 클라이언트(100)에서 전송된 것으로 인식한다. 여기서 상기 프록시(200)에서 암호화된 상기 제1세션키는 상기 서버(300)의 개인키를 이용하여 복호화하게 된다.
이에 따라 상기 서버(300)와 상기 프록시(200) 간의 연결이 완료되게 된다(SSL_connect_finished). 즉 상기 서버(300)와 상기 프록시(200) 간에 데이터 통 신을 위한 제1데이터 통신채널이 형성되게 되어, 데이터 전송의 준비가 완료되게 된다.
이후 상기 프록시(200)는 상기 서버(300)에서 전송된 상기 서버인증서와 동일한 CN(Common Name)을 가지는 프록시 인증서를 생성한다(S204). 그리고 상기 프록시(200)에서는 상기 프록시 인증서를 'Proxy Certificate' 과정을 통해 상기 클라이언트(100)로 전송한다. 상기 클라이언트(100)에서는 상기 프록시 인증서를 상기 서버(300)의 인증서로 인식하여 검증하고, 상기 프록시(200)(상기 클라이언트(100) 입장에서는 서버(300))와의 통신에 사용할 제2세션키를 생성하게 된다(S127). 상기 클라이언트(100)에서는 상기 제2세션키를 상기 프록시 인증서에 포함된 공개키를 이용하여 암호화하여 상기 프록시(200)(상기 클라이언트(100) 입장에서는 상기 서버(300))로 전송함에 의하여 상기 클라이언트(100)와 상기 프록시(200) 간의 제2세션키 교환 과정이 수행된다. 암호화된 상기 제2세션키는 상기 프록시(200)의 개인키를 이용하여 복호화하게 된다.
이로써 상기 프록시(200)와 상기 클라이언트(100) 간의 연결이 완료되게 된다. 즉 상기 클라이언트(100)와 상기 프록시(200) 간의 데이터 통신을 위한 제2데이터 통신채널이 형성되게 되어, 데이터 전송의 준비가 완료되게 된다.
이후에 상기 클라이언트(100)와 상기 프록시(200) 간의 데이터(메시지 포함)의 통신은 상기 제2세션키를 통한 암호화 및 복호화를 통해 수행되게 된다.
여기서 상기 클라이언트(100)는 상기 프록시(200)를 상기 서버(300)로 인식한다. 또한, 상기 서버(300)와 상기 프록시(200) 간의 데이터(메시지 포함)의 통신 은 상기 제1세션키를 통한 암호화 및 복호화를 통해 수행되게 된다. 물론 여기서도 상기 서버(300)는 상기 프록시(200)를 상기 클라이언트(100)로 인식한다.
요약하면, 상기 클라이언트(100)와 상기 서버(300) 간의 데이터 통신은, 상기 클라이언트(100)와 상기 프록시(200) 간의 제2세션키를 이용한 데이터 암호화 및 복호화, 및 상기 프록시(200)와 상기 서버(300) 간의 제1세션키를 이용한 데이터의 암호화 및 복호화 과정을 통해 수행되게 된다.
여기서, 상기 클라이언트(100)와 상기 프록시(200) 간의 인증 및 데이터 통신 동작은, 도 2에서 설명된 종래의 암호화 데이터 통신 시스템에서의 클라이언트(10)와 서버(30) 간의 인증 및 데이터 통신 동작의 모든 과정을 포함할 수 있다. 또한, 상기 프록시(200)와 상기 서버(300) 간의 인증 및 데이터 통신 동작은, 도 2에서 설명된 종래의 암호화 데이터 통신 시스템에서의 클라이언트(10)와 서버(30) 간의 인증 및 데이터 통신 동작의 모든 과정을 포함할 수 있다.
이하 본 발명의 일 실시예에 따른 암호화 통신 시스템(500)에서 상기 클라이언트(100), 상기 프록시(200), 및 상기 서버(300) 간의 접속인증 및 데이터 통신 을 포함한 전체적인 동작과정을 도 5 내지 도 6의 동작 순서도를 통해 자세히 알아보기로 하자.
도 5에 도시된 바와 같이, 우선 상기 클라이언트(100)에서 상기 프록시(200)(상기 클라이언트(100)입장에서는 상기 서버(300))에 접속요청을 하게 된다(S112). 상기 프록시(200)는 상기 클라이언트(100)의 접속요청 메시지를 받아서 상기 서버(300)에 접속요청을 하게 된다(S114).
상기 서버(300)는 상기 프록시(200)(상기 서버(300)입장에서는 상기 클라이언트(100))에 서버인증서를 전송하게 된다(S116). 이후 상기 프록시(200)에서는 상기 서버인증서를 검증하고, 상기 서버(300)와 제1세션키를 교환하게 된다(S118). 상기 서버(300)와의 제1세션키 교환과정은 도 4를 통해 자세히 설명한 바 있다. 상기 서버(300)와의 상기 제1세션키 교환에 의해 상기 서버(300)와 상기 프록시(200)의 접속(연결)이 완료되게 된다(S120).
도 6에 도시된 바와 같이, 상기 서버(300)와 상기 프록시(200)의 접속(연결)이 완료된 이후, 상기 프록시(200)에서는 상기 서버(300)에서 전송된 서버인증서와 동일한 CN을 가지는 프록시 인증서가 있는지의 여부를 판단한다(S122). 상기 서버인증서와 동일한 CN의 프록시 인증서가 없으면(무), 상기 서버인증서와 동일한 CN의 프록시 인증서를 생성한다. 그리고, 상기 서버인증서와 동일한 CN의 프록시 인증서가 있으면(유), 별도의 인증서 생성동작을 진행하지 않을 수 있다.
상기 프록시(200)에서는 생성되거나 이미 존재하는 상기 서버인증서와 동일한 CN의 프록시 인증서를 상기 클라이언트(100)로 전송한다(S126). 여기서, 상기 서버인증서와 동일한 CN을 가지는 프록시 인증서의 유무와 관계없이, 즉 프록시인증서의 유무를 판단하는 과정이 없이, 상기 프록시(200)에서 무조건 상기 프록시 인증서를 생성하여 상기 클라이언트(100)에 전송할 수도 있다.
상기 클라이언트(100)에서는 상기 프록시(200)에서 전송된 프록시 인증서를 검증하고 상기 프록시(200)와 제2세션키를 교환한다(S128). 상기 프록시(200)와 상기 클라이언트(100) 간의 상기 제2세션키 교환 과정은 도 4에서 자세히 설명한 바 있다. 상기 프록시(200)와 상기 클라이언트(100)의 상기 제2세션키 교환이 완료됨에 따라 상기 클라이언트(100)와 상기 프록시(200) 간에 접속(연결)이 완료되게 된다(S130).
전체적으로는 상기 서버(300)와 상기 클라이언트(100)간에 접속이 완료되게 된다. 상기 서버(300)와 상기 클라이언트(100) 간의 접속이 완료되었다는 의미는, 상기 서버(300)와 상기 클라이언트(100) 간에 암호화 데이터 통신을 위한 준비가 되었다는 것을 의미할 수 있다.
이하의 동작은 암호화 데이터 통신에서의 보안유지를 중점적으로 설명하기 위해 상기 프록시(200)를 중심으로 하여 그 동작을 설명한다.
도 7에 도시된 바와 같이, 상기 서버(300)와 상기 프록시(200), 상기 프록시(200)와 상기 클라이언트(100) 간의 접속이 완료되어, 상기 서버(300)와 상기 클라이언트(100) 간에 전체적으로 접속이 완료되게 되면, 상기 프록시(200)에서는 상기 서버(300) 또는 상기 클라이언트(100)로부터의 데이터 전송이 있는지 여부를 판단하게 된다(S132).
데이터의 전송이 없으면(No), 접속을 종료한다(S134). 그러나 데이터의 전송이 있으면(Yes), 데이터가 상기 서버(300) 또는 상기 클라이언트(100) 중 어느 쪽에서의 전송인지를 판단한다(S136).
상기 데이터가 상기 클라이언트(100)에서 전송되는 경우(클라이언트), 상기 프록시(200)는 상기 클라이언트(100)에서 전송되는 데이터를 수신한다(S138). 물론 상기 클라이언트(100)에서는 상기 프록시(200)로 데이터를 전송할 때 상기 제2세션 키를 통해 암호화하여 데이터를 전송함은 이미 설명한바와 같다. 또한 상기 클라이언트(100)는 상기 프록시(200)를 상기 서버(300)로 인식하고 있으므로 상기 서버(300)로 데이터를 전송한 것으로 인식할 것이다.
상기 프록시(200)에서는 상기 클라이언트(100)로부터 전송된 데이터를 상기 제2세션키를 통해 복호화하여 평문(plain text)으로 변환(추출)한다(S140). 이후 상기 프록시(200)에서는 평문으로 변환된 데이터에 대한 필터링 또는 로깅 동작을 수행한다(S142). 상기 데이터 로깅 동작은 데이터를 복호화하여 저장하고 데이터의 전송을 차단하지는 않는다. 따라서, 데이터의 필터링 동작 없이 데이터의 로깅동작만을 수행하는 경우에는 상기 데이터를 상기 제1세션키를 통해 암호화하여 상기 서버(300)로 전송한다(S144,S146).
그러나 상기 데이터 필터링 동작이 수행되는 경우에는, 전송되는 데이터가 상기 서버(300)로 전송되어도 문제가 없는 데이터 인지를 판단하게 된다. 보안상 또는 바이러스 감염 등을 포함하여 미리 정해진 규칙에 의해, 문제가 있는 데이터라고 판단되면, 상기 서버(300)로의 데이터 전송을 차단하게 된다. 그리고 문제가 없는 데이터라고 판단되면, 상기 제1세션키를 통해 상기 데이터를 암호화한다(S144). 이후 상기 프록시(200)는 상기 제1세션키를 통해 암호화된 데이터를 상기 서버(300)에 송신하게 된다(S146).
이때 상기 서버(300)에서는 상기 프록시(200)로부터 전송된 암호화 데이터를 상기 제1세션키를 이용하여 복호화하여 데이터를 해석하고 이에 대한 응답을 수행하게 된다. 즉 상기 클라이언트(100)로 데이터 전송이 필요한 경우에는 상기 프록 시(200)(상기 서버(300)입장에서는 상기 클라이언트(100))에 필요한 데이터를 전송하게 된다.
이후의 동작은 상기 서버(300) 또는 상기 클라이언트(100)로부터의 데이터 전송이 있는지 여부를 판단하는 단계(S132)를 포함하여 이후의 단계들(S134 내지 S156) 중 해당되는 단계를 통해 반복적으로 데이터 통신이 수행되게 된다.
상기 데이터가 상기 서버(300) 또는 상기 클라이언트(100) 중 상기 서버(300)에서 데이터가 전송되는 것으로 판단되는 경우(서버), 상기 프록시(200)는 상기 서버(300)에서 전송되는 데이터를 수신한다(S148). 이때 상기 서버(300)에서 전송되는 데이터는 상기 제1세션키를 통해 암호화 되어 전송됨은 이미 설명한 바와 같다. 또한 상기 서버(300)는 상기 프록시(200)를 상기 클라이언트(100)로 인식하고 있으므로 상기 클라이언트(100)로 데이터를 전송한 것으로 인식할 것이다.
상기 프록시(200)에서는 상기 서버(300)에서 전송된 데이터를 상기 제1세션키를 통해 복호화화여 평문으로 변환한다(S150). 이후 상기 프록시(200)에서는 평문으로 변환된 데이터에 대한 필터링 또는 로깅 동작을 수행한다(S152).
상기 데이터에 대한 필터링 및 로깅 동작은 상기 클라이언트(100)에서 데이터가 전송되는 경우와 그 대상이 다를 뿐 동작은 동일하다. 여기서, 상기 서버(300)에서 전송되는 데이터는 보안상 필요에 의한 차단은 필요하지 않을 수 있으므로, 바이러스 검사 등의 간단한 검사 만으로 상기 데이터 필터링 동작이 수행될 수도 있다. 또는 상기 바이러스 검사 등도 불필요한 경우에는 데이터 로깅동작만을 수행하거나 이 또한 생략될 수도 있다.
상기 서버(300)에서 전송된 데이터가 문제가 없을 경우 상기 제2세션키를 이용하여 데이터를 암호화한다(S154). 여기서 상기 데이터는 상기 서버(300)에서 상기 프록시(200)로 전송된 데이터가 그 대상이 될 것이다.
이후 상기 프록시(200)는 상기 제2세션키를 통해 암호화된 데이터를 상기 클라이언트(100)에 송신하게 된다(S156).
이때 상기 클라이언트(100)에서는 상기 프록시(200)로부터 전송된 암호화 데이터를 상기 제2세션키를 이용하여 복호화하여 데이터를 해석하고 이에 대한 응답을 수행하게 된다. 즉 상기 서버(200)로 데이터 전송이 필요한 경우에는 상기 프록시(200)(상기 클라이언트(100)입장에서는 상기 서버(200))에 필요한 데이터를 전송하게 된다.
이후의 동작은 상기 서버(300) 또는 상기 클라이언트(100)로부터의 데이터 전송이 있는지 여부를 판단하는 단계(S132)를 포함하여 이후의 단계들(S134 내지 S156) 중 해당되는 단계를 통해 반복적으로 데이터 통신이 수행되게 된다.
상술한 바와 같이, 본 발명에 따른 암호화 데이터 통신 시스템은 프록시를 이용하여 클라이언트와 상기 서버 간의 암호화 데이터 통신을 수행하되, 보안상 또는 기타 필요에 따라 전송되는 데이터에 대한 필터링 또는 로깅 등의 데이터 검증을 수행할 수 있게 된다. 따라서, 암호화 데이터 전송과정에서의 기밀유출이나 바이러스 유입 등에 효과적으로 대응할 수 있게 된다.
상기한 실시예의 설명은 본 발명의 더욱 철저한 이해를 위하여 도면을 참조로 예를 든 것에 불과하므로, 본 발명을 한정하는 의미로 해석되어서는 안될 것이다. 또한, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 있어 본 발명의 기본적 원리를 벗어나지 않는 범위 내에서 다양한 변화와 변경이 가능함은 명백하다 할 것이다.
도 1은 일반적인 SSL 프로토콜의 구조도이고,
도 2는 종래의 암호화 데이터 통신 시스템에서 핸드쉐이크 과정 및 데이터 통신과정을 나타낸 도면이고,
도 3은 본 발명의 일 실시예에 따른 암호화 데이터 통신 시스템의 블록도이고,
도 4는 도 3에서 클라이언트, 프록시, 및 서버간의 핸드쉐이크 과정 및 데이터 통신과정을 나타낸 도면이고,
도 5 내지 도 7은 도 3의 전체적인 동작과정을 나타낸 동작 순서도이다.
*도면의 주요 부분에 대한 부호의 설명*
100 : 클라이언트 200 : 프록시
300 : 서버

Claims (16)

  1. 웹 보안 프로토콜을 이용한 암호화 데이터 통신시스템에 있어서:
    서버인증서를 제공하고, 데이터 통신시 제1세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 서버와;
    제공되는 프록시 인증서를 검증하고, 데이터 통신시 제2세션키를 이용하여 데이터의 암호화 및 복호화를 수행하는 클라이언트와;
    상기 서버로부터 전송되는 상기 서버인증서를 검증하고 상기 서버와 상기 제1세션키를 교환하여 상기 제1세션키를 이용한 데이터 암호화 및 복호화를 통한 상기 서버와의 데이터 통신을 수행하고, 상기 클라이언트에 제공하기 위한 프록시 인증서를 생성하고 상기 클라이언트와는 상기 제2세션키를 교환하여 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통한 상기 클라이언트와의 데이터 통신을 수행하여, 상기 서버와 상기 클라이언트 간의 데이터 통신 및 인증동작을 중개하는 프록시를 구비함을 특징으로 하는 암호화 데이터 통신시스템.
  2. 청구항 1에 있어서,
    상기 프록시는 상기 클라이언트에 대해서는 상기 서버로 인식되고, 상기 서버에 대해서는 상기 클라이언트로 인식됨을 특징으로 하는 암호화 데이터 통신시스템.
  3. 청구항 2에 있어서,
    상기 제1세션키는 상기 프록시에서 생성되어 상기 서버인증서에 포함된 공개키를 이용하여 암호화되어 상기 서버로 전송되고, 상기 제2세션키는 상기 클라이언트에서 생성되어 상기 프록시인증서에 포함된 공개키를 이용하여 암호화되어 상기 프록시에 전송됨을 특징으로 하는 암호화 데이터 통신시스템.
  4. 청구항 3에 있어서,
    상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가짐을 특징으로 하는 암호화 데이터 통신시스템.
  5. 청구항 3에 있어서,
    상기 프록시는 상기 서버 또는 상기 클라이언트에서 전송된 데이터의 복호화를 통하여 데이터 필터링 또는 데이터 로깅 동작을 수행함을 특징으로 하는 암호화 데이터 통신시스템.
  6. 청구항 5에 있어서,
    상기 데이터 필터링 동작은 세션검사, 첨부파일검사, 및 본문검사를 포함하는 복수의 데이터 검사동작을 통하여 데이터의 종류 또는 상태를 판별하고, 데이터의 종류 또는 상태에 따라 데이터 전송 여부를 결정함을 특징으로 하는 암호화 데이터 통신시스템.
  7. 청구항 1 또는 청구항 6에 있어서,
    상기 웹보안 프로토콜은 SSL(Secure Sockets Layer) 프로토콜을 포함함을 특징으로 하는 암호화 데이터 통신시스템.
  8. 클라이언트와 서버를 중개하여 데이터 통신을 수행하는 프록시에 있어서:
    상기 클라이언트의 접속요청을 상기 서버에 전달하고, 상기 서버에 대해서는 상기 클라이언트로 인식되도록 상기 서버로부터 전송되는 서버인증서를 검증하고, 상기 서버와의 제1세션키 교환을 통해 상기 서버와의 제1데이터 통신채널을 형성하며,
    상기 클라이언트에 대해서는 상기 서버로 인식되도록 프록시 인증서를 생성하여 상기 클라이언트에 전송하고 상기 클라이언트에서의 상기 프록시 인증서 검증 후에, 상기 클라이언트와의 제2세션키 교환을 통하여 상기 클라이언트와의 제2데이터 통신채널을 형성하며,
    상기 제2데이터 통신채널을 통한 상기 클라이언트와의 데이터 통신은 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하고, 상기 제1데이터 통신채널을 통한 상기 서버와의 데이터 통신은 상기 제1세션키를 이용한 데이터의 암호화 및 복호화를 통하여, 암호화 데이터 통신을 수행하는 것을 특징으로 하는 프록시.
  9. 청구항 8에 있어서,
    상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가짐을 특징으로 하는 프록시.
  10. 청구항 8 또는 청구항 9에 있어서,
    상기 프록시는 상기 서버 또는 상기 클라이언트에서 전송된 데이터의 복호화 를 통하여 데이터 필터링 또는 데이터 로깅 동작을 수행함을 특징으로 하는 프록시.
  11. 클라이언트와 서버를 중개하는 프록시를 이용한 암호화 데이터 통신방법에 있어서:
    상기 클라이언트의 접속요청에 응답하여 상기 서버로부터 상기 프록시로 제공되는 서버인증서의 검증 및 상기 프록시와 상기 서버 간의 제1세션키 교환을 통해 상기 서버와 상기 프록시 간의 제1데이터 통신채널을 형성하는 단계와;
    상기 프록시에서 생성되어 상기 클라이언트로 제공되는 프록시 인증서의 검증 및 상기 프록시와 상기 클라이언트 간의 제2세션키 교환을 통해, 상기 프록시와 상기 클라이언트 간의 제2데이터 통신 채널을 형성하는 단계와;
    상기 제1데이터 통신 채널 및 상기 제2데이터 통신채널을 통하여 암호화 데이터 통신을 수행하되, 상기 클라이언트와 상기 프록시 간의 데이터 통신은 상기 제2세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하고, 상기 서버와 상기 프록시 간의 데이터 통신은 상기 제1세션키를 이용한 데이터의 암호화 및 복호화를 통하여 수행하는 데이터 통신 단계를 구비함을 특징으로 하는 암호화 데이터 통신방법.
  12. 청구항 11에 있어서,
    상기 서버는 상기 프록시를 상기 클라이언트로 인식하며, 상기 클라이언트는 상기 프록시를 상기 서버로 인식함을 특징으로 하는 암호화 데이터 통신방법.
  13. 청구항 12에 있어서,
    상기 서버인증서와 상기 프록시 인증서는 동일한 CN(Common Name)를 가짐을 특징으로 하는 암호화 데이터 통신방법.
  14. 청구항 11 또는 청구항 13에 있어서,
    상기 데이터 통신 단계는 상기 서버 또는 상기 클라이언트에서 상기 프록시로 전송된 데이터의 복호화 이후에, 복호화된 데이터에 대한 데이터 필터링 또는 데이터 로깅 동작을 상기 프록시에서 수행하는 단계를 포함함을 특징으로 하는 암호화 데이터 통신방법.
  15. 청구항 14에 있어서,
    상기 데이터 필터링 또는 데이터 로깅 동작의 수행이후에, 상기 프록시에서 상기 데이터의 전송여부를 결정하여 데이터 전송을 허용하거나 차단하는 단계를 더 포함함을 특징으로 하는 암호화 데이터 통신방법.
  16. 청구항 15에 있어서,
    상기 데이터 통신은 SSL(Secure Sockets Layer) 프로토콜을 포함하는 웹보안프로토콜을 이용하여 수행됨을 특징으로 하는 암호화 데이터 통신방법.
KR1020080023997A 2008-03-14 2008-03-14 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법 KR20090098542A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020080023997A KR20090098542A (ko) 2008-03-14 2008-03-14 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020080023997A KR20090098542A (ko) 2008-03-14 2008-03-14 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법

Publications (1)

Publication Number Publication Date
KR20090098542A true KR20090098542A (ko) 2009-09-17

Family

ID=41357602

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020080023997A KR20090098542A (ko) 2008-03-14 2008-03-14 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법

Country Status (1)

Country Link
KR (1) KR20090098542A (ko)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180027235A (ko) * 2016-09-06 2018-03-14 주식회사 수산아이앤티 보안 소켓 계층 통신을 이용하는 패킷을 선택적으로 검사하는 방법
KR20180031435A (ko) * 2016-09-20 2018-03-28 주식회사 수산아이앤티 보안 소켓 계층 통신을 이용하는 패킷을 검사하는 방법
KR20180038496A (ko) * 2015-08-25 2018-04-16 후아웨이 테크놀러지 컴퍼니 리미티드 서비스 처리 방법 및 장치
KR101896449B1 (ko) * 2017-12-21 2018-09-07 주식회사 넷앤드 암호화 통신 프로토콜 기반 서버 원격 접근 세션에 대한 보안 감사 및 통제를 위한 접근 통제 시스템
WO2019045424A1 (ko) * 2017-08-29 2019-03-07 주식회사 수산아이앤티 보안을 위한 보안 소켓 계층 복호화 방법
KR20190024581A (ko) * 2017-08-29 2019-03-08 주식회사 수산아이앤티 보안을 위한 보안 소켓 계층 복호화 방법
KR20190047924A (ko) * 2017-10-30 2019-05-09 (주) 빌트온 모바일용 애플리케이션과 애플리케이션 서버 사이에서 송수신되는 데이터를 중계하고 추출하는 프록시 서버 및 이를 포함하는 빅데이터 추출 시스템 및 방법
KR20190072907A (ko) * 2017-12-18 2019-06-26 부산대학교 산학협력단 웨어러블 디바이스 통신 지원 장치 및 방법
WO2019172663A1 (ko) * 2018-03-09 2019-09-12 주식회사 수산아이앤티 기설정된 운영체제에서 송신되는 패킷의 보안을 위해서 보안 소켓 계층을 복호화하는 방법
CN116599755A (zh) * 2023-06-09 2023-08-15 四川省交通勘察设计研究院有限公司 一种基于Soc芯片的安全通信及认证方法和装置

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180038496A (ko) * 2015-08-25 2018-04-16 후아웨이 테크놀러지 컴퍼니 리미티드 서비스 처리 방법 및 장치
KR20180027235A (ko) * 2016-09-06 2018-03-14 주식회사 수산아이앤티 보안 소켓 계층 통신을 이용하는 패킷을 선택적으로 검사하는 방법
KR20180031435A (ko) * 2016-09-20 2018-03-28 주식회사 수산아이앤티 보안 소켓 계층 통신을 이용하는 패킷을 검사하는 방법
WO2019045424A1 (ko) * 2017-08-29 2019-03-07 주식회사 수산아이앤티 보안을 위한 보안 소켓 계층 복호화 방법
KR20190024581A (ko) * 2017-08-29 2019-03-08 주식회사 수산아이앤티 보안을 위한 보안 소켓 계층 복호화 방법
KR20190047924A (ko) * 2017-10-30 2019-05-09 (주) 빌트온 모바일용 애플리케이션과 애플리케이션 서버 사이에서 송수신되는 데이터를 중계하고 추출하는 프록시 서버 및 이를 포함하는 빅데이터 추출 시스템 및 방법
KR20190072907A (ko) * 2017-12-18 2019-06-26 부산대학교 산학협력단 웨어러블 디바이스 통신 지원 장치 및 방법
KR101896449B1 (ko) * 2017-12-21 2018-09-07 주식회사 넷앤드 암호화 통신 프로토콜 기반 서버 원격 접근 세션에 대한 보안 감사 및 통제를 위한 접근 통제 시스템
WO2019172663A1 (ko) * 2018-03-09 2019-09-12 주식회사 수산아이앤티 기설정된 운영체제에서 송신되는 패킷의 보안을 위해서 보안 소켓 계층을 복호화하는 방법
US11601405B2 (en) 2018-03-09 2023-03-07 Soosan Int Co., Ltd. Method for decoding secure socket layer for security of packet transmitted in preset operating system
CN116599755A (zh) * 2023-06-09 2023-08-15 四川省交通勘察设计研究院有限公司 一种基于Soc芯片的安全通信及认证方法和装置

Similar Documents

Publication Publication Date Title
US7584505B2 (en) Inspected secure communication protocol
US9819666B2 (en) Pass-thru for client authentication
Maughan et al. Internet security association and key management protocol (ISAKMP)
US7448081B2 (en) Method and system for securely scanning network traffic
US8281127B2 (en) Method for digital identity authentication
US7774594B2 (en) Method and system for providing strong security in insecure networks
KR20090098542A (ko) 프록시를 이용한 암호화 데이터 통신시스템 및 암호화데이터 통신방법
KR20010004791A (ko) 인터넷 환경의 이동통신시스템에서 사용자 정보 보안 장치 및그 방법
US20120072717A1 (en) Dynamic identity authentication system
JP6548172B2 (ja) 端末認証システム、サーバ装置、及び端末認証方法
TW201537937A (zh) 統一身份認證平臺及認證方法
US11722466B2 (en) Methods for communicating data utilizing sessionless dynamic encryption
JP4783340B2 (ja) 移動ネットワーク環境におけるデータトラフィックの保護方法
Maughan et al. RFC2408: Internet Security Association and Key Management Protocol (ISAKMP)
CN114531235B (zh) 一种端对端加密的通信方法及系统
Wang Security issues to tele-medicine system design
Chouhan et al. Privacy Preservation and Data Security on Internet Using Mutual SSL
Dodd Cryptocraft Ltd. matthew@ cryptocraft. co. uk
Anbalagan Secure Shell (SSH): Public Key Authentication over Hypertext Transfer Protocol (HTTP)
Kaighobadi et al. A Pattern for the Secure Shell Protocol
Schneider et al. Network Working Group D. Maughan Request for Comments: 2408 National Security Agency Category: Standards Track M. Schertler Securify, Inc.
is HTTP VI How secure is the Encryption
Andre Domain 5. Cryptography
Kalibjian AN UPDATE ON NETWORK-BASED SECURITY TECHNOLOGIES APPLICABLE TO TELEMETRY POST-PROCESSING AND ANALYSIS ACTIVITIES
Gurbanova Review of the operations over the digital certificates in various cases

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application