KR101055861B1 - 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램 - Google Patents

통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램 Download PDF

Info

Publication number
KR101055861B1
KR101055861B1 KR1020057024375A KR20057024375A KR101055861B1 KR 101055861 B1 KR101055861 B1 KR 101055861B1 KR 1020057024375 A KR1020057024375 A KR 1020057024375A KR 20057024375 A KR20057024375 A KR 20057024375A KR 101055861 B1 KR101055861 B1 KR 101055861B1
Authority
KR
South Korea
Prior art keywords
communication
protocol
tcp
encryption
integrity authentication
Prior art date
Application number
KR1020057024375A
Other languages
English (en)
Other versions
KR20060059908A (ko
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 케이코 오가와
Publication of KR20060059908A publication Critical patent/KR20060059908A/ko
Application granted granted Critical
Publication of KR101055861B1 publication Critical patent/KR101055861B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0485—Networking architectures for enhanced packet encryption processing, e.g. offloading of IPsec packet processing or efficient security association look-up
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Abstract

상위 애플리케이션의 프로그램을 변경하지 않고, 데이터의 누설, 개찬(改竄), 위장(spoofing), 진입, 공격의 방지기능을 강화하기 위해, 송신 측과 수신 측에서 암호화ㆍ복호화 논리 회로의 결정을 실시하고, 이것을 트랜스포트층에 존재하는 TCP 또는 UDP에 해당하는 프로토콜의 페이로드에 적용하는 새로운 암호화시스템TCP(2)을 제공한다. 이 TCP(2)를 채용함으로써, 종래의 IPsec 또는 SSL이 가지는 다양한 제약을 해소하고, 상위 애플리케이션의 제약을 받지 않는 동시에 IP층에서의 호환성이 있는 암호처리통신이 실현된다.

Description

통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기 위한 통신 프로그램{Communication system, communication device, communication method, and communication program for realizing the same}
본 발명은, 통신에 있어서의 보안 시스템, 특히, 인터넷상에서의 데이터의 「누설」 및 「개찬」 또 「위장」, 「진입」 내지 「공격」을 막기 위한 통신 시스템, 특히, 통신 시스템을 실현하는 프로토콜 스택과, 통신 장치, 통신 방법 및 그것을 실현하기 위한 컴퓨터 프로그램에 관한 것이다.
근래, 인터넷을 이용한 통신은, Windows PC만 있으면, 그것을 네트워크에 접속하는 것만으로, 누구라도 네트워크상의 컴퓨터에 액세스할 수 있기 때문에, 사회 속에서 급속히 보급 확대되고 있다. 한편, 이 인터넷 통신의 보급 확대에 수반하여, 해커(backer)나 크래커(Cracker)가 타인의 컴퓨터 시스템에 침입하여, 소프트웨어나 데이터를 훔쳐 보거나 개찬이나 파괴를 실시하거나 한다고 하는 사회 문제도 커지고 있다.
구체적인 부정 방해의 케이스로서는, 우선 첫 번째로, 중심적인 시스템을 사용할 수 없게 되도록, 네트워크로부터 대량의 메시지를 보내서 컴퓨터 시스템의 운용을 방해하는 시스템 방해가 있다. 이 방해에 의해서 호스트가 과부하가 되면 시스템이 다운되어 버리는 일도 일어날 수 있다.
또, 호스트의 패스워드를 입수하고, 기밀 정보를 훔치거나 정보의 개찬이나 파괴를 실시하거나 하는 「부정 액세스로 위장」의 부정 방해가 있다. 이 방해에는 컴퓨터가 보유하는 정보를 마음대로 고쳐 쓰고, 사람을 모함하는 비열한 것도 있다. 또, 특정 PC에 잠입하여, 메일 주소나 패스워드 등 개인의 기밀 데이터를 착취하는 스파이웨어라고 하는 부정행위도 발생하고 있다. 이와 같이 네트워크에 접속한 컴퓨터가 가지는 데이터베이스의 내용을 부정하게 훔쳐 보는, 이른바 도청 행위도 빈번히 행해지고 있을 가능성도 부정할 수 없다.
또, 사이트 혹은 서버의 운영원에서, 의도적으로 개인정보를 훔친다고 하는 행위나, 사내에 잠복하는 스파이 등에 의한 사이버 테러(Cyber terrorism)라고 하는 위기도 전혀 없다고는 할 수 없는 상황이다.
게다가, 타인의 컴퓨터에 컴퓨터 장해를 가져오는 프로그램인 「바이러스」를 보낸다고 하는 부정 방해가 최근 많아지고 있다. 이 이송된 바이러스에, 메일 등을 자택에서 사용한 PC가 감염되고, 그것을 사내(社內)에 접속한 순간에 사내의 PC 전체가 감염되거나, 바이러스가 컴퓨터 안의 파일을 파괴시키거나, 또는, 네트워크 전체를 다운시키거나 한다고 하는 문제도 발생하고 있다.
이 때문에, 종래의 TCP／IP(Transmission Control Protocol／Internet Protocol)나 UDP(User Datagram Protocol)를 이용한 인터넷상에서의 통신에 있어서, 데이터의 「누설」 「개찬」 등을 막는 기능으로서 IPsec(아이피섹크：Security Architecture for Internet Protocol)나 SSL(Secure Socket Layer)라고 하는 암호화 통신이 이용되고 있다. 일반적으로, 암호화 통신에는, 공통열쇠(비밀열쇠라고도 한다) 암호방식과 공개열쇠 암호방식이 있지만, IPsec는 공통열쇠 암호방식을 이용한 것이 많다. 공통열쇠 암호방식이 공개열쇠 암호방식보다 암호화ㆍ복호화의 속도가 빠르다고 하는 특징이 있다. 이 IPsec에 이용되는 공통열쇠 암호방식은, 암호화와 복호화를 동일한 열쇠로 실시하는 방식이며, 열쇠의 생성은 송신측 또는 수신측의 어느 쪽에서 생성해도 좋지만, 수신측과 송신측에서 공통열쇠를 사용하기 때문에, 열쇠의 교환시에 내용이 외부에 새지 않게 세심한 주의를 기울이지 않으면 안 된다.
공통열쇠 암호방식에서 사용되는 알고리즘은 DES(Data Encryption Standard：미국 IBM사가 개발한 공통열쇠(비밀열쇠) 암호화 알고리즘)가 대표적이다. IPsec도 이 DES를 암호 알고리즘의 하나로 채용하고 있다. IPsec는, IET F(Internet Engineer Task Force)가 표준화를 진행시킨 것이며, 이 특징은, 단지 특정 애플리케이션만을 암호화하는 것이 아니라, 호스트로부터 송신되는 모든 통신을 IP레벨로 암호화하는 것에 있다. 이것에 의해 사용자는 애플리케이션을 의식하지 않고 안전한 통신을 가능하게 할 수 있다. 또, IPsec는, 장래에도 사용할 수 있도록, 그 자체의 구조를 바꾸지 않고 사용하는 암호 알고리즘을 변경하는 것을 가능하게 하고 있다.
IPsec에서 이용되는 공통 암호열쇠로서는, SPI(Security Pointer Index)라고 불리는 32비트 부합이 이용되며, 열쇠 교환 프로토콜로서는, IKE(Internet Key Exchange)가 이용된다. 게다가, IPsec에는, 완전성 인증을 위한 프로토콜 AH(Antbentication Header)가 준비되어 있다.
또, SSL은, 미 네트스케이프사(현재 AOL에 흡수 합병)가 개발한 보안 기능 첨부 HTTP 프로토콜이며, 이것을 이용함으로써 클라이언트와 서버가 네트워크상에서 서로를 인증할 수 있게 되며, 크레디트 카드정보 등의 기밀성이 높은 정보를 암호화하여 주고 받는 것이 가능해진다. 이것에 의해, 데이터의 도청, 재송(再送) 공격(네트워크상에 떠도는 데이터를 도청하여 몇 번이나 반복하여 보내 오는 공격), 위장(본인인척 하여 통신한다), 데이터의 개찬 등을 방지할 수 있다.
도 25는 종래의 IPsec를 이용한 암호화 통신을 실시하는 경우의 프로토콜 스택의 예를 나타내고, 도 26은 종래의 SSL을 이용한 암호화 통신을 실시하는 경우의 프로토콜 스택의 예를 나타내고 있다.
OSI참조 모델은, 최하층(제 1층)이 물리층, 제 2층이 데이터링크층, 제 3층이 네트워크층, 제 4층이 트랜스포트층, 제　5층이 세션층, 제 6층이 프레젠테이션층, 최상층(제 7층)이 애플리케이션층으로 되어 있다. 이 OSI참조 모델에 있어서의 7 계층은, 통신 기능을 7 단계로 나눈 것이며, 그 계층마다 표준적인 기능 모듈을 정하고 있다. 도 25에서는, 제 5층의 세션층까지가 나타나고 있다.
프로토콜 스택이란, 네트워크의 각 계층에 있어서의 기능을 실현하기 위한 프로토콜을 선택하고, 계층형으로 쌓아 올린 소프트웨어군이다.
우선, OSI참조 모델에 대해서 개략을 설명하면, 제 1층의 물리층은, 신호선의 물리적인 상기 특성이나 부호의 변조 방법 등을 규정한 층이다. 단지, 이 층만이 단독으로 정의(定義)ㆍ실장(實裝)되는 경우는 적고, 통상은, 제 2층의 데이터 링크층과 함께, 예를 들어 이더넷(ethernet)의 규격, 등으로서 정의된다.
제 2층의 데이터 링크층은, 데이터의 패킷화나 물리적인 노드 주소, 패킷의 송수신 방법 등을 규정하는 층이다. 이 층은, 물리적인 통신 매체를 통하여, 2개의 노드간에 패킷을 교환하기 위한 프로토콜을 규정하는 것이며, 각 노드에 대해서, 어떤 주소를 붙이고, 그 주소에 의거하여 패킷의 송신처를 특정하고, 패킷을 통신 매체상에 송신한다. 통신 매체로서는, 동(銅)배선이나 무선, 광섬유 등, 다양한 것이 있다. 또, 접속 형태(토폴로지)도, 1대 1의 대향 접속뿐만 아니고, 버스형이나 스타형, 링형 등 많은 종류가 있다. 통신 매체상에 송신된 패킷은, 수신측 노드에 도착한 시점에서 그 노드에 받아들여지며, 한층 더 상위의 프로토콜층으로 전해진다.
물리층과 데이터 링크층에 걸쳐서 배치되는 NIC(Network Interface Card)Driver는, PC나 프린터 등을 구내 네트워크(LAN)에 연결하기 위한 확장 보드이다. 단지 네트워크 카드라고 하는 경우는 이더넷(ethernet)에 연결하는 경우가 많다.
이 NIC Driver에 의해, 데이터를 송신하고 싶은 노드(기기)가 케이블의 빈 상황을 감시하여, 케이블이 비면 송신을 개시하도록 하고 있다. 이때, 만약 복수의 노드가 동시에 송신을 개시하면 케이블 내에서 데이터가 충돌하여 파괴되므로, 양자(兩者)는 송신을 중지하고, 랜덤인 시간을 기다려 송신을 재개하는 것이다. 이것에 의해서 한 개의 케이블을 복수의 노드가 공유하여 서로 통신할 수 있다.
제 3층의 네트워크층은, 임의의 2개의 노드간에서의 통신 방법을 규정하는 층이다. TCP／IP로 말하면 IP층에 상당한다. 데이터 링크층에서는, 동일 네트워크 매체상의 노드간에서의 통신을 실시할 수 있지만, 그 기능을 사용하여, 네트워크상에 존재하는 임의의 2개의 노드간에서, 루팅(routing)을 실시하면서 통신하는 것이 이 네트워크층의 역할이다. 여기서, 루팅이란 TCP／IP네트워크에 있어서 목적의 호스트까지 패킷을 송신할 경우에, 최적인 경로를 선택하여 송신하는 것을 말한다. 예를 들면, 이더넷(ethernet)에서는, 동일 세그먼트(segment)상의 노드끼리밖에 서로 통신할 수 없지만, 네트워크층에서는, 2개의 이더넷 세그먼트간에 패킷을 루팅함으로써 통신을 실시한다. 또, 전화 회선을 통해서 컴퓨터를 네트워크(이더넷이더넷하는 다이얼 업 PPP(Point to Point Protocol) 회선으로의 루팅, 또, 광섬유를 사용한 전용선으로의 루팅 등, 물리적인 네트워크 매체에 의하지 않고 패킷을 루팅할 수 있다. 이 목적을 위해, 통상은, 물리 매체에 의존하지 않는 주소(TCP／IP라면, IP 주소)를 각 노드에 할당하여, 이것에 의거하여 루팅을 실시하고 있다. IPsec는, 이 네트워크층에서, 즉 IP레벨에서 호스트로부터 송신되는 모든 통신을 암호화하므로, 사용자는 애플리케이션을 의식하지 않고 안전한 통신을 가능하게 할 수 있는 것이다.
제 4층의 트랜스포트층은, 각 노드상에서 실행되고 있는 2개의 프로세스간에서, 에러가 없는, 가상적인 통신로를 실현하기 위한 프로토콜층이다. TCP／IP로 말하면 TCP층에 상당한다. 네트워크층에서는, 2개의 노드간에서의 통신을 실시하는 기능을 제공하고 있지만, 이것을 사용하여, 2개의 프로세스(애플리케이션) 간 에서, 에러가 없는, 가상적인 통신로를 제공하는 것이 이 층의 역할이다. 즉, 네트워크층에서는 데이터를 보낼 수 있지만, 그 데이터가 확실히 상대에게 닿는다고 하는 보증은 없다. 또, 송신한 순서대로 올바르게 데이터가 닿는다고 하는 보증도 없다. 그래서, 애플리케이션에 있어서 사용하기 쉽게 하기 위해서, 에러가 없는 통신로를 제공하는 것이 이 층이다. 필요하면 데이터의 재발송ㆍ회복 처리 등을 실시한다.
이 트랜스포트층에는 TCP 외에 UDP도 배치되지만, 이 UDP와 TCP의 차이는, TCP가 데이터의 보상이 되고 있는 프로토콜인 만큼, 저속인데 비해, UDP는 데이터 보상이 없는 만큼, 고속으로 되어 있는 점이다. 컴퓨터간의 통신과 같이 주로 데이터를 보내는 경우에는 TCP가 이용되며, IP전화와 같이 음성이나 화상을 보내는 경우에는 UDP가 많이 이용된다. 이 제 4층의 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 처리를 가한 예는, 지금까지 존재하고 있지 않다.
제 5층의 세션층은, 세션(통신의 개시부터 종료까지)의 순서를 규정하는 층이며, 애플리케이션간에 커넥션을 개설하여 통신을 할 수 있는 상태로 하는 층이다. 이 층에 배치되는 소켓(socket)은, 컴퓨터가 가지는 네트워크 내의 주소에 해당되는 IP 주소와, IP 주소의 서브 주소인 포트 번호를 조합한 네트워크 주소를 의미하고 있다. 컴퓨터끼리를 접속하는 경우는, 반드시 소켓(IP 주소와 포트 번호의 조)을 지정하여 실시한다. 도 26에 나타내는 바와 같이, 종래의 대표적인 암호화 통신기술인 SSL은, 이 세션층에서 암호화 통신을 실현하고 있다.
제 6층의 프레젠테이션층은, 세션(통신의 개시부터 종료까지)에서 교환하는 데이터의 표현 방법이나 부호화, 암호화 등을 규정하는 층이다. TCP／IP 프로토콜에서는, 이 층에 상당하는 부분은 없고, 통상은 애플리케이션 스스로 스트림 데이터의 처리를 핸들링하고 있다.
또, 제 7층의 애플리케이션층은, 애플리케이션간에서의 데이터의 교환을 규정하기 위한 층이며, TCP／IP 프로토콜에서는 이 층에 상당하는 부분은 없다. 예를 들면, 전자 메일의 포맷이나, 문서의 내부 구조 등, 애플리케이션간에 서로 데이터를 교환하는 경우에 필요한, 공통의 데이터 구조 등을 규정하는 층이다.
도 25는, IPsec를 탑재한 표준 프로토콜 스택이지만, 우선, 물리층(제 1층)과 데이터 링크층(제 2층)에, NIC(Network Interface Card)Driver가 설치되어 있다. 이 드라이버는, 컴퓨터 등의 하드웨어를 네트워크에 접속하기 위한 인터페이스 카드의 드라이버이며, 그 내용은 데이터 송수신 제어 소프트웨어이다. 예를 들면　Ethernet에 접속하기 위한 LAN 보드 또는 LAN 카드가 이것에 상당한다. 제 3층의 네트워크층은, 일부가 트랜스포트층(제 4층)까지 늘어난 IP 에뮬레이터(emulator)가 존재하고 있다. 이 트랜스포트층까지 늘어난 부분에는, 트랜스포트로서의 기능은 실장하고 있지 않다. 세션층에, 네트워크층의 기능을 제공하고 있을 뿐이다. 이 IP 에뮬레이터는, IPsec에 의한 암호화 통신을 실시하는 프로토콜과, 암호화 통신을 실시하지 않는 프로토콜인 IP를 용도에 따라 전환하여 사용하는 기능을 한다. 또, 제 3층의 네트워크층에는 ARP(Address Resolution Protocol)가 배치되어 있다. 이 ARP는, IP 주소로부터 Ethernet의 물리 주소인 MAC(Media Access Control) 주소를 요구하는데 사용되는 프로토콜이다. MAC는, 매체 액세스 제어로 불리는, LAN 등에서 이용되는 전송 제어 기술이며, 데이터의 송수신 단위인 프레임의 송수신 방법이나 프레임의 형식, 오류 정정 등을 규정하는 기술로서 이용되고 있다.
또, 이 네트워크층에는, IP의 에러 메시지나 제어 메시지를 전송하는 프로토콜인 ICMP(Internet Control Message Protocol)와, 동일한 데이터를 복수의 호스트에 효율적으로 배송하기 위한 또는 배송을 받기 위해서 구성되는 호스트의 그룹을 제어하기 위한 프로토콜인 IGMP(Internet Group Management Protocol)가 설치되어 있다. 그리고, 네트워크층의 상위층의 트랜스포트층에는, TCP와 UDP가, 그리고 또한 상위층인 세션층에는 소켓(Socket) 인터페이스가 배열되어 있다.
도 26은, 암호화 처리 프로토콜로서 SSL을 구비한 표준 프로토콜의 예이며, 네트워크층에 IPsec를 탑재하지 않은 대신에 소켓(세션층)에 SSL이 탑재되어 있다. 이 외의 프로토콜은 도 25에 나타낸 것과 동일하다.
종래의 대표적인 암호화 통신기술 중에서, IPsec는, IP의 패킷을 암호화하여 송수신하는 것이며, 따라서, TCP나 UDP 등의 상위의 프로토콜을 이용하는 애플리케이션 소프트는 IPsec가 사용되고 있는 것을 의식할 필요가 없다.
한편, SSL에서는, 서로의 인증 레벨에서는 RSA(Rivest Shamir Adleman：공개열쇠 암호방식을 개발자 3명의 머리글자) 공개열쇠 암호기술을 이용한 디지털 증명서가 이용되며, 데이터의 암호화에서는 DES 등의 공통열쇠 암호기술이 이용되고 있다. 이 SSL은 제 5층의 세션층에 있기 때문에, 특정 애플리케이션에 의존하게 된다.
IPsec는, OSI에 있어서의 제 4층(트랜스포트층)보다 하위의 제 3층(네트워크층)에 있어서의 데이터의 「누설」이나 「개찬」을 막는 기능으로서 실현한 것이다(예를 들면, R.Atkinson, 1995년 8월, 「Security Architecture for the Internet Protocol」, RFC1825를 참조.). 이것에 대해서, SSL은, 제 5층의 세션층에 있어서의 암호화 기술이며, 현재 인터넷에서 널리 사용되고 있는 WWW(World Wide Web)나 FTP(File Transfer Protocol) 등의 데이터를 암호화하여, 프라이버시와 관련되는 정보나 기업 비밀 정보 등을 안전하게 송수신하기 위한 것이다.
표 1은, IPsec와 SSL의 기능을 비교하여 기재한 것이다. 이 표에서 보는 한, IPsec와 SSL은 서로 상반되는 이점과 결점이 있는 것처럼 생각할 수 있다.
예를 들면, 클라이언트-클라이언트간의 통신에서는, SSL의 경우, 그 커멘드 체계와 통신 내용이 주종의 관계, 즉 클라이언트／서버가 되어 버리므로, 서버를 통하지 않고 클라이언트-클라이언트 간의 통신은 할 수 없었다. 즉, 단말(A)로부터 단말(B)에 비밀의 데이터를 SSL에 의해 암호화하여 보내는 경우에는, 반드시 사이에 서버를 개재할 필요가 있었다. 이것에 대해서, IPsec에서는 이러한 제약이 없으므로 직접 통신이 가능해진다.
표 1 : IPsec와 SSL의 기능비교
IPsec SSL
(1) 클라이언트-클라이언트간의 통신 Ｏ 직접 통신가능 × 직접 통신불가. 특별한 서버를 통해 통신하는 것은 가능.
(2) PPP 모바일 환경 △ XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. Ｏ
 통신가능.
(3) ADSL 환경
(4) NAT, IP 매스커레이드 환경 △ NAT-T와 병용하는 것으로 실현 가능. Ｏ 통신가능.
(5) TCP/IP 프로토콜 스택으로의 DoS 공격 Ｏ DoS 공격으로의 대응가능. × 대응 블가.
(6) 열악한 통신환경화(물리 노이즈가 많아 통신에러가 발생하는 환경) × 대응이 불충분. 스루 풋의 저하를 초래한다. Ｏ 대응가능.
(7) 다른 LAN 사이의 통신 △ 서브네트워크 주소가 동일 주소의 경우, 통신불가. Ｏ 통신가능.
(8) 다른 네트워크 환경 △ 관리가 어렵고 곤란. Ｏ 관리의 간소화가 가능.
(9) 복수의 캐리어 경유의 환경 × 통신불가. Ｏ 통신가능.
(10) 모든 UDP 포트의 안전한 통신 Ｏ 안전한 통신이 가능. × 통신불가.
(11) 모든 UDP 포트의 안전한 통신 Ｏ 안전한 통신이 가능. × 특정 TCP 포트 이외는 통신불가.
(12)애플리케이션에서의 제한 Ｏ 영향 없음. × 소켓 프로그램의 변경이 필요.
(13) 액세스 단위 IP 단위 리소스단위(URL단위, 폴더단위)
(14) MUT(최대 세그먼트 사이즈) △ 조정이 필요. Ｏ MTU를 의식하지 않고 통신가능.
(15) 모바일 환경하에서, VoIP를 사용한 인터넷 전화 △ XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. × 사용 불가.
(16) ADSL 환경하에서, VoIP를 사용한 인터넷 전화 △ XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. × 사용 불가.
(17) 다른 LAN 사이에서, VoIP를 사용한 인터넷 전화 △ NAT-T, IPsec-DHCP를 사용하는 것으로 실현 가능. × 사용 불가.
(18) 복수 캐리어 LAN 사이에서, VoIP를 사용한 인터넷 전화 × 통신불가. × 사용 불가.
또, PPP(Point to Point Protocol) 모바일 환경 혹은 ADSL(Asymmetric Digital Subscriber Line) 환경에 있어서는, IPsec는, 데이터의 암호화 통신을 개시하기 전에, 암호화 방식의 결정, 열쇠의 교환, 상호 인증에 사용하는 프로토콜인 IKE(Internet Key Exchange) 프로토콜을 사용한 통신 중에서, 접속처 상대의 인증을 실시하고 있다. 따라서, PPP모바일 환경(리모트 클라이언트) 또는 ADSL 환경의 경우, IP 주소를 고정할 수 없기 때문에, IPsec의 게이트웨이간에서, 가장 많이 사용하고 있는 IKE의 Main 모드, 즉 인증시에 통신 상대의 IP 주소 정보를 사용하는 모드를 사용할 수 없다. 또한, 해결책으로서는, 어그레시브 모드(Aggressive mode)를 사용하는 것으로, ID 정보에 IP 주소를 사용하지 않아도 되고, ID 정보에 예를 들면 사용자 정보를 사용하고, 기존 공유열쇠에 사용자의 패스워드를 사용하는 것으로 상대를 특정할 수 있다. 단, 어그레시브　모드에서는 열쇠 교환 정보와 같은 메시지 중에서 접속처 상대의 ID를 송신하기 때문에, ID는 암호화되지 않고 평문인 채 송신하게 된다. 또,　XAUTH(Extended Authentication within IKE)를 이용함으로써, 인증의 문제를 해결할 수 있지만, 파이어 월(fire wall)의 설정에서, 리모트 클라이언트로부터의 액세스는, IP 주소가 불분명하기 때문에, IKE, IPsec를 모두 허가로 할 필요가 있고, 보안상 문제가 남는다. SSL은, 이 환경하에 있어서도, 통신하는 것이 가능하다.
또, IPsec는, NAT(Network Address Translation)나 IP 매스커레이드에 대응할 수 없다고 하는 문제가 있다. 이러한 것에 대응하기 위해서는, 예를 들면 UDP의 페이로드에 싣는 등 다른 기능과 병용해야 한다. NAT는, 인터넷에 접속된 기업 등이 1개의 세계적인 IP 주소를 복수의 컴퓨터로 공유하는 기술이며, 조직내에서만 통용되는 IP 주소(로컬 주소)와 인터넷상의 주소(글로벌 주소)를 상호 변환하는 기술이다. NAT에 대응할 수 없는 것은, IP헤더가 AH(Authentication Header)의 인증 범위에 들어가 있기 때문에, 이 로컬 주소로부터 글로벌 주소의 상호 변환을 할 수 없게 되고, 서브네트워크가 다른 로컬 주소끼리의 통신을 할 수 없게 되기 때문이다.
또, IP 매스커레이드란,　LAN　안의 개인 주소를 가지는 복수의 클라이언트로부터 인터넷에 액세스하는 것을 가능하게 하는 구조이며, 이것을 이용하면, 외부(인터넷)에서는 IP 매스커레이드가 동작하고 있는 단말밖에 보이지 않기 때문에 보안상 바람직하다고 말할 수 있는 것이다. IPsec가 IP 매스커레이드에 대응할 수 없는 이유는, IPsec의 ESP(Encapsulating Security Payload：암호 페이로드) 헤더가 IP헤더의 바로 다음에 있기 때문이다. IP 매스커레이드를 실장하고 있는 통상의 루터는, IP헤더의 바로 뒤에는, TCP／UDP의 포트 번호가 있다고 판단하고 있다. 따라서, IP 매스커레이드를 실장하고 있는 루터를 경유하면, 이 포트 번호를 변경해 버리기 때문에, IPsec는, 개찬되었다고 판단하여, 호스트의 인증을 할 수 없다고 하는 문제가 생긴다. 이 문제는, UDP의 페이로드에 싣기 위한 NAT－T(NAT－Traversal)를 서포트하는 제품을 이용하는 것으로 회피할 수 있다. 단, NAT－T의 드래프트 버젼이 다르면, NAT－T 대응 제품끼리라도 접속할 수 없다. SSL은, 이 환경하에 있어서도, 통신하는 것이 가능하다.
이것에 대해, 해커나 크래커라고 하는 네트워크의 부정 침입자에 의한 TCP／IP로의 다양한 공격, 이른바 DoS 공격(Denial of Service：서비스를 정지시키는 공격)에 대해서는, SSL은 무력하다. TCP／IP 프로토콜 스택으로의 DoS 공격, 예를 들면, TCP 절단 공격이 실시되면, TCP 세션이 끊겨 버려 SSL의 서비스는 정지해 버리는 것이다. IPsec는 제 3층(IP층)에 실장하고 있기 때문에, IP층에 보안 기능을 가지므로, TCP／IP(제 4층, 제 3층)로의 DoS 공격을 막을 수 있다. 그러나, SSL은, TCP／IP(제 4층, 제 3층)보다 위의 층(제 5층)에 실장되어 있는 암호화 프로토콜이기 때문에, TCP／IP로의 DoS 공격을 막을 수 없다.
또한, 물리 노이즈가 많고 통신 에러가 다발하는 바와 같은 열악한 통신 환경화에 있어서의 통신에 대해서는, SSL이 IPsec에 비해 효과적이다. 즉, IPsec는, 에러의 검출을 했을 경우, 재발송 동작을 상위의 TCP에 맡기게 된다. TCP는, 재발송 데이터를 IPsec에 보내지만, IPsec는 이 재발송 데이터인 것을 인식하지 못하고, 재암호를 실시하여 버리는 것이다. SSL은 TCP에서 에러 회복 처리를 실시하므로 같은 데이터를 재암호화할 필요는 없다.
또, IPsec에서는 다른 LAN 사이의 통신을 할 수 없다. 즉, LAN 내의 서브네트워크 주소의 배포 관리는, LAN 내에 있는 DHCP(Dynamic Host Configuration Protocol) 서버가 관리하고 있기 때문에, LAN 내에서는, 동일한 서브네트워크 주소가 할당되는 경우는 없지만, 다른 LAN 사이의 통신의 경우, 서로의 LAN 내에 있는 DHCP 서버가 개별적으로 서브네트워크 주소를 할당하고 있기 때문에, 동일 주소가 할당될 가능성이 있다. 이와 같이 동일 주소가 할당되었을 경우에는, IPsec에서는 통신할 수 없다. 단, 별도로 IPsec－DHCP 서버를 세워서, 동일 주소가 되지 않게 관리하면, 통신할 수 있다. SLL은 상술한 바와 같이 OSI참조 모델의 제 5층(세션층)에 위치하고 있기 때문에, 하위층의 TCP에서 에러 회복 처리를 실시할 수 있고, 상기와 같은 열악한 환경하에서도 통신하는 것이 가능해진다.
또, 다른 네트워크 환경하에 있어서의 통신에 대해서는, IPsec는, 경유하는 노드 모두를 관리하고, IPsec를 통과할 수 있도록 설정 변경해야 하기 때문에, 관리가 어렵지만, SSL은, 이 환경하에 있어서도, 경유하는 노드의 환경을 의식하지 않고 통신하는 것이 가능하다.
또한, IPsec는 복수의 캐리어 경유의 접속을 할 수 없다고 하는 문제가 있다. 즉, IPsec는, 경유하는 노드 모두를 관리하고, IPsec를 통과할 수 있도록 설정 변경하지 않으면 안 되기 때문에, 복수의 캐리어 경유의 접속을 할 수 없다. 예를 들면, 도쿄와 오사카에서, 다른 캐리어와 계약하고 있는 경우에, 접속할 수 없기 때문에, 별도, 고액의 전용선을 사용하고 있는 케이스도 있다. SSL은, 이 환경하에 있어서도, 통신하는 것이 가능해진다.
또, SSL은, UDP의 통신을 서포트하고 있지 않기 때문에, UDP를 암호 통신할 수 없다. TCP도 특정의 포트밖에 서포트하고 있지 않기 때문에, TCP 모든 포트를 암호 통신할 수 없다. 이것에 대해서, IPsec는, UDP에서도 TCP에서도 암호 통신할 수 있다.
게다가, SSL은 애플리케이션에 대한 호환성을 가지지 않는 점에 있어서 문제가 있다. 애플리케이션은, 인터넷 통신을 실시할 때에 소켓(제 5층)을 프로그램 인터페이스로서 사용한다. 이 때문에, 애플리케이션이 SSL(제 5층)을 사용하는 경우에는, 이 소켓 인터페이스를 SSL 인터페이스로 변경해야 한다. 따라서, SSL에 애플리케이션의 호환성은 없다. 이것에 대해, IPsec는, 소켓(제 5층) 아래에 위치하고 있기 때문에, 애플리케이션은, 소켓(제 5층)을 프로그램 인터페이스로서 그대로 사용할 수 있으므로 애플리케이션의 호환성이 있다.
또, IPsec는, IP 주소 단위로 제어할 수 있는데 비해, SSL은, 소스 단위(UR L단위, 폴더 단위)로 제어하게 된다.
게다가, IPsec는 최대 세그먼트(segment) 사이즈가 작아진다고 하는 문제가 있다. 즉, IPsec에서는, ESP헤더, ESP페이로드를 사용하기 때문에, 페이로드가 작아지기 때문에, 프래그맨트(패킷의 분할)가 발생하고, 스루 풋이 저하한다. 또, TCP 패킷에서는, 프래그맨트가 금지이기 때문에, 엔드 엔드에서, IPsec의 통과하는 환경을 파악하고, 프래그맨트가 발생하지 않는 최대 세그먼트 사이즈를 설정할 필요가 있다. 이것에 대해, SSL은, 통과하는 환경을 파악할 필요가 없기 때문에, 최대 세그먼트 사이즈를 설정할 필요는 없다.
이상, 표 1에 의거하여 IPsec와 SSL의 기능 비교에 대해서 설명했지만, 후술하는 본 발명의 프로토콜인 TCP(2)(등록상표 출원중)는, 이러한 IPsec와 SSL의 모든 장점을 포함하고, 그 밖에도 더 많은 메리트를 가지는 획기적인 암호 통신 프로토콜이다.
본 발명은, 상술과 같은 문제에 감안하여 이루어진 것이며, 컴퓨터 단말로의 부정 침입을 막기 위한 「암호화의 기능」을 애플리케이션ㆍ프로그램 각각에 실장할 필요가 없고, 따라서, 애플리케이션ㆍ프로그램 자체를 재작성할 필요도 없고, 또한 상기 암호화 기능에 대응하고 있지 않은 통신 상대와도 종래의 평문에 의해 통신할 수 있고, 또 IPsec를 이용할 수 없는 환경(혹은 이용하고 싶지 않은 상황)에서도 암호화나 인증의 혜택을 받을 수 있는 통신 시스템, 특히 프로토콜 스택과 관련하는 통신 장치, 통신 방법 및 이것들을 실현하기 위한 통신 프로그램을 제공하는 것을 목적으로 한다.
상기 과제를 해결하고, 본 발명의 목적을 달성하기 위해, 본 발명의 통신 시스템은, 트랜스포트층에 위치하는 TCP 또는 UDP에 해당하는 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 시스템에 있어서, 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 통신로의 양단에서 대응하는 암호화 및 복호화 논리 회로를 결정하는 결정 수단과, 송수신하는 정보 단위로서의 패킷 중, 적어도 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 수단과, 수신한 이 암호화된 프로토콜을 상기 결정 수단에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 수단을 갖추며, 상기 접속 순서 수단이 정당한 권한을 가진다고 판단하여 접속한 통신 상대와만 상기 결정 수단이 트랜스포트층의 TCP 또는 UDP 프로토콜에 암호화 및 복호화 논리 회로를 적용하여 암호화 통신을 실시하는 것이다.
이것에 의해, 종래는 존재하지 않았던 TCP 또는 UDP 레벨 독자적인 암호화가 가능해지고, IP보다 위의 층에 있어서의 데이터 누설이나 개찬의 가능성이 격감하게 된다. 즉, IP레벨의 암호화인 IPsec가 해제된 후의 데이터도, TCP 또는 UDP 레벨의 독자적인 암호화가 이루어져 있게 되며, 이중의 암호화라고 하는 의미로 암호의 강도가 커지는 동시에, IP가 정당하게 복호화된 직후의 데이터에 대한 감청 등 인터페이스를 노린 데이터 누설에 대한 유효한 방어가 된다.
또, IP가 암호화되지 않는 경우에도 TCP나 UDP만을 암호화함으로써 보안을 독자적으로 강화할 수 있다.
또한, UDP의 브로드캐스트 기능을 퍼포먼스 등의 관점으로부터 IPsec와 분리하여 독자적으로 기능하게 하는 경우가 있지만, 이 경우도 본 발명의 TCP 또는 UDP 레벨의 암호화가 유효하다.
또한, 암호화 및 복호화 논리 회로의 결정은, 통신로의 양단에서 대응하는 암호화 및 복호화 논리 회로의 사전에 결정하는 것이 바람직하다. 여기서, 통신로란 유선, 무선을 묻지 않는다. 위성을 통해서 통신하는 방법도 포함하는 것은 말할 것도 없다. 또, 본 발명의 암호화 및 복호화 논리 회로의 결정에는, 플로피디스크, CD(Compact Disk), USB 메모리 혹은 IC 칩 등의 리무버블 미디어(매체)에 암호화 및 복호화 논리 회로를 기억시켜서, 이러한 매체를 송신측과 수신측에서 교환하여 암호화 및 복호화 논리 회로의 결정을 실시하는 것도 포함하는 것이다.
또, 본 발명에서는, 보다 상위의 층, 전형적으로는 HTTP 등의 애플리케이션층으로의 「진입」이나 「공격」 등의 부정 통신 패턴의 인식을, 보다 하위의 층(트랜스포트층)에서 실시할 수 있다. 예를 들면, 본 발명의 통신 시스템에서 이용되는 프로토콜 암호화 수단 혹은 프로토콜 복호화 수단과, 종래의 크래킹ㆍ프로텍터와 같은 기능 모듈(일반적인 분쇄 패턴의 검출, 파기 내지 통과 제한 수단)과의 편성이, 상위층인 애플리케이션층보다 하위층인 트랜스포트층의 TCP, UDP, 또한 그 아래의 층인 네트워크층에 해당하는 IP, ARP, ICMP, IGMP 등의 어느 쪽에서 실현된다. 이러한 프로토콜 스택은, 단일의 프로토콜 스택으로서 「소프트웨어 내지 하드웨어 모듈」에 의해서 실현될 수 있다.
이것에 의해, 상술의 효과 외에, 데이터의 「누설」 「개찬」 또한 「위장」이나 「진입」 「공격」을 막는 기능에 대해서 프로토콜 스택간에 중복이나 틈새가 없고 비용에 비해 효과가 큰 통신 시스템을 실현할 수 있다.
또, 본 발명의 통신 시스템에서는, 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 시스템에 이용되는 암호화 및 복호화 논리 회로를 결정하는 결정 수단과, 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 이 통신 상대와의 접속을 실시하기 위한 접속 순서 수단을 갖추는 제 1 및 제 2통신장치와, 암호화 및 복호화 논리 회로의 결정 수단을 갖추지 않는 제 3통신 장치를 포함하고, 상기 암호화 및 복호화 논리 회로의 결정 수단을 갖추는 통신 장치(제 1통신 장치와 제 2통신 장치)는, TCP 또는 UDP의 암호화 및 복호화 프로토콜 처리 수단 외에, 암호화 및 복호화를 수반하지 않는 통상의 TCP 또는 UDP를 처리하는 통상 프로토콜 처리 수단도 갖추며, 이러한 암호화 및 복호화 논리 회로 결정 수단을 가지는 통신 장치끼리 통신할 경우에는, 암호화 및 복호화 프로토콜 처리 수단을 이용하여 통신을 실시하고, 상기 암호화 및 복호화 논리 회로의 결정 수단을 갖추는 통신 장치(제 1 및 제 2통신 장치)와 암호화 및 복호화 논리 회로의 결정 수단을 갖추지 않은 제 3통신 장치와 통신하는 경우에는, 상기 접속 순서 수단의 판단 정보에 의거하여 암호화 및 복호화 결정 수단에 의해, 이 통신에 있어서 암호화 및 복호화를 실시하지 않는 것을 결정하고, 통상의 TCP 또는 UDP 프로토콜 처리 수단에 의해, 통신을 실시할 수 있도록 하고 있다.
이것에 의해, 본 발명에 의한 암호 통신에 대응하고 있지 않은 통신 장치와의 사이라도 종래대로의 통신을 확보할 수 있게 된다.
게다가, 본 발명의 통신 시스템에 있어서는, 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추는 통신 장치(제 1 또는 제 2통신 장치)로부터 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추지 않은 통신 장치(제 3통신 장치)에 통신하는 경우에, 제 1 및 제 2통신 장치가, 암호화 및 복호화 논리 회로 결정 수단에 의해, 제 3통신 장치와의 통신을 실시하지 않는 것을 결정하고, 이 제 3통신 장치와의 통신을 실시하지 않게 할 수도 있다.
이것에 의해, 통신 상대의 제한 및 각 보안 레벨에 대해서 철저한 보안 폴리시를 채용할 수 있다.
본 발명에서는 또, 암호화 및 복호화 논리 회로 결정 수단에 의한 결정의 후보가 될 수 있는 암호화 및 복호화 논리 회로를 메모리 내지 회로에 기억하고 있고, 이 기억하는 내용을 정기적으로 변경하는 논리 회로 변경 수단을 한층 더 갖출 수 있다.
이것에 의해, 프로토콜 스택 자체를 재작성하거나 교체할 필요가 없고, 새로운 암호화 알고리즘에 대응하거나 암호열쇠를 변경함으로써 해독 리스크를 삭감할 수 있다.
게다가, 본 발명에서는, 암호화 및 복호화 논리 회로 결정 수단이, 암호화ㆍ복호화 논리 회로에 대해서 암호화를 하지 않고 평문(平文)을 취급하는 취지를 결정하는 것도 가능하다.
이것에 의해, 통신 상대, 예를 들면 클라이언트측의 프로토콜 스택 등이 본 발명에 의한 암호화 등에 대응하고 있지 않은 경우에도, 종래대로 통신할 수 있다.
또한 이러한 경우에도, 「위장」이나 「진입」 「공격」을 막는 이른바 크래킹ㆍ프로텍터(CP) 기능에 대해서는 활용할 수 있다.
본 발명은, 또, TCP 또는 UDP에 해당하는 프로토콜에 인증 기능을 추가하여 통신하는 통신 시스템에 있어서, 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 통신로의 양단에서 대응하는 완전성 인증 논리 회로를 결정하는 완전성 인증 결정 수단과, 송수신하는 정보 단위로서의 패킷 중, 적어도 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증 정보를 부가하여 출력 또는 송신하는 프로토콜 완전성 인증 정보부가 수단과, 수신한 이 완전성 인증 정보가 부가된 프로토콜을 상기 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 수단을 갖춘 통신 시스템을 제공하는 것이다.
또, 본 발명은, 트랜스포트층에 위치하는 TCP 또는 UDP를 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 이 TCP 또는 UDP를 이용하여 완전성 인증의 결정을 실시하는 완전성 인증 결정 수단을 갖추는 제 1 및 제 2통신 장치와, 완전성 인증 결정 수단을 갖추지 않은 제 3통신 장치가 각각 네트워크에 접속되어 있고, 제 1 및 제 2통신 장치는, 완전성 인증 정보를 부가하여 TCP 또는 UDP를 처리하는 완전성 인증 프로토콜 처리 수단과, 완전성 인증 정보의 부가를 실시하지 않는 통상의 TCP 또는 UDP를 처리하는 통상 프로토콜 처리 수단의 양쪽 모두를 갖추며, 제 3통신 장치는, 완전성 인증을 수반하지 않는 통상의 프로토콜 처리 수단만을 갖추고 있고, 완전성 인증 결정 수단을 가지는 통신 장치끼리(제 1통신 장치와 제 2통신 장치) 통신할 때는, 이 완전성 인증 결정 수단에 의해, 완전성 인증 정보를 부가한 완전성 인증 프로토콜 수단에 의해 통신하는 것과 동시에, 완전성 인증 결정 수단을 가지는 통신 장치, 예를 들면 제 1통신 장치가 완전성 인증 결정 수단을 갖추지 않은 통신 장치(제 3통신 장치)와 통신할 경우에는, 상기 완전성 인증 정보를 부가하지 않는 것을 결정하고, 상기 통상 프로토콜 처리 수단에 의해 통신을 실시하도록 하고 있다.
또, 이 경우, 완전성 인증 결정 수단을 갖춘 통신 장치(제 1 또는 제 2통신 장치)가, 완전성 인증 결정 수단을 갖추지 않은 통신 장치(제 3통신 장치)와 통신할 때는, 완전성 인증 결정 수단에 의해 통신을 실시하지 않는 것을 결정하고, 통신을 하지 않게 할 수도 있다.
또, 본 발명에서는, 완전성 인증 결정 수단에 의한 결정 후보가 될 수 있는 완전성 인증 논리 회로를 메모리에 기억 내지 회로에 실장하고 있고, 이 기억하는 완전성 인증 논리 회로 정기적으로 변경하는 완전성 인증 논리 회로 변경 수단을 한층 더 갖출 수 있다.
게다가, 본 발명에서는, 완전성 인증 결정 수단이, 완전성 인증 정보부가 및 완전성 인증을 하지 않는 취지를 결정하는 것도 가능하다.
또한, 이러한 경우에도, 「위장」이나 「진입」 「공격」을 막는 크래킹ㆍ프로텍터(CP) 기능에 대해서는 활용할 수 있다.
또, 본 발명은, 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 기능을 추가하여 통신하는 통신 방법을 제공한다. 이 통신 방법은, TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 접속 스텝과, 통신로의 양단에서 대응하는 암호화ㆍ복호화 논리 회로를 사전에 결정하는 결정 스텝과 송수신하는 정보 단위가 되는 패킷 중, 적어도 TCP 또는 UDP의 페이로드에 해당하는 프로토콜을 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 스텝과, 수신한 암호화된 프로토콜을 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 스텝을 포함하고, 접속 스텝에 있어서 통신 상대가 정당한 권한을 가진다고 판단한 경우에, 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 처리를 실시하여 통신하는 것이다.
또, 본 발명의 통신 방법에서는, 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 기능을 추가하여 통신하는 통신 방법에 이용되는 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추는 제 1 및 제 2통신 장치와, 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추지 않은 제 3통신 장치가 각각 네트워크에 접속되어 있는 경우의 통신 방법을 제공한다. 즉, 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추는 통신 장치(제 1 및 제 2통신 장치)끼리 통신할 경우에는, TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 통신하는 것과 동시에, 암호화 및 복호화 논리 회로 결정 수단을 갖춘 통신 장치(제 1 또는 제 2통신 장치)가 암호화 및 복호화 논리 회로 결정 수단을 가지지 않는 통신 장치(제 3통신 장치)와 통신할 때는, TCP 또는 UDP 프로토콜의 페이로드를 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하지 않는 것을 결정하고, 암호화 논리 회로를 수반하지 않는 통상의 TCP 또는 UDP 프로토콜로 통신하도록 하고 있다.
또, 제 1 또는 제 2통신 장치와 제 3통신 장치와의 통신에서는, 제 1 또는 제 2통신 장치가, 제 3통신 장치가 암호화 및 복호화 결정 수단을 갖추지 않은 것을 이유로 통신을 실시하지 않는 것을 결정하고, 상기 제 3통신 장치와의 통신을 실시하지 않게 할 수도 있다.
또, 상기의 암호화 및 복호화 논리 회로의 결정에 있어서 결정 후보가 될 수 있는 암호화ㆍ복호화 논리 회로를 메모리 내지 회로에 기억해 두고, 이 기억하는 암호화ㆍ복호화 논리 회로의 내용을 정기적으로 변경하는 것도 가능하다.
게다가, 이 결정 스텝에 있어서, 암호화ㆍ복호화 논리 회로에 대해서 암호화를 하지 않고 평문을 취급하는 취지를 결정할 수도 있다. 또, 본 발명에 의한 통신 방법에서는 또한, 결정 스텝보다 전에, 통신 상대를 인증하는 스텝을 한층 더 포함할 수 있다.
또, 본 발명은, 트랜스포트층에 있는 TCP 또는 UDP에 해당하는 프로토콜에 인증 기능을 추가하여 통신하는 통신 방법에 있어서, TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 접속 스텝과, 통신로의 양단에서 대응하는 완전성 인증 논리 회로를 사전에 결정하는 완전성 인증 결정 스텝과, 송수신하는 정보 단위의 패킷 중, 적어도 TCP 또는 UDP의 페이로드에 해당하는 프로토콜을 완전성 인증 결정 스텝에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증 정보를 부가하여 송신하는 프로토콜 완전성 인증 정보부가 스텝과, 수신한 이 완전성 인증 정보가 부가된 프로토콜을 완전성 인증 결정 스텝에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 스텝을 포함하고, 접속 스텝에 있어서 통신 상대가 정당한 권한을 가진다고 판단한 경우에, 트랜스포트층에 있는 상기 TCP 또는 UDP 프로토콜에 완전성 인증 정보를 부가하여 통신하는 통신 방법을 제공한다.
그리고, 또한 본 발명은, 트랜스포트층의 TCP 또는 UDP를 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 이 TCP 또는 UDP를 이용하여 완전성 인증의 결정을 실시하는 완전성 인증 결정 수단을 갖추는 통신 장치(제 1 및 제 2통신 장치)간, 혹은 상기 완전성 인증 결정 수단을 갖추는 통신 장치와 상기 완전성 인증 결정 수단을 갖추지 않은 제 3통신 장치와의 사이에 네트워크를 통하여 통신하는 통신 방법을 제공한다. 이 통신 방법은, 완전성 인증 프로토콜을 탑재한 통신 장치(예를 들면, 제 1통신 장치)가, 동일한 완전성 인증 프로토콜을 탑재한 통신 장치(제 2통신 장치)와 통신할 때는, 접속 순서 수단의 판단 정보에 의거하여 완전성 인증 결정 수단에 의해, 완전성 인증 정보를 부가한 TCP 또는 UDP를 처리하는 완전성 인증 프로토콜 처리를 실시하여 송신하고, 완전성 인증 프로토콜을 탑재한 제 1 또는 제 2통신 장치가, 상기 완전성 인증 프로토콜을 탑재하지 않은 제 3통신 장치와 통신할 때는, 접속 순서 수단의 판단 정보에 의거하여 완전성 인증 결정 수단에 의해, 완전성 인증 정보를 부가하지 않는 것을 결정하고, 통상의 TCP 또는 UDP를 처리하는 통상 프로토콜 처리를 실시하고 통신을 실시하도록 하고 있다.
또한, 제 1 또는 제 2통신 장치가, 완전성 인증 결정 수단을 가지지 않는 제 3통신 장치와 통신할 때에, 제 1 또는 제 2통신 장치가, 상기 제 3통신 장치가 완전성 인증 결정 수단을 가지지 않는 것을 이유로, 통신을 실시하지 않게 할 수도 있다.
또, 본 발명에서는, 완전성 인증 결정 스텝에 있어서 결정의 후보가 될 수 있는 완전성 인증 정보를 부가하기 위한 완전성 인증 논리 회로를 메모리에 기억 내지 회로에 실장하는 스텝과, 이 기억 내지 실장하는 내용을 정기적으로 변경하는 완전성 인증 논리 회로 변경 스텝을 한층 더 갖출 수 있다. 또, 완전성 인증 결정 스텝보다 전에, 통신 상대를 인증하는 스텝을 한층 더 포함할 수도 있다.
도 1은, 본 발명의 통신 시스템에 이용되는 TCP(2)의 프로토콜 스택을 나타 내는 도면이다.
도 2는, 본 발명의 TCP(2)를 이용한 통신 시스템의 제 1실시형태(TCPsec에 의한 EC 애플리케이션)에 있어서의 시스템의 전체 구성도이다.
도 3은, 본 발명의 TCP(2)를 이용한 통신 시스템의 제 2실시형태(UDPsec에 의한 방송 애플리케이션)에 있어서의 시스템의 전체 구성도이다
도 4는, 본 발명의 TCP(2) 중 3개의 프로토콜 스택의 패킷 구조와 그 암호화 범위 및 인증 범위를 나타내는 도면이다. (a), (b)(c)는, 각각 TCPsec／IPsec, TCPsec／IP, UDPsec／IP의 패킷 구조 및 각 암호화 범위, 완전성 인증의 적용 범위를 나타내는 도면이다.
도 5는, 본 발명의 TCP(2)의 실시형태인 TCP／TCPsec 패시브 오픈의 처리를 나타내는 흐름도이다.
도 6은, 본 발명의 TCP(2)의 실시형태인 TCP／TCPsec 액티브 오픈의 처리를 나타내는 흐름도이다.
도 7은, 표준 TCP와 본 발명의 TCPsec의 호스트(A)(액티브 오픈)와 호스트(B)(패시브 오픈) 간의 통신의 교환을 나타내는 순서도이다.
도 8은, 도 5의 TCP 패시브 오픈 처리(S5)의 상세를 나타내는 흐름도이다.
도 9는, 도 5의 TCPsec 패시브 오픈 처리(S6)의 상세를 나타내는 흐름도이다.
도 10은, 도 6의 TCP 액티브 오픈 처리(S12)의 상세를 나타내는 흐름도이다.
도 11은, 도 6의 TCPsec 액티브 오픈 처리(S13)의 상세를 나타내는 흐름도이 다.
도 12는, 도 9의 TCPsec 송수신 처리(S37) 및 도 11의 TCPsec 송수신 처리(S76)의 상세를 나타내는 흐름도이다.
도 13은, 도 9의 TCPsec 패시브 접속 처리(S48)의 상세를 나타내는 흐름도이다.
도 14는, 도 11의 TCPsec 액티브 접속 처리(S88)의 상세를 나타내는 흐름도이다.
도 15는, 본 발명의 TCP(2)의 실시형태인 UDP／UDPsec 오픈의 처리를 나타내는 흐름도이다.
도 16은, 본 발명의 TCP(2)를 이용한 UDP／UDPsec 유니캐스트 통신의 순서도이다.
도 17은, 본 발명의 TCP(2)를 이용한 UDP／UDPsec 브로드캐스트 통신의 순서도이다.
도 18은, 도 15의 UDP 오픈 처리(S124)의 상세를 나타내는 흐름도이다.
도 19는, 도 15의 UDPsec 오픈 처리(S125)의 상세를 나타내는 흐름도이다.
도 20은, 도 19의 UDPsec 브로드캐스트 수신 개시 처리(S141)의 상세를 나타내는 흐름도이다.
도 21은, 도 19의 UDPsec 유니캐스트 송신 개시 처리(S146)의 상세를 나타내는 흐름도이다.
도 22는, 도 19의 UDPsec 데이터 송수신 처리(S144)의 상세를 나타내는 흐름 도이다.
도 23은, 도 19의 UDPsec 유니캐스트 수신 개시 처리(S137)의 상세를 나타내는 흐름도이다.
도 24는, 본 발명의 TCP(2)를 종래의 IPsec 또는 SSL을 적용했을 경우와 비교한 메리트를 설명하기 위한 도면이다.
도 25는, 종래의 IPsec를 이용한 표준적인 통신의 프로토콜 스택을 나타내는 도면이다.
도 26은, 종래의 SSL을 이용한 표준적인 통신의 프로토콜 스택을 나타내는 도면이다.
*부호의 설명
1. 호스트 컴퓨터 2. 네트워크 제어기기(루터)
3a, 3b, 3c. 클라이언트 단말 4a, 4b, 4c. 클라이언트 단말
11. NIC 드라이버 12. ARP 또는 ARP on CP
13. IP 에뮬레이터 13b. IPsec on CP
15. TCP 에뮬레이터 15b. TCPsec on CP
16. UDP 에뮬레이터 16b. UDPsec on CP
17. 소켓(Socket) 41. IP 헤더
42. ESP 헤더 43. TCP 헤더
44. TCPsec 부가 정보 45. 데이터(페이로드)
46. TCPsec 부가 트레일러 47. TCPsec 부가 인증 데이터
48. ESP 트레일러 49. ESP 인증 데이터
이하, 도 1 ~ 도 24를 참조하면서 본 발명의 실시형태의 예를 설명한다.
도 1은, 본 발명의 암호화 통신 시스템의 일 실시형태에 이용되는 프로토콜 스택을 나타내는 것이다.
본 발명에 이용되는 프로토콜 스택은, 도 1에 나타내는 바와 같이, OSI7계층의 물리층(제 1층)과 데이터 링크층(제 2층)에 상당하는 계층에, NIC(Network Interface Card)의　Driver(11)가 배열된다. 이 드라이버는, 이미 기술한 바와 같이, 컴퓨터 등의 하드웨어를 네트워크에 접속하기 위한 인터페이스 카드의 드라이버이며, 그 내용은 데이터 송수신 제어 소프트웨어이다. 예를 들면 Ethernet에 접속하기 위한 LAN 보드 또는 LAN 카드가 이것에 상당하는 것이다.
제 3층의 네트워크층에는, 일부가 트랜스포트층(제 4층)까지 늘어난 IP 에뮬레이터(emnlator)(3)가 존재하고 있다. 상기 늘어난 부분에는, 트랜스포트로서의 기능은 실장하고 있지 않다. 세션층에, 네트워크층의 기능을 제공하고 있을 뿐이다. 이 IP 에뮬레이터(3)는, 암호화 통신을 실시하는 프로토콜인 「IPsec on CP」(13b)와, 「IP on CP」(13a)를 용도에 따라 전환하여 사용하는 기능을 하는 것이다. 여기서, 「on CP」란, 크래킹ㆍ프로텍터(CP)에 의한, 「진입」 「공격」의 감시, 파기, 절단 내지 통과 제한의 대상이 되어 있는 것, 또는, 설정에 의해 이루어질 수 있는 것을 나타내고 있다.
또, 네트워크층에는 ARP on CP(Address Resolution Protocol on Cracking Protetor)가 배열되어 있다. 이 ARP on CP는, 크래커(Cracker)에의 보호 대책을 구비한 IP 주소로부터　Ethernet의 물리 주소인　MAC(Media Access Control) 주소를 요구하는데 사용되는 프로토콜이다. MAC는, 매체 액세스 제어라고 불리는, LAN 등에서 이용되는 전송 제어 기술이며, 데이터의 송수신 단위인 프레임의 송수신 방법이나 프레임의 형식, 오류 정정 등을 규정하는 기술로서 이용되고 있다.
여기서, IP 에뮬레이터(13)는, 본 발명에 의한 각종의 보안 기능을, 종래의 IP 주변의 스택에 정합시키기 위한 소프트웨어 또는 펌웨어이다. 즉, IP의 에러 메시지나 제어 메시지를 전송하는 프로토콜인 ICMP(Internet Control Message Protocol)(14a), 동일한 데이터를 복수의 호스트에 효율적으로 배송하기 위한 또는 배송을 받기 위해서 구성되는 호스트의 그룹을 제어하기 위한 프로토콜인 IGMP(Internet Group Management Protocol)(14b), TCP(15), UDP(16) 또한 소켓(Socket) 인터페이스(17)에 정합시키기 위한 소프트웨어, 또는 펌웨어 내지 하드웨어(전자회로, 전자부품)이다. 이 IP 에뮬레이터(13)에 의해, IPsec의 암호화ㆍ복호화 및 필요한 인증 정보부가ㆍ인증 등의 전후의 적합 처리를 실시할 수 있다.
이 IP 에뮬레이터(13)의 상층의 트랜스포트층(제 4층)에는, TCP 에뮬레이터(15)와 UDP 에뮬레이터(16)가 배치되어 있다. TCP 에뮬레이터(15)는, 암호화 통신을 실시하는 프로토콜인 「TCPsec on CP」(15b)와, 통상의 통신 프로토콜인 「TCP on CP」(15a)를 용도에 따라 전환하여 사용하는 기능을 한다. 동일하게 UDP 에뮬레이터(16)는, 암호화 통신을 실시하는 프로토콜인 「UDPsec on CP」(16b)와, 통상의 통신 프로토콜인 「UDP on CP」(16a)를 용도에 따라 전환하여 사용하는 기능을 한다.
본 발명의 가장 특징으로 해야 할 점은, 이 트랜스포트층(제 4층)에, TCPsec(15b)와, UDPsec(16b)의 암호화 통신 프로토콜을 탑재한 것이다. TCPsec(15b)와 UDPsec(16b)에 대해서는 후술한다.
이 트랜스포트층(제 4층)의 상층의 세션층(제 5층)에는, TCP 및 UDP 등의 프로토콜과 데이터의 교환을 실시하는 소켓(socket) 인터페이스(17)가 설치되어 있다. 이 소켓의 의미는, 이미 기술한 바와 같이 컴퓨터가 가지는 네트워크 내의 주소에 해당되는 IP 주소와, IP 주소의 서브 주소인 포트 번호를 조합한 네트워크 주소를 의미하고 있고, 실제로는, 일련의 헤더의 추가 내지 삭제를 정리하여 실시하는, 단일의 소프트웨어 프로그램 모듈(module)(실행 프로그램 등) 혹은 단일의 하드웨어 모듈(전자회로, 전자부품 등)로 이루어져 있다.
이 소켓 인터페이스(17)는, 한층 더 상위의 애플리케이션(도 2에서 나타내는 EC 애플리케이션 및 도 3에서 나타내는 방송 애플리케이션 등)으로부터의 통일적인 액세스 방식을 제공하는 것이며, 인수(引數)의 종류나 형태 등 종래와 같은 인터페이스를 유지하도록 하고 있다.
TCP 에뮬레이터(15)는, 트랜스포트층에 있어서, 데이터의 누설ㆍ개찬의 방지 기능, 즉 암호화, 완전성 인증 및 상대 인증 등의 기능을 가지는 TCPsec(15b)와, 이러한 암호화, 완전성 인증 및 상대 인증 등의 기능을 가지지 않는 통상의 프로토콜 TCP(15a)의 어느 쪽인가에 패킷을 배분하는 기능을 갖고 있다. 또, TCPsee(15b) 및 TCP(15a)의 어느 쪽도 크래킹ㆍ프로텍터(CP)를 갖추고 있기 때문 에, 그 어느 쪽을 선택했을 경우에도, 크래커에 의한 「진입」 「공격」에 대해서 방어하는 기능을 실현할 수 있다. TCP 에뮬레이터(15)는 상위층인 소켓과의 인터페이스의 역할도 하고 있다.
또, 이미 기술한 바와 같이 TCP가 에러보상기능을 가지는데 비해, UDP는 에러보상기능을 가지지 않지만, 그만큼 전송 속도가 빠르고, 또한 브로드캐스트 기능을 갖추고 있다고 하는 특징이 있다. UDP 에뮬레이터(16)는, TCP 에뮬레이터(15)와 동일하게, 데이터의 누설ㆍ개찬의 방지 기능, 즉 암호화, 완전성 인증 및 상대 인증 등의 기능을 가지는 UDPsec(16b)와, 이러한 암호화, 완전성 인증 및 상대 인증 등의 기능을 가지지 않는 통상의 프로토콜 UDP(16a)의 어느 쪽인가에 패킷을 배분하는 기능을 가지고 있다.
도 1에 나타내는 바와 같이, 소켓(17), TCP 에뮬레이터(15), UDP 에뮬레이터(16), 「TCPsec on CP」(15b), UDPsec on CP」(16b), 「TCP on CP」(15a), 「UDP on CP」(16a), 「ICMP on CP」(14a), 「IGMP on CP」(14b), IP 에뮬레이터(13), 「IP on CP」(13a) 및 「ARP on CP」(12)로 이루어지는 프로토콜 스택이 본 발명의 암호화처리를 행하기 위한 프로토콜 스택이며, 이하, 이 프로토콜 스택을 총칭하여 TCP(2)(등록상표 출원중)라고 부르기로 한다. 또한 TCP(2)에는 「IPsec on CP」(13b)는 필수의 것으로서 포함되지 않지만, 「IPsec on CP」(13b)를 포함하여 TCP(2)로 할 수도 있다.
본 발명의 TCP(2)는, TCP, UDP, IP, IPsec, ICMP, IGMP, ARP의 표준 프로토콜에 CP(크래킹ㆍ프로텍트)를 실장하고, 각 프로토콜 스택에 대한 통신으로부터의 공격 및 애플리케이션ㆍ프로그램으로부터의 공격(트로이의 목마, 프로그램의 개찬, 정규 사용자의 부정사용)을 방어할 수 있다. 또, TCP(2)에서는, TCP 에뮬레이터(15)를 실장하고, 이 TCP 에뮬레이터(15)는, 세션층에 있는 소켓(Socket)(17) 및 네트워크층에 있는 IP 에뮬레이터(13)에서 보아, 호환성을 유지하기 때문에, 밖으로 향할 때에는 표준 TCP와 동일하게 보이게 할 수 있다. 실제는, TCP(2)의 기능으로서 TCP와 TCPsec를 바꾸어 실행한다. TCPsec는, 본 발명인 트랜스포트층에서의 암호화 및 인증 기능이다.
또, 동일하게, TCP(2)에서는, UDP 에뮬레이터(16)를 실장하고 있고, UDP 에뮬레이터(16)는, 세션층인 소켓(Socket)(17) 및 네트워크층인 IP 에뮬레이터(13)에서 보아, 호환성을 유지하기 때문에, 외부에서는 표준 UDP로서 보일 수 있다. 실제는, TCP(2)의 기능으로서 UDP, UDPsec를 바꾸어 실행한다. UDPsec는, 본 발명인 트랜스포트층에서의 암호화 및 인증 기능이다.
다음에, TCP(2)에 있어서, 특히 중요한 기능인 「데이터 누설」을 막는 기능인 TCPsec(15b) 및 UDPsec(16b)에 대해 설명한다.　
TCPsec(15b) 및 UDPsec(16b)를 위한 암호화ㆍ복호화의 방법(알고리즘, 논리 회로(논리))으로서는, 공지의 비밀열쇠(공통열쇠) 암호 알고리즘이 이용된다. 예를 들면, 1960년대에 IBM사에 의해서 개발된 비밀열쇠 암호 알고리즘인 DES(Data Encryption Standard)나, 그 개량판으로서의 3DES가 이용된다. 또, 그 외의 암호 알고리즘으로서는, 1992년에 스위스 공과대학의 James L.Massey씨와 Xuejia Lai씨에 의해서 발표된 IDEA(International Data Encryption Algorithm)도 이용된다. 이 암호 알고리즘은, 데이터를 64비트의 블록으로 단락지어서 암호화하는 것으로 암호열쇠의 길이는 128비트이다. 비밀열쇠 암호를 효율적으로 해독하는 선형 해독법이나 차분 해독법에 대해서도 충분한 강도를 가지도록 설계되어 있다.
또, 본 발명에 이용되는 TCPsec(15b) 및 UDPsec(16b)의 암호방식으로서, FEAL(Fast data Encipherment Algorithm), MISTY, AES(Advanced　Encryption Standard)와 같은 암호방식도 이용되는 것 외에, 또, 독자적으로 작성한 비밀의 암호화ㆍ복호화 알고리즘을 이용할 수도 있다. 여기서, FEAL은, 일본 전신전화 주식회사(당시)가 개발한 암호방식으로, 암호화와 복호화에 동일한 열쇠를 사용하는 비밀열쇠형의 암호방식이다. 이 FEAL은, DES에 비해 고속으로 암호화와 복호화가 가능하다고 하는 이점이 있다.
다음에, 동일하게 본 발명에 이용되는 암호방식인 MISTY는, 미츠비시 전기 주식회사가 개발한 비밀열쇠형의 암호방식이며, IDEA와 동일하게 데이터를 64비트의 블록으로 단락지어서 암호화한다. 열쇠의 길이는 128비트이다. 암호화와 복호화에는 동일한 프로그램이 사용되는 점은 DES 등과 같다. 이 방식도 비밀열쇠 암호를 효율적으로 해독하는 선형 해독법이나 차분 해독법에 대해서도 충분한 강도를 가지도록 설계되어 있다.
또, AES는, 미국 상무성 표준 기술국에 의해서 선정(選定) 작업이 실시되고 있는, 미국 정부의 차세대 표준 암호화 방식이며, 현재의 표준적인 암호방식인 DES를 대신하는 차세대의 암호 표준으로서 개발이 진행된 것이다. 세계에 공모하여 모아지는 몇 개인가의 암호방식 중에서, 2000년 10월에, 벨기에의 암호 개발자 Joan Daemen씨와　Vincent Rijmen씨가 개발한 Rijndael이라고 하는 방식이 채용되었다.
이와 같이, 본 발명의 TCPsec(15b) 및 UDPsec(16b)의 암호방식으로서는, 이미 알려져 있는 다양한 비밀열쇠의 암호 알고리즘을 채용할 수 있는 것 외에, 사용자가 독자적으로 개발한 비밀열쇠(공통열쇠) 암호방식도 이용하는 것이 가능하다.
게다가, 이른바 「위장」 및 「데이터의 개찬」 등을 막기 위한 「상대 인증」 및 「완전성 인증」방법으로서, 공개열쇠나 사전 비밀 공유(Pre－Shared)를 이용한 알고리즘, 예를 들면, MD5(Message Digest 5), SHAl(Secure Hash Algorithm 1) 등의 인증 알고리즘이 이용된다. 또, 이러한 공지의 인증 알고리즘을 대신하여 독자적인 한 방향 함수를 이용한 알고리즘을 채용할 수도 있다.
이 MD5는, 인증이나 디지털 서명에 이용되는 해시 함수(한 방향 요약 함수)의 하나이며, 원문을 바탕으로 고정길이의 해시값을 발생하고, 이것을 통신 경로의 양단에서 비교함으로써, 통신 도중에 원문이 개찬되어 있지 않은가를 검출할 수 있는 것이다. 이 해시값은 유사적인 난수와 같은 값을 취하고, 이것을 기본으로 하여 원문을 재생할 수 없게 되어 있다. 또, 동일한 해시값을 생성하는 다른 메시지를 작성하는 것도 곤란하게 되어 있다.
SHAl도, 인증이나 디지털 서명 등에 사용되는 해시 함수의 하나이며, 2의 64승 비트 이하의 원문으로부터 160 비트의 해시값을 생성하고, 통신 경로의 양단에서 비교함으로써, 통신도(通信途)상의 원문의 개찬을 검출하는 것이다. 이 인증 알고리즘은 종래의 인터넷의 암호화 통신의 대표적인 것인 IPsec에도 채용되고 있 다.
또한 이러한 인증 알고리즘에 대해서는, DH(DiffieㆍHellman) 공개열쇠 배송법이나, IPsec와 같은 IKE(Internet Key Exchange) 프로토콜(UDP의 500번) 등에 의해 안전한 열쇠 교환을 할 수 있도록 설계되며, 또한, 정기적으로 암호화／완전성 인증 알고리즘(논리) 자체나 그것을 위한 열쇠의 집합／정의 영역이 변경되도록, 프로토콜 드라이버 프로그램(TCPsec(15b), UDPsec(16b) 등)에 의해 스케줄되고 있다.
다음에, 도 2에 의거하여, 본 발명의 제 1실시형태인　암호화 방식 TCP(2)(특히, TCPsec)를 이용한 암호화 통신에 대해서 설명한다. 도 2는, 특히, EC(Electronic Commerce：전자 상거래) 애플리케이션에 응용한 통신에 적용하는 예이다.
도 2는, 네트워크(20)에 접속된 EC 애플리케이션용의 클라이언트 단말(3a, 3b, 3e)이, 이른바 루터 또는 게이트웨이와 같은 네트워크 제어기기(2)를 통하여 다른 네트워크(30)에 접속된 호스트 컴퓨터(이른바 서버로서 기능하는 통신 장치)에 접속되었을 경우의 전체 구성을 나타내는 도면이다.
네트워크(20)에 접속되는 클라이언트 단말(3a), 클라이언트 단말(3b) 및 클라이언트 단말(3c) 가운데, 클라이언트 단말(3b,　3c)은, 본 발명의 TCP(2)를 실장하고 있지 않다. 즉 클라이언트 단말(3b, 3c)에는, 본 발명의 암호화 방식을 위한 프로토콜인 TCPsec도 UDPsec도 실장되어 있지 않다. TCP(2)를 서포트하고 있는 클라이언트 단말은 3a뿐이다. 그리고, 클라이언트 단말(3b)에 대해서는, 도 시하지 않은 네트워크 폴리시 설정에 의해 통상의 프로토콜 처리에 의한 접속, 즉, TCP 레벨에 대해서는, 「데이터 누설」을 막는 암호화 기능, 「데이터 개찬」을 막는 완전성 인증 기능 및 「위장」을 막는 상대 인증 기능은 수반하지 않는 접속을 실시하도록 하고 있다.
어느 쪽의 클라이언트 단말(3a ~ 3c)에 있어서도, 소켓(socket)의 상층에는, EC용의 응용 프로그램이 실장되어 있다. 또, 네트워크(30)에 접속된 호스트 컴퓨터(1)는, TCP(2)를 탑재하고 있고, 그 소켓(17)의 상층에 EC응용 프로그램(18)이 실장되어 있다. 도 2에서는 UDPsec 등의 사용하지 않은 프로토콜을 생략하고 있지만, 이 호스트 컴퓨터(1)의 프로토콜 스택의 구조는 도 1의 프로토콜 스택의 구조인 TCP(2)를 구성하는 소프트웨어는 모두 탑재되어 있다.
즉, 우선 제 1층(물리층)과 제 2층(데이터 링크층)에 걸쳐 NIC 드라이버(NIC Driver)(11)가 배치되며, 또한 그 상층(제 3층)의 네트워크층에는 ARP(Address Resolution Protocol)(12)와 IP 에뮬레이터(13)가 배치되어 있다.　 그리고, 제 4층의 트랜스포트층에 TCP 에뮬레이터(15)와 UDP(16)가 배치된다. 도 2에 UDP 에뮬레이터(UDPsec와 UDP를 포함한다)의 기재가 없는 것은, 제 1실시형태의 EC 애플리케이션에 대한 암호화 통신으로서는 속도보다도 오류 보상에 중점을 두는 TCPsec가 사용되기 때문이다. 이것은, 호스트 컴퓨터가 UDPsec를 탑재하고 있지 않은 것을 의미하는 것은 아니다. TCP(2)를 탑재하는 것은, 이미 설명한 바와 같이 UDPsec와 TCPsee의 양쪽 모두를 탑재하고 있는 것을 의미하고 있다.
네트워크(20)에 접속된 클라이언트 단말(3a, 3b, 3c)과 네트워크(30)에 접속 되는 호스트 컴퓨터(1)를 개재하는 네트워크 제어기기(2)의 프로토콜 스택은, NIC 드라이버, ARP, IP를 스택으로서 쌓아 올릴 수 있었던 펌웨어(비휘발성 메모리 첨부 전자회로)에 의해 구성되어 있다.
또, 클라이언트 단말(3a)은, 본 발명의 TCP(2)를 서포트하는 단말이지만, 여기에서는 TCPsec에만 대응한 통신 장치를 갖춘 단말로서 프로토콜 스택이 나타나고 있다. 클라이언트 단말(3b, 3c)은 본 발명의 TCP(2)를 서포트하고 있지 않다.
클라이언트 단말(3a)에는, 네트워크를 통해 또는 CD－ROM과 같은 기록 매체를 통하여 사전에 배포되는 프로토콜 드라이버 소프트웨어가 실장되어 있다. 또, 클라이언트 단말(3b), 클라이언트 단말(3c)에 대해서도 동일하게 프로토콜 드라이버 소프트웨어가 사전에 배포되어 실장된다.
특히, 클라이언트 단말(3c)에 대해서는, 종래의 암호화 방식인 IPsec를 실장하고 있지만, 네트워크 제어기기(루터)(2)가 TCP 포트 번호를 참조한 IP 매스커레이드를 실시하고 있기 때문에 IPsec가 유효하게 사용할 수 없게 되어 있다. 또한 클라이언트 단말(3c)에 대해서는, 도시하지 않은 네트워크 폴리시 설정에 의해 접속 요구를 파기하도록 하고 있다. 또한, 이러한 네트워크 폴리시의 설정 내지 프로토콜을 실장하고 있는지의 확인(수신 패킷 해석 등) 자체에 대해서는 당업자에게 주지의 사항이기 때문에, 본 명세서에서는 설명을 생략한다.
호스트 컴퓨터(1)가 클라이언트 단말(3a)과 통신할 때는, 본 발명의 TCP(2), 특히 TCPsec에 의거한 암호화 및 복호화 결정에 의해, 통신을 실시하게 되지만, 호스트 컴퓨터(1)가 클라이언트 단말(3b 또는 3c)과 통신할 때는, 본 발명의 TCP(2)( 특히, TCPsec)에 의한 암호화 및 복호화의 결정이 되지 않는 상태, 즉 통상의 TCP 프로토콜에 의한 통신을 하게 된다. 물론, 호스트 컴퓨터(1)가 IPsec를 서포트하고 있는 클라이언트 단말(3c)과 통신하는 경우에는, IPsec에 의한 암호화 통신을 할 수 있는 것은 당연하다. 또한 호스트 컴퓨터(1)가, TCP(2)가 탑재되어 있지 않은 클라이언트 단말(3b 또는 3c)과 통신하려고 해도 호스트 컴퓨터(1)가 가지는 TCP(2)의 기능으로, 통신을 정지시키는 것도 가능하다.
또, 이 실시형태에서는, 네트워크를 통하여 호스트 컴퓨터(1)와 클라이언트 단말(3a)이 암호화 및 복호화 논리 회로의 교환을 실시하도록 하고 있지만, FD나 CD, UDB 메모리 등의 리모트 미디어를 이용하여 미리 통신 상대끼리 암호화 및 복호화를 위한 결정논리 회로를 교환하여 둘 수도 있는 것은 말할 필요도 없다.
다음에, 도 3에 의거하여, 본 발명의 제 2실시형태인 TCP(2) 중 UDPsec의 암호화 방식을 이용한 암호화 통신에 대해서 설명한다. 도 3은, 네트워크(20)에 접속된 방송 애플리케이션용의 클라이언트 단말(4a, 4b, 4c)이, 이른바 루터 또는 게이트웨이와 같은 네트워크 제어기기(2)를 통하여 다른 네트워크(30)에 접속된 호스트 컴퓨터(이른바 서버로서 기능하는 통신 장치)(1)와 통신하는 통신 시스템의 전체 구성을 나타내는 도면이다.
도 3은, 클라이언트 단말(4a, 4b, 4c) 및 호스트 컴퓨터(1)의 프로토콜 스택을 나타내고 있지만, TCP(2)를 서포트하고 있는 클라이언트 단말은 4a와 4b이다. 즉 단말(4a, 4b)만이 UDPsec를 갖추고 있다. 각 클라이언트 단말의 소켓(socket)의 상층에는, 방송용의 응용 프로그램이 실장되어 있다. 또, 네트워크 (30)에 접속된 호스트 컴퓨터(1)도 TCP(2)를 탑재하고 있고, 그 소켓(17)의 상층에 방송 응용 프로그램(19)이 실장되어 있다. 도 3의 호스트 컴퓨터(1)도 도 2의 호스트 컴퓨터(1)와 동일하게, 도 1의 프로토콜 스택의 구조인 TCP(2)를 구성하는 소프트웨어는 모두 탑재하고 있다.
호스트 컴퓨터(1)가 보유하는 프로토콜 스택은, 도 2의 호스트 컴퓨터(1)의 프로토콜 스택과 대략 동일하지만, 도 2의 호스트 컴퓨터(1)의 프로토콜 스택과 다른 점은, TCP 에뮬레이터 대신에 UDP 에뮬레이터(16)가 있는 점이다. 이것은 방송 애플리케이션 소프트에서는 화상 등의 대량 데이터가 취급되기 때문에, 데이터 전송과 같은 오류 보상보다도, 고속성이 중시되기 때문이다.
네트워크(20)에 접속된 클라이언트 단말(4a, 4b, 4c)과 네트워크(30)에 접속되는 호스트 컴퓨터(1)를 개재하는 네트워크 제어기기(2)의 프로토콜 스택은, NIC 드라이버, ARP, IP를 스택으로서 쌓아 올릴 수 있었던 펌웨어(비휘발성 메모리 첨부 전자회로)에 의해 구성되어 있다.
또, 클라이언트 단말(4a)은, 본 발명의 TCP(2)를 서포트하는 단말이지만, 여기에서는 UDPsec에만 대응한 통신 장치를 갖춘 단말이며, 클라이언트 단말(4b)은, 본 발명의 UDPsec 및 공지의 IPsec에 대응한 통신 장치이며, 클라이언트 단말(4e)은 공지의 IPsec에만 대응한 통신 장치이다. 이 클라이언트 단말(4c)은 본 발명의 TCP(2)를 서포트하고 있지 않다. 이러한 클라이언트 단말(4a ~ 4c)에는, 도 2의 클라이언트 단말(3a ~ 3c)과 동일하게, 네트워크를 통해 또는 CD－ROM과 같은 기록 매체를 통하여 사전에 배포되는 프로토콜 드라이버 소프트웨어가 실장되어 있다.
또, 특히 「데이터 누설」방지를 위한 암호화ㆍ복호화 논리 회로 및 「데이터 개찬」방지를 위한 인증 정보부가ㆍ인증 논리 회로에 대해서는, 호스트 컴퓨터(1)와 클라이언트 단말(4a, 4b, 4c)의 사이에 대응하고 있을 필요가 있다. 공지의 이른바 IPsec와 동일한 폴리시로 결정을 실시할 수도 있지만, 본 발명의 제 2실시형태에 있어서는, 사전에 프로토콜 드라이버 소프트웨어 자체를 배포하고 있으므로, 보다 간결한 독자적인 프로토콜에 의해 비밀열쇠 등을 결정하거나, 보다 간단하고 쉬운 구조의 패킷을 사용하거나 할 수도 있다. 또, 공지의 암호화ㆍ복호화 및 인증 알고리즘이 아니고, 독자적으로 작성한 암호화ㆍ복호화 및 인증 알고리즘(논리) 자체를 프로토콜 드라이버의 소프트웨어 모듈 등으로서 편성할 수도 있다.
또한 클라이언트 단말(4c)은, TCP(2)를 실장하고 있지 않지만, 인터넷에서 이용되는 공지의 IPsec를 실장하고 있기 때문에, 이것에 의해서 어느 정도 안전한 통신을 할 수 있다. 그러나, 클라이언트(4a, 4b)는, 대상으로 하는 방송 애플리케이션의 퍼포먼스 내지 보안 폴리시의 형편상, IPsec가 아닌 본 발명에 의한 TCP(2)의 구성요소인 UDPsee를 실장하여 사용하고 있다. IPsec가 아닌 UDPsec를 이용하는 이유는, 예를 들면, UDP포트 번호 부분(IP페이로드에 속한다)을 IPsec로 암호화하는 것에 의한 퍼포먼스의 저하 등, IPsec자체에 취약함이 있기 때문이다.
또, 통신 상대가 올바른지 아닌지를 판단하는 상대 인증 프로토콜을, 본 발명의 TCP(2)의 TCP 또는 UDP 프로토콜 스택, 즉 TCPsec 또는 UDPsee에 채워 넣음으로써, 통신 상대 상호간에 상위 애플리케이션을 의식하지 않고, 통신 상대 인증 기 능을 실시할 수 있다. 이 경우, 비용 증가가 되지 않는 범위에서 실질적으로 통신 패킷수나 패킷길이 등을 늘릴 수도 있다.
또, 특히, 네트워크 내에서 불특정 다수의 상대를 향해 데이터를 송신하는 브로드캐스트 기능을 실시할 때에, 본 발명에 의한 암호화 방식인 UDPsec를 이용하는 경우에는, 브로드캐스트를 받는 클라이언트 단말(3a, 3b)이 니고시에이션(결정)을 개시하고, 통신 상대 인증이나 통신용 비밀열쇠를 얻는다. 그리고, 클라이언트 단말(3a, 3b)은, 통신 상대의 인증을 실시하여 통신용의 비밀열쇠를 취득할 때까지는, 호스트 컴퓨터(1)로부터의 UDPsec에 의한 전달 데이터를 복호화할 수 없다.
다음에, 도 4에 의거하여, 본 발명의 제 1 및 제 2실시형태의 통신에서 송수신 되는 패킷 구조와, 그 암호화 범위 및 완전성 인증의 적용 범위에 대해서 설명한다.
도 4(a)는 TCPsec／IPsec의 패킷 구조와 각 암호화 범위와 완전성 인증의 적응 범위를 나타내고, 도 4(b)(c)는 각각 TCPsec／IP, UDPsec／IP의 패킷 구조와 각 암호화 범위 및 완전성 인증의 적용 범위를 나타낸 것이다.
도 4(a)에 나타내는 바와 같이, TCPsec／IPsec의 패킷 구조는, IP헤더(41)의 바로 다음에, IPsec의 ESP헤더(42)가 계속되고 있다. 계속해서 TCP헤더(43)와 TCPsec의 부가 정보(44)가 설치되며, 그 후에 애플리케이션 데이터(45)가 계속되는 구조로 되어 있다. 그리고, 애플리케이션 데이터(45)의 다음에는, 블록 암호에서 발생하는 데이터의 블랭크나 그 블랭크의 길이, 다음의 헤더 번호 등의 암호 데 이터를 서포트하는 정보인 TCPsec 부가 트레일러(46)가 배열되며, 그 후에 TCPsec의 부가 인증 데이터(47)가 배열된다. 그리고, 또한 그 후에 IP를 위한 ESP트레일러(48)와 ESP인증 데이터(49)가 배열되는 패킷 구조로 되어 있다.
이 중 번호(41, 42, 48, 49)로 나타나는 부분은 IPsec용의 정보이며, 번호(43, 44, 46, 47)가 본 발명에 의한 TCP(2)의 중심적인 역할을 완수하는 TCPsec에 관련되는 정보이다. 또한 여기에서는 TCPsec도 IPsec에 준한 배열로 했지만, 채용하는 암호화나 인증의 알고리즘에 따라서는, TCPsec의 부가 정보(44)와 부가 트레일러(46)를 생략하거나, TCPsec의 부가 인증 데이터(47)를 삭감하거나 해도 이용 가능하다.
도 4(a)에 나타내는 TCP(2)의 패킷 구조에 있어서는, TCPsee와 IPsec의 2개의 방식으로 암호화를 한다. 이 경우, 우선 송신측에서는, TCPsec측을 최초로 암호화하여, TCPsec 인증 데이터를 부가한다. 다음에, IPsec를 암호화하고, IPsec 인증 데이터를 부가하고 있다. 그리고, 수신측에서는, 우선, IPsec를 복호화하여, IPsec 인증 데이터에 의해 수신 패킷의 데이터를 검증하고, 계속해서 TCPsec측을 복호화하여, TCPsec 인증 데이터에서 수신 패킷의 데이터를 검증한다.
이와 같이, 도 4(a)에 나타내는 패킷 구조를 가지는 데이터에서는, IPsec와 TCPsec의 2종류의 암호 알고리즘을 이용하여 암호화하고, 한층 더 완전성 인증을 실시하므로, IPsec만으로 비교해서 외부로부터의 침입 등에 대해서 현격히 강고한 암호화 통신 시스템을 확립할 수 있다. TCPsec에 의해 암호화되는 범위는, 애플리케이션 데이터(45), TCPsec 부가 트레일러(46)의 부분이며, TCPsec에 의한 인증 범위로서는 상기 암호화 범위에 한층 더 TCPsec 부가 정보(44)가 더해진다. 또한 종래의 IPsec에서 암호화되는 암호화 범위는, TCP헤더(43)에서 ESP트레일러(48)까지의 부분이며, 그 인증 범위는, ESP헤더(42)에서 ESP트레일러(48)까지의 범위가 된다.
도 4(b)는, TCPsec／IP의 패킷 구조를 나타내고 있고, 도 4(a)와 달리, IP헤더(41)의 바로 다음에, TCP헤더(43) 및 TCPsec 부가 정보(44)가 이어지며, 더욱 애플리케이션 데이터(45)가 계속되는 구조로 되어 있다. 그리고, 애플리케이션 데이터(45)의 다음에는, 블록 암호에서 발생하는 데이터의 블랭크나 그 블랭크의 길이, 다음의 헤더 번호 등의 암호 데이터를 서포트하는 정보인 TCPsec의 부가 트레일러(46)와 TCPsec의 부가 인증 데이터(47)가 배열되는 구조로 되어 있다.
여기서, 번호(43, 44, 46, 47)가 TCPsec에 특징적인 정보가 된다. 다만, 상술한 바와 같이 이러한 정보는, 채용하는 암호화／인증 알고리즘에 따라서는, TCPsec／IP의 사용하고 있지 않은 헤더 필드 부분 등에 분산하거나, 개개의 패킷으로부터는 역산ㆍ추측할 수 없는 독립된 사전 결정(니고시에이션)에 의해 생략하거나 할 수 있는 것이다. 또, IP층의 상층에 해당되는 TCP 및 IP를 사용하고 있지 않은 프로토콜 필드를 이용하여, 도 4(b)에 나타내는 TCPsec／IP 패킷을 구성함으로써, 보다 하층의 IP에만 주목한 IPsec 패킷보다 패킷길이를 간단하게 삭감할 수 있게 된다. 또한 여기서 암호화 범위는, 도시한 대로, 애플리케이션 데이터(45), TCPsec 부가 트레일러(46)이며, 인증 범위는 상기 암호화 범위 외에, TCPsec의 부가 정보(44)가 더해진다.
도 4(c)는, 본 발명에 있어서의 UDPsec／IP의 패킷 구조를 나타내는 것이며, UDPsec 부가 정보(44a), UDPsec 부가 트레일러(46a) 및 UDPsee 부가 인증 데이터(47a)가 UDPsec를 서포트하기 위해서 필요한 정보가 된다. 이 암호화 범위는, 도시한 대로, 애플리케이션 데이터(45a), UDPsec 부가 트레일러(46a)이며, 인증 범위는 상기 암호화 범위 외에, UDPsec 부가 정보(44a)가 더해진다.
다음에, 본 발명의 제 1실시형태인 TCPsec를 이용한 암호화 처리 시스템의 동작을 도 5 ~ 도 6, 도 8 ~ 도 14에 나타내는 흐름도 및 도 7에 나타내는 순서도에 의거하여 설명한다.
도 5는, TCP 및 TCPsec의 패시브 오픈(도 7의 호스트(B)에 상당하는 접속 대기의 오픈이며, 예를 들면, Web 서버가, 이 상태로 오픈한다.)에 있어서의 처리의 흐름도이며, 상위 애플리케이션ㆍ프로그램에서, 접속 대기 오픈했을 경우에, 이 TCP／TCPsec 패시브 오픈 처리가 시작된다(스텝(Sl)). 또한 이 부분은, 도 7로 말하면 호스트(B) 측의 처리가 이것에 상당한다.
우선, 최초로, 오픈하는 포트 번호의 해석이 실시된다(스텝(S2)). 이 해석에서는, 예를 들면, Web서버의 경우는, TCP 포트의 80번을 사용하여, 그 정의 상태를 확인한다. 그리고 다음에 이 포트 번호(80)가, TCPsec의 패시브 오픈이 허가되고 있는지 어떤지를 판정한다(스텝(S3)). 스텝(S3)에 있어서 TCPsec의 패시브 오픈이 허가되고 있지 않은 경우는, 이번에는 TCP 패시브 오픈이 허가되고 있는지 어떤지가 판단된다(스텝(S4)). 판단 스텝(S4)에서 TCP 패시브 오픈도 허가되고 있지 않은 경우는, TCPsec도 TCP도 허가되고 있지 않게 되며, TCP／TCPsec 패시 브 오픈은 실패가 되고, 처리를 중단한다(스텝(S7)).
판단 스텝(S4)에서 TCP 패시브 오픈이 허가되고 있는 경우, 즉 TCPsec 패시브 오픈은 허가되고 있지 않지만 TCP 패시브 오픈은 허가되고 있을 때는, 후술하는 도 8에 나타내는 TCP 패시브 오픈 처리가 실행된다(스텝(S5)).
판단 스텝(S3)에서, TCPsec의 패시브 오픈의 허가 상태가 확인되었을 경우는, 동일하게 후술하는 도 9에 나타내는 TCPsec의 패시브 오픈 처리가 실행된다(스텝(S6)). 스텝(S5) 또는 스텝(S6)에 있어서의 TCP 패시브 오픈 처리 또는 TCPsec의 패시브 오픈 처리가 종료하면 TCP／TCPsec패시브 오픈 처리를 종료한다(스텝(S7)). 이와 같이, 본 예에서는, 상위인 애플리케이션으로부터는, TCP에서 패시브 오픈을 실시하고 있지만, TCP(2)의 판단에 의해, TCPsec가 서포트되고 있으면 TCPsec로 통신을 실시하고, TCPsec가 서포트되고 있지 않으면 TCP에서 통신하게 된다.
다음에, 도 6에 의거하여 본 발명의 TCP 및 TCPsec의 액티브 오픈 처리에 대해서 설명한다. TCP／TCPsec의 액티브 오픈이란, 접속 요구의 오픈이며, 예를 들면, Web브라우저를 실장하는 클라이언트 단말이, 이 상태로 오픈하게 된다. 도 7로 말하면 호스트(A) 측의 처리가 이것에 상당한다. 도 6은, 이 액티브 오픈에 있어서의 처리의 흐름도이며, 상위 애플리케이션ㆍ프로그램에 대해서 접속 요구 오픈이 이루어졌을 경우에, 이 TCP／TCPsec의 액티브 오픈 처리가 개시된다(스텝(S8)).
우선, 최초로, 오픈하는 포트 번호의 해석이 이루어진다(스텝(S9)). 이 해석은, 예를 들면, Web브라우저를 실장하는 클라이언트 단말 애플리케이션이, TCP 포트의 3000번을 사용하려고 했을 경우는, TCP 포트의 3000번의 정의 상태를 확인한다.
다음에 이 포트 번호(3000)에 대해서 TCPsec의 액티브 오픈이 허가되고 있는지 어떤지가 판단된다(스텝(SlO)). 스텝(SlO)에 있어서 TCPsec의 액티브 오픈이 허가되고 있지 않다고 판정되었을 경우는, 계속해서 TCP 액티브 오픈이 허가되고 있는지 어떤지가 판단된다(스텝(Sll)). 판단 스텝(Sll)에서 TCP 액티브 오픈도 허가되고 있지 않은 경우는, TCPsec, TCP의 어느 액티브 오픈도 허가되고 있지 않게 되며, TCP／TCPsec 액티브는 실패가 되고, 접속 처리는 중단된다(스텝(S14)).
판단 스텝(Sll)에서 TCP 액티브 오픈이 허가되고 있는 경우, 즉 TCPsec 액티브 오픈은 허가되고 있지 않지만 TCP 액티브 오픈은 허가되고 있을 때는, 후술하는 도 10에 나타내는 TCP 액티브 오픈 처리가 실행된다(스텝(S12)).
판단 스텝(SlO)에서, TCPsec의 액티브 오픈의 허가 상태가 확인되었을 경우는, 후술하는 도 11에 나타내는 TCPsec의 액티브 오픈 처리가 실행된다(스텝(S13)). 스텝(S12) 또는 스텝(S13)에 있어서의 TCPsec 액티브 오픈 처리 또는 TCPsec의 액티브 오픈 처리가 종료하면 TCP／TCPsec 액티브 오픈 처리가 끝난다(스텝(S14)). TCP／TCPsec 액티브 오픈의 경우도, TCP／TCPsec 패시브 오픈(도 5)의 경우와 동일하게, 상위인 애플리케이션으로부터는, TCP에서 액티브 오픈을 실시하고 있지만, TCP(2)의 판단에 의해, TCPsec가 서포트되고 있으면 TCPsec로 통신을 실시하고, TCPsec가 서포트되고 있지 않으면 TCP에서 통신하게 된다.
다음에, 도 7에 의거하여 액티브 오픈 측의 호스트(A)와 패시브 오픈 측의 호스트(B)간의 순서 처리에 대해서, 본 발명의 TCPsec를 사용한 통신의 처리를 설명한다.
도 7은, 본 발명의 암호 처리 프로토콜인 TCPsec를 이용했을 때의 접속 순서, 데이터 통신 순서 및 절단 순서를, 표준의 TCP와 비교하여 나타낸 것이다. 도 7(a)은 표준 TCP, 도 7(b)은 본 발명의 TCPsec를 이용했을 때의 통신의 순서를 나타낸 도면이다.
도 7(a)에 나타내는 바와 같이, 표준의 TCP는, 호스트(B)의 애플리케이션이 TCP 패시브 오픈하고, 호스트(A)의 애플리케이션이 TCP 액티브 오픈하고 있다.
호스트(B)의 애플리케이션이 TCP 패시브 오픈을 하면, TCP 패시브 오픈 처리(도 5의 스텝 5 및 도 8 참조)를 개시하고, 후술하는 도 8의 스텝(S15)에 나타내는 바와 같이 수신대기가 된다. 호스트(A)의 애플리케이션이 TCP 액티브 오픈을 하면, TCP 액티브 오픈 처리(도 6의 스텝(S12) 및 도 10 참조)를 개시하고, 후술하는 도 10의 스텝(S52)에 나타내는 바와 같이 호스트(A)로부터 호스트(B)에 대해서 접속 요구(SYN)가 송신된다. 이것에 의해, 표준 TCP의 접속 순서가 개시 상태가 된다.
호스트(B) 측에서는, 이 접속 요구(SYN)를 수신하면 이 접속 요구의 수신 패킷의 해석을 종료하고, 호스트(A) 측에 접속 응답(SYNㆍACK)을 송신한다. 여기서 ACK란, Acknowledgement의 약어이며, 데이터 전송이 정상적으로 종료했을 때 등에 송신되는 것이다. 호스트(A) 측은, 이 접속 응답(SYNㆍACK)을 수신하면, 접 속이 완료한 취지의 ACK(긍정 응답)를 송신하고, 표준 TCP의 접속 순서를 종료한다.
이 표준 TCP의 접속 순서를 종료하면, 표준 TCP에 의한 데이터 통신 순서가 유효가 되며, 호스트(A) 측, 또는, 호스트(B) 측의 어느 쪽인가가 데이터를 송신 후, 데이터를 수신한 측으로부터 ACK(긍정 응답)를 돌려준다고 하는 기본 패턴을 반복하여 데이터의 송수신을 한다.
이 표준 TCP의 데이터 통신 순서에서는, 호스트(A) 또는 호스트(B)의 어느 쪽인가가, 상대에 대해서 절단요구를 할 수 있다.
도 7(a)에서는, 액티브 오픈 측의 호스트(A)로부터 패시브 오픈 측의 호스트(B)에 대해서 절단요구가 송신되었을 경우를 나타내고 있다. 호스트(A)의 애플리케이션으로부터 절단요구가 있으면, 호스트(A)는, 절단요구(FIN)를 송신한다. 호스트(B)는, 이 절단요구(FIN)를 수신하면, 후술하는 도 8의 스텝(S23)에 나타내는 바와 같이 절단응답(FINㆍACK)을 송신한다. 호스트(A)는, 이 절단응답(FINㆍACK)을 수신하면, ACK(긍정 응답)를 송신하고, 표준 TCP의 절단 순서를 종료한다.
다음에, 본 발명의 TCPsec에 의한 통신의 순서를 도 7(b)에 의거하여 설명한다. 도 7(b)에서는, 호스트(B)의 애플리케이션이 TCPsec 패시브 오픈하고, 호스트(A)의 애플리케이션이 TCPsec 액티브 오픈하고 있다.
호스트(B)의 애플리케이션이 TCPsec 패시브 오픈을 하면, TCPsec 패시브 오픈 처리(도 5의 스텝(S6) 및 도 9를 참조)를 개시하고, 후술하는 도 9의 스텝(S31)에 나타내는 바와 같이 수신 대기가 된다. 호스트(A)의 애플리케이션이 TCPsec 액티브 오픈을 하면, TCPsec 액티브 오픈 처리(도 6의 스텝(S13) 및 도 11을 참조)를 개시하고, 도 11의 스텝(S69)에 나타내는 바와 같이 호스트(A)로부터 호스트(B)에 대해서 접속 요구(SYN)가 송신된다. 이것에 의해, TCPsec의 접속 순서가 개시 상태가 된다. 또한 접속 요구(SYN)에는, 옵션으로, TCP(2)의 고유 정보를 암호화하여 부가하고, 올바른 상대인 것을 상대에게 통지하도록 하고 있다. 즉, 호스트(A)와 호스트(B)의 사이에 다음의 TCPsec 니고시에이션 데이터를 교환하기 이전에 상대방 단말이 TCP(2)를 서포트하는 단말인지 아닌지, 바꾸어 말하면 통신하는 올바른 상대인지의 여부를 확인할 수 있다.
호스트(B) 측에서는, 호스트(A)로부터 송신된 접속 요구(SYN)를 수신하면, 올바른 상대라면, 호스트(A)에 대해서 접속 응답(SYNㆍACK)을 송신한다. 그리고, 호스트(A) 측은, 이 호스트(B)로부터의 접속 응답(SYNㆍACK)을 수신하면 ACK(긍정 응답)를 송신한다. 계속해서 호스트(A)와 호스트(B)의 사이에 TCPsec 니고시에이션 데이터를 교환하고, 올바른 상대라면, TCPsec의 접속 순서를 종료한다.
이 접속 순서가 종료하면, TCPsec의 데이터 통신 순서가 유효가 되며, 호스트(A) 측 또는 호스트(B) 측의 어느 쪽인가가 데이터를 송신 후, 데이터를 수신한 측으로부터 ACK(긍정 응답)를 돌려주는 기본 패턴을 반복하여 데이터의 송수신을 한다. 또한 이 데이터는, 모두 암호 데이터인 것은 말할 필요도 없다.
또한, TCPsec의 데이터 통신 순서에서는, 호스트(A) 또는 호스트(B)의 어느 쪽인가가 상대방에 대해서 절단요구를 할 수 있다. 도 7(b)에서는, 액티브 오픈 측의 호스트(A)로부터 절단을 개시하고 있다. 호스트(A)의 애플리케이션으로부 터 절단요구가 있으면, 호스트(A)는 절단요구(FIN)를 송신한다. 이 절단요구(FIN)에는, 옵션으로, TCP(2)의 고유 정보를 암호화하여 부가하고, 올바른 상대인 것을 상대에게 통지할 수 있는 것이다. 호스트(B)는, 이 절단요구(FIN)를 수신하면, 올바른 상대라면, 후술하는 도 9의 스텝(S42)에 나타내는 바와 같이 절단응답(FINㆍACK)을 송신한다. 호스트(A)는, 이 절단응답(FINㆍACK)을 수신하면, ACK(긍정 응답)를 송신하고, TCPsec의 절단 순서를 종료한다.
이상, 도 7에 의거하여, 표준 TCP와 본 발명의 TCP(2)의 하나인 TCPsec에 대해서 통신의 접속에서 절단까지의 순서를 설명했지만, 이하, TCP 및 TCPsec의 패시브 오픈 처리 및 액티브 오픈 처리에 대해서 흐름도에 따라 순서대로 설명한다.
우선, 도 5의 흐름도의 스텝(S5)에 있어서, TCP 패시브 오픈 처리가 시작됐을 경우의 상세에 대해서 도 8의 흐름도에 의거하여 설명한다.
도 5의 스텝(S5)에서 처리하는 프로토콜이 TCP로 결정했을 경우에, 이 도 8의 TCP 패시브 오픈 처리가 시작된다. 최초로, 수신 대기를 하여, 수신한 수신 패킷의 해석을 실시한다(스텝(S15)). 계속해서 이 수신한 패킷이 올바른 패킷인지 아닌지, 즉 DoS 공격에 있어서의 TCP 프로토콜 공격패턴인지 아닌지를 판단한다(스텝(S16)). 그리고 스텝(S16)의 판단의 결과, 부정 패킷이라고 판정되었을 경우에는 그 수신 패킷을 폐기하고(스텝 S17), 다음 패킷의 수신을 기다린다.
판단 스텝(S16)에 있어서, 수신 패킷이 올바른 TCP 패킷이라고 판단되었을 경우는, 계속해서 접속중인지 아닌지, 즉 도 7의 호스트(A)와 호스트(B)의 접속 순서가 완료되어 있는지 어떤지가 판단된다(스텝(S18)). 판단 스텝(S18)에 있어 서, 접속중이라고 판정되었을 경우는, 다음에 패킷이 절단요구(도 7(a)의 FIN)인지 아닌지가 판단된다(스텝(S19)). 절단요구가 아니면, 계속해서 절단응답(도 7(a)의 FIN／ACK)인지 아닌지가 판단된다(스텝(S2)0). 절단요구도 아니고, 절단응답도 아닌 경우에는, TCP 데이터의 송수신 처리를 하고(스텝(S21)), 수신 패킷이 절단응답인 경우는, 도 7의 호스트(A)로부터 ACK가 송신되어 TCP 접속이 절단된다(스텝(S25)). 판단 스텝(S19)에서 호스트(A)로부터의 절단요구라고 판단되면, 이것에 대한 절단응답이 호스트(B)로부터 송신된다(스텝(S23)).
스텝(S23)에서 절단응답이 송신되었을 경우에는, 최종의 ACK를 기다린다(스텝(S24)). 그리고, 최종 ACK를 수신한 후에 TCP를 절단상태로 하고(스텝(S25)), TCP 패시브 오픈을 종료한다(스텝(S26)).
판단 스텝(S18)에 있어서, 수신 포트가 접속중이 아니라고 여겨졌을 경우에는, 수신한 패킷이 패시브 오픈 허가 포트인지 아닌지가 판정된다(스텝(S27)). 그리고 수신 패킷이 허가되고 있지 않은 경우는, 수신 패킷을 폐기하여(스텝(S28)) 다음의 패킷을 기다린다. 또, 판단 스텝(S27)에 있어서, 수신 패킷이 패시브 오픈 허가가 되어 있다고 여겨진 경우는, 다음에 패킷이 접속 요구인지 아닌지가 판단되며(스텝(S29)), 접속 요구가 아닌 경우는, 패킷을 폐기하여(스텝(S28)) 다음의 패킷을 기다린다. 또, 판단 스텝(S29)에서 접속 요구라고 판단되었을 경우에는, 접속 응답을 송신하고, TCP를 접속 상태로 한다(스텝(S30)).
다음에, 도 5의 TCPsec의 패시브 오픈에 있어서의 처리 스텝(S6)의 상세에 대해서, 도 9의 흐름도에 의거하여 설명한다.
이 처리는, 도 5의 스텝(S6)에 나타나는 바와 같이, 수신 패킷의 처리가 TCPsec의 처리라고 결정되었을 경우의 처리이다. 최초로, 수신 대기를 하여, 수신한 수신 패킷의 해석이 이루어진다(스텝(S31)). 계속해서 이 수신한 패킷이 올바른 패킷인지 아닌지, 즉 DoS 공격에 있어서의 TCP 프로토콜 공격 패턴이 아닌지 어떤지가 판단된다(스텝(S32)). 이 스텝(S32)의 판단의 결과, 부정 패킷이라고 판정되었을 경우에는 그 수신 패킷을 폐기하고(스텝(S33)), 스텝(S31)으로 돌아오고, 다음 패킷의 수신을 기다린다.
판단 스텝(S32)에 있어서, 수신 패킷이 올바른 패킷이라고 판단되었을 경우는, 계속해서 호스트(A)와 호스트(B)의 접속이 완료하고 있는지(접속중인지 어떤지)가 판단된다(스텝(S34)). 판단 스텝(S34)에 있어서, 호스트(A)와 호스트(B)가 접속중이라고 판정되었을 경우는, 다음에 수신한 패킷이 절단요구(FIN)인지 아닌지가 판단된다(스텝(S35)). 절단요구가 아니면, 이번은 수신한 패킷이 절단응답(FINㆍACK)인지 아닌지가 판단된다(스텝(S36)). 그리고, 수신한 패킷이 절단요구도 아니고, 절단응답도 아니라고 하는 것이면, 후술하는 도 12에 나타나는 TCPsec 데이터의 송수신 처리가 실시되고(스텝(S37)), 스텝(S49)으로 진행된다. 다음에, 판단 스텝(S36)에서 절단응답이 있었을 경우에는, 절단열쇠가 일치하고 있는지 어떤지가 판단된다(스텝(S38)). 여기서, 절단열쇠란 호스트(A)와 호스트(B) 사이에 도 7의 접속 순서에 있어서의 니고시에이션에 있어서 교환한 공통열쇠(비밀열쇠)이며, 이 열쇠가 일치했을 때만 양자 사이의 통신을 절단할 수 있는 것이다. 판단 스텝(S38)에서 절단열쇠가 일치했을 경우에는, ACK를 송신하여(스텝(S39)), 호스트(A)와 호스트(B)간의 TCPsee를 절단한다(스텝(S44)). 판단 스텝(S38)에서 절단열쇠가 일치하지 않았던 경우에는, 부정 패킷으로서 패킷을 폐기하고(스텝(S41)), 다음의 수신 패킷을 기다린다. 또, 판단 스텝(S35)에 있어서, 수신 패킷이 절단요구(FIN)라고 판단되었을 경우도, 절단열쇠가 일치하고 있는지 아닌지가 판단된다(스텝(S40). 그리고, 절단열쇠가 일치하지 않는 경우는, 수신 패킷이 부정한 패킷으로서 폐기되며(스텝(S41)), 절단열쇠가 일치했을 경우는, 절단응답(FINㆍACK)의 송신을 한다(스텝(S42)). 스텝(S42)에서 절단응답이 송신되었을 경우에는, 상대방으로부터의 최종의 ACK를 기다리고(스텝(S43)), 이 최종 ACK를 수신하면 TCPsec를 절단상태로 하여(스텝(S44)), TCPsec 패시브 오픈을 종료한다(스텝(S45)).
판단 스텝(S34)에 있어서, 호스트(A)와 호스트(B)가 접속중이 아니라고 판단되었을 경우에는, 수신한 패킷이 패시브 오픈의 허가 포트인지 아닌지가 판단된다(스텝(S46)). 그리고 수신 패킷이 패시브 오픈의 허가 포트가 아닌 경우는, 수신 패킷을 폐기하여(스텝(S47)), 스텝(S31)으로 돌아와 다음의 패킷을 기다린다. 또, 판단 스텝(S46)에 있어서, 수신 패킷이 패시브 오픈 허가 포트가 되어 있다고 여겨졌을 경우는, 후술하는 도 13에 나타내는 TPCsec 패시브 접속 처리가 실행된다(스텝(S48)).
이어서, 공통열쇠와 인증 데이터에 의거하여 통신상대가 정상, 즉 정당한 권한을 가진 상대인지 아닌지가 판단된다(스텝(S49)). 정상적인 상대라고 판단되면, 스텝(S31)으로 돌아오고, 다음의 수신 패킷을 기다리지만, 통신상대가 정상의 상대가 아니라고 판단되면, TPCsec의 접속을 강제 절단하고(스텝(S50)), TCPsec의 패시브 오픈의 처리를 종료한다(스텝(S51)).
다음에, 도 6의 스텝(S12)에 나타내는, TCP 액티브 오픈의 처리에 대해서 도 10의 흐름도에 의거하여 설명한다.
도 10은, 도 6에 있어서의 처리하는 프로토콜이 TCP라고 결정했을 경우의 처리를 나타내는 도면이며, 최초로, 송신측 호스트(A)로부터 수신측 호스트(B)에 대해서 접속 요구(SYN)가 송신된다(스텝(S52)). 이 접속 요구에 대해서 수신측 호스트(B)로부터 접속 응답(SYNㆍACK)이 송신되면, 다음에 수신 대기를 하고, 수신한 패킷의 해석을 한다(스텝(S53)). 다음에, 이 수신한 패킷이 올바른 패킷인지 아닌지, 즉 DoS 공격에 있어서의 TCP 프로토콜 공격 패턴이 아닌지 어떤지를 판단한다(스텝(S54)). 이 스텝(S54)에 있어서의 판단의 결과, 부정 패킷이라고 판정되었을 경우에는 그 수신 패킷을 폐기하고(스텝(S55)), 스텝(S53)으로 돌아오고, 다음 패킷의 수신을 기다린다.
판단 스텝(S54)에 있어서, 수신 패킷이 올바른 패킷이라고 판단되었을 경우는, 계속해서 송신측(액티브측) 호스트(A)와 수신측(패시브측) 호스트(B)가, 접속중인지 어떤지가 판단된다(스텝(S56)). 이 판단 스텝(S56)에 있어서, 접속중이라고 판정되었을 경우는, 다음에 수신 패킷이 송신측 호스트(A)로부터 수신측 호스트(B)에 대한 절단요구인지 아닌지가 판단된다(스텝(S57)). 이것이 절단요구가 아니면, 이번은 수신측 호스트(B)로부터 송신측 호스트(A)에 대한 절단응답(FINㆍACK)인지 아닌지가 판단된다(스텝(S58)). 절단요구도 아니고 절단응답도 아니라고 하는 것이 되면, TCP 데이터의 송수신 처리가 실시되고(스텝(S59)), 다음의 수신 패킷을 기다린다. 판단 스텝(S58)에서 호스트(B)로부터 호스트(A)로의 절단응답이라고 판단되면, 호스트(A)는 절단을 긍정하는 ACK를 송신하고(스텝(S60)), TCP를 절단한다(스텝(S63)).
판단 스텝(S57)에 있어서, 수신한 패킷이 절단요구인 경우는, 호스트(B)로부터 호스트(A)에 대해서 절단응답이 송신되며(스텝(S61)), 호스트(B)는 호스트(A)로부터의 최종의 ACK의 수신을 기다린다(스텝(S62)). 그리고, 호스트(B)가 호스트(A)로부터 최종 ACK를 수신한 후에 TCP를 절단상태로 하여(스텝(S63)), TCP 액티브 오픈을 종료한다(스텝(S64)).
판단 스텝(S56)에 있어서, 송신측 호스트(A)와 수신측 호스트(B)가 접속중이 아니라고 여겨졌을 경우에는, 수신한 패킷이 액티브 오픈 허가 포트인지 아닌지가 판정된다(스텝(S65)). 그리고 수신 패킷이 허가되고 있지 않은 경우는, 수신 패킷을 폐기하여(스텝(S66)) 다음의 패킷을 기다린다. 또, 판단 스텝(S65)에 있어서, 수신 패킷이 액티브 오픈 허가가 되어 있다고 여겨졌을 경우는, 다음에 수신측 호스트(B)로부터의 접속 응답이 있었는지 아닌지가 판단되며(스텝(S67)), 접속 응답이 없으면, 패킷을 폐기하여(스텝(S66)) 다음의 패킷을 기다리고, 수신측 호스트(B)로부터 접속 응답이 이루어졌을 경우에는, TCP의 접속 상태로서(스텝(S68)), 스텝(S53)으로 돌아오고, 다음의 수신 패킷을 기다린다.
다음에, 도 6의 스텝(S13)의 TCPsec 액티브 오픈이 개시되었을 경우의 상세한 처리에 대해서 도 11의 흐름도에 의거하여 설명한다.
도 11의 흐름도에 나타내는 처리는, 도 6의 스텝(S13)에서 처리하는 프로토콜이 TCPsec라고 결정했을 경우에 개시되는 것이다. 최초로, 송신측 호스트(A)로부터 수신측 호스트(B)에 대해서 접속 요구(SYN)가 송신된다(스텝(S69)). 이것에 대해서, 수신측 호스트(B)로부터 접속 응답(SYNㆍACK)이 있어서 패킷의 수신이 개시되며, 수신한 패킷의 해석을 한다(스텝(S70)).
다음에, 수신 패킷의 해석의 결과, 수신한 패킷이 올바른 TCP의 패킷인지 아닌지, 즉, DoS 공격에 있어서의 TCP 프로토콜 공격 패턴이 아닌지의 여부가 판단된다(스텝(S71)). 이 결과, 부정 패킷이라고 판정되었을 경우에는, 그 패킷을 폐기(스텝(S72))하고, 스텝(S70)으로 돌아와 다음의 패킷을 기다린다.
판단 스텝(S71)에 있어서, 수신한 패킷이 올바른 TCP 패킷이라고 판정되었을 경우는, 다음에 송신측 호스트(A)와 수신측 호스트(B)의 접속이 완료되어 있는지 어떤지(접속중인지 어떤지)가 판단된다(스텝(S73)). 그리고 호스트(A)와 호스트(B)가 접속중이면, 이번은 수신한 패킷이 절단요구(FIN)인지 아닌지가 판단된다(스텝(S74)). 수신한 패킷이 절단요구가 아닐 때는, 다음에 수신측 호스트(B)로부터 절단응답이 있을지 어떨지가 판단된다(스텝(S75)). 절단요구도 없고 절단응답도 없는 경우는, 도 12에 나타내는 TCPsec 데이터의 송수신 처리가 실시되고(스텝 76), 그 후 스텝(S89)으로 진행된다.
판단 스텝(S75)에서 절단응답이 있었을 경우에는, 절단열쇠가 일치하고 있는지가 판단된다(스텝(S77)). 이 절단열쇠에 대해서는 도 9에 있어서 설명했던 대로이다. 판단 스텝(S77)에서 절단열쇠가 일치했을 경우에는, 송신측 호스트(A)로부터 수신측 호스트(B)에 대해서 ACK를 송신하여(스텝(S78)), 호스트(A)와 호스트(B)간의 TCPsec를 절단한다(스텝(S83)). 판단 스텝(S77)에서 절단열쇠가 일치하지 않았던 경우에는, 부정 패킷으로서 패킷을 폐기하고(스텝(S80)), 다음의 수신 패킷을 기다린다. 또, 판단 스텝(S74)에 있어서, 수신 패킷이 절단요구(FIN)라고 판단되었을 경우도, 절단열쇠가 일치하고 있는지 아닌지가 판단된다(스텝(S79)). 그리고, 절단열쇠가 일치하지 않는 경우는, 수신 패킷이 부정한 패킷으로서 폐기되며(스텝(S80)), 절단열쇠가 일치했을 경우는, 절단응답(FINㆍACK)의 송신을 한다(스텝(S81)). 스텝(S81)에서 절단응답이 송신되었을 경우에는, 상대방으로부터의 최종의 ACK를 기다리고(스텝(S82)), 이 최종 ACK를 수신하면 TCPsec를 절단상태로 하여(스텝(S83)), TCPsec 액티브 오픈을 종료한다(스텝(S84)).
판단 스텝(S73)에 있어서, 송신측 호스트(A)와 수신측 호스트(B)의 접속이 완료되어 있지 않은, 즉 접속중이 아니라고 여겨졌을 경우에는, 수신한 패킷이 액티브 오픈 허가 포트인지 아닌지가 판정된다(스텝(S85)). 그리고 수신된 패킷이 허가되고 있지 않은 경우는, 그 수신 패킷을 폐기하여(스텝(S87)) 스텝(S70)으로 돌아오고, 다음의 패킷을 기다린다. 또, 판단 스텝(S85)에 있어서, 수신 패킷이 액티브 오픈 허가가 되어 있다고 여겨졌을 경우는, 수신되는 패킷이 수신측 호스트(B)로부터의 접속 응답(SYNㆍACK)의 패킷인지 아닌지가 판단되며(스텝(S86)), 접속 응답의 패킷이 아닌 경우는, 패킷을 폐기하여(스텝(S87)) 다음의 패킷을 기다리고, 판단 스텝(S86)에서 접속 응답의 패킷이라고 판단되었을 경우에는, 도 14에서 그 상세를 나타내는 TCPsec 액티브 접속 처리를 한다(스텝(S88)).
스텝(S88)에서 TCPsec의 액티브 접속 처리가 이루어지면, 다음에 수신측의 호스트(B)가 정상적인 상대인가 아닌가, 즉 접속이 허가되고 있는 상대인지 아닌지가 판단된다(스텝(S89)). 그리고, 접속이 허가되고 있는 상대라고 판단되면, 스텝(S70)으로 돌아와 다음 패킷의 수신을 기다리고, 스텝(S89)으로 접속이 허가되고 있지 않은 상대라고 판단되면, TCPsec에 의한 송수신을 강제적으로 절단하여(스텝(S90)), TCPsec의 액티브 오픈을 종료한다(스텝(S91)).
다음에, 상술한 도 9 스텝(S37) 및 도 11의 스텝(S76)이 선택되었을 경우의 TCPsec 데이터의 송수신 처리의 상세에 대해서 도 12의 흐름도에 의거하여 설명한다.
우선, 도 9의 스텝(S37) 및 도 11의 스텝(S76)에서 TCPsec 데이터의 송수신 처리가 개시되면, 최초로, 호스트(A)의 상위 애플리케이션으로부터의 송신 요구가 있는지 없는지가 판단된다(스텝(S92)). 그리고, 호스트(A)의 상위 애플리케이션으로부터 송신 요구가 있었던 경우는, 송신측 호스트(A)에서 송신 데이터가 암호화되며(스텝(S93)), 또한 인증 데이터가 부가되어서(스텝(S94)), 수신측 호스트(B)에 암호화되어 인증 데이터가 부가된 패킷이 송신된다(스텝(S95)).
다음에, 수신측 호스트(B)에서, 수신 데이터가 있는지 없는지가 판단되며(스텝(S96)), 수신 데이터가 있는 경우에는, 수신 데이터의 복호화를 한다(스텝(S97)). 다음에, 이 수신되어 복호화된 데이터가 올바른 데이터인지가 판단된다(스텝(S98)). 이 판단은, 복호화한 데이터와 수신된 인증 데이터를 확인하는 것에 의해서 행해지지만, 복호 데이터를 확인한 결과, 올바른 데이터가 아니라고 판 정되었을 경우에는, TCP／TCPsec를 강제적으로 절단한다(스텝(S99)). 이 강제 절단은, 수신한 데이터를 폐기하는 것과 동시에, 송신 측에 절단요구를 하는 것에 의해서 행해진다. 판단 스텝(S98)에서, 복호화한 데이터가 올바른 데이터라고 판정되었을 경우에는, 수신 데이터의 확보, 즉 상위 프로토콜 스택으로의 데이터의 배달이 실시되고(스텝(SlOO)), TCPsec의 데이터 송수신 처리가 완료된다(스텝(SlOl)).
다음에, 도 9의 스텝(S48)에서 TCPsec 패시브 접속 처리가 개시되었을 경우의 상세한 처리를 도 13의 흐름도에 의거하여 설명한다.
최초로, 상대가 올바른 상대, 즉 자기 컴퓨터에 접속하는 권한을 가지는 컴퓨터인지 아닌지를 판단하고(스텝(SlO2)), 올바른 상대가 아닌 경우에는 TCPsee의 강제 절단을 위한 처리를 실시한다(스텝(SlO3)). 판단 스텝(SlO2)에 있어서 접속 상대가 올바른 상대라고 판단되면, 수신측 호스트(B)로부터 접속 응답을 송신한다(스텝(SlO4)).
그리고, 접속 응답을 송신해 온 상대의 정보가 자기 컴퓨터 내에 있는지를 확인한다(스텝(SlO5)). 상대 정보가 컴퓨터 내에 없는 경우는, 본 시스템, 즉 TCP(2)를 인스톨할 때에 사용한, 인스톨 서버로부터 상대 정보를 취득한다(스텝(SlO6)). 또는, 제 3자 인증의 서버로부터 상대 정보를 취득하여 스텝(SlO7)으로 진행된다. 이 취득하는 정보로서는, 상대측의 TCP(2)의 ID, 사용자 ID, 패스워드, 바이오 매트릭스 정보, 기기 고유 정보, LAN 접속 기기 정보 등 중, 1개 혹은 복수를 사용할 수 있다. 또한 서버로부터의 취득 정보를 이미 자기 컴퓨터가 보유하고 있는 경우에 있어서도, 유효기간 혹은 유효 사용 회수를 넘고 있는 경우에는, 재차 취득 동작을 실시할 필요가 있다.
다음에, 상대 정보가 올바른 상대인지 아닌지가, 즉, 자신의 컴퓨터에 액세스하는 것이 허용되고 있는 상대일지가 판단된다(스텝(SlO7)). 여기서, 접속하는 상대가 올바른 상대라면, TCPsec의 패시브 접속을 완료하지만(스텝(SlO8)), 올바른 상대가 아닌 경우에는 TCPsec의 강제 절단을 실시하여 접속을 중지한다(스텝(SlO3)).
다음에, 도 11의 스텝(S88)에서 TCPsec의 액티브 접속처리가 개시되었을 경우의 상세한 처리를 도 14의 흐름도에 의거하여 설명한다.
도 13의 패시브 접속 처리의 경우와 동일하게, 최초로, 접속 요구를 해 온 상대가 올바른 상대인지 아닌지, 즉 자기 컴퓨터에 액세스권한을 가지고 있는 상대로부터의 통신인지를 판단한다(스텝(SlO9)). 정당한 액세스권한을 가지지 않는 상대로부터의 통신이면, TCPsec의 액티브 접속을 강제 절단하여 종료한다(스텝(SllO)).
판단 스텝(SlO9)에서 올바른 상대라고 판정되면, 송신측 호스트로부터 수신측 호스트(B)에 대해서 긍정적인 접속 응답(ACK)을 송신한다(스텝(Slll)).
다음에, 자기 컴퓨터가 상대측의 정보를 보유하고 있는지가 판단된다(스텝(Sl12)). 상대 정보가 컴퓨터 내에 없는 경우는, 본 시스템, 즉 TCP(2)를 인스톨할 때에 사용한, 인스톨 서버로부터 상대 정보를 취득한다(스텝(Sl13)). 또는, 제 3자 인증의 서버로부터 상대 정보를 취득하여 스텝(Sl14)으로 진행된다. 여기서, 이 취득하는 정보는, 도 13 스텝(SlO6)과 동일하게, 상대측의 TCP(2)의 ID, 사용자 ID, 패스워드, 바이오 매트릭스 정보, 기기 고유 정보, LAN 접속 기기 정보 등 중, 1개 혹은 복수로 할 수 있다. 또한 서버로부터의 취득 정보를 이미 자기 컴퓨터가 보유하고 있었다고 해도, 유효기간 혹은 유효 사용 회수를 넘고 있는 경우에는, 재차 취득 동작을 실시할 필요가 있다.
다음에, 상대 정보가 올바른 상대인지 아닌지, 즉, 자신의 컴퓨터에 액세스하는 것을 허용되고 있는 상대인지가 판단된다(스텝(Sl14)). 접속하는 상대가 올바른 상대이면, TCPsec의 액티브 접속을 완료하지만(스텝(Sl15)), 올바른 상대가 아닌 경우에는 TCPsec의 강제 절단을 실시하여 접속을 중지한다(스텝(SllO)).
이상, 본 발명의 TCP(2) 중, TCP／TCPsec를 이용한 패시브 오픈 및 액티브 오픈의 통신 처리에 대해서 설명했다.
다음에, 도 3에서 나타내는 바와 같은, 본 발명의 제 2실시형태인 UDP／UDPsec를 이용한 통신 시스템 및 통신 방법에 대해서 설명한다.
도 15는, 본 발명의 제 2실시형태에 이용되는 UDP／UDPsec의 패시브 오픈 처리에 대해서 설명하기 위한 흐름도이다.
이 처리는, 상위 애플리케이션ㆍ프로그램에 의해 개시된다(스텝(120)). 최초로, 오픈하는 포트 번호의 해석, 즉 포트 번호의 정의(定義) 상태가 확인된다(스텝(121)). 다음에, 이 포트 번호가 UDPsec 오픈이 되어 있는지 아닌지가 판단된다(스텝(S122)). UDPsec가 오픈이 되어 있지 않은 경우는 UDP가 오픈이 되어 있는지 아닌지가 판단된다(스텝(123)). 그리고, UDPsec, UDP가 양쪽 모두 오픈 허가로 되어 있지 않은 경우는, UDP／UDPsec는 종료한다(스텝(S126)). 판단 스텝(S123)에서, UDP가 오픈 허가가 되어 있는 경우, 즉 UDPsec는 오픈 허가로 되어 있지 않지만 UDP가 오픈 허가가 되어 있는 경우는, 도 18에 나타내는 UDP 오픈 처리가 실시된다(스텝(S124)). 또, 판단 스텝(S122)에 있어서 UDPsec가 오픈인 경우는, UDP가 오픈인지 아닌지에 관계없이, UDPsee의 오픈 처리가 실시되어(스텝(S125)), UDP／UDPsec 오픈 처리는 종료한다(스텝(S126)). 또한 상위인 애플리케이션으로부터는, UDP에서 오픈을 실시하고 있었다고 해도, TCP(2)의 판단에 의해, UDPsec 혹은 UDP에서 통신하는 것도 가능하다.
다음에, 본 발명의 제 2 실시형태의 하나인 UDP／UDPsec를 이용한 유니캐스트(uni-cast) 통신에 있어서의 순서 처리에 대해서 도 16에 의거하여 설명한다.
도 16은, 표준의 UDP 및 본 발명의 TCP(2) 중 UDPsec에 있어서의 유니캐스트 통신의 개시 순서, 데이터 통신 순서의 패킷(헤더와, 페이로드로 구성한다) 및 그 흐름을 설명한 도면이다.
도 16(a)이 표준의 UDP를 이용한 통신 순서를 나타내고, 도 16(b)은, UDPsec에 의한 암호화 통신의 순서를 나타낸다.
도 16(a)의 표준 UDP는, 호스트(A), 호스트(B) 모두 애플리케이션이 UDP 오픈하고 있는 예를 나타내고 있다. 호스트(B)의 애플리케이션이 UDP 오픈을 하면, UDP 오픈 처리(도 15의 스텝(S124) 및 도 18 참조)를 개시한다. 또, 동일하게 호스트(A)의 애플리케이션이 UDP 오픈했을 경우도 상기의 UDP 오픈 처리를 개시한다. 이것에 의해, UDP의 데이터 통신을 실시하는 것이 가능해진다. 여기서 도 16(a)에 나타내는 유니캐스트 통신에서는, 호스트(A), 호스트(B)의 어느 쪽으로부터도 데이터의 송신이 가능하다.
다음에, 본 발명의 TCP(2)의 암호화 방식의 하나인 UDPsec에 의한 통신 처리의 순서를 설명한다.
도 16(b)은, 본 발명의 TCP(2)가 가지는 UDPsec에 의해 암호화 통신하는 경우의 예이지만, 이 예는, 호스트(A), 호스트(B) 모두 애플리케이션이 UDP 오픈하고, TCP(2)가 UDPsec로 오픈이라고 판단한 케이스이다.
호스트(B)가 UDPsec 오픈을 하면, UDPsec 오픈 처리(도 15의 스텝(S125) 및 도 19를 참조)가 개시된다. 또, 호스트(A)가 UDPsec 오픈했을 경우도 이와 같이 UDPsec 오픈 처리가 개시된다. 그리고, UDPsec의 데이터 통신이 실현 가능해진다.
이 도 16(b)에 나타낸 UDPsec를 이용한 유니캐스트 통신에 있어서도, UDP 때와 동일하게, 호스트(A) 측 또는 호스트(B) 측의 어느 쪽으로부터도 데이터를 송신할 수 있다. 도 16(b)의 경우, 우선, 호스트(A)의 애플리케이션으로부터 UDP 데이터의 송신 요구가 있었다고 가정하여 설명한다. 애플리케이션으로부터 UDP 데이터의 송신 요구를 받아들이면, 호스트(B)는, UDPsec 유니캐스트 수신 개시 처리를 개시하고, 니고시에이션을 개시한다. 니고시에이션을 하여, 상대가 올바른 상대이면, 니고시에이션을 완료하고, 애플리케이션으로부터 UDP 데이터의 송신 요구를 UDPsec 데이터(암호 데이터)로서 송신한다. 이 UDPsec 유니캐스트 통신에서는, 데이터를 수신한 측으로부터 ACK(긍정 응답)를 돌려주지 않는다. 이 때문 에, 송달 확인과 데이터의 보증을 하는 기능은 없지만, 그만큼 데이터의 통신이 고속이 되며, 대용량의 화상 데이터 등의 통신에 적합하다.
도 17은, 표준 UDP와 본 발명의 TCP(2)의 암호화 방식인 UDPsec를 이용한 브로드캐스트 통신의 개시 순서, 데이터 통신 순서의 패킷(헤더와, 페이로드로 구성한다) 및 그 흐름을 설명한 도면이다.
도 17(a)이, 표준의 UDP, 도 17(b)이 본 발명의 TCP(2)의 UDPsec에 의한 통신의 순서도이다.
도 17(a)의 표준의 UDP는, 호스트(A), 호스트(B) 모두 애플리케이션이 UDP 오픈하고 있다. 그리고, 호스트(B)의 애플리케이션이 UDP 오픈을 하면, UDP 오픈 처리(도 15의 스텝(S124) 및 도 18 참조)를 개시한다. 또, 호스트(A)의 애플리케이션이 UDP 오픈했을 경우도, 똑같이 UDP 오픈 처리를 개시한다. 이것에 의해, UDP의 데이터 통신을 실시할 수 있는 상태가 된다.
또, 데이터는 호스트(A), 호스트(B)의 어느 쪽도 발생할 수 있지만, 도 17(a)에서는, 브로드캐스트 통신이라고 하는 경우도 있어서, 호스트(A) 측으로부터 호스트(B) 측으로 한 방향적으로 데이터가 흐르는 도면으로 하고 있다. 데이터를 수신한 호스트(B) 측으로부터 ACK(긍정 응답)를 돌려주지 않기 때문에, 송달 확인과 데이터의 보증을 하는 기능은 가지지 않는다. 또한 데이터를 브로드캐스트 하는 경우에는, IP 주소의 서브네트워크 주소를 전부 1로 하는 것으로, 데이터를 브로드캐스트 하는 것이 가능해진다.
다음에, 도 17(b)의 UDPsec에 의한 암호화 통신에 대해서 설명한다. 이 경우도, 호스트(A), 호스트(B) 모두 애플리케이션이 UDP 오픈하고, TCP(2)가 UDPsec에서 오픈으로 하고 있다.
호스트(B)가 UDPsec 오픈을 하면, UDPsec 오픈 처리(도 15의 스텝(S125) 및 도 19)를 개시한다. 또, 호스트(A)가 UDPsec 오픈해도 동일하게, UDPsec 오픈 처리를 개시한다. 이것에 의해, UDPsec의 데이터 통신을 실시할 수 있는 상태가 된다.
도 17(b)에 나타내는 바와 같이, 호스트(A)의 애플리케이션으로부터 UDP의 브로드캐스트 데이터(IP 주소가 브로드캐스트를 나타내고 있는 데이터)의 송신 요구가 있었을 경우를 설명한다. 애플리케이션으로부터 UDP의 브로드캐스트 데이터의 송신 요구를 받아들이면, 니고시에이션을 하지 않고, UDPsec에서 암호 데이터로서 불특정 호스트에 전달한다. 호스트(B)는, 브로드캐스트 데이터를 받으면, 후술하는 도 19의 스텝(S141)의 UDPsec 브로드캐스트 수신 개시 처리를 개시한다. 호스트(A)와 호스트(B)간에 니고시에이션을 개시하고, 상대가 올바른 상대이면, 니고시에이션을 완료하여, 브로드캐스트 데이터를 복호화하여, 애플리케이션에 보낸다. 이때, 데이터를 수신한 측으로부터 ACK(긍정 응답)를 돌려주지 않기 때문에, 송달 확인과 데이터의 보증을 하는 기능은 없다.
다음에, 도 18에 의거하여, 도 15의 스텝(S124)의 표준 UDP의 오픈 처리에 대해서 설명한다.
도 18은, UDP의 오픈 처리의 흐름도이며, 이 처리는 도 15의 스텝(S124)에서, 처리하는 프로토콜이 UDP로 결정했을 경우에 개시되는 처리이다.
최초로, 애플리케이션으로부터의 송신 요구, 또는 수신 패킷을 기다리고, 송신 요구 또는 패킷을 수신했을 때에, 패킷의 해석을 실시한다(스텝(S127)). 여기서, 수신 패킷뿐만이 아니라 송신 요구도 해석하는 것은, 악의를 가진 제 3자가 송신하는 호스트(A)발판으로 하여, 호스트(A)를 가해자로서 불특정 다수에게 통신하는 것을 막기 위해서이다. 이 송수신 패킷의 해석을 실시한 후에, 올바른 패킷인지, 즉 DoS 공격에 있어서의 UDP 프로토콜 공격 패턴이 아닌지 어떤지를 판단한다(스텝(S128)). 이 판단 스텝(S128)에 있어서, 부정 패킷이라고 판정되었을 경우에는, 패킷을 폐기하고(스텝(S129)), 다음의 패킷을 기다린다.
판단 스텝(S128)에서 올바른 패킷이라고 판정되었을 경우는, UDP 데이터의 송수신 처리가 실시되고(스텝(S130)), 계속해서 상위 애플리케이션으로부터 UDP의 클로즈 요구가 있었는지가 판단된다(스텝(S131)). 상위 애플리케이션에서 UDP 클로즈 요구가 있었을 경우에는, UDP 오픈처리를 종료한다(스텝(S132)).
다음에, 도 19에 의거하여, 도 15의 스텝(S125)의 UDPsec의 오픈 처리에 대해서 설명한다. 도 19는, UDPsec의 오픈에 있어서의 처리의 흐름도이며, 도 15의 스텝(S125)에 나타내는 바와 같이, 처리하는 프로토콜이 UDPsec로 결정했을 경우에 이 처리가 개시된다.
최초로, 애플리케이션으로부터의 송신 요구 또는 수신 패킷을 기다리고, 송신 요구 또는 수신한 패킷의 해석을 한다(스텝(S133)). 다음에, 상위 애플리케이션으로부터의 송신 요구 혹은 송수신 패킷이 올바른 UDP 패킷인지 아닌지, 즉 DoS 공격에 있어서의 TCP 프로토콜 공격 패턴이 아닌지 어떤지를 판단한다(스텝(S134)). 판단 스텝(S134)에 있어서 올바른 UDP 패킷이 아니라고 판단되었을 경우는, 패킷을 폐기하고(스텝(S135)), 다음의 패킷을 기다린다.
판단 스텝(S134)에 있어서, 올바른 UDP 패킷이라고 판정되었을 경우는, 다음에 UDPsec 니고시에이션이 된 수신 패킷인지 아닌지가 판단된다(스텝(S136)).
그리고, 이 결과, UDPsec의 니고시에이션 패킷이라고 판단되었을 경우는, 후술하는 도 23에서 나타내는 UDPsec 유니캐스트 수신 개시 처리를 실시하고(스텝(S137)), 스텝(S147)으로 진행된다.
또, 판단 스텝(S136)에 있어서, UDPsec의 니고시에이션 패킷이 아니라고 판단되면, 계속해서 브로드캐스트 통신인지 아닌지를 판단한다(스텝(S138)). 그리고, 브로드캐스트 통신이라고 판정되었을 경우는, 통신의 개시 패킷인지, 즉 오픈 후의 최초의 통신 패킷인지 아닌지를 판단하고(스텝(S139)), 개시 패킷이 아닌 경우는 도 22에서 설명하는 UDPsec 데이터 송수신 처리를 실시한다(스텝(S144)). 판단 스텝(S139)에 있어서 통신의 개시 패킷이라고 판정되었을 경우는, 다음에 송신 패킷인지 아닌지가 판단된다(스텝(S140)). 그리고, 이 결과, 송신 패킷이라면, 상술한 UDPsec 데이터 송수신 처리를 실시하지만(스텝(S144)), 송신 패킷이 아니라고 판정되었을 경우는, 후술하는 도 20의 UDPsec 브로드캐스트 수신 개시 처리가 실시된다(스텝(S141)). 이 수신 개시 처리 후에, 송신된 패킷이 올바른 상대로부터의 것인지를 판단한다(스텝(S142)). 그리고, 판단 스텝(S142)에서, 송신된 패킷이 올바른 상대로부터의 것이 아니라고 판단되면, 패킷을 폐기하고(스텝(S143)), 다음의 패킷을 기다린다. 판단 스텝(S142)에서, 올바른 상대라고 판정되었을 경우에는, 도 22에서 나타내는 UDPsec 데이터 송수신 처리를 한다(스텝(S144)).
또, 판단 스텝(S138)에 있어서, 브로드캐스트 통신이 아닌, 즉 유니캐스트 통신이라고 판정되었을 경우는, 통신의 개시 패킷, 즉 오픈 후의 최초의 통신 패킷인지 아닌지가 판단된다(스텝(S145)). 이 결과, 개시 패킷은 아니라고 판단되었을 경우에는, 도 22에서 상술하는 UDPsec 데이터 송수신 처리가 이루어진다(스텝(S144)).
또, 판단 스텝(S145)에서, 오픈 후의 최초의 통신 패킷이라고 판단되었을 경우는, 도 21에서 후술하는 UDPsec 유니캐스트 송신 개시 처리를 한다(스텝(S146)). 그 후, 통신 상대가, 올바른 상대인지를 판단하고(스텝(S147)), 올바른 상대인 경우에는, 계속 UDPsec 데이터 송수신 처리가 이루어지고(스텝(S144)), 올바른 상대가 아니라고 판정되었을 경우에는, 수신한 패킷을 폐기하고(스텝(Sl48)), 스텝(S133)으로 돌아와서 다음의 패킷을 기다린다.
다음에, 도 19의 스텝(S141)의 UDPsec 브로드캐스트 수신의 개시에 있어서의 처리에 대해서, 도 20에 나타내는 흐름도에 의거하여 설명한다.
최초로, 브로드캐스트를 전달해 온 상대의 정보를 자기 컴퓨터가 보유하고 있는지 아닌지를 판단한다(스텝(S149)). 그리고, 정보를 보유하고 있지 않은 경우에는, 본 시스템을 인스톨할 때에 사용한, 인스톨 서버로부터 상대 정보를 취득한다(스텝(S150)). 또는, 제 3자 인증의 서버로부터 정보를 취득한다. 이 취득하는 정보는, 상대의 TCP(2)의 ID, 사용자 ID, 패스워드, 바이오 매트릭스 정보, 기기 고유 정보, LAN 후속 기기 정보 등 중, 1개 혹은 복수를 사용한다. 다음에, 브로드캐스트를 전달해 온 상대가 올바른 상대인지를 판단한다(스텝(S151)). 그리고, 올바른 상대라고 판단되면, UDPsec로의 수신이 가능한 것이 되고, UDPsec 브로드캐스트의 통신 개시 처리를 종료하고(스텝(S153)), 수신 가능한 것을 도 19의 스텝(S142)에 지시한다. 판단 스텝(S151)에서 올바른 상대가 아니라고 여겨졌을 경우에는, 통신의 거부를 실시하고(스텝(S152)), 데이터를 취득하지 않는 취지를 동일하게 도 19의 스텝(S142)에 지시한다. 또한 스텝(S149)에서 만일 상대방에 관한 취득 정보가 있었다고 해도 유효기간, 혹은, 유효 사용 회수를 넘고 있는 경우에는, 재차 스텝(S150)에서 상대 정보의 취득 동작을 실시하는 편이 좋다.
다음에, 도 19의 스텝(S146)의 UDPsec 유니캐스트 송신 개시 처리에 대해서, 도 21에 나타내는 흐름도에 의거하여 설명한다.
최초로, 송신하는 상대의 정보를 자기 컴퓨터가 보유하고 있는지 아닌지를 확인한다(스텝(S154)). 그리고, 정보를 보유하고 있지 않은 경우에는, 도 20의 스텝(S150)과 같은 방법으로 상대 정보를 취득한다(스텝(S155)). 이 취득하는 정보도 도 20의 경우와 동일하다.
다음에, 송신하는 상대가 올바른 상대인지를 판단한다(스텝(S156)). 그리고, 올바른 상대라고 판단되면, UDPsec로의 송신이 가능한 것이 되고, UDPsec 유니캐스트의 통신 개시 처리를 종료하고(스텝(S158)), 송신 가능한 것을 도 19의 스텝(S147)에 지시한다. 판단 스텝(S156)에서 올바른 상대가 아니라고 여겨졌을 경우에는, 통신의 거부를 실시하고(스텝(S157)), 데이터를 취득하지 않는 취지를 도 19의 스텝(S147)에 지시한다.
다음에, 도 22에 의거하여, 도 19의 스텝(S144)에 나타내는 UDPsec 데이터의 송수신 처리에 대해서 설명한다.
최초로, 호스트(A)의 애플리케이션으로부터 송신 요구가 있었는지 아닌지를 판단한다(스텝(S159)). 송신 요구가 있으면 송신측 호스트(A)에 있어서 데이터를 암호화하고(스텝(S160)), 이 암호화한 데이터에 인증 데이터가 부가되어서(스텝(S161)), 수신측 호스트(B)에 암호화되어 인증 데이터가 부가된 패킷이 송신된다(스텝(S162)).
다음에, 수신측 호스트(B)에서, 수신 데이터가 있는지 없는지가 판단되며(스텝(S163)), 수신 데이터가 있는 경우에는, 수신 데이터의 복호화를 한다(스텝(S164)). 다음에, 이 수신되어 복호화된 데이터가 올바른 데이터일지가 판단된다(스텝(S165)). 이 판단은, 복호화한 데이터와 수신된 인증 데이터를 확인하는 것에 의해서 행해지지만, 복호 데이터를 확인한 결과, 올바른 데이터가 아니라고 판정되었을 경우에는, UDP／UDPsec를 강제적으로 절단한다(스텝(S166)). 판단 스텝(S165)에서, 복호화한 데이터가 올바른 데이터라고 판정되었을 경우에는, 수신 데이터의 확보, 즉 상위 프로토콜 스택으로의 데이터의 배달이 실시되고(스텝(S167)), UDPsec의 데이터 송수신 처리가 완료된다(스텝(S168)).
다음에, 도 23의 흐름도에 의거하여, 도 19의 스텝(S137)에 나타내는 UDPsec 유니캐스트 수신의 개시 처리에 대해서 설명한다.
최초로, 유니캐스트에서 수신한 패킷의 상대 정보를 자기 컴퓨터가 보유하고 있는지 아닌지를 판단한다(스텝(S169)). 상대 정보를 가지고 있지 않은 경우에는, 본 시스템을 인스톨할 때에 사용한, 인스톨 서버 혹은 제 3자 인증의 서버로부터 상대 정보를 취득한다(스텝 S170). 취득하는 정보로서는, 도 20의 스텝(S150) 혹은 도 21의 스텝(S155)과 동일하며, 상대의 TCP(2)의 ID, 사용자 ID, 패스워드, 바이오 매트릭스 정보, 기기 고유 정보, LAN 접속기기정보 등 중, 1개 혹은 복수가 이것에 상당한다.
다음에, 유니캐스트를 송신해 온 상대가 올바른 상대인지 아닌지를 판단한다(스텝(S171)). 올바른 상대라고 판정되면, UDPsec에서의 수신이 가능한 것을 도 19의 스텝(S147)에 전하여 UDPsec 브로드캐스트 통신 개시 처리를 종료한다(스텝(S173)). 판단 스텝(S171)에서 올바른 상대가 아니라고 판단되었을 경우에는, 데이터를 취득하지 않는 취지를 도 19의 스텝(S147)에 전해서 통신을 거부한다(스텝(S172)).
이상, 본 발명의 제 1실시형태인 TCPsec를 이용한 암호화 처리 및 본 발명의 제 2실시형태인 UDPsec를 이용한 암호화 처리에 대해서 흐름도 및 순서도에 의거하여 자세하게 설명했다.　
다음에, 본 발명의 TCP(2)가, 종래의 IPsec 혹은 SSL과 비교해서 어떻게 우위인가 하는 점에 대해서, 표 2 및 도 24에 의거하여 설명한다.
표 2는, 표 1의 IPsec와 SSL의 기능비교표에 TCP(2)의 기능을 추가하여 나타낸 것이다.
이 표 2로부터 명확한 바와 같이, IPsec 및 SSL이 가지고 있는 다양한 문제 점(이것들에 대해서는 배경 기술에 대해서 나타냈다)을, TCP(2)를 채용하는 것으로 모두 해결하고 있는 것을 알 수 있다.
표 2: IPsec, SSL 및 TCP2의 구성비교
IPsec SSL TCP2
(1) 클라이언트-클라이언트간의 통신 Ｏ 직접 통신가능 × 직접 통신불가. 특별한 서버를 통해 통신하는 것은 가능 Ｏ 직접 통신가능.
(2) PPP 모바일 환경 △
 XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. Ｏ
통신가능.		 Ｏ
 통신가능.
(3) ADSL 환경
(4) NAT, IP 매스커레이드 환경 △ NAT-T와 병용하는 것으로 실현 가능. Ｏ 통신가능. Ｏ 통신가능.
(5) TCP/IP 프로토콜 스택으로의 DoS 공격 Ｏ DoS 공격으로의 대응가능. × 대응불가. Ｏ Dos 공격으로의 대응가능.
(6) 열악한 통신환경화(물리 노이즈가 많아 통신에러가 다발하는 환경) × 대응이 불충분. 스루 풋의 저하를 초래한다. Ｏ 대응가능. Ｏ 대응가능.
(7) 다른 LAN 사이의 통신 △ 서브네트워크 주소가 동일 주소인 경우, 통신불가. Ｏ 통신가능. Ｏ 통신가능.
(8) 다른 네트워크 환경 △ 관리가 어렵고 곤란. Ｏ 관리의 간소화가 가능. Ｏ 관리의 간소화가 가능.
(9) 복수의 캐리어 경유의 환경 × 통신불가. Ｏ 통신가능. Ｏ 통신가능.
(10) 모든 UDP 포트의 안전한 통신 Ｏ 안전한 통신이 가능. × 통신불가. Ｏ 통신가능.
(11) 모든 UDP 포트의 안전한 통신 Ｏ 안전한 통신이 가능. × 특정 TCP 포트 이외는 통신불가. Ｏ 통신가능.
(12)애플리케이션에서의 제한 Ｏ 영향 없음 × 소켓 프로그램의 변경이 필요. Ｏ 소켓 프로그램 부분을 그대로 사용하는 것이 가능.
(13) 액세스 단위 IP 단위 리소스단위(URL단위, 폴더) PORT단위, 세션단위
(14) MUT(최대 세그먼트 사이즈) △ 조정이 필요. Ｏ MTU를 의식하지 않고 통신가능. Ｏ 의식 없이 통신가능.
(15) 모바일 환경하에서, VoIP를 사용한 인터넷 전화 △ XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. × 사용불가. Ｏ 사용가능.
(16) ADSL 환경하에서, VoIP를 사용한 인터넷 전화 △ XAUTH를 이용하는 것으로 가능. 단, 보안상에 문제 있음. × 사용불가. Ｏ 사용가능.
(17) 다른 LAN 사이에서, VoIP를 사용한 인터넷 전화 △ NAT-T, IPsec-DHCP를 사용하는 것으로 실현 가능. × 사용불가. Ｏ 사용가능.
(19) 복수 캐리어 LAN 사이에서, VoIP를 사용한 인터넷 전화 × 통신불가. × 사용불가. Ｏ 사용가능.
예를 들면, SSL에서는 대응이 곤란한, 클라이언트-클라이언트간의 통신, TCP／IP 프로토콜에의 DoS 공격, 모든 UDP 포트 혹은 TCP 포트의 안전한 통신, 소켓 프로그램을 변경해야 했던 애플리케이션으로의 제한 등에, TCP(2)는 완전히 대응하고 있다.
또, IPsec에서는 대응이 곤란한, 에러가 다발하는 열악한 환경하에서의 통신, 다른 LAN간으로의 통신, 복수 캐리어 경유의 접속, PPP모바일 환경, ADSL 환경에서의 통신에 대해서도, TCP(2)는 완전하게 서포트하고 있다.
게다가, 모바일 환경하나 ADSL 환경하에서 VoIP(Voice over Internet Protocol)를 사용한 인터넷에 대해서는, IPsec 및 SSL와 표 1 및 표 2에 나타내는 바와 같이 문제가 있지만, 본 발명의 TCP(2)에 의하면, 어느 쪽의 환경하에서도 대응 가능하다.
또, 다른 LAN간이나 복수 캐리어에 걸친 LAN 사이에서 VoIP를 사용한 인터넷 전화에 대해서도, IPsec와 SSL에서는 대응 불가능했지만, 본 발명의 TCP(2)에 완전히 대응할 수 있다.
도 24는, TCP(2)의 우위성을 설명하기 위한 도면이지만, 보안성이 없는 프로토콜 스택(a)에, 종래의 SSL을 적용한 케이스(b)와, IPsec를 적용한 케이스(c)와, 본 발명의 TCP(2)(TCPsec／UDPsec)를 적용한 케이스(d)를 비교하여 나타내고 있다. 도 24(b)의 SSL은 이미 기술한 바와 같이, 세션층(제 5층)의 소켓에 설치되어 있으므로, 상위의 애플리케이션에 대한 호환성이 없는 것이다. 이 때문에, SSL 자체, 상술과 같은 문제를 책임지게 되어 있다. 또 도 24(c)의 IPsec는, 네트워크층(제 3층)에 있고, IP층에서의 호환성이 없기 때문에, 네트워크를 구성하는데 있어서 상술한 바와 같은 여러가지 제약을 받게 된다. 이것에 대해서, 도 24(d)의 TCP(2)(TCPsec／UDPsec)는, 트랜스포트층(제 4층)에 도입하는 암호화 기술이며, 이 때문에 애플리케이션으로부터 보면 소켓을 그대로 이용할 수 있고, 또 네트워크로부터 보면 IP도 그대로 이용할 수 있으므로 네트워크를 구성하는데 있어서의 제약은 받지 않는다.
이상과 같이, 본 발명의 TCP(2)를 이용한 암호화 통신 시스템, 암호화 통신 방법은, 기존의 암호화 처리 시스템에 비해서도, 특히 데이터의 누설, 개찬, 위장, 진입 그리고 공격에 대해서 지극히 높은 보안 기능을 가지는 것이다.
또한 본 발명은, 이상 설명한 실시형태로 한정되는 것이 아니고, 특허 청구의 범위에 기재한 본 발명의 요지를 일탈하지 않는 범위에 있어서, 한층 더 많은 실시형태를 포함하는 것은 말할 필요도 없다.

Claims (27)

  1. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 시스템에 있어서,
    통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과,
    통신로의 양단에서 대응하는 암호화 및 복호화 논리 회로를 결정하는 결정 수단과,
    송수신하는 정보 단위로서의 패킷 중, 적어도 상기 TCP 또는 UDP 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 수단과,
    수신한 상기 암호화된 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 수단을 갖추며,
    상기 결정 수단은, 상기 접속 순서 수단이 정당한 권한을 가진다고 판단하여 접속한 통신 상대와만 상기 트랜스포트층의 상기 TCP 또는 UDP 프로토콜을 이용하여 상기 암호화 및 복호화 논리 회로에 의거한 통신을 실시하도록 구성된 것을 특징으로 하는 통신 시스템.
  2. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 시스템에 이용되는 암호화 및 복호화 논리 회로를 결정하는 결정 수단과, 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 이 통신 상대와의 접속을 실시하기 위한 접속 순서 수단을 갖추는 제 1 및 제 2통신 장치와, 상기 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추지 않은 제 3통신 장치가 각각 네트워크에 접속되어서 이루어지는 통신 시스템에 있어서,
    상기 제 1 및 제 2통신 장치는, 송수신하는 정보 단위의 패킷 중, 적어도 상기 TCP 또는 UDP 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 수단과, 수신한 상기 암호화된 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 수단으로 이루어지는 암호화 프로토콜 처리 수단과, 상기 암호화 및 복호화 논리 회로를 수반하지 않는 통상의 프로토콜 처리 수단의 양쪽 모두를 갖추며,
    상기 제 3통신 장치는, 상기 TCP 또는 UDP 프로토콜의 암호화 및 복호화 논리 회로를 결정하기 위한 결정 수단을 갖추지 않은 통상의 프로토콜 처리 수단만을 갖추며,
    상기 제 1통신 장치가, 상기 제 2통신 장치와 통신할 때는, 상기 접속 순서 수단의 판단 정보에 의거하여, 상기 암호화 및 복호화 논리 회로의 결정 수단에 의해,
    상기 암호화 프로토콜 수단을 선택하고, 상기 암호화 프로토콜 수단에 의해 통신하는 것과 동시에,
    상기 제 1통신 장치가 상기 제 3통신 장치와 통신할 때는, 상기 접속 순서 수단의 판단 정보에 의거하여, 상기 암호화 및 복호화 논리 회로의 결정 수단에 의해, 상기 암호화 및 복호화를 수반하지 않는 상기 통상 프로토콜 처리 수단에 의해 통신하든지, 상기 제 3통신 장치와의 통신을 실시하지 않는 것을 선택 가능하게 하도록 구성된 것을 특징으로 하는 통신 시스템.
  3. 삭제
  4. 삭제
  5. 제 1항 또는 제 2항의 어느 한 항에 있어서,
    상기 암호화 및 복호화 논리 회로의 결정 수단에 의한 결정 후보가 될 수 있는 암호화 및 복호화 논리 회로를 메모리에 기억 내지 회로에 실장하고, 이 기억 내지 실장한 결정 후보가 될 수 있는 암호화 및 복호화 논리 회로를 정기적으로 변경하는 논리 회로 변경 수단을 한층 더 갖추도록 구성된 것을 특징으로 하는 통신 시스템.
  6. 제 1항 또는 제 2항의 어느 한 항에 있어서,
    상기 암호화 및 복호화 논리 회로의 결정 수단이, 상기 암호화 및 복호화 논리 회로에 관련하여, 암호화를 하지 않고 평문을 취급하는 취지를 결정할 수 있도록 구성된 것을 특징으로 하는 통신 시스템.
  7. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 인증 기능을 추가하여 통신을 실시하는 통신 시스템에 있어서,
    통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과,
    통신로의 양단에서 대응하는 완전성 인증 논리 회로를 결정하는 완전성 인증 결정 수단과,
    송수신하는 정보 단위인 패킷 중, 적어도 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증 정보를 부가하여 송신하는 프로토콜 완전성 인증 정보부가 수단과,
    수신한 이 완전성 인증 정보가 부가된 프로토콜을 상기 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 수단을 갖추며,
    상기 접속 순서 수단이 정당한 권한이 있다고 판단한 통신 상대와만, 상기 트랜스포트층에 있는 TCP 또는 UDP 프로토콜을 이용하여 상기 완전성 인증 논리 회로에 의거한 통신을 실시하도록 구성된 것을 특징으로 하는 통신 시스템.
  8. 트랜스포트층에 위치하는 TCP 또는 UDP를 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 상기 TCP 또는 UDP를 이용하여 완전성 인증의 결정을 실시하는 완전성 인증 결정 수단을 갖추는 제 1 및 제 2통신 장치와,
    상기 완전성 인증 결정 수단을 갖추지 않는 제 3통신 장치가 각각 네트워크에 접속되어서 이루어지는 통신 시스템에 있어서,
    상기 제 1 및 제 2통신 장치는, 상기 완전성 인증 정보를 부가하여 TCP 또는 UDP를 처리하는 완전성 인증 프로토콜 처리 수단과, 상기 완전성 인증 정보의 부가를 실시하지 않는 통상의 TCP 또는 UDP를 처리하는 통상 프로토콜 처리 수단의 양쪽을 갖추며,
    상기 제 3통신 장치는, 상기 완전성 인증을 수반하지 않는 통상의 프로토콜 처리 수단만을 갖추며,
    상기 제 1통신 장치가, 상기 제 2통신 장치와 통신할 때는, 상기 접속 순서 수단에 있어서 상기 제 2통신 장치인 통신 상대가 정당한 상대인 것을 확인하고 나서 이 제 2통신 장치와의 접속을 실시하여 상기 완전성 인증 정보를 부가한 완전성 인증 프로토콜 수단에 의해 통신하는 것과 동시에,
    상기 제 1통신 장치가 상기 제 3통신 장치와 통신할 때는, 상기 접속 순서 수단에 있어서의 판단 정보에 의거하여, 상기 완전성 인증 정보를 부가하지 않는 것을 결정하고, 상기 통상 프로토콜 처리 수단에 의해 제 3통신 장치와의 통신을 실시하든지, 또는 상기 완전성 인증 결정 수단에 의해 상기 제 3통신 장치인 통신 상대가 정당한 권한을 가지는 통신 상대가 아닌 것을 확인하여 통신의 접속을 실시하지 않든지의 어느 쪽을 선택 가능하게 하도록 구성된 것을 특징으로 하는 통신 시스템.
  9. 삭제
  10. 제 7항 또는 제 8항의 어느 한 항에 있어서,
    상기 완전성 인증 결정 수단에 의한 결정 후보가 될 수 있는 완전성 인증 논리 회로를 메모리에 기억 내지 회로에 실장하고 있고, 이 기억 내지 실장한 완전성 인증 논리 회로를 정기적으로 변경하는 완전성 인증 논리 회로 변경 수단을 한층 더 갖추도록 구성된 것을 특징으로 하는 통신 시스템.
  11. 제 7항 또는 제 8항의 어느 한 항에 있어서,
    상기 완전성 인증 결정 수단에 의한 상기 결정은, 송신 데이터에 상기 완전성 인증 정보를 부가하든지, 또는 상기 완전성 인증 정보를 부가하지 않는 취지를 결정하는 것을 특징으로 하는 통신 시스템.
  12. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 장치에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과,
    통신을 위한 암호화 및 복호화 논리 회로를 결정하는 결정 수단과, 송신하는 정보 단위로서의 패킷 중, 적어도 상기 TCP 또는 UDP 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 수단과, 수신한 상기 암호화된 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 수단으로 이루어지는 암호화 프로토콜 처리 수단과,
    상기 암호화 및 복호화를 수반하지 않는 통상의 프로토콜을 처리하는 통상 프로토콜 처리 수단의 양쪽을 갖추며,
    상기 암호화 및 복호화 논리 회로의 결정 수단은, 상기 접속 순서 수단이, 통신 상대가 정당한 권한을 가지는 통신 상대라고 확인한 경우에는, 상기 암호화 프로토콜 처리 수단을 이용하여 통신을 실시하고, 상기 통신 상대가 정당한 권한을 가지고 있지 않은 통신 상대인 것을 확인한 경우에는, 상기 통상 프로토콜 처리 수단을 이용하여 통신하든지, 혹은 통신을 실시하지 않든지를 선택 가능하게 하도록 구성된 것을 특징으로 하는 통신 장치.
  13. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 인증 기능을 추가하여 통신을 실시하는 통신 장치에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과,
    통신을 위한 완전성 인증 논리 회로를 결정하는 완전성 인증 결정 수단과,
    송수신하는 정보 단위인 패킷 중, 적어도 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리회로에 따라서 완전성 인증 정보를 부가하여 송신하는 프로토콜 완전성 인증 정보 부가 수단과, 수신한 이 완전성 인증 정보 부가된 프로토콜을 상기 완전성 인증 결정 수단에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 수단을 갖추고,
    상기 접속 순서 수단의 판단 정보에 의거하여, 트랜지스터층에 있는 TCP 또는 UDP 프로토콜을 이용하여 상기 완전성 인증 논리 회로에 의거한 통신을 실시하도록 구성된 것을 특징으로 하는 통신 장치.
  14. 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 기능을 추가하여 통신하는 통신 방법에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 접속 스텝과,
    통신로의 양단에서 대응하는 암호화ㆍ복호화 논리 회로를 사전에 혹은 동적으로 결정하는 결정 스텝과,
    송수신하는 정보 단위가 되는 패킷 중, 적어도 상기 TCP 또는 UDP의 페이로드에 해당하는 프로토콜을 상기 결정 스텝에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하는 프로토콜 암호화 스텝과,
    수신한 암호화된 프로토콜을 상기 결정 스텝에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 스텝을 포함하고,
    상기 접속 스텝에 있어서 통신 상대가 정당한 권한을 가진다고 판단한 경우에는, 상기 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 처리를 실시하여 통신하도록 구성된 것을 특징으로 하는 통신 방법.
  15. 트랜스포트층의 TCP 또는 UDP에 해당하는 프로토콜에 암호화 기능을 추가하여 통신하는 통신 방법에 이용되는 암호화 및 복호화 논리 회로를 결정하는 결정 수단과 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 이 통신 상대와의 접속을 실시하기 위한 접속 순서 수단을 갖추는 제 1 및 제 2통신 장치와, 상기 암호화 및 복호화 논리 회로를 결정하는 결정 수단을 갖추지 않은 제 3통신 장치가 각각 네트워크에 접속되어서 이루어지는 통신방법에 있어서,
    상기 제 1통신 장치로부터 상기 제 2통신 장치로 통신할 때에는, 상기 접속 순서 수단의 판단 정보에 의거하여, 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 통신하는 것과 동시에,
    상기 제 1통신 장치가 상기 제 3통신 장치와 통신할 때는, 상기 접속 순서 수단의 판단 정보에 의거하여, 상기 TCP 또는 UDP 프로토콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 암호화하여 송신하지 않는 것을 결정하고, 상기 암호화 논리 회로를 수반하지 않는 통상의 TCP 또는 UDP 프로토콜에서 통신하든지, 상기 제 3통신 장치와의 통신을 실시하지 않든지의 어느 쪽인가를 선택하여 통신하도록 구성된 것을 특징으로 하는 통신 방법.
  16. 삭제
  17. 제 14항에 있어서,
    상기 결정 스텝에 대해 결정 후보가 될 수 있는 암호화 및 복호화 논리 회로를 메모리 내지 회로에 기억해 두고, 이 기억하는 암호화 및 복호화 논리 회로의 내용을 정기적으로 변경하도록 구성된 것을 특징으로 하는 통신 방법.
  18. 제 14항에 있어서,
    상기 결정 스텝에 있어서, 암호화 및 복호화 논리 회로에 대해 암호화를 하지 않고 평문을 취급하는 취지를 결정할 수 있도록 구성된 것을 특징으로 하는 통신 방법.
  19. 제 14항에 있어서,
    상기 결정 스텝보다 전에, 통신 상대를 인증하는 스텝을 한층 더 포함하도록 구성된 것을 특징으로 하는 통신 방법.
  20. 트랜스포트층에 있는 TCP 또는 UDP에 해당하는 프로토콜에 인증 기능을 추가하여 통신하는 통신 방법에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 접속 스텝과,
    통신로의 양단에서 대응하는 완전성 인증 논리 회로를 사전에 결정하는 완전성 인증 결정 스텝과,
    송수신하는 정보 단위의 패킷 중, 적어도 상기 TCP 또는 UDP의 페이로드에 해당하는 프로토콜을 상기 완전성 인증 결정 스텝에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증 정보를 부가하여 송신하는 프로토콜 완전성 인증 정보 부가 스텝과,
    수신한 이 완전성 인증 정보가 부가된 프로토콜을 상기 완전성 인증 결정 스텝에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 스텝을 포함하고,
    상기 접속 스텝에 있어서 통신 상대가 정당한 권한을 가진다고 판단한 경우에는, 상기 트랜스포트층에 있는 상기 TCP 또는 UDP 프로토콜에 상기 완전성 인증 정보를 부가하여 통신하도록 구성된 것을 특징으로 하는 통신 방법.
  21. 트랜스포트층의 TCP 또는 UDP를 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하기 위한 접속 순서 수단과, 상기 TCP 또는 UDP를 이용하여 완전성 인증 결정을 실시하는 완전성 인증 결정 수단을 갖추는 제 1 및 제 2통신 장치와의 사이, 혹은 상기 완전성 인증 결정 수단을 갖추는 제 1 또는 제 2통신 장치와 상기 완전성 인증 결정 수단을 갖추지 않은 제 3통신 장치와의 사이에서 네트워크를 통해서 통신하는 통신 방법에 있어서,
    완전성 인증 프로토콜을 탑재한 상기 제 1통신 장치가, 동일한 완전성 인증 프로토콜을 탑재한 상기 제 2통신 장치와 통신할 때는, 상기 접속 순서 수단의 판단 정보에 의거하여 상기 완전성 인증 결정 수단에 의해, 상기 완전성 인증 정보를 부가한 TCP 또는 UDP를 처리하는 완전성 인증 프로토콜 처리를 실시하여 송신하고, 상기 완전성 인증 프로토콜을 탑재한 상기 제 1 또는 제 2통신 장치가, 상기 완전성 인증 프로토콜을 탑재하지 않은 상기 제 3통신 장치와 통신할 때는, 상기 접속 순서 수단의 판단 정보에 의거하여 상기 완전성 인증 결정 수단에 의해, 상기 완전성 인증 정보를 부가하지 않는 것을 결정하고, 통상의 TCP 또는 UDP를 처리하는 통상 프로토콜 처리를 실시하여 상기 제 3통신 장치와 통신을 실시하든지, 상기 완전성 인증 결정을 하지 않고 상기 제 3통신 장치와 통신을 실시하지 않든지의 어느 쪽인가를 선택하도록 구성된 것을 특징으로 하는 통신 방법.
  22. 삭제
  23. 제 20항에 있어서,
    상기 완전성 인증 결정 스텝에 있어서 결정의 후보가 될 수 있는 완전성 인증 정보를 부가하기 위한 완전성 인증 논리 회로를 메모리에 기억 내지 회로에 실장하는 스텝과, 이 기억 내지 실장한 내용을 정기적으로 변경하는 완전성 인증 논리 회로 변경 스텝을 한층 더 갖추도록 구성된 것을 특징으로 하는 통신 방법.
  24. 제 20항에 있어서,
    상기 완전성 인증 결정 스텝에 있어서, 완전성 인증 정보를 부가하기 위한 완전성 인증 논리 회로에 의해 완전성 인증 정보 부가를 하지 않는 취지를 결정할 수 있도록 구성된 것을 특징으로 하는 통신 방법.
  25. 제 20항에 있어서,
    상기 완전성 인증 결정 스텝보다 전에, 통신 상대를 인증하는 스텝을 한층 더 포함하도록 구성된 것을 특징으로 하는 통신 방법.
  26. 트랜스포트층에 위치하는 TCP 또는 UDP 프로토콜에 암호화 기능을 추가하여 통신을 실시하는 통신 시스템을 실현하는 프로그램에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 기능과,
    통신로의 양단에서 대응하는 암호화 및 복호화 논리 회로를 결정하는 결정 기능과,
    송수신하는 정보 단위의 패킷 중, 적어도 상기 프로트콜의 페이로드를 상기 결정 수단에 의해 결정한 암호화 논리 회로에 따라서 송신하는 프로토콜을 암호화하는 기능과,
    수신한 상기 암호화된 프로토콜의 페이로드를 상기 결정에 의해 결정한 복호화 논리 회로에 따라서 복호화하는 프로토콜 복호화 기능을 구비하고,
    상기 통신 상대가 정당한 권한을 가진다고 판단했을 때에는, 상기 TCP 또는 UDP 프로토콜을 이용하여 상기 암호화 및 복호화 논리 회로를 실시한 통신 기능을 실현하도록 구성된 것을 특징으로 하는 통신 프로그램.
  27. 트랜스포트층에 있는 TCP 또는 UDP에 해당하는 프로토콜에 인증 기능을 추가하여 통신하는 통신 시스템을 실현하는 컴퓨터 프로그램에 있어서,
    상기 TCP 또는 UDP 프로토콜을 이용하여 통신 상대가 정당한 권한을 가지는 통신 상대인지 어떤지를 판단한 후에 통신 상대와의 접속을 실시하는 기능과,
    통신로의 양단에서 대응하는 완전성 인증 논리 회로를 결정하는 완전성 인증 결정 기능과,
    송수신하는 정보 단위인 패킷 중, 적어도 상기 TCP 또는 UDP에 해당하는 프로토콜의 페이로드를 상기 완전성 인증 결정에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증 정보를 부가하여 송신하는 프로토콜 완전성 인증 정보 부가 기능과,
    수신한 이 완전성 인증 정보가 부가된 프로토콜을 상기 완전성 인증 결정에 의해 결정한 완전성 인증 논리 회로에 따라서 완전성 인증하는 프로토콜 완전성 인증 기능을 구비하고,
    상기 통신 상대가 정당한 권한을 가진다고 판단했을 때에는, 상기 TCP 또는 UDP 프로토콜을 이용하여 상기 완전성 인증 논리 회로를 실시하여 통신하는 기능을 실현하기 위한 통신 프로그램.
KR1020057024375A 2003-08-08 2004-07-30 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램 KR101055861B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JPJP-P-2003-00290822 2003-08-08
JP2003290822 2003-08-08
PCT/JP2004/011304 WO2005015827A1 (ja) 2003-08-08 2004-07-30 通信システム、通信装置、通信方法、及びそれを実現するための通信プログラム

Publications (2)

Publication Number Publication Date
KR20060059908A KR20060059908A (ko) 2006-06-02
KR101055861B1 true KR101055861B1 (ko) 2011-08-09

Family

ID=34131609

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057024375A KR101055861B1 (ko) 2003-08-08 2004-07-30 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램

Country Status (12)

Country Link
US (4) US8041816B2 (ko)
EP (1) EP1653660A4 (ko)
JP (1) JP3783142B2 (ko)
KR (1) KR101055861B1 (ko)
CN (1) CN1833403B (ko)
AU (1) AU2004302108C1 (ko)
CA (1) CA2534919C (ko)
IL (1) IL173316A (ko)
IN (1) IN2014DN00130A (ko)
NO (1) NO20056234L (ko)
TW (1) TW200518516A (ko)
WO (1) WO2005015827A1 (ko)

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343413B2 (en) 2000-03-21 2008-03-11 F5 Networks, Inc. Method and system for optimizing a network by independently scaling control segments and data flow
US8380854B2 (en) 2000-03-21 2013-02-19 F5 Networks, Inc. Simplified method for processing multiple connections from the same client
JP4898168B2 (ja) 2005-03-18 2012-03-14 キヤノン株式会社 通信システム、通信装置、通信方法、及びプログラム
JP5389145B2 (ja) * 2005-03-18 2014-01-15 キヤノン株式会社 通信システム、通信方法、及びプログラム
US7706314B2 (en) * 2005-05-20 2010-04-27 Cisco Technology, Inc. Approach for implementing IPsec in performance enhancing proxy (PEP) environments
JP2006352676A (ja) * 2005-06-17 2006-12-28 Toshiba Corp 情報処理装置およびその制御方法
WO2007069327A1 (ja) * 2005-12-15 2007-06-21 Fujitsu Limited 中継装置，中継方法，中継用プログラム，中継用プログラムを記録したコンピュータ読取可能な記録媒体および情報処理装置
JP4757088B2 (ja) * 2006-04-25 2011-08-24 株式会社Ｉｎｔｏ 中継装置
JP4783665B2 (ja) * 2006-04-25 2011-09-28 株式会社Ｉｎｔｏ メールサーバ装置
JP4866150B2 (ja) * 2006-05-30 2012-02-01 株式会社Ｉｎｔｏ Ｆｔｐ通信システム、ｆｔｐ通信プログラム、ｆｔｐクライアント装置及びｆｔｐサーバ装置
JP4855147B2 (ja) * 2006-05-30 2012-01-18 株式会社Ｉｎｔｏ クライアント装置、メールシステム、プログラム及び記録媒体
JP2007329750A (ja) * 2006-06-08 2007-12-20 Ttt Kk 暗号化通信システム
US20080022388A1 (en) * 2006-06-30 2008-01-24 Karanvir Grewal Method and apparatus for multiple inclusion offsets for security protocols
EP2043296A4 (en) * 2006-07-13 2011-04-20 Keiko Ogawa RELAY DEVICE
JP2008060817A (ja) * 2006-08-30 2008-03-13 Ttt Kk 通信システム、ウェブサーバ装置、クライアント装置、通信を行うための通信プログラム及びプログラムを記録した記録媒体
US7433226B2 (en) * 2007-01-09 2008-10-07 Macronix International Co., Ltd. Method, apparatus and computer program product for read before programming process on multiple programmable resistive memory cell
JP2008287519A (ja) * 2007-05-17 2008-11-27 Keiko Ogawa データ暗号化伝送保存システム及びリムーバブルメディア
KR100889670B1 (ko) * 2007-08-08 2009-03-19 삼성에스디에스 주식회사 모바일 디바이스상에서 ｔｃｐ 기반의 서비스거부 공격의 차단 방법
FI120479B (fi) * 2007-12-05 2009-10-30 Telcont Oy Menetelmä ja päätelaite yhteyden muodostamiseksi laitteeseen
KR100977365B1 (ko) * 2007-12-20 2010-08-20 삼성에스디에스 주식회사 바이러스 및 네트워크 공격에 대한 자기 방어 기능을 갖는모바일 디바이스 및 이를 이용한 자기 방어 방법
US8671202B2 (en) * 2007-12-20 2014-03-11 Ooma, Inc. Mechanisms for role negotiation in the establishment of secure communication channels in peer-to-peer environments
WO2009117844A1 (en) * 2008-03-25 2009-10-01 Alcatel Shanghai Bell Co., Ltd. Methods and entities using ipsec esp to support security functionality for udp-based oma enablers
US8806053B1 (en) 2008-04-29 2014-08-12 F5 Networks, Inc. Methods and systems for optimizing network traffic using preemptive acknowledgment signals
US8799809B1 (en) 2008-06-04 2014-08-05 United Services Automobile Association (Usaa) Systems and methods for key logger prevention security techniques
CN101521667B (zh) * 2009-04-15 2012-04-04 山东渔翁信息技术股份有限公司 一种安全的数据通信方法及装置
US8868961B1 (en) 2009-11-06 2014-10-21 F5 Networks, Inc. Methods for acquiring hyper transport timing and devices thereof
US10721269B1 (en) 2009-11-06 2020-07-21 F5 Networks, Inc. Methods and system for returning requests with javascript for clients before passing a request to a server
CN101808142B (zh) * 2010-03-10 2013-03-27 上海十进制网络信息技术有限公司 通过路由器或交换机实现可信网络连接的方法和装置
US9294506B2 (en) * 2010-05-17 2016-03-22 Certes Networks, Inc. Method and apparatus for security encapsulating IP datagrams
US9141625B1 (en) 2010-06-22 2015-09-22 F5 Networks, Inc. Methods for preserving flow state during virtual machine migration and devices thereof
US10015286B1 (en) 2010-06-23 2018-07-03 F5 Networks, Inc. System and method for proxying HTTP single sign on across network domains
US8908545B1 (en) 2010-07-08 2014-12-09 F5 Networks, Inc. System and method for handling TCP performance in network access with driver initiated application tunnel
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US9083760B1 (en) 2010-08-09 2015-07-14 F5 Networks, Inc. Dynamic cloning and reservation of detached idle connections
CN101945105B (zh) * 2010-08-31 2013-05-08 施昊 网络信息收发系统及方法
US8886981B1 (en) 2010-09-15 2014-11-11 F5 Networks, Inc. Systems and methods for idle driven scheduling
US8804504B1 (en) 2010-09-16 2014-08-12 F5 Networks, Inc. System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device
US9554276B2 (en) 2010-10-29 2017-01-24 F5 Networks, Inc. System and method for on the fly protocol conversion in obtaining policy enforcement information
WO2012058486A2 (en) 2010-10-29 2012-05-03 F5 Networks, Inc. Automated policy builder
US8971539B2 (en) * 2010-12-30 2015-03-03 Verisign, Inc. Management of SSL certificate escrow
US10135831B2 (en) 2011-01-28 2018-11-20 F5 Networks, Inc. System and method for combining an access control system with a traffic management system
US9246819B1 (en) 2011-06-20 2016-01-26 F5 Networks, Inc. System and method for performing message-based load balancing
JP4843116B1 (ja) * 2011-08-22 2011-12-21 株式会社Ｉｎｔｏ ネットワークゲートウェイ装置
US9270766B2 (en) 2011-12-30 2016-02-23 F5 Networks, Inc. Methods for identifying network traffic characteristics to correlate and manage one or more subsequent flows and devices thereof
US10230566B1 (en) 2012-02-17 2019-03-12 F5 Networks, Inc. Methods for dynamically constructing a service principal name and devices thereof
US9231879B1 (en) 2012-02-20 2016-01-05 F5 Networks, Inc. Methods for policy-based network traffic queue management and devices thereof
US9172753B1 (en) 2012-02-20 2015-10-27 F5 Networks, Inc. Methods for optimizing HTTP header based authentication and devices thereof
US10097616B2 (en) 2012-04-27 2018-10-09 F5 Networks, Inc. Methods for optimizing service of content requests and devices thereof
US10984415B2 (en) * 2012-06-25 2021-04-20 Li Tan System and methods for using limit-use encrypted code to transfer values securely among users
US9729309B2 (en) * 2012-12-19 2017-08-08 Intel Corporation Securing data transmission between processor packages
US9231918B2 (en) * 2013-02-19 2016-01-05 Cisco Technology, Inc. Use of virtual network interfaces and a websocket based transport mechanism to realize secure node-to-site and site-to-site virtual private network solutions
US10375155B1 (en) 2013-02-19 2019-08-06 F5 Networks, Inc. System and method for achieving hardware acceleration for asymmetric flow connections
US10187317B1 (en) 2013-11-15 2019-01-22 F5 Networks, Inc. Methods for traffic rate control and devices thereof
US10015143B1 (en) 2014-06-05 2018-07-03 F5 Networks, Inc. Methods for securing one or more license entitlement grants and devices thereof
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10122630B1 (en) 2014-08-15 2018-11-06 F5 Networks, Inc. Methods for network traffic presteering and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US11350254B1 (en) 2015-05-05 2022-05-31 F5, Inc. Methods for enforcing compliance policies and devices thereof
US10505818B1 (en) 2015-05-05 2019-12-10 F5 Networks. Inc. Methods for analyzing and load balancing based on server health and devices thereof
KR102335741B1 (ko) * 2015-08-13 2021-12-06 삼성전자주식회사 이동 통신 시스템에서 빔포밍된 csi-rs를 이용하는 통신 기법
US10432754B2 (en) 2015-09-16 2019-10-01 Profire Energy, Inc Safety networking protocol and method
US10514683B2 (en) 2015-09-16 2019-12-24 Profire Energy, Inc. Distributed networking system and method to implement a safety state environment
US10348867B1 (en) * 2015-09-30 2019-07-09 EMC IP Holding Company LLC Enhanced protocol socket domain
US11757946B1 (en) 2015-12-22 2023-09-12 F5, Inc. Methods for analyzing network traffic and enforcing network policies and devices thereof
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US11178150B1 (en) 2016-01-20 2021-11-16 F5 Networks, Inc. Methods for enforcing access control list based on managed application and devices thereof
JP2017220890A (ja) * 2016-06-10 2017-12-14 システムプラザ株式会社 暗号通信システム及び暗号通信方法
US10791088B1 (en) 2016-06-17 2020-09-29 F5 Networks, Inc. Methods for disaggregating subscribers via DHCP address translation and devices thereof
CN106102051A (zh) * 2016-08-26 2016-11-09 北京方研矩行科技有限公司 一种局域网内安全发现智能设备的方法
US11063758B1 (en) 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US10505792B1 (en) 2016-11-02 2019-12-10 F5 Networks, Inc. Methods for facilitating network traffic analytics and devices thereof
US10812266B1 (en) 2017-03-17 2020-10-20 F5 Networks, Inc. Methods for managing security tokens based on security violations and devices thereof
US10972453B1 (en) 2017-05-03 2021-04-06 F5 Networks, Inc. Methods for token refreshment based on single sign-on (SSO) for federated identity environments and devices thereof
US11122042B1 (en) 2017-05-12 2021-09-14 F5 Networks, Inc. Methods for dynamically managing user access control and devices thereof
US11343237B1 (en) 2017-05-12 2022-05-24 F5, Inc. Methods for managing a federated identity environment using security and access control data and devices thereof
CN111033599B (zh) * 2017-08-22 2023-04-28 日本电信电话株式会社 协商系统、协商装置以及记录介质
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
KR102460071B1 (ko) * 2017-12-21 2022-10-28 삼성전자주식회사 통신모뎀 전단의 통신신호 식별 장치 및 방법
US11044200B1 (en) 2018-07-06 2021-06-22 F5 Networks, Inc. Methods for service stitching using a packet header and devices thereof
US11418491B2 (en) * 2020-02-26 2022-08-16 Cisco Technology, Inc. Dynamic firewall discovery on a service plane in a SDWAN architecture
US11395329B2 (en) * 2020-06-19 2022-07-19 Qualcomm Incorporated Uplink traffic prioritization across multiple links
US11831539B2 (en) 2022-02-03 2023-11-28 Karunesh Rama KAIMAL Methods and systems of sharing encrypted organization data packets among network devices based on service-oriented protocol

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020008797A (ko) * 2000-07-24 2002-01-31 이데이 노부유끼 데이터 처리 장치, 데이터 처리 방법, 라이센스 시스템,및 프로그램 제공 매체
KR20020076701A (ko) * 2001-03-30 2002-10-11 파츠닉(주) 극초단파 입력필터회로

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6058478A (en) * 1994-09-30 2000-05-02 Intel Corporation Apparatus and method for a vetted field upgrade
US5764915A (en) * 1996-03-08 1998-06-09 International Business Machines Corporation Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack
US6055575A (en) * 1997-01-28 2000-04-25 Ascend Communications, Inc. Virtual private network system and method
US6233624B1 (en) * 1997-05-08 2001-05-15 Microsoft Corporation System and method for layering drivers
US6704866B1 (en) * 1997-07-11 2004-03-09 Cisco Technology, Inc. Compression and encryption protocol for controlling data flow in a network
FI105753B (fi) * 1997-12-31 2000-09-29 Ssh Comm Security Oy Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa
US6148336A (en) * 1998-03-13 2000-11-14 Deterministic Networks, Inc. Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering
US6781991B1 (en) * 1999-02-26 2004-08-24 Lucent Technologies Inc. Method and apparatus for monitoring and selectively discouraging non-elected transport service over a packetized network
US6957346B1 (en) * 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations
US7370348B1 (en) * 1999-07-30 2008-05-06 Intel Corporation Technique and apparatus for processing cryptographic services of data in a network system
GB2353676A (en) 1999-08-17 2001-02-28 Hewlett Packard Co Robust encryption and decryption of packetised data transferred across communications networks
US7581110B1 (en) * 1999-08-25 2009-08-25 Nokia Corporation Key distribution for encrypted broadcast data using minimal system bandwidth
US20010052072A1 (en) * 2000-01-25 2001-12-13 Stefan Jung Encryption of payload on narrow-band IP links
US6880017B1 (en) * 2000-03-20 2005-04-12 International Business Machines Corporation System and method for providing an adaptive streaming flow control mechanism between the TCP and IP layers of the TCP/IP suite of protocols
US7536726B2 (en) 2000-05-09 2009-05-19 Microsoft Corporation Restricted software and hardware usage on a computer
US20030014624A1 (en) * 2000-07-31 2003-01-16 Andes Networks, Inc. Non-proxy internet communication
US20020042875A1 (en) * 2000-10-11 2002-04-11 Jayant Shukla Method and apparatus for end-to-end secure data communication
KR100501080B1 (ko) * 2000-12-19 2005-07-18 노병희 인터넷상 트래픽의 상위 계층 프로토콜들을 구분하는 방법및 장치
US6845397B1 (en) * 2000-12-29 2005-01-18 Nortel Networks Limited Interface method and system for accessing inner layers of a network protocol
JP3859450B2 (ja) 2001-02-07 2006-12-20 富士通株式会社 秘密情報管理システムおよび情報端末
US20030156715A1 (en) * 2001-06-12 2003-08-21 Reeds James Alexander Apparatus, system and method for validating integrity of transmitted data
US20050210243A1 (en) * 2001-09-28 2005-09-22 Archard Paul L System and method for improving client response times using an integrated security and packet optimization framework
US7289509B2 (en) * 2002-02-14 2007-10-30 International Business Machines Corporation Apparatus and method of splitting a data stream over multiple transport control protocol/internet protocol (TCP/IP) connections
US7127613B2 (en) * 2002-02-25 2006-10-24 Sun Microsystems, Inc. Secured peer-to-peer network data exchange
US7373663B2 (en) * 2002-05-31 2008-05-13 Alcatel Canada Inc. Secret hashing for TCP SYN/FIN correspondence
US20040260921A1 (en) * 2002-07-18 2004-12-23 Treadwell William S. Cryptographic method, system and engine for enciphered message transmission
US7069438B2 (en) * 2002-08-19 2006-06-27 Sowl Associates, Inc. Establishing authenticated network connections
US7594262B2 (en) * 2002-09-04 2009-09-22 Secure Computing Corporation System and method for secure group communications
KR100477513B1 (ko) * 2002-11-25 2005-03-17 전자부품연구원 이기종 프로토콜간 상호 데이터 전송을 위한 공통프로토콜 계층 구조 및 방법과 공통 프로토콜 패킷
US7949785B2 (en) * 2003-03-31 2011-05-24 Inpro Network Facility, Llc Secure virtual community network system
US7526640B2 (en) * 2003-06-30 2009-04-28 Microsoft Corporation System and method for automatic negotiation of a security protocol
US7191248B2 (en) * 2003-08-29 2007-03-13 Microsoft Corporation Communication stack for network communication and routing
US20050060538A1 (en) * 2003-09-15 2005-03-17 Intel Corporation Method, system, and program for processing of fragmented datagrams
US20050086342A1 (en) * 2003-09-19 2005-04-21 Andrew Burt Techniques for client-transparent TCP migration
US20050175184A1 (en) * 2004-02-11 2005-08-11 Phonex Broadband Corporation Method and apparatus for a per-packet encryption system
CA2574776A1 (en) * 2004-07-23 2006-02-02 Citrix Systems, Inc. Systems and methods for optimizing communications between network nodes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020008797A (ko) * 2000-07-24 2002-01-31 이데이 노부유끼 데이터 처리 장치, 데이터 처리 방법, 라이센스 시스템,및 프로그램 제공 매체
KR20020076701A (ko) * 2001-03-30 2002-10-11 파츠닉(주) 극초단파 입력필터회로

Also Published As

Publication number Publication date
US20140115320A1 (en) 2014-04-24
IN2014DN00130A (ko) 2015-05-22
AU2004302108A1 (en) 2005-02-17
CA2534919A1 (en) 2005-02-17
KR20060059908A (ko) 2006-06-02
US20140223169A1 (en) 2014-08-07
US20060190720A1 (en) 2006-08-24
TW200518516A (en) 2005-06-01
IL173316A (en) 2010-12-30
NO20056234L (no) 2006-05-08
US8799505B2 (en) 2014-08-05
US9749449B2 (en) 2017-08-29
CN1833403B (zh) 2011-05-25
AU2004302108C1 (en) 2010-09-16
TWI362859B (ko) 2012-04-21
US8041816B2 (en) 2011-10-18
CN1833403A (zh) 2006-09-13
JP3783142B2 (ja) 2006-06-07
JPWO2005015827A1 (ja) 2006-10-12
US20120066489A1 (en) 2012-03-15
EP1653660A1 (en) 2006-05-03
CA2534919C (en) 2011-04-05
EP1653660A4 (en) 2011-12-28
WO2005015827A1 (ja) 2005-02-17
IL173316A0 (en) 2006-06-11
AU2004302108B2 (en) 2010-02-25

Similar Documents

Publication Publication Date Title
KR101055861B1 (ko) 통신 시스템, 통신 장치, 통신 방법 및 그것을 실현하기위한 통신 프로그램
US7353380B2 (en) Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols
EP1746801A2 (en) Transmission of packet data over a network with a security protocol
US20100077203A1 (en) Relay device
JP2004295891A (ja) パケットペイロードを認証する方法
CN113904809B (zh) 一种通信方法、装置、电子设备及存储介质
WO2023036348A1 (zh) 一种加密通信方法、装置、设备及介质
JP4757088B2 (ja) 中継装置
JP4866150B2 (ja) Ｆｔｐ通信システム、ｆｔｐ通信プログラム、ｆｔｐクライアント装置及びｆｔｐサーバ装置
JP2007329750A (ja) 暗号化通信システム
JP4783665B2 (ja) メールサーバ装置
JP2007329751A (ja) 暗号化通信システム
JP2007019633A (ja) 中継コネクタ装置及び半導体回路装置
TW200841672A (en) Relaying apparatus
JP2008060817A (ja) 通信システム、ウェブサーバ装置、クライアント装置、通信を行うための通信プログラム及びプログラムを記録した記録媒体
JP2007324726A (ja) ファイル共有サーバ装置、クライアント装置、印刷装置、ファイル共有システム、ファイル共有プログラム
KR20090032072A (ko) 중계장치
JP2007019632A (ja) 通信ボード装置及び通信方法

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20140723

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20150723

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20160722

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20170726

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20180726

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20190724

Year of fee payment: 9