DOI QR코드

DOI QR Code

Vulnerability and Security Requirement Analysis on Security Token and Protection Profile Development based on Common Criteria Version 3.1

보안토큰의 취약성/보안요구사항 분석 및 CC v3.1 기반 보호프로파일 개발

  • Kwak, Jin (Soonchunhyang University, Department of Information Security Engineering) ;
  • Hong, Soon-Won (Korea Information Security Agency) ;
  • Yi, Wan-Suck (Korea Information Security Agency)
  • 곽진 (순천향대학교 정보보호학과) ;
  • 홍순원 (한국정보보호진흥원 평가기획팀) ;
  • 이완석 (한국정보보호진흥원 IT기반보호단 u-IT서비스보호팀)
  • Published : 2008.04.30

Abstract

Recently, financial institutes and industrial companies are adopted to security token such as OTP, smart card, and USB authentication token and so on for secure system management and user authentication. However, some research institutes have been introduced security weaknesses and problems in security tokens. Therefore, in this paper, we analyses of security functions and security requirements in security token performed by analyses of standardization documents, trends, security problems, attack methods for security tokens. Finally, we propose a CC v.3.1 based security token protection profile.

최근, 공공기관을 비롯한 금융기관 및 기업들은 안전한 시스템관리 및 사용자 신원확인을 위해 OTP, 스마트카드, USB 인증토큰 등의 보안토큰을 도입하고 있다. 그러나 최근 들어 이런 제품들에 대한 취약성이 소개되었다. 따라서 본 논문에서는 국내 외 보안토큰 표준화 및 개발 동향을 살펴보고, 보안토큰의 취약성, 공격방법 등의 분석을 통해 보안토큰이 일반적으로 갖춰야 할 보안기능과 보안 요구사항을 도출하고, 이를 바탕으로 CC v3.1 기반 보안토큰 보호프로파일을 개발한다.

Keywords

I.서론

최근 들어, 금융기관을 중심으로 전자금융거래의 보안 강화 방안으로 강한 사용자인증을 위해 보안토큰에 대한수요가 증가하고 있으며, 공공/국가기관에서도 안전한 시스템관리 및 사용자 신원확인을 위해 보안토큰을 도입하고 있는 추세이다. 인증(Authentication)은 사용자를 정당한 본인이라고 증명하는 것으로, 전자금융거래에서 사용자 인증에 사용되는 수단은 여러 가지가 있으며 현재 가장 많이 쓰이는 인증 수단으로 ID와 비밀번호가 있다. 사용자는 자신만 알고 있는 비밀번호를 인터넷뱅킹 서비스 접속 시 입력함으로써 사용자 자신이 정당한 본인임을 인증 받는 것이다. 이와 같이 비밀번호 한 가지 요소만 이용한 人}용자 인증을 단일요소인증(Single-Factor Authentication)이라고 하며 이때 사용된 비밀번호는 단일요소인증 수단이 된다. 이중요소인증(Two-Factor Authentication)은 두 개 이상의 인증수단을 이용하여 사용자를 인증하는 것이다. 사용자만 알고 있는 비밀번호 이외에 사용자가 가지고 있는 매체나 사용자의 고유한 생체정보를 결합시켜 사용자 인증 시 사용할 수 있으며, 스마트카드와 PIN(Personal Identification Number) 사용, 비밀번호와 공인인증서의 사용 등을 예로 들 수 있다. 이러한 강한 인증을 이용해 전자금융거래 시 이용자가 OTP를 사용하거나 보안카드, 또는 HSM(Hardware Security Module) 방식을 동시에 사용할 경우보다 안전한 사용자 인증 수단을 사용한 것으로 간주된다.

보안토큰은 사용자 인증을 위한 용도로 IC칩을 탑재해, 정보를 기록/처리할 수 있도록 하고 있으며, USB 플러그 형태를 한 USB형 토큰 등이 주로 사용된다. 대부분 이러한 솔루션들은 공개키기반구조(PKI: Public Key Infi*astructure)의 공개키 인증서에 주민등록번호 또는 생체인식 정보와 같은 사용자 개인에 대한 개인식별정보를 안전하게 주입하고 이러한 개인 식별정보가 포함된 공개키 인증서를 이용하여 사용자를 인증하는 방법 및 시스템에 대한 것이다. 또한, 공개키를 기반으로 하는 암호화 기술에서 스마트카드나 보안토큰 등과 같은 템퍼 프루프(Tamper-Proof) 매채에 대한 개인키인입 및 인출이 가능하도록 하는 공개키 기반 구조에서의 템퍼 프루프 매체를 이용한 개인키 관리 방법에 관한 것이다.

그러나, 최근 들어 이런 솔루션들이 Blackhat이나 Defbori등의 보안 컨퍼런스에서 제품들에 대한 취약성이 소개되고, 실제 공격을 수행한 사례들이 발생하면서 더 이상 보안토큰 방식의 인증솔루션에 대한 안전성을 보장할 수 없다는 인식이 확산되었다.

해외 각국에서는 이런 공격 및 취약점을 미연에 방지하기 위해 개발된 보안토큰에 대해 FIPS 13-2(암호 모듈검증)이나 CC(Common Criteria)기준을 통해 이들 제품에 대한 안전성을 검증 및 평가해 보증하고 있다[1, 2].

본 논문에서 제안하는 보안토큰 보호프로파일은, 산학연 보호프로파일 공동개발, 의 일환으로 한국 정보보호진흥원의 보호프로파일 개발 계획에 따라 공동으로 개발되었으며, 보안토큰 보호프로파일 개발을 위해 보안토큰의 형태별 분류에 따른 기능과 국외 보안토큰 관련 PP/ST의 내용에 대한 분석을 통해 보안토큰이 갖춰야 할 보안요구사항을 도출하고, 이를 기반으로 보안 토큰 보호 프로파일을 개발하였다. 본 논문에서는 ”인증토큰”, "USB 토큰”, ”암호토큰” 등으로 불리는 ”보안토큰"에 대한 취약성, 공격방법 등을 분석하고[3-6], 보안 토큰이 일반적으로 갖춰야 할 보안요구사항을 도출하며, 이를 기반으로 CC(Common Criteria) v3.1에 따른 PP (Protection Profile)를 개발한다.

Ⅱ. 관련연구

2.1. 보안토큰

2.1.1. 보안토큰 정의

토큰의 정의는 RFC 2828과 NIST에서 다음의 [표 1] 과 같이 기술되어있다.

〔표 1〕보안토큰 정의

2.1.2. 보안토큰 동향

보안토큰은 그 형태에 따라, USB 플래쉬 메모리, OTP 토큰, USB 인증 토큰 또는 암호토큰으로 구분할 수 있으며, 각각의 특징 및 주요 기능은 다음의 [그림 1]에 정리하였다.

[그림 1] 하드웨어 토큰 현황 (형태별 분류)

2.2. 국외 보안토큰 PP/ST 비교

현재 보안토큰관련 국외 PP/ST는 4종이 존재하고 있으며, 스마트카드와 유사한 보안요구사항을 규정하고 있다[7-10]. 다음의 [표 2]는 국외 보안토큰 관련 PP/ST 현황에 대하여 정리한 것이다.

〔표 2) 국외 보안토큰 관련 PP/ST 현황

미국 DoD의 PKI/KMI PP는 공개키 인증서의 안전한 생성, 배포, 제어, 추적, 폐기에 사용되는 디바이스를 보안토큰으로 정의하고 있으며, IC칩과 운영체제를 포함하고 있다. 본 PP는 기존 스마트카드 PP인 SCSUG-PP의 내용을 대부분 수용하고 있다. 보증등급은 EAL4+ 등급이다.

독일 USB 데이터 미디어 PP는 사용자 인증 및 주요 데이터에 대한 암호화 저장기능을 제공하고 있으며, USB 형태의 디바이스를 정의하고 있다. 보증등급은 EAL2+(ADV_SPM.l)로 정의되어 있으며, TOE의 기능은 사용자 인증, 암호화, 물리적 보호 등으로 정의하고 있다.

프랑스 Authentication Device PP는 유럽 전자서명법에 의한 인증서 검증 디바이스에 대해 정의하고 있으며, 보증등급은 EAL4+(ADV_IMP.2, ADV_INT.l, ALC_ FLR.3, AVA_VAN.5)이며, TOE의 주요 기능은 인증서 검증과 사용자 인증 기능으로 정의하고 있다.

iKey 2032 ST는 사용자를 단말기에 인증하고 인증서 관리 및 처리 용도로 사용되는 USB 인증 토큰의 형태를 정의하고 있으며, 보증등급은 EAL2이며 TOE의 주&기능으로는 공개키 생성 및 인증서 검증, 사용자 인증 등에 대해 정의하고 있다.

다음의 [표 3]은 국외 PP/ST의 TOE 용도, 형태, 범위, 기능, 그리고 보증등급에 대하여 비교하여 정리한 것이다.

〔표 3) 해외 PP 비교

2.3. 보안토큰 취약성 및 보안요구사항

2.3.1. 주요 공격방법

2.3.1.1. 물리적인 공격

물리적인 공격의 목적은 보안토큰 내부의 장치들에 접근하여 전기적 공격 방법이 흔적 없이 적용되도록 하는 것이다. 그러므로 보안토큰 장치들은 내부의 장치들에 대한 침입과 훼손 등을 방지하거나 탐지하기 위하여 탬퍼 방어(temper-proofing) 특성을 가지도록 설계하여야 한다. 그러므로 물리적 공격을 막기 위해서는 외부 덮개가 개봉되지 않도록 하나의 부품으로 성형하며 회로의 구성을 복잡하게 하여 분해가 어렵도록 하여야 한다.

2.3.1.2. 전기적인 공격

외부 덮개가 제거되어진 보안토큰의 내부 회로는 마이크로프로세서와 외부 메모리, 그리고 몇 개의 소자들로 이루어져 있으며, 패스워드 등의 비밀 정보는 EEPROM에 저장되어 있다. EEPROMe 읽기와 쓰기가 가능한 메모리로써 사용자와 공격자가 모두 접근 가능하므로 공격자가 EEPROM에 저장된 패스워드를 바꿔 쓰는 것이 가능하다. 따라서 EEPROMe 여러 분야에 많이 사용되지 만 EEPROM의 특성으로 인하여 보안상의 문제점이 존재한다. 그러므로 보안토큰 장치 등에 EEPROM을 사용할 경우에는 이에 대한 접근제어 방안이 요구된다. 그러므로 전기적 공격을 방어하기 위해서는 내부 회로에 대해 코팅하여야 하며, 마이크로프로세서를 안전한 메모리와 함께 사용하여야 한다.

〔표 4) 보안토큰의 주요 공격 방법

2.3.1.3. 소프트웨어적 공격

소프트웨어적 공격은 보안토큰에 어떤 조작이나 물리적인 변형을 가하지 않고 적용하는 공격으로, 보안토큰의 정상 동작 상태에서 소프트웨어나 펌웨어의 결점을 찾아내는 것을 목적으로 한다. 공격의 영역은 2가지로 나눌 수 있는데, 첫 번째는 보안토큰과 호스트 컴퓨터 사이의 통신 채널을 분석함으로써 문서화되지 않은 명령어와 고의적인 오류 명령어를 사용하는 방법이고 두 번째는 보안토큰의 PIN 등을 brute-force 공격을 통해서 알아내는 방법이다. 일반적으로 보안토큰 제품 구입 시 제공되는 Software Development Kits(SDK)의 헤더나 소스 코드에 소프트웨어 구조와 같은 많은 정보들이 포함되어 있다. 그러므로 소프트웨어적 공격 방법을 방어하기 위해서는 보안토큰 개발 단계에 사용하던 명령어는 모두 제거하고, 고의적인 오류 명령어나 불법 패킷에 안전하도록 설계하여야 한다.

2.3.2. 취약성 식별

공격자는 공격을 수행하기 위해 먼저 TOE(Target of Evaluation)의 취약성을 식별하고, 그 취약성을 악용 하고 공격을 시도한다. 하드웨어에 관련되는 취약성은 [표 5]와 같이 분류할 수 있다.

(표 5) 보안토큰 관련 취약성 분석

2.3.3. 취약성 식별에 따른 위협의 재 분류

물리적인 공격의 목적은 보안토큰 내부의 장치들에 접근하여 전기적 공격 방법이 혼적 없이 적용되도록 하는 것이다. 이와 관련되는 위협은 크게 아래의 3가지 항목으로 크게 나눌 수 있다. .

O T.1 : TOE의 물리적 취약성을 이용해 공격하는 것

O T.2 : TOE의 복제(클론)를 사용해 공격하는 것

O T.3 : TOE의 개발 . 제조 . 배부 등의 환경으로부터 TOE의 공격에 이용할 수 있는 정보를 훔치는 것

■ T.1 : 공격자가 TOE의 물리적 특성과 관련된 취약성을 이용해 TOE에 물리적으로 접근해 사용자의 정보 자산을 공격 (폭로 ・ 개찬 . 파괴 . 액세스방해) 한다.

■ T.2 : 공격자가 TOE 복제 (클론)를 만들어 클론을 사용해 사용자의 정보 자산을 훔치거나 TOE의 서비스 제공을 방해한다.

■ T.3 : 공격자가 TOE 의 개발 환경, 제조 환경, 배포 환경에 접근해 TOE의 설계 정보를 훔친다. 이 설계 정보는 TOE의 취약성을 식별하거나, TOE 의 복제를 만드는 등 다른 공격을 수행하기 위해 사용된다.

Ⅲ. 보안토큰 보호프로파일

3.1. TOE 개요 및 정의

TOE는 사용자 식별 및 인증 기능을 수행하는데 사용되고 암호 키와 인증서 등을 저장하며, 보안토큰에는 스마트카드, USB 토큰, PCMCIA 카드를 포함하는 다양한 형태가 존재한다.

TOE는 집적회로에 탑재되는 임베디드 소프트웨어이며, 집적회로는 연산을 위한 중앙처리장치, 데이터 저장을 위한 메모리, 통신을 위한 USB, 무선 등의 인터페이스 등으로 구성된다. TOE가 보호하고자 하는 자산은 보안토큰의 소유자를 증명하기 위한 패스워드, 암호 키, 인증서를 비롯해 TOE 자체, TOE 내부의 중요 데이터 (보안 속성, TSF 데이터 등)이다.

보안토큰은 다양한 응용에 활용될 수 있는 사용자 인증을 위한 디바이스로, 인증을 위한 정보(개인 식별번호、암호 키, 바이오인식 정보 등)를 저장한 휴대용 인증토큰이다. TOE는 주로 PC, 단말기 등에서 사용자 인증 장치로 사용되며, 원격 접근, 전자서명, 암호화한 기밀성이 높은 메일 교환 등에 이용할 수 있匸+. TOE는 제한된 접속을 허용하는 온라인 서비스에 접속하거나 서비스 이용 시 전송되는 개인 식별번호, 패스워드 등의 비밀성 또는 무결성을 검증하기 위해 사용된다. TOE는 전자서명 키를 보안토큰 내부에서 생성함으로써 인증서 등의 중요정보를 각종 보안위협으로부터 안전하게 보관할 수 있는 저장장치로 사용된다.

3.1.1. TOE 범위

다음 [그림 2]은 보안토큰의 TOE 범위를 나타내고 있다. 보안토큰은 보안기능 수행 등의 연산을 위한 CPU 및 제어회로와 임베디드 소프트웨어를 저장하는 휘발성/비휘발성 메모리, 통신을 위한 무선 및 USB 인터페이스 등의 하드웨어 장치인 IC칩과 메모리 등에 탑재되는 임베디드 소프트웨어다.

[그림 2] TOE 정의

TOE의 물리적 범위인 임베디드 소프트웨어는 IC칩의 ROM이나 EEPROM 등 메모리에 탑재되어, IC칩을 구동하고, 보안기능을 수행하는 역할을 담당하는 OS, 응용프로그램 등으로 이뤄져 있다. TOE의 논리적 범위와 경계는 IC칩을 구동하기 위한 파일, 프로세스, 메모리 관리 등의 OS기능과 응용프로그램에서 제공하는 암호화 기능과 식별 및 인증, 접근통제 등의 보안기능이다. 보안토큰은 사용자가 인증 데이터를 입력할 수 있는 단말기(PIN 패드 터미널, PC 등)와 통신을 수행하며, 단말기는 보안토큰과의 안전한 통신을 위해 신뢰된 장치이다.

3.1.2. TOE 기능

TOE의 안전성을 보장하기 위해서는 암호지원, 접근통제, 데이터보호, 식별 및 인증, 보안 관리, TOE 보호 등의 보안기능이 요구되며, 요구되는 각각의 보안 기능에 대한 내용을 다음의 [표 6]에 정리하였다.

〔표 6) TOE 보안기능

3.2. TOE 보안문제의 정의

TOE 보안문제는 TOE 및 운영환경에 의해 대응되어야 하는 위협, 수행되어야 하는 조직의 보안정책, 지원되어야 하는 가정사항으로 나누어 설명하며, 다음 [표7]은 그 내용을 정리한 것이다.

〔표 7] 보안문제 정의

보안토큰은 휴대용이므로, 개인이 소지해 관리해야 하므로 논리적인 위협과 함께 물리적인 위협도 발생하게 된다. 위협원은 일반적으로 TOE 및 보호 대상시스템에 불법적인 접근을 시도하거나 비정상적인 방법으로 TOE에 위해를 가하는 외부 실체이며, 위협원은 강화된 -기본 수준의 전문지식, 자원, 동기를 가진다. 조직의 보안정책은 본 논문에서 제안하는 보호프로파일을 수용하는 TOE에서 준수되어야 하는 사항이며, 가정사항은 본 프로파일을 수용하는 TOE 운영환경에 존재한다고 가정 된다.

3.3. TOE 보안목적

본 논문에서 제안하는 보호프로파일은 보안목적을 TOE에 대한 보안목적 및 운영환경에 대한 보안목적으로 분류하여 정의한다. TOE에 대한 보안목적은 TOE에 의해서 직접적으로 다루어지는 보안목적이고, 운영환경에 대한 보안목적은 IT영역이나 비기술적/절차적 수단에 의해 다루어지는 보안목적이다.

다음의 [표 8]은 TOE에 대한 보안목적과 운영환경에 대한 보안목적의 내용을 정리한 것이다.

〔표 8) TOE 보안목적

보안목적의 이론적 근거는 명세한 보안목적이 적합한 보안 문제를 다루기에 충분하며, 과도하지 않고 반드시 필요한 것임을 입증한다. 그러므로 보안목적의 이론적 근거는 각 위협, 조직의 보안정책, 가정사항이 최소한 하나의 보안목적에 의해 다루어지며, 각 보안목적은 최소한 하나의 위협, 조직의 보안정책, 가정사항을 다루며, 다음의 [표 9]와 같이 대응된다.

〔표 9] 보안환경과 보안목적 대응

3.4. 보안요구사항

3.4.1. 보안기능 요구사항

보안요구사항은 보안기능요구사항과 보증요구사항으로 나누어 서술한다. 보안기능요구사항은 보안목적을 충족하기 위한 TOE 및 IT 환경의 요구사항으로 정의된다. 즉, TOE 및 IT 환경은 보안기능요구사항을 통해 보안목적을 달성하며, 보안기능요구사항은 모든 보안목적을 충족해야 한다. 보증요구사항은 TOE가 제공하는 보안기능에 대하여 보증을 하기위한 요구사항을 제시한다. 이는 평가보증등급(EAL)에 따라 공통평가기준 3부의 부록에 패키지 형태로 구성이 되어있다. 본 논문에서는 보증등급을 EAL4로 선정하고 이에 해당하는 보증요구사항을 기술한다. [표 1이는 보안 기능요구사항을 나열하였으며, [표 11]는 [표 10]에서 도출한 보안 기능요구사항들이 TOE의 보안목적을 달성하는지 이론적 근거를 제시한다. 보안기능요구사항과 보안목적의 달성 여부를 상세히 서술할 수 있으나, 간단하게 보안 기능요구사항과 보안목적의 매핑으로 이론적 근거를 표시하였다. 마지막으로 [표 12]에서 도출한 보안 기능요구사항이 종속관계를 모두 만족하고 있음을 나타낸다.

〔표 10) 보안기능요구사항

〔표 11) 보안목적과 보안기능요구사항 대응

(표 12) 보안목적과 보안기능요구사항 대응

3.4.2. 보증요구사항

본 논문에서 제안하는 보호프로파일이 보증요구사항은 공통평가기준 3부의 보증 컴포넌트로 구성되었고, 평가보증등급은 EAL4 이다. 다음의 [표 11]은 보증 컴포넌트들에 대해 정리한 것이다.

3.4.3. 보안요구사항의 이론적 근거

보안요구사항의 이론적 근거는 서술된 보안 요구사항이 보안목적을 만족시키기에 적합하고, 그 결과 보안 문제를 다루기에 적절함을 입증한다. 그러므로 각 TOE 보안목적은 적어도 하나의 보안기능요구사항에 의해서 다루어지며, 각 보안기능요구사항은 적어도 하나의 TOE 보안목적을 다룬다. 다음의 [표 12]는 보안목적과 보안 기능요구사항 사이의 대응관계를 나타낸 것이다.

Ⅳ. 결론

본 논문에서 제안하는 보안토큰 보호프로파일은 보안토큰에 대한 최소 보안요구사항을 정의하고 있다. 그러므로 본 보호프로파일을 이용하는 제품 개발자 또는 판매자는 본 보호프로파일에 정의된 내용들을 모두 준수하여 보안목표명세서를 작성할 수 있고 사용자는 사용하고자 하는 제품의 선정 및 운용관리를 위해 활용할 수 있다. 본 보호프로파일은 보안토큰에서 요구되는 최소한의 보안요구사항을 포함하고 있으며 TOE의 구현모델에 대하여 정의하지는 않는다. 그러므로 TOE의 구현 모델에 따라 발생할 수 있는 사항에 대해 개발자는 추가적인 보안문제, 보안목적, 보안요구사항을 정의해야 한다. 만약 TOE가 분산형태로 구현될 경우, 각 구성 요소 간 전송데이터를 외부의 위협으로부터 보호하기 위하여 개발자는 보안목표명세서 에 추가적인 보안 문제, 보안목적, 보안요구 사항을 정의해야 한다.

References

  1. Common Criteria for Information Technology Security Evaluation, Version 3.1, CCMB, 2006. 9
  2. Common Methodology for Information Technology Security Evaluation, Version 3.1, CCMB, 2006. 9
  3. 국가기관용 개방형 스마트카드 플랫폼 보호프로 파일 Vl.1, 국가정보원 IT보안인증사무국, 한국 정보보호진흥원, 2006. 5
  4. Supporting Docrunent Mandatory Technical Document, Application of Attack Potential to Smartcards, Version 2.1, CCDB, 2006. 4
  5. Supporting Docrunent Mandatory Technical Document, The Application of CC to Integrated Circuits, Version 2.0, CCDB, 2006. 4
  6. KISA, KCAC.TS.HSM v1.2, 보안토큰 기반의 공인인증서 이용 기술규격, 2007
  7. Common Criteria Protection Profile, USBDatentrager, BSI-PP-0025, 2006. 3
  8. Protection Profile Authentication Device, DAUTHPP (PKI based), 2006. 1
  9. Department of Defense Public Key Infrastructure and Key Management Infrastructure Token Protection Profile(Medium Robustness), V3.0, 2002. 3
  10. iKey 2032 Security Target, RainbowA사, 2004. 5