Secure Key Exchange Protocols against Leakage of Long-tenn Private Keys for Financial Security Servers

금융 보안 서버의 개인키 유출 사고에 안전한 키 교환 프로토콜

Abstract

The world's widely used key exchange protocols are open cryptographic communication protocols, such as TLS/SSL, whereas in the financial field in Korea, key exchange protocols developed by industrial classification group have been used that are based on PKI(Public Key Infrastructure) which is suitable for the financial environments of Korea. However, the key exchange protocols are not only vulnerable to client impersonation attacks and known-key attacks, but also do not provide forward secrecy. Especially, an attacker with the private keys of the financial security server can easily get an old session-key that can decrypt the encrypted messages between the clients and the server. The exposure of the server's private keys by internal management problems, etc, results in a huge problem, such as exposure of a lot of private information and financial information of clients. In this paper, we analyze the weaknesses of the cryptographic communication protocols in use in Korea. We then propose two key exchange protocols which reduce the replacement cost of protocols and are also secure against client impersonation attacks and session-key and private key reveal attacks. The forward secrecy of the second protocol is reduced to the HDH(Hash Diffie-Hellman) problem.

세계적으로 통용되고 있는 키 교환 프로토콜은 TLS/SSL 등의 공개된 암호 통신프로토콜인 반면에 국내 금융권에서는 공인인증과 더불어 금융권에 적합한 공개키 기반 구조(PKI: Public Key Infrastructure)를 이용한 키 교환 프로토콜을 민간 주도로 개발하여 사용하고 있다. 하지만 금융권에서 사용하고 있는 키 교환 프로토콜은 클라이언트 위장공격(client impersonation attack)과 기지 키 공격(known-key attack)에 취약하며, 전방향 안전성 (forward secrecy)을 제공하지 않는다. 특히, 암호문과 서버 측 개인키(예: RSA 개인키)만 있으면 쉽게 과거의 세션키(session-key)를 알아내 암호화된 메시지를 복호화 할 수 있기 때문에, 만약 내부 관리 등의 문제로 인해 금융보안 서버의 개인키 유출 시 막대한 개인정보와 금융정보가 노출될 우려가 있다. 본 논문에서는 금융권에 사용 중인 암호 통신 프로토콜의 취약점을 분석하고, 국내 환경에 적합하도록 프로토콜 교체 비용을 최소화하면서 클라이언트 위장 공격과 세션키 노출 및 개인키 유출 사고에도 안전한 두 개의 키 교환 프로토콜을 제안한다. 또한 제안하는 두 번째 프로토콜이 HDH(Hash Diffie-Hellman) 문제가 어렵다는 가정 하에 증명 가능한 전방향 안전성을 제공함을 보인다.

Ⅰ. 서론

국내에서는 1999년 전자서명법이 개정되면서 금융권을 시작으로 PKI 보안 솔루션들이 급속도로 보급되기 시작했다. 인증 분야는 공인인증서가 자리를 잡았으며 , 사용자 정보 보호를 위한 클라이언트와 서버 간의 보안 통신 프로토콜은 금융감독원의 전자 금융 안전대책 기준(2000.9)에 의거 SEED 암호 알고리즘 의사용이 권고 되어 TLS/SSL 암호 통신 프로토콜이 아닌 민간 보안 업체에서 직접 개발한 암호 프로토콜을 사용하게 되었다〔1〕.

현재 금융권에서는 대고객 서비스 분야인 인터넷뱅킹 분야에 사용되는 암호 통신 프로토콜을 가장 중요하게 다루고 있으며, 프로토콜의 형태는 PKI/TTP 를 기반으로 구성되어 있고, 공개키 암호 알고리즘으로는 RSA만이 사용되고 있다. 민간 기업에서 개발한 암호 프로토콜은 혼합(hybrid) 구조로, 키 교환은 공개키 암호 시스템을 이용하고, 메시지에 대한 암호화는 교환된 세션 키를 이용해 대칭키 기반으로 암호화하고 있다. 따라서 클라이언트와 서버 간의 보안 통신의 안전성은 키 교환 프로토콜의 안전성에 의존한다.

키 교환 프로토콜의 가장 기본적인 안전성 요구사항은 키 기밀성(key secrecy)이다. 공격자는 정직한 개체 간의 통신을 도청하거나, 메시지를 위조하거나 변조하여 전송 할 수 있다. 키 기밀성은 이러한 수동적 및 능동적 공격자가 세션 키에 대한 어떠한 정보도 얻을 수 없어야 함을 의미한다. 키 기밀성 이외에 키교환 프로토콜에 요구되는 안전성은 전방향 안전성 (forward secrecy)과 기지 키 공격에 대한 안전성 (known-key secrecy)이다. 전 방향 안전성은 개체의 롱텀 개인 키 (long-term private key)를 알고 있는 어떠한 공격자라도 개인 키 노출 이전에 정직한 두 개체 간에 성공적으로 교환된 세션 키에 대한 어떠한 정보도 얻을 수 없어야 함을 의미한다. 기지 키 공격에 대한 안전성은 여러 세션의 세션키들이 노출되어도 노출되지 않은 세션의 키 비밀성에는 영향을 주지 않아야 함을 의미한다.

금융 암호 통신 프로토콜에서 문제가 되는 것은 키교환 부분으로, 키 기밀성, 기지 키 공격에 대한 안전성, 전방향 안전성 모두 만족하지 않는다. 만약 금융암호 통신 프로토콜이 위와 같은 공격에 대해 안전성을 갖도록 설계된다면, 국내 금융권 보안 수준을 한층 강화 할 수 있고, 금융권에서는 개인 키 관리를 위해 도입되는 고가의 HSM(Hardware Security Module)】) 장비 비용을 줄일 수 있을 뿐만 아니라, 보안 소프트웨어 공급 업계도 암호 소프트웨어의 업그레이드로 인한 시장 창출에 기여할 수 있다.

본 논문에서는 국내 환경에 적합하도록 프로토콜 교체 비용을 최소화하면서 키 기밀성. 기지 키 공격에 대한 안전성, 전 방향 안전성을 모두 제공하는 키교환 프로토콜을 제안한다.

본 논문의 2장에서는 현재 국내 금융권 암호 통신프로토콜의 사용 현황과 특징을 살펴보고, 금융권 암호 통신 프로토콜의 취약점 및 대책 현황을 설명한다. 3장에서는 국내 금융권에 적용 가전 방향전방향 안전성을 제공하는 두 가지의 안전한 키 교환 프로토콜을 제시한다. 4장에서는 제안하는 키 교환 프로토콜의 기존프로토콜 대비 효율성과 안전성에 대해서 설명하고, 5 장에서 결론을 맺는다. 부록에서 제안 프로토콜의 안전성을 증명한다.

Ⅱ. 국내 금융권 암호 통신 프로토콜의 사용 현황 및 취약점

국내에서는 인증기관(CA: Certificate Author- ity)이 TTP(Trusted Third Party)의 역할을 하는 PKI가 공인인증이라는 이름으로 광범위하게 이용되고 있다. CA가 발행하는 공인인증서는 신원확인 이외에, 전자서명에 대한 부인 방지, 암호화 통신을 위한 공개키 전달 등 다양한 용도로 사용되고 있다. 그리고 세계적으로 통용되고 있는 웹 브라우저(IE, FireFox, Safari, Opera 등)에서도 SSL(Secure Socket Layer)을 지원하고 있기 때문에, 국내를 포함해 세계 145개국 9만여 개의 ISP(Internet Service Provider) 에서 SSL 인증서를 발급받아 암호 통신 서비스를 제공하고 있다 (2008년 5월 Verisign 기준, TNS Research 조사).

현재 ISO, IEEE 등 국제 표준기구에서 표준으로 정해진 인증서를 사용하는 키 교환 스킴들은 대부분이 Diffie-Hellman 키 교환 방식〔10〕을 확장한 스킴들이다. 이는 Diffie-Hellman 키 교환 방식이 지니고 있는 구조의 유연성(flexibility)과 안전성 증명의 용이성에 기인하고 있다. 현재 학계에서 발표되는 키 교환 방식의 대부분도 Diffie-Hellman 방식을 이용하여 다양하고 융합된 환경과 강화된 안전성을 제공하도록 설계되고 있다〔8, 9.11-14〕. 반면에 국내에서는 상용 서비스 중인 모든 인증기관이 암호 통신을 위해 키 암호화(key encipherment) 용도로 발급하는 인증서 (X. 509)들은 모두 RSA 알고리즘만 지원하고 있다. 이는 사회적으로 TTP(즉 인증기관)를 통한 RSA 기반의 암호/인증 서비스가 이미 일반화되어, TTP 와 RSA 기반이 아닌 키 교환 프로토콜은 국내에 사용하기 어렵기 때문이다. 따라서 금융권에서 사용하는 암호 통신 프로토콜도 모두 RSA 암호 스킴만을 사용하고 있다. 또한 PKI에서 TTP의 역할을 하는 인증기관은 보안 사고에 대해서 오프라인(off-line) 상에서 중재역할을 하는 보험 창구의 기능도 수행하기 때문에, TTP가 존재하지 않는 자력 집행형 인증 (self-enforcement authentication) 방식의 프로토콜도 금융 분야와 같은 민감(critical)한 업무에는 사회적 분위기상 적용하기 어렵다.

2.1 금융권에서 사용 중인 암호 통신 프로토콜

국내 금융권에 사용 중인 암호 프로토콜은 공개키 암호 시스템과 대칭키 암호 시스템을 혼합(hybrid cipher)해서 사용 중이며, 그 형태에 따라 크게 키 교환 정보와 암호문이 일체화된 전자 봉투 방식과 키 교환을 별도로 수행 후 암호화된 메시지만 주고받는 세션 키 교환 방식의 두 가지 형태로 구성된다〔2〕.

〔표 1〕은 국내 인터넷 뱅킹 서비스를 제공하고 있는 시중 은행별 사용 중인 암호 프로토콜 형태에 대해 기술한 표이다.

〔표 1) 은행별 인터넷 뱅킹 암호 프로토콜 방식

(2009년 4월 기준)

세션 키 교환 방식과 전자 봉투 방식을 함께 쓰는 은행은 하나의 시스템에서 두 가지 방식을 모두 人] 용하는 것이 아니라, 각각의 업무에서 하나의 방식을 채택해 사용하고 있다. (예: 개인 인터넷 뱅킹-세션키 교환 방식, 기업 인터넷 뱅킹 - 전자 봉투 방식)

2.2.1 전자 봉투 방식

전자 봉투 방식은 하나의 암호문에 키 교환 정보와 메시지를 암호화한 내용이 함께 구성되어 있어 하나의 통신 전문으로 처리할 수 있는 편의성 때문에 많이 사용되고 있다. 하지만 세션 키 교환 방식에 비해 재생 공격(replay attack), 세션 하이젝킹 공격(session hijacking attack) 등에 취약해 점차 세션키 교환방식으로 바뀌고 있는 추세이다. (대부분의 은행들이 2010년까지 세션키 방식으로 교체할 예정이다 J

다음은 6阮海가 전자 봉투 형태의 암호문을 만드는 과정이다.

Step 1. Server 인증서의 유효성을 검증 후 Server 인증서에서 liSA 공개키를 추출한다. (Server 인증서는 X.509 표준을 따르며, 보통 공인인증기관(C₄)에서 발급 받는다.)

Step 2. 대칭 키 암호 알고리즘을 선택한다. (보통 SEED를 사용한다.)

Step 3. 난수 발생기 (secu芝e-random)를 이용해 , 선택된 대칭키 암호 시스템에서 사용 가능한 키 길이의 세션 키를 생성한다.

Step4. 세션 키를 陷W의 공개키로 암호화(PKCS#1 RSAES) 한다.

Sep 5. 세션 키로 전송하고자 하는 평문을 암호화한다. (예: SEED-CBC)

Step 6. 암호화된 세션 키 (키 교환 정보)와 평문에 대한암호문을 하나의 암호 전문으로 구성한다.

Step 7. 완성된 암호문을 Server에게 전송한다.

다음은 Server가 전자 봉투 형태의 암호문을 복호화하는 과정이다,

Step 1. <3血it로부터 전송된 암호 전문을 키 교환 정보와 암호화된 평문으로 분리한다.

Step2. 倒■의 RSA 개인 키를 이용해 암호화된 세션 키를 복호화한다.

StepS. 복호화된 세션 키로 암호화된 평문을 복호화한다. (예: SEED-CBC)

2.1.2 세션 키 교환 방식

세션 키 교환 방식은 통신을 개시하는 단계에서 보안 핸드쉐이킹 과정이 있어 키를 교환 후 암호화 통신을 수행한다. 보안 세션을 별도로 관리해야하는 부담이 따르지만, 모든 암호화 트렌젝션에 RSA 연산을 해야 하는 전자 봉투 방식에 비해, 초기 키 교환 과정에서만 RSA 연산이 한번 수행되기 때문에, 서버 시스템 부하를 최소화 할 수 있어 많이 사용 되고 있다. 전체적인 세션키 교환과정은〔그림 1〕과 같은 방식이나, 정확하게는 두 종류의 키 교환 방식이 존재한다.

〔그림 1) 세션 키 교환 방식

다음은 금융권에서 사용 중인 키 교환 과정이다. 이중 사전비밀정보 PS (premaster secret)를 통해 세션 키를 생성하는 키 생성 알고리즘 f는 사용 중인 암호 소프트웨어 마다 조금씩 다르다.

Step 1. Client는 Serwer에게 Server 인증서 Cfert、를 요청한다.

Step 2. Seruer는 Client로 Server 인증서 (刼如를 전송한다.

Step 3. Client는 Server 인증서 의 유효성을 검증 후, 난수 발생기 (secure-random)을 이용해, 임의의 사전 비밀정보 P^Cpremaster secret)를생성하고, Server 인증서 내의 RSA 공개키 e를 이용해 PS를 암호화(PKCS#1 RSAES)한 K= PEEPS')를 Server로 전송한다.

Step 4. 는 K를 자신의 RSA 개 인키 d를 이용해 복호화한다(用= PDd{K)).

Step 5- GKent와 Seruer는 세션키 생성 함수 j를 이용해 FS로부터 세션키 SKfPS') 를 계산한다.

2.2 금융권에서 사용 중인 암호 통신 프로토콜의 취약점 및 대책 현황

2.2.1 전자 봉투 방식의 취약점

키 기밀성. 전자 봉투 방식은 클라이언트 가장 공격 (impersonation attack)에 취약하기 때문에 능동적 공격자(active attacker)에 대한 키 기밀성을 제공하지 않는다. 전자 봉투 방식은 클라이언트가 세션 키를 생성해 서버의 공개키로 암호화 후 서버로 전달하는 방식이다. 이때 클라이언트가 전송하는 메시지에 대한 인증(authentication)이 없으므로 서버는 클라이언트로부터 받은 메시지가 실제 클라이언트가 보낸 메시지인지 확인할 수 없다. 따라서 공격자는 정직한 클라이언트를 가장하여 서버와 세션 키를 교환할 수 있게 되고, 서버는 클라이언트와 세션키를 교환했다고 생각하고 세션키를 향후 보안 통신에 사용할 것이다.

기지 키 공격에 대한 안전성. 전자 봉투 방식은 클라이언트가 세션키를 생성해 서버의 공개키로 암호화 후 서버로 전달할 때 난수 또는 타임스탬프(time stamp) 등이 사용되지 않으므로 재전송 공격 (replay attack) 이 가능하다. 만약 공격자가 특정 세션에서 클라이언트로부터 서버에 전송되었던 암호문을 새로운 세션에서 재전송한다면, 두 세션에서 계산되는 세션키는 항상 동일하다. 이 경우, 만약 한 세션의 세션키가 노출된다면 노출되지 않은 다른 세션 키 역시 알아낼 수 있으므로 전자봉투 방식은 기지 키 공격에 취약하다.

전 방향 안전성. 전자 봉투 방식은 클라이언트가 세션 키를 생성해 서버의 공개키로 암호화 후 서버로 전달하는 방식이기 때문에 서버의 개인키가 노출되었을 때, 이 키를 이용해 과거 보안 통신의 암호문을 복호하여 세션키를 알아낼 수 있기 때문에 전방향 안전성을 만족하지 않는다.

다음은 전자 봉투 방식이 서버의 개인 키 노출에 취약함을 실제 실험을 통해 알아본 것이다. 다음의 〔그림 2〕와〔그림 3〕은 전자 봉투 방식이 서버의 개인 키 노출에 취약함을 실제 예를 통해 알아보기 위하여 전자 봉투 형태의 암호 프로토콜을 사용하는 N은행의 통신 패킷을 캡춰한 결과와 그 암호문의 구성을 분석한 것이다.

〔그림 2) 전자 봉투 형태로 암호화된 HTTP Request(N 은행)

(그림 3) 전자 봉투 형태로 구성된 암호문의 분석

〔그림 4〕의 분석 결과를 보면 전자 봉투 형태의 프로토콜은 비교적 분석이 간단함을 알 수 있다. 전자 봉투 형태의 암호문은 모든 암호문에 복호화에 필요한 모든 정보(예: 키 교환을 위한 정보)가 들어있기 때문에, 패킷 단위로 수집하기도 편리하고, 프로토콜 자체가 전방향 안전성을 제공하지 않기 때문에, 서버의 공개키에 쌍이 되는 개인 키를 소유한 사람은 누구든 암호문을 쉽게 복호화 할 수 있다. 결과적으로 세션키를복호할 수 있고, 알아낸 세션 키로 암호화된 메시지를복호할 수 있다.

〔그림 4) K 은행 키 교환 과정의 패킷

2.2.2 세션 키 교환 방식의 취약점

키 기밀성. 세 선키 교환 방식도 전자봉투 방식과 마찬가지로 클라이언트가 세션 키를 생성하는데 사용되는 사전비밀정보 PS를 생성해 서버의 공개키로 암호화 후 서버로 전달하는 방식으로 클라이언트가 전송하는 메시지에 대한 인증(authentication)이 없으므로 누구나 클라이언트를 위장하여 서버와 세션키 교환이 가능하다. 따라서 세션 키에 대한 키 기밀성이 만족하지 않는다.

기지 키 공격에 대한 안전성. 세션 키 교환 방식도전자 봉투 방식과 마찬가지로 재전송 공격(replay attack)으로 매 세션의 세션 키를 동일하게 설정할 수 있다. 따라서 기지 키 공격에 안전하지 않다.

전 방향 안전성. 세션 키 교환 방식은 클라이언트가 사전 비밀정보 PS를 생성해 서버의 공개키로 암호화 후 서버로 전달하는 방식이기 때문에 서버의 개인 키가 노출 되었을 때, 이 키를 이용해 과거 보안 통신의 암호문을 복호하여 세션 키를 알아낼 수 있다. 따라서 전 방향 안전성을 만족하지 않는다.

다음은 세션 키 교환 방식이 서버의 개인키 노출에 취약함을 실제 실험을 통해 알아본 것이다. 다음의 〔그림 4〕와〔그림 5〕는 세션 키 교환 방식이 서버의 개인 키 노출에 취약함을 실제 예를 통해 알아보一기 위하여 세션 키 교환 방식의 암호 프로토콜을 사용하는 K 은행과 H은행의 키 교환 통신 부분을 캡춰한 결과이다.

〔그림 5] H 은행 키 교환 과정의 패킷

K은행의 경우(〔그림 4J) SSL Handshake를 통해 키 교환하는 것을 볼 수 있다. 이 경우에는 TLS/SSL 프로토콜이 공개이工로, SSL Handshake 과정에서의 패킷과 서버의 RSA 개인 키만 있으면 세션 키를 계산할 수 있다.

H 은행의 경우(〔그림 5〕)에도 Handshake 과정에서의 패킷과 서버의 RSA 개인키만 있으면 PS (premaster secret)까지는 복호화가 가능하나, PS를 통해 세션 키 (SK) 를 계산하는 / 알고리즘은 공개되어 있지 않다. 하지만 암호 소프트웨어를 담당하는 은행 직원과 개발 업체는 이 내용을 공유하고 있으므로, 최소한 이들이 내부공격자(inside attacker) 가 되는 경우 세션 키(SK)를 쉽게 계산할 수 있다. 즉, 현재 금융권에서 사용 중인 세션 키 교환 방식도전자 봉투 방식과 마찬가지로 전 방향 안전성을 제공하지 않으므로, 서버의 개인 키와 / 알고리즘을 아는 공격자인 경우 세션 키를 쉽게 얻을 수 있다.

2.2.3 키 유출 사고에 대한 대책 현황

앞에서 언급한 것과 같이 모든 금段권에서 사용 중인 암호 통신 프로토콜은 암호문과 서버의 RSA 개인 키만 있으면 모든 과거 암호 메시지를 복호화 할 수 있는 구조이기 때문에 내부에 악의적인 직원이 개인 키를 유출하거나, 관리의 부실로 개인키를 도난당했을경우 심각한 보안 문제가 발생하게 된다.

금융권에서도 이러한 문제 때문에 개인키의 중요성에 대해 인식하고 있어’ 개인 키 유출 방지를 위해 HSM(Hardware Security Module) 장비를 도입해 한번 주입된 개인 키는 밖으로 나올 수 없게 구성해놓았다. 하지만 결국 HSM 장비의 장애상황 발생을 우려해 개인키를 파일로 백업받아 놓아, HSM 장비의 역할이 유명무실하다고 볼 수 있다' 그리고 HSM 장비를 도입한 은행도 30-40% 정도밖에 되지 않기 때문에’ 대부분의 은행들은 단순히 파일로 개인 키를 관리하고 있어 그 관리의 실태가 심긱하■다. 따라서 암호 소프트웨어를 담당하는 금융권 내부 직원 또는 금융권에 서버 및 암호 소프트웨어 유지 보수를 담당하는 외부 직원이라면 대부분이 개인 키를 쉽게 얻을 수 있다. 더욱 우려되는 상황으로, 은행별로 HSM 장비를 도입했다가도 못 쓰고 있는 경우도 있는데, 이는 HSM 장비 성능이 은행에 사용 중인 슈퍼컴퓨터 급 서버 성능에 미치지 못해 HSM 장비가 병목 구간이 되어 정상적인 서비스를 할 수 없었기 때문이다.

상기한 바와 같이 개인 키 유출은 가능성이 희박한 학술적인 우려가 아니라. 국내의 특.수한 환경에서 반드시 대처해야할 위협이다. 이러한 이유에서 개인 키 유출에도 과거의 통신으로부터 개인정보와 금융정보를 보호할 수 있는 전 방향 안전성을 제공하는 키 교환프로토콜의 개발이 반드시 필요한 상황이다.

Ⅲ. 금융권에 적용 가능한 키 유출 사고에 안전한 키 교환 프로토콜

서론에서 언급한 바와 같이 국내에 상용 서비스 중인 모든 인증기관(CA)이 RSA 공개키 기반의 인증서만을 발급하고 있기 때문에. 프로토콜의 교체 비용을 최소화하기 위해서는 RSA 인증서와 RSA 알고리즘의 파라미터 (parameter)만을 사용하여 키 교환 스킴을 설계해야하는 제약이 따른다. 본 장에서는 전 방향 안전성을 위해 널리 사용되는 Diffie-Hellman 기법에 현재의 인증서를 그대로 사용하는 RSA 암호와 전자서명을 혼합한 키 교환 프로토콜을 제안한다. 먼저 RSA 알고리즘과 Diffie-Hellman 기법을 혼합할 수 있는 직시적인(straightforward) 방법인 FKE1 (Financial Key Exchange]) 프로토콜을 제시하고, 좀 더 교체 비용이 적은 FKE2 프로토콜을 제안한다. 제안 프로토콜은 모두 능동적 공격자에 대한 키 기밀성과 기지 키 공격에 대한 안전성 및 전 방향 안전성을 제공하도록 설계되었다.

본 논문에서는 a부터 b 사이의 정수의 집합을 0 씨로 나타낸다. 집합 S로부터 임의로 선택된 c에 대한 표기로 云S을 사용한다. 제안 프로토콜에서 사용하는기호는 〔표 2〕와 같다.

〔표 2] 기호

3.1 FKE1 프로토콜

초기화 단계. 클라이언트 6 와 서버 5는 인증기관 (。)으로부터 전자서명용 인증서 6切七, 와 를 각각 발급 받는다. 공개 파라미터인 (Z, 乃는 모든 개 체에게 접근 가능한 정보이다. 서명 알고리즘으로 RSA 서명 알고리즘을 사용한다.

키 교환 단계. 클라이언트 c와 서버 5는 세션 키를 교환하기 위해 다음과 같이 프로토콜을 수행한다.

Step 1. 서버 S는 Diffie-Hellman 파라미터인 P次 =(Gp, g)을 생성한다. G는 소수『를 위수(order)로 갖는 순환 군이고, g는 G의 생성자(generator)이다. 서버 S는 [1, ?] 내에서 랜덤 하게 &amp; 를 선택하여 % = g" modp를 계산한다. 그리고 RSA 개인 키를為를 이용해 서명값 七=阮%泪濟 匕)를 계산 후, 클라이언트 인증을 받을지 여부를 결정해 <:任{。, 1}를 선택 후, 클라이 언트 c에 게 (Ckrtg, {PDH, yj), as, c) 를 전송한디-.

Step 2. 클라이언트 6耘 CkrtgS] 유효성을 검증 후, 유효하다면 (3”$에서 공개키를 주줄 하여 서명 气를 검증한다. 만약 即가 유효하다면, [l, p] 내에서 랜덤하게 a를 선택하여>; = g"modp를 계산한다. 만약, Step 1에서 서버로부터 받은 c의 값이 0인 경우 서버 S에게 匕 를 전송하고, c의 값이 1인 경우 클라이언트 인증을 요구하는 것이므로. 자신의 개인 키 를 이용하여 匕에 대한 서명 = 匕)를 생성한다. 그리고 서버 S에게 (。"/匕9。)를 전송한다.

Step 3. 클라이언트 從 点 = (g^inodp를 계산한다. 서버 S는(가 0인 경우 k= (.9°)6 mod p를 계산하고, <가 1인 경우 Qrtc의 유효성을 검증하고. 유효하다면 서명 값 "를 검증한다. 가 유효하다면 서버 ■拦는 /: = 3)"modp를 계산한다.

Step 4. 클라이언트 (와 서버 S는 대칭키 암호 시스템에서 사용 가능한 형태의 세션 키 SK=H(C, S, 匕, 匕統)를 계산한디, .

실제로 금字권에서는 모든 암호 통신이 클라이언트 인증을 받지는 않기 때문에 클라이언트 인증 부분은 옵션으로 처리해 두었다. Step 4 이후 해쉬 함수나 MAC (message authentication code)을 이용한 키 확인(key conformation) 방법을 통해 정상적으로 키가 교환되었는지 확인하는 과정을 추가할 수 있다.

FKE1 프로토콜은 기존의 서명을 사용한 DH 키교환 방식과 큰 차이가 없고, 단지 DH 키 교환을 위해 DH 파라미터를 서버가 생성 후, RSA 서명해서 클라이언트에 전달해 주는 부분에서 차이가 있다. 현재 국내 금융 보안 서버에는 키 암호 화(keyencipherment)용 인증서만 발급되어 사용되고 있고. 클라이언트에게는 서명용 인증서만 발급되어 사용되고 있다. 따라서 본 프로토콜의 도입 시에는 서버가 전자 서명용 인증서를 별도로 발급받아야 하므로 추가 비용이 발생한다. 다음에서 클라이언트 측에서만 RSA 전자서명을 사용하도록 한 스킴을 제안한다.

(그림 6) FKE1 프로토콜

3.2 FKE2 프로토콜

초기화 단계. 클라이언트 C와 서버 S는 신뢰된 기관 (必)으로부터 전자서명용 인증서와 키 암호화 용인증서 Ckf 를 각각 발급받는다. 공개 파라미터인 (PKE, 疝 且)는 모든 개체에게 접근 가능한 정보이다. 암호 알고리즘으로 RSA 암호 알고리즘을 사용하고' 서명 알고리즘으로 RSA 서명 알고리즘을 사용한다.

키 교환 단계. 클라이언트 6 와 서버 S는 세션 키를 교환하기 위해 다음과 같이 프로토콜을 수행한다.

Step 1. 서버 S는 서버 인증서 方如에서 RSA 공개키 파라미터인 %®=(%e) 를 추출한다. 서버 ■아는 [l, n] 내에서 랜덤하게 b를 선택하여 * = /modri를 계산한다. n은 RSA의 공개된 법 (modulus)이고, e는 공개된 지수 (exponent) 이다. 서버 S는 클라이언트 인증을 받을지 여부를 결정해 ce{o, i}를 선택 후, 클라이언트 C에게(<3冰s, Yb, c)를 전송한다.

Step 2. 클라이언트 從 의 유효성을 검증 후, 유효하다면 [1, 끼 내에서 랜덤하게 a를 선택하여 Ya=ea moc坑를 계산한다. 그리고 서버의 공개키 e를 이용해 匕를 암호화한 X= 項 ( 匕) 를 계산한다. (이때, 암호화 함수 /举의 설계는 PKCS#1 RSAES-OAEPf- 따를 수 있다.) 만약. Step 1에서 서버로부터 받은 a의 값이 0인 경우 서버 s에게 X를 전송하고, C가 1인 경우 클라이언트 인증을 요구하는 것이므로. 자신의 개인 키를心를 이용하여 X에 대한 서명 % = 钩%* !)을 생성한다. 그리고 서버 S에게 (@仃。, ;七气)를 전송한다.

Step 3. 클라이언트 C는 方nJJWnodn를 계산한다. 서버 S는<가 0인 경우 X를 복호화 흐H%=F>q(X)를 생성 후, k=(匕)bmodn를 계산하고. c가 1인 경우 art。의 유효성을 검증한 후, 유효하다면 서명 값。«를 검증한다. <圣가 유효하다면 서버 S는 X를 복호화 해 K = PDd§X)를 생성 후, »= (炒)岫0<切를 계산한다.

Step 4. 클라이언트 C와 서버 S는 대칭키 암호 시스템에서 사용 가능한 형태의 세션 키 SK= I职를 계산한다.

Step 4 이후 해쉬 함수나 MAC을 이용하여 정상적으로 키가 교환되었는지를 확인하는 키 확인(key conformation) 과정을 추가할 수 있다.

완전성 (Completeness). 프로토콜이 모두 정상적으로 수행되면 클라이언트 C와 서버 S는 동일한 임시키 论= (e"), modn= (e")"modn= e""modn를 계산하게 되고, 동일한 세션 키 SK=H(e, 씨를 공유하게 된다.

〔그림 7) FKE2 프로토콜

FKE2 프로토콜은 기존에 사용 중인 키 암호 화용 서버 인증서와 클라이언트의 서명용 인증서를 교체하지 않고 사용할 수 있는 스킴으로, RSA 그룹 4:에서 Diffie-Hellman 키 교환 기법을 사용한 것으로 밑 (base)을 서버의 RSA 공개키 e로 사용한다’ 현재 금융권에서는 e를 고정된 소수인 22+1을 사용하고 있다〔7〕.

FKE2 프로토콜의 전 방향 안전성은 HDH(Hash Diffie-Hellman) 문제의 어려움에 기반한다. HDH 문제는 해쉬된 Diffie-Hellman 튜플(tuple)값과랜덤값을 구분하는 문제로 부록에서 자세히 설명한다. 합성수를 위수(composite order)로 가지는 순환군 %* 에서 DDH 문제는 어렵다고 알려져 있다〔5〕, 여기서 儿 = 网이고 電, 끄3丄号는 소수이고, 甘의 위수는 (p-l)(q-i)이다. 따라서 a에서 HDH 문제 역시 어려운 문제라는 것은 자명하다.

만약 서버 인증서 발급 과정에서 RSA 키 생성 시 e의 위수가 s(n)이 되고, 위의 조건을 만족하도록 p, q 를 선택한다면 기존의 e를 교체하지 않아도 되므로 프로토콜 교체 비용도 최소화할 수 있다.

〔그림 8〕은 FKE2 프로토콜을 실제로 구현했을 때 클라이언트와 서버가 정상적으로 같은 세션키를 공유하는지 확인할 수 있는 예제 프로그램 코드와 실행 결과이다.

〔그림 8) RSA 그룹(group)상에서 DH 구현 예제 (개발 언어: Java)

Ⅳ. 기존 프로토콜 대비 효율성 및 안전성 분석

4.1 기존 프로토콜 대비 효율성

금융권 암호 통신 프로토콜에서 가장 많은 비용이 드는 연산은 지수 승 연산이다. 그 중 1024bit에 가까운 RSA 개인 키 (private exponent) 'd에 대한 지수 승 연산 수행 시 가장 많은 비용이 필요하다. 그러므로 금융권에서는 서버를 기준으로 지수 승 연산을 최소화 하는 프로토콜 설계를 요구하고 있다. (반면 클라이언트에서 지수승 연산이 많이 일어나는 것은 수용하고 있다.)

현재 금융권에 적용된 키 교환 시스템은 모두 한 번의 키 교환 과정에서 서버 기준으로 한 번의 지수승연산이 이루어진다. 기존 프로토콜의 경우 키 교환 요청 시 서버 인증서만 클라이언트로 전달되지만, 제안된 프로토콜은 유형에 따라 서버 인증서와 몇 가지 안전성 파라미터 (security parameter)가 추가로 전달된다. 이 안전성 파라미터에 따라 FKE1 프로토콜과 FKE2 프로토콜의 성능은 많은 차이를 나타낸다.

4.1.1 FKE1 의 효율성

키 교환 과정에서 사용되는 DH Parameter 중 心는 한번 만 생성 후 계속 사용해도 되지만, Step 1 과정에서 b, :頃 弓는 매번 생성해야 하므로, 2번의 지수 승 연산이 필요하고, Step 3 과정에서 R(="modp)계산을 위해 1번의 지수 승 연산을 수행하므로 키 교환 과정에서 총 3번의 지수 승 연산이 필요하다.

4.1.2 FKE2의 효율성

Step 1 과정에서 匕(=/modn)를 계산해야 하므로 1번의 지수 승 연산이 이루어 지진다. Step 2, 3 과정 에서 熒 Dec 함수를 PKCS#1 RSAES-OAEP 스킴으로 설계할 경우, I를 RSA의 공개키 기의 바이트 길이, hLen을 OAEP에서 사용할 해쉬 알고리즘축약 값의 바이트 길이, mLen을 肝의 바이트 길이라고 했을 때, F■는 PKCSffl RSAES-OAEP 스킴에 정의된 한 블록에서 암호화 가능한 메시지의 길이 (mZenMZ-와iZen-2)를 벗어나기 때문에, 2개의 블록으로 나누어 암호화를 해야 한다. 그러므로 X의 길이는 2Z이 되어 Step 3 과정에서 Dec 함수를 2번 사용하게 되므로, 2번의 지수 승 연산이 필요하다. step 4 에서는 M*nio=de n) 를 계산하기 위해 1번의 지수 승 연산이 사용된다. 그러므로 총 4번의 지수승 연산이 필요하다.

하지만 匸를 암/복호화하는 함수를 PKCS#1 RSAES-OAEP 스킴을 사용하지 않고, X=PEe(Yj = 匸。modn, PDd(X) = X*nodn 으로 설계하면, Step 1 과정 에서 F(=d&modSS))를 미리 계산해 둠으로써 , Step 3 과정에서 단 1번의 지수승 연산으로 »(= *〃方0血 = 3。)* 也10血 =炒虹10<坑)를 계산할 수 있다. 이 경우 Step 1 과정의 지수 승 연산을 포함, 총 2 번의 지수승 연산이 필요하다.

4.1.3 기존 프로토콜과의 성능 비교

기존에 사용 중인 키 교환 프로토콜은 서버 측 기준으로 1번의 지수 승 연산이 일어나는 반면 본 논문에서 제안하는 프로토콜은 2〜4번 지수 승 연산이 이루어진다. 하지만 두 프로토콜 모두 서버 인증서 와 함께 클라이언트로 전송되는 안전성 파라미터 (security parameter)를 CPU 유휴시간 대에 많이 생성해 두거나, 중복 사용하되, 교체 주기를 하루에 한번 정도로 조절 흐卩견, 세션키(演)를 계산하는 과정에서만 지수 승 연산이 필요하므로, 기존 프로토콜과 성능 면에서 동일해진다. 단, FKE2는 RSAES-OAEP 사용 시 3번의 지수 승 연산이 사용된다.〔표 3〕은 RSA 키 크기 별 지수 승 연산 부하의 평균치를 조사한 것이다.

〔표 3) RSA 키 길이별 지수 연산 1회에 걸리는 평균 시간

(intelCPU 1.83Ghz, Sun Java 환경 기준)

〔표 4〕와〔표 5〕는 FKE 1, 2와 기존 키 교환(전자 봉투, 세션키 교환) 프로토콜의 지수 승 연산 수와 시간(1024 Bit 기준)을 비교한 것이다.

〔표 4] 클라이언트 인증이 없는 경우

〔표 5) 클라이언트 인증이 있는 경우

4.2 제안 프로토콜의 안전성 분석

FKE1 은 서명을 사용하는 인증된(authenticated) Diffie-Hellman 키 교환 방식으로 이미〔14〕 에서안전성 증명이 되었으므로. 본 논문에서는 FKE2에대한 안전성만을 증명한다. 제안 프로토콜의 안전성 증명에 필요한 암호 프리미티브(primitive)와 키 교환 프로토콜의 안전성 모델(security model)을 부록에서 정의한다.

다음 정리에서 FKE2 프로토콜이 클라이언트 인증을 포함하고(즉, (:— 1), 공개키 암호 스킴으로 IND- CCA(indistinguishability under chosen cipher­ text attack)에 안전한 RSAOAEP를 사용할 경우에 대한 안전성을 증명한다.

정리 1. (까 HDHCHash Diffie-Hellman) 가정이 만족하는 그룹이고, 프로토콜에서 사용하는 PKE 가 IND.CCA에 인전한 공개키 암호 스킴이고, X가 강한 위조불가능성 (strong unforgeability, SUF) 을 지닌 서명 스킴이라면, FKE2는 능동적 공격자에 대한 키 기밀성과 전 방향 안전성, 기지 키 공격에 대한 안전성을 제공한다' 구체적인 안전성은 다음과 같다.

#

f는 공격자의 수행 시간을 포함한 최대 총 게임의 수행 시간이다. 공격자는 釘개의 Execute 쿼리와 qse 개의 Send 쿼리를 만든다. 은 전체 클라이언트의 수이고, 0=<如+&amp; 이다

증명. 그룹 G에서 HDH 문제를 풀기 어렵다면, FKE2는 전방향 안전성을 제공한다. 클라이언트의 개인 키 如와 서버의 개인 키 d를 가지고 FKE2의 전 방향 안전성을 깨려는 공격자 4는 과거 통신으로부터 모든 암호문 X=/"e"「modn)를 얻을 수 있고、서버의 개인 키를 이용해 암호문 X를 복호할 수 있다. 이로부터 공격자 4는 ( 匕 =«七 % = /)를 알 수 있다. L와 Yb 로부터 세션키 5贸=7丑«必)에 대한 정보를 알아내기 위해서 공격자는 HDH 가정을 깨야 한다. 무시할 수 없는(non-ne이igible) 확률로 FKE2의 전방향 안전성을 깨는 공격자』를 이용하여 HDH 문제를 푸는 알고리즘을 만들 수 있다. (이에 대한 자세한 증명은 부록에서 설명한다.) 이것은 HDH 문제가 어렵다는 사실에 모순되므로 무시할 수 없는 확률로 다항 시간 안에 세션키에 대한 전 방향 안전성을 깨는 공격자가 존재 할 수 없음을 의미한다. 口

PKE八 IND-CCA에 안전한 공개키 암호 스킴이고, , 가 강한 위조 불가능성을 지닌 서명 스킴이라면, 제안 프로토콜은 능동적 공격자 4에 대한 키 기밀성을 제공한다. 만약 4가 서버를 가장하여 F을 선택하고, 프로토콜의 첫 번째 라운드에서 서버 S의 인증서 由如와 * = /'을 보낸다 하더라도 실제 서버 S는 두 번째 라운드에서 클라이언트가 전송하는 X=PEe{Ya) 로부터 K=e«에 대한 정보를 알아내기 위해서 공격자는 공개키 암호 스킴 瓦 RSA-OAEP) 의 IND-CCA 안전성을 깨야 한다. 또한 만약 4가 클라이언트를 가장하여 a'을 선택하고 匕' = 沼를 계산하여 , 두 번째 라운드에서 乂 = 孚(匕')을 서버 S에게 전송하기 위해서는 X에 대한 서명 값을 위조하여야 한다. 무시할 수 없는(non-negligible) 확률로 FKE 2의 키 기밀성을 깨는 공격자 4를 이용하여 RKE의 IND-CCA 안전성을 깨는 알고리즘이나 전자서명 스킴 £의 강한 위조불7] 능성을 깨는 알고리즘을 만들 수 있다. (이에 대한 자세한 증명은 본 논문의 full 논문인〔16〕 에서 설명한다.)

만약 두 세션에서 匕, = /(또는匕 = £少가 서버(또는 클라이언트)에 의해 반복 사용된다면 공격자』는 하나의 세션키를 이용해 다른 세션의 세션키를 알아낼 수 있다. 즉, 』는 FKE2의 기지 키 공격에 대한 안전성을 깰 수 있다. 하지만 vb 또는 匕가 반복되어 사용될 확률은 무시할만한(negligible) 하므로 공격자 A 가 FKE2의 기지 키 공격에 대한 안전성을 깰 확률 역시 무시할만한 값이다. (이에 대한 자세한 증명은 본 논문의 full 논문인〔16〕에서 설명한다.)

Ⅴ. 결론

본 논문에서는 현재 국내 금융권 암호통신 프로토콜이 서버의 개인키가 노출되었을 경우 쉽게 중요한 금융정보가 노출될 수 있음을 살펴보았으며, 클라이언트 위장 공격과 기지키 공격에 취약함을 보였다. 대부분의 보안사고가 내부 공격자에 의하여 이루어지고 있는 현실을 고려할 때, 서버의 개인키 노출에 대한 대비가 절실히 필요하다. 본 논문에서는 TTP와 RSA 를 반드시 사용해야 하는 국내 상황을 고려하여 국내 금융권에 사용 가능한 개인키 유줄 사고에 안전하며 키 기밀성과 전방향 안전성을 제공하는 증명 가능한 안전성을 가지는 키교환 프로토콜을 제시하였다. 국내의 특수한 상황을 고려할 때 제안된 프로토콜은 국내 연구자에 의 하여 수행되어야 되는 당위성과 시급성을 모두 만족하는 중요한 결과이다.