KR100430611B1

KR100430611B1 - 통신 프로토콜 보안 방법

Info

Publication number: KR100430611B1
Application number: KR10-2001-0050315A
Authority: KR
Inventors: 문정훈
Original assignee: 와이더덴닷컴 주식회사
Priority date: 2001-08-21
Filing date: 2001-08-21
Publication date: 2004-05-10
Also published as: KR20030017687A

Abstract

다운로드 되는 소프트웨어의 언어에 관계없이 사용이 가능한 통신 프로토콜 보안 방법을 개시한다. 상기 통신 프로토콜 보안 방법은, 암호화된 컨텐츠 다운로드 단계, 핸드 쉐이킹 단계 및 데이터 교신단계를 구비한다. 상기 암호화된 컨텐츠 다운로드 단계는, 다운로드 서버에서, 클라이언트가 입력하는 제1정보를 이용하여 바이너리 키 코드를 생성시켜 소정의 컨텐츠에 삽입시키고, 상기 바이너리 키 코드가 삽입된 컨텐츠를 상기 클라이언트에게 다운로드 한다. 상기 핸드 쉐이킹 단계는, 상기 클라이언트 및 어플리케이션 서버 사이의 핸드 쉐이킹(shaking)을 통하여, 어플리케이션 서버에서 클라이언트를 인증하여 네트워킹을 연결한다. 상기 데이터 교신단계는, 네트워킹이 연결된 후, 상기 클라이언트 및 상기 어플리케이션 서버 사이에서 데이터를 송수신한다. 본 발명에 따른 통신 프로토콜 보안 방법은, 특정언어에 구애받지 않으며 어플리케이션 제작 업체조차도 프로토콜을 충분히 파악하지 못하게 하며, 보안키를 복제 할 수 없게 하는 반면에, 여러 형태의 API에 적응 가능한 장점이 있다.

Description

통신 프로토콜 보안 방법{A securing method for communication protocol}

본 발명은 통신 프로토콜 보안에 관한 것으로, 특히 다운로드형 소프트웨어의 바이너리 패치를 이용한 통신 프로토콜 보안 방법에 관한 것이다.

상기 통신 프로토콜 보안방법은, 유무선 인터넷 상에서 소프트웨어를 다운로드(download)할 때, 프로토콜의 노출로 인한 서버데이터의 해킹을 방지하기 위한 시스템 및 관련된 툴(tool)에 관한 것으로서, 무선 단말기에서 동작하는 버추얼 머신(virtual machine)에서의 소프트웨어에 적용될 수 있다.

제한된 처리 용량을 가지는 무선 단말기 등의 클라이언트는 보안구조가 취약하다. 서버/클라이언트 구조가 간단한 경우의 프로토콜은 제3자에게 쉽게 분석될 수 있으며, 사용자가 상기 프로토콜을 쉽게 악용할 수 있다. 예를 들면, 게임 사용자가 상기 프로토콜을 입수하게 된다면 자신의 점수를 유리하게 고칠 수 있도록 조작할 수 있게 되며, 프로토콜을 입수한 사용자의 나쁜 의도에 따라 여러 가지의 해악이 따르게 된다.

상술한 폐해를 막기 위해서는, 다운로드형 소프트웨어의 프로토콜이 악의의 제3자에게 노출되지 않도록 하는 것이 최선이다. 종래에는 소프트웨어의 API(Application Program Interface) 알고리즘을 공개하지 않도록 하거나, 어플리케이션 서버의 서비스 구조를 공개하지 않도록 하였다. 그러나 이러한 방법은 네트웍을 기초한 무선 소프트웨어 시장의 활성화에 많은 제약을 가져오게 한다.

상기 API는, 운영 체제(operation system)의 기능을 이용자가 사용하기 위한 CALL 베이스의 함수 군으로서, 파일 관리, 메모리 관리, 태스크 관리, 디바이스 드라이버의 작성, 프로세스 간 통신 등 모든 형식의 서비스 인터페이스를 나타낸다. 각 메이커가 공통한 API를 공급함으로써 그것을 이용하는 이용자는 프로그램 개발을 효율적으로 할 수 있다.

그러나, GVM(General Virtual Machine) 등의 구조에서는, 소스 자체가 제3자에게 공개될 수밖에 없으므로, 일반적인 형태의 어플리케이션 서버를 사용할 경우 프로토콜의 노출에 따른 해킹의 위험이 급증하는 문제점이 있다.

따라서 본 발명이 이루고자 하는 기술적 과제는, 공개하는 소스의 언어에 관계없이 사용이 가능한 프로토콜 보안 방법을 제공하는 데 있다.

본 발명의 상세한 설명에서 사용되는 도면을 보다 충분히 이해하기 위하여, 각 도면의 간단한 설명이 제공된다.

도 1은 본 발명에 따른 통신 프로토콜 보안 방법을 단계별로 나눈 블록다이어그램이다.

도 2는 클라이언트와 서버간의 프로토콜 다이어그램이다.

도 3은 본 발명에 따른 통신 프로토콜 보안 방법에 대한 신호흐름도(flowchart)이다.

상기 기술적 과제를 달성하기 위한 본 발명의 실시 예에 따르면, 상기 프로토콜 보안 방법은, 암호화된 컨텐츠 다운로드 단계, 핸드 쉐이킹 단계 및 데이터 교신단계를 구비한다.

상기 암호화된 컨텐츠 다운로드 단계는, 다운로드 서버에서, 클라이언트가 입력하는 제1정보를 이용하여 바이너리 키 코드를 생성시켜 소정의 컨텐츠에 삽입시키고, 상기 바이너리 키 코드가 삽입된 컨텐츠를 상기 클라이언트에게 다운로드 한다. 상기 핸드 쉐이킹 단계는, 상기 클라이언트 및 어플리케이션 서버 사이의 핸드 쉐이킹(shaking)을 통하여, 어플리케이션 서버에서 클라이언트를 인증하여 네트워킹을 연결한다. 상기 데이터 교신단계는, 네트워킹이 연결된 후, 상기 클라이언트 및 상기 어플리케이션 서버 사이에서 데이터를 송수신한다.

이하, 첨부한 도면을 참조하여 본 발명의 바람직한 실시 예를 설명함으로써, 본 발명을 상세히 설명한다. 각 도면에 대하여, 동일한 참조부호는 동일한 부재임을 나타낸다.

도 1을 참조하면, 본 발명에 따른 프로토콜 보안 방법은, 바이너리(binary) 키 코드 생성 전 단계(Binary 패치 전), 바이너리 키 코드 적용단계(Binary 패치적용) 및 바이너리 키 코드적용 후 단계(Binary 패치 후)와 같이 3개의 단계로 크게 나눠 설명할 수 있다.

바이너리 키 코드 생성 전 단계는(110), 클라이언트(Client, 111)에게 다운로드될 소프트웨어의 API가 공개되어 있으며, 상기 소프트웨어에는 테스트용 키 코드(key code)가 전용으로 할당되어 있다. 클라이언트(111)와 서버(Server) 사이는 공개된 프로토콜을 이용하여 통신할 수 있다. 서버는 공개 키 코드만을 확인할 수 있으며, 테스트용 서비스를 제공할 수 있다(113).

바이너리 키 코드적용 단계(120)는, 다운로드 서버(121)에서, 클라이언트로부터 원본 바이너리 데이터(115)를 수신하여 단말 별 인증코드를 생성하고 API에서의 상기 테스트용 키 코드부분이 상기 바이너리 키 코드(인증코드)로 치환된 후, 사용자 단말에 소프트웨어가 다운로드된다.

바이너리 키 코드 적용 후 단계(130)는, 인증코드를 사용하여 프로토콜을 암호화한다. 이 때, 클라이언트는 상기 바이너리 키 코드를 이용하여 암호화된 변경 바이너리 데이터(125)를 수신하게 된다. 상기 바이너리 키 코드는 클라이언트에 따라 다르다. 서버의 경우, 인증키를 확인, 프로토콜의 암호화 및 사용자와 트랜젝션의 기록을 한다(133). 또한 서버와 클라이언트 사이에는 보안 프로토콜을 이용한 데이터의 송수신이 이루어지며, 이러한 암호화된 데이터의 송수신이 가능하도록 하기 위해 서버에서는 동작 모드의 변경이 일어난다.

도 2는 클라이언트와 서버간의 프로토콜 다이어그램이다.

도 2를 참조하면, 클라이언트가 Mobile Id Number(MIN) 및 소정의정보(SEED)를 서버에 송신(201)하는 것으로 프로토콜이 시작됨을 알 수 있다. 여기서, 정보(SEED)는 상기 보안 프로토콜이 게임 소프트웨어에 사용되는 경우에는 Game ID(GID)를 의미하며, 기타 사용되는 영역에 따라 정해지는 정보를 의미한다.

서버는 클라이언트로부터 상기 정보를 수신하여 바이너리 키 코드(K)를 생성시켜 클라이언트에 송신한다(203). 이 때, 해쉬(HASH) 함수가 사용될 수 있다. 상기 해쉬 함수로는 MD5, SHA-1 등의 함수들이 가장 널리 사용된다. 상기 해쉬 함수는 특정한 입력으로부터 충분한 연산을 통하여 확률적으로 유일한(unique) 결과물을 생성하는 함수이다. 상기 해쉬 함수는, 역함수가 존재하지 않으므로, 상기 해쉬 함수에 적용한 결과로 생성된 문자열로부터 원본을 추출해 내는 것은 매우 어렵다.

상기 바이너리 키 코드를 수신한 클라이언트는, 상기 바이너리 키 코드 및 요구사항을 인코드하여 서버에 송신(205)하고, 서버는 상기 클라이언트에 의하여 인코드 된 데이터를 수신하여 디코드하여 인식한 후 상기 바이너리 키 코드 및 응신 사항을 인코드하여 클라이언트에 송신(207)한다. 클라이언트는 서버로부터 수신한 인코드된 데이터를 디코드하여 인식함으로써, 서버 및 클라이언트 사이의 암호화된 통신이 가능하여 진다.

도 3을 참조하면, 본 발명에 따른 통신 프로토콜 보안 방법은, 클라이언트가 컨텐츠를 다운로드받는 단계(310), 클라이언트가 컨텐츠를 구동시켜 네트웍을 연결하는 단계(320) 및 네트웍이 연결된 후의 교신단계(330)로 구분된다.

다운로드받는 단계(310)는, 클라이언트 리퀘스트단계(311), 다운로드 서버의 바이너리 키 코드 생성단계(312), 패치 응용단계(313) 및 클라이언트에게 다운로드 시키는 단계(314)를 구비한다.

클라이언트 리퀘스트 단계(311)에서, 사용자는 MIN 및 Contents ID(CID)를 입력하여야 한다. 다운로드 서버의 바이너리 키 코드 생성단계(312)는, 상기 MIN, CID를 제1해쉬 함수(Hash1)의 변수로 이용하여 바이너리 키 코드(KeyStr)를 생성시킨다. 상기 제1해쉬 함수(Hash1)의 변수로는 상기 MIN 및 CID 외에 내부의 소정의 정보(Secretkey)를 더 추가 할 수 있다. 상기 정보(Secretkey)는 다운로드 서버 및 어플리케이션 서버에서만 공유한다.

네트웍 연결단계(320)는, 클라이언트 핸드 쉐이트 단계(321), 어플리케이션 서버에서의 인증단계(322), 어플리케이션 핸드 쉐이크 단계(323) 및 클라이언트의 디코딩 단계(324)를 구비한다.

클라이언트 핸드 쉐이크 단계(321)는, 클라이언트가 상기 바이너리 키 코드(Keystr)를 변수로 한 제2해쉬 함수(Hash2)의 결과 데이터, MIN 및 CID를 어플리케이션 서버에 송신하다. 인증단계(322)는, 어플리케이션 서버에서 바이너리 키 코드를 자체적으로 생성하여 클라이언트로부터 수신한 데이터와 비교한 후 클라이언트를 인증한다. 어플리케이션 핸드 쉐이크 단계(323)는, MIN, CID 및 소정의 코드(OTP)를 인코드하여 클라이언트에 송신한다. 클라이언트 디코딩 단계(324)는, 상기 어플리케이션 서버로부터의 인코딩 된 데이터를 디코딩하여 정보를 상기 코드(OTP)를 판독한다. 여기서 OTP(One Time Pad)는, 세션의 무결성을 보완하기 위하여 사용된 소정의 길이를 가지는 바이너리 코드이다.

클라이언트에게 다운로드 시키는 단계(314)는, 클라이언트 및 서버는 모두 송신 및 수신을 수행하므로, 대표적으로 수신 및 송신을 설명한다.

송신의 경우(331), 메시지 및 바이너리 키 코드(keystr)를 인코드한 데이터 및 메시지를 제2해쉬 함수에 적용시킨 데이터를 송신한다. 수신의 경우(332), 수신된 데이터를 디코딩하고 제2해쉬 함수에 적용시킨 데이터와 비교하여 판단한다.

여기서, 인코드 및 디코드는 일반 블록 사이퍼(block cipher) 또는 스트림 사이퍼(stream cipher) 함수이다.

본 발명에 따른 프로토콜 보안 방법의 주된 아이디어는 다음과 같다.

다운로드 서버는 사용자에게 소프트웨어를 다운로드하기 전에 특정 컨텐츠의 ID, 사용자 ID 및 특정한 암호를 조합하여 생성시킨 바이너리 키 코드를 상기 공개되는 소스에 삽입하는데 있다. 또한, 다운받은 소프트웨어를 사용자가 실행시킬 때, 상기 바이너리 키 코드를 사용하여 서버와 통신하는 프로토콜을 암호화한 후, 특정 어플리케이션 및 사용자 ID 별로 암호화된 트랜젝션을 만들어 낸다.

서버에서는 소프트웨어 ID 및 사용자 ID와 함께 자신이 가지고 있는 암호를 사용하여 트랜젝션을 복호화한다. 불규칙한 트랜젝션이 발생하였을 경우, 소프트웨어 ID 및 사용자 ID를 기준으로 피해를 최소화 할 수 있게 된다. 특정 사용자는 상기와 같은 코드 때문에 다른 사용자의 키를 알아낼 수 없으며, 따라서 다른 사용자의 기록을 조작할 수 없게 된다.

여기서 트랜젝션이란, 데이터베이스의 데이터가 부정확하게 업데이트 되지않도록 배타적인 제어가 필요한데, 배타적인 제어에 의해 업데이트 되는 일괄처리가 어긋남이 없이 실행되도록 관리하는 것을 말한다.

본 발명에 따른 통신 프로토콜 보안 방법에서 사용하는 프로토콜 알고리즘에 대하여 설명한다.

첫 째, 제1해쉬 알고리즘에 대하여 설명한다.

제1해쉬 함수 또는 제1해쉬 알고리즘은, 클라이언트에서는 실행될 필요가 없으며, 단지 한 번의 바이너리 패치용 코드를 만들기 위하여 다운로드 서버에서 사용되거나, 아니면 메시지를 초기화 할 때 사용한다. 이 때의 입력데이터의 길이는 어떤 길이든 상관없으며, 단지 출력데이터가 예측 불가능할 정도로 복잡한 알고리즘이면 충분하다. 따라서, RFC 1321에서 명시한 MD5 알고리즘을 약간 변형하여 사용할 수 있다.

클라이언트 및 게임 별로 특정한 문자열이 지정되어야 하므로, 사용자의 user agent 필드를 활용하여 다음과 같은 문자열을 MD5의 입력으로 사용한다.

CARRIER_IC(3 bytes)|MIN_NUMBER(11 bytes)|GID(5 bytes, zero padded)|KEY_STRING(predefined)

이 때, KEY_STRING은 충분한 길이의 암호이면 되며, 상기 암호는 다운로드 서버 및 게임포탈 서버에서 공유되어야 하므로 하드코드 되던가 아니면 특정한 곳에 암호화되어 저장되어 있으면 된다.

따라서, SK사의 011-123-4567을 사용하는 사용자의 경우, 10001 번 게임을 다운로드 할 때, MD5의 입력은 다음과 같다.

SKT| 01112345670|10001|SOMESECRETKEY

이를 사용하면 나오는 MD5 결과는 128 비트(16바이트) 스트링이며, 앞 쪽 8 바이트만을 키로 사용하는 것으로 설명한다.

MD5를 이용하여 key string을 만들어 내는 루틴의 예제는 다음과 같다. FreeBSD의 경우 아래와 같은 프로그램을 이용한다.

#include <stdio.h>

#include <sys/types.h>

#include <md5.h> // Compile with - lmd option

const char *str = "SKT|01112345670|100001|THESECRETKEY"

int

main()

{

MD5_CTX buf;

MD5Init( buf);

MD5Update($buf, str, str|len(str));

print|("String = % sWn", str);

print|("%sWn", MD5End($buf, 0));

}

둘 째, 제2해쉬 알고리즘에 대하여 설명한다.

제2해쉬 알고리즘은 문장의 완결성을 검사하고자 사용되는 알고리즘이므로,자체가 복잡할 필요는 없고 다음과 같이 간단하게 구현될 수 있다.

Function hash2(message M) returns short int

unsigned short

hash2(char * msg) {

unsigned short h2 = 21591; // □WT □문자열에 대한 숫자 표현. Initial 값

int |;

for(i=0; I < strilen(msg); I++) { // 271 is a prime number

* = msg[i];

h2 = ((h2 ^ (x*x)) % 271) + (~h2 ^ (x << ((i+8)%16)));

h2 = (h2 << 3) | (h2 >> 13);

}

return h2;

}

상기 제2해쉬 함수는 버추얼 머신에서 빠른 속도로 동작하여야 하므로, 최대한의 간단한 연산만을 사용하도록 한다.

세 째, One Time Pad는 세션의 보안성을 추구하기 위하여 생성되는 1 바이트 랜덤코드로써, '매우 랜덤한' 숫자 1 바이트를 사용하면 된다. URL로 전달되는 경우는 아스키코드 0으로 시작하는 것으로 하며, 그렇지 않은 경우는 핸드 쉐이크 당시에 'urandom' 등을 이용하여 생성하는 것으로 한다.

네 째, 스트림 사이퍼(stream cipher)는 상기 제1해쉬 알고리즘의 결과 및 상기 OTP를 이용하여 원문을 암호화한다. 암호화하는 방법을 코드로 간단히 표현하면 다음과 같다.

char *KeyText; // Result of Hash1 Function (Binary Patched)

char *msg; // Message to be crypted

char *target; // target message buffer

char otp; // One Time Pad

int |;

target = (char *) mal|loc(strlen(msg)+3); // Reserve 2 chechsum bytes

for( I = 0; I < strlen(msg); I++) {

target[i] = (msg[i] ^ KeyText[i % strlen(KeyText)]) + (otp++);

}

// Append Hash2 Function at the end of target here.

return target // Encrypt Done

복호화 하는 방법은 다음과 같다.

char *KeyText; // Calculate with MIN/GID

char *msg;

char *target;

char otp; // One Time Pad

char ch;

int I;

// Check validity of Hash2 Function first.

msg = (char *) mal|loc(strlen(target)); // □Enough buffer □

for( I = 0; I < strlen(target); I++) {

msg[i] = (target[i] - (otp++)) ^ KeyText[i % strlen(KeyText)]);

}

return msg

다섯 째, 패킷 전송순서에 대하여 설명한다.

암호화 트랜젝션을 위하여 기본적으로 MIN, GID를 알 수 있어야 한다. VM(Virtual Machine) 어플리케이션과 직접 통신하는 경우는 VM 어플리케이션에서 핸드 쉐이크 과정을 거침으로 이 정보를 교환하게 된다. 먼저 핸드 쉐이크 과정의 경우를 표시하면 다음과 같다.

Client Request; ' Hello 'MIN, GID, Hash(hash2, key)

클라이언트는 핸드쉐이크를 하는 프로토콜 코드와 MIN, GID 및 Key에 대한 Hash2 코드를 보낸다.

Server Response; Cipher( 'Hello' , MIN, GID, OTP), Hash1(...)

서버의 경우 받은 리퀘스트를 Stream Cipher를 이용하여 OTP를 보낸다. 클라이언트의 경우, Initial OTP는 ASCII 코드 0으로 하며, 서버로부터 OTP를 받은 이후는, 그 값으로 리셋한다.

통신과정은,

핸드 쉐이크 이 후, 모든 패킷 통신을 Stream Cipher를 이용하여 암호화한다. 이 때, OTP는 패킷 단위로 기존 값으로 리셋하여 사용하는 것이 바람직하다. 이는, URL을 이용한 API등에서 Connection-less Transaction과의 통일성이 용이할 것으로 판단되기 때문이다.

본 발명은 도면에 도시된 일 실시 예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

상술한 바와 같이, 본 발명에 따른 통신 프로토콜 보안 방법은, 특정언어에 구애받지 않으며 어플리케이션 제작 업체조차도 프로토콜을 충분히 파악하지 못하게 하며, 보안키를 복제 할 수 없게 하는 반면에, 여러 형태의 API에 적응 가능한 장점이 있다.

Claims

다운로드 서버에서, 클라이언트가 입력하는 제1정보를 이용하여 바이너리 키 코드를 생성시켜 소정의 컨텐츠에 삽입시키고, 상기 바이너리 키 코드가 삽입된 컨텐츠를 상기 클라이언트에게 다운로드 하는 암호화된 컨텐츠 다운로드 단계;

상기 클라이언트 및 어플리케이션 서버 사이의 핸드 쉐이킹(shaking)을 통하여, 어플리케이션 서버에서 클라이언트를 인증하여 네트워킹을 연결하는 핸드 쉐이킹 단계; 및

네트워킹이 연결된 후, 상기 클라이언트 및 상기 어플리케이션 서버 사이에서 데이터를 송수신하는 데이터 교신단계를 구비하는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제1항에 있어서, 상기 암호화된 컨텐츠 다운로드 단계는,

상기 클라이언트가 제1정보 즉, Mobile Id Number(MIN) 및 Contents ID(CID)를 다운로드 서버에 전달하는 단계;

상기 다운로드 서버가, 제1해쉬 함수에 상기 제1정보를 변수로 적용시켜 바이너리 키 코드를 생성하여 컨텐츠에 삽입하는 단계;

상기 바이너리 키 코드가 삽입된 컨텐츠를 클라이언트에게 다운로드 하는 단계를 구비하는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제2항에 있어서, 상기 제1해쉬 함수는,

상기 제1정보뿐만 아니라 상기 다운로드 서버 및 상기 어플리케이션 서버에서만 공유하는 소정의 비밀키(secret key)를 더 이용하여 상기 바이너리 키 코드를 생성하는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제1항에 있어서, 상기 핸드 쉐이킹 단계는,

상기 클라이언트가, 제2해쉬 함수에 상기 바이너리 키 코드를 변수로 적용시켜 출력된 데이터, 상기 MIN 및 상기 CID를 상기 어플리케이션 서버에 전달하는 단계;

상기 어플리케이션 서버에서, 상기 MIN 및 상기 CID를 이용하여 바이너리 키 코드를 생성하고, 상기 제2해쉬 함수의 출력데이터와 상기 바이너리 키 코드를 비교하는 단계;

상기 어플리케이션 서버에서, 상기 MIN, 상기 CID, 소정의 랜덤 코드를 가지는 OTP (One-Time-Pad) 및 상기 바이너리 키 코드를 인코드한 데이터 및 제2해쉬 함수에 상기 MIN, 상기 CID 및 상기 OTP를 변수로 적용시킨 결과를 상기 클라이언트에게 전달하는 단계; 및

상기 클라이언트에서, 상기 인코드된 데이터를 디코드하고 상기 OTP를 회수하는 단계를 구비하는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제1항에 있어서, 상기 데이터 교신 단계는,

송신측에서, 메시지와 상기 바이너리 키 코드를 인코딩한 데이터 및 상기 제2해쉬 함수에 상기 메시지를 변수로 적용시킨 결과데이터를 송신하는 단계; 및

수신측에서, 상기 인코딩 데이터를 수신하여 디코딩하고, 상기 제2해쉬 함수에 상기 메시지를 변수로 적용시킨 결과데이터와 상기 디코딩 데이터를 비교하는단계를 구비하는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제4항에 있어서, 상기 OTP는,

1 바이트(byte)의 데이터 길이를 가지며,

URL로 전달되는 경우는 아스키코드 0(zero)으로 시작되는 것을 특징으로 하는 통신 프로토콜 보안 방법.
제2항 또는 제3항에 있어서, 상기 제1해쉬 함수는,

바이너리 키 코드를 만들기 위하여 다운로드 서버에서 사용되거나 메시지를 초기화시킬 때, 사용될 수 있으며, 입력 데이터의 길이에 무관하게 동작하고 출력 데이터가 예측 불가능한 알고리즘 인 것을 특징으로 하는 통신 프로토콜 보안 방법.
제4항에 있어서, 상기 제2해쉬 함수는,

문장의 완결성을 검사하고자 사용되는 것을 특징으로 하는 통신 프로토콜 보안 방법.