이하, 본 발명의 공개키 기반 보안 웹메일 서비스 제공 방법 및 그를 위한 시스템에 대한 바람직한 일 실시 예를 첨부된 도면을 참조하여 설명한다.
본 발명에서는 안전한 PKI 기반의 보안 웹메일을 제공한다. 즉, 인터넷사용자(특히, 메일사용자)가 변조되지 않은 암호키(공개키 및 개인키)를 사용하여 직접 사용자 컴퓨터에서 암호화 및 전자서명을 수행한다. 그에 따라 웹메일 서버가 암호화 및 전자서명에 개입하는 것을 원천적으로 차단한다. 결국 본 발명에서는 암호화된 메일 메시지가 사용자 컴퓨터에서 전송되는 순간부터 해당 수신측 메일사용자가 수신하여 자신의 컴퓨터를 통해 해당 메일 메시지를 읽기 전까지 완벽한 기밀성이 보장된다.
또한 본 발명은 PKI 기반 보안 웹메일에서의 개인키 관리 기술을 제공한다. 특히 본 발명에서는 메일사용자가 PKI 기반에서의 개인키를 서버에 위탁하여 관리한다.
또한 본 발명에서는 보안 웹메일을 통해 수신된 메일 메시지의 본문에 대한 전자서명을 확인하여 읽어볼 수 있다. 즉 첨부파일을 포함한 메일 메시지를 전부 받은 뒤에 서명 확인을 거치던 기존과 달리 메일 본문에 대해서만 부분적으로 서명 확인을 실시하여 선택적으로 메일 본문만을 읽어볼 수 있다.
다음은 본 발명의 공개키 기반 보안 웹메일 서비스 시스템에 대해 상세히 설명한다.
도 1은 본 발명에 따른 보안 웹메일 서비스를 위한 시스템 구성을 나타낸 도면이다.
도 1을 참조하면, 본 발명의 시스템은 인터넷사용자(특히, 메일사용자)의 사용자 컴퓨터(10)와, 사용자 컴퓨터(10)와 암호화된 메일 메시지를 주고받는 웹메일 서버(20)와, 웹메일 서버(30)를 통해 인증 서비스를 제공하는 인증 서버(30)로 구성된다.
사용자 컴퓨터(10)에는 인터넷을 통해 웹메일 서버(20)로 접속하기 위한 브라우저(browser)(11)가 내장된다.
메일사용자는 사용자 컴퓨터(10)에 내장된 브라우저(11)를 구동시키고, 구동된 브라우저에서 미리 알고있는 고유자원 위치자(URL : Uniform Resource Locator)를 사용하여 웹메일 서버(20)로 접근한다.
웹메일 서버(20)는 메일사용자에게 웹환경의 인터페이스를 제공하는데, 다시 말하자면, 메일사용자가 서버(20)로의 접근 시도가 있을 경우에, 그 메일사용자의 사용자 컴퓨터(10)로 메일 송수신을 위한 웹 페이지를 인터페이스시킨다. 이는 메일사용자가 보안 웹메일 사이트에 접속된다는 것을 의미한다.
본 발명의 웹메일 서버(20)는 메일사용자의 사이트 접속이 성공됨에 따라 보안 웹메일 제어모듈(12)을 그 메일사용자의 사용자 컴퓨터(10)로 다운로드(download)시킨다.
메일사용자는 다운로드된 보안 웹메일 제어모듈(12)을 통해 공개키 및 개인키를 생성하고, 그 생성된 공개키와 개인키를 인증기관의 인증 서버(30)에 등록한다. 즉 메일사용자는 개인키와 공개키를 전송하여 전자인증서 등록을 인증 서버(30)에 신청한다.
인증 서버(30)는 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한다.
이후 메일사용자는 메일 메시지 전송을 위한 전자인증서를 발급 받으며, 자신의 개인키와 그 개인키를 암호화하기 위한 암호문장(passphrase)과 함께 상기에서 발급 받은 전자인증서를 자신의 저장장소에 보관하거나, 그 개인키와 암호문장과 함께 위탁하여 보관한다.
본 발명에서는 다음의 세 가지 경우로 나누어 전자인증서를 등록하고, 개인키와 암호문장(passphrase)을 위탁 보관한다.
첫 번째, 메일사용자가 전자인증서 등록만을 요청한 경우이다. 이 경우에는 인증 서버(30)가 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관한다. 또한 이 경우에 그 메일사용자는 자신의 개인키와 암호문장을 디스켓이나 그 밖의 안전한 저장장소에 보관한다.
두 번째, 메일사용자가 전자인증서 등록과 함께 개인키의 위탁 보관을 요청한 경우이다. 이 경우에도 인증 서버(30)는 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관한다. 또한 이 경우에는 메일사용자가 암호문장으로 자신의 개인키를 암호화한 후 웹메일 서버(20)에 위탁 보관한다. 특히 이 때는 암호화된 개인키를 웹메일 서버(20)에 위탁하여 보관하므로 그 웹메일 서버(20)의 신뢰성이 요구된다.
세 번째, 메일사용자가 전자인증서 등록과 함께 암호문장 및 그 암호문장으로 암호화된 자신의 개인키의 위탁 보관을 요청한 경우이다. 이 경우에도 인증 서버(30)는 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관하며, 또한 이 경우에는 메일사용자가 암호문장으로 자신의 개인키를 암호화한 후 웹메일 서버(20)에 위탁 보관하고 동시에 그 개인키 암호화에 사용한 암호문장을 그 웹메일 서버(20)에 위탁 보관한다. 이 때 암호문장은 웹메일 서버(20)에서 미리 제공된 공개키로 암호화된 후 웹메일 서버(20)에 전송되어 보관된다.
마지막 세 번째 경우는, 웹메일 서버(20)를 관리하는 운영자와 타 서버를 관리하는 운영자들 간의 협의에 의해 모든 보안 정보가 노출될 가능성이 있으므로, 메일사용자의 입장에서는 보안성이 떨어진다. 그러나 이 경우는 추후에 메일사용자가 암호문장을 잊어버렸을 경우에 그 암호문장을 알아내는데 적합하며, 또한 키 위탁이 필요할 때 가장 적합하다.
메일사용자는 상기 세 가지 경우 중에서 하나의 경우를 선택하여, 전자인증서의 등록 후 그 전자인증서를 발급 받으며, 또한 자신의 개인키와 그 개인키를 암호화하기 위한 암호문장(passphrase)을 보관 또는 위탁한다.
이후 메일사용자는 보관 또는 위탁된 개인키 및/또는 암호문장을 사용자 컴퓨터(10)로 다운로드되어 내장된 보안 웹메일 제어모듈(12)을 통해 웹메일 서버(20)로부터 제공받고, 결국 자신의 공개키와 개인키를 획득한다. 이후 메일사용자는 획득한 공개키와 개인키를 사용하여 자신의 사용자 컴퓨터(10)에서 다양한 메일 메시지를 생성한다.
여기서, 만약 메일사용자가 사용자 컴퓨터(10)에서 암호화된 메일 메시지를 작성하고자 한다면, 그 메일사용자는 보안 웹메일 제어모듈(12)을 통해 웹메일 서버(20)로부터 전자인증서를 다운로드(download)받아 메일 메시지에 대한 암호화를 실시한다.
다음 메일사용자가 전자서명된 메일 메시지를 작성하고자 한다면, 그 메일사용자는 보안 웹메일 제어모듈(12)에 암호문장을 입력하여 암호화된 개인키를 복호화하고, 그 복호화에 의한 개인키를 사용하여 작성된 메일 메시지에 대해 전자서명을 한다.
다음 메일 메시지를 작성하는데 개인키가 필요할 때나 메일 메시지를 읽는데 개인키가 필요할 때, 우선 메일사용자는 자신이 보관하고 있던 암호화된 개인키를 얻거나, 또는 그 메일사용자는 웹메일 서버(20)로부터 암호화된 개인키를 얻는다. 이후 그 메일사용자는 보안 웹메일 제어모듈(12)에 암호문장을 입력하여 암호화된 개인키를 복호화하고, 그 복호화에 의한 개인키를 개인키 메모리에 로드하여 사용한다. 그러나 개인키를 메모리에 계속 로드해서 사용하는 경우에는 메모리 덤프로 개인키가 누출될 가능성이 있다. 따라서 필요할 때만 개인키를 복호화한 후 메모리에 로드하여 사용하고, 다 사용한 후에는 로드된 복호화 개인키를 곧바로 지운다.
그런데, 상기에서 메일사용자가 전자인증서를 사용하고자 할 때는, 먼저 웹메일 서버(20)에 접속한 후 인증 서버(30)로부터 제공되는 전자인증서 취소 리스트(CRL : Certificate Revocation List)를 통해 사용할 전자인증서가 등록 취소된 것이 아닌지를 확인한다.
다음 메일사용자가 수신된 암호화된 메일 메시지를 읽기 위해서는 송신측의 보안 웹메일 제어모듈(미도시)을 통해 암호화된 메일 메시지를 복호화하여 확인한다. 이 때 메일 메시지 확인을 위한 복호화에는 미리 복호화하여 개인키 메모리에 로드해 둔 자신의 개인키를 사용한다. 이 때도 개인키를 메모리에 계속 로드해서 사용하면 개인키가 누출될 가능성이 있으므로, 필요할 때만 개인키를 복호화한 후 메모리에 로드하여 사용하고 다 사용한 후에는 로드된 복호화 개인키를 곧바로 지운다.
또한 전자서명된 메일 메시지를 읽기 위해서는 그 메일 메시지와 함께 전송된 송신측의 전자인증서를 통해 전자서명을 확인(검증)한다. 그러면 메일 메시지 전체를 읽을 수 있다.
그런데 다른 예로써, 전자서명된 메일 메시지에 첨부파일이 있는 경우에는 메일 메시지의 전자서명을 확인하여 메일 메시지 전체를 읽을 수 있으며, 이후에 메일 사용자가 그 첨부파일을 선택(click)하면 해당 첨부파일에 대한 개별적인 전자서명 확인이 다시 이루어진다.
다시 말하자면, 본 발명에서는 송신측에서 메일 메시지에 대한 전자서명을 실시할 때, 메일 본문에 대한 전자서명이 이루어지고 또한 그 메일 메시지에 첨부된 파일에 대한 개별적인 전자서명이 별도로 이루어지도록 하여, 메일 메시지 전체에 대한 전자서명 확인, 메일 본문에 대한 전자서명 확인과 첨부파일에 대한 전자서명 확인이 개별적으로 이루어지도록 한다. 그에 따라 선택적으로 첨부파일에 대한 전자서명 확인(검증)이 실시되어 그 첨부파일을 다운로드한다.
다음은 상기에서 설명된 시스템 구성을 토대로 하여, 본 발명의 공개키 기반 보안 웹메일 서비스 제공 절차를 보다 상세히 설명한다.
도 2a는 본 발명에 따른 보안 웹메일 서비스를 위한 키 관리 절차를 나타낸 플로우챠트로, 여기서 키 관리는 전자인증서의 생성/보관, 개인키와 암호문장의 위탁 보관을 의미한다.
도 2a를 참조하여 키 관리 절차를 설명하면, 먼저 메일사용자가 자신의 사용자 컴퓨터(10)에 내장된 브라우저(11)를 사용하여 웹메일 서버(20)에 접속하면, 그 웹메일 서버(20)는 보안 웹메일 제어모듈(12)을 그 메일사용자의 사용자 컴퓨터(10)로 다운로드(download)시킨다.
메일사용자는 다운로드된 보안 웹메일 제어모듈(12)을 통해 공개키 및 개인키를 생성한다(S10). 여기서 메일사용자는 공개키와 개인키가 생성될 때 다음에 설명될 세 가지 키 관리 방식 중 하나를 선택하여 결정해 둔다.
이후 메일사용자는 그 생성된 공개키와 개인키를 인증기관의 인증 서버(30)에 등록하기 위한 전자인증서 등록 요청과 개인키 및/또는 암호문장의 위탁 보관을 위한 키 위탁 요청을 포함한 요청 메시지를 작성한다(S20). 여기서 전자인증서 등록/키 위탁 요청 메시지는 인증기관의 인증 서버(30)에게 메일사용자의 공개키를 기반으로 전자인증서를 만들어 줄 것을 요청하는 메시지이며 또한 웹메일 서버(20)와 연동하는 키 관리 데이터베이스(미도시)에 메일사용자의 암호문장 및 그 암호문장으로 암호화된 개인키의 위탁 보관을 요청하는 메시지로써, 다음 표 1과 같은 내용을 포함한다.
사용자 정보 <NL>공개키 <NL>암호화된 개인키(옵션) <NL>암호문장(옵션) <NL> |
여기서, <NL>은 줄 바꿈 기호(Newline character)
A. 만약 메일사용자가 상기한 표 1의 내용을 포함하는 요청 메시지를 사용하여 전자인증서 등록만을 요청한 경우에는, 인증 서버(30)가 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관한다(S30, S60). 또한 메일사용자는 암호문장을 사용하여 개인키를 암호화한 후 그 암호문장과 암호화된 자신의 개인키를 디스켓이나 사용자 컴퓨터(10) 내부의 키 관리 데이터베이스(미도시)와 같은 저장장소에 보관한다(S70, S80).
B. 만약 메일사용자가 상기한 표 1의 내용을 포함하는 요청 메시지를 사용하여 전자인증서 등록과 개인키 위탁 보관을 요청한 경우에는, 일단 인증 서버(30)가 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관한다(S40, S60). 또한 메일사용자는 암호문장을 사용하여 개인키를 암호화한 후 그 암호화된 자신의 개인키를 웹메일 서버(20)에 전송하여 그 웹메일 서버(20)의 키 관리 데이터베이스(미도시)에 위탁 보관한다(S70,S90).
C. 만약 메일사용자가 상기한 표 1의 내용을 포함하는 요청 메시지를 사용하여 전자인증서 등록과 함께 개인키와 암호문장 위탁 보관을 요청한 경우에는, 일단 인증 서버(30)가 메일사용자로부터 전송된 공개키를 자신의 비밀키로 서명하여 전자인증서를 생성한 후 그 생성된 전자인증서를 보관한다(S50, S60). 또한 메일사용자는 암호문장을 사용하여 개인키를 암호화한 후 그 암호화된 자신의 개인키와 암호문장을 웹메일 서버(20)에 전송하여 그 웹메일 서버(20)의 키 관리 데이터베이스(미도시)에 위탁 보관한다(S70,S100). 특히 암호문장은 웹메일 서버(20)에서 미리 제공된 공개키로 암호화된 후 웹메일 서버(20)에 전송되어 보관된다.
이후 메일사용자는 상기 세 가지 키 관리 방식(A, B, C) 중에서 하나를 선택하여 전자인증서의 등록 후 그 전자인증서를 발급 받으며, 자신의 개인키와 그 개인키를 암호화하기 위한 암호문장(passphrase)과 함께 상기에서 발급 받은 전자인증서를 자신의 저장장소에 보관하거나, 그 개인키와 암호문장과 함께 웹메일 서버(20)에 위탁하여 보관한다. 다음은 전자인증서 발급 및 키 관리 절차에 대해 상세히 설명한다.
도 2b는 본 발명에 따른 보안 웹메일 서비스를 위한 전자인증서 발급 및 키 관리 절차를 나타낸 플로우챠트로써, 메일사용자가 상기한 표 1의 내용을 포함하는 요청 메시지를 사용하여 전자인증서 등록과 함께 개인키와 암호문장 위탁 보관을 요청한 경우에 대한 것이다.
도 2b를 참조하면, 우선 메일사용자는 상기한 도 2a에서 설명된 키 관리의 세 가지 방식 중에서 하나를 선택하여 전자인증서 등록을 요청한다. 이 때는 선택적으로 개인키 및/또는 암호문장의 위탁 보관을 요청하며, 그 요청을 위한 메시지 내용은 표 1과 같이 작성된다.
특히 본 발명에서는 작성된 요청 메시지 내용이 제3자에게 노출되지 않도록, 그 요청 메시지 내용을 포함한 다음 표 2와 같은 요청 메일을 작성하고(S110), 다시 그 요청 메일을 웹메일 서버(20)에서 미리 제공된 공개키로 암호화한 후 웹메일 서버(20)에 전송한다(S120,S130).
From : 보안 웹메일 제어모듈To : 웹메일 서버Subject : 전자인증서 요청 메시지Content-Type : text/plain
전자인증서 요청 메시지
첨부파일 : certreq.xcqContent-Type : application/x-certreq; name : certreq.xcqContent-Transfer-Encoding : base64Content-Disposition : attachment; filename : certreq.xcq
내용 : 요청 메시지 |
이후 웹메일 서버(20)는 전송 받은 요청 메일을 복호화하고(S140), 다음 웹메일 서버(20)는 인증기관의 인증 서버(30)에 그 메일사용자의 공개키와 사용자 정보를 제공하여 전자인증서 발급을 요청한다(S150).
이후 웹메일 서버(20)는 인증 서버(30)로부터 전자인증서를 발급 받아 저장 보관하며, 또한 요청 메시지에 포함되었던 메일사용자의 암호화된 개인키와 암호문장(passphrase)을 저장 보관한다(S160).
다음 메일사용자는 사용자 컴퓨터(10)로 다운로드되어 내장된 보안 웹메일 제어모듈(12)을 통해 웹메일 서버(20)에 보관 또는 위탁된 개인키 및 암호문장을 웹메일 서버(20)로부터 제공받으며, 또한 그 웹메일 서버(20)로부터 전자인증서를 발급 받는다(S170).
결국 메일사용자는 자신의 공개키와 개인키를 획득하게 되며, 그 획득한 공개키와 개인키를 사용하여 자신의 사용자 컴퓨터(10)에서 다양한 메일 메시지를 생성한다. 또한 발급 받은 전자인증서를 사용하여 암호화 메일을 작성한다.
다음 도 2c는 본 발명에 따른 보안 웹메일 서비스를 위한 전자인증서 갱신 절차를 나타낸 플로우챠트로써, 이는 상기한 도 2a 및 도 2b의 절차와 거의 유사하다. 단지 초기에 메일사용자에 의해 선택된 키 관리 방식이 그대로 유지된다.
도 2c를 참조하면, 메일사용자는 웹메일 서버(20)로부터 다운로드된 보안 웹메일 제어모듈(12)을 통해 새로운 공개키와 개인키를 생성한다(S200).
이후 메일사용자는 이미 결정해 둔 키 관리 방식을 그대로 유지한 상태에서, 새롭게 생성된 공개키와 개인키를 인증기관의 인증 서버(30)에 갱신 등록하기 위한 전자인증서 갱신 등록 요청과 새로운 개인키 및/또는 암호문장의 위탁 보관을 위한 키 위탁 요청을 포함한 갱신 요청 메시지를 작성한다(S210). 여기서 갱신 요청 메시지는 인증기관의 인증 서버(30)에게 메일사용자의 새로운 공개키를 기반으로 전자인증서를 다시 만들어 줄 것을 요청하는 메시지이며 또한 웹메일 서버(20)와 연동하는 키 관리 데이터베이스(미도시)에 메일사용자의 암호문장 및 그 암호문장으로 암호화된 새로운 개인키의 위탁 보관을 요청하는 메시지로써, 다음 표 3과 같은 내용을 포함한다.
공개키 <NL>암호화된 개인키(옵션) <NL>암호문장(옵션) <NL> |
표 3에서 알 수 있듯이, 그 메일사용자의 사용자 정보는 이미 초기에 등록되어 있으므로, 갱신 요청 메시지에는 공개키 값, 암호화된 개인키 값, 암호문장 값만이 포함된다.
다음에는 작성된 갱신 요청 메시지 내용을 포함하는 다음 표 4와 같은 갱신 요청 메일을 작성한다(S220).
From : 보안 웹메일 제어모듈To : 웹메일 서버Subject : 전자인증서 갱신 요청 메시지Content-Type : text/plain
전자인증서 갱신 요청 메시지
첨부파일 : certreq.xcqContent-Type : application/x-certreq; name : certreq.xcqContent-Transfer-Encoding : base64Content-Disposition : attachment; filename : certreq.xcq
내용 : 갱신 요청 메시지 |
그 작성된 상기 표 4의 갱신 요청 메일은 기존에 생성되었던 메일사용자의 개인키로 전자서명되고(S230), 다시 웹메일 서버(20)에서 미리 제공된 공개키로 암호화되어 웹메일 서버(20)로 전송된다(S240,S250).
이후 웹메일 서버(20)는 전송 받은 갱신 요청 메일을 복호화하고(S260), 다음 웹메일 서버(20)는 인증기관의 인증 서버(30)에 그 메일사용자의 새로운 공개키를 제공하여 전자인증서 재발급을 요청한다(S270).
이후 웹메일 서버(20)는 인증 서버(30)로부터 새로운 전자인증서를 발급 받아 저장 보관하며, 또한 갱신 요청 메시지에 포함되었던 메일사용자의 암호화된 개인키와 암호문장(passphrase)을 갱신 저장 보관한다(S280).
다음 메일사용자는 사용자 컴퓨터(10)로 다운로드되어 내장된 보안 웹메일 제어모듈(12)을 통해 웹메일 서버(20)에 보관 또는 위탁된 개인키 및 암호문장을 웹메일 서버(20)로부터 제공받으며, 또한 그 웹메일 서버(20)로부터 전자인증서를 발급 받는다(S290).
결국 메일사용자는 자신의 갱신된 공개키와 개인키를 획득하게 되며, 그 획득한 공개키와 개인키를 사용하여 자신의 사용자 컴퓨터(10)에서 다양한 메일 메시지를 생성한다. 또한 발급 받은 전자인증서를 사용하여 암호화 메일을 작성한다.
특히 메일사용자가 전자서명된 메일 메시지를 작성하고자 한다면, 그 메일사용자는 보안 웹메일 제어모듈(12)에 암호문장을 입력하여 암호화된 개인키를 복호화하고, 그 복호화에 의한 개인키를 사용하여 작성된 메일 메시지에 대해 전자서명을 한다. 또한 암호화된 수신 메일을 읽을 때도 그 개인키가 필요하다.
그런데 메일사용자는 자신의 공개키/개인키 또는 갱신된 공개키/개인키를 획득함에 있어, 상기에서 이미 설명된 키 관리 방식에 따라 서로 다르게 획득한다.
첫 번째, 메일사용자가 전자인증서 등록만을 요청한 경우에는 사용자 컴퓨터(10)의 키 관리 데이터베이스(미도시)에 암호문장으로 암호화되어 저장된 개인키를 암호문자 입력으로 복호화함으로써 그 개인키를 획득한다. 이 때는 보안 웹메일 제어모듈(12)에 암호문장을 입력하여 암호화된 개인키를 복호화한다.
두 번째, 메일사용자가 전자인증서 등록과 함께 개인키의 위탁 보관을 요청한 경우에 그 메일사용자는 웹메일 서버(30)로부터 암호화된 개인키를 얻은 후 보안 웹메일 제어모듈(12)에 암호문장을 입력하여 암호화된 개인키를 복호화함으로써 그 개인키를 획득한다.
세 번째, 메일사용자가 전자인증서 등록과 함께 암호문장 및 그 암호문장으로 암호화된 자신의 개인키의 위탁 보관을 요청한 경우에는, 메일사용자가 전자인증서 등록과 함께 개인키만의 위탁 보관을 요청한 경우와 동일한 방식으로 개인키를 획득한다. 단지 이 세 번째 경우에는 추후에 메일사용자가 암호문장을 잊어버렸을 경우에 보안이 유지된 채널을 통해 그 암호문장을 다시 알아낼 수 있다.
다음은 본 발명의 보안 웹메일 서비스를 실시함에 있어, 전자서명된 메일 메시지에 대한 부분적인 전자서명 확인 절차에 대해 설명한다.
그런데 부분적 전자서명 확인 절차의 설명에 앞서 도 3을 참조하여, 전자서명된 메일 메시지 포맷에 대해 설명한다.
도 3은 본 발명의 보안 웹메일 서비스에서 부분적 전자서명 확인 절차를 설명하기 위한 전자서명된 메일 메시지 포맷을 나타낸 도면으로, n개의 첨부파일이 포함된 메일 메시지 포맷을 나타낸 것이다.
본 발명의 메일 메시지는 기본적으로 MIME 형식의 메일 포맷을 사용한다. 하나의 MIME 형식 메일 포맷의 한 예를 아래 표 5에 나타내었다.
Received: by soft.co.kr(?.?.?/?.?.?) id forumDate: Mon, 26 Jul 1999 15:10:11Message-Id: <199907261510.forum@soft.co.kr>From: 홍길동Subject: today's newsContent-type: text‥‥▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶성 명 : 홍길동우편번호 : 123-456주 소 : 서울시 영등포구 여의도동 78-90전화번호 : 02-123-4567이메일 주소 : hanson@soft.co.kr근 무 처 : (주)소프트포럼▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶▶ |
도 3에서 각 블록(100∼300)은 상기 표 5에서의 "Content-Type"이 멀티파트(multipart)인 MIME 형식의 메일 포맷에서 경계(boundary)로 구분되는 것과 동일하다.
먼저 메인 메시지 블록(100)은 메일사용자가 메일 본문을 기입하는 블록이며, 수신측 메일사용자에게 송신되었을 때 그 메일 본문이 포함되는 블록이다. 특히 메인 메시지 블록(100)은 메인 메시지(110)와 메인 메시지 서명 값(120)으로 나뉜다.
메인 메시지(110)에는 메일사용자가 기입한 메일 본문과 첨부된 여러 파일들의 전자서명 값들이 들어 있다. 따라서 도 3과 같이 첨부파일이 n개라면 메인 메시지에 포함된 첨부파일에 대한 전자서명 값도 n개이다.
수신측 메일사용자는 처음에 메인 메시지 블록(100)이 다운로드됨에 따라 메일 본문에 대한 전자서명을 확인하며, 메인 메시지(110)에 메일 본문과 함께 포함된 각 첨부파일에 대한 전자서명 값은 이후에 다운로드될 각 첨부파일 블록(200∼300)들에 대해 개별적인 전자서명 확인을 위한 것이다.
본 발명에서는 수신측 메일사용자가 메일 메시지를 수신한 뒤 그 내용을 확인할 때, 도 3의 모든 블록을 포함한 전자서명된 메일 메시지 전체 중에서 첨부파일이 생략된 메인 메시지 블록(100)만을 내려 받아 부분적으로 전자서명을 확인한다.
다음 전체 메일 메시지(100∼300)가 n개의 첨부파일을 포함한다면, 첨부파일 블록(200,300) 또한 n개가 된다.
각 첨부파일 블록(200,300)은 첨부파일 본문(210,310)과 첨부파일 서명 값(220,320)으로 나뉜다.
첨부파일 본문(210,310)에는 말 그대로 첨부된 하나의 파일이 들어 있으며, 각 첨부파일 블록(200,300)마다 각 첨부파일 본문에 대한 전자서명 값(220,320)이 들어 있다.
만약 수신측 메일사용자가 n번째 첨부파일을 다운로드(download)하면, n번째 첨부파일 블록(300)의 첨부파일 본문(310)과 그 첨부파일 본문에 대한 전자서명 값(320)을 얻는다. 따라서 이 때 수신측 메일사용자는 일단 메인 메시지 블록(100)에 포함된 n번째 첨부파일 서명 값과 다운로드된 n번째 첨부파일 블록(30)의 첨부파일 서명 값(320)을 먼저 비교하여 해당 첨부파일이 적절히 왔는지를 확인한 후 n번째 첨부파일 본문(310)과 그 첨부파일 본문의 전자서명 값(320)을 통해 전자서명을 확인한다.
다음 도 4는 본 발명에 따른 보안 웹메일 서비스에서 부분적 전자서명 확인 절차를 나타낸 플로우챠트이다.
도 3을 참조하면, 송신측 메일사용자는 첨부파일이 포함된 메일 메시지를 자신의 개인키로 전자서명한 뒤 송신한다(S300).
수신측 메일사용자는 전체 메일 메시지 중에서 일단 도 3에 도시된 메인 메시지 블록(100)을 수신한다(S310). 더욱 상세하게, 메일 프로그램의 구동에 따라 수신측 사용자 컴퓨터(10)의 브라우저(11) 화면에 디스플레이되는 메일 목록에서 수신측 메일사용자가 원하는 하나의 메일을 선택(click)하면, 첨부파일이 포함된 전체 메일 메시지 대신에 메인 메시지 블록만이 수신된다.
이후 수신측 메일사용자는 수신된 메인 메시지 블록에서 메인 메시지에 대해 전자서명을 확인한다(S320). 여기서 메인 메시지에 대한 전자서명 확인은 메일 메시지 전체에 대한 전자서명 확인과 동일하게 해쉬함수 알고리즘(Hash function algorithm)으로 실시된다.
실제 전자서명 확인은 다음 수학식 1 내지 수학식 3의 제1메시지해쉬값과 제2메시지해쉬값이 동일한지 검증하여 메인 메시지의 전자서명을 확인한다.
제1메시지해쉬값 = H{ 메인 메시지 }
여기서 H는 해쉬함수를 나타내며, 제1메시지해쉬값은 메인 메시지(110)를 해쉬함수로 전자서명하여 얻은 값이다.
메인 메시지 블록(100)에서 메인 메시지(110)는 메일 본문과 여러 첨부파일 서명 값으로 구성되므로, 다음 수학식 2와 같이 나타낸다.
메인 메시지 = { 메일본문 | 첨부파일 서명값(1) | ‥‥ | 첨부파일 서명값(n) }
다음 제2메시지해쉬값은 수신된 메인 메시지 서명 값(120)을 송신측에서 미리 알려준 공개키로 복호화하여 얻은 값으로, 수학식 3과 같다.
제2메시지해쉬값 = 송신측 공개키로 복호화 { 메인 메시지 서명 값 }
이렇게 수학식 1 내지 수학식 3의 제1메시지해쉬값과 제2메시지해쉬값이 동일한지 검증하여 메인 메시지의 전자서명을 확인한다.
이후 수신측 메일사용자는 메일 메시지에 포함된 첨부파일을 수신하고, 그 첨부파일에 대한 전자서명을 확인한다(S330,S340).
만약 수신측 메일사용자가 n번째 첨부파일을 선택(click)하여 다운로드(download)하면, n번째 첨부파일 블록(300)의 첨부파일 본문(310)과 그 첨부파일 본문에 대한 전자서명 값(320)을 얻는다. 따라서 이 때 수신측 메일사용자는 n번째 첨부파일 본문(310)과 그 첨부파일 본문의 전자서명 값(320)을 통해 전자서명을 확인한다.
실제 첨부파일에 대한 전자서명 확인은 다음 수학식 4 내지 수학식 5의 제3메시지해쉬값과 제4메시지해쉬값이 동일한지 검증하여 첨부파일의 전자서명을 확인한다.
제3메시지해쉬값 = H{ 첨부파일본문 }
여기서 H는 해쉬함수를 나타내며, 제3메시지해쉬값은 첨부파일 본문(310)을 해쉬함수로 전자서명하여 얻은 값이다.
다음 제4메시지해쉬값은 첨부파일 서명 값(320)을 송신측에서 미리 알려준 공개키로 복호화하여 얻은 값으로, 수학식 5와 같다.
제4메시지해쉬값 = 송신측 공개키로 복호화 { 첨부파일 서명 값 }
이렇게 수학식 4 내지 수학식 5의 제3메시지해쉬값과 제4메시지해쉬값이 동일한지 검증하여 첨부파일의 전자서명을 확인한다.
상기한 도 4의 절차를 통해 수신측 메일사용자는 첨부파일을 처음에 모두 다운로드 받지 않고도 메일 메시지 전체에 대한 전자서명 확인이 가능하며, 이후의 첨부파일에 대한 개별적인 서명확인도 가능하다.