KR100423191B1

KR100423191B1 - 보안 프로토콜을 이용하여 전송될 벌크 데이터의 대칭 암호화 효율을 향상시키기 위한 방법, 시스템 및 기록 매체

Info

Publication number: KR100423191B1
Application number: KR10-2001-0026321A
Authority: KR
Inventors: 도브너에드워드제이; 퀘르-맥라렌데이비드지; 리베치패트릭마이클; 쇼리애크티모시지
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2000-06-08
Filing date: 2001-05-15
Publication date: 2004-03-18
Anticipated expiration: 2021-05-15
Also published as: GB2366974B; KR20010110991A; GB2366974A; CN1329417A; GB0113692D0; CN1309207C

Abstract

본 발명은 보안 소켓 계층(SSL) 또는 트랜잭션 층 보안(TLS)과 같은 보안 프로토콜을 이용하여 전송될 벌크(bulk) 데이터의 대칭 암호화를 수행하는 방식의 효율을 향상시키기 위한 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다. 제공되는 파일은 그 파일 내에 프로토콜 규정에 따라서 해시 값이 요구되는 위치에 빈 공간을 삽입한다. 상기 파일이 클라이언트에 의해 요청될 때, 실제 해시 값이 계산되어 예약된 빈 공간을 대체한다. 본 기법은 큰 데이터 블록을 암호화 엔진에 전송할 수 있도록 하며, 보안 프로토콜 규정에 의해 부과되는 메시지 세그먼트들에 대한 보다 작은 크기 제한에 관계없이 그 결과의 처리 효율을 이용한다.

Description

보안 프로토콜을 이용하여 전송될 벌크 데이터의 대칭 암호화 효율을 향상시키기 위한 방법, 시스템 및 기록 매체{IMPROVING SECURE SERVER PERFORMANCE WITH PRE-PROCESSED DATA READY FOR SECURE PROTOCOL TRANSFER}

본 발명은 컴퓨터 시스템에 관한 것으로, 특히, 보안 프로토콜(보안 소켓 계층 또는 "SSL", 또는 트랜잭션 층 보안 또는 "TLS"와 같은 보안 프로토콜)을 이용하여 전송될 데이터를 전처리(pre-processing)함으로써, 네트워킹 환경의 성능을 개선하기 위한 방법, 시스템 및 컴퓨터 프로그램 제품에 관한 것이다.

보안 소켓 계층 또는 "SSL"은 넷스케이프사와 RSA 데이터 시큐리티사에 의해 개발된 네트워킹 프로토콜로서, 안전하지 않은(non-secure) 환경에서 네트워크 통신을 안전하게 할 수 있도록 하기 위한 것이다. 보다 구체적으로는, SSL은 인터넷 환경에서 사용되도록 설계되어, TCP/IP(Transmission Control Protocol/Internet Protocol) 층 위의 프로토콜층으로서 동작한다. 그러면, 애플리케이션 코드가 네트워킹 프로토콜 스택 내의 SSL 상에 위치한다. 애플리케이션(브라우저와 같은)이 네트워크 내의 피어(peer)로 전송될 데이터를 생성하면, 상기 데이터는 다양한 보안 절차가 행해지는 SSL 층으로 전송되며, 그 다음에 SSL에 의해 변환된 데이터가 TCP 층으로 전송된다. 접속의 수신측 상에서, TCP 층은 인입되는 데이터를 수신한 후에 그 데이터를 SSL 층으로 전송하며, 상기 SSL 층에서 상기 데이터를 원래의 형태로 복원하고 복원된 데이터를 수신 애플리케이션에 전송하는 절차가 수행된다. SSL의 가장 최신 버전은 1996년 11월 18일자로 갱신된 "The SSL Protocol, Version 3.0"에 상세히 개시되어 있으며, http://home.netscape.com/eng/ssl3/draft302.txt(이하에서는 "SSL 상세"라 함)의 월드 와이드 웹("Web")에서 얻을 수 있다.

상기 인터넷 하의 프로토콜(예를 들면, TCP/IP)은 보안 데이터 전송을 제공하도록 설계되지 않았다. 인터넷은 원래 대학 및 학술 단체를 염두에 두고 설계되었으며, 네트워크의 사용자들은 적대적이 아닌 협력하는 방식으로 네트워크를 이용하리라고 추정되었다. 인터넷이 대중망으로 확장되기 시작했지만, 대부분의 사용자들은 큰 단체 내에 위치하였기 때문에 이들 단체 외부에서의 사용은 제한되었다. 이들 단체들은, 인터넷 그 자체에 내장되는 시큐리티를 필요로 하지 않는 방화벽과 같은 다양한 보안 절차들로 사용자의 데이터를 보호하는 컴퓨팅 시설을 갖고 있다. 그러나, 지난 수년동안 인터넷 사용이 급증하여 왔다. 현재에는 수백만의 사람들이 일상적으로 인터넷과 웹을 사용한다. (이하에서, "인터넷" 및 "웹"이란 용어는, 특별한 언급이 없는 한 동일한 의미로 사용된다.) 사용자들은 전자 우편 메시지 교환으로부터 상거래에 대한 정보를 검색하는 것까지 다양한 작업을 수행한다. 사용자들은 보안 절차들이 일반적으로 이용될 수 없는 가정으로부터, 그들의 셀룰러 폰으로부터, 또는 수많은 기타 환경으로부터 인터넷을 액세스할 수도 있다. "전자 상거래" 또는 간단히 "e-commerce"라 지칭되는 비즈니스가 존속할 수 있는 공간으로서의 인터넷의 성장을 지원하기 위해, 쉽게 액세스할 수 있고 저렴한 보안 절차가 개발되어야 한다. SSL은 하나의 일반적인 솔루션으로서, 하이퍼텍스트 전송 프로토콜("HTTP")을 이용하여 데이터를 송신 및 수신하는 애플리케이션과 함께 일반적으로 사용된다. HTTP는 웹이라고 하는 인터넷의 일부를 액세스하는데 가장 일반적으로 이용되는 프로토콜이다. HTTP는 안전한 통신을 제공하기 위해 SSL과 함께 사용되며, 그 조합은 "HTTPS"로 지칭된다. 비상업적 인터넷 트래픽은 또한 SSL이 제공하는 보안으로부터 이득을 얻을 수 있다. SSL은 SMTP(Simple Mail Transfer Protocol) 및 NNTP(Network News Transfer Protocol)과 같은 HTTP 이외의 데이터 전송 프로토콜과 함께 사용하는 것이 제안되어 왔다.

SSL은 몇가지 상이하지만 상보형인 시큐리티를 제공하도록 설계된다. 첫째는 메시지 프라이버시이다. 프라이버시는 송신자 및 수신자 이외의 사람에 의해 판독될 수 없도록 메시지 내용을 보호하는 것을 지칭한다. 프라이버시는 메시지를 암호화하고 해독하기 위해 암호문(cryptography)을 이용하여 제공된다. SSL은 또한 공용키 암호문으로 알려져 있는 대칭 암호문을 이용한다. 메시지 수신자는, 메시지 생성자의 공용키와 관련되는 적절한 개인 키 및 해독 알고리즘을 갖고 있으면 암호화된 메시지를 해독할 수 있다. 둘째, SSL은 전송되는 메시지에 대한 데이터 무결성을 제공한다. 데이터 무결성은, 메시지가 생성된 후 그 메시지의 내용이 변경되었는지의(따라서, 그 메시지가 신뢰할 수 없게 함) 여부를 메시지 수신측이 검출할 수 있는 능력을 지칭한다. 메시지 생성자는 "메시지 다이제스트" 또는 "메시지 인증 코드"라고 하는 것을 생성하는 알고리즘을 통해 상기 메시지를 전송한다. 한편, 상기 알고리즘 출력은, 이러한 타입의 알고리즘이 "해싱 알고리즘"으로 알려져 있기 때문에, 때론 메시지의 "해시"로서 지칭된다. 상기 다이제스트 또는 해시는 메시지와 함께 송신된다. 메시지가 수신되면, 수신기는 또한 다른 다이제스트를 생성하는 알고리즘을 통해 메시지를 처리한다. 만약 수신기에 의해 계산된 다이제스트가 메시지와 함께 송신된 다이제스트와 일치하지 않으면, 메시지가 생성된 후 메시지 내용이 몇몇 방법으로 변경되었다고 추측할 수 있다. SSL이 제공하는 제 3 보안 특징은 인증(authentication)으로 알려져 있다. 인터넷을 통한 통신은 일련의 전자 신호들로서 발생되므로, 통신측은 서로 볼 수 없으며, 그들이 통신하는 대상을 시각적으로 판정할 수 없다. 인증이란, 통신측이 사람이든 애플리케이션 프로그램이든 관계없이, 통신측이 그들 자신이 누구인지를 나타내는 것을 보증하도록 돕는 기법이다. 예를 들면, 사용자(사람)가 신용카드를 이용하여 인터넷을 통해 상품을 구입하는 경우, 사용자가 그의 신용카드 정보를 위해 접속하고 있는 다른 말단(the other end)에 대기하고 있는 애플리케이션이 실제로 그가 거래를 하고자 생각하고 있는 판매인인지 아니면 그의 신용카드 정보를 훔치려고 대기하고 있는 사기꾼인지를 아는 것이 중요하다.

이들 보안 특징들은 아주 강력하며, 인터넷 사용자들에게 고도의 방호를 제공한다. 그러나, SSL 프로토콜의 동작은 상당한 량의 처리 오버헤드를 발생한다. 보안 HTTP 서버와 같은 보안 인터넷 서버들은 보안 메시지 내용에 대한 아주 많은 수의 요청에 대해 적절히 응답할 수 있어야 한다. SSL 프로토콜의 오버헤드로 인해 이들 서버들은 클라이언트 요청 처리시에 병목현상을 일으키게 된다. SSL 프로토콜 오버헤드는 다음의 세가지 요인에 기인한다. (1) 여분의 네트워크 트래픽(예를 들면, 다수의 다양한 보안 관련 파라미터들이 일련의 메시지 교환을 협상하는 핸드쉐이킹(handshaking) 프로토콜에서), (2) 보안 세션이 시작될 때 클라이언트와 서버 사이에서 전송되는 암호키 및 해독키에 대한 비교적 고가의 비대칭 키 암호문 동작의 이용, (3) 클라이언트와 서버 사이에 전송되는 벌크 데이터의 대칭 암호화.

상기 첫 번째 요인은 소켓에 관해서 SSL 프로토콜을 효율적으로 구현함으로써 처리되었다. 두 번째 요인은 암호화 하드웨어 어댑터 카드 및 액셀러레이터의 다양한 판매업자들에 의해 해결된다. 벌크 데이터의 암호화 동안, 세 번째 요인은 다른 요인들만큼 많은 오버헤드를 발생하지 않지만, 여전히 상당한 량의 처리 시간을 소모한다. 많은 암호화 하드웨어 액셀러레이터들은 공지되어 있는 DES, 3DES, RC4 암호와 같은 대칭 암호화("대칭 암호(symmetric ciphers)"라고도 함)를 위한 회로를 포함한다. 그러나, SSL 프로토콜의 성질이 이들 액셀러레이터로부터의 이점을 얻을 수 없도록 한다. 이것은, SSL 프로토콜이 임의의 개별적인 메시지 전송의 페이로드로 전송되는 데이터에 대해 최대 크기를 16 킬로바이트로 제한하기 때문이다. 따라서, 이 크기를 초과하는 메시지 또는 필드는 다수의 메시지 전송을 이용하여 분할(segment)하여 교환되어야 한다. (일부 더 높은 레벨의 애플리케이션들은 상기 크기 제한을 더 낮게 하며, 애플리케이션의 최적의 세그먼트 크기는 4K로 결정된 것으로 알려져 있다.) 이것과 관련된 문제는 대부분의 암호화 하드웨어 카드 및 액셀러레이터들이 큰 블록의 데이터에 의해 가장 효율적으로 동작한다는 것이다. 그러나, 각각의 암호화된 블록이 블록 내의 데이터에 대해 (암호화 프로세스 전에)계산된 해시 값(hash value)을 포함해야 하기 때문에, SSL 프로토콜은 최대 레코드 크기보다 더 큰 블록 내의 데이터 암호화를 금지한다. 상기 제한 때문에, 대형의 메시지는 최대 레코드 크기보다 더 작은 복수의 세그먼트들(즉, 각 세그먼트 내에 삽입된 해시 값을 위한 공간을 가짐)을 이용하여 암호화 엔진으로 전송되며, 그 결과 암호화 엔진을 최적으로 사용할 수 없게 된다. (본원 명세서에 사용되는 "암호화 엔진"은, 카드 또는 액셀러레이터와 같은 하드웨어로 구현된 프로세스일 수도 있지만 특정 환경에서는 소프트웨어 또는 하드웨어와 소프트웨어의 조합으로 구현될 수도 있는 암호화 프로세스를 지칭한다.)

트랜잭션 층 보안(TLS) 프로토콜은 SSL을 대체할 후속 기술로서 설계된다. (SSL은 버전 3.0으로 끝나고, TLS가 SSL 버전 3.0 상세에 기초한 버전 1.0으로 시작된다.) TLS는 IETF(Internet Engineering Task Force)의 작업 그룹에 의해 표준화되며, 1999년 1월의 "The TLS Protocol, Version 1.0"(RFC 2246)에 상세히 설명되어 있다. TLS 프로토콜에서의 메시지 교환은 SSL 프로토콜의 메시지 교환과 유사하며, 따라서 TLS도 전술한 비효율성을 갖는다.

SSL 처리량을 증가시키기 위한 한 가지 방법은 전체 프로토콜을 하드웨어 장치에 집어넣는 것이다. 이 경우, 상기 전체 SSL 프로토콜은 네트워크 층에서 행해지며, 애플리케이션은 카드 인터페이스로 진행하는 데이터와 카드 인터페이스로부터 나오는 (암호화되지 않은) 데이터를 분명히 보기만 한다. 그러나, 통상적인 서버가 동시에 진행하는 수백개의 SSL 세션을 가질 수도 있기 때문에, 단일 카드 내에서 효율적으로 관리하기가 어려울 수 있다. 또한, 상이한 애플리케이션(및 때론 동일 애플리케이션 내부의 일부 상이한 포트들)이 상이한 키 값들, 클라이언트 인증 등과 같이 SSL 프로세싱에서 변수를 요구할 수도 있다. 전체 프로토콜을 수행하는 SSL 하드웨어 디바이스는 유연하지 않거나 또는 카드의 비용(처리량 및 달러 양면에서)이 기능의 향상에 따라 증가될 것이다. 또한, SSL 하드웨어는 새로운 암호가 SSL 및/또는 TLS에 부가될 때 갱신되기 어려울 것이다.

따라서, SSL 또는 TLS와 같은 보안 프로토콜을 이용하여 전송용의 벌크 데이터의 대칭 암호화를 수행하는 방법을 개선하는 기술이 필요하다.

본 발명의 목적은 SSL 또는 TLS와 같은 보안 프로토콜을 이용하여 전송될 벌크 데이터의 대칭 암호화를 개선하는 기법을 제공하는 것이다.

본 발명의 다른 목적은 상기 데이터가 복수의 보다 작은 블록들로 전송되어야 하는 경우에도, 상기 기법을 이용하여 보다 큰 데이터 블록의 이점이 실현될 수 있도록 하는 것이다.

본 발명의 또 다른 목적은 보안 프로토콜을 이용하여 전송될 데이터 파일의 사전 처리(pre-processing)를 통해 상기 기법을 제공하는 것으로, 상기 사전 처리는, 보다 작은 블록 크기를 전송하기 위한 프로토콜 요건을 고집하는, 대형 블록 크기를 이용하여, 암호화를 위한 최적의 형식으로 수정된 파일을 생성한다.

본 발명의 또 다른 목적 및 이점은 다음의 상세한 설명 및 도면에 부분적으로 개시되어 있다.

도 1은 본 발명이 실시될 수 있는 컴퓨터 워크스테이션 환경의 블록도,

도 2는 본 발명이 실시될 수 있는 네트워크로 연결된 컴퓨팅 환경을 도시한 도면,

도 3 및 4는 본 발명의 바람직한 실시예를 구현하는데 이용될 수 있는 논리의 흐름도,

도 5는 본 발명의 바람직한 실시예에 따른 파일 처리 전후에 요청자에게 전송되는 데이터 파일을 도시한 도면.

도면의 주요 부분에 대한 부호의 설명

10 : 워크스테이션 14 : 버스

16 : 사용자 인터페이스 어댑터 18 : 키보드

20 : 마우스 22 : 인터페이스 장치

24 : 디스플레이 장치 26 : 디스플레이 어댑터

28 : 메모리 30 : 저장 장치

32 : 통신 채널

상기 목적을 달성하기 위하여, 본 발명은 보안 프로토콜을 이용하는 전송을 위해 벌크 데이터의 대칭 암호화가 수행되는 방법을 향상시키기 위한 방법, 시스템 및 컴퓨터 프로그램 제품을 제공한다. 상기 기법은 안전하게 전송될 파일을 결정하는 단계와, 상기 파일을 사전 처리하여 보안 전송 전에 인가될 대칭 암호화 프로세스를 최적화하는 단계를 포함한다. 상기 사전 처리 단계는 보안 전송 동안 파일에 사용될 데이터의 레코드 크기를 계산하는 단계 -상기 레코드 크기는 (세그먼트 크기 - 해시 길이)임-와, 상기 파일을 레코드 크기의 일련의 레코드들로 분할하는 단계 -상기 레코드들 중 하나는 상기 레코드 사이즈보다 짧을 수도 있음-와, 각각의 레코드 열에 빈 공간을 부가하는 단계와, 각각의 레코드 열 및 부가된 빈 공간을 출력 파일에 기록하는 단계를 더 포함한다. 마지막 블록에서 상기 부가 단계가 동작하기 전에 패딩(padding) 블록이 상기 레코드들 중 마지막 레코드에 첨부될 수도 있다.

출력 파일의 첫 번째 레코드에 헤더가 미리 부착될 수도 있는데, 상기 헤더는 다음 중 하나 이상을 포함하는 정보를 저장한다. (1)대칭 암호화 프로세스에 사용되는 암호화 알고리즘의 식별, (2) 대칭 암호화 프로세스의 동작 전에 레코드에 적용되는 해싱 알고리즘의 식별, (3) 레코드 크기.

상기 기법은 파일 요청을 수신하는 단계와, 상기 수신에 응답하여 출력 파일을 배치하는 단계와, 수신된 요청과 관련된 암호화 키 및 해시 키를 획득하는 단계와, 상기 획득한 해시 키를 이용하여 시퀀스 내의 각각의 레코드에 해싱 알고리즘을 적용하는 단계와, 각각의 레코드에 대하여, 부가된 빈 공간을 해싱 알고리즘의 결과로 대체하여 암호화된 파일을 생성하는 단계와, 상기 요청에 응답하여 암호화된 파일을 전송하는 단계를 더 포함한다. 이 경우, 상기 기법은 또한, 헤더를 출력 파일의 선두에 부가하는 단계 -상기 헤더는 대칭 암호화 알고리즘의 식별을 포함하는 정보를 저장함- 와, 획득한 암호화 키를 암호화에 사용하기 위해 헤더에 부가하는 단계를 더 포함한다. 또는, 선두에 부가된 헤더는 해싱 알고리즘의 식별을 포함하는 정보를 저장할 수도 있는데, 이 경우, 상기 기법은 상기 적용 단계에 이용하기 위해 획득된 해시 키를 헤더에 부가하는 단계를 더 포함한다.

보안 프로토콜은 보안 소켓 계층(SSL), 트랜잭션 층 보안(TLS) 또는 다른 보안 프로토콜일 수도 있다.

이하, 본 발명을 첨부한 도면과 관련하여 설명한다. 도면에서 유사한 참조 번호는 동일한 요소를 나타낸다.

도 1은 본 발명이 실시될 수 있는 대표적인 워크스테이션 하드웨어 환경을 도시한 것이다. 도 1의 환경은 개인용 컴퓨터와 같이 관련 주변 장치를 포함하는 대표적인 단일 사용자 컴퓨터 워크스테이션(10)을 포함한다. 워크스테이션(10)은 마이크로프로세서(12)와, 공지되어 있는 기술에 따른 워크스테이션(10)의 컴포넌트들과 마이크로프로세서(12) 사이의 접속 및 통신을 가능하게 하는데 사용되는 버스(14)를 포함한다. 워크스테이션(10)은 통상적으로 버스(14)를 통하여 키보드(18), 마우스 및/또는 터치 스크린, 디지털화된 입력 패드 등과 같은 임의의 사용자 인터페이스 장치일 수도 있는 기타 인터페이스 장치(22)와 같은 하나 이상의 인터페이스 장치에 마이크로프로세서(12)를 접속하는 사용자 인터페이스 어댑터(16)를 포함한다. 버스(14)는 또한 LCD 스크린 또는 모니터와 같은 디스플레이 장치(24)를 디스플레이 어댑터(26)를 통해 마이크로프로세서(12)에 접속한다. 버스(14)는 또한 마이크로프로세서(12)를 하드 드라이브, 디스켓 드라이브, 테이프 드라이브 등을 포함할 수 있는 장기간 저장 장치(30) 및 메모리(28)에 접속한다.

워크스테이션(10)은 예를 들어 통신 채널 또는 모뎀(32)을 통해 다른 컴퓨터 또는 컴퓨터 네트워크와 통신할 수도 있다. 한편, 워크스테이션(10)은 32에서 CDPD(cellular digital packet data) 카드와 같은 무선 인터페이스를 이용하여 통신할 수도 있다. 워크스테이션(10)은 LAN(local area network) 또는 WAN(wide area network) 내의 다른 컴퓨터들과 관련될 수도 있고, 다른 컴퓨터 등을 구비한 클라이언트/서버 장치 내의 클라이언트일 수도 있다. 이러한 모든 구성들 및 적절한 통신 하드웨어 및 소프트웨어는 공지되어 있다.

도 2는 본 발명이 실시될 수 있는 데이터 처리 네트워크(40)를 도시한 것이다. 데이터 처리 네트워크(40)는 복수의 개별적인 워크스테이션(10)을 각각 포함할 수도 있는 무선 네트워크(42) 및 네트워크(44)와 같은 복수의 개별적인 네트워크를 포함할 수도 있다. 또한, 당업자라면, 하나 이상의 LAN이 포함될 수도 있음을 알 수 있을 것이다. 여기서 상기 LAN은 호스트 프로세서에 결합된 복수의 지능형 워크스테이션을 포함할 수도 있다.

도 2에서, 네트워크(42, 44)는 게이트웨이 컴퓨터(46) 또는 애플리케이션 서버(47)(데이터 저장소(48)를 액세스할 수도 있는)와 같은 메인프레임 컴퓨터들 또는 서버들을 포함할 수도 있다. 게이트웨이 컴퓨터(46)는 각각의 네트워크(44)로의 입구로서 작용한다. 게이트웨이(46)는 통신 링크(50a)에 의해 다른 네트워크(42)에 결합되는 것이 바람직할 수도 있다. 게이트웨이(46)는 또한 통신 링크(50b, 50c)를 이용하여 하나 이상의 워크스테이션(10)에 직접 결합될 수도 있다. 게이트웨이 컴퓨터(46)는 IBM 사의 Enterprise Systems Architecture/370, Enterprise Systems Architecture/390 컴퓨터 등을 이용하여 구현될 수도 있다. 애플리케이션에 따라서, 애플리케이션 시스템/400(AS/400이라고도 함)과 같은 중간범위의 컴퓨터가 이용될 수도 있다. ("Enterprise Systems Architecture/370"은 IBM의 상표이며, "Enterprise Systems Architecture/390", "Applicatin System/400", "AS/400"은 IBM의 등록 상표이다.)

게이트웨이 컴퓨터(46)는 또한 저장 장치(데이터 저장소(48)와 같은)에 결합될 수도 있다(49). 또한, 게이트웨이(46)는 하나 이상의 워크스테이션(10)에 직접 또는 간접으로 연결될 수도 있다.

당업자라면, 게이트웨이 컴퓨터(46)가 네트워크(42)로부터 지리적으로 멀리 떨어져서 위치될 수도 있으며, 마찬가지로, 워크스테이션(10)이 네트워크(42, 44)로부터 상당한 거리를 두고 위치할 수도 있음을 알 수 있을 것이다. 예를 들면, 네트워크(42)는 캘리포니아에 위치할 수도 있지만, 게이트웨이(46)는 텍사스에 위치할 수도 있으며, 하나 이상의 워크스테이션(10)이 뉴욕에 위치할 수도 있다. 워크스테이션(10)은 셀룰러 폰, 무선 주파수 네트워크, 위성 네트워크 등과 같은 다수의 다른 접속 매체를 통해, TCP/IP(Transmission Control Protocol/InternetProtocol)와 같은 네트워킹 프로토콜을 이용하여 무선 네트워크(42)에 접속될 수도 있다. 무선 네트워크(42)는 IP, X.25, 프레임 중계(Frame Relay), ISDN(Integrated Services Digital Network), PSTN(Public Switched Telephone Network) 등을 통해 TCP 또는 UDP(User Datagram Protocol)와 같은 네트워크 접속(50a)을 이용하여 게이트웨이(46)에 접속되는 것이 바람직하다. 또한 워크스테이션(10)은 다이얼 접속(50b 또는 50c)을 이용하여 게이트웨이(46)에 직접 접속될 수도 있다. 또한, 무선 네트워크(42) 및 네트워크(44)가 도 2에 도시된 것과 유사한 방식으로 하나 이상의 다른 네트워크(도시되지 않음)에 접속될 수도 있다.

본 발명을 실시하는 소프트웨어 프로그래밍 코드는, 통상적으로 CD-ROM 드라이브 또는 하드 드라이브와 같은 일부 유형의 장기간 저장 매체(30)로부터 서버(예를 들면, 서버(47))에 의해 액세스된다. 소프트웨어 프로그래밍 코드는 디스켓, 하드 드라이브, 또는 CD-ROM과 같은 데이터 처리 시스템과 함께 사용하기 위한 임의의 공지되어 있는 매체 상에서 실시될 수도 있다. 코드는 그러한 매체 상에 분산될 수도 있고, 몇몇 유형의 네트워크를 통해 하나의 컴퓨터 시스템의 저장 장치 또는 메모리로부터 다른 컴퓨터 시스템으로 그러한 다른 시스템의 사용자가 사용하도록 사용자들에게 분배될 수도 있다. 한편, 프로그래밍 코드는 메모리(28) 내에서 실시될 수도 있고, 버스(14)를 이용하여 마이크로프로세서(12)에 의해 액세스될 수도 있다. 메모리 내 또는 물리적 매체 상에 소프트웨어 프로그래밍 코드를 구현하는 상기 기법 및 방법 및/또는 네트워크를 통해 소프트웨어 코드를 분배하는 기법 및 방법은 공지되어 있으므로 더 이상 설명하지 않는다.

본 발명을 처리하는 파일을 요청하는 사용자는 유선 접속 또는 무선 접속을 이용하여 상기 컴퓨터를 서버에 접속할 수도 있다. 유선 접속은 케이블 전화선과 같은 물리적인 매체를 이용하는 것이며, 무선 접속은 위성 링크, 무선 주파수 파 및 자외선 파와 같은 매체를 이용한다. 전화선을 통하여 접속을 개설하는 컴퓨터 모뎀, 토큰 링 또는 이더넷과 같은 LAN 카드, 무선 접속을 개설하는 셀룰러 모뎀 등과 같은 다양한 매체와 함께 많은 접속 기법이 이용될 수 있다. 사용자의 컴퓨터는 랩탑, 핸드헬드 또는 이동 컴퓨터, 차량 탑재 장치, 데스크탑 컴퓨터, 메인프레임 컴퓨터 등 처리(및 잠재적으로 계산) 능력을 갖는 어떠한 유형의 컴퓨터 프로세서일 수도 있다. 이와 유사하게, 원격 서버는 처리 및 계산 능력을 갖는 임의의 수의 상이한 유형의 컴퓨터 중 어느 하나일 수 있다. 이들 기법들은 공지되어 있으며, 하드웨어 장치 및 이들 하드웨어를 사용할 수 있도록 하는 소프트웨어는 쉽게 얻을 수 있다. 이하에서, 사용자 컴퓨터는 "워크스테이션", "장치", 또는 "컴퓨터"로 지칭되며, 이들 용어들 또는 "서버"라는 용어는 전술한 임의의 유형의 계산 장치를 지칭한다.

바람직한 실시예에서, 본 발명은 하나 이상의 컴퓨터 소프트웨어 프로그램으로서 구현된다. 소프터웨어는 하나 이상의 모듈(또한 객체 지향 프로그래밍에서 코드 서브루틴 또는 "오브젝트"라고도 함)로서 구현될 수도 있다. 본 발명을 실시하는 논리는 SSL 프로토콜을 실시하는 프로그램의 코드와 결합될 수도 있고, 본원에 개시된 신규한 개념으로부터 벗어나지 않고 그러한 프로그램에 의해 야기되는 서비스를 제공하는 하나 이상의 개별적인 유틸리티 모듈로서 구현될 수도 있다.본 발명을 동작시키는 서버는 웹 서버로서 기능할 수도 있으며, 여기서 상기 웹 서버는 인터넷을 통해 접속된 클라이언트로부터의 요청에 응답하여 서비스를 제공한다. 한편, 상기 서버는, 클라이언트의 워크스테이션이 그 일부를 구성하는 통합된 인트라넷(intranet) 또는 엑스트라넷(extranet) 내에 있거나 또는 임의의 다른 네트워크 환경 내에 있을 수도 있다.

다음은 본 발명의 바람직한 실시예를 도 3 내지 5를 참조하여 보다 상세히 설명한다.

도 3은 바람직한 실시예에 따라 사전 처리되는 파일의 논리를 도시한 것이다. 상기 사전 처리(pre-processing)는, SSL 프로토콜과 함께 사용하기 위한 최소 프로세싱을 필요로 하는 파일을 준비하며, 그 파일은 암호화 엔진에서 얻을 수 있는 최적화된 프로세싱을 이용하기 위하여 하나 이상의 큰 블록 내의 암호화 엔진에 공급될 수 있다. 도 4는, 서버에서 파일에 대한 요청이 수신될 때 바람직하게 사용되는 논리를 도시한 것으로, 상기 파일은 도 3의 논리에 따라서 바람직하게 사전 처리되었다.

도 3의 사전 처리는 상기 파일에 대한 클라이언트 요청을 수신하기 전에 미리 수행되는 것이 바람직하다. 한편, 상기 사전 처리는 본 발명의 범주로부터 벗어나지 않고 그러한 요청을 수신하자마자 행해질 수도 있다. (이 경우, 도 3의 동작으로 인한 사전 처리된 파일은 영구 저장 장치에 저장되는 것이 바람직하며, 후속하는 클라이언트 요청을 이행하는데 있어서 효율성을 증가시키는데 사용될 수도 있다.) 간단히 말하면, 사전 처리 동작은 홀(hole) 또는 빈 공간을, 상기 파일의 SSL 프로토콜이 해시 값을 요구하는 장소에 삽입한다.

상기 사전 처리 동작은 도 3의 블록(300)에서 시작되며, 여기서 사전 처리될 파일이 얻어진다. 블록(310)에 나타낸 바와 같이, 선택적인 파일 헤더가 생성될 수도 있다. 상기 파일 헤더는, 서로에 대해 유사한 파일들을 구별하고 파일의 후속 암호화의 효율을 증가시키는데 사용될 수 있는 파일에 대한 정보를 포함한다. 상기 SSL 프로토콜은 많은 상이한 벌크 암호화 알고리즘 및 해싱 알고리즘의 이용을 위해 제공된다. 상이한 알고리즘들 사이에는 다수의 차이가 존재한다. 예를 들면, 벌크 RC4 암호에 대하여 두 개의 SSL 암호 쌍이 있는데, 이들 중 한 쌍은 MD5 해싱 알고리즘을 이용하고 다른 하나는 SHA-1 해싱 알고리즘을 이용한다. MD5 해시는 128비트를 사용하는 반면에, SHA-1 해시는 140 비트를 사용한다. 따라서, MD5 해시와 함께 사용하기 위해 사전 처리되는 파일은 SHA-1 해시와 함께 사용하기 위해 사전 처리되는 파일보다 더 작은 홀을 삽입할 것을 요구한다. 다른 차이는 또한, 전송에 사용된 다수의 레코드 크기인 특정 바운다리 상에서 끝나지 않는 파일의 끝에서 패딩이 요청되는지와 같이, 암호 쌍들과 알고리즘들 사이에 존재한다. 이들 유형의 차이 때문에, 하나의 포맷보다 더 많은 포맷으로 개별적인 파일들을 사전 처리하는 것이 바람직할 수도 있다. 각각의 저장된 버전의 헤더는 어느 알고리즘이 사전 처리된 파일과 함께 사용되는지를 식별하는데 사용될 수 있으며, 클라이언트와 서버 사이에서 어느 암호 쌍이 결정되는지에 기초하여 저장된 적절한 버전이 선택될 수 있다. (이것은 도 4의 블록(430)을 참조하여 후술한다) 상기 헤더는 또한, 홀을 삽입할 때 사용된 레코드 크기를 나타내는 것이 바람직하다(16K의디폴트 레코드 크기가 항상 사용되면, 상기 정보는 생략될 수도 있지만).

도 5a는 본 발명에 따라 파일을 처리하기 전에, 요청자에게 전송될 데이터 파일의 일례를 도시한 것이다. 상기 파일의 내용은 종래 기술에서와 같이 바이트열로서 저장된다. 도 5b는 도 3의 논리에 따라 파일을 처리한 후의 데이터 파일을 도시한 것이다. 선택적인 헤더는 510으로 도시되어 있으며, 사전 처리된 파일의 시작에 일단 저장된다. (상기 헤더는 클라이언트에게 전송되지 않고, 본 발명의 목적을 위한 서버 내에 내부적으로 사용된다.)

도 3에서, 상기 파일에 대한 전송된 메시지 세그먼트들에 사용되는 레코드 크기는 블록(320)에서 계산된다. 이것은 메시지 페이로드에 사용되는 데이터의 길이로부터 해시의 길이를 감산하는 연산을 포함한다. 예를 들면, 16K 바이트의 데이터가 각각의 메시지 세그먼트에서 전송되고, 128비트(16 바이트)의 해시가 전술한 MD5 해시에 사용되면, 블록(320)에서 계산된 레코드 크기는 (16K-16) 바이트이다. 그 다음에, 선택적인 헤더는, 사용될 때, 생성되는 출력 파일에 기록된다(블록(330)). 전술한 바와 같이, 헤더에 기록되는 정보는 파일을 준비하기 위한 암호화 알고리즘 및 해싱 알고리즘의 식별과, 사용되는 레코드 크기를 포함하는 것이 바람직하다. (이어서 도 4에 따라서 암호화를 위한 파일을 준비하여 특정 클라이언트에 전송할 때 다른 정보가 헤더에 삽입될 수도 있다. 이것에 대해서는 후술한다.)

블록(340)은 처리될 상기 파일의 끝에 도달했는지의 여부를 문의한다. 만약 끝에 도달했다면, 도 3의 처리는 종료된다. 그렇지 않으면, 상기 처리는, 입력 파일의 끝에 이를 때까지 블록(350, 360)의 논리를 통하여 반복된다. 블록(350)은 블록(320)에서 계산된 레코드 크기로 지정된 길이에 대하여, 입력 파일의 다음 바이트들을 획득하고, 상기 데이터의 끝에 빈 공간을 추가한다. 상기 빈 공간은 상기 파일을 준비하기 위한 해싱 알고리즘에 의해 요청된 것과 동일한 길이를 갖는다. 만약, 입력 파일 내에서 처리되는 나머지 바이트들의 수가 계산된 레코드 크기보다 작으면, 그리고 사용중인 암호 쌍이 이러한 유형의 패딩 쇼트 블록을 요구하면, 블록(350)은 빈 공간을 추가하기 전에 상기 요구된 양의 패딩을 추가한다. 그 다음에 블록(360)은 블록(350)에 의해 생성된 데이터 블록을 출력 파일에 기록하고, 그 후 제어권이 블록(340)으로 넘어간다.

도 5b의 출력 파일은 도 5a의 입력 파일이 도 3의 처리 동작에 의해 수정되는 방법을 도시한 것이다. 빈 공간(예를 들면, 요소(525, 535))은 각각의 데이터 블록(요소(520, 530))에 후속한다. 상기 빈 공간은 SSL 프로토콜이 각각의 데이터 블록의 해시를 요구하는 장소에 삽입된다. 본 예에서의 최종 데이터 블록(590) 다음에는 패딩 공간(592)이 후속하고, 그 다음에 마지막 빈 공간(595)이 뒤따른다.

도 4의 논리는 클라이언트로의 파일 전송 요청이 수신될 때 발생한다. 상기 요청이 수신되면(도 4a의 블록(400)), 상기 파일의 사전 처리된 버전이 사용가능한지를 판정하기 위한 테스트가 이루어진다. 만약 사용가능하지 않다면, 블록(420)에 도시된 바와 같이 파일은 종래 기술에 따라서 처리되어 전송될 수 있으며, 그 다음에, 상기 요청에 대한 도 4의 처리가 종료된다. (한편, 전술한 바와 같이 상기 파일의 사전 처리된 버전을 생성하기 위해 도 3의 논리가 실시될 수도 있다. 이 경우, 사전 처리 동작이 완료된 후 도 4의 처리가 블록(430)에서 계속되는 것이 바람직하다.) 블록(410)에서의 테스트가 긍정의 결과를 가지면, 블록(430)은 서버와 요청 클라이언트 사이에 사용하도록 결정된 암호화 알고리즘과 해싱 알고리즘을 준비하는 버전이 이용가능한지를 확인한다. 만약 이용가능하지 않다면, 상기 파일은 블록(420)에 도시된 바와 같이 종래 기술에 따라서 처리되어 전송될 수도 있고, 다른 실시예에서는 적절한 버전을 생성하기 위해 도 3의 논리가 실시될 수도 있으며, 그 다음에 도 4의 처리가 블록(440)에서 계속되는 것이 바람직하다.

요청된 파일의 사전 처리된 버전이 이용가능하면 제어는 블록(440)으로 넘어간다. 상기 파일은 SSL에 의해 요청된 해시 값들이 상기 요청 클라이언트에 파일을 전송하기 전에 삽입될 필요가 있는 빈 공간을 갖는다. 블록(450)은 전송을 위해 파일을 더 준비하는데 사용되는 암호화 키 및 해시 키를 획득한다. SSL 프로토콜에 따르면, 암호화 키 및 해시 키는 모두 SSL 접속에 대해 다시 한번 결정된다. 이것은 수신측을 알 때까지 해시 값의 계산을 지연시키는 것을 필요로 한다(이것은 실제 계산된 해시 값이 아니라 해시 값이 속하는 빈 공간을 갖는 사전 처리된 파일을 저장하도록 유도한다).

그 다음에 블록(460)(도 4b)은 처리되는 파일의 끝에 도달했는지를 검사한다. 만약 파일의 끝에 도달하지 않았다면, 블록(480, 495)은 출력 파일 처리를 반복해서 실시하고, 목적하는 수신측으로 그것을 전송하도록 준비한다. 블록(480)은 종래 기술의 SSL 핸드쉐이킹 프로토콜에 따라서)결정된 해싱 알고리즘을 이용하여, 파일 내 데이터의 그 다음 블록에 대한 해시를 계산한다. 그 다음에, 블록(495)은상기 계산된 해시를 상기 블록을 대해 예약된 빈 공간 대신에 삽입하고, 그 다음에 제어권이 블록(460)으로 반환된다. (바람직하게는, 사전 처리된 파일에 직접 재기록하는 대신에 데이터 버퍼 또는 임시 파일이 사용된다.)

전송될 전체 파일에 대한 해시 값이 계산되면, 제어권은 블록(470)으로 넘어간다. 블록(470)은 처리된 데이터 버퍼를 상기 클라이언트에게 전송하는데 사용되는 암호화 키와 함께 암호화 엔진으로 전송된다. 만약, 초기화 벡터가 암호화 엔진을 준비하는데 사용되면, 상기 벡터는 또한 이 때 전송되는 것이 바람직하다. (사용중에 특정 암호화 엔진에 적절한 크기의 데이터 블록을 이용하여)암호화 엔진이 데이터 버퍼를 암호화한 후, 상기 데이터는 사용되는 레코드 크기에 따라서 분할된다(예를 들면, SSL 프로토콜의 최대 16K 레코드 크기). 그러면 종래 기술의 SSL 메시지 및 기법을 이용하여, 블록(490)에 도시된 바와 같이 상기 파일의 다수의 세그먼트들이 다수의 송출 SSL 메시지의 페이로드로 삽입되어(메시지 페이로드당 하나의 세그먼트) 클라이언트로 전송된다. (상기 데이터의 실제 전송은 암호화 엔진으로부터 직접 수행되는 것이 바람직하다. 상기 동작은 도 4에 도시되어 있으며, 암호화된 데이터가 클라이언트에게 전송되기 전에 도 4의 동작들을 수행하는 동일 논리로 반환되어야 한다는 것을 암시하는 것은 아니다.) 그 다음에, 본 발명의 개선된 처리를 이용하여 클라이언트의 요청의 처리가 완료된다.

양호한 실시예의 선택적인 측면에서, 처리된 파일의 헤더는 블록(470)의 동작 이전에 부가적인 정보를 포함하여 갱신될 수도 있다. 상기 부가적인 정보는 암호화 엔진에 의해 사용되는 암호화 키와, 암호화 알고리즘을 준비하는데 사용되는초기화 벡터가 있는 경우에는 그 초기화 벡터를 포함한다. 이런 방법으로, 암호화 엔진에 필요한 모든 정보가 파일 헤더에 제공된다. 데이터 파일을 취하고 벌크 내에 유효 SSL 레코드들을 반환하도록 설계되는 하드웨어 장치 또는 소프트웨어 인터페이스와 함께 사용될 때 이 방법은 특히 유리하다.

다른 측면에서, 해시 키가 파일 헤더 내에 포함될 수도 있다. 상기 방법이 사용될 때, 블록(460, 480, 495)에 도시된 해싱 프로세스는 암호화 엔진에 파일을 송신하기 전에 수행되지 않고, 상기 파일을 수신할 때 암호화 엔진 그 자체에 의해 수행된다.

또 다른 측면에서, 해싱 프로세스가 암호화 엔진에 의해 수행될 때, 상기 해시 키는 (전술한)블록(470)의 처리 동안 암호화 엔진으로 전송된다.

부가적인 처리 효율은 암호화 엔진(또는 암호화 엔진들의 어레이)을 통하여 병렬로 암호화 프로세스를 파이프라이닝(pipelining)함으로서 실현할 수도 있으며, 따라서 암호화 프로세스는 클라이언트/서버 요청의 네트워크 지연을 오버랩하여 응답한다.

전술한 바와 같이, 본 발명은 SSL 또는 TLS와 같은 보안 프로토콜을 이용하여 요청자에게 전송되는 벌크 데이터의 대칭 암호화에 대한 개선된 기법을 제공하며, 그 결과 파일을 요청자에게 전송할 때 처리량을 증가시킬 수 있으며 지연을 감소시킬 수 있다. 16K보다 훨씬 더 많은 양을 암호화 엔진에 전송할 수 있는 방식으로 파일이 준비되어 저장된다. 공급되는 파일에 대한 간단한 수정과 함께 기존의 SSL 처리에 약간의 수정만이 요구된다. SSL 또는 TLS 프로토콜에 대한 수정은 요구되지 않는다. 상기 기법은 메시지 페이로드 크기의 변경 및 암호화 알고리즘 및 해싱 알고리즘의 변화(가변적인 해시 값 길이를 포함)와 함께 사용하는데 쉽게 응용될 수 있는 유연한 해법을 제공한다. 상기 기법은 단지 최소한의 프로세싱만 추가함으로서 SSL 트래픽의 처리량을 증가시킬 수 있다.

이상, 본 발명의 바람직한 실시예를 설명하였지만, 당업자가 본 발명의 기본 개념을 일단 파악하면, 상기 실시예에 부가적인 변경 및 수정이 이루어질 수도 있다. 본원에 개시된 기법은 처리될 보안 프로토콜(SSL, TLS)의 사전 정의된 특징에 기초하고 있다. 본원에 개시된 본 발명의 개념은, 본원에서 논의한 것과 동일한 의미를 갖는 새로운 프로토콜로의 완전한 대체를 포함하여 보안 프로토콜의 변화가 발생하면 그 보안 프로토콜의 변화에 적응될 수도 있다. 따라서, 첨부된 청구항들은 상기한 바람직한 실시예 및 본 발명의 정신 및 범주 내에서의 모든 그러한 변형들 및 수정들을 포함하도록 구성되어 있음을 주지하라.

Claims

삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
보안 프로토콜을 이용하여, 전송될 벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법에 있어서,

보안 전송될 파일을 결정하는 단계와,

상기 보안 전송 전에 행해질 대칭 암호화 프로세스를 최적화하도록 상기 파일을 사전 처리하는 단계를 포함하고,

상기 사전 처리하는 단계는,

상기 보안 전송 동안 상기 파일에 사용되는 데이터의 레코드 크기를 계산하는 단계 -상기 레코드 크기는 (전송 세그먼트 크기 - 해시 길이)임- 와,

상기 파일을 상기 레코드 크기의 레코드 열로 분할하는 단계 -상기 레코드들 중 마지막 레코드는 상기 레코드 크기보다 더 짧을 수도 있음- 와,

빈 공간을 상기 레코드 열의 각각에 부가하는 단계와,

상기 각각의 레코드 열 및 상기 부가된 빈 공간들을 출력 파일에 기록하는 단계를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 17 항에 있어서,

상기 빈 공간을 상기 레코드 열의 각각에 부가하는 단계가 상기 마지막 블록 상에서 행해지기 전에 상기 레코드들 중 상기 마지막 레코드에 패딩(padding) 블록을 부가하는 단계를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 17 항에 있어서,

헤더를 상기 출력 파일 내의 상기 레코드들 중 첫 번째 레코드의 선두에 부가하는(prepending) 단계를 더 포함하되, 상기 헤더는 (1) 상기 대칭 암호화 프로세스에 의해 사용되는 암호화 알고리즘의 식별부와, (2) 상기 대칭 암호화 프로세스의 동작 전에 상기 레코드들에 적용되는 해싱 알고리즘의 식별부와, (3) 상기 레코드 크기 중 하나 이상을 포함하는 정보를 저장하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 17 항에 있어서,

상기 파일에 대한 요청을 수신하는 단계와,

상기 요청을 수신하는 단계에 응답하여, 상기 출력 파일을 위치시키는 단계와,

상기 수신된 요청과 관련된 해시 키 및 암호화 키를 획득하는 단계와,

상기 획득된 해시 키를 이용하여, 상기 레코드 열 내의 각각의 레코드에 해싱 알고리즘을 적용하는 단계와,

상기 각각의 레코드에 대하여, 상기 부가된 빈 공간을 상기 해싱 알고리즘의 결과로 대체하여 해시 파일을 생성하는 단계와,

상기 획득된 암호화 키 및 상기 대칭 암호화 프로세스를 수행하기 위한 대칭 암호화 알고리즘을 이용하여 상기 해시 파일을 암호화하여 암호화된 파일을 생성하는 단계와,

상기 요청에 응답하여 상기 암호화된 파일을 전송하는 단계를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 20 항에 있어서,

헤더를 상기 출력 파일의 선두에 부가하는(prepending) 단계 -상기 헤더는 상기 대칭 암호화 알고리즘의 식별을 포함하는 정보를 저장함- 와,

상기 해시 키를 암호화하는 단계에 의해 사용되도록 상기 획득된 암호화 키를 상기 헤더에 부가하는 단계를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 20 항에 있어서,

헤더를 상기 출력 파일의 선두에 부가하는(prepending) 단계 -상기 헤더는 상기 해싱 알고리즘의 식별부를 포함하는 정보를 저장함- 와,

상기 해싱 알고리즘을 적용하는 단계에 의해 사용되도록 상기 획득된 해시 키를 상기 헤더에 부가하는 단계를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 21 항에 있어서,

상기 헤더는 상기 해시 파일을 암호화하는 단계에 의해 사용되는 초기화 벡터를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 22 항에 있어서,

상기 헤더는 상기 해시 파일을 암호화하는 단계에 의해 사용되는 초기화 벡터를 더 포함하는

벌크(bulk) 데이터의 대칭 암호화의 효율을 향상시키기 위한 방법.
제 17 항 내지 24 항 중 어느 한 항에 기재된 방법을 컴퓨터에서 구현하는 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체.
제 17 항 내지 제 24 항 중 어느 한 항에 따른 방법의 각 단계를 구현하는 각 수단들을 포함하는, 보안 프로토콜을 이용하여, 전송될 벌크 데이터의 대칭 암호화의 효율을 향상시키기 위한 시스템.