KR20190034048A

KR20190034048A - 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법

Info

Publication number: KR20190034048A
Application number: KR1020180002141A
Authority: KR
Inventors: 전상훈; 이원재; 김형섭
Original assignee: 삼성전자주식회사
Priority date: 2017-09-22
Filing date: 2018-01-08
Publication date: 2019-04-01

Abstract

본 개시의 기술적 사상의 일측면에 따른 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법은, 서버가 TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 클라이언트로부터 수신하는 단계, 서버가 제1 무결성 검증에 필요한 제1 검증 정보에 대한 요청을 포함하는 제2 메시지를 클라이언트에 전송하는 단계, 서버가 제1 검증 정보를 클라이언트로부터 수신하고, 제1 검증 정보를 이용하여 제1 무결성 검증을 수행하는 단계, 및 핸드쉐이크를 종료하고, 제1 무결성 검증 결과를 기반으로 클라이언트와 서버간 데이터 통신을 수행하는 단계를 포함할 수 있다.

Description

암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법 및 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트와 서버간 무결성 검증 방법{SERVER REGISTRATION METHOD OF CLIENT USING ENCRYPTION SECURITY PROTOCOL-BASED COMMUNICATION AND INTEGRITY VERIFICATION METHOD BETWEEN CLIENT AND SERVER USING THE SAME}

본 개시의 기술적 사상은 클라이언트의 서버 등록 방법 및 클라이언트와 서버간 무결성 검증 방법에 관한 것으로서, 자세하게는 암호화 보안 프로토콜을 기반으로 하는 클라이언트와 서버간 통신에서 클라이언트를 서버에 등록하고, 클라이언트 또는 서버에 대한 무결성 검증을 효율적으로 수행할 수 있는 방법에 관한 것이다.

TLS(Transport Layer Security) 또는 SSL(Secure Sockets Layer)은 인터넷 통신 보안을 제공하는 암호화 보안 프로토콜들이다. 이들은 인증 및 키 교환을 위해서 비대칭 암호화 기법을 이용하고, 기밀성을 위해서 대칭 암호화 기법을 이용할 수 있다. 특히, TLS는 RFC 5246 및 RFC 6176 등에서 정의된 IETF 표준 프로토콜일 수 있다. 종래에는 클라이언트-서버 컴퓨팅 시스템에서 표준 TLS 프로토콜 기반으로 클라이언트와 서버간 통신을 수행할 때에, 클라이언트 또는 서버에 대한 무결성 검증을 같이 수행할 수 없었다. 따라서, 클라이언트 또는 서버에 대한 무결성 검증을 하기 위해서 소정의 메시지 인증 코드들을 이용한 별도의 무결성 검증 수행이 요구되었다. 결국, 별도의 무결성 검증을 수행할 때마다, 매번 클라이언트-서버 컴퓨팅 시스템의 RF 자원들(Radio Frequency Resources)에 대한 사용이 필요하기 때문에, RF 자원들을 효율적으로 사용하지 못하는 문제가 있었다. 이에 따라, RF 자원들을 좀더 효율적으로 사용하기 위한 무결성 검증 방법이 요구된다.

본 개시의 기술적 사상은 클라이언트-서버 컴퓨팅 시스템에서 클라이언트를안전하게 서버에 등록하는 방법 및 클라이언트-서버 컴퓨팅 시스템의 RF 자원들을 효율적으로 사용하기 위한 클라이언트와 서버간의 무결성 검증을 수행하는 방법을 제공한다.

상기와 같은 목적을 달성하기 위하여, 본 개시의 기술적 사상의 일측면에 따른 클라이언트와 서버간 무결성 검증을 지원하는 암호화 보안 프로토콜 기반 통신 방법은, 서버가 TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 클라이언트로부터 수신하는 단계, 서버가 제1 무결성 검증에 필요한 제1 검증 정보에 대한 요청을 포함하는 제2 메시지를 클라이언트에 전송하는 단계, 서버가 제1 검증 정보를 클라이언트로부터 수신하고, 제1 검증 정보를 이용하여 제1 무결성 검증을 수행하는 단계, 및 핸드쉐이크를 종료하고, 제1 무결성 검증 결과를 기반으로 클라이언트와 서버간 데이터 통신을 수행하는 단계를 포함할 수 있다.

본 개시의 기술적 사상의 일측면에 따른 암호화 보안 프로토콜 기반 통신을 이용한 제1 클라이언트에 대한 무결성 검증 방법은, 제1 클라이언트와 소정의 네트워크를 통해 연결된 제2 클라이언트가 서버와의 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 서버에 전송하는 단계, 제2 클라이언트가 서버로부터 제1 클라이언트에 대한 제1 무결성 검증에 필요한 제1 클라이언트의 제1 검증 정보에 대한 요청을 포함하는 제2 메시지를 수신하는 단계, 및 제2 클라이언트가 제1 검증 정보를 서버에 전송하는 단계를 포함할 수 있다.

본 개시의 기술적 사상의 일측면에 따른 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법은, TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트에 대한 등록 요청을 서버에 전송하는 단계, 서버로부터 핀 정보를 수신하는 단계, 서버에 핀 정보가 입력 되었는지 여부를 나타내는 핀 인증 결과 정보 요청을 서버에 전송하는 단계, 서버에 핀 정보가 입력됨에 따라 서버로부터 핀 인증 결과 정보를 수신하는 단계, 및 서버로부터 서버에 접근할 수 있는 권한을 포함하는 액세스 토큰을 수신하는 단계를 포함할 수 있다.

본 개시의 기술적 사상의 일측면에 따른 암호화 보안 프로토콜 기반 통신을 이용한 제1 클라이언트의 서버 등록 방법은, 제2 클라이언트가 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트에 대한 등록 요청을 서버에 전송하는 단계, 제2 클라이언트가 서버로부터 핀 정보를 수신하고, 수신된 핀 정보를 제1 클라이언트에 전송하는 단계, 제2 클라이언트가 서버에 핀 정보가 입력 되었는지 여부를 나타내는 핀 인증 결과 정보 요청을 서버에 전송하는 단계, 제2 클라이언트가 서버에 핀 정보가 입력됨에 따라 서버로부터 핀 인증 결과 정보를 수신하는 단계, 및 제2 클라이언트가 서버로부터 제1 클라이언트가 서버에 접근할 수 있는 권한을 포함하는 액세스 토큰을 수신하고, 수신된 액세스 토큰을 제1 클라이언트에 전송하는 단계를 포함할 수 있다.

본 개시의 기술적 사상의 일측면에 따른 암호화 보안 프로토콜 기반 통신을 이용한 서버의 클라이언트 등록 방법은, TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트로부터 클라이언트에 대한 등록 요청을 수신하는 단계, 등록 요청에 응답하여, 클라이언트에 핀 정보를 할당하여, 핀 정보를 상기 클라이언트에 전송하는 단계, 서버에 핀 정보가 입력되었을 때, 핀 정보가 인증되었음을 나타내는 핀 인증 결과 정보를 클라이언트에 전송하는 단계, 및 클라이언트의 서버로의 접근 권한을 포함하는 액세스 토큰을 클라이언트에 전송하는 단계를 포함할 수 있다.

본 개시의 예시적 실시예에 따른 클라이언트와 서버간 암호화 보안 프로토콜 기반 통신 동작에 의하면, 핸드쉐이크 구간 내에서 클라이언트를 서버에 등록하거나, 클라이언트 또는 서버에 대한 무결성 검증을 더 수행할 수 있기 때문에, 무결성 검증을 수행하기 위하여 클라이언트-서버 컴퓨팅 시스템 내의 RF 자원들(Radio Frequency Resources)에 대한 사용이 요구되는 별도의 구간을 설정할 필요가 없어 RF 자원들에 대한 효율적인 사용이 가능할 수 있다.

또한, 본 개시의 기술적 사상에 따른 클라이언트와 서버간 암호화 보안 프로토콜 기반 통신 동작에 의하면, 클라이언트와 서버간의 데이터 통신을 위한 세션 연결 시에 클라이언트 또는 서버에 대한 무결성 검증 결과가 반영될 수 있기 때문에, 클라이언트와 서버간 통신의 보안성이 향상되는 효과가 있다.

도 1a는 본 개시의 일 실시예에 따른 클라이언트-서버 컴퓨팅 시스템을 개략적으로 나타내는 블록도이고, 도 1b는 도 1a의 TLS 프로토콜 스택을 구체적으로 설명하기 위한 도면이다.
도 2는 본 개시의 일 실시예에 따른 클라이언트의 서버 등록을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 3은 본 개시의 일 실시예에 따른 클라이언트의 서버 등록을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 4는 본 개시의 일 실시예에 따른 무결성 검증을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 5는 본 개시의 일 실시예에 따른 도 1b의 핸드쉐이크 프로토콜을 구체적으로 설명하기 위한 도면이다.
도 6a는 본 개시의 일 실시예에 따른 무결성 검증을 위해 필요한 검증 정보에 대하여 구체적인 설명을 위한 도면이며, 도 6b 내지 도 6d는 도 6a의 소프트웨어 설정 타입에 관한 구체적인 설명을 위한 도면이다.
도 7a는 본 개시의 일 실시예에 따른 인증서를 발행받는 방법을 설명하기 위한 블록도이고, 도 7b는 인증서에 포함된 무결성 검증 관련 정보들을 설명하기 위한 도면이며, 도 7c는 무결성 검증 관련 정보들이 인증서가 아닌 보안 메모리 영역에 저장된 실시예를 설명하기 위한 블록도이다.
도 7d는 소프트웨어 설정 값을 생성하는 방법을 설명하기 위한 순서도이다.
도 8a는 도 7b와 같이, 인증서에 소프트웨어 설정 정보가 포함된 경우에 클라이언트와 서버간 제1 무결성 검증 동작을 설명하기 위한 순서도이고, 도 8b는 도 7c와 같이, 보안 메모리 영역에 소프트웨어 설정 정보가 저장된 경우에 클라이언트와 서버간 제1 무결성 검증 동작을 설명하기 위한 순서도이다.
도 9는 도 8a의 소프트웨어 설정 서명 정보를 생성하는 방법을 설명하기 위한 순서도이다.
도 10은 도 8a의 S250 단계를 구체적으로 설명하기 위한 순서도이다.
도 11은 본 개시의 일 실시예에 따른 제2 무결성 검증을 수행하는 방법을 설명하기 위한 순서도이다.
도 12는 본 개시의 일 실시예에 따른 클라이언트 및 서버간의 핸드쉐이크 구간 내의 검증 동작을 설명하기 위한 순서도이다.
도 13은 본 개시의 일 실시예에 따른 무결성 검증 동작의 기반이 되는 명령들이 저장된 저장 매체를 나타내는 블록도이다.
도 14는 본 개시의 일실시예에 따른 제1 및 제2 클라이언트-서버 컴퓨팅 시스템을 개략적으로 나타내는 블록도이다.
도 15는 본 개시의 일실시예에 따른 제1 클라이언트에 대한 서버 등록을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 16은 본 개시의 일실시예에 따른 제1 클라이언트에 대한 서버 등록을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 17a는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 네트워크 인증 시스템을 나타낸다.
도 17b는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 인증키 생성 프로토콜을 나타낸다.
도 17c는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 인증 메시지 생성 프로토콜을 나타낸다.
도 17d는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 인증 메시지 검증 프로토콜을 나타낸다.
도 18은 본 개시의 일실시예에 따른 제1 클라이언트에 대한 무결성 검증을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.
도 19a는 도 7b와 같이, 인증서에 소프트웨어 설정 정보가 포함된 경우에 제1 클라이언트에 대한 제1 무결성 검증 동작을 설명하기 위한 순서도이고, 도 19b는 도 7c와 같이, 보안 메모리 영역에 소프트웨어 설정 정보가 저장된 경우에 제1 클라이언트에 대한 제1 무결성 검증 동작을 설명하기 위한 순서도이다.
도 20은 본 개시의 일실시예에 따른 제1 클라이언트, 제2 클라이언트 및 서버 간의 핸드쉐이크 구간 내의 검증 동작을 설명하기 위한 순서도이다.
도 21은 본 개시의 실시예들이 적용된 IoT 네트워크 시스템을 보여주는 개념도이다.

이하, 첨부한 도면을 참조하여 본 발명의 실시예에 대해 상세히 설명한다.

도 1a는 본 개시의 일 실시예에 따른 클라이언트-서버 컴퓨팅 시스템(100)을 개략적으로 나타내는 블록도이고, 도 1b는 도 1a의 TLS 프로토콜 스택(126)을 구체적으로 설명하기 위한 도면이다.

도 1a를 참조하면, 클라이언트-서버 컴퓨팅 시스템(100)은 복수의 클라이언트들(또는, 클라이언트 컴퓨팅 장치들, 120) 및 복수의 서버들(또는, 서버 컴퓨팅 장치들, 140)을 포함할 수 있고, 클라이언트(120)와 서버(140)는 소정의 네트워크를 통해 연결될 수 있다.

클라이언트-서버 컴퓨팅 시스템(100)은 IoT 네트워크 시스템일 수 있다. 복수의 클라이언트들(120)은 각각 IoT 장치들일 수 있으며, 복수의 서버들(140)은 허브 장치(또는, 엑세스 포인트) 또는 공유기 장치일 수 있다. 또한, 클라이언트-서버 컴퓨팅 시스템(100)은 클라우드 컴퓨팅 보안 시스템(Cloud Computing Security System)일 수 있다. 복수의 서버들(140)은 클라우드 서비스를 제공하기 위한 클라우드 서비스 제공 서버들일 수 있으며, 복수의 클라이언트들(120)은 클라이언트 서비스를 이용하기 위한 장치들일 수 있다.

클라이언트-서버 컴퓨팅 시스템(100)은 USN(Ubiquitous Sensor Network) 통신 시스템, MTC(Machine Type Communication) 시스템, MOC(Machine Oriented Communication) 시스템, M2M(Machine to Machine) 통신 시스템 또는 D2D(Device to Device) 통신 시스템 등 중 어느 하나에 해당할 수 있다. 클라이언트-서버 컴퓨팅 시스템(100)은 클라이언트(120)와 서버(140) 간의 통신을 위해 UDP(User Datagram Protocol), TCP(Transmission Control Protocol) 등의 전송 프로토콜, IPv6 인터넷 라우팅 프로토콜 및 CoAP(Constrained Application Protocol), HTTP(Hypertext Transfer Protocol), MQTT(Message Queue Telemetry Transport), MQTT-S(MQTT for Sensors networks) 등의 애플리케이션 프로토콜을 이용할 수 있다.

클라이언트들(120)은 유선/무선 인터페이스를 통해 서버들(140)과, 또는 상호 간에 통신할 수 있다. 유선/무선 인터페이스는 유선 근거리 통신망(Local Area Network; LAN), WiFi(Wireless Fidelity)와 같은 무선 근거리 통신망(Wireless Local Area Network; WLAN), 블루투스(Bluetooth)와 같은 무선 개인 통신망(Wireless Personal Area Network; WPAN), 무선 USB(Wireless Universal Serial Bus), Zigbee, NFC(Near Field Communication), RFID(Radio-frequency identification), PLC(Power Line Communication), 또는 3G(3rd Generation), 4G(4th Generation), LTE(Long Term Evolution) 등의 이동 통신망(Mobile Cellular Network)에 접속 가능한 모뎀 통신 인터페이스 등을 포함할 수 있다.

일 예로, 클라이언트(120)와 서버(140)는 네트워크(160)를 통해 데이터 신호를 송수신하는 데이터 통신을 수행할 수 있다. 구체적으로, 암호화 보안 프로토콜을 통해 클라이언트(120)와 서버(140)는 연결될 수 있으며, 이를 통해 클라이언트(120)와 서버(140)간의 통신에 대한 제3자의 해킹을 방지하고, 데이터 무결성을 확보할 수 있다. 본 개시에서 클라이언트(120)와 서버(140)간의 통신을 위해 이용되는 암호화 보안 프로토콜은 SSL(Secure Socket Layer) 프로토콜 또는 TLS(Transprot Layer Security) 프로토콜일 수 있다. 이하에서는, TLS 프로토콜을 이용하는 클라이언트-서버 컴퓨팅 시스템(100)을 중심으로 서술하도록 하겠다.

클라이언트(120)는 애플리케이션 프로세서(122) 및 베이스밴드 프로세서(124)를 포함할 수 있다. 베이스밴드 프로세서(124)는 클라이언트(120)와 서버(140)간의 TLS 기반의 통신을 수행하기 위해 필요한 TLS 프로토콜 스택(126)을 포함할 수 있다. 애플리케이션 프로세서(122)는 TLS 프로토콜 스택(126)을 기반으로 클라이언트(120)와 서버(140)간 연결을 위한 일련의 동작을 제어할 수 있다. 또한, 애플리케이션 프로세서(122)는 상위 레이어 기능 프로세싱(예를 들면, 애플리케이션 레이어 및/또는 트랜스포트 레이어)을 제공할 수 있고, 베이스밴드 프로세서(124)는 하위 레이어 기능 프로세싱(예를 들면, 피지컬 레이어 및/또는 네트워크 레이어)을 제공할 수 있다.

서버(140)는 애플리케이션 프로세서(122) 및 베이스밴드 프로세서(124)를 포함할 수 있다. 베이스밴드 프로세서(144)는 서버(140)와 클라이언트(120)간의 TLS 기반의 통신을 수행하기 위해 필요한 TLS 프로토콜 스택(146)을 포함할 수 있다. 애플리케이션 프로세서(142)는 TLS 프로토콜 스택(146)을 기반으로 서버(140)와 클라이언트(120)간 연결을 위한 일련의 동작을 제어할 수 있다. 또한, 애플리케이션 프로세서(142)는 상위 레이어 기능 프로세싱을 제공할 수 있고, 베이스밴드 프로세서(144)는 하위 레이어 기능 프로세싱을 제공할 수 있다.

도 1b에는 TLS 프로토콜 스택(126, 146)에 포함되는 프로토콜들을 구체적으로 나타낸다. 도 1b를 참조하면, TLS 프로토콜 스택(TLS_PT_S)은 핸드쉐이크(Handshake) 프로토콜(PT1), 사이퍼 체인지(Cipher Change) 프로토콜(PT2), 경고(Alert) 프로토콜(PT3) 및 레코드(Record) 프로토콜(PT4)을 포함할 수 있다. TLS 프로토콜 스택(TLS_PT_S)은 국제 인터넷 표준화 기구(Internet Engineering Task Force, IETF)의 표준 규약이며, 본 개시의 실시예들은 IETF의 표준 규약에 따를 수 있다.

클라이언트(120) 및 서버(140)는 핸드쉐이크 프로토콜(PT1)을 기반으로 클라이언트(120)와 서버(140)간의 TLS 연결을 위한 핸드쉐이크를 수행할 수 있다. 클라이언트(120) 및 서버(140)는 핸드쉐이크 구간 내에 클라이언트(120)와 서버(140)간에 송수신 데이터의 암호화 방법, TLS의 버전 정보 등을 서로 공유할 수 있다. 또한, 클라이언트(120)와 서버(140)는 핸드쉐이크 프로토콜(PT1)을 기반으로 클라이언트(120) 및 서버(140)의 각각에 대한 인증(authentication)을 수행할 수 있다.

클라이언트(120) 및 서버(140)는 사이퍼 체인지 프로토콜(PT2)을 기반으로 클라이언트(120)와 서버(140)간 핸드쉐이크의 결과로 결정된 파라미터들을 적용하여 향후 보안 통신을 수행할 것을 서로에게 알릴 수 있다. 클라이언트(120) 및 서버(140)는 경고 프로토콜(PT3)을 기반으로 보안 통신 중에 발생하는 에러들을 서로에게 리포팅(reporting)할 수 있다. 클라이언트(120) 및 서버(140)는 레코드 프로토콜(PT4)을 기반으로 트랜잭션 레이어(transaction layer)를 공유할 수 있고, 이는 클라이언트(120) 및 서버(140)간에 세션(session)이 연결된 것으로 지칭할 수 있다. 클라이언트(120) 및 서버(140)는 레코드 프로토콜(PT4)을 기반으로 세션(또는 트랜잭션 레이어)을 통해 암호화된 데이터를 서로 송수신할 수 있다.

본 개시의 일 실시예로, 핸드쉐이크 프로토콜(PT1)에는 클라이언트(120) 및 서버(140)에 대한 무결성 검증 동작(ITV(InTegrity Verification) operation)이 정의될 수 있다. 클라이언트(120)와 서버(140)간 핸드쉐이크 구간에서, 클라이언트(120)와 서버(140)는 핸드쉐이크 프로토콜(PT1)을 기반으로 서로의 데이터 무결성을 선택적으로(optional) 검증할 수 있다. 구체적으로, 클라이언트(120)는 서버(140)와의 핸드쉐이크를 수행하는 구간 내에서, 핸드쉐이크 프로토콜(PT1)을 기반으로 서버(140)에 대한 무결성을 검증할 수 있다. 또한, 서버(140)는 클라이언트(120)와의 핸드쉐이크를 수행하는 구간 내에서, 핸드쉐이크 프로토콜(PT2)을 기반으로 클라이언트(120)에 대한 무결성을 검증할 수 있다. 또한, 클라이언트(120)와 서버(140)간 핸드쉐이크 구간에서 클라이언트(120)와 서버(140)는 핸드쉐이크 프로토콜(PT1)을 기반으로 서로에 대한 인증 동작을 선택적으로 수행할 수 있다. 이후, 클라이언트(120)와 서버(140)간의 세션은 무결성 검증 결과 및 인증 결과 중 적어도 하나를 기반으로 연결될 수 있다.

본 개시에 따른 클라이언트(120)와 서버(140)간 TLS 기반 통신 동작은, 핸드쉐이크 구간 내에서 클라이언트(120)와 서버(140)에 대한 무결성 검증을 더 수행할 수 있기 때문에, 무결성 검증을 수행하기 위하여 클라이언트-서버 컴퓨팅 시스템(100) 내의 RF 자원들(Radio Frequency Resources)에 대한 사용이 요구되는 별도의 구간을 설정할 필요가 없어 RF 자원들에 대한 효율적인 사용이 가능할 수 있다. 또한, 클라이언트(120)와 서버(140)간의 세션 연결 시에 클라이언트(120) 또는 서버(140)에 대한 무결성 검증 결과가 반영될 수 있기 때문에, 클라이언트(120)와 서버(140)간 통신의 보안성이 향상되는 효과가 있다.

도 2는 본 개시의 일 실시예에 따른 클라이언트의 서버 등록을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 2를 참조하면, 클라이언트(120)와 서버(140)는 TLS 기반 핸드쉐이크를 시작할 수 있다(S10). 즉, 클라이언트(120)와 서버(140)는 TLS 프로토콜 스택의 핸드쉐이크 프로토콜을 기반으로 핸드쉐이크를 시작할 수 있다.

클라이언트(120)는 TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트(120)에 대한 등록 요청을 서버(140)에 전송할 수 있다. 클라이언트(120)에 대한 등록은, 클라이언트(120)가 서버(140)에 대한 접근 권한을 얻기 위해 클라이언트(120)를 서버(140)에 등록(register)하는 것을 나타낼 수 있다.

클라이언트(120)로부터 수신된 등록 요청에 응답하여, 서버(140)는 핀 정보를 클라이언트(120)에 전송할 수 있다(S30). 서버(140)는 핀 정보를 클라이언트(120)에 전송하기 전, 클라이언트의 정품 여부를 확인할 수 있고, 이는 도 3을 참조하여 설명된다.

서버(140)로부터 핀 정보를 수신함에 따라, 클라이언트(120)는 서버(140)에 핀 인증 결과 정보 요청을 전송할 수 있다(S40). 핀 인증 결과 정보는 서버(140)에 핀 정보가 올바르게 입력 되었는지 여부를 나타내는 정보일 수 있다. 예를 들어, 클라이언트(120)는 서버(140)로부터 핀 정보를 수신함에 따라, 클라이언트(120)에 포함된 시각적 표시 장치 및 청각적 표시 장치 중 적어도 하나를 포함하는 표시 장치를 통해 핀 정보를 상기 클라이언트(120)를 사용하는 사용자에게 알릴 수 있다. 사용자는 표시 장치에 표시된 핀 정보를 습득한 뒤, 핀 정보를 서버(140)에 입력할 수 있다. 클라이언트(120)는 사용자에 의해 서버(140)에 입력된 핀 정보가 클라이언트(120)에 전송된 핀 정보와 일치하는지 판단할 수 있다. 클라이언트(120)에 전송된 핀 정보와 사용자에 의해 입력된 핀 정보가 일치하는 경우, 핀 정보가 올바르게 입력되었다고 칭할 수 있다. 클라이언트(120)는 핀 정보가 올바르게 입력 되었는지 여부를 확인하기 위해 서버(140)에 핀 인증 결과 정보 요청을 전송할 수 있다.

사용자에 의해 서버(140)에 핀 정보가 입력될 수 있다(S50). 서버(140)는 올바른 핀 정보가 입력된 경우, 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 클라이언트(120)에 전송할 수 있다(S60). 클라이언트(120)는 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 수신함으로써 올바른 핀 정보가 입력되었음을 확인할 수 있다.

클라이언트(120)는 핀 인증 결과 정보 수신에 응답하여 등록 완료 신호를 서버(140)에 전송할 수 있다(S70). 서버(140)는 클라이언트(120)로부터 등록 완료 신호를 수신함에 따라 클라이언트(120)가 서버(140)에 접근할 수 있는 권한을 포함하는 액세스 토큰을 클라이언트(120)에 전송할 수 있다(S80). 이후, 클라이언트(120)는 액세스 토큰을 이용하여 서버(140)에 접근할 수 있다.

이후, 클라이언트(120)와 서버(140)는 TLS 기반 핸드쉐이크를 종료할 수 있다(S90).

본 개시의 예시적 실시예에 따른 암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법에 따르면, 핸드쉐이크 구간 내에서 클라이언트(120)를 서버(140)에 등록함으로써 클라이언트(120)를 서버(140)에 안전하게 등록할 수 있다.

도 3은 본 개시의 일 실시예에 따른 클라이언트의 서버 등록을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 3을 참조하면, 클라이언트(120)와 서버(140)는 TLS 기반 핸드쉐이크를 시작할 수 있다(S10). 즉, 클라이언트(120)와 서버(140)는 TLS 프로토콜 스택의 핸드쉐이크 프로토콜을 기반으로 핸드쉐이크를 시작할 수 있다.

클라이언트(120)는 TLS 연결의 핸드쉐이크를 시작하기 위해 클라이언트(120)에 대한 등록 요청을 서버(140)에 전송할 수 있고, 등록 요청과 함께 클라이언트(120)의 인증서 및 인증서 서명 정보를 서버(140)에 전송할 수 있다(S20).

서버(140)는 수신된 클라이언트(120)의 인증서 및 인증서 서명 정보를 이용해 클라이언트(120)의 정품 여부를 확인할 수 있다(S25). 예를 들어, 서버(140)는 클라이언트(120)의 인증서를 발행한 인증 기관의 공개키를 이용하여 클라이언트(120)의 인증서 서명 정보를 복호화하고, 복호화 값과 클라이언트(120)의 인증서의 인증된 속성들에 대한 정보를 비교함으로써 클라이언트(120)의 인증서를 검증할 수 있다. 클라이언트(120)의 인증서가 검증된 경우, 서버(140)는 클라이언트(120)가 정품인 것으로 판단할 수 있다.

서버(140)는 핀 정보를 클라이언트(120)에 전송할 수 있고, 핀 정보와 함께 핀 정보 만료 시간을 클라이언트(120)에 전송할 수 있다. 핀 정보 만료 시간은 핀 정보가 유효한 상태를 유지하는 시간을 나타낼 수 있다. 핀 정보 만료 시간은 시간 간격으로서 수 초 내지 수 분을 나타낼 수 있다. 이 경우, 핀 정보 만료 시간 동안 핀 정보가 유효할 수 있다. 하지만 이에 제한되는 것은 아니며, 예를 들어, 서버(140)는 클라이언트(120)에 절대 시각을 나타내는 핀 정보 만료 시간을 클라이언트(120)에 송신할 수 있다. 이 경우, 핀 정보 만료 시간이 될 때까지 핀 정보는 유효할 수 있다. 또한 서버(140)는 보안의 강화를 위해 랜덤 데이터를 함께 클라이언트(120)에 전송할 수 있다.

서버(140)로부터 핀 정보를 수신함에 따라, 클라이언트(120)는 서버(140)에 핀 인증 결과 정보 요청을 전송할 수 있다(S40). 핀 인증 결과 정보는 핀 정보 만료 시간 내에 서버(140)에 핀 정보가 올바르게 입력되었는지 여부를 나타내는 정보일 수 있다.

사용자에 의해 서버(140)에 핀 정보가 핀 정보 만료 시간 내에 입력될 수 있다(S50). 서버(140)는 올바른 핀 정보가 핀 정보 만료 시간 내에 입력된 경우, 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 클라이언트(120)에 전송할 수 있다(S60). 클라이언트(120)는 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 수신함으로써 올바른 핀 정보가 입력되었음을 확인할 수 있다.

클라이언트(120)는 핀 인증 결과 정보 수신에 응답하여 등록 완료 신호를 서버(140)에 전송할 수 있다(S70). 서버(140)는 클라이언트(120)로부터 등록 완료 신호를 수신함에 따라 클라이언트(120)가 서버(140)에 접근할 수 있는 권한을 포함하는 액세스 토큰을 클라이언트(120)에 전송할 수 있고, 클라이언트(120)를 식별하기 위한 유니크 식별자(Unique Identifier; Unique ID)를 함께 클라이언트(120)에 전송할 수 있다(S80). 이후, 클라이언트(120)는 액세스 토큰 및 유니크 식별자를 이용하여 서버(140)에 접근할 수 있다.

도 4는 본 개시의 일 실시예에 따른 무결성 검증을 수행하는 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 4를 참조하면, 클라이언트(120)와 서버(140)는 TLS 기반 핸드쉐이크를 시작할 수 있다(S100). 즉, 클라이언트(120)와 서버(140)는 TLS 프토토콜 스택의 핸드쉐이크 프로토콜을 기반으로 핸드쉐이크를 시작할 수 있다. 클라이언트(120)는 서버(140)에 제1 무결성 검증을 요청할 수 있다(S110). 제1 무결성 검증은 클라이언트(120)에 대한 무결성 검증을 의미할 수 있다. 서버(140)는 제1 무결성 검증 요청에 응답하여, 제1 무결성 검증에 필요한 제1 검증 정보를 클라이언트(120)에 요청할 수 있다(S120). 클라이언트(120)는 제1 검증 정보의 요청에 응답하여, 제1 검증 정보를 서버(140)에 전송할 수 있다(S130). 제1 검증 정보는 클라이언트(120)의 소프트웨어 설정 정보(software configuration information) 및 클라이언트(120)로부터 생성된 소프트웨어 설정 서명 정보(software configuration signature information)를 포함할 수 있다. 이에 대한 구체적인 내용은 후술한다. 서버(140)는 제1 검증 정보를 이용하여 클라이언트(120)에 대한 제1 무결성 검증을 수행할 수 있다(S140). 이후, 클라이언트(120)와 서버(140)는 TLS 기반 핸드쉐이크를 종료할 수 있다(S150). 클라이언트(120)와 서버(140)간의 세션은 무결성 검증 결과를 기반으로 연결될 수 있다(S160). 일 예로, 클라이언트(120)의 무결성이 확인되지 않은 때에는, 클라이언트(120)와 서버(140)간의 세션은 연결되지 않고, 클라이언트(120)의 무결성이 확인된 때에만, 클라이언트(120)와 서버(140)간의 세션이 연결되어, 암호화된 데이터 통신을 수행할 수 있다. 또한, 비제한적인 예시로서, 클라이언트(120)의 무결성이 확인되지 않은 경우, 서버(140)는 사용자의 핸드폰 등과 통신함으로써 사용자에게 클라이언트(120)가 외부의 악의적 소프트웨어에 의해 공격받았음을 알릴 수 있다. 악의적 소프트웨어는 멀웨어(Malware)라 칭해질 수 있으며, 멀웨어는 한정되지 않는 예시로서, 컴퓨터 바이러스, 웜(Worms), 트로이 목마, 스파이웨어, 정직하지 못한 애드웨어(Dishonest Adware), 스캐어웨어(Scareware), 크라임웨어(Crimeware) 및 다른 악의적인 소프트웨들 및 악의적인 프로그램들 중 적어도 하나를 포함할 수 있다.

다만, 도 4에서는 클라이언트(120)에 대한 무결성을 검증하는 서버(140)의 실시예에 대해서만 개시하였으나, 이에 국한되지 않고, 클라이언트(120)는 서버(140)에 대한 무결성을 검증할 수 있으며, 이에 대한 구체적인 실시예는 후술한다.

도 5는 본 개시의 일 실시예에 따른 도 1b의 핸드쉐이크 프로토콜(PT1)을 구체적으로 설명하기 위한 도면이다.

도 5를 참조하면, 핸드쉐이크 프로토콜(PT1)은 클라이언트와 서버간의 핸드쉐이크 방법에 대한 규약으로서, 핸드쉐이크 프로토콜(PT1)의 내용은 핸드쉐이크 프로토콜(PT1)에 대응하는 데이터 구조(DS)에 코드 형식으로 정의될 수 있다. 즉, 클라이언트 애플리케이션 프로세서 및 서버의 애플리케이션 프로세서는 핸드쉐이크 프로토콜(PT1)에 대응하는 데이터 구조(DS)를 참조하여, 클라이언트와 서버간 핸드쉐이크를 수행할 수 있다.

핸드쉐이크 프로토콜(P1)에 대응하는 데이터 구조(DS)는 핸드쉐이크 구간 내에 추가로 수행되는 동작이 정의될 수 있는 확장 영역(Extension Region, ER)을 포함할 수 있다. 일 실시예로, 확장 영역(ER)에는 무결성 검증을 위한 항목들(20)이 정의될 수 있다. 일 실시예로, 무결성 검증을 위한 항목들(20)은 무결성 검증 요청과 관련된 항목(20a) 및 무결성 검증 정보와 관련된 항목(20b) 등을 포함할 수 있다. 구체적으로, 클라이언트 또는 서버는 무결성 검증 요청과 관련된 항목(20a)을 참조하여, 무결성 검증을 상대방에게 요청할 수 있으며, 클라이언트 또는 서버는 무결성 검증을 위해 필요한 검증 정보와 관련된 항목(20b)을 참조하여, 검증 정보를 생성하거나, 상대방에게 검증 정보를 전송할 수 있다. 즉, 클라이언트 또는 서버는 데이터 구조(DS)의 확장 영역(ER)에 정의된 무결성 검증을 위한 항목들(20)을 참조하여, 클라이언트와 서버간 핸드쉐이크 구간 내에서 무결성 검증을 수행할 수 있다. 이를 통해, 클라이언트 및 서버는 핸드쉐이크 구간 내에서, IETF 표준 규약에 따른 무결성 검증을 수행할 수 있다.

다만, 도 5의 확장 영역(ER)에 정의된 항목들(20a, 20b)은 예시적인 실시예에 불과하며, 이에 국한되지 않고, 클라이언트 또는 서버에 대한 무결성을 검증하기 위해 필요한 다양한 항목들이 확장 영역(ER)에 정의될 수 있다.

도 6a는 본 개시의 일 실시예에 따른 무결성 검증을 위해 필요한 검증 정보(VI)에 대하여 구체적인 설명을 위한 도면이며, 도 6b 내지 도 6d는 도 6a의 소프트웨어 설정 타입(SW_CT)에 관한 구체적인 설명을 위한 도면이다.

도 6a를 참조하면, 무결성 검증을 수행하기 위해 필요한 검증 정보(VI)는 소프트웨어 설정 정보(SW_CI) 및 소프트웨어 설정 서명 정보(SW_CSI)를 포함할 수 있다. 일 실시예로, 소프트웨어 설정 정보(SW_CI)는 소프트웨어 설정 타입 정보(SW_CT) 및 소프트웨어 설정 타입에 대응하는 소프트웨어 설정 값(SW_CV)을 포함할 수 있다. 소프트웨어 설정 타입 정보(SW_CT)는 무결성 검증시에 값 변경 여부를 확인하는 대상을 특정하기 위한 정보일 수 있다. 예를 들어, 서버는 클라이언트의 소프트웨어 설정 타입 정보(SW_CT)에 대응하는 소프트웨어 설정 값(SW_CV)의 변경 여부를 판단함으로써, 클라이언트에 대한 무결성 검증을 수행할 수 있다. 소프트웨어 설정 타입 정보(SW_CT)는 무결성 검증을 위하여 미리 설정(set)된 소프트웨어 설정 타입을 나타낼 수 있으며, 소프트웨어 설정 타입은 다양하게 설정될 수 있다.

클라이언트는 소프트웨어 설정 서명 정보(SW_CSI)에 대한 요청을 수신하는 경우, 소프트웨어 설정 서명 정보(SW_CSI)에 대한 요청에 응답하여 소프트웨어 설정 서명 정보(SW_CSI)를 생성할 수 있다. 클라이언트는 클라이언트 내부의 보안 실행 환경에서 소프트웨어 설정 서명 정보(SW_CSI)를 생성할 수 있다. 보안 실행 환경은 외부에서 접근이 불가능한 환경으로서 신뢰된 실행 환경(Trusted Execution Environment; TEE)을 포함할 수 있다. 소프트웨어 설정 서명 정보(SW_CSI)의 생성 방법에 대해서는 도 9를 참조해 설명된다.

도 6b를 더 참조하면, 소프트웨어 설정 타입 정보(SW_CT)는 소프트웨어 설정 타입이 설정되지 않은 비설정 타입(None), 프로세스-맵 타입(Process_map), 보안 정책 타입(Security policy), 프로세스 맵-보안 정책 혼합 타입(Process map & Security policy) 및 사용자 정의 타입(User define) 중 어느 하나로 설정되었음을 나타낼 수 있다.

도 6c를 더 참조하면, 클라이언트 또는 서버 컴퓨팅 장치(600)는 애플리케이션 프로세서(620), TLS 프로토콜 스택(646)이 구비된 베이스밴드 프로세서(640) 및 메모리(660)를 포함할 수 있다. 메모리(660)는 운영 체제(662)를 저장할 수 있고, 애플리케이션 프로세서(620)는 메모리(660)를 리드하여, 운영 체제(662)를 실행할 수 있다. 일 실시예로, 애플리케이션 프로세서(620)에 의해 실행되는 운영 체제(662)는 소정의 보안 정책을 기반으로 컴퓨팅 장치(600)의 보안을 관리할 수 있다. 보안 정책은 시스템 설정 파일에 대한 설정 정보 및 메모리 보호 기법에 대한 설정 정보를 포함할 수 있다. 무결성 검증을 위해 운영 체제(662)의 보안 정책의 설정 값의 변경 여부를 확인하는 대상으로 특정된 때에는, 소프트웨어 설정 타입 정보(SW_CT)는 보안 정책 타입(Security policy)으로 설정될 수 있다.

도 6d를 더 참조하면, 메모리(660)는 운영 체제(662) 및 복수의 애플리케이션들(264)을 저장할 수 있다. 프로세스 맵은 컴퓨팅 장치(600)의 메모리(660) 상의 코드 영역에 대한 정보 및 시스템 실행 파일들(예를 들면, 애플리케이션들(664) 관련 실행 파일들)에 대한 정보를 포함할 수 있다. 무결성 검증을 위해 프로세스 맵의 설정 값의 변경 여부를 확인하는 대상으로 특정된 때에는, 소프트웨어 설정 타입 정보(SW_CT)는 프로세스 맵 타입(Process map)으로 설정될 수 있다.

무결성 검증을 위해 도 6c에서 전술한 운영 체제(662)의 보안 정책의 설정 값 및 도 6d에서 전술한 프로세스 맵의 설정 값을 포함하는 혼합 설정 값의 변경 여부를 확인하는 대상으로 특정된 때에는, 소프트웨어 설정 타입 정보(SW_CT)는 프로세스 맵-보안 정책 혼합 타입(Process map & Security Policy)으로 설정될 수 있다. 더 나아가, 보안 정책, 프로세스 맵 외에 사용자가 지정한 소프트웨어 설정 값을 이용하여 무결성을 검증할 수 있으며, 이 때에 소프트웨어 설정 타입 정보(SW_CT)는 사용자 지정 타입으로 설정될 수 있다. 다만, 도 6b에 도시된 내용은 예시적인 실시예에 불과한 바, 이에 국한되지 않고, 소프트웨어 설정 타입 정보(SW_CT)는 상황에 따라 다양한 타입으로 설정될 수 있다.

도 7a는 본 개시의 일 실시예에 따른 인증서(Certicate)를 발행 받는 방법을 설명하기 위한 블록도이고, 도 7b는 인증서(30)에 포함된 무결성 검증 관련 정보들을 설명하기 위한 도면이며, 도 7c는 무결성 검증 관련 정보들이 인증서가 아닌 보안 메모리 영역(368)에 저장된 실시예를 설명하기 위한 블록도이다. 또한, 도 7d는 소프트웨어 설정 값을 생성하는 방법을 설명하기 위한 순서도이다.

도 7a를 참조하면, 클라이언트/서버(300)는 인증서 서명 요청(Certificate Signing Request; CSR)을 인증 기관(Certificate Authority; CA, 320)에 제공할 수 있다. 일 실시예에 따라, 인증서 서명 요청(CSR)은 무결성 검증과 관련된 클라이언트/서버(300)의 소프트웨어 설정 타입 정보 및 소프트웨어 설정 타입 정보에 대응하는 소프트웨어 설정 값을 포함할 수 있다. 이하에서, 클라이언트/서버는 클라이언트 또는 서버를 의미한다. 인증 기관(320)은 인증서 서명 요청(CSR)에 응답하여 인증서(Certificate)를 클라이언트/서버(300)에 제공할 수 있다. 인증서(Certificate)는 인증서 서명 요청(CSR)에 포함된 클라이언트/서버(300)의 소프트웨어 설정 타입 정보 및 소프트웨어 설정 타입 정보에 대응하는 소프트웨어 설정 값을 포함할 수 있다. 즉, 인증서(Certificate)는 클라이언트/서버(300)가 인증서 서명 요청(CSR)을 인증 기관(320)에 제공할 당시의 클라이언트/서버(300)에 대한 소프트웨어 설정 정보(SW configuration info.)를 포함할 수 있다.

도 7b를 더 참조하면, 인증서(Certificate)는 인증된 속성들에 대한 정보가 저장된 제1 영역(31a)과 소정의 해쉬 알고리즘, 서명 알고리즘 및 인증 기관(320)의 개인키를 이용하여 인증된 속성들에 대한 정보로부터 생성된 인증 기관 서명 정보가 저장되는 제2 영역(31b)을 포함할 수 있다.

제1 영역(31a)은 인증서(Certificate)의 버전 넘버가 저장된 정보 영역(32), 인증 기관(320)에 의해 할당된(assigned) 고유의 넘버가 저장된 시리얼 넘버 정보 영역(33), 인증 기관 서명 정보를 생성하기 위해 사용되는 SHA(Secure Hash Algorithm), DSA(Digital Signature Algorithm) 등과 같은 암호화 알고리즘에 대한 정보가 저장된 서명 알고리즘 정보 영역(34), 인증서 발행자 정보 영역(35), 인증서(Certificate)의 유효성 인정 시작 시점, 종료 시점 등에 대한 정보가 저장된 인증서(Certificate)의 유효성 지시자 정보 영역(36), 인증서 발행 대상(또는, 서브젝트) 식별자 정보 영역(37), 인증서 발행 대상(또는, 서브젝트) 공개키 정보 영역(38) 및 확장 영역(39)을 포함할 수 있다.

일 실시예로, 확장 영역(39)에는 클라이언트/서버(300)의 무결성 검증을 위한 소프트웨어 설정 정보(SW_CI)가 저장될 수 있다. 소프트웨어 설정 정보(SW_CI)는 전술한 바와 같이, 소프트웨어 설정 타입 정보(39a) 및 소프트웨어 설정 타입 정보(39a)에 대응하는 소프트웨어 설정 값(39b)을 포함할 수 있다.

도 7c를 더 참조하면, 클라이언트/서버(또는, 컴퓨팅 장치, 300)가 인증서 서명 요청(CSR)을 인증 기관(320)에 제공할 당시(또는, 주기적/비주기적으로)의 클라이언트/서버(300)에 대한 소프트웨어 설정 정보(SW_CI)를 생성하여 메모리(360)의 보안 메모리 영역(368)에 저장할 수 있다. 보안 메모리 영역(368)은 인증된 사용자만이 접근할 수 있는 영역일 수 있다. 즉, 클라이언트/서버(300)는 도 5b와 같이 소프트웨어 설정 정보(SW_CI)를 포함하는 인증서(Certificate)를 이용하여 무결성 검증을 수행할 수 있으며, 인증서(Certificate)에 소프트웨어 설정 정보(SW_CI)가 포함되지 않는 경우에는, 보안 메모리 영역(368)에 별도로 소프트웨어 설정 정보(SW_CI)를 저장하고, 이후에 보안 메모리 영역(368)의 소프트웨어 설정 정보(SW_CI)를 리드하여, 무결성 검증을 수행할 수 있다.

도 7d를 더 참조하면, 클라이언트/서버(300)는 인증 기관(320)에 소프트웨어 설정 정보를 제공할 때, 또는, 클라이언트/서버(300)는 보안 메모리 영역(368)에 소프트웨어 설정 정보를 저장할 때에, 소프트웨어 설정 정보에 포함되는 소프트웨어 설정 값을 다음과 같이 생성할 수 있다. 클라이언트/서버(300)는 무결성 검증을 위해 설정된 소프트웨어 설정 타입에 대응하는 소프트웨어 설정을 리드할 수 있다(S10). 예를 들어, 소프트웨어 설정 타입으로 프로세스 맵 타입이 설정된 때에는, 클라이언트/서버(300)는 메모리 상의 코드 영역에 대한 정보 및 시스템 실행 파일들에 대한 정보를 리드할 수 있다. 이후, 클라이언트/서버(300)는 리드 값에 소정의 해쉬 알고리즘을 선택적으로 적용할 수 있다(S12). 클라이언트/서버(300)는 리드 값을 이용하여 소프트웨어 설정 값을 생성할 수 있다(S14).

도 8a는 도 7b와 같이, 인증서(30)에 소프트웨어 설정 정보(SW_CI)가 포함된 경우에 클라이언트(220)와 서버(240)간 제1 무결성 검증 동작을 설명하기 위한 순서도이고, 도 8b는 도 7c와 같이, 보안 메모리 영역(368)에 소프트웨어 설정 정보(SW_CI)가 저장된 경우에 클라이언트(220)와 서버(240)간 제1 무결성 검증 동작을 설명하기 위한 순서도이다.

도 8a를 참조하면, 클라이언트(220)는 서버(240)에 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 무결성 검증 요청을 포함하는 제1 메시지를 전송할 수 있다(S210). 제1 무결성 검증은 클라이언트(220)에 대한 무결성 검증을 의미할 수 있다. 서버(240)는 제1 무결성 검증에 필요한 클라이언트 인증서와 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제2 메시지를 클라이언트(220)에 전송할 수 있다(S220). 클라이언트(220)는 소프트웨어 설정 서명 정보에 대한 요청에 응답하여, 소프트웨어 설정 서명 정보를 생성할 수 있다(S230). 클라이언트(220)는 서버(240)에서 제1 무결성 검증을 수행하기 위해 필요한 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 서버(240)에 전송할 수 있다(S240). 서버(240)는 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 이용하여 제1 무결성 검증을 수행할 수 있다(S250).

도 8b를 참조하면, 클라이언트(220)는 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 무결성 검증 요청을 포함하는 제1 메시지를 전송할 수 있다(S210). 서버(240)는 제1 무결성 검증에 필요한 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제2 메시지를 클라이언트(220)에 전송할 수 있다(S222). 클라이언트(220)는 소프트웨어 설정 서명 정보에 대한 요청에 응답하여, 소프트웨어 설정 서명 정보를 생성할 수 있다(S230). 클라이언트(220)는 서버(240)에서 제1 무결성 검증을 수행하기 위해 필요한 소프트웨어 설정 서명 정보 및 보안 메모리 영역에 저장된 소프트웨어 설정 정보를 리드하여 서버(240)에 전송할 수 있다(S242).

클라이언트(220)는 보안 메모리 영역에 저장된 소프트웨어 설정 정보를 리드하여 서버(240)에 전송하기 전에, 보안 메모리 영역에 저장된 소프트웨어 설정 정보의 위/변조 여부를 검증할 수 있다. 일 실시예로, 클라이언트(220)는 소프트웨어 설정 정보를 보안 메모리 영역에 저장할 때에, 보안 서명 정보도 같이 보안 메모리 영역에 저장할 수 있다. 보안 서명 정보는, 소프트웨어 설정 정보가 소정의 키를 통해 암호화된 정보이며, 보안 메모리 영역에 저장된 소프트웨어 설정 정보의 위/변조 여부를 검증하기 위해 필요한 정보를 의미한다. 클라이언트(220)는 보안 메모리 영역에 저장된 소프트웨어 설정 정보 및 보안 서명 정보를 리드하여, 보안 서명 정보를 복호화하고, 복호화된 값과 소프트웨어 설정 정보를 비교함으로써, 소프트웨어 설정 정보의 위/변조 여부를 검증할 수 있다. 클라이언트(220)는 위/변조되지 않음이 검증된 소프트웨어 설정 정보에 한하여, 서버(240)에 전송할 수 있다. 위와 같은, 클라이언트(220)의 보안 메모리 영역의 소프트웨어 설정 정보에 대한 위/변조 여부 검증 동작은 클라이언트(220)에 한하지 않고, 서버 상에서도 수행될 수 있음은 분명하다. 이후, 서버(240)는 소프트웨어 설정 서명 정보 및 소프트웨어 설정 정보를 이용하여 제1 무결성 검증을 수행할 수 있다(S250).

도 9는 도 8a의 소프트웨어 설정 서명 정보를 생성하는 방법을 설명하기 위한 순서도이다.

도 8a 및 도 9를 참조하면, S220 단계 이후에, 클라이언트(220)는 클라이언트 인증서에 포함된 소프트웨어 설정 타입 정보에 대응하는 현재 소프트웨어 설정을 클라이언트(220)의 메모리 영역으로부터 리드할 수 있다(S232). 클라이언트(220)의 현재 소프트웨어 설정은 서버에서 클라이언트(220)에 대한 무결성 검증을 수행하기 직전의 클라이언트(220)의 소프트웨어 설정 상태를 지칭할 수 있다. 클라이언트(220)는 현재 소프트웨어 설정 리드 값에 소정의 해쉬 알고리즘을 선택적으로 적용할 수 있다(S232). 클라이언트(220)는 리드 값을 이용하여 현재 소프트웨어 설정 값을 생성하고, 클라이언트의 개인키를 이용해 현재 소프트웨어 설정 값을 암호화하여 소프트웨어 설정 서명 정보를 생성할 수 있다(S236). 클라이언트는 클라이언트 내부의 보안 실행 환경에서 소프트웨어 설정 서명 정보를 생성할 수 있다. 이후, S240 단계를 진행할 수 있다. 도 9에서는 S232 단계에서, 클라이언트(220)가 클라이언트 인증서를 참조하여, 클라이언트 인증서의 소프트웨어 설정 타입 정보를 이용하는 동작을 중심으로 기술하였으나, 이는 일 실시예로, 이에 국한되지 않고, 클라이언트(220)는 보안 메모리 영역에 접근하여, 보안 메모리 영영에 저장된 소프트웨어 설정 타입 정보를 이용할 수도 있다.

도 10은 도 8a의 S250 단계를 구체적으로 설명하기 위한 순서도이다.

도 8a 및 도 10을 참조하면, S240 단계 이후에, 서버(240)는 클라이언트 인증서의 클라이언트 공개키를 이용하여 클라이언트(220)로부터 수신한 소프트웨어 설정 서명 정보를 복호화할 수 있다(S252). 서버(240)는 복호화 값과 클라이언트 인증서에 포함된 소프트웨어 설정 값을 비교하여 클라이언트의 무결성을 검증할 수 있다(S254). 이후, 도 4의 S150 단계를 진행할 수 있다.

도 11은 본 개시의 일 실시예에 따른 제2 무결성 검증을 수행하는 방법을 설명하기 위한 순서도이다.

도 11을 참조하면, 클라이언트(220)는 TLS 연결의 핸드쉐이크를 시작하기 위한 제1 메시지를 전송할 수 있다(S310). 서버(240)는 제2 무결성 검증 요청 및 제2 무결성 검증에 필요한 제2 검증 정보를 포함하는 제2 메시지를 클라이언트(220)에 전송할 수 있다(S320). 제2 무결성 검증은 서버(240)에 대한 무결성 검증을 의미할 수 있다. 일 실시예로, 서버(240)는 서버 인증서 및 서버(240)의 소프트웨어 설정 서명 정보를 포함하는 제2 검증 정보를 클라이언트(220)에 제공할 수 있다. 서버 인증서는 전술한 바와 같이, 서버(240)의 소프트웨어 설정 정보를 포함할 수 있다. 다른 실시예로, 서버(240)는 서버(240)의 보안 메모리 영역에 저장된 소프트웨어 설정 정보 및 서버(240)의 소프트웨어 설정 서명 정보를 포함하는 제2 검증 정보를 클라이언트(220)에 제공할 수 있다.

제2 검증 정보는 도 2의 제1 검증 정보와 동일한 방식으로 생성되고, 제2 무결성 검증은 도 2의 제1 무결성 검증과 동일한 방식으로 무결성 검증 주체 및 대상만을 달리하여 수행될 수 있다. 제2 무결성 검증에 대한 구체적인 내용은 생략한다.

도 12는 본 개시의 일 실시예에 따른 클라이언트(420) 및 서버(440)간의 핸드쉐이크 구간 내의 검증 동작을 설명하기 위한 순서도이다.

클라이언트(420)와 서버(440)는 보안된 데이터 통신을 위한 세션 연결을 위해 도 1b의 핸드쉐이크 프로토콜(PT1)에 기반하여 다음과 같은 핸드쉐이크를 수행할 수 있다. 도 12를 참조하면, 클라이언트(420)는 TLS 기반 핸드쉐이크를 시작하기 위하여 클라이언트 헬로(Client Hello) 메시지를 서버(440)에 전송할 수 있다(S400). 클라이언트 헬로 메시지는 클라이언트(420)의 TLS 프로토콜 버전 정보, 서버(440)와 과거에 연결되었던 세션의 ID 필드 정보, 클라이언트(420)에서 생성된 제1 보안 랜덤 데이터, 클라이언트(420)에서 지원 가능한 암호화 알고리즘 리스트 및 클라이언트(420)에서 지원 가능한 압축 방법 리스트 중 적어도 하나를 포함할 수 있다. 클라이언트(420)는 클라이언트(420)의 소프트웨어 설정 타입 정보를 포함하는 제1 무결성 요청을 서버(440)에 전송할 수 있다(S410). 일 실시예로, 클라이언트(420)는 도 4b에 도시된 소프트웨어 타입 정보(SW_CT)를 포함하는 제1 무결성 검증 요청을 서버(440)에 전송할 수 있다. 일 예로, 제1 무결성 요청에 포함된 소프트웨어 타입 정보(SW_CT)가 비설정 타입(None)으로 설정된 때에는, 서버(440)는 제1 무결성 검증을 수행하지 않을 수 있다. 제1 무결성 요청에 포함된 소프트웨어 타입 정보(SW_CT)가 프로세스-맵 타입(Process_map), 보안 정책 타입(Security policy), 프로세스 맵-보안 정책 혼합 타입(Process map & Security policy) 및 사용자 정의 타입(User_define) 중 어느 하나로 설정된 때에는, 서버(440)는 설정된 소프트웨어 타입에 대응하는 클라이언트(420)의 소프트웨어 설정 값을 이용하여 제1 무결성 검증을 수행할 수 있다. 클라이언트 헬로 메시지와 제1 무결성 검증 요청은 클라이언트(420)가 서버(440)에 전송하는 제1 메시지(1st message)에 포함되는 것으로 정의할 수 있다. 또한, IETF 표준 규약에 따라, 클라이언트(420)가 제1 무결성 검증 요청하는 단계는 선택적인(optional) 단계일 수 있다.

서버(440)는 클라이언트 헬로 메시지에 응답하여 서버 헬로(Server Hello) 메시지를 클라이언트(420)에 전송할 수 있다(S410). 서버 헬로 메시지는 서버(440)의 TLS 프로토콜 버전 정보, 클라이언트(420)와 과거에 연결되었던 세션의 ID 필드 정보, 서버(440)에서 생성된 제2 보안 랜덤 데이터, 클라이언트(420)에서 지원 가능한 암호화 알고리즘 리스트 중 선택된 암호화 알고리즘 및 클라이언트(420)에서 지원 가능한 압축 방법 리스트 중 선택된 압축 방법 중 적어도 하나를 포함할 수 있다. 서버(440)는 클라이언트(420)로부터의 클라이언트 헬로 메시지 또는 제1 무결성 검증 요청에 응답하여 클라이언트 인증서 및 클라이언트(420)의 소프트웨어 설정 서명 정보를 클라이언트(420)에 요청할 수 있다(S412). 다만, 클라이언트(420)에 대한 무결성 검증을 수행할 필요가 없는 때에는, S412 단계에서, 서버(440)는 클라이언트 인증서만을 클라이언트(420)에 요청할 수 있다. 서버(440)는 서버(440)의 소프트웨어 설정 타입 정보를 포함하는 제2 무결성 검증 요청을 클라이언트(420)에 전송할 수 있다(S414). 일 실시예로, 서버(440)는 도 6b에 도시된 소프트웨어 타입 정보(SW_CT)를 포함하는 제2 무결성 검증 요청을 클라이언트(420)에 전송할 수 있다. 일 예로, 제2 무결성 요청에 포함된 소프트웨어 타입 정보(SW_CT)가 비설정 타입(None)으로 설정된 때에는, 클라이언트(420)는 제1 무결성 검증을 수행하지 않을 수 있다. 제2 무결성 요청에 포함된 소프트웨어 타입 정보(SW_CT)가 프로세스-맵 타입(Process_map), 보안 정책 타입(Security policy), 프로세스 맵-보안 정책 혼합 타입(Process map & Security policy) 및 사용자 정의 타입(User define) 중 어느 하나로 설정된 때에는, 클라이언트(420)는 설정된 소프트웨어 타입에 대응하는 서버(440)의 소프트웨어 설정 값을 이용하여 제2 무결성 검증을 수행할 수 있다. 서버(440)는 클라이언트(420)가 제2 무결성 검증 또는 서버 인증서의 검증을 수행할 수 있도록 서버 인증서 및 서버(440)의 소프트웨어 설정 서명 정보를 클라이언트(420)에 제공할 수 있다(S416). 다만, 서버(440)에 대한 무결성 검증을 수행할 필요가 없는 때에는, S440 단계에, 서버(440)는 서버 인증서만을 클라이언트(420)에 전송할 수 있다. 이후, 서버(440)는 클라이언트 헬로 메시지에 응답한 메시지 전송을 완료했음을 의미하는 서버 헬로 완료(Server Hello Done) 메시지를 클라이언트(420)에 제공할 수 있다(S420). 서버 헬로 메시지, 클라이언트 인증서 및 클라이언트의 소프트웨어 설정 서명 정보 요청, 제2 무결성 검증 요청, 서버 인증서 및 서버의 소프트웨어 설정 서명 정보, 및 서버 헬로 완료 메시지는 서버(440)가 클라이언트(420)에 전송하는 제2 메시지(2nd message)에 포함되는 것으로 정의할 수 있다. IETF 표준 규약에 따라, 서버(440)의 S412 단계, S414 단계 및 S416 단계는 선택적인(optional) 단계일 수 있다.

클라이언트(420)는 제2 무결성 검증 요청(S414)에 응답하여, 서버 인증서 및 서버(440)의 소프트웨어 설정 서명 정보를 이용하여 제2 무결성 검증을 수행할 수 있다(S430). 구체적으로, 클라이언트(420)는 서버 인증서 내의 서버(440)의 소프트웨어 설정 정보 중 소프트웨어 설정 값과 서버(440)의 소프트웨어 설정 서명 정보를 이용하여 제2 무결성 검증을 수행할 수 있다. 즉, 클라이언트(420)는 서버(440)의 소프트웨어 설정 서명 정보를 서버 인증서에 포함된 서버 공개키를 이용하여 복호화한 후에, 복호화 값과 서버(440)의 소프트웨어 설정 값을 비교함으로써, 서버(440)의 무결성을 검증할 수 있다. 일 예로, 비교 결과가 일치하는 때에는, 클라이언트(420)는 서버(440)의 무결성을 확인할 수 있다. 또한, 클라이언트(420)는 서버(440)로부터 서버 인증서를 수신한 때에, 서버 인증서에 대한 검증을 수행할 수 있다(S432). 일 실시예로, 클라이언트(420)는 서버 인증서를 발행한 인증 기관의 공개키를 이용하여 서버 인증서의 서명 정보를 복호화하고, 복호화 값과 서버 인증서의 인증된 속성들에 대한 정보를 비교하여 서버 인증서를 검증할 수 있다. 다만, 도 12에서는 S430 단계 및 S432 단계는 S420 단계 이후에 수행되는 것으로 도시되어 있으나, 이에 국한되지 않고, 제2 무결성 검증을 수행할 수 있는 때, 서버 인증서에 대한 검증을 수행할 수 있는 때에 바로 수행될 수 있다. 더 나아가, S430 단계 및 S432 단계에 대한 수행 순서는 IETF 표준 프로토콜(또는, TLS)에 의해 정의될 수 있다.

클라이언트(420)는 클라이언트 인증서 및 클라이언트(420)의 소프트웨어 서명 정보를 서버(400)에 전송할 수 있다(S440). 다만, 클라이언트(420)에 대한 무결성 검증을 수행할 필요가 없는 때에는, S440 단계에서, 클라이언트(420)는 클라이언트 인증서만을 서버(440)에 전송할 수 있다. IETF 표준 규약에 따라, 클라이언트(420)의 S440 단계는 선택적인(optional) 단계일 수 있다.

클라이언트(420)는 클라이언트(420)에서 생성된 제1 보안 랜덤 데이터 및 서버(440)에서 생성된 제2 보안 랜덤 데이터를 이용하여 세션키(session key)를 생성하고, 생성된 세션키를 서버(440)에 전송할 수 있다(S450). 클라이언트(420)는 세션키를 이용하여 앞으로 서버(440)에 전송할 메시지를 암호화한다는 것을 알리는 체인지 사이퍼 스펙(Change Cipher Spec) 메시지를 서버(440)에 전송할 수 있다(S452). 이후, 클라이언트(420)는 핸드쉐이크를 위한 메시지 전송을 종료한다는 클라이언트 종료(Client Finished) 메시지를 서버(440)에 전송할 수 있다(S454).

서버(440)는 제1 무결성 검증 요청(S402)에 응답하여, 클라이언트 인증서 및 클라이언트(420)의 소프트웨어 설정 서명 정보를 이용하여 제1 무결성 검증을 수행할 수 있다(S460). 구체적으로, 서버(440)는 클라이언트 인증서 내의 클라이언트(420)의 소프트웨어 설정 정보 중 소프트웨어 설정 값과 클라이언트(420)의 소프트웨어 설정 서명 정보를 이용하여 제1 무결성 검증을 수행할 수 있다. 즉, 서버(440)는 클라이언트(420)의 소프트웨어 설정 서명 정보를 클라이언트 인증서에 포함된 클라이언트 공개키를 이용하여 복호화한 후에, 복호화 값과 클라이언트(420)의 소프트웨어 설정 값을 비교함으로써, 클라이언트(420)의 무결성을 검증할 수 있다. 일 예로, 비교 결과가 일치하는 때에는, 서버(440)는 클라이언트(420)의 무결성을 확인할 수 있다. 또한, 서버(440)는 클라이언트(420)로부터 클라이언트 인증서를 수신한 때에, 클라이언트 인증서에 대한 검증을 수행할 수 있다(S462). 일 실시예로, 서버(440)는 클라이언트 인증서를 발행한 인증 기관의 공개키를 이용하여 클라이언트 인증서의 서명 정보를 복호화하고, 복호화 값과 클라이언트 인증서의 인증된 속성들에 대한 정보를 비교하여 클라이언트 인증서를 검증할 수 있다. 다만, 도 12에서는 S460 단계 및 S462 단계는 S454 단계 이후에 수행되는 것으로 도시되어 있으나, 이에 국한되지 않고, 제1 무결성 검증을 수행할 수 있는 때, 클라이언트 인증서에 대한 검증을 수행할 수 있는 때에 바로 수행될 수 있다. 더 나아가, S430 단계 및 S432 단계에 대한 수행 순서는 IETF 표준 프로토콜(또는, TLS)에 의해 정의될 수 있다.

서버(440)는 수신된 세션키를 이용하여 앞으로 클라이언트(420)에 전송할 메시지를 암호화한다는 것을 알리는 체인지 사이퍼 스펙(Change Cipher Spec) 메시지를 클라이언트(420)에 전송할 수 있다(S470). 이후, 서버(440)는 핸드쉐이크를 위한 메시지 전송을 종료한다는 서버 종료(Server Finished) 메시지를 클라이언트(420)에 전송할 수 있다(S472).

이후, 클라이언트(420)와 서버(440) 간의 세션은 무결성 검증 결과 및 인증서 검증 결과 중 적어도 하나를 기반으로 연결될 수 있다(S480). 일 실시예로, 클라이언트(420) 및 서버(440) 중 적어도 하나의 무결성이 확인되지 않거나, 인증서가 변조된 때에는, 클라이언트(420)와 서버(440)간의 세션은 연결되지 않을 수 있다.

이와 같이, 본 개시의 일 실시예에 따른 클라이언트(420)와 서버(440)간 핸드쉐이크 구간 내의 무결성 검증을 통하여 데이터 통신에 대한 보안성을 더욱 향상시킬 수 있는 장점이 있다.

도 13은 본 개시의 일 실시예에 따른 무결성 검증 동작의 기반이 되는 명령들이 저장된 저장 매체를 나타내는 블록도이다.

도 13을 참조하면, 클라이언트/서버 컴퓨팅 장치(500)는 애플리케이션 프로세서(510) 및 저장 매체(520)를 포함할 수 있다. 저장 매체(520)는 애플리케이션 프로세서(510)에 의해 판독 가능하고, 비-일시적인(non-transitory) 정보들을 저장할 수 있다. 저장 매체(520)는 애플리케이션 프로세서(510)에 의해 실행 가능한 명령들을 저장할 수 있다. 일 실시예로, 저장 매체(520)는 TLS 연결을 위해나 핸드쉐이크 구간내에 무결성 검증을 수행하기 위한 명령어들이 저장되는 소정의 영역(522)을 포함할 수 있다. 클라이언트 컴퓨팅 장치(500)에 포함된 애플리케이션 프로세서(510)는 저장 매체(520)의 소정의 영역(522)에 저장된 명령들을 판독하여, 서버 컴퓨팅 장치와의 TLS 연결의 핸드쉐이크 구간내에, 서버 인증서 및 소프트웨어 설정 서명 정보를 서버 컴퓨팅 장치로부터 수신하고, 소프트웨어 설정 서명 정보와 서버 인증서에 포함된 공개키, 소프트웨어 설정 타입 정보 및 소프트웨어 설정 값을 이용하여 서버 컴퓨팅 장치에 대한 무결성 검증을 수행할 수 있다.

또한, 서버 컴퓨팅 장치(500)에 포함된 애플리케이션 프로세서(510)는 저장 매체(520)의 소정의 영역(522)에 저장된 명령들을 판독하여, 클라이언트 컴퓨팅 장치와의 TLS 연결의 핸드쉐이크 구간내에, 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 클라이언트 컴퓨팅 장치로부터 수신하고, 소프트웨어 설정 서명 정보와 클라이언트 인증서에 포함된 공개키, 소프트웨어 설정 타입 정보 및 소프트웨어 설정 값을 이용하여 클라이언트 컴퓨팅 장치에 대한 무결성 검증을 수행할 수 있다.

도 14는 본 개시의 일실시예에 따른 제1 및 제2 클라이언트-서버 컴퓨팅 시스템(1100)을 개략적으로 나타내는 블록도이다. 제1 및 제2 클라이언트-서버 컴퓨팅 시스템(1100)은 제1 클라이언트(1110), 제2 클라이언트(1120) 및 서버(1140)를 포함할 수 있다. 제1 클라이언트(1110) 및 제2 클라이언트(1120) 각각은 도 1의 클라이언트(120)에 해당할 수 있고, 서버(1140)는 도 1의 서버(140)에 해당할 수 있다. 특히, 도 14에 개시된 제1 및 제2 클라이언트-서버 컴퓨팅 시스템(1100)은, 제1 클라이언트(1110)가 서버(1140)와 직접 통신할 수 없는 경우를 나타낸다. 제1 클라이언트(1110)가 서버(1140)와 직접 통신할 수 없는 경우는 다양한 경우를 포함할 수 있다. 예를 들어, 서버(1140)가 Wi-Fi(Wireless Fidelity) 통신을 지원하는 반면, 제1 클라이언트(1110)는 리소스의 제한에 의해 Wi-Fi 통신을 지원하지 않는 경우, 제1 클라이언트(1110)는 서버(1140)와 직접 통신할 수 없을 수 있다. 하지만 이에 제한되는 것은 아니다. 다른 예시로서, 메쉬 네트워크(mesh network)와 같은 그물 네트워크 시스템에서 제1 클라이언트(1110)와 서버(1140) 사이의 제2 네트워크는 끊어졌지만, 제1 클라이언트(1110)와 제2 클라이언트(1120) 사이의 제1 네트워크는 연결이 가능한 경우도 포함할 수 있다.

제1 클라이언트(1110)는 제2 클라이언트(1120)와 제1 네트워크(Network1)를 통해 연결되어 통신할 수 있고, 제2 클라이언트(1120)는 서버(1140)와 제2 네트워크(Network2)를 통해 연결되어 통신할 수 있다. 이러한 제1 및 제2 클라이언트-서버 컴퓨팅 시스템(1100)에서, 제2 클라이언트(1120)와 서버(1140)는 도 1 내지 도 13을 참조하여 설명된 클라이언트-서버 컴퓨팅 시스템에서의 서버 등록 및 무결성 검증 동작을 수행할 수 있다. 하지만 제1 클라이언트(1110)와 서버(1140)는 직접 통신할 수 없기 때문에, 도 1 내지 도 13을 참조하여 설명된 클라이언트-서버 컴퓨팅 시스템에서의 서버 등록 방법 및 무결성 검증 방법이 적용될 수 없다.

이 경우, 제1 클라이언트(1110)와 제1 네트워크(Network1)를 통해 연결되고, 서버(1140)와 제2 네트워크(Network2)를 통해 연결된 제2 클라이언트(1120)는 제1 클라이언트(1110)에 대한 서버 등록 및 무결성 검증 동작을 지원할 수 있다. 이에 대해 도 15 내지 도 20을 참조하여 설명한다.

도 15는 본 개시의 일실시예에 따른 제1 클라이언트(1110)에 대한 서버 등록을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 15를 참조하면, TLS 기반 핸드쉐이크를 시작하기 전, 제1 클라이언트(1110)와 제2 클라이언트(1120)는 각각의 인증서 및 인증서에 대한 서명 정보를 이용해 상호간 인증 동작을 수행할 수 있다(S1010). 상호간 인증 동작은 제1 클라이언트(1110) 및 제2 클라이언트(1120)의 상호간의 인증키(Authentication Key; Key_Auth)를 이용한 대칭키 방식 중 인증 메시지 검증 프로토콜에 따른 동작이 포함될 수 있다. 인증키를 이용한 대칭키 방식에 대해서는 도 17a 내지 도 17d를 참조하여 설명된다.

제1 클라이언트(1110) 및 제2 클라이언트(1120) 상호간 인증 동작이 정상적으로 완료된 경우, 제2 클라이언트(1120)와 서버(1140)는 TLS 기반 핸드쉐이크를 시작할 수 있다(S1020). 즉, 제2 클라이언트(1120)와 서버(1140)는 TLS 프로토콜 스택의 핸드쉐이크 프로토콜을 기반으로 핸드쉐이크를 시작할 수 있다.

제2 클라이언트(1120)는 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트(1110)에 대한 등록 요청을 서버(1140)에 전송할 수 있다(S1030). 제1 클라이언트(1110)에 대한 등록은, 제1 클라이언트(1110)가 서버(1140)에 대한 접근 권한을 얻기 위해 제1 클라이언트(1110)를 서버(1140)에 등록(register)하는 것을 나타낼 수 있다.

제2 클라이언트(1120)로부터 수신된 제1 클라이언트(1110)에 대한 등록 요청에 응답하여, 서버(1140)는 핀 정보를 제2 클라이언트(1120)에 전송할 수 있다(S1040). 서버(1140)는 핀 정보를 제2 클라이언트(1120)에 전송하기 전, 제1 클라이언트(1110)의 정품 여부를 확인할 수 있고, 이는 도 16을 참조하여 설명된다.

제2 클라이언트(1120)는 서버(1140)로부터 수신된 핀 정보를 제1 클라이언트(1110)에 전송할 수 있다(S1045).

또한, 제2 클라이언트(1120)는 서버(1140)로부터 핀 정보를 수신함에 따라, 서버(1140)에 핀 인증 결과 정보 요청을 전송할 수 있다(S1050). 핀 인증 결과 정보는 서버(1140)에 핀 정보가 올바르게 입력 되었는지 여부를 나타내는 정보일 수 있다. 예를 들어, 제1 클라이언트(1110)는 제2 클라이언트(1120)로부터 핀 정보를 수신함에 따라, 제1 클라이언트(1110)에 포함된 시각적 표시 장치 및 청각적 표시 장치 중 적어도 하나를 포함하는 표시 장치를 통해 핀 정보를 사용자에게 알릴 수 있다. 사용자는 표시 장치에 표시된 핀 정보를 서버(1140)에 입력할 수 있다. 제2 클라이언트(1120)는 서버에 핀 정보가 올바르게 입력 되었는지 여부를 확인하기 위해 서버(1140)에 핀 인증 결과 정보 요청을 전송할 수 있다.

사용자에 의해 서버(1140)에 핀 정보가 입력될 수 있다(S1055). 서버(1140)는 올바른 핀 정보가 입력된 경우, 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 제2 클라이언트(1120)에 전송할 수 있다(S1060). 제2 클라이언트(1120)는 올바른 핀 정보가 입력되었음을 나타내는 핀 인증 결과 정보를 수신함으로써 올바른 핀 정보가 입력되었음을 확인할 수 있다.

제2 클라이언트(1120)는 핀 인증 결과 정보 수신에 응답하여 등록 완료 신호를 서버(1140)에 전송할 수 있다(S1070). 서버(1140)는 제2 클라이언트(1120)로부터 등록 완료 신호를 수신함에 따라 제1 클라이언트(1110)가 서버(1140)에 접근할 수 있는 권한을 포함하는 액세스 토큰을 제2 클라이언트(1120)에 전송할 수 있다(S1080). 제2 클라이언트(1120)는 수신된 액세스 토큰을 제1 클라이언트(1110)에 전송할 수 있다(S1085). 이후, 제1 클라이언트(1110)는 액세스 토큰을 이용하여 서버(1140)에 접근할 수 있을 것이다.

이후, 제2 클라이언트(1120)와 서버(1140)는 TLS 기반 핸드쉐이크를 종료할 수 있다(S1090).

본 개시의 예시적 실시예에 따른 암호화 보안 프로토콜 기반 통신을 이용한 제1 클라이언트(1110)에 대한 서버 등록 방법에 따르면, 핸드쉐이크 구간 내에서 직접 서버(1140)에 연결이 불가능한 제1 클라이언트(1110)를 제2 클라이언트(1120)를 통해 서버(1140)에 안전하게 등록할 수 있다.

도 16은 본 개시의 일실시예에 따른 제1 클라이언트(1110)에 대한 서버 등록을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 16을 참조하면, 제1 클라이언트(1110)는 제1 클라이언트(1110)에 대한 등록 대행 요청을 제2 클라이언트(1120)에 전송할 수 있으며, 제2 클라이언트(1120)를 인증하기 위한 제2 클라이언트(1120)의 인증서 및 인증서 서명 정보에 대한 요청을 함께 제2 클라이언트(1120)에 전송할 수 있다(S1011). 제2 클라이언트(1120) 또한 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 요청할 수 있다(S1012).

제2 클라이언트(1120)는, 제1 클라이언트(1110)로부터 수신된 인증서 및 인증서 서명 정보에 대한 요청에 응답하여, 제2 클라이언트(1120)의 인증서 및 인증서 서명 정보를 제1 클라이언트(1110)에 전송할 수 있다(S1013). 제2 클라이언트(1120)는 제2 클라이언트(1120)의 개인키를 이용해 제2 클라이언트(1120)의 인증서에 포함된 인증된 속성들을 암호화함으로써 인증서 서명 정보를 생성할 수 있다.

제1 클라이언트(1110)는, 제2 클라이언트(1120)로부터 수신된 인증서 및 인증서 서명 정보에 대한 요청에 응답하여, 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 제2 클라이언트(1120)에 전송할 수 있다(S1014). 제1 클라이언트(1110)는 제1 클라이언트(1110)의 개인키를 이용해 제1 클라이언트(1110)의 인증서에 포함된 인증된 속성들에 대한 정보를 암호화함으로써 인증서 서명 정보를 생성할 수 있다. 또한, 제1 클라이언트(1110)는 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 이용해 인증키를 이용한 대칭키 방식 중 인증 메시지 생성 프로토콜에 따라 생성된 인증 메시지와 함께 제2 클라이언트(1120)에 전송할 수 있다.

제1 클라이언트(1110)는 제2 클라이언트(1120)의 인증서 및 인증서 서명 정보를 이용해 제2 클라이언트(1120)를 인증할 수 있다(S1015). 예를 들어, 제1 클라이언트(1110)는 제2 클라이언트(1120)의 공개키를 이용해 인증서 서명 정보를 복호화하고, 복호화 값과 제2 클라이언트(1120)의 인증서의 인증된 속성들에 대한 정보를 비교함으로써 제2 클라이언트(1120)의 인증서를 검증할 수 있다. 제2 클라이언트(1120)의 인증서가 모두 검증된 경우, 제1 클라이언트(1110)는 제2 클라이언트(1120)가 검증된 것으로 판단할 수 있다.

제2 클라이언트(1120)는 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 이용해 제1 클라이언트(1110)를 인증할 수 있다. 예를 들어, 제2 클라이언트(1120)는 인증 메시지와 함께 수신된 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 인증키를 이용한 대칭키 방식 중 인증 메시지 검증 프로토콜을 이용해 검증할 수 있다. 이후, 제2 클라이언트(1120)는 제1 클라이언트(1110)의 인증서에 포함된 제1 클라이언트(1110)의 공개키를 이용해 인증서 서명 정보를 복호화하고, 복호화 값과 제1 클라이언트(1110)의 인증서의 인증된 속성들에 대한 정보를 비교함으로써 제1 클라이언트(1110)의 인증서를 검증할 수 있다. 인증 메시지의 검증 및 제1 클라이언트(1110)의 인증서가 모두 검증된 경우, 제2 클라이언트(1120)는 제1 클라이언트(1110)가 검증된 것으로 판단할 수 있다.

이후 제1 클라이언트(1110) 및 제2 클라이언트(1120)는 서로 인증이 완료되었음을 나타내는 인증 완료 메시지를 상호간에 전송할 수 있다(S1017).

제2 클라이언트(1120)는 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트(1110)에 대한 등록 요청을 서버(1140)에 전송할 수 있고, 등록 요청과 함께 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 서버(1140)에 전송할 수 있다(S1030).

서버(1140)는 수신된 제1 클라이언트(1110)의 인증서 및 인증서 서명 정보를 이용해 제1 클라이언트(1110)의 정품 여부를 확인할 수 있다(S1035). 예를 들어, 서버(1140)는 제1 클라이언트(1110)의 인증서를 발행한 인증 기관의 공개키를 이용해 제1 클라이언트(1110)의 인증서 서명 정보를 복호화하고, 복호화 값과 제1 클라이언트(1110)의 인증서의 인증된 속성들에 대한 정보를 비교함으로써 제1 클라이언트(1110)의 인증서를 검증할 수 있다. 제1 클라이언트(1110)의 인증서가 검증된 경우, 서버(1140)는 제1 클라이언트(1110)가 정품인 것으로 판단할 수 있다.

서버(1140)는 핀 정보를 제2 클라이언트(1120)에 전송할 수 있고, 핀 정보와 함께 핀 정보 만료 시간을 제2 클라이언트(1120)에 전송할 수 있다. 서버(1140)는 보안의 강화를 위해 랜덤 데이터를 함께 제2 클라이언트(1120)에 전송할 수 있다.

제2 클라이언트(1120)는 서버(1140)로부터 수신된 핀 정보, 핀 정보 만료 시간 및 랜덤 데이터를 제1 클라이언트(1110)에 전송할 수 있다(S1045).

또한 제2 클라이언트(1120)는 서버(1140)로부터 핀 정보를 수신함에 따라, 서버(1140)에 따라, 서버(1140)에 핀 인증 결과 정보 요청을 전송할 수 있다(S1050). 핀 인증 결과 정보는 핀 정보 만료 시간 내에 서버(1140)에 핀 정보가 올바르게 입력되었는지 여부를 나타내는 정보일 수 있다.

제2 클라이언트(1120)는 핀 인증 결과 정보 수신에 응답하여 등록 완료 신호를 서버(1140)에 전송할 수 있다(S1070). 서버(1140)는 제2 클라이언트(1120)로부터 등록 완료 신호를 수신함에 따라 제1 클라이언트(1110)가 서버(1140)에 접근할 수 있는 권한을 포함하는 액세스 토큰을 제2 클라이언트(1120)에 전송할 수 있고, 제1 클라이언트(1110)를 식별하기 위한 유니크 식별자(Unique Identifier; Unique ID)를 함께 제2 클라이언트(1120)에 전송할 수 있다(S1080). 제2 클라이언트(1120)는 수신된 액세스 토큰 및 유니크 식별자를 제1 클라이언트(1110)에 전송할 수 있다(S1085). 이후, 제1 클라이언트(1110)는 액세스 토큰 및 유니크 식별자를 이용하여 서버(1140)에 접근할 수 있을 것이다.

도 17a는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 네트워크 인증 시스템(1300)을 나타낸다. 네트워크 인증 시스템(1300)은 제1 클라이언트(1110), 제2 클라이언트(1120) 및 키 관리 시스템(Key Management System; KMS; 1320)을 포함할 수 있다. 제2 클라이언트(1120)는 허브 장치라 칭해질 수 있고, 제1 클라이언트(1110)는 종단 장치라 칭해질 수 있다. 도 17a를 참조하면, 네트워크 인증 시스템(1300)은 하나의 제1 클라이언트(1110)를 포함하지만, 이는 설명의 편의를 위한 예시이고, 네트워크 인증 시스템(1300)은 복수의 종단 장치들을 포함할 수도 있다.

키 관리 시스템(1320)은 제1 클라이언트의 소트(Salt), 장치 ID(DEVICE ID), 식별자(IDENTIFIER) 및 비밀키(SECRET KEY)를 생성할 수 있다. 또한 키 관리 시스템(1320)은 소트, 장치 ID, 식별자 및 비밀 키를 이용해 제1 클라이언트(1110)의 인증키(KEY_AUTH)를 생성할 수 있다. 인증키(KEY_AUTH)의 생성은 도 17b에 개시된 인증키 생성 프로토콜에 따라 수행될 수 있다. 소트는 키 관리 시스템(1320)이 임의로 생성한 특정 비트 수의 데이터일 수 있다. 키 관리 시스템(1320)은 제2 클라이언트(1120)에 식별자 및 비밀키를 전달할 수 있으며, 제1 클라이언트(1110)에 소트, 장치 ID 및 인증키(KEY_AUTH)를 전달할 수 있다. 일 예시로서, 인증키(KEY_AUTH)는 제1 클라이언트(1110)에 미리 저장될 수 있다.

제2 클라이언트(1120)는 신뢰된 실행 환경(1122)을 포함할 수 있다. 신뢰된 실행 환경(1122)은 키 관리 시스템(1320)으로부터 수신한 식별자 및 비밀키를 저장할 수 있다. 신뢰된 실행 환경(1122)은 외부에서 접근이 불가능하기 때문에, 멀웨어 등과 같은 외부의 침입자는 식별자 및 비밀키에 접근할 수 없다.

제1 클라이언트(1110)는 보안 칩(1112)을 포함할 수 있다. 보안 칩(1112)은 키 관리 시스템(1320)으로부터 수신된 인증키(KEY_AUTH)를 저장할 수 있다. 보안 칩(1112)은 제1 클라이언트(1110) 내에서 보안이 강화된 영역이기 때문에, 외부에서 인증키(KEY_AUTH)에 접근할 수 없다. 제1 클라이언트(1110)는 장치 ID 및 소트를 저장할 수 있다.

제1 클라이언트(1110)는 제2 클라이언트(1120)에 검증 ID(VERIFY ID)를 사전에 전달할 수 있고, 제1 클라이언트(1110)의 인증을 위한 인증 메시지(AUTH MESSAGE)를 제2 클라이언트(1120)에 송신할 수 있다. 제1 클라이언트(1110)는 장치 ID, 소트, 인증 키(KEY_AUTH) 및 검증 정보를 이용해 인증 메시지(AUTH MESSAGE)를 생성할 수 있다. 제1 클라이언트(1110)의 인증 메시지(AUTH MESSAGE) 생성은 도 17c의 인증 메시지 생성 프로토콜에 따라 수행될 수 있다.

제2 클라이언트(1120)는 제1 클라이언트(1110)의 인증을 위해 인증 메시지(AUTH MESSAGE)를 수신할 수 있다. 제2 클라이언트(1120)는 사전에 수신된 검증 ID 및 인증 메시지(AUTH MESSAGE)를 이용해 제1 클라이언트(1110)를 인증할 수 있다. 제1 클라이언트(1110)에 대한 인증은 도 17d의 인증 메시지 검증 프로토콜에 따라 수행될 수 있다.

도 17b는 본 개시의 일실시예에 따른 인증키(KEY_AUTH)를 이용한 대칭키 방식을 설명하기 위한 인증키(KEY_AUTH) 생성 프로토콜을 나타낸다. 인증키(KEY_AUTH)의 생성은 도 17a의 제2 클라이언트(1120) 및 키 관리 시스템(1320)에 의해 수행될 수 있다. 이하에서 설명의 편의를 위해, 도 17b의 인증 키 생성 프로토콜이 제2 클라이언트에 의해 수행되는 것으로 설명한다. 키 관리 시스템에 의한 인증 키 생성 과정도 이하와 동일한 것으로 이해될 수 있다.

제2 클라이언트는 해쉬 함수를 이용해 식별자로부터 iHASH를 생성해낼 수 있다. 제2 클라이언트는 제1 태그(TAG1), iHASH 및 소트(SALT)를 이용해 제1 데이터 블록(DB1)을 생성할 수 있다. 제2 클라이언트는 제2 태그(TAG2) 및 소트를 이용해 제2 데이터 블록(DB2)을 생성할 수 있고, 해쉬 함수를 이용해 제1 데이터 블록(DB1)으로부터 해쉬 데이터 블록(HD)을 생성할 수 있다. 제1 태그(TAG1) 및 제2 태그(TAG2)는 일정한 비트 수를 갖는 임의의 데이터일 수 있다. 제2 클라이언트는 XOR 연산을 이용해 제2 데이터 블록(DB2) 및 해쉬 데이터 블록(HD)으로부터 마스크 데이터 블록(Masked DB)을 생성할 수 있다. 제2 클라이언트는 암호화 연산을 이용해 마스크 데이터 블록(Masked DB), 해쉬 데이터 블록(HD) 및 장치 ID(DEVICE ID)를 포함하는 메시지로부터 인증키(KEY_AUTH)를 생성할 수 있다. 암호화 연산은 비밀키(SECRET KEY)를 이용하여 수행될 수 있다.

따라서, 도 17a의 제2 클라이언트(1120)는 제1 클라이언트(1110)로부터 수신되는 인증 메시지(AUTH MESSAGE)에 포함된 소트 및 장치 ID와 저장하고 있던 식별자 및 비밀키를 이용하여 인증키(KEY_AUTH)를 생성할 수 있고, 키 관리 시스템(1320) 또한 소트, 장치 ID, 식별자 및 비밀키를 이용하여 인증키(KEY_AUTH)를 생성할 수 있다. 도17b에 개시된 인증키(KEY_AUTH) 생성 방식과 관련해, 여러 데이터를 이용해 데이터 블록을 구성하는 방식은 도 17b에 개시된 순서에 한정되지 않고, 데이터 블록 구성에 있어 데이터들의 순서는 바뀌어도 무방하다.

도 17c는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 인증 메시지(AUTH MESSAGE) 생성 프로토콜을 나타낸다. 인증 메시지(AUTH MESSAGE) 생성은 도 17a의 제1 클라이언트(1110)에 의해 수행될 수 있다.

제1 클라이언트는 미리 키 관리 시스템으로부터 인증키(KEY_AUTH)를 수신할 수 있고, 이를 보안 칩에 저장할 수 있다. 인증키(KEY_AUTH)는 암호화 키(KEY_ENC) 및 MAC 키(KEY_MAC)를 포함할 수 있다. 제1 클라이언트는 검증 ID(VERIFY ID), 타임 스탬프(TIME STAMP) 및 검증 정보(VFY_INFO)를 기초로 암호화 키(KEY_ENC)를 이용해 대칭키 방식의 암호화 연산을 수행하여 암호 메시지(ENC MESSAGE)를 생성할 수 있다. 검증 정보(VFY_INFO)는 제1 클라이언트의 인증에 사용할 다양한 검증 정보를 포함할 수 있다. 제1 클라이언트는 소트, 장치 ID 및 암호 메시지(ENC MESSAGE)를 기초로 MAC 키(KEY_MAC)를 이용해 MAC 연산을 수행하여 해쉬 메시지 인증 코드(HMAC)를 생성할 수 있다. 제1 클라이언트는 소트, 장치 ID, 암호 메시지(ENC MESSAGE) 및 해쉬 메시지 인증 코드(HMAC)를 이용해 인증 메시지(AUTH MESSAGE)를 생성할 수 있다.

따라서, 도 17a의 제1 클라이언트(1110)는 소트, 장치 ID, 인증키(KEY_AUTH)및 검증 정보(VFY_INFO)를 이용해 인증 메시지(AUTH MESSAGE)를 생성할 수 있다. 도 17c에 개시된 인증 메시지(AUTH MESSAGE) 생성 방식과 관련해, 여러 데이터를 이용해 데이터 블록을 구성하는 방식은 도 17c에 개시된 순서에 한정되지 않고, 데이터 블록 구성에 있어 데이터들의 순서는 바뀌어도 무방하다.

도 17d는 본 개시의 일실시예에 따른 인증키를 이용한 대칭키 방식을 설명하기 위한 인증 메시지 검증 프로토콜을 나타낸다. 인증 메시지(AUTH MESSAGE) 검증은 도 17a의 제2 클라이언트(1120)에 의해 수행될 수 있다. 설명의 편의 상, 도 17d에 음영 처리된 데이터 블록들은 수신된 데이터들을 나타내며, 음영 처리되지 않은 데이터 블록들은 내부에서 생성된 데이터들을 나타낸다.

제2 클라이언트는 수신된 인증 메시지(AUTH MESSAGE)에 포함된 소트 및 장치 ID를 이용해 도 17b의 인증키(KEY_AUTH) 생성 프로토콜에 따라 인증키(KEY_AUTH)를 얻어낼 수 있다. 인증키(KEY_AUTH)는 암호화 키(KEY_ENC) 및 MAC 키(KEY_MAC)를 포함할 수 있다.

제2 클라이언트는 수신된 인증 메시지(AUTH MESSAGE)에 포함된 암호 메시지(ENC MESSAGE)를 암호화 키(KEY_ENC)를 이용해 대칭키 방식의 복호화 연산을 통해 복호화 할 수 있고, 검증 ID(VERIFY ID), 타임 스탬프(TIME STAMP) 및 검증 정보(VFY_INFO)를 얻어낼 수 있다. 제2 클라이언트는 별도로 수신된 검증 ID, 타임 스탬프 및 검증 정보와 얻어낸 정보들을 비교함으로써 이들에 대해 검증 동작을 수행할 수 있다.

제2 클라이언트는 수신된 인증 메시지(AUTH MESSAGE)에 포함된 소트, 장치 ID 및 암호 메시지(ENC MESSAGE)를 MAC 키(KEY_MAC)를 이용해 MAC 연산을 수행함으로써 해쉬 메시지 인증 코드(HMAC)를 얻어낼 수 있다. 제2 클라이언트는 얻어진 해쉬 메시지 인증 코드와 수신된 해쉬 메시지 인증 코드를 비교함으로써 해쉬 메시지 인증 코드에 대해 검증 동작을 수행할 수 있다.

제2 클라이언트에 의해 검증 ID, 타임 스탬프, 검증 정보 및 해쉬 메시지 인증 코드 모두가 검증된 경우, 인증 동작이 정상적으로 완료되었다고 칭할 수 있다.

상기 제2 클라이언트에 의한 인증 메시지 검증 프로토콜은 제1 클라이언트의 장치 인증에 이용될 수 있으며, 그 뿐 아니라, 제1 클라이언트로부터 수신되는 검증 정보에 대한 무결성 검증에도 이용될 수 있을 것이다. 이와 같이, 인증 메시지 검증 프로토콜에 따른 제2 클라이언트에 의한 제1 클라이언트의 검증 정보에 대한 무결성 검증 동작을 '클라이언트간 무결성 검증' 동작이라 칭할 수 있다.

도 17a 내지 17d에 개시된 인증키(KEY_AUTH)를 이용한 대칭키 방식에 의하면, 제1 클라이언트 및 제2 클라이언트는 직접적으로 대칭키를 공유하지 않고도 간접적인 방식에 의해 인증키(KEY_AUTH)를 공유하는 효과를 얻을 수 있으며, 대칭키 방식에 따른 복호화 연산은 비대칭키 방식에 다른 복호화 연산에 비해 연산량이 적기 때문에 적은 리소스 만으로도 장치 인증 또는 무결성 검증 동작을 수행할 수 있다.

도 18은 본 개시의 일실시예에 따른 제1 클라이언트(1110)에 대한 무결성 검증을 수행하는 제1 및 제2 클라이언트-서버 컴퓨팅 시스템의 동작을 설명하기 위한 순서도이다.

도 18을 참조하면, 제2 클라이언트(1120)와 서버(1140)는 TLS 기반 핸드쉐이크를 시작할 수 있다(S1100). 즉, 제2 클라이언트(1120)와 서버(1140)는 TLS 프로토콜 스택의 핸드쉐이크 프로토콜을 기반으로 핸드쉐이크를 시작할 수 있다.

제2 클라이언트(1120)는 서버(1140)에 제1 클라이언트(1110)에 대한 제1 무결성 검증을 요청할 수 있다(S110). 서버(1140)는 제1 무결성 검증 요청에 응답하여, 제1 무결성 검증에 필요한 제1 검증 정보를 제2 클라이언트(1120)에 요청할 수 있다(S1120).

제2 클라이언트(1120)는 서버(1140)의 제1 검증 정보의 요청에 응답하여, 제1 검증 정보를 제1 클라이언트(1110)에 요청할 수 있다(S1130).

제1 클라이언트(1110)는 제2 클라이언트(1120)의 제1 검증 정보의 요청에 응답하여, 제1 검증 정보를 제2 클라이언트(1120)에 전송할 수 있다(S1140). 제1 검증 정보는 제1 클라이언트(1110)의 소프트웨어 설정 정보 및 클라이언트(120)로부터 생성된 소프트웨어 설정 서명 정보를 포함할 수 있다. 또한, 제1 클라이언트(1110)는 제1 검증 정보와 함께 제1 검증 정보를 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 생성 프로토콜에 따라 생성된 인증 메시지를 함께 제2 클라이언트(1120)에 전송할 수 있다.

제2 클라이언트(1120)는 제1 검증 정보를 이용하여 무결성 검증을 수행할 수 있다(S1150). 예를 들어, 제2 클라이언트(1120)는 수신된 제1 검증 정보 및 함께 수신된 인증 메시지를 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 검증 프로토콜에 따라 무결성 검증 동작을 수행할 수 있다.

제2 클라이언트(1120)는 무결성이 검증된 제1 클라이언트의 제1 검증 정보를 서버(1140)에 전송할 수 있다(S1160).

서버(1140)는 제1 검증 정보를 이용하여 제1 클라이언트(1110)에 대한 제1 무결성 검증을 수행할 수 있다(S1170). 이후, 제2 클라이언트(1120)와 서버(1140)는 TLS 기반 핸드쉐이크를 종료할 수 있다(S1180).

도 19a는 도 7b와 같이, 인증서(30)에 소프트웨어 설정 정보(SW_CI)가 포함된 경우에 제1 클라이언트(1210)에 대한 제1 무결성 검증 동작을 설명하기 위한 순서도이고, 도 19b는 도 7c와 같이, 보안 메모리 영역(368)에 소프트웨어 설정 정보(SW_CI)가 저장된 경우에 제1 클라이언트(1210)에 대한 제1 무결성 검증 동작을 설명하기 위한 순서도이다.

도 19a를 참조하면, 제2 클라이언트(1220)는 서버(1240)에 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트(1210)에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 전송할 수 있다(S1210).

서버(1240)는 제1 무결성 검증에 필요한 제1 클라이언트(1210)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제2 메시지를 제2 클라이언트(1220)에 전송할 수 있다(S1220).

제2 클라이언트(1220)는 서버(1240)로부터의 요청에 응답하여, 제1 클라이언트(1210)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제3 메시지를 제1 클라이언트(1210)에 전송할 수 있다(S1230).

제1 클라이언트(1210)는 제2 클라이언트(1220)로부터의 요청에 응답하여, 소프트웨어 설정 서명 정보를 생성할 수 있다(S1240). 예를 들어, 제1 클라이언트(1210)는 소프트웨어 설정 서명 정보를 보안 실행 환경에서 생성할 수 있다.

제1 클라이언트(1210)는 제1 클라이언트(1210)의 인증서 및 소프트웨어 설정 서명 정보를 제2 클라이언트(1220)로 전송할 수 있다(S1250). 또한, 제1 클라이언트(1210)는 인증서 및 소프트웨어 설정 서명 정보와 함께 이들을 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 생성 프로토콜에 따라 생성된 인증 메시지를 함께 제2 클라이언트(1220)에 전송할 수 있다.

제2 클라이언트(1220)는 제1 클라이언트(1210)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 이용하여 무결성 검증을 수행할 수 있다(S1260). 예를 들어, 제2 클라이언트(1220)는 수신된 클라이언트 인증서 및 소프트웨어 설정 서명 정보와 함께 수신된 인증 메시지를 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 검증 프로토콜에 따라 무결성 검증 동작을 수행할 수 있다.

제2 클라이언트(1220)는 무결성이 검증된 제1 클라이언트(1210)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 서버(1240)에 전송할 수 있다(S1270).

서버(1240)는 제1 클라이언트(1210)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 이용하여 제1 클라이언트(1210)에 대한 제1 무결성 검증을 수행할 수 있다(S1280).

도 19b를 참조하면, 제2 클라이언트(1220)는 서버(1240)에 TLS 연결의 핸드쉐이크를 시작하기 위해 제1 클라이언트(1210)에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 전송할 수 있다(S1210).

서버(1240)는 제1 무결성 검증에 필요한 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제2 메시지를 제2 클라이언트(1220)에 전송할 수 있다(S1222).

제2 클라이언트(1220)는 서버(1240)로부터의 요청에 응답하여, 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보에 대한 요청을 포함하는 제3 메시지를 제1 클라이언트(1210)에 전송할 수 있다(S1232).

제1 클라이언트(1210)는 제1 클라이언트(1210)의 소프트웨어 설정 서명 정보 및 제1 클라이언트(1210)의 보안 메모리 영역에 저장된 소프트웨어 설정 정보를 리드하여 제2 클라이언트(1220)로 전송할 수 있다(S1252). 또한, 제1 클라이언트(1210)는 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보와 함께 이들을 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 생성 프로토콜에 따라 생성된 인증 메시지를 함께 제2 클라이언트(1220)에 전송할 수 있다.

제2 클라이언트(1220)는 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보를 이용하여 무결성 검증을 수행할 수 있다(S1262). 예를 들어, 제2 클라이언트(1220)는 수신된 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보와 함께 수신된 인증 메시지를 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 검증 프로토콜에 따라 무결성 검증 동작을 수행할 수 있다.

제2 클라이언트(1220)는 무결성이 검증된 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보를 서버(1240)에 전송할 수 있다(S1272).

서버(1240)는 제1 클라이언트(1210)의 소프트웨어 설정 정보 및 소프트웨어 설정 서명 정보를 이용하여 제1 클라이언트(1210)에 대한 제1 무결성 검증을 수행할 수 있다(S1282).

제1 클라이언트(1210)는 보안 메모리 영역에 저장된 소프트웨어 설정 정보를 리드하여 제2 클라이언트(1220)에 전송하기 전에, 보안 메모리 영역에 저장된 소프트웨어 설정 정보의 위/변조 여부를 검증할 수 있다. 일 실시예로, 제1 클라이언트(1210)는 소프트웨어 설정 정보를 보안 메모리 영역에 저장할 때에, 보안 서명 정보도 같이 보안 메모리 영역에 저장할 수 있다. 보안 서명 정보는, 소프트웨어 설정 정보가 소정의 키를 통해 암호화된 정보이며, 보안 메모리 영역에 저장된 소프트웨어 설정 정보의 위/변조 여부를 검증하기 위해 필요한 정보를 의미한다. 제1 클라이언트(1210)는 보안 메모리 영역에 저장된 소프트웨어 설정 정보 및 보안 서명 정보를 리드하여, 보안 서명 정보를 복호화하고, 복호화된 값과 소프트웨어 설정 정보를 비교함으로써, 소프트웨어 설정 정보의 위/변조 여부를 검증할 수 있다. 제1 클라이언트(1210)는 위/변조되지 않음이 검증된 소프트웨어 설정 정보에 한하여, 제2 클라이언트(1220)에 전송할 수 있다.

도 20은 본 개시의 일실시예에 따른 제1 클라이언트(1410), 제2 클라이언트(1420) 및 서버(1440) 간의 핸드쉐이크 구간 내의 검증 동작을 설명하기 위한 순서도이다. 도 20은 도 12의 검증 동작과 비교하여 차이점 위주로 설명한다.

제2 클라이언트(1420)와 서버(1440)는 보안된 데이터 통신을 위한 세션 연결을 위해 도 1b의 핸드쉐이크 프로토콜(PT1)에 기반하여 다음과 같은 핸드쉐이크를 수행할 수 있다.

도 20을 참조하면, 제2 클라이언트(1420)는 TLS 기반 핸드쉐이크를 시작하기 위하여 클라이언트 헬로(Client Hello) 메시지를 서버(1440)에 전송할 수 있다(S1400). S1400 단계는, 도 12의 S400단계와 실질적으로 동일할 수 있다.

제2 클라이언트(1420)는 제1 클라이언트(1410)의 소프트웨어 설정 타입 정보를 포함하는 제1 클라이언트(1410)에 대한 제1 무결성 검증 요청을 서버(1440)에 전송할 수 있다(S1402). S1410 단계는, 제2 클라이언트(1420)가 제1 클라이언트(1410)에 대한 제1 무결성 검증 요청을 전송한다는 점을 제외하고는 도 12의 S402 단계와 실질적으로 동일할 수 있다.

서버(1440)는 클라이언트 헬로 메시지에 응답하여 서버 헬로(Server Hello) 메시지를 제2 클라이언트(1420)에 전송할 수 있다(S1410). S1410 단계는, 도 12의 S410단계와 실질적으로 동일할 수 있다.

서버(1440)는 제2 클라이언트(1420)로부터의 클라이언트 헬로 메시지 또는 제1 클라이언트(1410)에 대한 제1 무결성 검증 요청에 응답하여 제1 클라이언트(1410)의 클라이언트 인증서 및 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 제2 클라이언트(1420)에 요청할 수 있다(S1412). S1412 단계는, 서버(1440)가 제1 클라이언트(1410)의 클라이언트 인증서 및 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 제2 클라이언트(1420)에 요청한다는 점을 제외하고는 도 12의 S412 단계와 실질적으로 동일할 수 있다.

서버(1440)는 서버(1440)의 소프트웨어 설정 타입 정보를 포함하는 제2 무결성 검증 요청을 제2 클라이언트(1420)에 전송할 수 있다(S1414). S1414 단계는, 도 12의 S414단계와 실질적으로 동일할 수 있다.

서버(1440)는 제2 클라이언트(1420)가 제2 무결성 검증 또는 서버 인증서의 검증을 수행할 수 있도록 서버 인증서 및 서버(1440)의 소프트웨어 설정 서명 정보를 제2 클라이언트(1420)에 제공할 수 있다(S1416). S1416 단계는, 도 12의 S416단계와 실질적으로 동일할 수 있다.

이후, 서버(1440)는 클라이언트 헬로 메시지에 응답한 메시지 전송을 완료했음을 의미하는 서버 헬로 완료(Server Hello Done) 메시지를 제2 클라이언트(1420)에 제공할 수 있다(S1420). S1420 단계는, 도 12의 S420단계와 실질적으로 동일할 수 있다.

제2 클라이언트(1420)는 제2 무결성 검증 요청(S1414)에 응답하여, 서버 인증서 및 서버(1440)의 소프트웨어 설정 서명 정보를 이용하여 제2 무결성 검증을 수행할 수 있다(S1430). S1430 단계는, 도 12의 S430단계와 실질적으로 동일할 수 있다.

또한, 제2 클라이언트(1420)는 서버(1440)로부터 서버 인증서를 수신한 때에, 서버 인증서에 대한 검증을 수행할 수 있다(S1432). S1432 단계는, 도 12의 S432단계와 실질적으로 동일할 수 있다.

제2 클라이언트(1420)는 제1 클라이언트(1410)의 클라이언트 인증서를 요청할 수 있다(S1440). 경우에 따라, 제2 클라이언트(1420)는 제1 클라이언트(1410)의 클라이언트 인증서를 저장하고 있을 수 있고, 이러한 경우 S1440 단계는 선택적인(optional) 단계일 수 있다.

또한, 제2 클라이언트(1420)는 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 요청할 수 있다(S1442).

제1 클라이언트(1410)는 소프트웨어 설정 서명 정보 요청(S1442)에 응답하여, 소프트웨어 설정 서명 정보를 생성할 수 있다(S1450).

제1 클라이언트(1410)는 제1 클라이언트(1410)의 클라이언트 인증서를 제2 클라이언트(1420)에 전송할 수 있다(S1460). 경우에 따라, 제2 클라이언트(1420)는 제1 클라이언트(1410)의 클라이언트 인증서를 저장하고 있을 수 있고, 이러한 경우 S1440 단계는 선택적인(optional) 단계일 수 있다.

제1 클라이언트(1410)는 생성된 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 제2 클라이언트(1420)에 전송할 수 있다(S1462). 또한, 제1 클라이언트(1410)는 제1 클라이언트(1410)의 클라인트 인증서 및/또는 소프트웨어 설정 서명 정보를 인증키를 이용한 대칭키 방식의 인증 메시지 생성 프로토콜에 따라 생성된 인증 메시지를 함께 제2 클라이언트(1420)에 전송할 수 있다.

제2 클라이언트(1420)는 제1 클라이언트(1410)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보를 이용하여 무결성 검증을 수행할 수 있다(S1470). 예를 들어, 제2 클라이언트(1420)는 수신된 제1 클라이언트(1410)의 클라이언트 인증서 및 소프트웨어 설정 서명 정보와 함께 수신된 인증 메시지를 이용해 인증키를 이용한 대칭키 방식의 인증 메시지 검증 프로토콜에 따라 무결성 검증 동작을 수행할 수 있다.

제2 클라이언트(1420)는 제1 클라이언트(1410)의 클라이언트 인증서 및 제1 클라이언트(1410)의 소프트웨어 서명 정보를 서버(1440)에 전송할 수 있다(S1480). S1480 단계는, 제2 클라이언트(1420)가 제1 클라이언트(1410)의 클라이언트 인증서 및 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 전송한다는 점을 제외하고는 도 12의 S450 단계와 실질적으로 동일할 수 있다.

이후, 제2 클라이언트(1420)는 핸드쉐이크를 위한 메시지 전송을 종료한다는 클라이언트 종료(Client Finished) 메시지를 서버(1440)에 전송할 수 있다(S1482). S1482 단계는 도 12의 S454 단계와 실질적으로 동일할 수 있다.

서버(1440)는 제1 클라이언트(1410)에 대한 제1 무결성 검증 요청(S1402)에 응답하여, 제1 클라이언트(1410)의 클라이언트 인증서 및 제1 클라이언트(1410)의 소프트웨어 설정 서명 정보를 이용하여 제1 무결성 검증을 수행할 수 있다(S1490). S1490 단계는 도 12의 S460 단계와 실질적으로 동일할 수 있다.

또한, 서버(1440)는 제2 클라이언트(1420)로부터 제1 클라이언트(1410)의 클라이언트 인증서를 수신한 때에, 제1 클라이언트(1410)의 클라이언트 인증서에 대한 검증을 수행할 수 있다(S1492). S1492 단계는 도 12의 S462 단계와 실질적으로 동일할 수 있다.

이후, 서버(1440)는 핸드쉐이크를 위한 메시지 전송을 종료한다는 서버 종료(Server Finished) 메시지를 제2 클라이언트(1420)에 전송할 수 있다(S1495). S1495 단계는 도 12의 S472 단계와 실질적으로 동일할 수 있다.

도 21은 본 개시의 실시예들이 적용된 IoT 네트워크 시스템(2000)을 보여주는 개념도이다.

도 21을 참조하면, IoT 네트워크 시스템(2000)은 복수의 IoT 기기들(2100, 2120, 2140, 2160), 엑세스 포인트(2200), 게이트웨이(2250), 무선 네트워크(2300), 서버(2400)를 포함할 수 있다. 사물 인터넷(IoT, Internet of Things)은 유/무선 통신을 이용하는 사물 상호 간의 네트워크를 의미할 수 있다.

각 IoT 기기들(2100, 2120, 2140, 2160)은 각 IoT 기기의 특성에 따라 그룹을 형성할 수 있다. 예를 들면, IoT 기기들은 홈가젯 그룹(2100), 가전제품/가구 그룹(2120), 엔터테인먼트 그룹(2140), 또는 이동수단 그룹(Vehicle; 2160) 등으로 그룹핑 될 수 있다. 복수의 IoT 기기들(2100, 2120 및 2140)은 엑세스 포인트(또는, 허브 장치, 2200)를 통하여 통신망에 연결되거나 다른 IoT 기기에 연결될 수 있다. 엑세스 포인트(2200)는 하나의 IoT 기기에 내장될 수 있다. 게이트웨이(2250)는 엑세스 포인트(2200)를 외부 무선 네트워크에 접속하도록 프로토콜을 변경할 수 있다. IoT 기기들(2100, 2120 및 2140)은 게이트웨이(2250)를 통하여 외부 통신망에 연결될 수 있다. 무선 네트워크(2300)는 인터넷 및/또는 공중 네트워크(Public network)을 포함할 수 있다. 복수의 IoT 기기들(2100, 2120, 2140, 2160)은 무선 네트워크(2300)를 통해 소정의 서비스를 제공하는 서버(2400)와 연결될 수 있으며, 복수의 IoT 기기들(2100, 2120, 2140, 2160) 중 적어도 하나를 통해 유저는 서비스를 이용할 수 있다.

복수의 IoT 기기들(2100, 2120, 2140)은 엑세스 포인트(2200)와 암호화 보안 프로토콜 기반 통신을 수행할 수 있다. 일 실시예로, IoT 기기들(2100, 2120, 2140)은 엑세스 포인트(2200)와 TLS 기반 데이터 통신을 위하여, 이를 위해 IoT 기기들(2100, 2120, 2140)과 엑세스 포인트(2200)간의 핸드쉐이크가 수행될 수 있다. 본 개시의 실시예들에 따라, IoT 기기들(2100, 2120, 2140)과 엑세스 포인트(2200)간의 핸드쉐이크 구간 내에서 각각의 IoT 기기들(2100, 2120, 2140) 또는 엑세스 포인트(2200)의 무결성을 검증할 수 있다. 무결성 검증 결과에 따라 복수의 IoT 기기들(2100, 2120, 2140)은 엑세스 포인트(2200)와 암호화 보안 프로토콜 기반 통신을 위한 세션이 연결될 수 있다. 또한, 일부 IoT 기기들(2160)은 서버(2400)와 TLS 기반 통신을 수행할 수 있으며, 이 때도 역시, IoT 기기들(2160)과 서버(2400)간의 핸드쉐이크 구간 내에셔 IoT 기기들(2160) 또는 서버(2400)의 무결성을 검증할 수 있다.

이상에서와 같이 도면과 명세서에서 예시적인 실시예들이 개시되었다. 본 명세서에서 특정한 용어를 사용하여 실시예들을 설명되었으나, 이는 단지 본 개시의 기술적 사상을 설명하기 위한 목적에서 사용된 것이지 의미 한정이나 특허청구범위에 기재된 본 개시의 범위를 제한하기 위하여 사용된 것은 아니다. 그러므로 본 기술분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시예가 가능하다는 점을 이해할 것이다. 따라서, 본 개시의 진정한 기술적 보호범위는 첨부된 특허청구범위의 기술적 사상에 의해 정해져야 할 것이다.

Claims

클라이언트와 서버간 무결성(integrity) 검증을 지원하는 암호화 보안 프로토콜 기반 통신 방법에 있어서,
상기 서버가 TLS 연결의 핸드쉐이크를 시작하기 위해 상기 클라이언트에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 상기 클라이언트로부터 수신하는 단계;
상기 서버가 상기 제1 무결성 검증에 필요한 제1 검증 정보에 대한 요청을 포함하는 제2 메시지를 상기 클라이언트에 전송하는 단계;
상기 서버가 상기 제1 검증 정보를 상기 클라이언트로부터 수신하고, 상기 제1 검증 정보를 이용하여 상기 제1 무결성 검증을 수행하는 단계; 및
상기 핸드쉐이크를 종료하고, 상기 제1 무결성 검증 결과를 기반으로 상기 클라이언트와 상기 서버간 데이터 통신을 수행하는 단계를 포함하는 암호화 보안 프로토콜 기반 통신 방법.
제1항에 있어서,
상기 제1 무결성 검증 요청은,
상기 클라이언트의 소프트웨어 설정 타입 정보를 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제1항에 있어서,
상기 제1 검증 정보는, 클라이언트 인증서, 상기 클라이언트의 소프트웨어 설정 타입 정보 및 상기 클라이언트의 소프트웨어 설정 값을 포함하고,
상기 소프트웨어 설정 타입 정보 및 상기 클라이언트의 소프트웨어 설정 값은 상기 클라이언트의 보안 메모리 영역에 저장된 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제1항에 있어서,
상기 제1 검증 정보는, 상기 클라이언트의 인증서를 포함하고,
상기 클라이언트의 인증서는, 제1 공개키, 상기 클라이언트의 소프트웨어 설정 타입 정보 및 상기 클라이언트의 소프트웨어 설정 값을 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제4항에 있어서,
상기 제1 검증 정보는, 상기 클라이언트의 소프트웨어 설정 서명 정보를 더 포함하고,
상기 소프트웨어 설정 서명 정보는,
상기 클라이언트가 상기 제1 검증 정보에 대한 요청에 응답하여, 상기 클라이언트의 현재 소프트웨어 설정 값을 상기 제1 공개키에 대응하는 제1 개인키(private key)를 이용해 암호화(encryption)하여 생성된 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제4항에 있어서,
상기 제1 무결성 검증을 수행하는 단계는,
상기 서버가 상기 클라이언트의 인증서에 대한 검증을 수행하는 단계를 더 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제1항에 있어서,
상기 제2 메시지는, 상기 서버에 대한 제2 무결성 검증 요청 및 상기 제2 무결성 검증에 필요한 제2 검증 정보를 더 포함하고,
상기 암호화 보안 프로토콜 기반 통신 방법은,
상기 클라이언트가 상기 제2 검증 정보를 이용하여 상기 제2 무결성 검증을 수행하는 단계를 더 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제7항에 있어서,
상기 제2 검증 정보는, 상기 서버의 인증서를 포함하고,
상기 서버의 인증서는, 제2 공개키, 상기 서버의 소프트웨어 설정 타입 정보 및 상기 서버의 소프트웨어 설정 값을 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제8항에 있어서,
상기 제2 검증 정보는, 상기 서버의 소프트웨어 설정 서명 정보를 더 포함하고,
상기 소프트웨어 설정 서명 정보는,
상기 서버가 상기 서버의 현재 소프트웨어 설정 값을 상기 제2 공개키에 대응하는 제2 개인키를 이용해 암호화하여 생성된 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
제8항에 있어서,
상기 제2 무결성 검증을 수행하는 단계는,
상기 클라이언트가 상기 서버의 인증서에 대한 검증을 수행하는 단계를 더 포함하는 것을 특징으로 하는 암호화 보안 프로토콜 기반 통신 방법.
암호화 보안 프로토콜 기반 통신을 이용한 제1 클라이언트에 대한 무결성 검증 방법에 있어서,
상기 제1 클라이언트와 소정의 네트워크를 통해 연결된 제2 클라이언트가 서버와의 TLS 연결의 핸드쉐이크를 시작하기 위해 상기 제1 클라이언트에 대한 제1 무결성 검증 요청을 포함하는 제1 메시지를 상기 서버에 전송하는 단계;
상기 제2 클라이언트가 상기 서버로부터 상기 제1 클라이언트에 대한 상기 제1 무결성 검증에 필요한 상기 제1 클라이언트의 제1 검증 정보에 대한 요청을 포함하는 제2 메시지를 수신하는 단계; 및
상기 제2 클라이언트가 제1 검증 정보를 상기 서버에 전송하는 단계를 포함하는 무결성 검증 방법.
제11항에 있어서,
상기 제2 메시지에 응답하여, 상기 제2 클라이언트가 상기 제1 검증 정보에 대한 요청을 포함하는 제3 메시지를 상기 제1 클라이언트에 전송하는 단계; 및
상기 제2 클라이언트가 상기 제1 클라이언트로부터 상기 제1 클라이언트의 상기 제1 검증 정보를 수신하는 단계를 더 포함하는 무결성 검증 방법.
제12항에 있어서,
상기 제2 클라이언트가 상기 제1 클라이언트로부터 수신된 상기 제1 검증 정보를 이용하여 클라이언트간 무결성 검증을 수행하는 단계를 더 포함하고,
상기 클라이언트간 무결성 검증을 수행하는 단계는,
상기 제1 클라이언트 및 상기 제2 클라이언트 상호간의 인증키를 이용한 대칭키(Symmetric Key) 방식에 따른 인증 메시지 검증 프로토콜을 이용하는 것을 특징으로 하는 무결성 검증 방법.
제11항에 있어서,
상기 제1 클라이언트의 상기 제1 검증 정보는, 상기 제1 클라이언트의 클라이언트 인증서를 포함하고,
상기 클라이언트 인증서는, 제1 공개키, 상기 제1 클라이언트의 소프트웨어 설정 타입 정보 및 상기 제1 클라이언트의 소프트웨어 설정 값을 포함하는 것을 특징으로 하는 무결성 검증 방법.
제14항에 있어서,
상기 제1 클라이언트의 상기 제1 검증 정보는, 상기 제1 클라이언트의 소프트웨어 설정 서명 정보를 더 포함하고,
상기 소프트웨어 설정 서명 정보는,
상기 제1 클라이언트에 의해 상기 제1 클라이언트의 현재 소프트웨어 설정 값을 상기 제1 공개키에 대응하는 제1 개인키를 이용해 암호화하여 생성된 것을 특징으로 하는 무결성 검증 방법.
제11항에 있어서,
상기 제2 메시지는, 상기 서버에 대한 제2 무결성 검증 요청 및 상기 제2 무결성 검증에 필요한 제2 검증 정보를 더 포함하고,
상기 무결성 검증 방법은, 상기 제2 클라이언트가 상기 제2 검증 정보를 이용하여 상기 제2 무결성 검증을 수행하는 단계를 더 포함하고,
상기 제2 검증 정보는, 상기 서버의 인증서를 포함하고,
상기 서버의 인증서는, 상기 서버의 제2 공개키, 상기 서버의 소프트웨어 설정 타입 정보 및 상기 서버의 소프트웨어 설정 값을 포함하는 것을 특징으로 하는 무결성 검증 방법.
제16항에 있어서,
상기 제2 검증 정보는, 상기 서버의 소프트웨어 설정 서명 정보를 더 포함하고,
상기 소프트웨어 설정 서명 정보는,
상기 서버에 의해 상기 서버의 현재 소프트웨어 설정 값을 상기 제2 공개키에 대응하는 제2 개인키를 이용해 암호화하여 생성된 것을 특징으로 하는 무결성 검증 방법.
암호화 보안 프로토콜 기반 통신을 이용한 클라이언트의 서버 등록 방법에 있어서,
TLS 연결의 핸드쉐이크를 시작하기 위해 상기 클라이언트에 대한 등록 요청을 상기 서버에 전송하는 단계;
상기 서버로부터 핀 정보를 수신하는 단계;
상기 서버에 상기 핀 정보가 입력 되었는지 여부를 나타내는 핀 인증 결과 정보 요청을 상기 서버에 전송하는 단계;
상기 서버에 상기 핀 정보가 입력됨에 따라 상기 서버로부터 상기 핀 인증 결과 정보를 수신하는 단계; 및
상기 서버로부터 상기 서버에 접근할 수 있는 권한을 포함하는 액세스 토큰을 수신하는 단계를 포함하는 클라이언트의 서버 등록 방법.
제18항에 있어서,
상기 등록 요청을 상기 서버에 전송하는 단계에서,
상기 클라이언트의 인증서 및 인증서 서명 정보를 상기 서버에 더 전송하고,
상기 핀 정보는,
상기 서버에 의해 상기 인증서 및 상기 인증서 서명 정보를 기반으로 상기가 클라이언트가 정품으로 확인된 때, 상기 클라이언트에 할당된 핀을 나타내는 것을 특징으로 하는 클라이언트의 서버 등록 방법.
제18항에 있어서,
상기 핀 정보를 수신하는 단계에서,
상기 서버로부터 핀 정보 만료 시간을 더 수신하고,
상기 핀 인증 결과 정보는,
상기 핀 정보 만료 시간 내에 상기 서버에 상기 핀 정보가 입력되었음을 나타내는 것을 특징으로 하는 클라이언트의 서버 등록 방법.