- 1 -

정보통신산업기술개발사업' '

최종결과보고서

기반의 시스템 개발PKI Single Sign-On

A Development cf PKI based Single Sign-On system

2001.10.31.

주관연구기관: 주 인터넷시큐리티( )

정 보 통 신 부

- 2 -

제 출 문

정보통신부장관 귀하

본 보고서를 정보통신산업기술개발사업 기반의 시스템 개발 과제의' ' PKI Single Sign-On

최종결과보고서로 제출합니다. .

년 월 일2001 10 31

주관연구기관 : 주 인터넷시큐리티( )

연구 책임자 : 제길명 기술연구소장( )

참여연구원 : 정상규 수석연구원( )

유일선 주임연구원 외 명( ) 9

- 3 -

요 약 문

제목1.

기반의 시스템 개발"PKI Single Sign-On "

기술개발의 목적 및 중요성2.

인터넷 사용자의 기하급수적인 증가와 이용확산으로 인하여 전자문서에 기반을 둔 온라인

전자거래가 증가하게 되었다 그 결과 전자문서의 무결성 부인방지 거래자의 신원확인 전. , , ,

송내용의 기밀성 접근통제에 대한 보안문제점이 발생하였으며 이에 대한 해결책으로 공개,

키 기반구조 가 제시되었다 또한 웹 기반의 다양한 응용(PKI: Public-Key Infrastructure) .

서비스가 등장하여 사용자가 접속하게 될 사이트가 증가하였고 인터넷 뱅킹과 같이 강력한,

보안을 요구하는 대부분의 사이트들은 확실한 인증을 위해 한 세션에 여러 인증을 요구하여

사용자의 불편이 심화되었다.

이처럼 공개키 기반 기술과 웹 기반의 다양한 응용 서비스는 기존 시SSO(Single Sign-On)

스템에 대한 새로운 방향전환을 제시하였다.

즉 기존 시스템이 갖는 단일 인증의 편이성과 통합적이고 효율적인사용자 관리 기능을SSO

지원하는 동시에 공개키 기반구조를 통해 강력한 보안기능을 제공하고 또한 다양한 웹 응용

서비스에 쉽게 적용 가능한 시스템 개발이 요구되었다SSO .

본 연구과제에서는 이러한 요구사항을 만족시키는 기반의 시스템인PKI Single Sign-On

를 제안한다 제안된 시스템은 기반 구조의 강력한 보안기능 및 다양한 웹SecureSSO . PKl

응용 서비스에 대한 유연성있는 구조와 더불어 에서 제시된 표준구조를 통한X.509 v2 PMI

통합된 접근통제를 지원한다.

- 4 -

연구개발의 내용 및 범위3.

본 연구과제에서는 기반의 시스템 개발을 위하여 관련 연구와 기존의PKI Single Sign-On

시스템을 분석하였으며 그 결과를 토대로 시스템 설계 목표를 제안하였다SS0 .

제안된 설계 목표를 동해 통합된 접근통제 시스템을 지원하는 의X.509 v2 PMI(Privilege

기반 구조와 다양한 웹 환경에 쉽게 적용할 수 있도록 웹 기Management Infrastructure)

반의 유연성 있는 구조를 갖는 시스템을 설계하였으며 또한 인증서 기반의 신SecureSSO ,

뢰성 있는 프로토콜을 제시하였고 통합된 사용자 계정관리 및 권한 인증서 발급을 위SSO

한 를 설계하였다SecureDB .

시스템은 암호화 통신 라이브러리 와 인증서 기반의 사용자 인SecureSSO SecureSSLLib

증 라이브러리 인증 서버 클라이언트SecureCertLib, SecureSSO , SecureSSO ,

응용 서버 사용자 관리 시스템으로 구성되며 개발되었다SecureSSO , SecureSSO .

연구개발 결과4.

가 관련 기술 및 기존 연구 비교분석.

나 기반의 시스템 설계목표 제안. PKI Single Sign-On

다 분석. PMI

라 시스템 설계. SecureSSO

시스템 구성요소 정의(1)

- 5 -

기반 구조(2) PMI

다양한 웹 응용 시스템에 쉽게 적용할 수 있는 유연성 있는 구조(3)

의 인증 프로토콜 설계(4) SecurcSSO

설계(5) SccureDB

라 시스템 구현. SccureSSO

(1) SecureSSLLib

(2) SecureCertLib

인증 서버(3) SecureSSO

클라이언트(4) SecureSSO

응용 서버(5) SecureSSO

사용자 관리 시스템(6) SecureSSO

활용에 대한 건의5.

본 연구과제에서 개발된 는 국내 공인인증기관과의 연계를 통해 국내 공인인증SecureSSO

기관 기반으로 환경이 구축된 환경에서 쉽게 솔루션으로 적용될 수 있으며PKI SSO PMI

기반의 통합된 접근통제 지원을 통해 체계적인 접근 통제 관리 및 보안정책 수립을 유도하

여 실제 구축사이트의 보안 수준을 향상시킬 수 있다.

아울러 본 연구과제에서 제시한 시스템 설계목표는 기반의 시스템의 설계의SSO PKl SSO

기준으로 활용될 수 있으며 의 반 구조나 웹 환경에 유연성 있는 구조는SecureSSO PMI

시스템의 핵심기술로 활용될 수 있다SS0 .

- 6 -

기대 효과6.

본 연구과제의 결과는 사용자 인증의 편이성 및 통합된 계정관리 기반의 접근통제 기, PMI

능을 제공함으로써 공공기관 기업 학교 등 국내 정보동신환경의 체계적인 접근 권한 및, ,

보안정책 수립에 기여하고 그 결과 국내 정보통신망의 보안수준 향상을 유도할 것이며 동.

시에 사용자 지원 데스크로 집중되던 패스워드 관련 업무의 비용 절감과 사용자 관리 업무

의 비용 절감을 통해 생산성 향상을 기대할 수 있다.

또한 기반의 기술 확보를 통해 고가의 외국제품에 대한 가격 경쟁력, PKI Single Sign-On

을 확보함으로써 시작 단계에 있는 국내 시장 활성화에 기여할 것으로 기대된다SS0 .

- 7 -

SUMMARY

The popularity of PKI(Public Key Infrastructure) technique and various Web-based

applications have been the new challenge to current Single Sign-On systems.

This R&D project develops the PKI based Single Sign-On system that provides the

powerful security service by being integrated in the PKI besides the convenient

single log-on and the unified management of user accounts.

Specially the developed system has the flexible architecture that is easily adapted

to various web-based environments, and provides the unified access control in a

large heterogeneous distributed environment by the PMI based architecture

proposed in X.509.

- 8 -

CONTENTS

Chapter 1 Introduction

Chapter 2 Related Work

Section 1 User authentication method

1. Password method

2. Trust Channel method

3. One-Time Password method

4. PKI based method

5. Smart Card method

6. Biometrics method

7. hybrid method

Section 2 PKI(Public Key Infrastructure) based technology

1. Public Key Infrastructure

2. Nationally accredited certification authority

Chapter 3 SSO(Single Sign-On) technique analysis and design goal

Section 1 SSO(Single Sign- On) technique

1. General SSO system architecture

2. SSO System Implementation consideration and check points

Section 2 Conventional SSO technique

1. PKI-based Kerberos

2. SESAME

3. RSA Keonⓡ

4. Netscape SuiteSpot

5. Evaluation and analysis

6. Market Trend

Section 3 Design Goal

- 9 -

I. Strong initial authentication

2. Integrated access control system

3. Flexible architecture for various web applications

4. PKI-based system

5. Centralized User manager

6. open standard and specification support

Chapter 4 PMI(Privilege Management Infrastructure)

Section 1 Consideration for authorization in distributed environment

1. Administrative Domains

2. Acquirement of user privilege

3. Genric Privilege System

4. Trust System

Section 2 Access Control

I. Conventional access control

2. RBAC(Role based access control)

Section 3 PMI Overview

1. Definition

2. Component

3. AC (Attribute Certificate)

4. AC revocation and delegation

Chapter 5 SecureSSO Basic design

Section 1 SecureSSO architecture and component

1. SecureSSO Architecture

2. Service access procedure

3. Single Sign-On

Section 2 Authentication protocol

1. AC_REQ

2. AC_REP

3. AP_REQ

- 10 -

4. AP_REP

Section 3 SecureDB design

1. Database table design

2. E-R(Entity Relation) Diagram

Chapter 6 System design and implementation

Section 1 SecureSSLLib

1. OpenSSL analysis

2. SSL(Secure Socket Layer) analysis

3. TLS(Transport Layer Security) analysis

4. Korea cipher algorithm analysis

5. SecureSSLLib design and implementation

Section 2 SecureCertLib

1. Function

2. Development environment

3. class design and implementation

4. Scenario

Section 3 SecureSSO Authentication Server

1. Function

2. Development environment

3. Architecture

4. Scenario

Section 4 SecureSSO Client

1. Function

2. Development environment

3. Architecture

4. Scenario

Section 5 SecureSSO Application Server

1. Function

2. Development environment

3. Architecture

4. Scenario

- 11 -

Section 6 SecureSSO User management system

1. Function

2. Development environment

3. Architecture

Chapter 7 Conclusion and future works

Section 1 Summary and evaluation

Section 2 Future works

References

- 12 -

목 차

제 장 서론1

제 장 관련 연구2

제 절 사용자 인증 기법1

패스워드 기법1. (Password)

신뢰채널 기법2. (Trust Channel)

일회용 패스워드 기법3. (One-Time Password)

공개키 사용 기법 인 종 서 사용4. ( )

스마트 카드 기법5. (Smart Card)

생체인증6.

인증 기법의 혼합사용7.

제 절 공개키 기반 기술2

공개키 기반 구조1. (PKL: Public Key Infrastructure)

국내 공인인증기관2.

제 장 기술 분석 및 설계목표3 SSO(Single Sign-On)

제 절 기술1 SSO(Single Sign-On)

일반적인 시스템 구조1. SSO

시스템 구현시 고려사항 및 체크포인트2. SSO

제 절 기존의 기술2 SSO

기반의 키버러스]. PKI

2. SESAME

3. RSA Keonⓡ

4. Netscape SuiteSpot,

비교분석5.

국내외 업계동향6.

제 절 설계목표3

강력한 초기인증1.

통합된 접근통제 시스템2.

- 13 -

다양한 응용 시스템에 쉽게 적용할 수 있는 유연성 있는 구조3.

시반의 시스템4. PKI

통합된 사용자관리 지원5.

개방된 표준과 기술규격지원6.

제 장4 PMI(Privilege Management Infrastructure)

제 절 분산환경에서 권한에 관련된 고려사항1

관리 도메인1. (Administrative Domains)

사용자의 권한 획득2.

일반 권한 시스템3. (Genric Privilege System)

신뢰시스템4. (Trust System)

제 절 접근 통제2 (Access Control)

전통적인 접근 통제1.

역할기반의 접근통제2. (RBAC: Role based access control)

제 절3 PMI Overview

정의1.

구성요소2.

3. AC (Attribute Certificate)

의 취소 및 권한위임4. AC

제 장 기본설계5 SecureSSO

제 절 구조 및 구성요소1 SecureSSO

의 구조1. SecureSSO

서비스 접근절차2.

3. Single Sign-On

제 절 의 인증 프로토콜2 SecureSSO

1. AC_RFQ

2. AC_REP

3. AP_REQ

4. AP_REP

제 절 설계3 SecureDB

데이터베이스 테이블1·

- 14 -

2. E-R(Entity Relation)Diagram

제 장 시스템 상세 설계 및 구현6

제 절l SecureSSLLib

분석1. OpenSSL

분석2. SSL(Secure Socket Layer)

분석3. TLS(Transport Layer Security)

국내 표준 알고리즘 분석4.

설계 및 구현5. SecureSSLLib

제 절2 SecureCertLib

기능 구성1. SecurcCertLib

시스템 구현환경2.

클래스 설계 및 구현3.

동작 시나리오4.

제 절 인증 서버3 SecureSSO

인증 서버 기능 구성1. SecureSSO

시스템 구현환경2.

인증 서버 구조3.

동작 시나리오4.

제 절 클라이언트4 SecureSSO

클라이언트 기능 구성1. SecureSSO

시스템 구현환경2.

클라이언트 구조3. SecureSSO

동작 시나리오4.

제 절 응용 서버5 SecureSSO

응용 서버 기능 구성1. SecureSSO

시스템 구현환경2.

시스템 구조3.

동작 시나리오4.

제 절 사용자 관리 시스템6 SecureSSO

사용자 관리 시스템 기능 구성1. SccureSSO

시스템 구현환경2.

- 15 -

시스템 구조3.

제 장 결론 및 향후 연구과제7

제 절 연구 개발 요약 및 시스템 분석1

제 절 향후 연구 과제2

참고문헌

- 16 -

그 림 목 차

그림 시스템의 새로운 요구사항( 1-1) SSO

그림 기법( 2-1) S/KEY One-Time Password

그림 질의 응답 기법( 2-2) / (Challenge/Response)

그림 시간 동기화 기법( 2-3)

그림 형식( 2-4) X.509v2 CRL

그림 계층적 구성( 2-5)

그림 네트워크 구성( 2-6)

그림 국내의 공인인증기관 및 인증서비스( 2-7)

그림 시스템의 구성요소( 3-1) SSO

그림 브로커 기반 모델( 3-2)

그림 의 에이전트 기반 모델( 3-3) Client-Side

그림 에이전트기반 모델( 3-4) Server-Side

그림 에이전트 브로커 기반 모델( 3-5) Server-Side -

그림 에이전트 브로커 기반 모델( 3-6) Client-Side -

그림 게이트웨이 기반 모델( 3-7)

그림 오프라인 토큰기반 모델( 3-8)

그림 프로토콜( 3-9) PKDA

그림 을 이용한 초기인증( 3-10) PKINIT

그림 에서 사용자 인증과정( 3-11) PKINIT

그림 독립된 프로세스형태의( 3 l2) LTGS

그림 서버에 내장된( 3-13) LTGS

그림 의 인증과정( 3-14) PKCROSS cross-realm

그림 구조( 3-15) SESAME

그림 권한 검증 시스템( 3-16) SESAME

그림( 3-17) Delegation in SESAME

그림 의 구조( 3-18) RSA Keon

그림 동작모델( 3-19) RSA Keon

그림 인증방식의 교체( 3-20)

- 17 -

그림( 3-21) Basic Authentication

그림 인증서를 이용한 사용자 인증절차( 3-22)

그림( 3-23) Strong authentication

그림 다중 도메인인 접근( 4-1)

그럼 다중 도메인 신뢰 시스템( 4-2)

그림 구조( 4-3) PMI

그림 프로파일의 구조( 4-4) AC

그림 사용자 인증 및 접근제어( 5-1)

그림 응용 서버 지원( 5-2) Non Single Sign-On

그림 의 구조( 5-3) Secure SSO

그림 클라이언트 로그온( 5-4)

그림 서비스 접근 과정( 5-5)

그림 적용범위( 5-6) Single Sign-On

그림 의 지원방법( 5-7) SecureSSO Single Sign-On

그림 프록시를 이 용한 클라이언트 지원( 5-8)

그림 로그인 자동화를 이용한 클라이언트 지원( 5-9)

그림 의 구성요소간 인증 프로토콜( 5-10) SecureSSO

그림 와 에서의 인증절차( 5-11) AC_REQ AC_REP

그림 와 에서의 인증절차( 5-12) AP_REQ AP_REP

그림 객체 구성도( 5-13)

그림 객체 관계 다이어그램( 5-14)

그림 구조( 6-1) SSL/TLS

그림 핸드쉐이크 프로토콜( 6-2) SSL

그림 레코드 프로토골( 6-3) SSL

그림 전체 구조도( 6-4) SEED

그림 구조도( 6-5) HAS-160

그림 국내 암호 알고리즘을 적용한 설계( 6-6) OpenSSL

그림 국내 암호 알고리즘을 적용한 의 구성도( 6-7) OpenSSL

그림 의 암호 알고리즘 정의( 6-8) EVP

그림 의 해쉬 알고리즘 정의( 6-9) EVP

그림 실행 화면( 6-10) openssl.exc

그림 기존 초기화면( 6-11) OpenSSL

- 18 -

그림 와 이 추가된 초기화면( 6-12) SEED HAS160

그림 파일을 으로 해쉬 한 화면( [3-13) test.txt has160

그림 모드로 파일을 암호하기 위한 초기화면( 6-14) seed ecb 111.txt

그림 모드로 를 암호시 결과 화면( 6-15) seed ecb 111.txt

그림 모드로 파일 암호해서 결과 파일 생성( 6-16) seed ecb 333.txt 333.ofben

그림 암호화된 파일을 복호한 로 결과 파일 생성( 6-17) 333.ofben 333.ofben

그림 테스트 프로그램 인터페이스( 6-18)

그릭 테스트를 위한 테스트 원본 파일을 한 화면( 6-19) open

그림 암호화한 파일을 한 화면( 6-20) open

그림 복호화된 파일을 한 화면( 6-21) open

그림 복호화 성공화면( 6-22)

그림 에서 을 옵 으로 다이제스트 한 화면( 6-23) OpenSSL has160 hex tus

그림 독립적으로 실행되는 알고리즘으로 다이제스트 한 화면( 6-24) has160

그림 주요기능( 6-25) SecureCertLib

그림 클래스 관계 다이어그램( 6-26)

그림 클래스 세부 속성 다이어그램( 6-27)

그림 클라이언트 동작 시나리오( 6-28) SecureSSO ·

그림 인증서버 동작 시나리오( 6-29) SecureSSO

그림 응용 서버 동작 시나리오( 6-30) SecureSSO

그림 인증 서버 주요기능( 6-31) SecureSSO

그림 인증 서버 구조( 6-32) SccureSSO

그림 인증 서버 실행흐름( 6-33) SecureSSO Main Part

그림 초기 인증 동작시나리오( 6-34) SecureSSO Sub Part

그럼 서비스 요청 처리 동작 시나리오( 6-35) SecureSSO Sub Part

그림 클라이언트 주요기능( 6-36) SecureSSO

그림 클라이언트 구조( 6-37) SecureSSO

그림 클라이언트 초기 인증( 6-38) SecureSSO

- 19 -

그림 초기 인증 화면( 6-39)

그림 사용자 맞춤형 페이지 화면( 6-40)

그럼 클라이언트 서비스 요청 처리( 6-41) SecureSSO

그림 서비스 접속 화면 예( 6-42) 1

그림 서비스 접속 화면 예( 6-43) 2

그림 응용 서버 주요기능( 6-44) SecureSSO

그림 응용 서버 구조( 6-45) SecureSSO

그림 응용 서버의 사용자 인증 및 권한 검증( 6-46) SecureSSO

그림 사용자 관리 시스템 주요기능( 6-47) SecureSSO

그림 사용자 관리 시스템 구조( 6-48) SeucreSSO

그림 사용자 정 보 관리 데 이 터 흐름도( 6-49)

그림 초기 실행 화면( 6-50)

그림 사용자 정보 관리 화면( 6-51)

그림 서비스별 인증정보 조회( 6-52)

그림 그룹 정보 관리 데이터 흐름도( 6-53)

그림 그룹 정보 관리 화면( 6-54)

그림 역할 정보 관리 데이터 흐름도( 6-55)

그림 역할 정보 관리 화면( 6-56)

그림 기타 정보 관리( 6-57)

그림 접속 사용자 조회 데이터 흐름도( 6-58)

그림 접속 사용자 조회 화면( 6-59)

- 20 -

표 목 차

표 인증 기법 분류[ 2-1]

표 의 다양한 응용분야[ 2-2] PKI

표 의 형식[ 2-3] X.509v3

표 계층적구성과 네트워크구성의 장 단점[ 2-4] ·

표 시설 및 장비 세부지정기준[ 2-5]

표 인증 서비스의 종류[ 2-6]

표 국내외의 인증 서비스 제공 업체 현황[ 2-7]

표 공인인증기관의 인증업무 추진현황[ 2-8]

표 국내 공인인증기관의 인종수수료[ 2-9]

표 한국증권전산 주 의 인증서비스 종류 및 용도[ 2-10] ( )

표 한국정보인증 주 에서 제공하는 인증서의 종류와 용도[ 2-11] ( )

표 금융결재원에서 제공하는 인증서의 종류[ 2-12]

표 무선 인터넷 관련기술[ 2-13]

표 국내 무선 인터넷 서비스업체 현황[ 2-14]

표 시스템 구조에 따른 시스템 분류[ 3-1] SSO

표[ 3-2] trusted intermediary

표 인증 프로토콜 기호[ 3-3] PKDA

표 인증 프로토클 기호[ 3-4] PKINIT

표 의 구조[ 3-5] PAC

표 의[ 3-6] PAC Common Contents·

표 의[ 3-7] PAC protection method

표 잘 알려진[ 3-8] attribute

표 의[ 3-9] PAC Signature

표 시스템 비교[ 3-10] SSO

표 모델과 모델의 장점[ 4-1] Push Pull ·

표 오프라인 모델과 온라인 모델의 단점[ 4-2]

표[ 4-3] Lampson access mathx

표[ 4-4] Role Based Access Control Matrices

- 21 -

표 와 와의 비교[ 4-5] PKC AC

표 의 요구사항[ 4-6] AC

표 프로파일의 항목[ 4-7] AC

표 프로파일의 확장필드[ 4-8] AC

표 프로파일의[ 4-9] AC Attribute Type

표 의[ 4-10] AC Revocation Scheme

표 기반의 구조 특성[ 5-1] PMI SecureSSO

표 개인키의 두가지 저장방법[ 5-2]

표 의 세 가지 적용범위[ 5-3] Single Sign-On

표 인증 프로토골의 기호[ 5-4]

표 테이블[ 5-5] ISUserInfo

표 테이블[ 5-6] ISFootphnt

표 테이블[ 5-7] ISGruopInfo

표 테이블[ 5-8] ISOrganization

표 테이블[ 5-9] ISDepartment

표 테이블[ 5-10] ISTitle

표 테이블[ 5-11] ISAthenInfo

표 테이블[ 5-12] ISAthenInfo

표 테이블[ 5-13] ISRoleInfo

표 테이블[ 5-14] ISRoleSerRel

표 테이블[ 5-15] ISAtthbute

표 테이블[ 5-16] ISAttribute

표 에서 이용되는 암호 알고리즘[ 6-1] SSL

표 과 의 비교 분석[ 6-2] SSL TLS

표 구현환경[ 6-3]

표 구현 과정[ 6-4]

표 구성 요소 기능[ 6-5] OpenSSL

표 설계목표와 시스템 구조[ 6-6] SecureSSO

표 시스템과 기곤연구의 비교[ 6-7] SecureSSO

- 22 -

제 장 서 론1

컴퓨터와 정보통신 기술의 발달이 혁명이라고 불릴 만큼 우리의 환경을 발전시켜왔다 사용.

자들은 분산 네트워크 환경에서 서로 상이한 플랫폼 기반의 여러 시스템 서비스를 제공받기

위하여 시스템마다 기본적으로 아이디와 패스워드를 통한 식별과정 인증과(Identification),

정 그리고 권한부여 과정을 거치게 된다 이처럼 분산환경(Authentication) (Authorization) .

에서 보안을 요구하는 다양한 응용 시스템에 의해 사용자는 각 시스템별로 서로 다른 사용

자 아이디와 패스워드를 기억하고 관리해야 하며 보안정책에 따라 패스워드의 최소길이와

형식을 제한 받고 자주 변경해야 하는 부담을 갖게 되었으며 시스템 관리자는 응용 시스템

별로 사용자들의 아이디와 패스워드를 일관성 있게 관리해야 하는 어려움을 겪게 되었다.

결국 사용자는 여러 패스워드를 관리하기 위해 시스템 별로 자신의 아이디와 패스워드를 종

이에 적어서 모니터에 붙여 놓거나 유추하기 쉬운 패스워드를 사용하거나 혹은 모든 시스템

에 동일한 아이디와 패스워드를 사용하는 등 보안상 허점을 초래하게 되었으며 시스템 관리

자는 서비스 질 향상보디 사용자 정보 관리를 위해 더 많은 노력을 기울이게 되었다- .

이와 같은 분산환경의 보안문제에 대한 해법으로 사용자에게는 단일 인증의 편이성과 시스

템 관리자에게는 통합적이고 효율적인 사용자 관리를 제공하기 위한 SSO(Single Sign-On)

기술이 연구되었다[8][10][11].

는 단 한번의 인증을 통해 다양한 시스템과 응용 프로그램의 정보에 접근하도록 하는SSO

기술로서 시스템 구조나 인증 방식에 따라 분류될 수 있다 시스템 구조에 따른 시스. SSO

템은 브로커 기반 모델 에이전트 기반 모민 에이전트 브로커 기반 모델(Broker) , (Agent) , - ,

게이트웨이 기반 모델로 분류된다 브로커 기반 모델은 중앙 집중적인 인증과 사(Gateway) .

용자 계정관리를 위한 하나의 서버가 존재하며 한번의 인증 후 브로커는 이후의 접속요청을

위해 토큰을 부여한다.

- 23 -

에이전트기반 모델은 서로 다른 응용 프로그램의 사용자를 자동적으로 인증하는 에이전트가

존재하는 모델이다 에이전트 브로커 기반 모델은 브로커 기반 모델의 장점인 중앙 집중식. -

계정관리와 에이전트 기반 모델의 장점인 유연성을 결합한 모델이다 게이트웨이 기반 모델.

은 게이트웨이나 프록시 형태의 강력한 암호화 인증 서버를 두어서 도메인으로 들(Proxy)

어오는 네트워크 흐름을 여과하면서 기능을 지원하는 구조이다SSO .

인증 방식에 따른 시스템 모델은 패스워드 동기화 모델 로그온 자동화 모델 토큰기SSO , ,

반 모델로 분류된다 패스워드 동기화 모델은 응용 시스템마다 다른 여러 개의 사용자 아이.

디와 패스워드를 하나로 통일시켜서 사용자가 단지 하나의 사용자 아이디와 패스워드를 기

억하도록 하는 기술이다 로그온 자동화 모델은 사용자의 로그온 정보를 별도의 저장소에.

저장한 후 인증시 사용자를 대신하여 자동으로 로그온을 하는 기술이다 토큰기반의 인증, .

모델은 인증을 위해 사용자의 패스워드 같은 로그온 정보대신에 응용 시스템을 위한 토큰을

통해 로그온 하도록 하는 모델이다 이 모델의 주된 특징은 사용자의 로그온 정보가 네트워.

크 상에서 전송되지 않는 다는 점과 응용시스템 서버를 화하거나 응용 시스템 서버에SSO

을 위한 를 두는 것이다SSO Agent .

한편 인터넷 사용자의 기하급수적인 증가와 이용확산으로 인하여 전자문서에 기반을 둔 온

라인 전자거래가 증가하게 되었으며 이로 인하여 발생하는 전자문서의 무결성 부인방지, ,

거래자의 신원화인 전송내용의 기밀성 접근통제에 대한 보안 문제를 해결하기 위해 공개, ,

키 기반구조 가 제시되었다(PKI: Public-Key Infrastructure) .

- 24 -

또한 웹 기반의 다양한 응용서비스가 등장함에 따라 기존의 환경과는 달리 접속하게 될 사,

이트가 증가하게 되었고 확실한 인증을 위해 한 세션에 여러 번에 걸친 인증을 요구하는,

사이트가 등장하게 되어 사용자의 불편이 심화되었다.

따라서 공개키 기반 구조와의 연계를 통해 강력한 보안기능을 제공하며 다양한 웹 응용 시

스템에 쉽게 적용 가능한 시스템 개발에 대한 필요성이 제시되었으며 이는 그림SS0 ( 1-1)

과 같이 기조 시스템에 대한 새로운 도전이 되었다SSO .

그림 시스템의 새로운 요구사항( 1-1) SS0

본 연구과제에서는 기존 시스템이 갖는 단일 인증의 편이성과 통합적인 사용자 관리의SSO

특성을 살리며 다양한 웹 응용 시스템 환경에 쉽게 적용 가능한 유연성 있는 구조를 갖고

공개키 연산을 적용하어 강력한 보안을 제공하는 기반의 시스템인PKI Single Sign-On

를 개발하고자 한다SecureSSO .

- 25 -

는 통합된 접근통제를 위해 기반구SecureSSO PMI(Privilege Management Infrastructure)

조를 지원한다 즉 중앙에 의 역할을 하는 권한서버를 두어서 형. Attribute Issuer X.509 v2

태의 인 를 발급하도록 하여 통합된 접근통Privilege Certificate AC(Attribute Certificate)

제를 제공한다 또한 는 형태의 인증. SecureSSO PKC(Public Key Certificate, X.509 v3

서 를 통한 사용자 인증 기밀성 무결성 사용자 부인방지 사용자 사칭 차단 등 기반) , , , , PKI

의 강력한 보안 서비스를 제공한다.

본 보고서의 구성은 다음과 같다.

장에서는 본 연구과제의 관련연구를 기술하고 장에서는 일반적인 기술을 분석하고2 3 SSO

기존 시스템 비교분석 및 기반의 시스템인 설계목표를 제시한다 장에서는SSO PKI SSO . 4

구조에 대해서 기술하며 장에서는 의 기본 설계를 기술하고 장에서는PMI 5 SecureSSO 6

의 상세설계 및 구현을 언급한 후 장에서는 결론 및 향후 연구를 제시한다SecureSSO ,8 .

- 26 -

제 장 관련 연구2

본 장에서는 기반의 기술의 기본이 되는 사용자 인증기법과 기반 기술에 관하PKI SSO PKI

여 기술한다.

제 절 사용자 인증 기법1

일반적으로 서비스를 제공하는 시스템에서 사용자를 인증하는 과정은 사용자 식별(User

사용자 인증 사용자 권한부여Identification), (User Authentication), (User Authorization)

의 세 과정을 거친다 사용자 식별 단계는 사용자고유의 식별자를 통해 시스템의 서비스를.

제공받는 사용자들 사이에서 유일성을 확인하는 단계이며 사용자 인종 단계는 사용자의 신,

원 확인 후 서비스를 제공받을 수 있는 정당한 사용자임을 증명하는 단계이며 마지막으로

사용자 권한부여 단계는 인증된 사용자가 접근할 수 있는 응용 서버의 자원에 대한 접근권

한을 결정하는 단계이다.

사용자 인증 기법은 사용자 인증 과정에서 사용자의 신원을 증명할 수 있는 매체(witness)

에 따라 분류 될 수 있으며 또한 사용자 인증 과정의 보안강도에 차이를 두고 분류될 수,

있다.

사용자 신원을 증명할 수 있는 매체를 분류하는 방법은 사용자가 알고 있는 정보

에 의한 인증 사용자가 기니고 있는 정보(something known by the user) , (something

에 의한 인증 사용자가 지니고 있는 정보 에 의한 인증으possessed) , (something embodied)

로 구분할 수 있다.

사용자 인중 과정에서 보안 강도에 의한 인증 기법 분류는 약한 인종(weak authentication)

기법과 강한 인증 기법 두 가지로 구분된다 또한 위의 분류 기준과(strong authentication) .

상관없이 인증 기법들간에 필요로 하는 환경과 보안 강도에 따라 혼합되어 사용 될 수 있

다.

- 27 -

표 은 앞서 구분한 증명 매체와 보안강도를 기준으로한 분류방법에 따라 다양한 인증[ 2-1]

기법들을 지니고 있는 특성을 정리한 것이다.

표 인증 기법 분류[ 2-1]

증명매체

보안강도사용자가 아는 정보 사용자가 소유한 정보 사용자가 지닌 정보

약한 인증 Static Password 없음 없음

강한 인증일회용 패스워드

(One-Time Password)

공개키 (Public-key),

H/W Token,

Smart Token

생체정보(Biometric)

패스워드 기법1. (Password)

패스워드 기법은 대부분의 시스템에서 가장 기본적인 사용자 인증 기법으로서 사용자가 이

미 알고 있는 패스워드를 응용 시스템 서버에게 전송하여 시스템이 가지고 있는 패스워드와

비교하여 정당한 사용자임을 확인하는 인증 기법이다 일반적으로 사용되던 기존의 패스워.

드 기법은 패스워드를 암호화되지 않은 평문 상태로 네트워크 통신 경로에 전송하고 반복적

으로 사용하기 때문에 보안에 있어서 많은 취약점을 갖고 있다 따라서 이러한 문제점을 개.

선하기 위해 최근에는 등과 같은 암호화 기법과 일회용 패스워SSL(Secure Socket Layer)

드 기법 등을 적용하여 모든 시스템에 기본적으로 사용되는 패(OTP, One Time Password)

스워드 인증 기법의 보안성을 강화하고 있다.

신뢰채널 기법2. (Trust Channel)

신뢰채널 기법은 인증 기법의 분류 증에서 패스워드 기법과 같은 분류에 속한다 신뢰채널.

은 보통 유닉스 계통 시스템의 등의 명령에서 사용되던 인증 기법으로서 사용rlogin, rsh

자는 서비스 접속 이진에 서비스를 제공받을 시스템과의 신뢰 관계를 구축한 후 실제 서비,

스 접속 시에 미리 가지고 있는 신뢰정보를 통해 부가적인 사용자 인증없이 서비스를 제공

받을 수 있다.

- 28 -

하지만 서비스 접속 시 전달되는 사용자 신뢰정보의 안전한 전송이 보장되지 않으므로 신뢰

정보가 유출 될 수 있다는 문제가 있다 현재 신뢰채널을 사용하는 와 같은 명령. rlogin, rsh

어는 시스템 취약점의 한 부분으로 많이 알려졌기 때문에 그 사용 빈도가 적다 따라서 신.

뢰채널 기법도 사용자와 서비스 시스템간에 신뢰관계가 확실히 맺어져 있는 환경외에는 사

용하지 않는다.

일회용 패스워드 기법3. (One-Time Password)

일회용 패스워드 기법은 기존의 패스워드 기법이 동일한 패스워드를(One-Time Password)

여러 번 반복하여 사용함으로써 발생할 수 있는 보안 문제점을 해결하기 위해 제안되었으며

크게 기법 질의 응답 기법 시간동기화 기법으로 분류된다S/Key , / , .

가 기 법. S/Key

기법은 수동공격에 대해 사용자의 패스워드를 보호하기 위한 구조로서 네트워크상S/KEY

의 도청이나 재전송 공격으로부터 안전한 인증을 제공한다 이 기법은 거의 모든 시. UNIX

스템에 추가적인 하드웨어 없이 패스워드정보를 저장하지 않고 쉽고 빠르게 설치할 수 있,

으며 통신 기능을 가진 에도 사용이 가능하다PC .

기법은 그림 과 같은 절차에 의해서 사용자 인증을 한다S/KEY ( 2-1) .

시스템 초기에는 사용자의 패스워드와 값으로 구성된 를 단방향 해쉬함수 에 의Seed S f()

해 Ninit번 계산한 일회용 패스워드가 클라이언트의 초기설정 을 통해 호스트(Initial Setup)

컴퓨터에 저장된다.

- 29 -

사용자가 호스트 컴퓨터에 인증을 할 경우 사용자는 사용자의 아이디를 호스트 컴퓨터에,

제시한다 호스트 컴퓨터는 사용자의 아이디를 통해 사용자에 해당하는 순서 값 이때 호. N (

스트에는 번 연산된 일회용 패스워드가 저장되어 있음 과 값을 클라이언트에게 전N+1 ) Seed

송한다 클라이언트는 호스트가 전송한 값과 사용자 비밀번호를 결합하여 를 구한. Seed S

후 에 단방향 해쉬함수 를 번 적용하여 일회용 패스워드를 생성한다 생성된 패스워, S f() N .

드는 호스트에 전송된다 호스트는 클라이언트로부터 전송받은 일회용 패스워드에 단방향.

해쉬함수 를 회 적용한 후 그 결과 값과 저장된 일회용 패스워드 번 연산된 일회f() 1 , (N+1

용 패스워드 와 비교하여 인증을 한다 인증이 성공적이라면 클라이언트가 전송한 일회용) .

패스워드를 다음 단계에 적용하기위하여 저장한다.

그림 기법( 2-1) S/KEY One-Time Password

- 30 -

나 질의 응답 기법. / (Challenge/Response)

이 기법은 사용자가 인증 요구와 함께 사용자 식별 번호 를 인증 서버에게 전달하면(PIN) ,

인증 서버는 난수를 생성하여 질의 값으로 사용자에게 전달한다 이와 동시에 인증 서버는.

이용자의 사용자 식별 번호에 해당하는 패스워드를 키 데이터베이스에서 꺼내 이것을 이용

하여 난수의 암호화를 시작한다.

질의 값을 받은 사용자는 그것을 자신의 패스워드로 암호화하여 응답 값으로 인증 서버에게

반환하다 사용자로부터 응답 값을 받은 인증 서버는 서버자신이 계산한 값과 수신된 값을.

비교하여 일치하는 경우에 사용자를 정당한 사용자로 인증하게 된다.

질의 응답 기법은 여러 번의 절차로 인해 다소 느리다는 단점이 있기는 하지만 시간 동기/ ,

화 기법에 비해 복잡성이 덜하고 안전성이 높기 때문에 최근이 방법을 적용한 인증 시스템

이 국외에서 많이 개발되고 있는 실정이다.

그림 는 질의 응답 기법의 절차를 나타낸다( 2-2) / .

그림 질의 응답 기법( 2-2) / (Challenge/Response)

- 31 -

다 시간 동기화 기법.

시간 동기화 기법 기법은 매분마다 이 시간 간격은 네트워크 관리자에 위해 정해진다 하( .)

나씩의 난수를 생성하기 위해 난수 생성 알고리즘과 비트 크기의 비밀키가 필요하다 각64 .

각의 사용자에게는 특정키가 할당되어져 있는데 이것은 지능형 토큰과 인증 서버의 데이터,

베이스에 저장되어 진다.

사용자가 응용 서비스를 제공받기 위해 응용 서버에 로그온을 시도하면 서버는 개의 숫자, 4

로 이루어진 과 개의숫자로 이루어진 난수를 요구하PIN(Personal Identification Number) 6

게 된다 개의 숫자로 이루어진 난수는 토큰으로부터 생성되어진다 토큰에서 생성되어지. 6 .

는 난수는 토큰 안에 저장되어있던 비밀키와 시간을 초기 값으로 하여 토큰 안의 알고리즘

을 통해 만들어진다 이렇게 만들어진 개의 숫자가 서버로 가게 되면 서버는 개의 숫자. 10 , 4

를 인덱스로 하여 서버의 데이터 베이스에서 해당 비밀키를 찾는다 이런 다음 서버(PIN) .

측에서도 알고리즘에 시간과 비밀키를 넣어 생성된 개의 랜덤 숫자들을 수신된 개의 랜6 6

덤 숫자와 일치하는지를 검사하여 그 두 개의숫자들이 서로 일치하게 되면 서비스에 대한,

이용 권한을 부여하게 되어 사용자 인증 절차가 끝나게 된다.

이러한 시간 동기화 기법은 다음과 같은 세 가지 문제점을 갖고 있다.

첫째 난수를 일치시키기 위해 시간에 대한 동기가 보장되어야 한다 예를 들어 서버는 캘, .

리포니아에 있고 토큰은 런던에 있을 경우 시간에 대한 동기는 보장 될 수가 없을 것이다, , .

시간 동기에 관한 문제는 약간의 부담은 있지만 의 표준시간을 양쪽 장치에 프, Greenwich

로그램 함으로써 해결되어 질수는 있다.

둘째 시간 편차 의 문제가 있다 토큰이라는 것이 일회용이 아니고 일반적, (Time Slippage) .

으로 수년간에 걸쳐 사용되어지는 장치이기 때문에 하루에 단 몇 초만이라도 늦어지거나,

빨라진다면 토큰과 서버간에 동기는 또한 보장될 수 없게 되는 것이다.

- 32 -

셋째 시간에 관련된 문제가 있다 토큰에서 생성된 난수가 여기서는 패스워드로 사용되어, .

지는데 이 패스워드에는 초간의 유효시간이 있게 된다 만약 해커가 네트워크 상의 패스, 60 .

워드를 초안에 도청을 시도하여 과 패스워드를 훔쳐 다른 서버에 접속을 시도한다면60 PIN

사용자 인증에 성공하게 되는 것이다.

그림 은 시간 동기화 기법에 의한 사용자 인증 과정을 나타내고 있다( 2-3) .

그림 시간 동기화 기법( 2-3)

- 33 -

공개키 사용 기법 인증서 사용4. ( )

공개키 사용 기법은 신뢰기관 에서 개인키와 인증시를 발급 받(CA: Certificate Authority)

은 사용자가 인증을 위해 자신의 인증서와 자신의 개인키로 전자서명된 값을 보냄으로써 정

당한 사용자임을 인증 받는 기법이다 공개키사용 방식에는 공개키 암호화를 이용한 질의. /

응답 방식과 전자서빙을 이용한질의 응답 방식이 있다/ .

스마트 카드 기법5. (Smart Card)

스마트 카드 기법은 사용자의 개인키와 인증서를 스마트 카드에 저장하여 공개키 기반의 환

경에서 인증서를 이용한 사용자 인증을 지원하는 기법으로 개인키와 인증서를 컴퓨터의 저

장장치가 아닌 스마트 카드의 메모리에 저장함으로써 개인키 유출의 위험성을 최소화하였고

사용자의 이동성을 지원하였다 스마트 카드에 저장되는 인증서는 보통 표준을 따르. X.509

며 인증서를 접근하기 위한 표준 인터페이스로는 의 과 의RSA Security PKCS#11 MS

등이 있다PC/SC .

생체인증6.

생체인증 기법은 사용자의 생리학적 혹은 행동상의 특징을 기반으로 사용자를 인증하는 기

법이다 생체인식 기법에서 사용자는 패스워드를 기억하거나 토큰을 가지고 다녀야 할 필요.

성이 없기 때문에 가장 보안성이 늪은 인중기법의 하나로 연구되고 있다 현재 지문 정맥. , ,

홍채 망막 음성 얼굴 모양 손 모앙 등 다양한 형태의 생체 인증 시스템이 개발되고 있으, , , ,

며 가장 대중적인 것은 얼굴과 지문을 이용한 시스템이다.

- 34 -

가 지문 인식.

현재 가장 잘 알려져 있는 생체 인식 형태로 주로 의 종접이나 가지들에서 발생하는, ridge

특징점 패턴에 의해 분류함 그러나 지문 인식 시스템이 완벽한 개인 식별수단이(minutiae) ,

될 수는 없는데 이는 땀이나 물기가 스캐너에 배어있는 경우 에러 발생률이 크게 높아진다,

는 점 여러 사람이 연속적으로 접촉한 곳에 자신의 손가락을 댄다는 불쾌감 지문이 닳아, ,

없어진 사람도 간혹 있다는 점 등이 지문 인식 시스템의 한계로 인식되고 있다.

나 망막 및 홍채 인식.

사람의 눈을 이용한 생체 인증에서 눈은 홍채와 망막의 혈관이 인증을 목적으로 사용되고

있으며 이중 망막 인식은 사용자의 안구 배면에 위치한 모세 혈관의 구성이 지문과 같이,

종생불변의 특성을 가지고 있다는 점을 이용하는 것으로 이러한 망막 패턴을 읽기 위해서,

는 눈을 검색기에 접안해야 하는 불편과 레이저 빛에 대한 두려움을 유발하는 등 일반인을,

대상으로 하여사용하기에는 비효율적인 면이 있음 이에 반해 홍채 인식은 자연스러운 상태.

에서 획득된 영상을 이용하므로 망막 인식에서와 같은 단점이 없어 차후 많은 분야로의 적

용이 기대된다.

다 얼굴 인식.

얼굴 인식은 입력 화상으로부터 얼굴 영역을 추출하는 것으로 시작되는데 얼굴의 열상을,

이용하는 방식과 차원 얼굴 영상을 이용하는 방식으로 구분할 수 있음 얼굴 인식 기법은3 · .

사용자의 기분과 상황에 따라 표정이 변하게 되는 특성을 고려해야 하며 수위 조명에 많은

영향을 받게 되는 등 해결해야할 문제가 많이 있다.

- 35 -

라 음성인식.

음성인식은 음성을 이용한 사용자 인식에서는 말 그 자체가 아니라 말을 할 때의 음성학적

특성들에 초점을 맞추는 것으로 이러한 음성학적 특성들은 억양에 의하여 영향을 받는 것,

이 아니라 신체 내의 말을 처리하는 절차에 의존함 화자 인식 시스템은 크게 두 가지 형태.

로 나눌 수 있는 데 접근 통제에 사용될 수 있는 독립적인 것과 전화망상에서의 사람을 인

증할 수 있는 시스템이 있음 이러한 화자 인식 시스템은 원격기에서도 전화를 이용하여 신.

분 확인을 할 수 있다는 점과 시스템 가격도 저렴하다는 장점이 있으나 잡음과 사용 환경,

상의 소음 등에 영향을 받는 단점이 있다.

마 다중 생체 인식 기술의 출현.

이상 언급한 생체 인식 분야 외에도 손 서명 귀 근전도 신호 손 팔의 동작 걸음걸이 타, , , ( / ), ,

이핑 리듬 입술 인식 등이 현재 개발되고 있으나 아직 상용화하기에는 많은 시간이 걸릴, ,

것으로 예상된다 또한 각각의 생체 인식기술은 나름대로의 장단점을 가지고 있기 때문에. , ,

하나의 생체 정보에만 의존하기보다는 여러 생체 정보의 조합과 통합을 통한 복합적인 생체

인식 기술 에 대한 관심이 높아지고 있다(Multi-Modal) .

인증 기법의 혼합 사용7.

인증 기법의 혼합 사용은 인증 서비스의 보안강도를 만족시키기 위하여 여러 인증 기법을

함께 사용하는 기법이다.

가 적용 예 생체 인식 보안 토큰 공개키 기반 구조의 결합. - , ,

생체 인식 시스템을 이용하여 어떤 사람이 요구하는 아이디를 인증하기 위해서는 그 사람.

이 생체 인식 시스템에 등록시 저장된 원본 데이터와 새로이 제시한 샘플을 비교하는데 이,

때 원본 데이터 샘플은 그들이 항상 가지고 다니는 보안 토큰이나 서버의 데이터베이스에.

보관될 수 있다.

- 36 -

그러나 생체 정보를 데이터베이스에 저장하는 경우에는 데이터베이스의 유지 및 관리에 어

려움이 많아 현재는 생체 정보를 보안 토큰에 저장하는 방법에 대한 많은 연구가 진행중이,

다 개인의 생체 정보로부터 추출된 특징을 보안 토큰에 저장하여 각 개인이 보유하게 함으.

로써 생체 정보 데이터베이스 관리의 어려움이 해소될 뿐만 아니라 특징 정합 절차가 보안,

토큰내의 생체 정보를 이용하여 수행됨으로써 비용 및 처리 시간을 줄일 수 있다 이처럼.

생체 인식 기술 보안 토큰 그리고 공개키 기반 구조는 각각이 지니는 장점이 있으나 독립, , ,

적으로 활용된다면 기술적인 약점을 극복하지 못한다 예를 들어 보안 토큰은 내부의 데이. ,

터를 외부와 차단할 수 있고 소지하기 쉬운 반면에 분실이나 도난의 우려가 있으며 생체,

인식 기술은 도용이 힘든 반면에 현실적으로 인식 오류율이 에 도달하지 못하므로 인한0 %

응용분야의 제한이 발생함 공개키 기반 구조는 공개키에 대한 인증 능력을 높였으나 비밀.

키의 보안성에 대한 문제를 해결하지 못하고 있다 그러나 각 요소 기술들의 한계를 세 요. ,

소기술들의 융합을 통하여 극복할 수 있다 즉 공개키 기반 구조가 제공하지 못하는 비밀. ,

키의 보안과 사용의 용이성을 동시에 높이기 위하여 내부 보안능력 처리능력 및 기억 능력,

을 가지고 있는 보안 토큰 기술을 도입하고 보안 토큰의 모난 및 타인에 의한 남용을 방지,

하기 위하여 생체 인식기술을 보안 토큰에 도입함으로써 보안 토큰은 본인이 아닌 타인에

의한 사용이 거부되도록 설계할 수 있다.

- 37 -

제 절 공개키 기반 기술2

통신과 컴퓨터 기술이 비약적으로 발전하면서 현재 우리가 일상적으로 행하던 은행업무 쇼,

핑 등의 거래를 전자적으로 행하는 전자거래가 이미 일부에서 시행되고 있고 이러한 추세,

는 전자 공간에서 전자적 방식에 따라 이루어지는 상거래인 전자상거래의 자연스러운 출현

이라고 생각된다 특히 인터넷의 급속한 확산에 의한 인터넷상의 전자상거래가 활발히 전개.

되고 있는 실정이다.

특히 미 행정부는 인터넷을 세기 미국 무역의 주요 통로로 삼는 등 인터넷을 통한 전자21

상거래를 활성화하기 위해 전자상거래 육성을 위한 방안을 모색중에 있으며 우리나라도 이

에 발맞추어 현재 정보통신부 재정경제원 통상산업부 등 정부 부처는 물론 민간부문에서, ,

도 전자상거래의 실현을 추진하고 있다 미국의 시장조사업체인 주피터 커뮤니케이션스가.

조사한 바에 따르면 전자상거래 시장은 지난해 억달러에서 오는 년에는 억달러로10 2000 70

성장할 것이라 한다 그러므로 전자상거래는 국가경쟁력 강화의 중요한 요소로 고려되어야.

한다.

국가경쟁력 강화의 일환으로 전자상거래를 활성화하기 위해서는 먼저 전자상거래의 안전성·

신뢰성을 확보해야 한다 현재 국내에서는 전자상거래의 정보보호 문제로 인하여 전자상거.

래를 활성화하는 데 많은 한계점을 노출하고 있으며 이를 해결하기 위하여 관련 부처에서

현행 법 제도 정비 필요성을 인식하여 많은 논의가 이루어지고 있는 실정이다/ .

전자상거래의 안전성 신뢰성을 확보하는 시작은 전자인증제도의 정립이라고 말할 수 있다.ㆍ

전자인증제도란 가상공간상의 전자문서 전자거래 등 관련 전자업무에서의 당사자의 신분확,

인 기능 전자업무 내용의 정보보호 및 무결성 기능 전자행위에 대한 부인봉쇄 기능 등 전, ,

자업무의 중요 인증과 관련하어 신뢰할만한 제 자 인증기관 가 확인 및 증명해 주는 제도이3 ( )

다 전자인종제도의 핵심은 전자상거래의 안전성과 신뢰성을 확보하기 위한 핵심기술인 전.

자서명기술의 안전한 운영을 의미한다.

- 38 -

전자서명기술은 공개키 암호알고리즘으로 비밀키와 공개키가 사용된다 공개키 암호알고리.

즘에서 사용되는 비밀키가 전자서명을 생성하는 생성키가 되고 공개키가 전자서명을 검증하

는 검증키 역할을 한다 그러므로 전자서명 기술의 안전한 운영은 서명키 공개키 암호알고. (

리즘의 비밀키 와 검증키 공개키 암호알고리즘의 공개키 의 안전한 운영에 달려있으며 서명) ( )

키의 안전한 운영은 비밀키의 안전한 보관을 말하며 검증키의 안전한 운영은 공개키의 안전

한 관리를 의미한다 공개키는 공개된 정보이므로 어떻게 공개키 위 변조문제를 해결하는가. ·

하는 공개키 인증문제로 귀착된다.

이러한 공개키의 인증문제를 해결하기 위해 나온 것이 바로 공개키 기반구조(PKI: Public

이다Key Infrastructure) .

다시 말해 전자상거래의 안전성과 신뢰성을 확보하기 위해서는 전자인증제도가 요구되며,

전자인증제도는 바로 전자서명기술의 안전한 운영을 의미하고 다시 전자서명기술에 사용되

는 공개키암호알고리즘의 비밀키의 기밀성과 공개키의 무결성을 보장해야 하며 이를 해결하

고자 하는 것이 바로 공개키 기반 구조이다 즉 공개키 기반 구조 구축은 전자인종제도를. ,

실체화하는 것이다.

본 절에서는 공개키 기반구조의 정의 및 구성 모델을 살펴보고 국내 공인인증 기관에 관하

여 기술한다.

공개키 기반 구조1. (PKI: Public Key Infrastructure)

가 주요용어.

인증기관(1) (CA: Certification Authority)

인증 정책에 따라 인증서를 생성하거나 취소하는 객체 로 모든 인증기관들은 자신의(entity)

키쌍을 생성하고 선택적으로 사용자의 키를 생성할 수 있다.

- 39 -

인증서(2) (certificate)

인증 기관의 비밀키로 암호화되어 위조할 수 없는 사용자의 유일한 이름 사용자의 공개키,

및 기타 정보로 이루어진 문서로 인증서블 발행한 의 인증 정책도 포함한다 는CA . X<<Y>>

인증 기관 가 사용자 또는 하위 인증기관 에게 발행한 인증서를 의미한다X Y .

인증정책(3) (certification policy)

인증정책은 가 작동하는 메커니즘과 사용되는 암호 알고리즘과 서명 알고리즘 최소 키CA ,

크기 인증서 유효의 최대 길이 인증서 취소 목록 갱신의 최대 기간 인증서를 발행하기 위, , ,

해 사용자의 신분을 확인하는 메커니즘등을 기술한다 정책은 객체 식별자. (OID: Object

로 명명되고 정책의 는 그 정책하에 발행된 모든 인증서내 영역 에Identifier) OID (extension )

포함된다.

보안 정책(4) (security policy)

보안 서비스 및 기능의 제공을 관리하는 보안 기관에 의한 규칙들이다.

도메인(5) (domain)

공통적인 보안 정책을 구현하거나 밀접하게 관련있는 명명공간 내에 사용자들(namespace)

에 대해 인증서를 발행해주는 들이 논리적으로 그룹화되어 있는 것을 도메인이라 한다CA .

고유 이름(6) (Distinguished Name)

내의 객체들을 유일하게 구별하는 이름으로 보통 명명 방식을 따른다PKI X.500 .

- 40 -

상호인증서(7) (cross-certificate)

한 가 다른 를 신뢰하여 그 에 인증서를 발행할 때 그 인증서를 상호인증서라 한CA CA CA

다 한 를 신뢰하는 모든 객체는 그 가 상호 인증한 에 의해서 발행된 모든 인증. CA CA CA

서를 신뢰한다.

인증 경로(8) (certification path)

경로상의 최종 객체에 대한 공개키를 얻기 위한 인증서들의 정렬된 순서로 는 로부A B A→

터 로의 인증 경로를 나타낸다 는 의 인증서로 시작되어 의 인증서로 끝나는 고B . A B A B→

리의 형태인 로 구성된다CAA<<A>> CAB<<B>> .ㆍㆍㆍ

디렉토리(9) (directory)

객체에 대한 정보 저장소로 사용자들로 하여금 그 정보에 접근할 수 있는 서비스를 제공한

다.

신뢰(10) (trust)

일반적으로 한 실체는 다른 실체가 자신의 기대한 바와 같이 행동을 하리라고 가정할 수 있

을 때 실체는 다른 실체를 신뢰한다고 말할 수 있다 이러한 신뢰는 일부 특정 기능에만 적.

용될 수 있다 인증 프레임워크에서 이 신뢰의 주요 역할은 인증하려는 실체와 인증 기관간.

의 관계를 기술하는 것으로 인증하려는 실체는 인증 기관이 유효하고 신뢰할만한 인증서를

생성한다고 확신할 수 있어야 한다.

- 41 -

나 공개키 기반구조. (PKI: Public Key Infrastructure)

공개키 암호기술은 보안이 필요한 옹용 분야에 널리 사용된다 공개키 암호 기술에서는 비.

밀키와 공개키를 이용한다 비밀키는 그 소유자만이 알고 있고 공개키는 공개된다 공개키. .

를 공개하는 문제는 비밀키를 소유자만이 알도록 하는 것보다 얼핏 보기에 매우 단순한 것

같지만 실제 구현시 공개키를 공개하는 데에 사용되는 메커니즘 공개키 디렉토리 게시판( ,

등 이 자체적으로 안전하지 않아 누구나 쉽게 접근하여 정보를 변경할 수 있으므로 공개키)

의 위 변조 문제를 야기시킨다 다음과 같은 경우를 생각해 보자 가 에게 문서를 비밀리· . . A B

보내고자 하는 경우 는 의 공개키로 그 문서를 암호화할 것이다 그런데 제 자인 가A B . 3 C

공개키 디렉토리에 접근하여 의 공개키를 자신의 공개키로 바꾸어 버리고 전송되는 암호B

문을 중간에 가로채 버린다면 가 원래 문서를 보내려고 했던 가 아닌 가 그 문서를 읽A B C

게 될 것이다.

이렇게 공개된 공개키가 위 변조되지 않았음을 보장하는 문제 즉 공개키의 무결성을 보장,ㆍ

하기 위해 등장한 것이 공개키 기반구조 이다 공개키 기(PKI: Public Key Infrastructure) .

반구조에서는 공개키를 공개하는 대신 공개키와 그 공개키의 소유자를 연결하여 주는 인증

서 를 공개한다 인증서는 신뢰할 수 있는 제 자 인증기관 의 서명문이므로 신(certificate) . 3 ( )

뢰 객체가 아닌 사람은 그 문서의 내용을 변경할 수 없도록 한다.

의 정의(1) PKI

공개키 기반구조에 대한 정의는 다음과 같이 여러 가기로 생각할 수 있다.

사용자의 공개키를 인증해주는 인증 기관들의 네트워크▶

- 42 -

모르는 사람과의 비밀 통신을 가능하게 하는 암호학적 키와 인증서의 배달 시스템▶

공개키의 인증서를 이용해 공개키들을 자동적으로 관리해주는 기반구조▶

공개키 인증서를 발행하고 그에 대한 접근을 제공하는 인증서 관리 기반구조▶

이를 통합하여 정리하면 정보시스템 보안 전자 상거래 안전한 통신 등의 여러 응용분야에, ,

서 인증서 의 사용을 용이하도록 하는 정책 수단 도구등을 수립하고 제공하는(certificate) . ,

객체들의 네트워크이다.

가 제공하는 서비스(2) PKI

는 다음의 가지 기본 보안 서비스를 제공한다PKI 5 .

프라이버시 정보의 기밀성을 유지한다: .▶

접근통제 선택된 수신자만이 정보에 접근하도록 허락한다: .▶

무결성 정보가 전송중에 변경되지 않았음을 보장한다: .▶

인증 정보의 원천지를 보장한다: .▶

부인 봉쇄 정보가 송신자에 의해 전송되었음을 보장한다: .▶

응용 분야(3) PKI

는 공개키 암호기술이 사용되는 모든 분야의 하나의 기반기술로서 반드시 필요한 기반PKI

구조이다 그러므로 그 응용분야도 무궁무진하다 표 는 인증 기관과 서비스 받을 객체. . [ 2-2]

들에 따른 의 다양한 응용분야들이다PKI .

- 43 -

표 의 다양한 응용분야[ 2-2] PKI

인증 기관 서비스 받을 인증될 객체들( ) 응용 분야

재정 협회들,

은행들사인들 카드 소지자들. 안전한 지불 거래들

은행 계좌 소지자들 홈뱅킹 대불 저당 절차들 등, /

연방 정부 국민들

납세를 위한 소득신고 제출 사,

회보장제도에 대한 문의와 그에

대한 응답 등

연방 정부 기업들 재무상태 보고서 제출

우체국 우체국의 고객들전자적 소인 전자적 등기 메일,

등

의료 보험 회사,

건강 관리 조직들

의료 연합회

의사들 병원들,

환자 기록에의 접근 치료 계획,

의 제출 안전한 치료 인가와 수,

행된 서비스에 대한 상환

법 기관들과 법원 판사들 변호사들 법률가들, ,법원 선서와 다른 법 문서의 제

출

인터넷 서비스

제공자들

서비스들을 이용하는 기업ISP

들계정 접근dial-up

소프트웨어 사업들

소프트웨어 모듈들다운로드할 소프트웨어가 바이

러스등에 안정함을 보장

고객들 잔자적 소프트웨어 전송과 제공

인터넷 서비스 제공자JSP(Jnternet Service Provider):※

다 모델. PKI

구성 요소(1) PKI

를 구성 하는 최 소 객 체 들은 등록기 관 인증 기관 디PKl (RA:Registration AuthohtyT), ,

렉토리 사용자이다, .

- 44 -

가 인증기관( )

공개키기반구조를 구성하는 가장 핵심 객체로 그 역할 및 기능에 따라 계층적으로 구성되며

여러 명칭으로 불리운다 아래 세기관 모두를 통틀어 인증기관이라 한다. .

정책승인기관(PAN Policy Approving Authority)▶

전반에 사용되는 정책을 생성하고 구축의 루트 로의 역할을 하며 다음을 수행한PKI PKI CA

다.

전반에 사용되는 정책과 절차를 생성하여 수립한다- PKI .

하위 기관들의 정책 준수 상태 및 적정성을 감사한다- .

내 외에서의 상호 인증을 위한 정책을 수립하고 그를 승인한다- PKI · .

하위 기관의 공개키를 인증하고 인증서 인증서취소목록등을 관리한다- , .

정책인증기관(PCA: Policy Certification Authority)▶

아래 계층으로 자신의 도메인내의 사용자와 인증기관 이 따라야 할 정책을 수립하PAA (CA)

고 인증기관의 공개키를 인증하고 인중서 인증서 취소목록등을 관리한다, .

인증기관(CA: Certification Authority)▶

아래 계층으로 다음과 같은 기능을 수행한다- PCA .

사용자의 공개키 인증서를 발행하고 또 필요에 따라 취소한다- .

- 45 -

사용자에게 자신의 공개키와 상위 기관의 공개키를 전달한다- .

등록기관의 요청에 의해 인증서를 발행하고 되돌린다- .

상호 인증서를 발행한다- .

최소한의 정책 책임을 진다- .

인증서와 그 소유자 정보를 관리하는 데이터베이스를 관리한다- .

인증서 인증서취소목록 감사 파일을 보관한다- , , .

나 등록기관( ) (RA)

인증기관과 멀리 떨어져 있는 사용자들을 위해 인증기관과 사용자사이에 등록기관을 두어

인증기관대신 사용자들의 인증서 신청시 그들의 신분과 소속을 확인하는 기능을 수행한다.

사용자들의 신분을 확인한 후 등록기관은 인증서 요청에 서명을 한 후 인증기관에게 제출,

한다 인증기관은 등록기관의 서명을 확인한 후 사용자의 인증서를 발행한 후 등록기관에게.

되돌리거나 사용자에게 직접 전달한다 는 조직 등록기관. RA (ORA: Organizational

라고도 불리운다Registration Authority) .

다 디렉토리( )

인증서와 사용자 관련 정보 상호 인증서 쌍 및 인증서취소목록등을 저장 및 검색하는 장소,

로 응용에 따라 이를 위한 서버를 설치하거나 인증기관에서 관리한다 디렉토리를 관리하는.

서버 인증기관 는 나 를 이( ) DAP(Directory Access-.Protocol) LDAP(Lightweight DAP)[3]

용하여 디렉토리 서비스를 제공한다 인증서와 상호 인증서 쌍은 유효기간이 경과된X.500 .

후에도 서명 검증의 응용을 위해 일정기간동안 디렉토리에 저장된다.

- 46 -

라 사용자( )

내의 사용자는 사람뿐만 아니라 사람이 이용하는 시스템 모두를 의미한다 다음의 기능PKI .

을 수행한다.

자신의 비밀키 공개키 쌍을 생성할 수 있어야 한다- / .

공개키 인증서를 요청하고 획득할 수 있어야 한다- .

전자 서명을 생성 및 검증할 수 있어야 한다- .

특정 사용자에 대한 인증서를 획득하고 그 상태를 결정할 수 있어야 한다- .

인증 경로를 해석할 수 있어야 한다- .

디렉토리를 이용하여 자신의 인증서를 다른 사용자에게 제공할 수 있어야 한다- .

인증서 취소 목록을 해석할 수 있어야 한다- .

비밀키가 분실 또는 손상되거나 자신의 정보가 변했을 때 예 조직의 탈퇴 인증서 취소- ( : )

를 요청할 수 있어야 한다.

의 관리 대상(2) PKI

- 에서 관리해야 할 대상은 크게 인증서와 인증서 취소목록 상호 인증서쌍이 있다PKI , .

가 인증서( )

인증서는 사용자의 신분과 공개키를 연결해주는 문서로 인증기관의 비밀키로 전자서명하여

생성된다 다시 말해 이것은 사용자의 공개키가 실제로 사용자의 것임을 증명한다. .

- 47 -

에서 인증서의 발행대상은 인증기관과 사용자 서비등으로 인증기관에게는 상위 인증기PKI ,

관이 인증기관의 적법성을 증명하기위해 발행하고 사용자와 서버에게는 사용자의 신원 서,

버 등의 적법성을 증명하기 위해 인증기관에서 발행한다 인증서의 형식은 년에. 1988

가 초기 버전을 공표하고 년에 버전 를 공표했으며 년 이후로는ITU-T X.509 1993 2 1995

의 문서와 동일시되어 공동 개발되어왔다 현재에는 버전 까지 공ISO/IEC.9594-8 . X.509 3

표되었고 인증서의 영역에 대한 개정이 진행되고 있다 의 형식은 그extensions . x.509v3 [

림 과 같다1] .

표 의 형식[ 2-3] X.509v3

항목 설명

version의 버전으로 은 버전 은 버전 는 버전X.509 0 1, 1 2, 2

을 의미함3

serial number발행자가 생성한 가가가의 확인서에 대한 유일 식별

자

signature algorithm id발행자가 확인서를 서명하는 데에 사용한 알고리즘

을 기입

issuer name확인서를 서명하고 생성한 발행자의 로 명명id X.500

방식을 따름

validity period확인서가 사용될 수 있는 시작 시간과 끝 시간을 기

입하는 것으로 시간과 날짜 형식 로 표현됨(UTCT )

subject name확인서를 받는 공개키의 소유주의 로 명명id X.500

방식을 따름

subject public key info사용자의 공개키와 공개키에 대한 정보 알고리즘과(

파라미터 를 기입)

선택issuer unique identifier ( )버전 이상에서 사용되는 것으로 발행자의 부가적인2

정보를 포함함

선택subject unique identifier ( )버전 이상에서 사용되는 것으로 객체의 부가적인 정2

보를 포함함

선택extensions ( ) 인증 정책등 여러 가지 사항을 포함함

signature 앞의 목록들에 대한 서명값

나 상호인증서쌍( ) (cross-certification pair)

한 도메인이나 서로 다른 도메인의 인증기관들사이에 발행하는 인증서로 두가기 형태가 있

다 이것은 쌍을 이뤄 각 인승기관 의 엔트리로 디렉토리에서 관리된다. (X) .

- 48 -

순방 인증서 인증기관 에 대해 다른 인증기관에서 생성한 인증서(forward) : X▶

역방 인증서 인증기관 가 다른 인증기관에게 생성한 인증서(reverse) : X▶

상호 인증서를 사용함으로써 같은 도메인내에서는 인증 경로를 단축할 수 있고 서로 다른

도메인내의 사용자들에게는 그들간의 안전한 통신 수단을 제공할 수 있다.

다 인증서 취소 목록( ) (CRL: Certificate Revocation List)

인증서는 인증된 공개키에 해당하는 비밀키가 노출된다든가 그 공개키의 소유자가 다른 도

메인으로 옮기는 경우 등 여러 가지 이유로 유효기간이 만기되기 전에 그 효력이 상실될 수

있다 인증기관은 이렇게 효력이 상실된 인증서들에 대한 목록을 생성해 내에서 관리한. PKI

다.

그림 형식( 2-4) X.509v2 CRL

- 49 -

인증서 취소목록은 형식을 따르는 추세로 그림 와 같다 은 형식에서 볼X.509v2 ( 2-4) . CRL

수 있듯이 주기적으로 생성된다 이 주기는 인증 정책에 명시된다. .

구성(3) PKI

에서 신뢰는 인증 경로를 통해 전달된다 전자 서명을 검증할 때를 생각해 보자 전자서PKI . .

명의 검증자는 자신이 신뢰하는 인증 기관의 공개키만을 알고 있으므로 그 인증 기관의 공

개키를 이용하여 인증 경로를 검증함으로써 서명자의 공개키를 획득한다 이렇게 획득한 공.

개키는 무결성이 보장된다 검증자는 무결성이 보장된 공개키를 이용하여 서명을 검증할 수.

있는 것이다 이러한 신뢰가 인증 경로를 통해 어떻게 전달되는 지에 따라 는 다음 두. PKI

가지 형태로 구성될 수 있다.

가 계층적 구성( )

인증기관들이 하위 에게 인증서를 발행하는 루트 아래에 계층적으로 배열되CA '' '' CA(PAA)

어 있는 구성으로 인증기관들은 자신의 아래 들에게 인증서들을 발행한다 계층적으로CA .

구성된 에서 루트 의 공개키는 모든 사람에게 알려져 있어 사용자들의 인증서는 루PKI CA

트 로에서 자신이 신뢰하는 인증기관까지의 인증 경로를 검증함으로써 검증된다CA .

그림 에서 갑이 을의 전자서명을 검증한다고 하자 우선 갑은 을의 공개키를 획득해야( 2-5) .

한다 갑은 과 를 신뢰하고 을은 과 를 신뢰한다 을은 갑에서 서명문과. CA1 CA3 CA1 CA4 .

함께 인증기관 에서 까지의 인증경로를 전송한다 갑은 을이 자신과 같은 도메인에CA1 CA4 .

있음을 확인한 후 자신이 알고있는 의 공개키를 이용해 에서 까지의 인증경로CA1 CA1 CA4

를 검증하여 을의 공개키를 획득한 후 서명문을 검증한다.

- 50 -

그림 계층적 구성( 2-5)

- 51 -

나 네트워크 구성( )

그림 네트워크 구성( 2-6)

인증기관이 각각의 도메인을 형성하여 독립적으로 존재하는 구성으로 들이 서로를 상호CA

인증하여 서로에게 인증서를 발행한다 네트워크로 구성된 의 사용자는 자신의 인증서. PKI

를 발행한 즉 자신이 신뢰하는 인증 기관의 공개키만를 알고 있다 그림 과 같은 구성( , ) .( 2-6)

에서 갑이 을의 서명문을 검증하고자 한다고 생각하자 갑은 를 신뢰하고 을은 만. CA3 CA2

을 신뢰한다 을에서 갑으로의 인증 경로는 여러개가 존재하므로 이중에서 가장 짧은 인증.

경로를 찾는 탐색과정이 필요하다 가장 짧은 인증경로는.

을 이다CA3<<CA1>>CA1<<CA2>>CA2<< >> .

- 52 -

표 계층적 구성과 네트워크 구성의 장 단점[ 2-4] ㆍ

구성PKI 장점 단점

계층적

▶ 많은 조직의 관리 구조가 계층적

이므로 자연스럽게 부합된다

▶ 계층적 디렉토리 이름과 잘 부합

된다.

▶ 각 국가별 가 구축될 경우 이PKI

것을 모두통합하는 하나의 루트

가 존재한다는 것은 현실과CA

맞지 않다.

▶ 인증 경로 탐색 전략이 간단한다.▶

가 상업적인 분야에 이용될PKI

때는 관계는 계층적일 필요가 없

다.

▶도메인내의 모든 사용자는 루트

의 공개키를 알고 있고 인증하고

자하는 사용자는 루트로부터 자

신이 신뢰하는 인증기관까지의

인증 경로를 제공할 수 있으므로

인증서를 검증하고자 하는 다른

사용자는 루트의 공개키를 알고

있으므로 그 경로를 검증할 수

있다.

▶루트 비밀키의 노출은 끔찍한 상

황을야기하고 복구하기 위해서는

내의 모든 사용자에게 새로운PKI

공개키의 안전한 분배가 필요하

다

네트워

크

▶유연성을 가지며 사업 기관의 상

호 신뢰 관계를 잘 반영한다.

▶ 사용자는 자신의 인증서를 발행

한 를 신뢰해야 하고 이것이CA

모든 신뢰 관계의 기본이 되는

것이 자연스럽다.

▶ 인증 경로 탐색 전략이 계층적구

성에 비해 훨씬 복잡하다.

▶조직적으로 멀리 떨어져 있지만

그 속의 사용자들이 높은 신뢰감

으로 함께 일할 경우 들이 서CA

로 직접적으로 상호 인증될 수

있다.

▶ 사용자는 의 다른 사용자에게PKI

단일 인증 경로를 제공할수 없다.

왜냐하면 네트워크형에서의 두

사용자간의 인증경로는 여러개가

존재하기 때문이다.

▶ 자들이 빈번히 통신하는 들의CA

직접적 상호인증을 허락함으로써

인증서로 처리 부담을 감소한다.

▶ 비밀키가 손상되어 복구할 경우

에 는 새로운 공개키를 자신CA

의 사용자들에게만 안전하게 분

배하면 된다.

- 53 -

갑은 이 인증경로를 이용해 울의 공개키를 획득하고 그를 이용해 전자서명 검증한다 네트.

워크로 구성되었음 경우에는 인증 경로가 여러 게 존재할 수 있으므로 이중 짧은 경로를 찾

는 것이 중요 관건이다.

의 두가지 구성은 서로 장 단점을 가지고 있다 표 는 고 장 단점을 비교한 것이다PKI · ·[ 2-4] · .

실제 구축시에는 기본적으로는 계층적 구조를 구성하면서 효율성과 다른 와의 통신PKI PKI

을 위해 한 도메인내 또는 다른 도메인내의 인증기관들 사이에 네트워크 구조를 허락한다.

- 54 -

국내 공인인증기관2.

인증기관은 크게 공인인증기관과 사실인증기관으로 나누어 볼 수가 있다 공인인증기관은.

인터넷과 같은 공공환경에서 공식적으로 인증서를 발급하는 인증기관이고 사설인증기관은

조직내의 사설망 인트라넷 에서 사용할 목적으로 인증서를 발급해 주는 기관을 말한다 여( ) .

기서는 공인인증기관을 사설망에서 사용할 목적을 인증서를 발급해주는 기관을Public CA,

라 칭한다Private CA .

가 인증 기능의 정의 및 활용.

인증은 어떤 사실을 증명하거나 확인하기 위해 사용되는 기능으로 전자상거래에 있어서 인,

증 서비스의 목표는 크게 개로 압축하여 설명할 수 있다 첫째는 안전한 전자상거래의 보3 .

장이며 둘째는 개인 및 기업의 비밀 보장이다 그리고 마지막으로 거래 사실에 대한 증명, .

을 제공하는 것이다 이러한 목표를 달성하기 위해 전자상거래에 적용되는 인증 기능은 일.

반적으로 다음과 같이 구분할 수 있다.

사용자 인증 상대방의 신분 을 확인하는 기능 인증서를 통해 확인됨: (identity) ,▶

내용 인증 기래 내용 일시 동을 확인하는 기능 전자서명을 통해 확인됨: , ,▶

신용 인종 거래 상대의 신용 능력을 확인하는 기능:▶

전자상거래가 보다 복잡하게 사용되고 응용 서비스의 범위가 넓어짐에 따라 내용 인증과,

신용 인증의 필요성도 커지고는 있으나 전자상거래에서 가장 시급하고 것으로 인식되며 가,

장 활발하게 연구되고 있는 것은 사용자 인증 즉 신분 인증 기능이다, .

- 55 -

나 인증 기반 기술.

인증 서비스의 기반기술로써 현재 가장 주목받고 있으며 사실상의 표준으로 받아들여지고,

있는 것은 의 이다 를 이용한다 구성요소는 다음과 같다ITU-T X.509 . X.509 , X.509 .

인증기관 일반적으로 계층적 구조로 구성된다(CA): .▶

등록기관 는 를 대신해 사용자들(ORA): Organization Registration Authority): ORA CA▶

의 인증서 신청시 그들의 신분과 소속을 확인하는 기능을 수행한다.

인증서 소유주 로부터 인증서를 발급 받고 전자문서에 전자서명(Certificate holder): CA ,▶

을 할 수 있다.

클라이언트 신뢰할 수 있는 의 공개키를 통해 전자서명과 인증 경로를 검사(Client): CA▶

한다.

저장소 인증서와 사용자 관련 정보 상호인증서 및 인증서 취소 목록을 저(repository): ,▶

장 및 검색하는 장소로서 응용에 따라 이를 위한 서버를 따로 설치하거나 에서 관리한, CA

다.

다 인증기관의 운용 업무.

인증기관의 가장 중요한 업무는 인증서의 발행 취소 및 관리 업무이다 이밖에도 인증기관, .

은 사용자의 신원 확인 인증서의 공개 등의 업무를 수행하는데 기본적인 인증기관의 운용, ,

업무를 살펴보면 다음과 같다.

- 56 -

사용자 신원 확인(1)

인증기관은 인증서 발행 신청자로부터 신원과 관련된 정보를 제출 받아 이를 통해 본인 여,

부를 확인한다 이를 위해 인증기관은 통상 본인 이외에는 알기 어려운 정보를 통해 신원을.

확인하게 된다 사용자 신원 확인의 구체적인 방법에 대해서는 인증 서비스의 수준에 따라.

서 다를 수 있으나 통상 다음과 같이 분류할 수 있다, .

개인 운전면허증 여권 주민등록증 의료보험증 인감 증명 등에 의한 확인: , , , ,▶

법인 등기부 등본 및 대표자의 인감 증명 등에 의한 확인:▶

등록 신청이 대리인을 통해 이루어지는 경우 인증기관은 대리인이 정당한 권리를 가지고,

있는지 충분히 확인할 필요가 있다 이 경우에도 인증기관은 대리 신청 시에 요구되는 요건.

에 대해서 미리 명확하게 해두는 것이 바람직하다 대개의 경우 인증서 신청인에 대한 신원.

확인 절차의 수준에 따라 인증서 사용 용도나 요금 등 인증 서비스의 수준이 결정된다.

인증서 발행(2)

공개키 인증서에는 인증서 수령자가 필요로 하는 최소한의 정보가 기재되는 것이 필요하다.

구체적인 기재 사항은 인증 서비스의 내용에 따라 다르지만 기본적으로 등의 국제, X.509

표준에 따르는 것이 필요하다 또한 인증기관이 공개키 인증서 발행시에 배상 책임 한도액.

을 설정한 경우 공개키 인증서에 대해서도 해당 한도액을 기재하는 것이 필요하다, .

- 57 -

발행된 인증서의 공표(3)

사용자는 안전한 암호화 통신을 하기 위해서 상대방의 공개키를 검증해야하는데 이때 상대,

방의 인증서가 필요하다 필요한 인증서는 가 발급한 인증서를 보관하는. CA DSA(Directory

로부터 가져올 수 있다 그러나 인증기관은 인증서를 공개함에 있어서 본인Service Agent) .

의 승인을 얻어야 하며 인증서 정보 외에 개인의 사적인 정보가 노출되지 않도록 주의를· ,

기울여야한다.

인증서의 효력 상실(4)

인증기관이 발행한 인증서는 필요에 의해 효력을 정지시키는 것이 필요하다 효력 상실이.

필요한 경우는 개인 법인 법인소속의 개인인 경우 여러 가지 경우가 있어 각각의 경우에, ,

따라 인증서의 효력을 상실하는 요건을 가진다.

고객의 개인키의 생성 및 관리(5)

인증기관에게 고객의 공개키 인증 업무뿐만 아니라 개인키의 생성 보관 등의 업무를 허용, ,

하는 경우가 있다 고객이 인증기관에 의한 개인키의 생성 보관 등을 원하는 경우 이는 기. , ,

본적으로 인정되어야 한다.

업무의 중단 및 중지(6)

인증기관이 업무를 일시적으로 중단하거나 정지하면 고객은 불이익을 받게 된다 따라서 인.

증기관은 자신의 업무를 중단 혹은 정지하는 경우 충분한 시간적 여유를 가지고 고객에게,

공지할 필요가 있다 또한 영구적으로 업무를 폐지하는 경우 다른 인증기관에게 업무 및. ,

보유 데이터를 인계하는 것이 바람직하다 인승기관은 돌연한 업무 중단 및 정지에 의해 사.

용자에게 불의의 손해를 준 경우 범적인 책임을 져야 할 것이다, .

- 58 -

라 국내의 공인인증기관 지정기준.

기술능력 운영인력(1)

안정한 인증관리체제를 위해 다음의 조선을 갖춘 인 이상의 인증관리체계 운영인력을 확12

보해야 한다.

정보통신기사 정보처리기사 및 전자계산기조직응용기사 이상의 국가기술자격 또는 이와,▶

동등 이상의 자격이 있다고 정보통신부장관이 인정하는 자

정보통신부장관이 정하여 고시하는 정보보호 또는 정보통신 운영 관리 분야에서 년 이· 2▶

상 근무한 경력이 있는 자

인증관리체계의 운영 비상복구대책 및 침해사고의 대응 등에 관하여 보호센터에서 실시·▶

하는 교육을 이수한 자

시설 및 장비 세부지정기준(2)

표 시설 및 장비 세부지정기준[ 2-5]

분류 세부분류 기 능

가입자

신원확인

관리설비

등록관리

시스템

▶ 가입자 식별 기능

▶ 가입자 등록 관리 기능ㆍ

▶ 가입자 내역을 감사 기록하는 기능ㆍ

가입자

정보보관

설비

▶ 인증서와 관련한 가입자 정보 및 가입자인증서 등을 당해 인

증서의 효력이 소멸된 날부터 년 동안 보관하는 설비10

▶ 감사기록 기능을 갖는 출입통제 장치

▶ 카메라 등의 침입감시장치CCTV

▶ 가입자 정보 및 가입자 인증서 등에 대한 물리적 접근을 통

제하는 캐비넷 등의 장금장치

- 59 -

공인

인증기관

전자

서명키

생성시스

템

▶ 전자 서명키 시스템의 무결성 신뢰성 보장ㆍ

▶ 인 이상의 권한 있는 직원이 공동으로 전자 서명키를 생성3

하는 기능

▶ 전자 서명키를 생성한 사실 시각 행위자 등에 관한 내역을, ,

감사기록 보존하는 기능ㆍ

▶ 전자 서명키 생성 시스템의 이중 설치

전자

서명키

교부설비

▶ 가입자의 전자서명 생성키를 생성하는 경우 이를 유출하지

않고 안전하게 교부하기 위한 기능

▶ 국가기관 지방자치단계의 경우 국가기관용 암호가 이식 가ㆍ

능하도록 하는기능 부여

전자서명

생성키

저장장치

▶ 저장장치에 대한 봉인 기능

▶ 저장장치에 대한 접근권한을 확인하는 기능

▶ 전자서명 생성키의 불법 유출 변경을 방지하는 기능ㆍ

가입자용

전자서명

생성키

저장장치

▶ 개인식별번호 확인 기능을 가진 스마트 카드 또는 암호화된,

디스켓

인증서

생성관리

시스템

▶ 버전 규격의 인증서를 생성하는 기능X509 3

▶ 버전 규격의 인증서 폐지목록을 생성하는 기능X509 2

▶ 인 이상의 권한 있는 직원이 공동으로 인증서를 생성 발급2 ㆍ

갱신 효력정지 또는 폐지하는 기능ㆍ ㆍ

▶ 인증서를 생성 발급 갱신 효력정지 또는 폐지하한 사실,ㆍ ㆍ ㆍ

시각 행위자 등에 관한 내역을 감사기록 보관하는 기능, ㆍ

▶ 인증서 생성 관리 시스템의 이중 설치ㆍ

디렉토리

시스템

▶ 가입자인증서 등을 등록 관리하는 기능ㆍ

▶ 가입자인증서 등을 을 통해 항상 검색할 수 있도DAP(LDAP)

록 하는 기능

▶ 가입자 인증서 등을 등록 관리한 사실 시각 행위자 등에, ,ㆍ

관한 내역을 감사기록 보존하는 기능ㆍ

▶ 디렉토리 시스템의 이중 설치

가입자

인증서등

의

저장설비

▶ 가입자 인증서 등을 화재 홍수 등으로부터 안전하게 보관할,

수 있는 물리적으로 분리된 이중 저장설비

▶ 감사기록 기능을 갖춘 출입통제 장치

▶ 카메라 등의 침입감시장치CCTV

▶ 가입자인증서 등에 대한 물리적 접근을 통제하는 캐미넷 등

의 잠금장치

전자서명

알고리즘

▶ 등 안정성을 검증 받은 국제 국가 단체 표준RSA, KCDSA ㆍ ㆍ

알고리즘 또는 국가기관 지방자치단체의 경우 국가기관용으ㆍ

로 허용된 알고리즘

▶ 비트 이상의 안정성에 준하는 키 크기RSA 1024

해 쉬

알고리즘

▶ 등 안전성을 검증 받은 국제 국가 단SHA-1, HAS-160 ㆍ ㆍ

체 표준 알고리즘 또는 국가기관 지방자치단체의 경우 국가ㆍ

기관용으로 허용된 알고리즘

▶ 비트 이상의 해쉬 값 생성 기능160

- 60 -

시점

확인

장치

시각수신

장치

▶ 초단위로 표현 가능한 정확한 표준서를 수신하는 기능

▶ 시점확인 시스템의 시간을 보정하는 기능

▶ 시각수신 장티의 이중 설치

시점확인

시스템

▶ 시점확인용 전자서명 생성키를 이용하여 전자문서의 시점을

확인 할 수 있는 기능

▶ 시점확인 시스템의 이중 설치

보호

설비

핵심인증

시스템

운영실

▶ 핵심인증시스템을 운영할 수 있는 별도의 통제구역 설치

▶ 당화 유리 창문 통풍창의 차폐막,

다중출입

통제장치

▶ 핵심인증시스템 운영상에 대한출입을 통제하고 감사기록하는

기능을 갖는 출입통제장치

▶ 사원원확인 기능 중 여러 가지를 결합하여 사용하는 출입통

제장치

침입감지

경보 및ㆍ

감시ㆍ

통제장치

▶ 핵심인증시시스템 운영실 및 핵심인증시스템에 대하여 침입

을 감지하고 이를 정보 하여 주는 장치

▶ 핵심인증시스템 운영실 및 핵심인증시스템을 감시 통제하고

이에 대한 감사기록 기능을 갖는 장치

물리적

장금장치▶ 나중출입통제장치로부터의 출입현황정보 확인 기능

물리적

장금장치

▶ 평가필증을 교부받은 침입차단시스템

▶ 네트워크 서비스 방해 공격을 방지하는 보안 설비

네트워크

보안설비

▶ 국가기관 지방자치단체의 경구 국가전산보안업무기본지침[ ]ㆍ

에 의한 전산보안대책 강구

재해

예방설비

▶ 화재 발생시 이를 조기에 진화하여 주는 화재 예방 설비

▶ 수재 발생시 핵심인증 시스템의 지속적인 운영에 영향을 주

지 않는 설비이어야 함

▶ 정전 발생시 지속적인 인증업무의 수행이 가능하도록 일정기

간 전원을 공급하여 주는 전원 공급 설비

기타

보호설비

▶ 서로 다른 개의 외부네트워크 전용회선2

▶ 항온항습장치

마 인증 서비스.

인증이라 함은 보통 사용자 전자서명의 검증키와 이를 사용하는 사용자 또는 법인과의 귀속

관계 등을 인증기관이 전자 서명하여 확인 증명한 전자 정보를 말한다 인증 서비스는 공, .

개키 암호 알고리즘을 사용하면서 시작되었다 안전한 전자거래를 위해 서비스되는 인증. ,

비밀성 무결성 부인방지 등은 전자서명 기술을 적용함으로써 해결이 가능다다 이러한 전, , .

자서명 기술을 실제 적용하기 위해서는 인증 서비스가 필수적으로 필요하다 인증 서비스란.

인증기관이 제공하는 모든 서비스를 말한다.

- 61 -

즉 인증서 발급 인승서의 취소 및 관리 등 모든 인증기관이 담당하는 업무를 말한다 인증, .

서비스는 인증서의 종류에 따라 두 가지 종류로 나누어진다 인증서는 장에서 언급한 인증. 2

서를 발행한 인증기관의 종류에 따라 다르다 공인인증기관에서 발행한 인증서는 공인인증.

기관이 인증서를 발급하고 이에 대해 수수료를 받아 이득을 취하는 반면 사설인증기관에서

발급한 인증서는 자신들의 안전한 시스템구축을 위해 발급하는 인증서이다 다음 표. [ 2-6]

은 현재 각국의 인증 서비스업체들이 제공하고 있는 인증 서비스의 종류를 나열한 것이다.

표 인증 서비스의 종류[ 2-6]

종류 용도

S/MlME 전자메일용 인증서

SSL 웹 서버에 적용하기 위한 필요한 인증서

Global Server ID 미국외에서 을 사용하기 위해 필요한 인증서SSL

를 위한 금융서버OFX

ID프로토콜 적용에 필요한 인증서OFX

서버EDI ID 안전한 구현에 필요한 인증서EDI

MicroSoft

AuthenticDode

등 마르크로소프트사에서 제공하는기술OCX, CLASS, CAP

을 사용하여 제작한 의 온라인 판매시 사용되는 인증서S/W

Nstscape Object

signing

등으로 제작된 의 온라인 판매시 사용JavaScript, Java S/W

되는 인증서

SET 프로트콜 구현에 사용되는 인증서SET

- 62 -

바 국내외의 인증 서비스 제공 업체.

표 국내외의 인증 서비스 제공 업체 현황[ 2-7]

구분 국가 회사명 특징

국내 한국

한국정보인증 주( ) 한국 공인 인증기관 인증서 발급 서비스-

금융결재원 한국 공인 인증기관 인증서 발급 서비스-

한국증권전산 주( ) 한국 공인 인증기관 인증서 발급 서비스-

국외

미국

DST Company 유타주정부 공인인증기관

ARCANVS 유타주정부 공인인증기관

UWERTrust 유타주정부 공인인증기관

VeriSign 인증서 발급 및 솔루션 제공PKI

영국 Trusrwise 인증서 발급 서비스

프랑스 Certplus 인증서 발급 서비스

일본 VeriSign Japan 인증서 발급 및 솔루션 제공PKI

대만 HiTnist 인증서 발급 서비스

독일Deutsche Telekom 독일 공인 인증기관 인증서 발급 서비스-

Deutsche Post 독일 공인 인증기관 인증서 발급 서비스-

사 국내의 공인인증기관 및 인증 서비스.

국내의 전자서명법은 공인인증기관 지정 및 운영에 대한 내용이 기재되어있으며 한국정보,

보호진흥원로 하여금 공인인증기관 지정을 위한 실질심사와 지정된 공인인증기관에 대한 인

증서 발급 및 관리 업무를 수행하도록 하고 있다 현재 한국정보보호진흥원의 인증 업무준.

칙은 전자서명법 전자서명법시행령 및 전자서명법 시행규칙에 의하여 보호센터의 인증서,

정책 인증서발급 관리 보안통제 기타 운영정책 절차 등 전자 서명 인증과 관련된 업무에, · , , ·

관하여 필요한 사항 및 보호센터와 공인인증기관 등의 책임 의무에 관한 사항을 규정함에·

목적을 두고 있다 따라서 한국정보보호신흥원은 인증기관 관리의 최상위 기관으로서 전자.

서명 인증관리체계 구축 운영 및 공인인증기관에 대한 인증서 발급 및 관리를 통하여 전자·

서명 인증관리체계의 안전 신뢰성 확보와 전자서명 인증제도 및 전자문서 이용 활성화 기ㆍ

반 조성에 기반이 되고 있다.

- 63 -

한국정보보호진흥원에 의해 인증된 공인인증기관들은 이용자의 전자서명 검증키에 대한 무

결성 보장과 신분을 보증하기 위하여 인증서 발급서비스를 제공할 것이다 그러나 일반인증.

기관도 이와 같은 역할을 수행하지만 공인인증기관은 사용자에 대한 신원확인 절차 인증, ,

관리기관에서 발급한 인증서는 법 인감과 동일한 법적 효력을 발휘하기 때문에 해당 공인증

기관들은 법에서 정의나 특별 준칙의 요구조건을 만족해야하며 규정된 이외의 서비스는 제

공하지 않는다.

그림 국내의 공인인증기관 및 인증 서비스( 2-7)

- 64 -

국내의 공인인증기관현황(1)

현재의 국내에는 개의 업체가 공인인증기관으로 지정되어 인증업무를 수행하고 있다3 .

년 월에 한국정보인증 주 한국증권전산 주 이 공인인증기관으로 지정되었으며2000 2 ( ), ( ) , 2000

년 월에 금융결재원이 공인인증기관으로 지정되었다 현재 한국정보인증 주 와 한국증권전4 . ( )

산 주 은 년 월부터 사용서비스를 개시하였으며 금융결재원은 사용서비스를 준비중( ) 2000 3 ,

에 있다.

표 은 현재 국내의 공인인증기관의 인증업무 추진현황을 나타낸다[ 2-8] .

표 공인인증기관의 인증업무 수진현황[ 2-8]

공인인증기관의 인증수수료 현황(2)

공인인증기관의 인증수수료는 인증업무준칙에 명시해야하는 중요한 내용 중의 하나이다 현.

재 국내의 경우 공인인증기관의 인증수수료는 인증업무 개시 전에 인증업무준칙을 정보통신

부장관에게 통보하도록 되어있다.

- 65 -

표 국내 공인인증기관의 인증수수료[ 2-9]

국내에서 공인인증 기관으로 선정되어 인증 서비스를 수행하고 있는 공인인증기관은 기관별

로 인증수수료의 차이를 보이고 있다 표 는 공인인증기관이 현재 수행하고 있는 인증. [ 2-9]

서비스에 대한 인증수수료를 정리한 것이다.

국내 공인인증기관별 특징(3)

가 한국증권전산 주( ) ( )

한국증권전산 주 은 년 월에 공인인증기관으로 선정되어 현재 인증서비스를 수행하고( ) 2000 2

있다 표 은 한국증권전산 주 에서 시행하는 인증서비스의 종류와 용도를 요약한 것이. [ 2-10] ( )

다.

한국증권전산 주 의 는 전자금융거래를 인증하기 위해서 정부의 보안성 심의를( ) SignKorea

최초로 통과하였다 는 국내 최초로 전자서명법의 기준에 따라 정보보호센터의. SignKorea

실질 심사를 통과하였다 또한 실질 심사 결과 정보보호 센터로부터 국내 최고의 기술력과. ,

설비를 보유하고 있음을 인정받았다 국제표준 준수로 국제전자상거래에서 이용 가능한 표.

준을 채택하여 이를 적용하고 있다.

- 66 -

표 한국증귄전산 수 의 인증서비스 종류 및 용도[ 2-10] ( )

등급 이용범위 및 용도

Special

비대면 과정에서의 신원확인 및 전자서명▶

비금융기관 및 금융기관에서의 전자문서 교환▶

전자문서의 교환 규모가 크거나 내용이 매우 중요한 경우▶

통신채널 보호▶

Platinum비대면 과정에서의 신원확인 및 전자서명▶

비금융기관 및 금융기관에서의 전자문서 교환▶

Gold비대면 과정에서의 신원확인 및 전자서명▶

비금융기관 및 금융기관에서의 전자문서 교환▶

Silver

범인내 직원간의 등을 통한 신원확인 및Group Ware▶

전자서명

범인 대표명으로 발급하여 범인내무에서만 유효▶

RFC2459(X.509 ver.3)

RFC1777

RFC2559

RFC251 1

RFC25 10 (Certificate Management Protocol)

인증서의 관리 프로토콜의 표준 상호 연동문제의 핵심 고려사항X.509 ,

PKCS#1, #5,#1O

CSSM/CDSA

CSP/CDSA

ITU-T X.680

ITU-T X.690

등ISO7816

- 67 -

또한 은행업계의 공인인증서와의 호환이 가능하도록 금융결재원과 공동으로 공인인증시스템

의 기반을 개발했다 그리고 엘지 현재 신동아화재와 공동으로 배상체계를 구축함으로서. , ,

좀 더 신뢰성 있는 공인인증기관으로 인정받기 위해 노력하고 있다.

나 한국정보인증 주( ) ( )

한국정보인증 주 는 한국증권전산 주 와 같이 년 월 일에 공인인증기관으로 선정되( ) ( ) 2000 2 10

어 현재 인증서비스를 수행하고 있다.

표 은 한국정보인증 주 에서 서비스하는 인증서비스의 종류와 용도에 따른 분류이다[ 2-11] ( ) .

표 한국정보인증 주 에서 제공하는 인증서의 종류와 용도[ 2-1] ( )

등급 발급대상 유효기관 용도

등급1

개인 년1 인터넷상 뱅킹 보험가입 및 증권거래 기업 접속, , DB ,

회원제 온라인서비스 전자성거래 전자상거래 서버, ,

에 대한 인증

법인 단체/ 년1

서버 년1

등급2개인 년1

개인간 전자우편 회사내 회사간 전자우편 온라인, ,

가입 암호교체 소프트웨어 유효성 확인 위험도가, , ,

낮은 소규모 거래

개인 년 이하1주주총회용 등 특수 목적용 상거래

등급3 법인 단체/ 년 이하1

한국정보인증 주 에서 현재 제공중인 서비스는 개인 법인 인증 서비스와 웹 서버 인증 서비( ) /

스이다 한국정보인증 주 에서는 앞으로 인증서비스 무선 인터넷 인증 서비스. ( ) EDI , , VPN

인증 서비스 보안 메일 인증 서비스 소프트웨어 인증 서비스 시점확인 서비스 내용증명, , , ,

서비스 내용 증명 서비스 지불 결제 대행 및 인터넷 과금 서비스 등을 새로이 시행할 예정, , /

이다 또한 부가 서비스로서 인증 시스템 솔루션 제공 및 컨설팅 사업과 인증서비스 호스팅.

사업을 부가적으로 서비스하고 있다.

- 68 -

다 금융결재원( )

금융결재원은 년 월 일부터 공인인증서비스 의 시범서비스를 실시하고 있2000 9 1 (yessign)

다 금융결재원에서 제공하는 서비스는 표 와 같다. [ 2-12] .

표 금융결재원에서 제공하는 인증서의 종류[ 2-12]

종류 구분 내용

전자거래용

인증서 개인 법인( / )

대상 개인 개인사업자 법인 단체/ , /

용도금융기관이 제공하는 인터넷 뱅킹 등의 으용서비스 및

전자상거래에서의 거래정보의 무결성 및 신원확인용

저장매체개인용 컴퓨터의 하드디스크 프로피 디스크, . IC

CARD

서버용 인증서

대상 인터넷 기반의 서비스를 제공하는 사업자

용도 인터넷 기반의 서비스를 제공 사업자의 서버실체 인증

종류등급1 본인 확인 및 대금 결재용

등급2 본인 확인용

저장매체 서비스를 제공하는서버

아 무선인터넷 기반에서의 인증 서비스. PKI

국내의 동향(1)

년대 말에 들면서 무선 인터넷의 보급이 확대되고 무선인터넷을 통한 인터넷 뱅킹 사1990 ,

이버 주식 등의 전자상거래 서비스에 대한 요구가 높아지고있다 따라서 무선인터넷을 통해.

이루어지는 전자거래에서의 인증서비스 제공이 필요로 하게 되었다 이를 위해 먼저 무선.

체계의 구축이 선행되어야 한다 표 은 무선 인터넷 인증 서비스를 위한 무선 인PKI . [ 2-13]

터넷 기술은 유럽 주도의 과 사가 제안한WAP(Wireless Application Protocol) Microsoft

를 이용한 방식이 큰 주류를 이루고 있다ME(Moblie Explorer) .

- 69 -

표 무선 인터넷 관련기술[ 2-13]

항목 WAP ME I-mode

개발주도

업체

- Nokia

- Ericsson

- Phonecorn

- Microsoft

- Qualcomm- NTT Cocomo

주요기술

- WSP, WDP, WTP

등 새로운 프로토콜

사용

등 기존- TCP/IP

의 유선 프로토콜을

이용하여 무선 인터

넷을 수행

등 기존의 유- TCP/IP

선 프로토콜을 이용하되

축약된 언어를 사용html

시장현황등- Nokia, Ericsson

이 진행Trial Test

Workstyle Server

개발

현재 약 만가입- 1.300

자

특징사실상 산업체 표준-

무선환경에 적합-

제품군- Windows

과의 연계 용이최대 사용자 확보-

현재 전세계적으로 이 무선 인터넷 프로토콜의 주도권을 가지고 있지만 의 시장 점WAP ME

유율이 점차 증가하는 추세이다.

구내에서도 무선인터넷 서비스를 시행 중에 있다 국내의 무선 통신 사용가의 약 가 무. 46%

선 인터넷 서비스를 이용하고 있는 것으로 나타났다 앞으로 이 수치는 계속해 늘어날 것이.

다.

표 국내 무선 인터넷 서비스 업체 현황[ 2-14]

- 70 -

국내에서 제공하는 무선 인터넷 서비스 역시 기반의 서비스를 제공하는 업체와 를WAP ME

기반으로 한 서비스 업체가 있다 표 는 국내 무선인터넷 서비스를 제공하는 업체의. [ 2-14]

요약이다.

- 71 -

제 장 기술 분석 및 설계목표3 SSO(Single Sign-On)

본 장에서는 일반적인 기술 및 기존 시스템들의 장단점을 비교분석한 후 본 연SSO SS0 ,

구과제에서 개발할 기반의 시스템의 설계목표를 제안한다PKI Single Sign-On .

제 절 기술1 SSO(Single Sign-On)

일반적인 시스템 구조1. SSO

일반적으로 는 그림 과 같은 구조를 가지고 있다SSO ( 3-1) .

그림 시스템의 구성요소( 3-1) SSO

에서 자체의 인증메커니즘에 의해 초기에 사용자를 인증하고 서Local authentication SSO ,

비스와 자원에 대한 정보 로그인 정보와 필요한 스크립트 권한정보 등 를 부여credential ( , )

하거나 해제한다 즉 사용자 를 정보로 매핑한다 은 사용자의. identity credential . Credential

인증에 관한 정보로 대개보안이 보장되는 데이터 저장소에 저장 관리되고 는 사용Service

자가 접속하기를 원하는 응용 프로그램이다.

- 72 -

시스템 분류2. SSO

시스템은 시스템 구조와 인증방식에 따라 분류할 수 있다SS0 .

가 시스템 구조에 따른 분류.

시스템은 시스템 구조에 따라 브로커 기반 모델 에이전트 기반 모델 토큰기반 모델SS0 , , ,

에이전트 브로커 기반 모델 게이트웨이기반 모델이 있다- , .

브로커기반 모델(1)

이 모델에서는 중앙 집중적인 인증과 사용자 계정 관리를 위한 하나의 서버가 존재하며 한

번의 인증후 브로커는 이후의 접속요청을 위해 토큰을 부여 한다.

가 구조( )

그림 브로커 기반 모델( 3-2)

- 73 -

나 구현용이성( )

커버러스 와 같은 브로커 기반 모델의 주요 문제점은 티켓을 허용하기 위해 응용(kerberos)

시스템의 서버와 클라이언트가 수정되어야 하는 것이다 특히 응용 시스템의 서버 그리고. ( )

시스템이 중앙 집중적인 구조를 가졌기 때문에 서버 컴포넌트가 다운된다면 어느 누구도 로

그인 할 수 없게 만드는 요인이 될 수 있다 이 문제로 인해 의 보급속도가 현저히 느. SSO

리므로 추후 언급될 에이전트 기반모델의 합리성을 주장하는 의견도 있다[11].

다 시스템 관리( )

접근이 제한된 중앙의 데이터베이스에 사용자의 인증정보를 저장하어 관리하기 때문에 통합

된 중앙 집중식의 계정관리가 용이하며 또한 중앙 서버를통해 인증이 이루어지기 때문에 현

재의 접속상황을 감시하고 제어할 수 있다.

라 보안성( )

응용 프로그램을 적절하게 화 함으로써 사용자는 초기 인증 후 네트워크 상에서 패스SSO ,

워드를 보내는 것 없이 자신을 인증할 수 있고 완전한 패스워드 동기화를 이룰 수 있으며

백도어의 가능성이 존재하지 않는다.

에이전트기반 모델(2)

에이전트 기반 모델은 브로커 기반 모델처럼 별도의 중앙 인증서버가 존재하지 않는 대신에

시스템과 연계된 서로 다른 응용시스템에 사용자를 자동으로 인증시켜주는 에이전트가SSO

존재하는 모델이며 에이전트를 통해 브로커 기반 모델의 단점이었던 시스템의 화 비용SSO

을 최소화는데 그 목적을 둔다.

- 74 -

이 모델을 위해서 필수적으로 요구되어 지는 부분은 사용자의 정보 로그인 정보credential (

와 필요한 스크립트 권한정보등 가 안전하게 저장되어서 관리될 수 있는 저장소이다 이 모, ) .

델은 아래와 같이 여러 가지 다양한 방법으로 구현되어 질 수 있다.

가 구조( ) Client-Side

그림 의 에이전트 기반 모델( 3-3) Client-Side

에이전트가 클라이언트에 존재하여 사용하고자 하는 시스템의 사용자 아이디와 패스워드 목

록을 가지고 자동으로 로그인하여 사용자의 인증부담을 덜어주는 방법이다 이 방법은 사용.

자의 정보 로그인 정보와 필요한 스크립트 권한정보등 가 어떠한 방식으로 저장credential ( , )

되느냐에 따라서 세 가지 방법으로 분류될 수 있다 첫 번째는 정보가 별도의. credential

저장서버에 저장되는 방법이고 두 번째는 사용자가 사용하는 나 워크스테이션이 하드디PC

스크에 저장되는 방법이고 세 번째는 사용자가 휴대할 수 있는 스마트 카드나 스마트 토큰

과 같은 휴대용 하드웨어 장치에 저장되는 방법이다 특히 중앙 서버에 저장하는 방법이나.

휴대할 수 있는 별도의 하드웨어를 적용하는 방법은 사용자가 장소에 상관없이 접속할 수

있는 사용자의 이동성 을 지원 한다(mobility) .

- 75 -

나 구조( ) Server-Side

시스템과 연계된 응용시스템의 서버에 에이전트가 존재하는 구조로서 응용시스템 고유SSO

의 사용자 인증방식과 시스템의 단일 인증방식을 따르는 클라이언트의 인증방법사이에SSO

통역자로서 존재한다 이 방법은 오프라인 티겟을 사용하는 방식의 인증을 적용할 때. PKI

적합한 구조이다 이 구조에서는 인증을 위해 별도로 중앙서버가 존재하지 않는다 대신에. .

공인된 인증기관이니 사설 인증서버를 통해서 티켓 즉 인증서를 발행 받은 후 인증서를 통,

해 중앙 서버의 개입 없이 응용 시스템 사이에 클라이언트와 인증이 이루어지게 된다.

는 인증서를 이용한 인증요청이 발생하면 인증서 기반의 인증을 한 후 저장서버에서Agent ,

사용자의 정보를 추출하여 응용 시스템이 사용하고 있는 로그온 정보를 생성한Credential

후 응용 시스템으로부터 클라이언트를 대신하여 인증을 받게 된다, .

그림 에이전트기반 모델( 3-4) Server-Side

- 76 -

다 구현용이성( )

응용 시스템에 대한 별도의 수정을 가하기 않는 대신에 에이전트를 두기 때문에 시스SSO

템으로의 전환이 쉽다.

라 시스템 관리( )

사용자의 정보 로그인 정보와 필요한 스크립트 귄한정보등 를 중앙 저장 서버에credential ( , )

저장한다면 통합된 중앙 집중식의 계정관리가 가능하다 그러나 중앙의 인증서버가 존재하.

지 않기 때문에 현재의 접속상황을 파악하거나 제어하기가 어렵다.

마 보안성( )

강력한 를 갖고 자기 자신을 인증하는 에이전트는 보안성이 뛰어나지만 그렇cryptography

지 못할 경우 악의가 있는 소프트웨어에 의해 변형되거나 대체되어지는 경우가 발생할 수

있다 사용자의 아이디와 패스워드를 중앙의 저장소에 파일등 저. (DBMS, directory server, )

장하는 방법일 경우 저장소에 저장된 자료에 대한 보안이 무너지면 시스템 내부전체의 보,

안이 무너질 수 있는 치명적인 허점을 내포하고 있다 응용시스템의 서버가 시스템에. SSO

적합하게 수정되기 않았기 때문에 기존의 인증방식으로 접근 할 수 있으므로 인증 메SSO

카니즘과의 동기화 문제와 백도어의 가능성이 존재한다.

에이전트 브로커 기반 모델(3) -

브로커 기반 모델의 장점인 중앙 집중식 관리와 에이전트 기반 모델의 장점인 유연성을 결

합한 모델이다 이 모델은 브로커기반의 모델을 적용할 때 응용 시스템의 화 비용이 크. SSO

거나 불가능한 경우를 위한 구조이다.

- 77 -

가 에이전트 구조( ) Server-Side

그림 에이전트 브로커 기반 모델( 3-5) Server-Side -

이 구조에서 에이전트는 응용시스템의 서버쪽에 존재하여 인증서버가 넘겨준 정credential

보 로그온 정보 혹은 티켓 를 바탕으로 사용자를 인증하고 중앙에서 통합 정의된 접근권한( )

을 각자의 고유한 권한으로 변환한다 이 구조는 대체적으로 브로커기반 모델의 확장성을.

높이기 위해 적용되어 지는 구조다.

나 구조( ) Client-Side Agent

이 구조에서 에이전트는 클라이언트에 존재하며 응용 시스템에 인증요청이 발생할 경우 인,

증서버로부터 정보 로그인 정보와 필요한 스크립트 권한정보등 를 받아서 응용credential ( , )

서비스에 자동으로 접속한다 에이전트기반 모델의 구조에서 중앙 저장서버를. Client-Side

적용하는 경우와 비슷하지만 이 구조와의 중요한 차이점은 중앙에서 사용자의 접속을 감시

하고 제어하는 인증서버가 존재하시 않는 다는 것이다.

- 78 -

그림 에이전트 브로커 기반 모델( 3-6) Client-Side -

다 구현용이성( )

순수 에이전트기반 모델과 같다.

라 계정관리( )

접근이 제한된 중앙의 데이터베이스에 사용자의 정보를 저장하기 때문에 통합된 사용자 계

정관리가 용이하며 또한 중앙의 인승서버를 통해 인증이 처리되므로 현재의 접속상황을 감

시할 수 있고 제어할 수 있다.

마 보안성( )

에이전트는 네트워크상에서 패스워드를 보내는 것 없이 자신을 인증할 수 있으나 응용시스

템의 서버가 시스템에 적합하게 수정되기 않았기 때문에 기존의 인증방식으로 접근SSO

할 수 있으 로 인증 메카니즘과의 동기화 문제와 백도어의 가능성이 존재한다, am SSO .

- 79 -

게이트웨이 기반 모델(4) (Gateway)

이 모델은 커버러스와 같이 네트워크상에서 기능을 하는 것이 아니라 대문 자체watch dog

가 되는 솔루션이다 즉 이 구조는 게이투웨이나 프록시 형태의 강력한 암호화 인증서버를.

두어서 도메인으로 들어오는 네트워크 흐름을 여과하면서 기능을 지원하는 구조이며SSO

특히 에 적용하기에 적합한 구조이다WEB SSO .

가 구조( )

게이트웨이 형태의 인증서버는 네트워크 내에서 강력한 에 기반하여TCP/IP cryptography

동작한다 이 모델에서는 모든 서비스가 신뢰성있는 네트워크 세그먼트인 게이트웨이 뒤에.

존재하고 클라이언트는 서비스에 접근을 허용하는 게이트웨이에 자신을 인증한다 게이트웨.

이는 클라이언트의 에 근거하여 인증을 하기 때문에 를 기본으로 하는 규칙베이스가 클IP IP

라이언트의 아이디와 함께 게이트웨이에 구축되어 지고 이를 통해 의 구현이 가능해진SSO

다 즉 게이트웨이는 클라이언트의 인증후 클라이언트의 아이디를 기억하고 있다가 서비스. ,

접근 요청이 들어오면 재인증없이 접근을 허용한다 여기서 게이트웨이는 서비스로 가는 모.

든 패킷을 검사하고 변환할 수 있기 때문에 패킷의 흐름을 검사하다가 서비스에 적절한 인

증정보로 패킷을 변환할 수 있으며 이는 응용 프로그램 자체의 수정을 요구하지 않는다.

- 80 -

그림 게이트웨이 기반 모델( 3-7)

나 구현용이성( )

응용 시스템의 화 비용이 크지 않으므로 구현이 용이하다SSO .

다 시스템 관리( )

게이트웨이가 하나일 경우 브로커기반의 모델처럼 관리가 쉽지만 게이트웨이가 여러 개일,

경우 동기화가 필요하다, .

라 보안성( )

방화벽 위치에 있기 때문에 예를 들면 같이 방화벽에 가해지는 공격들이 인SYN-flooding

증서버에도 영향을 끼칠 가능성이 있으며 방화벽이 갖는 고유의 오버헤드가 존재한다.

- 81 -

표 은 시스템 구조에 따른 시스템의 분류를 나타낸다[ 3-1] SSO .

표 시스템 구조에 따른 시스템 분류[ 3-1] SSO

모델 장점 단점 예

브로커

기반

중앙 집중식 시스템▶

관리를 통한 효율성 증가

백도어가 존재하지 않음▶

기존 어플리케이션 수정 필

요 fault-tolerant

Kerberos

Sesame

에이전트

기반

기존 응용 시스템의 최소한

수정

백도어가 존재함▶

패스워드 동기화 문제▶

에이전트 신뢰성 문제▶

의I/O Software

SecureSessionM

에이전트

브로커

기반

중앙 집중식 시스템▶

관리를 통한 효율성 증가

기존 어플리케이션의▶

최소한 수정

시스템이 복잡함▶

관리 대상 컴포턴트▶

증가

백도어가 존재함▶

패스워드 동기화 문제▶

하지 않음fault-tolerant▶

의Axent ERM

RSA Keonⓡ

게이트웨이

기반

방활벽수준의▶

접근통제를 통해 보다

강화된 보안성제공

중앙 집중식 시스템▶

관리를 통한 효율성 증가

기존 어플리케이션의▶

최소한 수정

다수의 게이트웨이▶

존재시 이들 사이의 동기화

필요

방화벽이 갖는 문제점▶

포함

백도어가 존재함▶

패스워드 동기화 문제▶

의Cy1ink

Private Wire

나 인증방식에 따른 분류.

시스템은 인증방식에 따라 로그온 자동화 모델 토큰기반 모델로 분류할 수 있다SSO , [8].

패스워드 동기화 모델(1)

솔루션은 아니지만 패스워드 동기화 모델은 시스템과 응용프로그램마다 다른 여러 개SSO

의 사용자 아이디와 패스워드를 하나로 통일시켜서 사용자로 하여금 단지 하나의 사용자 아

이디와 패스워드를 기억하도록 하는 것이다 이 모델에는 서버에이전트가 존재하여 패스워.

드의 변화가 감지될 때 다른 시스템의 패스워드도 연속하여 변화시키는 기능을 담당한다, .

- 82 -

즉 사용자에게는 패스워드의 번화가 투명하게 보여진다.

가 구축사례( )

PassGOTM의 InSync[21].

나 와의 차이점( ) SSO

와 달리 사용자가 기존의 방법처럼 사용자가 여러번 로그온해야 한다SSO .

다 장점( )

구현이 간단하며 서버나 클라이언트의 어떠한 변화도 요구하지 않는다.

라 단점( )

여러 번 로그인 해야 하며 패스워드가 노출되면 치명적이다.

로그온 자동화 모델(2)

이 모델은 사용자의 정보를 별도의 저장소에 저장하여 기능을 제공한다credential SSO .

이 모델은 패스워드 동기화에 비해 보안이 뛰어나다 즉 패스워드 동기화에서는 여러 시스.

템에 대해 동일한 패스워드를 지정하였지만 로그온 자동화에서는 그렇지 않다.

가( ) Workstation Scripting

이 방법은 사용자의 정보 로그인 정보와 필요한 스크립트 귄한 정보등 를 나credential ( , ) PC

워크스테이션의 하드디스크 내에 저장하여 이를 통해 기능을 구현한다SSO .

구조①

그림 참조( 3-3)

- 83 -

장점②

기존의 시스템이나 응용프로그램에 대해 최소한의 수정을 요구한다.

단점③

사용자의 중요한 정보가 클라이언트 컴퓨터 내에 존재하기 때문에 해킹이나 악의적인 정보

변경의 우려가 있고 사용자가 여러 컴퓨터를 사용할 경우 각각의 컴퓨터마다, credential

정보를 저장하여야 하기 때문에 스크립트의 일관성유지 문제도 발생한다 또한 응용 시스템.

서버가 화되지 않았기 때문에 백도어 문제와 패스워드 동기화 문제가 발생할 수 있다SSO .

나( ) h/w token

이 방법은 사용자의 정보 로그인 정보와 필요한 스크립트 권한정보등 를 스마트credential ( , )

카드나 토큰에 저장하여 이를 통해 기능을 구현한다SSO .

구조①

그림 참조( 3-3)

장점②

기존의 시스템이나 응용프로그램에 대해 최소한의 수정을 요구하며 별도의 휴대용 하드웨어

저장장치에 정보를 저장하기 때문에 해킹이나 정보변경을 방지하는 강력한 보안credential

과 정보의 일관성을 제공한다.

- 84 -

단점③

별도의 하드웨어 장치 비용이 추가되며 응용 시스템 서버가 화되지 않았기 때문에 백SSO

도어 문제와 패스워드 농기화 문제가 발생할 수 있다.

다( ) Repository Server

이 방법은 사용자의 정보 로그인 정보와 필요한 스크립트 권한 정보등 를credential ( , )

나 디렉토리서버와 같은 별도의 저장서버에 보관하여 이를 통해 기능을 구현한DBMS SS0

다 이 방법에서는 사용자의 중요한 정보인 정보가 네트워크를 통해 전송되기 때. credential

문에 네트워크상에서 강력한 보안이 보장되는 프로토골 및 암호화라이브러리가 함께 제공되

어야 한다.

구조①

그림 참조( 3-3)

장점②

기존의 시스템이나 응용 프르그램에 대해 최소한의 수정을 요구하며 하나의 저장서버에서

정보를 관리하기 때문에 동합적인 계정관리가 가능하다credential .

단점③

저장서버에서 문제가 발생할 경우치럼 하시 않으며 응용시스템 서버가fault-tolerant SSO

화 되시 않았기 때문에 백도어 문제와 패스워드 동기화 문제가 발생할 수 있다.

라( ) Single Authentication Server

이 방법은 사용자의 정보 로그인 정보와 필요한 스크립트 권한 정보등 를 인증credential ( , )

서버의 저장소에 저장하며 인증서버를 통해 인증과정을 통합 관리함으로써 기능을 구, SSO

현한다.

- 85 -

사용자는 클라이언트에 존재하는 에이전트를 이용하여 인증서버에 인증을 하고 인증서버는

사용가능한 서비스리스트를 에이전트에게 부여한다 사용자가 서비스를 선택하면 에이전트.

는 인증서버로부터 서비스에 접속을 하기 위한 정보를 받는다 에이전트는 그것credential .

을 이용하여 자동으로 서비스에 접근한다 로그인 자동화시스템에 중앙 집중적인 계정관리.

도구를 추가하여 효율적인 사용자관리를 할 수 있다 이때 사용자계정과 권한을 중앙에 있.

는 보안이 보장된 저장소에 저장하여 사용자계정의 권한관리를 허용할 수도 있다.

구조①

에이전트 브로커 기반 모델 중 그림 과 같은 구조와 같다- ( 3-6) Client-Side .

구축사례②

의Novell v-GO [17].

장점③

인증서버를 통한 중앙 집중적인 관리가 가능하며 기존의 시스템이나 응용 프로그램에 최소

한의 수정을 요구한다 저장서버에서 을 관리하기 때문에 통합적인 계정관리가. credential

가능하다.

단점④

인증관리가 하나의 인증서버에 집중되어 있기 때문에 하지 않고 응용 시스템fault-tolerant

서버가 화되지 않았기 때문에 백도어 문제와 패스워드 동기화문제가 발생할 수 있다SSO .

- 86 -

토큰기반 모델(3)

효율성과 경제성이 도입의 주된 이유였다면 로그온 자동화 모델로도 충분하지만 로그SSO

온 자동화 모델은 응용 시스템 서버가 화 되는 것을 배제하였기 때문에 백도어 문제와SSO

패스워드 동기화와 같은 보안상의 문제와 또한 저장서버나 인증서버가 존재하는 경우 로그,

온을 위한 정보가 네트워크 상에서 전송되기 때문에 정보의 유출 위credential credential

험성을 갖게 된다 따라서 로그온 자동화 모델이 제공하는 수준 이상의 보안성이 요구되어.

질 경우 보다 강력한 보안체계를 갖는 인증모델이 개시되이야 한다 토큰기반의 인증모델, .

은 인증음 위해 사용자의 패스워드 같은 정보대신에 응용 시스템을 위한 토근을credential

통해 로그온 하도록 하는 모델이다 이 모델의 주된 특징은 사용자의 정보가 네. credential

트워크 상에서 전송되지 않는다는 점과 응용 시스템 서버를 화하거나 응용 시스템 서버SSO

에 을 위한 를 두는 것이다 즉 의 범위가 로그온 자동화 모델과 달리 응용SSO Agent . SSO

시스템 서버까지 확장된다 토큰기반의 인증은 두가지로 나뉘어 진다 첫번째는 토큰을 온. .

라인으로 발행하는 온라인 구조이고 두 번째는 토큰을 오프라인으로 발행하는 오프라인 구

조이다.

가 온라인 구조( )

이 구조는 사용자가 인증서버에 초기인증을 한 후 응용 시스템에 접근 요청을 하게 되면,

인증서버가 응용 시스템 서버에 대한 토큰을 온라인으로 발행하고 사용자로 하여금 이 토큰

을 통해서 응용 시스템에 로그온 하도록 하는 모델이다.

구조①

브로커 기반 모델의 그림 참조( 3-2)

- 87 -

구축사례②

커버러스, SESANIE, OSF/DCE, Window2000

장점③

인증서버를 통한 중앙 집중적인 관리가 가능하다 토큰을 이용하여 인증을 하기 때문에 패.

스워드가 네트워크 상에서 전송되지 않으며 백도어가 존재할 수 없다 통합적인 계정관리를.

통해 비교적 완전한 패스워드동기화를 유지할 수 있다.

단점④

인증관리가 인증서버에 집중되어 있기 때문에 하지 않고 응용 시스템 서버가fault-tolerant

화되어야 하기 때문에 시스템의 수정비용이 크다SSO .

나 오프라인 구조( )

이 구조는 사용자로 하여금 공인된 인증기관이나 사설 인증서버를 통하여 인증서 형태의 토

큰을 발급 받도록 하여 추후 응용 시스템에 대한 사용자 인증에 사용할 수 있도록 하는 구

조이다 이 구조는 온라인 구조와 달리 응용 시스템에 접속을 위해 중앙의 인증서버에서 온.

라인으로 토큰을 발급 받지 않기 때문에 사용자 인증을 위한 중앙 인증서버의 개입이 필요

하지 않다 따라서 온라인 구조와 같이 중앙서버에 집중된 작업부하를 분산할 수 있다 그. .

러나 발급된 인증서의 유효성을 검증하기 위한 별도의 메카니즘이 있어야 한다 이 구조는.

기반의 인증에 적합한 구조다PKI .

- 88 -

구조①

그림 오프라인 토큰기반 모델( 3-8)

구축사례②

Netscape SuiteSpot[16].

장점③

인증서 토큰 를 이용하여 인증을 하기 때문에 패스워드가 네트워크 상에서 전송되지 않으며( )

백도어가 존재할 수 없다 통합적인 계정관리를 통해 비교적 완전한 패스워드 동기화를 유.

지할 수 있다 오프라인으로 토큰이 발급되기 때문에 중앙 인증서버의 개입없이 사용자 인.

주이 이루어 질 수 있으며 이를 통해 중앙 인증서버로 집중되던 작업부하를 분산시키고 농

시에 한 특성을 갖게 된다fault-tolerant .

- 89 -

단점④

응용 시스템 서버가 화되어야 하기 때문에 시스템의 수정비용이 크며 오프라인으로 인SSO

증서 토큰 를 발급하기 때문에 인증서의 유효성을 보장할 수 있는 별도의 메카니즘이 필요( )

하게 된다.

다 에이전트 적용( )

기존의 응용 시스템에 토큰기반의 구조를 적용하려 한다면 응용 시스템 특히 서버의 수정이

불가피하며 경우에 따라서 그 비용이 크거나 불가능할 상황이 발생하게 된다 이러한 문제.

를 해결하기 위해 에이전트를 적용한다 에이전트는 토큰기반의 인증을 수행하여 사용자의.

유효성을 검증한 후에 사용자를 대신하여 응용 시스템에 인증을 하는 역할을 수행한다 에.

이전트를 통해서 시스템을 화하는 비용은 직접 시스템을 수정하는 비용에 비해Legacy SSO

상대적으로 적다 에이전트는 근본적인 통합이 아니기 때문에 기존 방법을 이용해 사. SSO

용자 인증을 하거나 사용자 정보를 수정할 수 있는 백도어와 패스워드 동기화 문제가 존재

한다 하지만 의 범위를 응용 시스템 서버까지 확장하는데 그 의미가 있다. SSO .

구조①

그림 그림 참조( 3-4) ( 3-5) .

구축사례②

RSA Keonⓡ

장점③

에이전트의 적용을 통해 시스템의 확장성을 향상시켰다 의 범위를 최소한 응용SSO . SSO

시스템 서버까지 확대하였다.

- 90 -

단점④

근본적인 통합은 아니다 백도어와 패스워드 동기화문제가 여전히 존재한다SSO . .

시스템 구현시 고려사항 및 체크포인트2. SSO

가 구현시 고려사항. Secure SSO

초기인증방식(1)

기존의 아이디 패스워드 방식에 비교하여 더욱 강력한 인증을 제공하는 스마트카드 생체인/ ,

식 질의 응답 등의 방식을 고려해야 한다, / .

단일 인증서버 데이터베이스는 유일한 공격대상(2) /

이 저장될 인증서버의 저장소는 견고하고 안전하게 보호되어야 한다 최소한credential .▶

모든 아이디 패스워드 로그온스크립트등은 암호화되어서 저장되며 관리되어야 한다/ , .

인증서버는 네트워크에서 발생되는 공격으로부터 방화벽수준의 보호를 받아야 한SSO▶

다.

단일 인증서비스 문제(3) - fault-tolerant

인증서버에 문제가 발생할 경유 아무도 로그온 할 수 없는 상황이 나타날 가능성이 존,▶

재하는가 이 경우 어떻게 대체할 것인가? ?

인증서버는 되거나 복제되어서 계속적인 서비스를 제공할 수 있어야 한다mirror .▶

- 91 -

시스템 관리자는 유사시를 대비하여 백도어 로그온 능력이 있어야 한다.▶

나 구현시 체크포인트 사용자 측면. Secure SSO ( )

시스템 구축시 현존하는 시스템 환경에 따라 적절한 솔루션을 결정하여야 한다SSO .

어떤 모델로 구축할 것인가(1) ?

앞서 언급한 모델중 어떤 것을 선택할 것인가 로그인자동화모델 토큰기반모델? ,▶

응용 시스템 서버의 수정이 허용될 경우와 그렇지 않을 경우에 따라 좌우된다.▶

지원 플랫폼(2)

시스템 구축을 위해 어느 정도의 비용이 드는지 기존에 구축된 시스템을 업그레이드 할‘ ', '

것인지 에 대한 중요한 선택기준이 된다' .

관리 구조(3)

시스템 관리 인터페이스와 원격관리능력등이 구축하고자 하는 사이트의 관리정책에 얼마나

적합한지와 시스템 교육기간은 중요한 요소이다.

백업구조(4)

모든 사용자에 대한 유일한 관리데이터는 보호되어야 하며 이를 위한 백업체계가 존재해야

한다.

로그와 오류보고(5)

로그와 오류 및 예외 보고 감사자료 추적기능을 제공해야 한다, .

- 92 -

현재 보안시스템에 대한 인터페이스(6)

만일 구축사이트에서 대규모의 인증 데이터베이스를 가지고 있다면 이들 제품과 용이SSO

하게 연계하기 위해서 표준화된 인터페이스가 제공되어야 한다.

인증구조(7)

보다 강력한 초기인종을 위해 기존의 아이디 패스워드 외에 일회용패스워드 질의 응답 스/ , / ,

마트카드 생체인식등을 지원할 수 있어야 한다 또한 인증후 시간제한기능을 제공해야 하, .

고 특정 사건발생 후 재인증을 할 수 있어야한다.

양방향인증(8)

클라이언트가 응용 시스템 서버를 인증할 수 있고 응용 시스템 서버 또한 클라이SSO SSO

언트를 인증할 수 있어야 한다.

패스워드(9)

사용자의 패스워드 변경기능을 설정 비설정 할 수 있는 선택기능을 제공해야 한다/ .▶

사용지가 주기적으로 패스워드를 변경하도록 하는 기능이 있어야 한다.▶

강력한 패스워드 제어가 이루어져야 한다.▶

암호화 기능(10)

암호화된 로그온 트래픽을 제공해야 한다.▶

- 93 -

시스템이 관리하는 중요 자료들은 적절히 암호화되어서 관리되어야 한다.▶

암호화 알고리즘은 공인된 알고리즘이어야 한다.▶

다 비용에 관한 측면.

제품 자체에 대한 비용분만 아니라 제품이 제공하는 솔루션이 필연적으로 수반하는 여러 가

지 비용요인들이 있다.

현존하는 시스템과 응용시스템들의 수정여부 수정의 비용은- ?▶

관리 기능이 얼마나 많이 새로워 졌으며 관리정책의 재수립이 필요한가?▶

장비비용 새로운 서버가 필요한가 혹은 현존하는 워크스테이션들이 업그레이드를 해- ?▶

야 하는가?

소프트웨어 배포 클라이언트 혹은 업그레이드된 사용자 인터페이스가 전체적으- S/W▶

로 배포되어야 하는가?

제품이 적절한 시기에 출시되어 질 수 있는가?▶

교육비용 관리자는 새로운 시스템을 위해 비싼 교육을 받아야 하는가- ?▶

- 94 -

제 절 기존의 기술2 SSO

절에서는 기존의 대표적인 기술인 기반의 커버러스와SSO PKI SESAME, RSA Keonⓡ,

기술을 중심으로 의 기술을 비교분석하고 최근의 국내외 업계동향Netscape SuiteSpot SSO

을 기술한다.

기반의 커버러스1. PKI

공개키 암호의 인기는 커버러스의 확장에 강한 동기부여를 해왔으며 그 결과 커버러스를 공

개키 환경으로 확장하는 방법이 활발히 제시되어 왔다.

은 공개키 기반의 환경과 커버러스의 연계를 목표로 한다 은 사용자PKINIT . [23]. PKINIT

로 하여금 인증서를 사용하여 에 초기인증을 할 수 있도록 하였다KDC .

는 클라이언트가 의 필요성을 제거하면서 직접 서버에 접속하여 인증을 받도록PKDA KDC

하였다 클라이언트와 서버가 초기 공개키기반의 인증에 함께 참여하여서 인증을 분산화했.

고 여기서 응용서버는 처럼 동작하고자신을 위한 서비스 티켓을 발행한다TGS [22].

은 의 필요성을 제거하면서 커버러스 티켓의 장점을 그대로 유지한 의 아PKAPP KDC PKDA

이디어를 를 이용하여 기존 커버러스의 최소 수정으로 구현하는 것에 목적을 두었PKINlT

디 는 이라는 의 기능을 하는 로컬 프로세·[26]. PKAPP LTGS(Local Ticket Granting) TGS

스로 클라이언트로 하여금 를 이용하여 인증을 받도록 하고 서비스티켓을 발행하여PKINIT

준다 는 공개키를 사용하여 인증이 가능하도록 커버러스를 확. PKCROSS[25] cross-realm

장한다 여기서 지원하는 방식은 에 속하면서 신뢰된 공개키로 암호화한. KDC cross-realm

비밀키를 전송한다.

- 95 -

가. PKDA

기존 커버러스의 경우 한 의 모는 들은 공유된 대칭키를 사용해야 한다 만, realm principal .

일 가 해킹당할 경우 대칭키가 공격자에게 누설될 수 있기 때문에 모두 취소되어야 하KDC ,

고 새로운 대칭키로 교체되어야 한다 이 비용은 대칭키를 사용하는 커버러스의 커다란 부.

담이 된다 는 기존의 커버러스인증과 공개키 암호의 연계를 통해 커버러스의 이러한. PKDA

문제를 해결한다[22].

인증에서 의 역할(1) trusted intermediary

보안과 확장성 측면에서 많은 연구가 되었으나 중장 집중된 는 여전히 남아 있었다KDC .

는 중앙 집중된 를 배제한다 는 서비스티켓이 요구될 때마다 공개키를 사PKDA KDC . PKDA

용할 것이다 이들 동작은 클라이언트와 서버사이에 분산되어서 로의 집중을 피한다. KDC .

즉 의 필요성을 제거하였다 표 은 커버러스와 공개키 기반의 구조에서KDC . [ 3-2] trusted

의 역할을 비교하였다intermediary .

프로토콜(2) PKDA

그림 는 의 인증프로토콜이고 표 는 인증기호이다 계안된 프로토콜에( 3-9) PKDA [ 3-3] . PKDA

서 커버러스의 는 배제된다KDC .

클라이언트는 직접 응용서버와 통신하면서 응용서버의 인증서를 요청하고 중앙 집중된 매개

자와 인증서버나 같은 의 접촉없이 세션티켓을 얻을 수 있다 가능한 서비는 인( TGS ) . PKDA

증서를 서비스할 뿐만 아니라 자신에 대한 것일지라도 의 기능을 갖고 세션티켓을 발TGS

행할 수 있다 프로토콜은 완전히 분산된 방법으로 실행되어 질 수 있으며 과. PKDA SSL

같은 공개키기반의 다른 방법들보다 더욱 많은 연산오버헤드를 요구하지 않는다.

- 96 -

표[ 3-2] trusted intermediary

항목 커버러스 공개키기반 시스템 비고

trusted

intermediaryKDC CA

trusted intermediary

의 확장성이 중요한

도전이다 이 문제가.

해결되지 않는다면 인

증지연이 발생하거나

인증의 신뢰성이 떨어

credential

상대적으로 짧은 생

명주기의 credential

가 클라이언트(TGT)

에세 부여된다. KDC

는 지속적으로 짧은

생명주기의 를TGT

갱신해야 하는 문제

와 클라이언트가 새

로운 서버에 접속을

요청할 때 마다 개입

되어야하는 부담을

갖고 있다 전형적으.

로 취소된 credential

에 대한 유일한 보호

방법은 의 짧은TGT

생명주기이다.

는 상대적으로 긴CA

생 명 주 기 의

인증서 을credential( )

발급한다 클라이언트.

와 서버가 인증서를 갖

는다면 이들은 의CA

개입없이 서로를 인증

할 수 있다 그러나 인.

증서가 상대적으로 긴

수명을 가졌기 때문에

취소된 인증서를 응용

서버에게 알려야 하며

이것은 인증서 사용시

에게 유효성을 검증CA

하도록 하는 것과 주기

적으로 을 모든 서CRL

중앙 집중된 부담을

해결하기 위한 요소는

두 방법에 따라 다르

다 는 클라. KDC/TGS

이언트가 서버에게 요

구하는 생명주기를 통

해 조정한다 는. PKI

클라이언트가 을CRL

얻기 위해 얼마나 자

주 와 접촉하는가CA

를 나타내는 빈도수를

통해 조정한다.

확장성

을 서로 다pnncipal

른 서버에게 지원받

는 으로 나눔으realm

로써 해결되며 이는

인증과cross realm

는 각 에TGS realm

서 복사되어 그

내에서 모든realm

인증요청을 처리한

다 여기서 하나의.

는 마스터로 선KDC

언되어 모든 공유비

에서는 이증서 체PKI

인을 통해 서로 다른

가 발행한 인증서를CA

검증하도록 한다 실제.

로 같은 회사VeriSign

는 하나의 가 수십CA

만의 인증서를 처리할

수 있는 능력을 보여

주었다.

를 커버러스와 연PKI

계시킴으로써 수백만

의 을 갖는principal

하나의 커버러스

을 구축하는 것realm

이 가능하다. cross

없이realm ...

- 97 -

그림 프로토콜( 3-9) PKDA

표 인증 프로토콜 기호[ 3-3] PKDA

기호 설명

S Server

C Client

Krand 임의로 생성한 대칭키

Px 구성요소 의 공개키X (S, C)

Px-1 구성요소 의 개인키X (S, C)

PKCx 구성요소 의 인증서X (S, C) X.509 v3

Tauth 초기인증요청기간

Kc.s 서비스티켓

Ps 서버만이 아는 대칭키

나. PMNIT

의 주된 목적은 공개키 기반의 환경과 커버러스와의 연계를 하는 것이다 즉PKINIT .

은 초기인증에서 클라이언트로 하여금 공개키 인증서를 사용하여 에 인증하고PKINlT KDC

를 받을 수 있도록 한다 이를 위해 은 와 는 동일하게 유지TGT . PKINIT AS-REQ AS-REP

하면서 새로운 을 사용하여 를 수행한다preauthentication-data type PK exchange [23].

- 98 -

사용자는 공개키나 혹은 대칭키를 이용하여 인증을 요청할 수 있다 만일 공개키암호가 사.

용되면 필드에 저장되어서 전송된다preauthentication .

그림 을 이용한 초기인증( 3-10) PKINIT

표 인증 프로토콜 기호[ 3-4] PKINIT

기호 설명

S Server

C Client

Krand 임의로 생성한 대칭키

Px 구성요소 의 공개키X (S, C)

Px-1 구성요소 의 개인키X (S, C)

PKCx 구성요소 의 인증서X (S, C) X.509 v3

cusec인증요청기간

ctime

nonce 임의로 생성한 난수

pachecksu

m무결성검증을 위한 체크섬

- 99 -

그림 에서 사용자 인증과정( 3-11) PKINIT

- 100 -

다. PKTAPP

는 중앙 집중된 의 필요성을 제거하면서 커버리스 티켓의 장점을 유지하였다PKDA KDC .

는 를 적용하여서 에서 소개된 아이디어를 커버러스의 대폭적인 수PKTAPP PKINIT PKDA

정없이 구현하는데 그 목적을 둔다 즉 클라이언트는 를 사용하여 에 개입없이. PKlNIT KDC

직접 응용서버에 인증을 한다[26].

(1) LTGS (Local Ticket Granting Server)

는 응용서버에 내장되어 있거나 혹은 서버 보통 응용서버와 같은 기계에LTGS stand-aIone (

존재한다 의 형태를 가지며 와 동반하는 와.) PKINIT preauthentication data AS-REQ

를 처리한다 클라이언트가 를 에 제출하면 는 응용서버를 지AS-REP . AS-REQ LTGS LTGS

정하고 서비스티겟을 가져온다.

결국 브로커기반의 모델에서 에이전트 모델로의 변환을 시도하여 확장성을 증가시키려고 한

다 이를 위한 최대 고려사항은 의 티켓발행 기능을 어떻게 로 분담하느냐 이다. TGS LTGS .

각 들의 정보 티겟정책 서비스키등 를 갖고 이에 적당한 티켓을 발행하기 때문에principal ( , )

이 정보를 가 어떻게 접근할 수 있는가를 고려해야한다LTGS ,

독립된 서버형태의(2) LTGS

이 형태의 는 같은 기계에 존개하는 응용서버를 지원하는 독립된 프로세스이다 이LTGS .

모델을 적용할 경우 공개키기반이며 커버러스로 구성된 이기종의 환경에서 커버러스의 확,

장이 용이하다 는 잘알려진 번 와 같은 포트를 사용하며 각 응용 서비스와. LTGS (88 -KDC )

대칭키를 공유한다.

- 101 -

그림 독립된 프르세스형태의( 3-12) LTGS

응용 서버에 내장된(3) LTGS

이 모델은 클라이언트가 직접 응용서버에 인증을 하지만 응용프로그램이 수정되어야 하는

단점이 있다 는 응용서버와 같은 포트를 쓰거나 혹은 잘알려진 커버러스의 포트를. LTGS

쓰기도 한다.

그림 서버에 내장된( 3-13) LTGS

- 102 -

라. PKCROSS

인증을 위해 계정관리자는 인증을 허용하기 원하는 다른 모든 즉cross-realm realm(

임 들의 키를 관리해야 하거나 들의 계층화된 구조를 이용해야n(n-11) ) cross-realm realm

한다 결국 키의 관리가 관리자에게는 커다란 부담으로 남게 되었다. cross-realm .

는 키관리의 부담을 최소화하기 위하여PKCROSS cross-realm PKI(Public Key

를 이용한다 인증을 위한 공유키는 잠시 동안 설정되어 지며Infrastructure) . cross-realm

은 클라이언트가 인증을 요구할 때 다시 되돌아 오는 정책정보remote realm cross-realm

를 발행한다 이 방법은 클라이언트에게는 투명하여 오직 만 수정하면 된다. KDC .

목적(1)

커버러스의 키들을 구축하는데 필요한 관리를 단순화한다cross-realm .▶

클라이언트와 응용서버의 수정을 피한다.▶

원격 가 사이의 공유된 키와 클라이언트가 제시하는KDC KDC cross-realm▶

티켓에 관한 정책을 제어하도록 한다cross-realm .

사이에 공유되는 키의 상태를 가 유지할 필요성을 제거한다KDC KDC .▶

대칭의 키 구축을 위한 공개키 프로토골을 제공하기 위해 을 적용cross-realm PKINIT▶

한다.

프로토콜(2)

클리이언트는 이미 를 갖고 있다고 가정한다 인증을 하기 위해 클라이언TGT . cross-realm

트는 기존의 커버러스에서 처럼 동작하면 된다.

기호▶

KDC_1 .......... local KDC

- 103 -

KDC_r .......... remote KDC

가 에게 발행하는 티켓XTKT_(1,r) ...... remote KDC local KDC PKCROSS

가 클라이언트로 하여금 에게 제시하기 위하여TGT_(c,r) ...... local KDC remote KDC

클라이언트에게 발행하는 cross-realm TGT

과정▶

그림 의 인증과정( 3-14) PKCROSS cross-realm

- 104 -

2. SESAME

유럽에서는 커버러스 처럼 적절한 제품이 존재하지 않았기 때문에 이를 위해 프SESAME

로젝트가 추진되었다 프로젝트의 목적은 인증과 접근통제 관리를 위한 프로토골. SESAME

을 정의하고 구현하는 것이다 년에 가 출시된 이후로 다양한 테스터들의 의견을. 1994 V2

수렴하고 공개키 지원을 추가하여 년에 가 출시되었으며 년에 커버러스 부분1995 V3 1996

을 추가하여 가 출시되었다V4 [27][28][30].

는 을 사용해서 역할기반의 접근통세 구조를 구현하였다SESAME Attribute Certificate .

은 에 서 으로 채택되었다Attribute Certificate V4 ECMA PAC[32] . Attribute Certificate

은 전자서명된 토큰의 형태를 갖으며 사용자의 와 응용 시스템에 접속할 수 있도록Identity

허용된 역할속성을 포함한다 각각의 응용 시스템 서버는 접근통제리스트 를 생성 및. (ACL)

관리하고 있으며 이들 접근통제리스트 는 해당 응용 시스템을 실행시키도록 허용된 역(ACL)

할속성을 나타낸다 사용자가 응용 시스템에 접속하고자 할 때 그는 부가적인 암호정보와.

함께 을 응용 시스템 서버에게 전송한다 을 수신한 응용 시스템 서버는 의PAC , PAC PAC

전자서명을 검증한 후 을 전송한 사용자가 내에서 언급된 사용자와 일치하는지 그, PAC PAC

리고 그의 역할이 해당 시스템에 접속 가능한 것인지를 체크한다 이 과정이 모두 성공적으.

로 테스트되면 접속은 승인된다.

가 구성 인소 및 인증절차.

구성요소(1)

그림 는 구조의 구성요소를 나타내고 있다 의 핵심부분은 세 개의( 3-15) SESAME . SESAME

온라인 서버와 하나의 데이더 베이스로 구성된다.

- 105 -

세 개의 온라인 서버는 서버와AS(Authentication Server) PAS(Privilege Attribute

서버 서버이다Server) , KDS(Key Disthbution Server) .

그림 구조( 3-15) SESAME

는 사용자의 인증을 담당하며 는 사용자의 요청이 발생할 때 적절한 을 생성하AS PAS PAC

는 역할을 담당하며 생성된 을 사용자의 에 반환한다PAC SACM . SACM(Secure

은 구성자간의 통신에 대한 보안을 담당하며 에Association Context Manager) GSS-API

의해 지원된다 는 도메인 내의 응용시스템과 통신할 수 있도록 하는 키를 생성하고 또. KDS

한 외부 도메인의 응용시스템을 위해 키를 해석한다 공개키 기술이 허용된다면 의 필. KDS

요성은 없어진다 는 와 가. SMIB(Security Management Information Base) AS PAS, KDS

필요한 모든 보안 정보를 저장하는 저장소이다 는 자신에게. PVF(PAC Validation Facility)

전송된 의 유효성을 검증하는 응용 시스템의 일부분이다PAC .

- 106 -

인증절차(2)

는 인증 를 통해 를 호출하여 사용자의 인증을 요청한다User Sponsor API APA client .①

인증방식은 패스워드 기반의 방식과 공개키를 이용한방식이 있다 공개키를 적용할 경우. ,

사용자의 개인키를 통해서 인증요청을 전자서명하여 에 보내고 는 사용자의 공개키를AS AS

통해 선자서명을 검증한다.

는 사용자를 인증한 후 사용자의 적절한 티켓 이것은 커버러스의 와 같AS , PAS ( TGT②

다 을 생성하고 커버러스의 제어 데이티와 함께 에게 반환한다 여기서 패스워.) APA client .

드 기반의 인증일 경우에는 티겟의 에 임의의 값이 삽PAS authorization data field PPID

입되며 공개키 기반의 인증일 경우에는 가 사용하는 인증서의 식별자가 삽입된다AS .

초기인증시 사용자에 의해 이 지정되거나 혹은 의role name PAC_manda_tory_at_login③

인증옵션이 지정될 경우에는 초기인증시에 요청이 발생되며 그렇지 않을 경우에는 초PAC

기인증후에 응용 시스템에 접근할 때 요청이 발생된다 요청이 발생되면PAC . PAC User

는 을 에게 전송하고 는 의 의 컴포넌Sponsor role name APA client APA client client SACM

트를 호출하여 를 통해 에게 을 요청한다 이때 티겟과GSS-API PAS PAC . PAS role name

이 에게 전달되어 진다PAS .

는 티켓의 복호화를 통해 이후에 발생하는 의 과 사이의 통신PAS PAS client SACM PAS④

을 보호하기 위한 세션키를 추출한다 는 사용자이름과 을 읽고 사용자가. PAS role name

에 적합한지를 검토한 후 적절한 을 생성하고 자신의 개인키로 전자서명을role name , PAC

한다 마지막으로 는 티켓을 생성하고 그것을 와 공유하고 있는 대칭키로 암. PAS KDS KDS

호화한다 이때 티겟으로부터 값을 가져와서 티켓에 삽입한다 는. PAS PPID KDS . PAS PAC

과 티켓 그리고 하나 이상의 제어변수 를 의 에게 전송하며 이들 데이KDS CV client SACM

터는 과 사이의 공유하고 있는 기본키를 통해 암호화 된다SACM PAS .

- 107 -

티켓과 티켓이 에게 전송되어 지면 은 이들을 캐쉬에PAS PAC, CV, KDS SACN4 SACAM

저장한다.

사용자가 프로그램을 통해 을 호출하면 은 캐쉬에 저장된 을 찾client SACM SACM PAC⑤

게 되며 적절한 이 존재하지 않을 경우 의 과정을 통해 을 가겨온다PAC , PAC .③ ④

적절한 이 확보되면 응용 시스템 서버를 위한 키가 요구된다 만일 응용 시스템 서PAC .⑥

버를 지원하는 가 공개키를 지원한다면 기본키 패키지의 생성을 위한 의 필요성이PVF KDS

없어진다 여기서는 공개키 지원의 경우만을 고려함 은 응용 시스템 의 공개키. ( ) SACM PVF

로 암호화된 기본키를 포함하는 토큰을 생성하며 사용자의 개인키로 전자서명한다GSS .

토큰은 기본키외에 대화키를 생성하는데 필요한 정보와 기본키로 암호화된 의GSS PAC

을 포함한다 토콘에 포함된 정보를 통해 파생될 대화키는 응용 시스템과CV, PAC . GSS

에 공유되어서 추후 이루어질 통신에 무결성과 기밀성을 지원한다 생성된 토큰SACM . GSS

은 사용자의 인증서와 함께 응용 시스템 서버에 전송된다.

응용 시스템 서버가 토큰을 받으면 를 통해 그것을 에 전송한다GSS GSS-API SACM .⑦

은 토큰에서 과 키정보 암호화된 를 추출하고 그들을 모두 에 전달SACM GSS PAC , CV PVF

한다 는 사용자의 인증서에서 사용자의 공개키를 추출하여 토큰의 전자서명을 검. PVF GSS

증한다 는 자신의 개인키를 통해서 기본키를 추출하고 기본키로 암호화된 를 복호. PVF CV

화한다 또한 추출된 기본키를 통해서 대화키를 계산한다 마지막으로 는 의 공개. . PVF PAS

키를 통해 의 전자서명을 검증하고 의 를 검증한다PAC PAC CV .

- 108 -

검증이 끝나면 는 검증결과와 결과가 성공일 경우에 유효화된 대화키를PVF PAC. CV,

에게 전송한다 은 과 대화키를 캐쉬에 저장한다SACM . SACM PAC CV, .

클라이언트와 응용 시스템 서버와의 상호인증이 요구되면 은 클라이언트에게SACM GSS⑧

토큰을 반환한다 클라이언트는 토큰을 통해 응용 시스템 서버를 인증한다. GSS .

나, Priviledge Attributes Certificate

의 유형(1) PAC

의 유형에는 과 의 두가지가 존재한다PAC Non-delegatable Delegatable .

가( ) Non-delegatable PAC

은 특정한 로 지정되며 방법에 의해 보호된다 내Non-delegatable PAC identity PPID . PAC

에 존재하는 보안정보는 해당하는 세션에 관한 많은 정보를 제공한다.

나( ) Delegatable PAC

은 임시로 사용자의 접근 권한을 사용자를 대신할 서버에게 위임하기 위Delegatable PAC

해 사용되어 진다 서버는 클라이언트를 흉내내지 않고 자신의 아이디를 갖고 그 아이디로.

인증을 받으며 클라이언트로부터 권한을 위임받는다 권한을 위임받은 서버는 위임받았음을.

증명하기 위하여 과 암호화된 를 제시한다 는 임의로 생성된 값PAC CV(Control Value) . CV

이며 는 에 이 적용된 결과값이며 의PV(Protection Value) CV one-way function PAC

필드에 저장된다protection method .

- 109 -

와 는 에 의해 생성되어지며 는 내에 저장되어서 는 현재 사용중인 세CV PV PAS PV PAC CV

션키를 통하여 암호화 되어서 클라이언트에 전송된다.

클라이언트나 서버가 자신의 권한을 다른 서버에게 위임하고자 한다면 를 현재의 세션키CV

로 암호화하여서 과 함께 위임받는 서버에게 전송한다 은 가능한한PAC . Delegatable PAC

제한적으로 권한을 만들어야 한다.

의 구조(2) PAC

의 구조는 표 과 같다PAC [ 3-5] .

표 의 구조[ 3-5] PAC

Body Check Value

Common Contents Specific Contents Signature

issuer domain

issuer identity

serial number

creation time

validity

protection methods

priviledge

miscellaneous

(in V3 just an audit

identity

time period)

value of the signature

algorithm identifier

certificate information

(3) Common Contents

표 의[ 3-6] PAC Common Contents

Issuer Domain 의issuing authority security domain: Directory Name Format

Issuer Identity 의 이름 내의 의 이름issuing authority : security domain PAS

Serial Number 가 할당한 의 유일한 번호PAS PAC

Creation Time 를 기준으로 한 인증서가 생성된 시간issuing authority UTC

Validity 인증서가 유효하다고 간주되는 시작과 종료시간

Algorithm

Identifier을 서명하는데 사용된 알고리즘PAC

- 110 -

(4) Specific Contents

가( ) protection methods

에는 표 에는 나타난 방법들이 있다protection method [ 3-7] .

표 의[ 3-7] PAC protection method

Method 설명

PPID

은 암호화되지 않고 단지 전자서명만 되기 때문에 공격자는 도청을PAC

통해 을 입수하여 악용할 수 있다 이 불법으로 사용되지 않게PAC . PAC

하기 위해서 의 개념이 소개되었고 이를 사용하는 기법PAC ownership

이 바로 이다 는PPID protection method . PPID “Primary Principal's

를 나타낸다 이 기법은 요청한 사용자의 즉 를Identifier" . ldentifier PPID

에 저장하고 동시에 를 키 구축정보의 일부로서 제공하여 응용PAC PPID

프로그램 서버로 하여금 의 요청자가 키 정보PAC (keying information)

를 획득한 객체와 같다는 것을 확인할 수 있도록 함으로써 의 사용PAC

을 제어한다 비록 공격자가 을 가로챌 수는 있지만 함께 가로챈 키. PAC

정보를 사용할 수 없고 유효한 를 갖는 키 정보를 생성할 수 없기PPID

때문에 의 약용을 방지 할 수 있다PAC .

Deligation

Contrlo

(CV/PV)

는 이 프록시로 사용될 수 있도록 한다CV/PV protection method PAC .

이 기법에서는 유효한 는 의 필드에 저initiator PAC protection method

장 된 를 통해 과 연계된다 는 에 의PV(Protection Value) PAC . PV PAS

해 생성되어지고 는 에 의해 암호화되어서CV initiator/PAS basic key

에게 전송된다 최초의 와 이후의 유효한 들은initiator . initiator delegate

로 를 암호화하여 전송함으로써 에 대응하는 를 알고basic key CV PV CV

있다는 것을 에게 증명해야 한다 각 의 는 주어진target . target PVF CV

의 해쉬값이 와 동일한지를 검증한다PV .

나 권한( )

모든 권한은 와 연관된다 에서는 단지defining authority . SESAME default defining

의 만 생성된다 는 의 필드의 값으authority attributes . default PAC Issuer security Domain

로 정의되며 이는 에 포함된 가 항상 의 에서PAC privilege attribute PAS security domain

파생된다는 것을 의미한다.

- 111 -

미래의 확장을 위해 만일 어떤 가 다른 에 속한다고 에 의attribute defining authority PVF

해 탐지되면 이는 에 있는 필드와 매치된다는 가정하에 승인PAC Issuer security Domain

된다 그렇지 않으면 거부되지 않고 단순히 무시된다. .

표 잘 알려진[ 3-8] attribute

Attribute 설명

Access

identity

만일 특정 가 데이터베이스에 지정되어 있다면Access Identity PAS

이것이 사용된다 그렇지 않으면 에 있는. PAC request Authenticated

가 사용된다 이것은 응용프로그램 컴퓨터를 통Identity (user login id) .

하여 접근통제를 위해 사용된다.

Role

Attribute

는 가 될 것이며 의Role Attribute default role attribute PAC

에 있는 과 대응한다 이것은 접근통제 결정을 위해request role name .

사용된다.

Primary

Group소유자가 소속된 주요 접근 그룹PAC

Secondary

Group소유자가 소속된 두 번째 접근 그룹PAC

다( ) Miscellaneous (Audit Identity)

소유자의 가 필드로서 나타난다 만일 사용자에 대PAC audit identity Miscellaneous PAC .

한 특정 가 데이터베이스에 존재한다면 이 값이 사용된다 그렇지 않다Audit Identity PAS .

면 요청에 제시된 값이 사용된다 이 값은 에PAC Authenticated Identity . Audit Facility

의해 내에 저장된다audit records .

라( ) Time Periods

그 범위 내에서만 이 유효한 하나 이상의 시간주기를 가르킨다PAC .

- 112 -

(5) Signature

표 의[ 3-9] PAC Signature

Value(of Signature)

이 값은 의 전자서명값이다 앞PAC Body . (MD5, RSA;512)

으로 등 의 키를 갖는 를 적RIP -160/SHA-1 RHK 1024 RSA

용할 계획임

Algorithm Identifier위에서 사용된 알고리즘 로 에서는 사용되identifier SESAME

지 않는다.

C e r t i f i c a t e

Information의 공개키인증서PAS

다 역할기반의 권한. (Role based privilege)

권한의 이질성과 확장성으로 인해 역할을 기본으로 하는 권한이 설계되었다 사용SESAME .

자는 시스템에 처음 등록할 때 역할을 할당받으며 이러한 은 인증후에 받게 되는role PAC

속에 포함된다 사용자가 접속하려는 자원은 속에 있는 역할 정보에 근거하여 사용자의. PAC

권한을 검증한다 이렇게 을 기반으로 하기 때문에 특정 운영체제에 의존하기 않고 전. role

통적인 보다 더욱 많은 확장성을 갖게 된다 는 권한 변동ACL . SESAME (privilege

문제를 극복하기 위하여 권한 매핑 서비스를 제공한다 는 역할 매핑을variation) . SESAME

허용한다 의 역할중 하나는 전송받은 에 포함된 역할을 자신의 도메인과. target PVF PAC

연관된 역할로 변환하는 것이다.

라. Trust System

그림 은 을 검증하는 과정이다 응용 시스템 서버가 클라이언트로부터 을( 3-16) PAC . PACㅎ

받으면 을 검증하기 위해 에게로 을 보낸다 는 에 있는 의 전자PAC PVF PAC . PVF PAC PAS

서명이 의 에 있는 의 전자서명과 일치하는지 검토한다 일치하게 되PVF Trusted List PAS .

면 은 신뢰할 수 있는 서버로부터 발행된 것임을 알 수 있다 보통 는 내PAC . Trusted List

부 와 외부 들을 포함한다 는 확장성으로 인해 영향받지 않는다PAS PAS . SESAME .

- 113 -

만일 에 외부 도메인을 등록시키려 한다면 관리사는 단지 디렉토리로부Trusted List X.500

터 그 도메인의 인증서를 가져오기만 하면 된다PAS X.509 .

그림 권한 검증 시스템( 3-16) SESAME

(Privilege Verification system)

마. Delegation and Revocation

는 권한부여를 위해 단지 만을 제공하고 을 제공하지 않는SESAME Delegation Revocation

다 서비스는 클라이언트가 접속하고 있는 자원으로 하여금 다른 자원을 접속할. Delegation

수 있도록 원래 클라이언트의 권한보다는 축소된 권한을 위임하는 것이다 에. Trusted List

는 이 가능한 서버가 언급되어 진다 는 모델을 사용하기 때문에delegation . SESAME push

한가지 제약 즉 그 시점에서 권한의 유효성을 확신할 수 없다는 제약을 갖고 있다.

이 문제를 해결하기 위해 은 생성시간 과 유효시간 유효PAC (creation time) (validity time),

기간 을 갖게 된다 대규모의 시스템에서 은 어렵기 때문에 이를 극(time period) . revocation

복하기 위해 는 의 유효시간 에 의존한다 따라서 권한위임이 일SESAME PAC (validity time) .

어날 경우 유효시간은 짧게 위임되는 권한은 가능한 적게 생성되어야 한다.

- 114 -

그림( 3-17) Delegation in SESAME

3. RSA Keonⓡ

은 쉽게 강력한 환경을 구축할 수 있도록 하는 이다RSA KEON PKl PKI Product family

[13][14][15]

가 의 기본 개념. RSA KEON

(1) PKI(Publjc Key Infrastructure)

의 각 컴포넌트들은 공개키쌍 및 그와 연관된 인증서를 생성 관리함으로써RSA KEON , PKI

를 구축한다 를 이루는 방법은 응용에 따라 다를 수 있지만 기본적으로. PKI CA(Ccrtificate

관리콘솔 같은 컴포넌트로 이루어진다 이들 컴포넌트 외에Authrity), LDAP, . RSA Keon

를 추가Security Server, RSA Keon Desktop, RSA Keon Agent, RSA Keon Agent SDK

하여서 솔루션을 확장할 수 있다PKI .

- 115 -

(2) Strong User Authentication

개인키를 가져오기 위하여 수행되는 사용자인증은 적어도 이상이어야 한다2-factor , RSA

에서는 솔루션을 제공한다RSA SecurID token, RSA SecurID smart token .

(3) RSA l(eon Credential Store

개인키를 웹브라우저와 같은 데스크탑 응용프로그램에 저장하는 방법은 안전한 키 보호와

이동에 문제점을 갖는다 안전한 키 보호와 이동을 위한 이상적인 솔루션은 스마트카드를.

적용하는 것이지만 널리 보급되지 않았다는 한계가 있다 는. RSA Keon Credential Store

스마트카드의 한계를 극복하기 위해 설계되었으며 사용자의 개인키와 인증서 등의

을 위한 저장소를 제공한다 는 다양한credential . RSA Keon Credential Store credential

사용자의 개인키 인증서 대칭키 사용자의 신상정보 등 을 위한 하( , , username/password, , )

나의 통합된 저장소이며 물리적인 스마트카드로 구현되거나 사용자의 데스크탑 컴퓨터에 임

시로 암호화되어서 저장된 컨테이너와 같은 소프트웨어 형태로 구현된다 사용자의 이동을.

지원하기 위해 소프트웨어 는 에 의해 안전하Credential Store RSA Keon Security Server

게 보관되어 지며 사용자의 성공적인 인증 후에 을 통하여서 사용자의 데스크탑에 다운SSL

로드된다.

(4) PAC (Privilege Attribute Certificate)

은 사용자의 특권과 권한정보를 전송하기 위해 컴포넌트들 사이에서 사용PAC RSA Keon

되는 의 형태의 인증서이며 최대 하루의 유효기간을 가지고 에X.509 V3 Security Server

의해 실시간으로 생성된다.

다음은 의 특징이다PAC .

- 116 -

짧은 생명주기를 가진다 대개 시간정도.( 8 )①

컴포넌트들에 의해 내부적으로만 사용된다RSA Keon .②

사용자의 인증정보와 권한정보가 저장되어 있으며 옵션에 따라 사용자가 접근할 수 있는③

모든 응용프로그램에 대한 인증정보와 권한정보가 각각의 해당 서버의 공개키로 암호화되어

서 저장되어 있거나 이 경우 한번만 에 접근함 특정 응용서비스에 대한( security server )

인증정보와 권한정보가 해당 서버의 공개키로 저장된다 이 경우 서비스 접근할 때마다.(

에 접근함security server )

PM-Ready Application④

인증서는 독립된 에 의해서 발행되며 에 초기 인증시 에identity CA RSA Kcon Desktop CS

있는 인증서기 제시되어서 인증서의 유효성과 이 검증된다identity· trust chain .

non PKI-ready Application⑤

와 는 는 에 의해 암호화되어서 에 저장된다identity privilege Security Server PAC . Security

는 처럼 동작하고 을 서명한다Server PAC issuer PAC .

나 설계원칙. RSA Keon

개방된 표준과 상호호환성 지원(1)

들은 다른 솔루션의 컴포넌트들과 상호 호환성을 갖도록 설계되RSA Keon component PKI

었다 즉 지원하며 각 모듈들을 컴포넌트화하여 요구에 따라서 다른. Open PKI Standard

제품들과 연동하여 사용할 수 있도록 설치하였다 인증서의 경우 사용자인증을 위한 인증. ,

서와 권한인증을 위한 인증서로 분리한다.

- 117 -

가 준비된 혹은 준비되지 않은 응용 프로그램 지원(2) PKI

한 응용프로그램들은 와 에 의해 지원받는다 이 에이전트들Legacy RSA Keon Agent SDK .

은 를 제공하여 투명하게 이 원래응용프로그램이 지원하는 인PKI wrapper PKI credential

증방법에 매핑되도록 한다 반면 응용프로그램들은 이나 와 같은. PKI-ready PKCS#11 CSP

표준인터페이스의 사용을 통해서 에 접근하도록 한다RSA Keon Credential Store .

이동하는 사용자를 지원(3)

스마트카드와 같은 이동가능한 암호화된 소프트웨어 를 제공함으로써 스마Credential Store

트카드의 한계를 해결하였다

다양한 수준의 사용자인증 지원(4)

기존의 패스워드 기반외에 등을 통해 다RSA SecurID Token, RSA SecurID Smart Card

양한 수준의 사용자인증을 지원한다.

- 118 -

다 구조. RSA Keon

그림 의 구조( 3-18) RSA Keon

구성요소(1)

은 그림 과 같이 개의 컴포넌트 즉 네스크탑 서버 에이전트 디렉RSA Keon ( 3-18) 5 , , , CA,

토리서비스로 구성되어 있다.

가( ) RSA Keon Desktop

은 사용자 인증 스마트카드나 토큰을 이용한RSA Keon Desktop , RSA Sccurll) 2-factor

인증 파일 암호화 응용프로그램과 네트워크 운영체제에 대한, user-authenticated SSL, ,

사용자 의 저장 및 관리를 기원하는 클라이언트 프로그램이다single sign-on, credential .

- 119 -

나( ) RSA Keon Security Server

의 가장 중요한 역할은 로 보호되고 있는 응용프로그램에Sccurity Server RSA Keon Agent

접근하기 위한 을 만드는 것이다 을 통해서 기능이 제공되며 인PAC . PAC Single Sign-on

증과 접근통제가 중앙에서 관리되어 진다 또한 는 사용자와 에. RSA Keon Security Server

이전트에 대한 정보의 저장소역할을 한다 사용자의 공개키 가상 스마트카드 혹. credential(

은 은 에 저장되며 인증후에 데스크탑에 다Credential Store) RSA Keon Security Server

운로드 된다 즉 사용자의 은 위치에 상관없이 접근가능하여 사용자의 이동능력. credential

을 향상시킨다.

다( ) RSA Keon Agent

는 응용프로그램에게 클라이언트와 서버의 수정없이 기반의 인증 세RSA Keon Agent PKI ,

션암호화 을 포함한 를 제공한다, single sign-on security .

라( ) RSA Keon Certificate Server

는 과 과RSA Keon Certificate Server Web S/MIME, IPSEC RSA Keon Agent-protected

과 함께 사용될 사용자나 서버의 인증서를 발급 관리 취소 등을 하application X.509 v3 , ,

는 서버 프로그램이며 키관리엔진 인증서엔진 인증서 저장소와 인증서취소 데이터, , LDAP

베이스를 하나의 강력한 패키지로 통합한 컴포넌트화된 관리시스템이다. RSA Keon

는 쉬운 관리를 위해 인증서 발급을 가속화하는Certificate Server RSA Keon OneSteptm

을 포함 한다.

- 120 -

마 디렉토리시비스( ) LDAP

전자인증서와 을 위한 저장소를 제공한다 에서는 넷스케이프의 디렉CRL . RSA Keon LDAP

토리서버가 권고된다.

라 동작 모델.

그림 는 컴프넌트들이 상호동작을 하는지 보여준다 사용자의( 3-19) RSA Keon . Credential

는 나 다른 신뢰된 에 의해 발급된 인증서를 포함해야 한다Store RSA Keon CA CA .

그림 동작모델( 3-19) RSA Keon

- 121 -

모델특징(1)

의 특징은 다음과 같다RSA Keon .

기반의 모델PKI SSO①

에이전트 브로커 기반 모델-②

모델On-Line Privilege Service, Push③

Role based Authorization④

형태의X.509 v3 PAC(Privilege Attribute Certificate)⑤

절차(2)

사용자는 에 로그온한다RSA Keon Desktop .①

는 사용자의 암호화된 를 서버의 데이터베RSA Keon Security Server Credential Store②

이스에서 가져온 다음 암호화된 채널을 통해 사용자 시스템에 전송한다 그 후SSL RSA

이 제시한 인증서의 유효성을 검증한다Keon Desktop .

이 시스템에 연결된 네트워크 운영체제에 자동으로 로그온 되도RSA Keon Desktop NT③

록 설정되어 있다면 은 로부터 과RSA Keon Desktop Credential Store NT username

를 추출하고 사용자의 개입없이 자동으로 에 로그온한다password NT Domain .

사용자가 웹서버에 접속하기를 원한다면 사용자는 웹브라우저를 실행한다 브라우저와.④

서버사이에 이 설정되는 시점에서 은 에 있는 인SSL, RSA Keon Desktop Credential Store

증서를 제시하여 웹서버와 상호인증을 하고 암호화된 을 구축한다SSL .

사용자가 응용프로그램에 접근하려 한다면 예를 들어 오라클 은( ), RSA Keon Desktop⑤

원속 필터를 통해서 그 연결요청을 가로챈다2.0 .

- 122 -

데스크탑은 에게 을 요청하던지 혹은 사용자의RSA Keon Security Sewer PAC Credential

에서 을 가져온다Store PAC .

만일 새로운 이 필요하다면 는 사용자가 요구한 응용프PAC RSA Keon Security Server⑥

로그램의 사용자 루그온 정보를 가져와서 그 응용프로그램을 위한 의 공RSA Keon Agent

개키로 암호화하고 암호화된 로그온정보를 포함하는 을 발급하여 인증된 세션을PAC SSL

통해 에 전송한다RSA Keon Desktop .

클라이언트와 서버인증과 함께 은 응용서버에 있는RSA Keoll Desktop RSA Keon⑦

사이에 을 이용하여 안전하고 인증된 채널을 설정한다Agent SSL v3.0 .

여기서 은 사용자의 인증서를 사용자의 클라이언트 사이트 인승서로 교체한PAC identity -

다.

는 자신의 개인키를 이용해서 으로부터 사용자의 로그온RSA Keon Agent PAC⑧

을 추출하여 응용서버에게 전송한다 로그온의 결과는 에 전credential . RSA Keon Desktop

송되고 에 로그된다 만일 인증이 성공이면 응용 서비스는 암호RSA Keon Security server .

화된 세션을 통해서 계속 진행된다.

4. Netscape SuiteSpot

넷스케이트는 대부Navigator 3.x, Communicator, Communicator Professional Edition,

분의 들을 위해 을 지원한다 에 대한SuiteSpot 3.x server Single Sign-on . Single Sign-on

넷스케이프의 접근은 인증을 위해서 인증서를 사용하는 것이다 넷스케이프 제품들에게.

은 현존하는 접근통제 메카니즘의 변경없이 다중 로그인을 교체하는 인증Single Sign-on

메카니즘이다[6].

가 에 대한 넷스케이프의 전략. Single Sign-on

- 123 -

그림 은 평가과정과 인종방식의 교체를 나타내고 있다 넷스케이프가( 3-20) ACL . Single

을 적용하기 위해 추구하는 전략은 네트워크상에서 전송되는 패스워드 기반의 인증Sing-on

방식을 과 인증서에 근거한 클라이언트의 인증서를 통한 인증방식으로 교체하는 것이SSL

다.

그림 인증방식의 교체( 3-20)

인증방식의 교체로 얻어지는 이점은 다음과 같다.

단일 인증의 사용자 편이성(1)

에 국한된 패스워드(2) local machine

로그인 하기 위해서 사용자는 개인키가 필요하며 이 개인키롤 가져오기 위해 패스워드를 입·

력한다 입력된 패스워드는 네트워크상에서 전송되지 않는다. .

단순화된 관리(3)

계정관리자는 클라이언트와 서버가 유지하고 있는 의 리스트를 제어함Certificate Authohty

으로써 누가 어떤 서버에 접근할 수 있는가를 제어할 수 있다.

- 124 -

의 리스트는 패스워드 리스트보다 작고 자구 변화하지 않는다Certificate Authority .

의 보존(4) ACL

클라이언트의 인증을 교체하지만 접근통제 메카니즘은 그대로 유기한다.

나 과. Ciient Authentication Single Sign-on

클라이언트 인증은 대부분의 인트라넷과 엑스트라넷의 필수요소다 본 절에서는 그림. ( 3-20)

에서 소개된 두가지 형태의 클라이언트 인증방식을 비교한다.

비교를 하기전에 다음과 같은 가정이 필요하다.

첫 째 클라이언트와 서버사이의 인증은 상에서 이루어지며 둘 째 서버 요청된 자원의SSL

을 평가하는 과정에서 클라이언트에게 인증요청을 한다ACL .

(1) Basic Authentication

그림( 3-21) Basic Authentication

그림 는 패스워드기반의 인증절차를 나타내고 있다( 21) .

- 125 -

인증단계는 다음과 같다.

서버로 부터의 인증요청이 발생하면서 클라이언트는 그 서버를 위한 사용가 이름과 패스①

워드를 요청하는 대화상자를 보게 된다 사용자는 접속하고자 하는 새로운 서버마다 다로.

따로 사용가 이름과 패스워드를 입력해야 한다.

클라이언트는 네트워그상에 사용자 이름과 패스워드를 전송한다 전송은 암호화된. SSL②

연결에서 이루어진다.

서버는 자신의 전용 패스워드 데이터베이스에 있는 사용자의 이름과 패스워드를 비교하③

여 인증한다.

서버는 계속해서 을 평가하며 식별된 사용자가 요청된 자원을 접근할 수 있는지 결ACL④

정한다 접근통제.( )

이 방법에서 사용자는 각 서버에 대해 새로운 패스워드를 제시해야 하고 관리자는 서버마다

각 사용자에 대한 이름과 패스워드를 추적해야만 한다.

다음에서 언급할 은 위의 세 단계를 단순히 사용자가 한번 로그인 하는 단single sign-on

계로 교체하며 관리자로 하여금 와 디렉토리서버의 도움을 받아서 사용자 계정을 중앙에CA

서 관리할 수 있도록 한다.

- 126 -

(2) Strong Authentication

그림 인증서를 이용한 사용자 인증절차( 3-22)

그림( 3-23) Strong authentication

- 127 -

넷스케이프의 은 각각의 서버를 위해 다중의 패스워드보다는 하나의 인증서Single sign-on

를 사용하도록 한다 인증받기 위해서 클라이언트는 임의로 발생한 데이터인 를 전자. nonce

서명하여 인증서와 함께 보낸다.

다음은 인증 절차이다.

의 경우 개인키 데이터베이스를 관리한다 사용자가 인증서 기반의 인증을Navigator 3.x .①

받기 위해서 개인키가 필요하며 이 개인키를 얻기 위해 패스워드를 입력한다 이 패스워드.

를 입력한 후 사용자는 나머지 세션과 다른 서버에 접속을 할 때도 패스워드를 재입력할,

필요가 없다.

사용자는 개인키를 가져온 후 를 생성하여 개인키로 전자서명을 한다, nonce .②

클라이언트는 전자서명된 값 과 인증서를 네트워크상에 전송 한다(evidence) .③

서버는 그림 같이 인증서와 전자서명된 값 을 통해서 사용자를 인증한다( 3-22) (evidence) .④

서버는 사용자의 를 디렉토리에 있는 유일한 항목과 매핑시켜서 사용자가identity LDAP⑤

제시했던 인증서와 동일한 인증서가 있는지 검토한다.

관리자는 사용자가 서버에 접근하지 못하도록 하기 위하여 단순히 디렉토리서버에서LDAP

사용자의 인증서를 제거하기만 하면 된다.

조사가 성공하면 서버는 계속해서 을 평가한다 그리고 요청된 자원에 접근LDAP ACL .⑥

을 허용할 것인지의 여부를 결정한다.

- 128 -

은 사용자가 개인키 데이터베이스에서 개인키를 얻기 위하여 단 한번 패스Single Sign-on

워드를 요구함으로써 구현된다.

비교분석5.

가에서 언급된 기반의 커버러스 구조는 기존의 대칭기 기반 구조에서 공개키 기반 구조PKl

로의 변환을 시도하면서 대칭키 기반의 구조에서 커다란 부담이었던 키관리 비용을 최소화

하도록 하였고 공개키 기반 구조가 제공하는 강력한 보안서비스를 적용하고자 하였다 특히.

은 인증서를 사용하여 에 초기인증을 할 수 있는 방안을 제시하였고 는PKINIT KDC PKDA

중앙의 인증서버인 의 개입없이 직접 클라이언트와 서버사이에서 이루어 지는 인증프KDC

로토콜을 제시하여 사용자인증의 부담을 분산화했다 그러나 기반의 키비러스 구조는. PKI

기존의 프로토골과 호환성을 유지하기 위하여 불필요한 절차를 제거하지 못하거나 여전히

대칭키를 공유하는 등 대칭키 기반 구조의 한계성을 극복하지 못하였다 또한 시스. Legacy

템의 를 위한 확장성 있는 구조를 고려하지 않았다 나에서 언급된 는 기존 커SSO . SESAME

버러스 구조를 유지하면서 권한 서버를 통해 대규모의 분산된 이기종 환경에서 역할기반의

통합된 접근통제 기능을 제공한다 또한 공개키 기반 구조를 적용하여 초기인증이 보다 강.

화되었고 응용 시스템 서버의 키관리 부담을 줄였다 그러나 는 공개키 기반 기술. SESAME

을 적용함에도 불구하고 기반의 커버러스처럼 대칭키 기반 구조의 한계를 벗어나지 못PKI

하였고 접근통제를 위해 를 추가함으로써 구조가 복잡해지는 문제점을 갖게 되었나 또PAS .

한 시스템의 를 위한 확장성있는 구조를 구조를 고려하지 않았다 언급된Legacy SSO . RSA

Keonⓡ은 사용자의 권한정보를 의 인증서 의 확장필드에 저장하는 구조를 갖PKC(X.509 v3 )

는 을 통해 사용자인증 아니라 중앙에서의 통합적인 접근통제가 가능하도록 하였으며PAC ,

기법을 적용하여서 시스템에 대한 확장성있는 구조를 제시하였다Agent Legacy .

- 129 -

또한 커버러스나 처럼 불필요한 대칭키 기반의 구조를 갖고 있지 않고 구조가SESAME

에 비해 단순하다 그러나SESAME . RSA Keonⓡ은 응용 시스템 서버측에 에이전트가 가능

하지 않을 경우에 대한 확장성을 고려하지 못하였고 사용자의 공개키 정보와 권한정보를 함

께 갖는 을 새로운 접속요구가 있을 때마다 온라인으로 발급해야 하기 때문에 을PAC PAC

발급할 때마다 공개키 쌍을 생성해야하는 부가적 비용이 손재한다 또한 은 서로 특성. PAC

이 틀린 공개키 정보와 권한정보를 함께 인증서에 저장하여 처리하는 문제점을 갖고 있다.

라에서 언급한 의 은 처럼 인증서버의 개입없이 클라이언트와 응Netscape SuiteSpot PKDA

용 시스템 서버와의 인증이 가능하도록 하는 비교적 단순한 구조를 제시하였다 그러나 통.

합적인 접근통제를 고려하지 않았고 시스템의 를 위한 확장성있는 구조를 고려Legacy SSO

하지 않았다 이외에 에서는 인트라넷 환경에서 보안서비스를 제공하기 위해. [5] SESAME

의 접근통제구조와 와의 연계를 제안하였다 는 웹에 보안서비스를 제공하는 훌륭TLS . TLS

한 기술임에도 불구하고 접근통제 부인봉쇄와 같은 한계를 가지고 있다 이에 대한 대안으, .

로 에서는 를 채택하였다 에서는 특성이 틀린 공개키와 권한의 효율적인[5] SESAME . [5]

관리를 위해 RSA Keonⓡ 처럼 이들 값을 인증서에 함께 두기 보다는 와 으로 분PKC PAC

리하였다 그러나 는 개방된 표준인 의 구조를 따르지 않은 제한을 갖고 있. [5] X.509 PMI

다.

의 는 웹에서의 분산된 접근통제를 위해 단순하고 일반적인 기반구조를 제시했다[6] WDAI .

하에서 웹브라우저와 서버는WDAI RSA Keonⓡ의 과 같이 형태의 권한 인증PAC X.509 v3

서를 통해 권한정보를 교환한다 이 구조는 서로 특성이 틀린 공개키 정보와 권한정보를 함.

께 저장하여 처리하는 문제점을 갖고 있으며 새로운 접속요청이 있을 때마다 권한인증서를

발급해야 하기 때문에 RSA Keonⓡ 처럼 공개키쌍을 생성해야 하는 오버헤드를 갖게된다.

- 130 -

표 시스템 비교[ 3-10] SSO

비교항목 Kerberos SESAME RSAKeon SuiteSpot

통합된 접근통제 ○ ○

기반의 사용자 인증PKC ○ ○ ○ ○

초기인증 생략 ○

상호 인증 ○ ○ ○ ○

부인 봉쇄 ○ ○ ○ ○

시스템 지원Legacy ○

유연성있는 구조SSO ○

통합된사용자관리지원 ○ ○ ○ ○

주문형 인터페이스 ○

국내외 업계동향6.

현재 국내에서는 이니텍과 펜타시큐리티 시큐아이닷컴을 비롯 이섬테크 썬인포메이션 시, , ,

스템 소프트포럼 드림시큐리티 등 개 업체 가량이 시장에 뛰어 들고 있는 상태, , 6 7 SSO∼

이며 세계적으로는 독자적인 입지를 구축하고 있는 네테그리티와 역시, SiteMinder PKI「 」

시장을 의 볼티모어 의 엔트러스 등이 눈에 띠는 활동을Select Access , Get Access「 「 」

보이고 있다.

해외의 경우 의 개념이 비교적 오래전부터 적용되어 왔으며 보안적인 관점보다는 사용, SSO

자와 운영자의 편의에 초점을 맞춰 시장이 형성되어 온 반면 국내의 경우에는 최근 들어서,

보안의 중요성과 함께 암호화 솔루션이 포함된 기반의 시장에서부티 출발 해외와PKI SSO ,

는 또 다른 시장의 성격을 띠고 있다고 할 수 있다.

최근 제품은 단일 인증 및 동 합된 계정관리 외에 각 사용자에 대한 통합된 접근통제SSO ·

로 까지 그 영역을 넓히고 있다.

- 131 -

통합된 접근통제를 위한 대표적인 권한관리 체계는 에서 제시된X.509 PMI(Pvivilege

구조이며 이 구조와 연계된 사용자 권한 통합관리에 대한 연Management Infrastructure)

구가 활발히 진행되고 있다 그 결과 최근에는 를 기반으로 한 통합인증 및 권한관리. PKI

솔루션이 제시되었다(EAM: Extranet Access Management) .

솔루션은 접근통제를 위한 기본기능과 제반 정책관리를 포함하며 인터넷 및 인트라넷EAM

에서 다양한 응용과 서비스에 대한 사용자의 접근권한을 통합적으로 관리하고 또한 일반적

인 를 통한 각종 인터넷 서비스의 통합 인증 구현은 물론 사용자 아이디와 역할을 명시SSO

하는 테이블과 역할 및 접근 가능 자원을 명시한 테이블 그리고 각각의 테이블을 변경하고,

관리하기 위한 정책부분으로 구성되어 강력한 권한관리 기능까지 함께 구현하고 있다.

- 132 -

제 절 설계목표3

설계될 시스템은 다음과 같은 설계목표를 갖는다.

강력한 초기인증1.

초기인종을 위하여 스마트 카드나 토큰 등 별도의 하드웨어를 통해 이상의USB 2 factor

강력한 인증이 지원되어야 한다.

통합된 접근통제 시스템2.

가. PAS(Privilege Attribute Server)

중앙의 단일 저장소에 사용자들의 권한정보를 저장하여 관리하며 사용자의 접속요청이 발생

하면 중앙저장소에서 해당 사용자의 권한정보를 가져온 후 자신의 서명을 동반한,

를 사용자에게 발급하는 역할을 하는 가 요구된다AC(Attribute Certificate) PAS .

나. AC(Attribute Certificate)

사용자의 권한정보를 응용 시스템 서버에게 전송하는 수단으로 가 자신의 전자서명을PAS

통해 보증하는 권한인증서인 가 요구된다 는 개방된 표준을 준수해서 시스템의 호환AC . AC

성을 유지해야 하며 인승서와 구별된다X.509 v3 .

다 통합된 권한체계.

대규모의 다중 도메인 환경에서 사용자는 다양한 응용 시스템에 접근해야 하며 이 경우 접

근권한이 저마다 다른 문제점이 발생한다.

- 133 -

이를 극복하기 위해서는 통합된 권한체계와 통합된 권한을 각각의 응용 시스템의 권한으로

변환하는 매핑함수가 필요하다.

라 단일인증.

사용자는 에 대한 초기인증을 통해 추후 별도의 인증없이 를 받고 여러 응용 시스템PAS AC

에 대한 접속을 할 수 있어야 한다.

다양한 응용 시스템에 쉽게 적용할 수 있는 유연성 있는 구조3.

설계될 시스템은 다양한 시스템 조건을 충족할 수 있는 유연성 있는 구조로 설계되어야 한

다 즉 응용 시스템의 서버가 화될 수 있는 경우 응용시스템의 서버가 화될 수 없. SSO , SSO

는 경우 에이전트가 허용된 경우 등과 같은 다양한 상황을 모두 지원할 수 있어야 한다, .

특히 웹 응용 시스템을 위해서 웹 환경에 적합한 구조가 제시되어야 한다.

기반의 시스템4. PKI

가 인증서를 통한 사용자 인증. X.509 v3

설계될 시스템은 인증서를 통한 사용자 인증을 제공해야 한다 사용자는 자신의X.509 v3 .

개인키로 전자서명을 하여 개인키 소유에 대한 증명을 함으로써 인증받을 수 있어야 있다.

나 합법적인 사용자 사칭 차단 및 부인봉쇄 기능.

사용자의 사칭차단과 부인봉쇄를 보장할 수 있는 구조가 제시되어야 한다.

- 134 -

다 구성요소간 신뢰성있는 통신지원.

설계될 시스템의 구성요소간에 발생하는 통신에 대해 와 같은 공개키 기반의 신뢰성있TLS

는 암호화 통신이 지원되어야 한다.

통합된 사용자관리 지원5.

사용자의 신상 및 권한 기타정보를 중앙 저장소에서 저장하도록 하여 사용자에 대한 통합,

관리가 이루어 기도록 해야 한다.

개방된 표준과 기술규격지원6.

설계될 시스템에 적용할 공개키 기반 기술은 개방된 표준과 기술규격을 지원하도록 해야 한

다 특히 공인 인증체계와 기술규격준수 및 상호 연동성이 고려되어야 한다. .

- 135 -

제 장4 PMI(Privilege Management Infrastructure)

본 장에서는 시스템의 통합된 접근통제 구조를 위해 분산환경에서 권한에 관련된 고려SSO

사항 을 언급하고 에서 제시된 표준 권한 관리 구조인(Authorization Issue) X.509 v2

구조를 분석한다PMI(Privilege Management Infrastructure) .

제 절 분산환경에서 권한에 관련된 고려사항1

그림 다중 도메인 접근( 4-1)

그림 은 한 도메인에 속한 사용자가 다른 도메인 내에 있는 자원을 접근하는 상황에서( 4-1)

발생하는 권한에 관한 문제를 보여준다.

- 136 -

외부의 도메인은 사용자에 대해 거의 알지 못한다 외부에 존재하는 서버는 사용자의.▶

권한 를 가져오는 방법을 알고 있어야 한다(privilege) .

도메인사이에 일반적인 권한 시스템이 존재해야 한다 사용자가 한 도메인에서 권한을.▶

부여 받았다면 그 권한은 접근통제 결정을 위해 다른 도메인에서 사용될 수 있어야 한다.

도메인들 사이에 트러스트 시스템이 존재해야 한다 이 트러스트 시스템은 사용자가.▶

권한을 통해 접근하려는 외부도메인으로 하여금 사용자가 속한 도메인이 유효한 권한을

발행했다는 것을 신뢰할 수 있게 한다.

관리 도메인1. (Administrative Domains)

대규모의 분산 시스템은 하나의 관리자에 의해 관리되어 질 수 없다 대신에 여러 개의 작.

은 도메인으로 분리되어 진다 시스템을 여러 도메인으로 분리할 때 어려운 점은 도메인들.

을 포함하는 하나의 권한관리 시스템을 구축하는 방법이다.

사용자의 권한 획득2.

가 권한 서버.

하나의 도메인일 경우 사용자의 권한을 저장하는 방법에 대해서 고려해야 한다 첫 번째, .

가능한 방법은 대부분의 시스템에서 사용되어 지는 경우로 각 사용자에 대해서 각각의 서버

에 사용자가 접근하는 계정을 저장하는 방법이다( ) .

- 137 -

이 방법은 도메인이 대규모일 경우 계정관리가 어려운 단점이 있다 두번째 방법은 중앙 집.

중적인 저장소 권한 서버 에다 사용자의 권한을 저장하는 방법이다 권한 요청시 사용자나( ) .

응용 서버가 권한을 가져온다.

다중 도메인일 경우 각 도메인 내의 권한 서버가 요구된다 각 서버는 자기의 도메인 내, .

사용자들의 권한을 저장한다 다중 도메인 접속이 요청되면 사용자의 권한은 사용자나 응용.

서버가 직접 가져온다.

나. Push vs Pull Models

사용자의 권한이 권한 서버에 저장되어 있는 환경에서 원격서버가 사용자의 권한을 획득하

는 방법에는 두 가지가 존재한다 모델은 접속요청이 발생할 때 사용자의 응용프로그. Push ,

램이 원격서버에게 권한을 전달하는 기법이고 모델은 사용자의 권한 서버로부터 직접Push

받는 기법이다 표 에서는 두 모델의 장점이 언급된다.[ 4-1] .

표 모델과 모델의 장점[ 4-1] Push Pull

models Push Pull

장점

접근결정이 서버에 의해 즉각 이루어 진다.

서버는 권한이 유효하다는

것을 바로 지금 확신할 수

있다.

권한 서버에 대한 접근은 사용자 의해 단 한번

접근된다.

사용자는 서버에 무명으로 접근 할 수 있다.

사용자의 콘텍스트에 근거하여 사용자의 권한을

수정할 수 있다.

사용자는 서버가 원하는 최소한의 정보만을 제

공할 수 있다 서버와 관련없는 정보는 제공하.

지 않는다.

- 138 -

다 온라인 오프라인 모델. vs

다중의 도매인 시스템에서 온라인 서비스 혹은 오프라인 서비스 중 어떤 것이 더 바람직한

것인지 고려해야 한다 온라인의 경우 권한 서비스는 권한 서버가 네트워크 상에 존재한다.

면 요청 즉시 권한을 제공한다 오프라인의 경우 권한 서버는 권한 인증서를 발행하여 접근.

가능한 디렉토리에다 저장한다 사용자와 응용서버는 필요할 때면 접근하여 권한을 가져 올.

수 있다 표 에서는 두 모델의 단점이 언급된다. [ 4-2] .

표 오프라인 모델과 온라인 모델의 단점[ 4-2]

models 오프라인 모델 온라인 모델

단점

종보가 인증서 형태로 정장되어야 하기 때문에

여러 복사본이 존재할 수 있고 정보의 변경이나

취소가 즉각 반영되기 어려움

하지 않Fault-tolerant

음

중앙집중적인 구조가 아니기 때문에 현재 눈가

로그인 되었는지 어떤 권한이 사용되는지 알 수

없음

중앙서버가 해킹당하면

치명적임

인증서는 모두에게 읽히기 쉽기 때문에 사용자

아이디나 권한 정보가 보호될 수 없음

시스템내에 있는 모든 컴포넌트가 공개키암호를

지원해야 한다 이것은 오버헤드를 발생시. CPU

킴

일반 권한 시스템3. (Genric Privilege System)

가 이질적인권한. (Heterogeneous Privileges)

대규모의 다중 도메인 환경에서 사용자는 다양한 운영체제에 존재하는 자원을 접근해야 하

며 이 경우 권한이 저마다 다른 문제점이 발생한다.

- 139 -

이를 극복하기 위해서는 모든 가능한 운영체제에 적합한 일반적인 권한 시스템과 일반적인

스타일의 권한을 각각의 운영체제 권한으로 변환하는 매핑 함수가 필요하다.

나 권한 변동.

대규모의 다중 도메인 시스템에 충분히 적합한 권한을 설계한다는 것은 거의 불가능한 일이

며 결국 권한 변동이 발생하게 된다 이러한 문제점을 해결하기 위한 한가지 가능한 접근은.

각 도메인에 적합한 권한을 설계하는 것이다 각 도메인 내에서는 적절한 방법이 존재할 것.

이며 도메인간에는 매핑함수가 존재하여 권한을 해석하도록 한다,

신뢰 시스템4. (Trust System)

사용자가 접속하려는 외부 도메인에 있는 서버는 사용자의 특권을 검증할 수 있어야 하며

이것은 다중 도메인 시스템에서 본질적으로 요구되는 사항이다 신뢰 시스템을 통해서 이.

문제를 해결할 수 있다.

그림 다중 도메인 신뢰 시스템( 4-2)

- 140 -

그림 는 간단한 신뢰 시스템을 보여주며 다음은 신뢰 과정을 나타낸다( 4-2) .

사용자는 도메인내의 권한 서버에게 을 제시하어여 서명된 인증서 형태의 권credential①

한을 받는다.

접속이 요청될 때 인증서가 외부 서버이게 전달된다.②

외부 서버는 관리자에 의해 생성된 신뢰목록 을 참조하여 권한을 검증한(Trusted List)③

다 권한목록 은 관리자가 신뢰하는 권한 서버의 서명을 포함한다. (Trusted List) .

권한의 위임과 취소5.

사용자가 접근하고 있는 자원이 원래의 목적을 달성하기 위해 또 다른 자원을 접근해야 할

경우가 있다 이때 사용자의 권한이 작업중인 자원에게 위임되어서 사용자를 대신하여 다른.

자원을 접근하도록 해야 한다 이를 위해위임 체인 을 만들어서 권한이 위. (delegation chain)

임된 과정을 체인에 기록하여 체인에 있는 자원들이 자신의 바로 전 단계의 자원이 사용자

를 대표한다는 것을 검증할 수 있도록 한다.

위임된 권한은 취소될 수 있어야 한다 즉 위임된 자원이 자신의 작업을 완료했거나 권한의.

시간이 종료되었을 경우 또는 사용자가 시스템에 존재하지 않을 경우 등에 권한은 취소되,

어야 한다 단일 도메인의 경우 이를 해결하기 위한 전형적인 방법은 취소된 권한 리스트. ,

인 블랙리스트를 통해 권한이 유효한지 검증하는 블랙리스트 방법이다.

- 141 -

제 절 접근 통제2 (Access Control)

전통적인 접근 통제1.

데이터에 대한 접근을 통제할 때 세 가지의 주요 목적이 있다.

데이터는 허용되지 않은 사람에게 노출되어서는 안된다Confidentiality: .▶

데이터는 허용되지 않은 사람에 의해 수정되어서는 안된다Integrity: .▶

모든 보안관련 행동은 로그에 남아서 안전하게 보관되어야 한다Accountability: .▶

에 의하면 시스템의 상태는 로 나타낼 수 있다Lampson subject, object, access matrix .

는 동작을 취하는 능동적인 주체이고 는 접근되어지는 객체이다subject object . access

는 표 과 같이 나타낼 수 있다matrix [ 4-3] .

표[ 4-3] Lampson access matrix (r=read, w=write, k=kill, -=none)

SubjectObject1:

~profile

Object2:

netscape-cache

Subject1:

editor

Subject2:

netscape

S1: editor rw - k -

S2: nescape - rw k k

표 에서 은 에 에 대한 권한이 있고 는[ 4-3] Subject S1 Object1 read/write Subject S2

에 권한을 갖고 있다Object2 read/write .

이 행렬에 있는 각 열은 이라 한다 은 의Access Control List(ACL) . ACL (subject, right)

리스트로 되어 있다.

또 다른 접근은 의 사용이다 위의 행렬에서 각각의 행이 이다 즉 각Capability · Capability .

는 들에 대해 권한을 갖는다Subject Object .

- 142 -

과 기반 구조의 난점은 관리와 확장성에 있다 분산환경에서는 무수히 많은ACL Capability .

와 가 존재하기 때문에 구현이 어렵다Subject Object .

역할기반의 접근통제2. (RBAC: Role based access control)

위에서 언급한 일반석인 의 문제를 해결하기 위해 를 이용한 접근제어가 제시되ACL RBAC

었다 전통적인 과 비교한다면 에서는 가 로 교체되며 어떤 가. ACL RBAC subject role subject

어떤 역할을 수행하도록 허용되는 지에 대한 정의가 분리되어서 지정된다 이것은 접근제어.

가 응용프로그램을 수행하려하거나 자원을 접근하려 하는 사용자의 에 근거하여 결정되role

는 것을 의미한다.

표[ 4-4] Role Based Access Control Matrices

(r=read, w=write, k=kill, -=none)

Role Subject

(R1) lecture mary, tom

(R2) student alice, jack

Role Object1 Object2 Role R1 Role R2

lecture rw - k -

student - rw k k

표 는 에 대한 전형적인 행렬이다[ 4-4] RBAC .

관리자는 단지 누가 어떤 역할을 할 수 있는지에 관한 리스트만을 유지하면 되기 때문에 어

떤 사람이 한 부서에서 다른 부서로 이동하거나 사용자를 시스템에 추가하는 것이 쉽다.

- 143 -

응용프로그램 측면에서는 단지 어떤 이 어떤 동작을 허용한다라는 것을 지정하는role ACL

응용프로그램마다 하나씩 을 구축하면 된다 이러한 유형의 접근제어는 사용자에게 매우( ) .

친숙하며 사용자는 사용자이름대신에 사용자 예롤 들면 을 통해서 로그rolename( student)

인 할 수 있다.

구축한 경험에 의하면 실제 환경과 잘 매핑됨을 알 수 있다 예를 들어 사용자로 구성. 500

된 한 조직은 대략 개의 에 매핑된다20 role .

즉 직접 와 와의 관계를 유지하면 와 의 수가 많아 질수록 복잡subject object subject object

하고 관리가 힘들어 지지만 중간에 잘 정의된 을 두어서 에 근거하여 관리하면 구role role

조가 단순해진다.

예를 들어 만큼의 다양한 경우의 권한을 가진 가 존재할 수 있지만 이럴 경우44 Subject

관리가 힘들게 된다 따라서 경우의 수를 잘정의된 로 축소시켜서 관리할 수 있다. role .

- 144 -

제 절3 PMI Overview

많은 시스템들이 를 이용하여 기반의 접근PKC(X.509 v3 Public Key Certificate) identity

통제를 수행한다 하지만 점차로 더욱 세분화된 규칙기반이나 혹은 역할기반의 접근통제가.

요구되어 지고 있고 이런 형태의 접근통제는 수명주기가 공개키 쌍보다 짧기 때문에 PKC

에 포함되지 않은 부가적인 정보를 필요로 한다 부가적인 정보를 와 연계시키기 위해. PKC

가 에서 정의되었고 후에 에AC(Attribute Certificate) ANSI ITU-Recommandation X.509

통합되었다.[1][2].

그림 구조( 4-3) PMI

정의1.

는 를 생성하거나 관리 거상 배포 취소하PMI(Privilege Management Infrastructure) AC , , ,

는데 필요한 하드웨어 소프트웨어 사람 정책과 전차의 집합을 말한다, , , .

- 145 -

구성요소2.

는 그림 과 같이 구성되어 있으며 그 구성요소는 다음과 같다PMI ( 4-3) .

혹은AC Issuer ( AA: Attribute Authority)▶

는 를 발행하고 취소하는 역할을 한다 는 매우 짧은 생명주기를 사용하AC Issuer AC . AA

여 를 취소한다AC .

AC User▶

는 를 파생하거나 처리하는 객체다AC User AC .

AC Verifier▶

는 의 유효성을 검증하고 결과를 이용하는 객체다AC Verifier AC .

Client▶

는 권한검증이 이루어지는 서비스를 요청하는 객체다Client .

Server▶

는 권한검증을 요청하는 객체다Server .

Repository▶

는 와 을 저장하고 사용할 수 있도록 하는 객체다Repository AC CRL .

- 146 -

3. AC (Attribute Certificate)

가 와 차이점. PKC

와 와의 가장 큰 차이점은 다음과 같다 의 경우 는 공개키와 연결되지PKC AC . PKC , identity

만 의 경우 공개키를 갖고 있지 않고 대신에 는 속성정보 소유자의 소속그AC , identity (AC

룹 역할 보안 클리어런스등 와 연결된다 비교 설명한다면 는 여권과 같고 는 비자, , ) . PKC AC

와 같다 즉 여권은 사용자를 식별하며 오랫동안 유효한 속성을 갖고 있으며 쉽게 얻을 수.

없다 반면 비자는 서로 다른 기관에 의해 발급되며 오랫동안 유효하시 않다 그리고 발급. .

과정은 비교적 단순하다 표 는 와 와의 비교를 나타내고 있다.[ 4-5] PKC AC .

표 와 와의 비교[ 4-5] PKC AC

비교항목 PKC AC

와 연결identity 공개키소유자의 소속그룹 역할 클리어, ,

런스등과 같은 보안속성

생명주기 길다 짧다

획득절차 복잡하다 비교적 단순하다

권한정보는 의 확장필드에 저장하거나 혹은 분리된 에 저장되어 질 수 있다PKC AC .

권한정보를 에 저장하는 방법은 두 가지 이유로 인해 바람직하지 않다 첫 번째 이유는PKC .

권한 정보가 공개기 쌍과 같은 생명주기를 갖지 않다는 것이다 즉 권한정보가 의 확장. PKC

필드에 저장된다면 의 주기가 짧아져서 공개키 쌍이 유효함에도 취소해야하는 경우가PKC

발생한다 두 번째 이유는 발급자가 권한정보 처리에 대한 자격을 갖지 못하였다는 것. PKC

이다 즉 발급자는 권위있는 객체로부터 권한정보를 가져오는 단계를 필요로 한다. PKC .

- 147 -

이러한 이유로 권한정보를 로부터 분리하는 것이 바람직하다PKC .

나 프로파일의 요구사항 및 구조. AC

프로파일의 요구사항은 표 과 같다AC [ 4-6] .

표 의 요구사항[ 4-6] AC

항목 요구사항

Time/Validity

긴 생명주기와 짧은 생명주기를 동시에 지원해야 한다 는. PKC

가 월단위로 측정되는데 반하여 는 시간단위로 측정된다validity AC .

짧은 는 가 취소 메카니즘 없이도 유용할 수 있도록 한다validity AC .

Attribute type

발급자는 내부 도메인에서의 사용을 위해 그들 자신만의AC attribute

을 지정할 수 있어야 한다type .

내에 포함될 수 있는 몇몇 표준 이 지정되어야 한다AC attribute type .

예를 들면 access identity", "group", "role", "clearance", "audit

identity", "charging identity"

정의한 표준 이 다른 도메인 내에서도 정의되었을 경우attribute type

가 구분할 수 있도록 해야한다AC verifier .

의AC Target 하나 이상의 서버에서 가 유효할 수 있도록 해야 한다AC .

Push & Pull

는 클라이언트가 서버에서 할 수 있어야 하며 혹은 온라인AC push AC

발급자와 같은 네트워크 서비스나 저장소로부터 서버에 의해 될pull

수 있어야 한다.

다음은 에서 정의된 프로파일의 구조이며 표 표 표 은 프로X.509 AC [ 4-7] [ 4-8] [ 4-9] AC

파일의 각 항목과 확장필드 에 관한 설명을 하고 있다, Attribute type .

- 148 -

- 149 -

- 150 -

- 151 -

그림 프로파일의 구조( 4-4)AC

표 프로파일의 항목[ 4-7] AC

항목 설명

acinfo

version 인증서의 버전을 나타내는 부분 로(default v1)

holder

의 소유자를 나타내는 부분이다 가 사용될AC . X.509 PKC

경우 이 값은 가 되어야 하며, baseCertificateID

는 소유자의 과 일치해야한baseCertificateID PKC serial

다.

issuer 의 발급자를 나타내는 부분AC

signature 서명을 검증하는데 사용되는 알고리즘의 식별자AC

serialNumber 인증서의 일련번호

attrCertValidityPeri

o인증서의 유효기간

attributes소유자에 대한 정보를 나타낸다 가 권한증명을 위AC . AC

해 사용될 때 이 필드는 의 집합을 포함한다privilege .

issuerUniqueID발급자이름의 재사용성을 제어하는 부분으로 발급AC AC

자의 에서 사용되지 않는다면 사용되지 말아야 한다PKC .

extension 의 확장필드AC

signatureAlgorithm 를 서명하기 위해 발급자가 서명한 알고리즘의 식별자AC

signatureValue 의 전자서명값AC

- 152 -

표 프로파일의 확장필드[ 4-8] AC

항목 설명

Audit Identity

이 항목은 을 목적으로 이 사용자를audit/logging audit trail

직접 식별하는 레코드를 포함하지 않는 경우 사용된다 대개.

의 경우 는 와 그리고 부가Audit Identity AC Issuer Serial

적인 정보를 통해 구성되어 진다.

AC Targeting

가 정해진 서버나 서비스에서만 동작 가능하도록 하는데AC

사용된다 즉 리스트에 존재하는 서버나 서. AC Targeting

비스만이 를 허용한다AC .

Authority Key Identifier 가 의 서명을 검증하는데 사용되어 진다AC verifier AC .

Authority Information

Access

가 의 상태를 검증하는데 사용되AC verifier AC revocation

어 진다.

CRL Distribution Points가 의 상태를 검증하는데 사용되AC verifier AC revocation

어 진다.

No Revocation Available에 적용가능한 정보가 생성되지 않았음을 나AC revocation

타낸다.

- 153 -

표 프로파일의[ 4-9] AC Attribute Type

항목 설명

Service Authentication

Information

이 은 를 서버나 서비스에게 알리며attribute AC holder

시스템을 위해 경우에 따라서 특정서비스를 위한 인증Legacy

정보 같은 를 포함할 수도 있다(username/password ) .

Access Identity

이 은 를 서버나 서비스에게 알려주며attribute AC holder

와 달리 인증정보를 포함Service Authentication Information

하지 않는다.

Charging Identity

이 은 어떠한 목적을 요구하기 위하여 를attribute AC Holder

식별한다 예를 들면 의 회사는 서비스에 대한 책임. AC Holder

을 갖는다.

Group 이 은 의 그룹소속 정보를 나타낸다attribute AC Holder .

Role이 은 에 할당된 역할에 관한 정보를 나타attribute AC Holder

낸다.

Clearance이 은 에 관련된 클리어런스 보안등급과attribute AC Holder (

관련있는 를 나타낸다) .

- 154 -

의 취소 및 권한위임4. AC

가 의 취소. AC

대개의 경우 정보를 발급하고 배포하는 시간보다 의 수명이 작으므로 짧AC revocation AC

은 생명주기를 갖는 는 별도의 기원을 필요하지 않는다 그러나 긴 생명주기AC revocation .

를 갖는 와 특별한 경우에 지원이 요구된다 에서는 표 과 같은 두AC revocation . AC [ 4-10]

가지의 구조가 정의 된다Revocation .

표 의[ 4-10] AC Revocation Scheme

구조 설명 비고

Never revoke

를 위한 정보가 생성되지 않- AC Revocation

으며 어떠한 지원이 이루어지지Revocation

않는다.

확장 필드에서 정의된- ‘No Revocation

옵션과 함께 사용된다Available' .

짧은 주기의

에 적절AC

Pointer in AC

는 자신의 확장필드에서 정의된AC Authority

나Information Access CRL Distribution

옵션을 사용하여 의 상태정Points revocation

보가 있는 위치를 가리킨다.

긴 주기의 에AC

적절

나 의 권한위임. AC

서버는 를 대신하여 다른 서버에게 클라이언트로서 행동할 수 있으며 이때 서버AC Holder

는 에 대한 권한을 위임받게 된다 권한위임의 발생은 발급자의 제어 하에서 이루어AC . AC

져야한다 권한위임을 위해 에서는 권한위임이 가능한 서버로 구성된 프록시 집합 의. AC (AC

체인 을 생성하고 관리하며 확장옵션과 같은 또 다른 확장옵션) AC Targeting

을 정의한다id-pe-ac-proxying .

- 155 -

만일 와 의 송신자가 둘 다 같은 의 집합 내에 존재한다면 의AC verifier AC AC Proxy AC

권한위임이 가능하다.

다음은 권한위임이 성공하는 조건이다.

송신자의 가 의 필드와 일치하고 현재 서버가 의 프록시 집합identity AC Holder AC▶

내에 존재할 경우

송신자의 가 의 집합 내에 존재하고 현재 서버기 의identity AC Proxy AC Targeting▶

그룹내에 존재할 경우

- 156 -

제 장 기본설계5 SecureSSO

본 장에서는 기반의 시스템 를 제안한다 제안된 는 구PKI SSO SecureSSO . SecureSSO PMI

조를 중심으로 장에서 제시한 설계목표를 만족하도록 설계되었다3 .

제 절 구조 및 구성요소1 SecureSSO

의 구조1. SecureSSO

가 기반구조. PMI

는 사용자의 권한정보를 제공하는 권한 인증서로 인 를 선택하였고SecureSSO X.509 v2 AC

의 생성 및 관리를 위해 구조를 기반으로 설계되었다AC PMI .

권한 서버(1)

기존의 연구에서 언급한데로 는 이미 가 발급하고 보증한 형태의 오프라PKC CA long-term

인 인증티켓 이므로 를 기반으로 사용사와 응용서버사이에 인증이 이루어 질 때PKC PKC

의 유효성을 증명하기 위한 중앙서버의 개입이 별도로 필요하지 않다 따라서. SecureSSO

는 사용자 인증보다는 사용사의 권한검증을 중앙에서 세어하는 의 와 같은PMI AC Issuer

권한 서버를 중심으로 설계된다· .

- 157 -

인증과 접근통제의 분리(2)

는 인증과 접근통제를 분리하어서 앞서 언급하였던 의 확장필드에 권한정보SccureSSO PKC

를 두는 방법의 문제점을 해결하고 또한 의SESAME PAC(Privilege Attribute Certificate)

과 같이 시스템내의 고유한 권한 인증서를 사용하기보다 는 개방된 표준인 의· X.509 v2 AC

를 지원함으로써 상호 호환성과 확장성을 제공한다.

를 이용한 접근제어(3) AC

는 권한 서버로부터 직접 를 받아서 응용 서버에게 전송하는SecurcSSO AC On-Line, Push

모델이다.

그림 사용자 인증 및 접근제어( 5-1)

그림 은 와 를 이용한 사용자 인중 및 접근통제의 과정을 나타내고 있다 사용( 5-1) PKC AC .

자는 응용서버에 있는 자원에 접근하기 위하여 와 를 함께 응용 서버에 제출한다PKC AC .

- 158 -

이때 의 는 로 선택되어 지며 이 값은 사용자가 와 함께 제AC Holder baseCertificateID AC

시한 의 및 값과 매칭 되어야 아다 응용서비는 제출된 를 통해 사PKC issuer serial . PKC

용자를 인증하며 인증이 끝난 후 를 통해 접근통제를 하게 된다 단 그림 처럼 용, AC . ( 5-2)

용 서

버가 화 될 수 없는 경우를 위해 는 필드의SSO AC Attributes Service Authentication

을 이용해서 사용자의 인증정보를 응용서버에게 제시할 수 있도록 한다Information Type .

그림 응용 서버 지원( 5-2) Non Single Sign-On

의 권한위임과 취소(4) AC

에서 의 권한위임은 의 확장필드에서 정의된 의SecureSSO AC AC id-pe-ac-proxying Type

확장옵션을 사용하여 이루어 진다.

는 의 취소를 위해 특별한 메카니즘을 지원하기 않으며 대신 짧은 생명주기SecureSSO AC

를 갖는 를 생성하는 정책을 적용한다 이를 위해 확장옵션AC . ‘No Revocation Available'

을 사용한다.

- 159 -

표 기반의 구조 특성[ 5-1] PMI SecureSSO

항목 특성 비고

중앙서버가 아닌Authentication Server Privilege

를 채택Server

중앙 집중된 접근

제어 가능

인증과 접급제어인증을 위한 와 접근제어를 위한 를PKC AC

통해 분리

표준기술적용을 통

한 호환성과 확장

성 제공

권한위임의 확장필드에서 정의된AC

을 이용하여 지원함id-pe-ac-proxying Type

집합을 통Proxy

해 권한위임이 결

정됨

취소특별한 메카니즘을 지원하지 않고 다만 짧은

주기의 를 생성할 것임AC

취소절차에 대한

엄격한 정책을 통

해 위험성을 제거

할 수 있음

Non Single

Sign-On

지원Application

의 중AC Attribute type Service

을 이용하여Authentication Information Type

지원함

그림 의 구조( 5-3) Secure SSO

- 160 -

나 구성요소 및 기능.

제안된 일반적인 의 구조는 그림 와 같다SecureSSO ( 5-3) .

는 다음과 같은 구성요소로 나뉘며 각 구성요소간 자세한 인증프로토골은 후에SecureSSO

언급된다.

서버(1) SecureSSO

서버는 사용자가 응용 서버에 접속할 수 있도록 를 발급해 주는 역할을 한SecureSSO AC

다 사용자로부터 특정 서비스를 위한 를 요청 받으면 서버는 자체. AC SecureSSO

에 저장된 사용자의 권한정보를 중심으로 를 생성하게 된다 사용자는 를SecureDB AC . AC

받기 위한 요청을 할 때마다 서버에 대한 인증을 받아야 한다 인증은 사용자SecureSSO .

의 와 그에 대응하는 개인키를 가지고 있다는 증거를 제시함으로써 이루어진다 사용자PKC .

는 를 요청할 때마다 서버로부터 인증을 받아야 하지만 와 개인키를 통AC SccureSSO PKC

해 인증이 이루어지기 때문에 기음 개인키 저장소로부터 개인키를 가져오기 위한 한번의 인

증을 거치게 되면 사용자 입장에서는 더 이상의 인증을 하지 않아도 되는 의 기능을 제SSO

공받는다 또한 는 커버러스나 등과 달리. SecureSSO SESAME TGT(ticket Granting

대신 를 통해 를 요청하므로 특별한 초기 인증의 과정이 없다Ticket) PKC AC .

클라이언트(2) SecureSSO

클라이언트는 웹브라우저의 플러그인 형태로 구현되며 사용자의 개인SecureSSO (Plug-In)

키 등의 정보를 통해 사용자로 하여금 응용 서비스를 제공받도록 하는 역할을 한, PKC, AC

다 클라이언트가 초기에 서버에 인증을 하면 사용자가 접근할 수. SecureSSO SecureSSO

있는 서비스 리스트와 사용자의 설정에 맞게 구성된 사용자 맞춤 페이지(Personalized

가 생성 된다page) .

- 161 -

사용자는 맞춤 페이지에 열거된 서비스 리스트 중에서 원하는 서비스를 선택하여 응용 서버

에 접속할 수 있다.

사용자가 서버나 응용 서버에 인증을 받기 위해 에 대응하는SecureSSO SecureSSO PKC

개인키를 소유하고 있다는 증거를 보여주어야 한다 사용자의 개인키는 안전하게 보관되어.

야 하며 다음과 같은 두 가지 방법으로 저장되어 질 수 있다.

표 개인키의 두가지 저장방법[ 5-2]

항목 파일기반의 저장방법 Smart Card / USB Token

저장장소 클라이언트의 하드디스크내부의Smart Key/USB Token

메모리

장점별도의 장치가 필요없다 구현이.

단순하다.

개인키를 안전하게 보관할 수

있다 휴대할 수 있으므로 장소.

의 제한이 없다.

단점사용장소가 제한적이다 해킹당.

할 위험성이 비교적 많다.

잃어버릴 우려가 있다 지원 프.

로그램을 설치하여야 한다.

위의 방법은 사용자의 정책에 따라 적용되어 질 수 있으며 에서는 두 가지 방법SecureSSO

을 다 지원한다.

사용자는 개인키에 접근하기 위하여 클라이언트에게 초기에 한번 비밀번호를SecureSSO

제시하며 이후에는 클라이언트가 자동으로 개인키에 접근한다SecureSSO .

응용 서버(3) SecureSSO

응용 서버는 사용자 접근통제 부분을 화한 응용서버이거나 혹은SecureSSO SecureSSO

앞에 에이전트나 프록시를 두어서 의 기능을 제공하도록 설정된다SecureSSO .

- 162 -

응용 서버는 그림 처럼 사용자의 를 통해 사용자 인증을 수행한 후SecureSSO ( 5-1) PKC ,

를 통해 접근통제를 결정을 한다AC .

및(4) CA Server Directory Server

는 시스템 내에서 사용되어 지는 를 생성하고 발급 등록 취CA Server SecureCSSO PKC , , ,

소 관리하는 역할을 하며 는 발급된 와 생성된 을 저장하는 역, Directory Server PKC CRL

할을 한다.

서비스 접근절차2.

에서 이루어지는 서비스의 접근절차는 다음과 같다SecureSSO .

가 클라이언트 로그온. SecureSSO

그림 클라이언트 로그온( 5-4)

사용자가 웹 브라우저 상에서 포털 사이트를 접속하면 초기 인증을 요청하는 페이지가 전송

되어 진다.

- 163 -

사용자가 초기 인증을 시도하게 되면 초기 인증요청 페이지의 플러그인 프로그램이 초기화

되고 사용자의 개인키를 가져오기 위해 사용자 인증 과정을 거친다 인증이 성공하면 플러.

그인 프로그램은 처럼 개인키 소유를 증명하는 전자서명을 계산하여서 와SecureSSO PKC

함께 방법으로 포털 사이트에 전송한다 포털 사이트는 서버와의 인터페POST . SecureSSO

이스를 통하여 사용자를 인증한 후 접근가능 페이지 리스트등 사용자의 정보를 추출하여,

사용자를 위한 맞춤페이지를 작성해서 사용자에게 전송한다.

나 서비스 접근 요청.

서비스 접근 요청과정은 응용서버의 화나 혹은 에이전트가 허용될 경우와 그렇지 못할SSO

경우에 따라 처리 과정이 다르다 응용서버의 화나 혹은 에이전트가 허용될 경우 맞춤. SSO ,

페이지에서 사용자가 원하는 페이지를 선택하게 되면 플러그인 프로그램은 우선 저장소AC

에 요청한 가 존재하는지를 검토한 후에 가 없다면 초기 인증과 마찬가지 방법으로AC AC

포털 사이트에 를 요구하게 된다 에이전트 사이트는 서버와의 인터페이스AC . SecureSSO

를 통해서 사용자를 인증한 후 를 생성하고 사용자의 개입 없이 요청 사이트로 자동 전AC

환할 웹 페이지와 함께 전송한다 웹 페이지가 사용자의 웹브라우저에 전송되면 플러그인이.

초기화되어서 전자서명을 계산하고 전송된 와 함께 방법으로 요청 사이트AC, PKC POST

에 전송한다 여기서 웹브라우저는 새 창에서 열기로 열리고 앞서 언급한 동작들은 사용자.( ‘ '

의 개입 없이 수행된다 플러그인은 이후의 재사용을 위해 를 저장소에 저장한다 요청사. AC .)

이트에서는 와 전자서명을 검증한 후 결과를 나타내는 페이지를 사용자에게 전송AC PKC, ,

한다.

- 164 -

응용서버의 화나 혹은 에이전트가 허용되지 않을 경우 맞춤페이지에서 사용자가 원하SSO ,

는 페이지를 선택하게 되면 플러그인 프로그램은 우선 저장소에 요청한 가 존재하는AC AC

지를 검토한 후에 가 없다면 초기 인증과 마찬가지 방법으로 에이전트 사이트에 를AC AC

요구하고 가 전송되기를 기다린다 에이전트 사이트는 서버와의 인터페이스AC . SecureSSO

를 통해서 사용자를 인증한 후 를 생성하고 사용자의 개입 없이 요청 사이트로 자동전환AC

할 웹 페이지와 함께 전송한다 웹 페이지가 사용자의 웹브라우저에 전송되면 플러그인이.

초기화되어서 진송된 를 저장소에 저장한다 여기서 웹브라우저는 새 창에서 열기로 열AC . ' '

린다 이때 를 기다리던 맞춤페이지의 플리그인은 가 저장됨을 감지하고 에서 사.) AC AC AC

용자의 로그온 정보를 추출하여 요청 사이트가 열리기까지 기다렸다가 사용자의 개입 없이

로고온 정보를 입력한 후 요청사이트에 대한 인증을 요청한다 요청 사이트에서는 기존의, .

방법으로 사용자를 인증하여 인증결과를 사용자에게 전송한다.

그림 서비스 접근 과정( 5-5)

- 165 -

3. Single Sign-On

가 지원. Legacy System

는 화 될 수 없는 시스템을 시스템과 연계시키기 위해SecureSSO SSO Legacy SecureSSO

다양한 방법을 지원한다 는 시스템에게 사용자의 적절한 인증 정보를. SecureSSO Legacy

제공하기 위해 서버에 있는 에 사용자의 인증 정보를 저장하여 통합SecureSSO SecureDB

관리한다 저장된 사용자의 인증정보는 가 생성될 때 의. AC , AC Service Authentication

을 통해 에 저장되어서 시스템에 전달되어 진다Information Attribute Type AC Legacy .

나 유연성있는 구조.

그림 적용범위( 5-6) Single Sign-On

- 166 -

는 기능을 지원하기 위해 다양한 환경과 요구상황에도 적응할 수 있는 유SecureSSO SSO

연성있는 구조를 갖는다 의 적용범위는 그림 과 같이 세 가지로 나눌 수 있다 첫. SSO ( 5-6) .

번째는 응용 서버 상에서 가 지원될 수 없는 경우 두 번째는 응용 서버 상에서 수정할SSO ,

수 없으나 를 지원하기 위해 에이전트나 프록시 서버가 가능한 경우 세 번째로는 응용SSO ,

서버를 화 할 수 있는 경우이다SSO .

표 후 의 세 가지 적용범위[ 5-3] Single Si -On

항목 서버 수정가능 에이전트 가능시스템과SSO

연계불가능

구조 브로커 에이전트 브로커- 클라이언트 에이전트

장점통합적이고 안정적

인 인증

통합적이고 안정적인 인증 가

능 서버의 모듈을 수정할 필요

가 없음

응용 서버를 수정할

필요가 없음

단점 의 수정Server시스템과의 근본적인 통SSO

합아님보안성이 떨어짐

지원

방법

라이SecureSSO

브러리

에이전트SecureSSO

프록시SecureSSO

로그인 자동화 에이전

트

표 은 세 가지 경우의 특성을 나타내었으며 는 그림 처럼 위의 세 가[ 5-3] SecureSSO ( 5-7)

지 경우를 지원할 수 있도록 설계되어 진다.

- 167 -

그림 의 지원방법( 5-7) SecureSSO Single Sign-On

그림 프록시를 이용한 클라이언트 지원( 5-8)

- 168 -

위의 세 가시 경우이외에도 클라이언트 측면에서 클라이언트를 수정할 수 있는 경우와 수정

할 수 없는 경우를 고려할 수 있다.

는 이 두 가시 경우를 위해 라이브러리 로그인 자동화 클라이언트SecureSSO SecureSSO , ,

프록시의 세 가지 기법을 지원한다.

그림 로그인 자동화를 이용한 클라이언트 지원( 5-9)

라이브러리의 경우는 클라이언트를 수정할 수 있는 경우로서 라이브러리를 이SecureSSO

용하여 클라이언트 프로그램의 인증 부분을 수정할 수 있고 클라이언트 프록시와 로그인,

자동화의 경우는 클라이언트 프로그램을 수정할 수 없는 경우로서 그림 그림 와( 5-8),( 5-9)

같이 적용된다.

- 169 -

제 절 의 인증 프로토콜2 SecureSSO

구성요소 간의 인증 프로토콜은 그림 과 같다SecureSSO ( 5-8) .

1. AC_REQ : S, C, PKCC, {Krandc}Ps, {Authenticator, {Authenticator}P-1c}Krandc

2. AC_REP : C, S, PKCs, AC, {Krands}Pc, {App, n, tss, {App, n, tss}P-1s}Krands

3. AP_REQ : App, C, PKCc, AC, {Krandc}PApp, {n, tsc, {n, tsc}P-1c)Krandc

4. AP_REP C, App, PKCApp, {KrandApp}Pc, {n, tsApp, {n, tsApp}P-1App}KrandApp

Authenticator = App, Timpexp, n, tsc

그림 의 구성요소간 인증 프로토콜( 5-10) SecureSSO

- 170 -

표 이증 프로토콜의 기호[ 5-4]

기호 설명

S 서버SecureSSO

C 클라이언트의 사용자SecureSSO

App 응용 서버SecureSSO

Krandx 의 구성요소 가 임의로 생성한 대칭키SecureSSO X (S, C, App)

PX 구성요소 의 공개키SecureSSO X (S, C, App)

AC Attribute Certificate

PKCx 구성요소 의 인증서SecureSSO X (S, C, App) X.509 v3

Timeexp 클라이언트가 요청하는 의 희망 종료시간SecureSSO AC

n nonce

tsx 에서 보낸X Time Stamp

각 구성요소간의 인증은 기본적으로 구성요소들의 와 전자서명을 통해 이루어 진다 인PKC .

증을 요청할 때 인증 요청 객체는 인증 요청 시간 정보인 타임스탬프와 임의로 생성한,

값을 생성하고 이 값들을 개인키로 전자서명하여 보냄으로써 재전송 공격을 방지하고nonce

와 대응하는 개인키를 소유하고 있다는 증거를 제시한다 인증 수행 객체는 인증 요청PKC .

객체의 공개키로 전자서명 값을 검증하고 타임스탬프의 유효성을 검증하여 인증을 수행한

다 그리고 나서 인증 수행 객체의 타임스탬프와 인증 요청 객체가 전송한 값을 자신. nonce

의 개인키로 전자서명하여 인증 요청 객체에게 전송함으로써 응답을 하게 된다 인증 요청.

객체는 인증 수행 객체와 공개키를 통해서 인증 수행 객체의 전가서명을 검증하고 값nonce

을 추출하여 자신이 보냈던 값과 비교한다 또한 인종 수행 객체의 타임스탬프를 추출하여.

유효성을 검증한다 이처럼 의 인증은 인증 요청 객체가 와 전자시명을 전. SecureSSO PKC

송하고 그에 대한 응답을 인증 수행 객체의 와 전자서명으로 받음으로써 이루지는 상PKC

호인증이다.

- 171 -

부인봉쇄를 지원하기 위하여 및 타임스탬프 그리고 이들의 선자서명은 상대방에서nonce

보내온 와 함께 보관되어 진다PKC .

1. AC_REQ

클라이언트는 를 통해 서버에게 를 요청한다SecureSSO AC_REQ SecureSSO AC . AC_REQ

의 항목은 서버의 식별자로서 서버로 하여금 요청메시지가 자신S SecureSSO SecureSSO

에게 전송되는 것임을 인식할 수 있도록 하고 항목은 송신자가 클라이언트의C SecureSSO

사용자라는 것을 알려준다 항목은 클라이언트의 사용자 인증서이며 항. PKCC SecureSSO

목 는 접속하고자 하는 의 응용 서버 식별자로 이 를 위한 가 생APP SecureSSO Server AC

성되어야 함을 나타내고 있다 항목. Timeexp는 의 희망만기시간을 나타내며AC SecureSSO

서버는 이 값을 참조하여 의 유효기간인 값을 결정한다 항목AC attrCertValidityPehod . tsC

는 를 요청하기 위해 현재 메시지가 생성된 시간을 나타낸다 클라이언트가AC . SecureSSO

를 생성했기 때문에 서버는 메시지의 시간 유효성을 검증할 수 있다 즉tsC SecureSSO .

서버는SecureSSO tsc가 현재시간을 중심으로 지정된 시간의 범위 보통 분 에 속하지 않( 5 )

는 경우 요청을 거부함으로써 재전송 공격을 예방할 수있다 항목 은 클, AC . n SecureSSO

라이언트에 의해 생성되는 임의의 값이며 을통해서 클라이언트는n SecureSSO SecureSSO

서버의 응답이 유효하다는 것을 확인할 수 있다.

클라이언트는SecureSSO App, Timeexp, n, tsc로 이 루어 진 를 자신의 개인Authenticator

키로 전자서명함으로써 서버에게 사용자가 에 대응하는 개인키를 소유하SecureSSO PKCC

고 있다는 것을 증명하며 더불어 값의 무결성을 보장한다 클라Authenticator . SecureSSO

이언트는 임의의 대칭키인 를 생성하고 이 대칭키를 통하여 와Krandc Authenticator

의 전자서명인Authenticator {Authenticator}P-1 를 암호화한다 그리고 나서 이c . Krandc를

서버의 공개키로 암호화하어 의 기밀성을 유지하도록 한다SecureSSO Authenticator .

- 172 -

그림 에 의 생성과정과 유효성 검증과정이 간략하게 나타난다( 5-11) AP_REQ .

그림 와 에서의 인증절차( 5-11) AC_REQ AC_REP

2. AC_REP

를 받으면 서버는 그림 처럼 사용자에 대한 인증작업을 수행한AC-REQ SecureSSO ( 5-11)

다 사용자 인증 후 서버는 에 적절한 를 생성하며 타임스탬프인. , SecureSSO App AC tss를

구하고 에 있었던 와 과 함께 서버의 개인키로 전자서명한다 그AC_REQ App n SecureSSO .

리고 나서 서버는 임의의 대칭키 를 생성하고 생성된 키를 통해SccureSSO Krands tss,

와 그리고App n tss와 의 전자서명값을 암호화하며 를 서버의App, n Krands SecureSSO

공개키로 암호화한다.

- 173 -

서버는 자신의 와 그밖에 앞서 언급된 값들을 통해 을 생성SecureSSO PKC, AC AC_REP

하고 클라이언트에게 전송한다 클라이언트는 을 받은 후SecureSSO . SecureSSO AC_REP ,

전송된 서버의 가 유효한 인증서 인지를 검증하고 사용자의 유효성을 검증SecureSSO PKC

하는 절차와 비슷한 과정을 거쳐 값을 추출한 다음 이 값이 에서 자신이 보냈던n AP_REQ

값과 같은지를 비교하여 재전송 공격을 방지한다 또한n . tss의 값을 추출하여 유효성을 검

증한다 여기서 부인봉쇄의 지원을 위해 서버는 중에서. SecureSSO AC_REQ Authenticator

와 의 전자서명 및 사용자의 를 보관하고 클라이언트는Authenticator PKC SecureSSO

중에서AC_REP tss 와 그리고, App n tss와 의 전자서명과 서버의App, n SecureSSO PKC

를 보관해 둔다.

3. AP_REQ

를 얻은 후 클라이언트는 응용 서버에게 서비스 접속요구를 한AC , SecureSSO SecureSSO

다 서비스 접속요구는 서버로부터 받은 를 포함한 것 외에는 와. SecureSSO AC AC_REQ

유사하다 는 과. Client n tsc를 구하고 과 값을 사용자의 개인키로 전자서명한다 그리고n tsc .

나서 임의로 대칭키 생성하고 이 키로 과Krandc n tsc 과, n tsc의 전자서명값을 암호화한다.

Krandc는 응용 서버의 공개키로 암호화되어 보호되어 진다 는 와 사SecureSSO . Client AC

용자의 그리고 앞서 언급된 값들을 통해 메시지를 생성하여 옹용 서버에게PKC AP_REQ

전송한다.

4. AP_REP

를 전송받으면 응용 서버는 서버와 같은 방법으로 사용자AP_REQ SecureSSO SecureSSO

를 인증한다 즉 사용자의 와 사용자의 개인키로 생성된 전자서명. PKC , tsc의 유효성을 검증

함으로써 사용자 인증을 수행한다.

- 174 -

응용 서버는 사용자의 를 검증한 후 자신의 개인키를 통해 를 복호화하여PKC , Krandc n,

tsc 과, n tsc의 전자서명을 추출한다 그리고 나서 사용자의 공개기롤 이용하여 과. n tsc의 전

자서명을 검증하고 tsc가 현재의 시간범위에 속하는지를 검토한다 이와 같은 절차로 사용자.

인증과정이 수행되고 나면 응용 서버는 전송된 내에 있는 사용자의 를 검사하AC Attribute

여 사용자가 요청한 서비스에 대한 권한을 갖고 있는지 검증한다 권한검증이 종료되면 응.

용 서버는 자신의 타임스탬프인 tsAPP를 구하여 이 값과 함께 에서 받은 의 값을AP_REQ n

자신의 개인키로 전자서명한다.

그림 와 에서의 인증절차( 5-12) AP_REQ AP_REP

그리고 나서 임의의 대칭키 를 생성하여KrandApp tsApp 그리고 전자서명을, n KrandAPp로

암호화한다. KrandAPP는 사용자의 공개키로 암호화된다 응용 서버는 자신의 와 앞서. PKC

언급한 값들을 통해 를 생성하여 에게 전송한다AP-REP Client .

- 175 -

가 를 전송받으면 응용 서버의 와 전자서명Client AP_REP PKC , tsAPP 그리고 의 유효성을n

검증한다.

여기서 부인봉쇄의 지원을 위해 응용 서버는 중에서AP_REQ tsc 그리고, n tsc 의 전자서, n

명 및 사용자의 를 보관하고 클라이언트는 중에서PKC SecureSSO AP_REP tsApp 그리고, n

tsApp 의 전자서명과 응용 서버의 를 보관해 둔다, n PKC .

- 176 -

제 절 설계3 SecureDB

본 절에서는 사용자의 로그인 정보와 권한정보 기타 세부사항을 저장하기 위한, SecureDB

를 설계한다.

데이터베이스 테이블1.

가. ISUserInfo

는 사용자의 사용자의 그룹 역할 등 를 위한 사용자의 기본 정보를 저ISUserInfo DN, , SSO

장하는 테이블로 사용자의 을 통해 인증서와 매칭된다 테이블의 내용은 표 허와 같DN . [ 5-

다.

표 테이블[ 5-5] ISUserInfo

필드 형식 의미 비고

*sSerial VARCHAR(25) 사용자 등록번호 사번이나 주민등록번호

sName VARCHAR(100) 사용자 이름

sUserDN VARCHAR(100) 사용자 인증서의 DN

sRoleCode CHAR(5) 사용자의 역할정보

sGroupCode CHAR(5) 사용자 소속그룹 코드

sLastLogOnTim

eCHAR(14) 최근 로그온 시간 YYYYMMDDHHMMSS

nLogOnFailCnt INTEGER 로그온 틀린 횟수

sAccessIP CHAR(12) 로그인 가능 위치

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

나. ISFootprint

는 사용자의 기본 정보 이외의 신상정보를 저장하는 테이블이다ISFootprint .

- 177 -

표 테이블[ 5-6] ISFootprint

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

다. ISGruopInfo

는 사용자가 속하는 그룹에 관련된 정보를 저장하는 테이블이다 그룹의 역할ISGI-uopInfo .

정보는 사용자 개개인의 역할정보에 우선한다.

표 테이블[ 5-7] ISGnDpInfo

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

라. ISOrganization

은 회사에 관련되 정보를 저장하는 테이블이다ISOrganization .

- 178 -

표 테이블[ 5-8] ISOrganization

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

마. ISDepartment

는 사용자가 속한 부서의 정보를 저장하는 테이블이다ISDepartment .

표 테이블[ 5-9] ISDepartment

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

바. ISTitle

은 지급 정보를 저장하는 테이블이다ISTitle .

표 테이블[ 5-10] ISTitle

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

- 179 -

사. ISAthenInfo

는 사용자의 서비스별 인증정보를 저장하는 테이블이다 이 테이블을 통해ISAthenInfo .

시스템에 대한 아이디와 패스워드를 저장한다Legacy .

표 테이블[ 5-11] ISAthenInfo

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

아. ISServiceInfo

는 서비스에 대한 정보를 저장한다ISServiceInfo .

표 테이블[ 5-12] ISAthenInfo

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

- 180 -

자. ISRoleInfo

는 역할정보를 저장하는 테이블이다ISRISeInfo .

표 테이블[ 5-13] ISRolelnfo

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

차. ISRoleServRel

은 역할과 서비스간의 관계를 나타내는 테이블이다ISRoleServRel .

표 테이블[ 5-14] ISRoleServRel

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

카. ISAttribute

는 권한 속성을 저장하는 테이블이다ISAttribute .

- 181 -

표 테이블[ 5-15] ISAttribute

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

타. ISRoleAttrRel

는 속성과 역할의 관계를 나타내는 테이블이다ISRoleAttrRel .

표 테이블[ 5-16] ISAttribute

가 붙은 필드는 기본키 를 나타낸다* (Primary Key) .※

- 182 -

2. E-R(Entity Relation) Diagram

그림 객체 구성도( 5-13)

- 183 -

그림 객체 관계 디이어그램( 5-14)

- 184 -

제 장 시스템 상세 설계 및 구현6

본 장에서는 기반의 시스템의 구성요소인 기반의 네트워크 전송 라이PKI SSO Open SSL,

브러리 인증서 기반의 사용자 인증 및 접근 통제 라이브러리SecureSSLLib,

인증서버 클라이언트 응용 서버 사용자 관리 시스템SecureCertLib, SSO , SSO , SSO , SSO

에 대한 상세 설계 및 구현을 제시한다.

제 절1 SecureSSLLib

네트워크를 통한 데이터 전송의 경우 다양한 보안 문제가 발생하므로 네트워크 구성요소들,

사이에 안전한 통신을 위한 신뢰성 있는 채널이 요구된다 는 시. SecureSSLLib SecureSSO

스템 구성요소 간의 안전하고 신뢰성 있는 네트워크 통신을 위해 적용되는 라이브러리이다.

는 기존의 보안 프로토콜인 에 국내에서 개발된 암호 알고리즘과SecureSSLLib OpenSSL

해쉬 알고리즘을 추가하여 국내 실정에 맞는 신뢰성 있고 안전한 보안 프로토콜을 지원한

다.

분석1. OpenSSL

가 의 개요. OpenSSL

은 범용적인 목적의 암호 라이브러리는 물론 과 프로토콜을 실행하는 오OpenSSL SSL TLS

픈 소스 툴킷으로 우수한 라이브러리를 기반으로 한다 현재 은, SSLeay . OpenSSL

까지 개발되어 소스가 공개되어 있다OpenSSL v0.9.6b , .

프로그램은 쉘로부터 의 암호 라이브러리의 다양한 암호 함수들을 사용OpenSSL OpenSSL

하기 위한 커맨드 라인 툴이다.

- 185 -

나 의 기능. OpenSSL

은 네트워크 보안 프로토콜로 네트워크 환경에 다양한 보안 서비스를 제공한다OpenSSL .

에서 제공하는 기능은 다음과 같다OpenSSL .

키 파라미터 생성RSA, DH, DSA▶

인증서 생성X.509 , CSRs, CRSs▶

메시지 다이제스트 계산▶

암호화와 복호화▶

클라이언트와 서버 테스트SSL/TLS▶

서명된 또는 암호화된 메일의 운용S/MIME▶

은 과 프르토콜을 구현한 오픈 소스 툴킷이다 다음절에서 과 에OpenSSL SSL TLS . SSL TLS

대해서 언급한다.

분석2. SSL(Secure Socket Layer)

가 의 개요. SSL

은 넷스케이프 사에서 년 월 처음 제안되어 을 거쳐 현재SSL 1994 7 , SSL v1.0, SSL v2.0

사용되고 있는 버전은 이다 은 웹 보안의 대명사로 알려져 있는 보안 프로토SSL 3.0 . SSL

콜이지만 웹과 같은 특정 응용을 워한 보안프로토콜이 아닌 일반적인 인터넷 보안 프로토,

콜로도 사용될 수 있다.

은 응용계층과 전송계층 사이에서 클라이언트와 서버간의 안전한 채널을 형성해 주는SSL

역할을 수행하며 비밀성 무결성 인증의 세가지 보안 서비스를 제공하고 데이터 압축 기능, ,

을 제공하는 보안 프로토콜이다.

- 186 -

나 의 구조. SSL

은 그림 에서 보는 바와 같이 두 부분 계층 으로 나누어져 있다 하나는 동작SSL ( 6-1) ( ) . SSL

에 대한 관리를 위해 사용되는 핸드쉐이크 프로토콜SSL , SSL Change Cipher Spec, SSL

프로토콜 부분이고 다른 한 부분은 실질적인 보안 서비스를 제공하는 레코드Alert , SSL

프로토콜 부분이다.

클라이언트와 서버가 을 이용해 연결을 할 경우 먼저 을 수SSL SSL Handshake Protocol

행하여 한 세션동안 보안 서비스 제공에 사용되는 세션키 암호 알고리즘 인증서 등과 같, ,

은 암호 매개변수를 서로 공유하게 된다 여기에서 생성된 세션 정보는. SSL Record

에서 보안 서비스를 제공하는 데 이용된다Protocol .

그림 구조( 6-1) SSL/TLS

세션 정보는 다음과 같은 요소들로 구성된다.

- 187 -

세션 정보▶

세션 식별자 서버가 생성하는 임의의 바이트- :

서버와 클라이언트의 인증서 서버와 클라이언트 인증서- : X.509

압축 방법 암호화하기 전에 데이터를 압축하는데 사용할 알고리즘- :

이것은 와 같은 표기를 사용하여 정의- Cipher Spec: "SSL_RSA_WITH_DSS_CBC_SHA"

되는데 는 공개키 알고리즘 는 암호화 알고리즘 는 계산에 이용, RSA , DSS-CBC , SHA MAC

되는 해쉬 알고리즘을 나타내며 세션키 크기 및 해쉬값의 크기를 포함하고 있다, .

은 모든 알고리즘을 사용하지 않음을 나타냄SSL_NULL_WITH_NULL_NULL

클라이언트와 서버가 공유하는 바이트 비밀 정보로써 암호화에 사용되-Master Secret: 48 ,

는 세션키를 생성하는데 이용

재사용 여부 클라이언트가 서버에 연결을 재시도할 경우 이미 생성된 세션정보를 재사용- :

할지를 나타내는 플래그

이러한 세션 정보는 재사용이 가능하며 송수신 되는 모든 메시지의 보안을 위해, SSL

에서 사용된다 세션 정보의 일부이지만 클라이언트가 서버에 연결을 한Record Protocol .

후 종료할 때까지만 사용되는 연결 정보가 별도로 존재하는데 다음과 같은 구성요소로 이,

루어져 있다.

연결 정보▶

클라이언트가 생성하는 임의의 난수- Client Random:

서버가 생성하는 임의의 난수- Server Random:

서버가 전송하는 데이터의 을 계산하는데 사용되는 비- Server Write MAC Secret: MAC

밀키

- 188 -

클라이언트가 전송하는 데이터의 을 계산하는데 사용- Client Write A4AC Secret: MAC

되는 비밀키

서버가 전송하는 데이터를 암 복호하는 데 사용하는 비밀키- Server Write Key: /

클라이언트가 전송하는 데이터를 암 복호화하는데 사용하는 비밀키- Client Write Key: /

모드와 같은 블록 암호에서 사용되는 값- Initializtion Vectors(IVs): CBC IV , Server

와 두 개로 이루어진다Write Key IV ClientWhte IV .

송수신되는 각 메시지에 대한 순서번호- Sequence numbers:

연결 정보는 클라이언트가 서버에 연결할 때마다 매번 새로 생성되는 비밀정보이다 그러나.

등의 프로토콜과 달리 는 요청과 응답 두 메시지로 연결과 종료가TELNET, FTP HTTP

매번 이루어지기 때문에 연결 정보가 매우빈번하게 발행하는 문제점이 나타날 수 있다 따.

라서 웹 서버와 클라이언트는 연결 정보의 유효시간의 따로 유지하여 이러한 문제점을 해결

하고 있다.

다 에서 제공하는 보안 서비스. SSL

은 상호 인증 무결성을 위한 메시지 인증 코드SSL (Mutual Authentication), (MAC:

기밀성을 위한 암호화 등을 제공함으로써 클라이언트와Message Authentication Code),

서버 사이에 안전한 데이터 통신을 제공한다 또한 이 프로토콜은 암호화 메시지 압축 메. , ,

시지 인증 코드 을 위해 사용되는 알고리즘을 선택하는 것이 가능하다 이렇게 함으로(MAC) .

써 암호 제품 사용에 대한 법적인 문제 수출입 등에 따른 제반 문제에 맞춰 특정 서버에서,

암호알고리즘을 선택할 수 있으며 새로운 알고리즘을 쉽게 이용하는 것이 가능하다, . SSL

프로토콜에 의해 제공되는 보안 서비스는 다음과 같다.

- 189 -

두 응용간의 기밀성 서비스(1)

등과DES(Data Encryption Standard), RC4(Rivest Cipher version four, Ron's Code 4)

같은 대칭키 암호화 알고리즘을 사용하여 제공되며 이때 사용되는 비밀키는 핸드쉐이크 프,

로토콜을 통해 생성된다 기밀성을 필요로 하는 다양한 어플리케이션 각각에 대해 여러 가.

지 암호 알고리즘을 제공할 수 있다.

클라이언트와 서버의 상호 인증(2) (Mutual Authentication)

연결 설정 과정에서 서로간에 신뢰할 수 있도록 클라이언트와 서버가 서로에 대해 인증을

할 수 있도록 하는데 와 같은 비대칭 키 암호 알고리, RSA(Rivest, Shamir and Adleman)

즘 와 같은 전자 서명 알고리즘과 공개키 인증서, DSS(Digital Signature Standard) X.509

가 사용된다.

서버의 인증서는 클라이언트가 신뢰할 수 있는 서버인지 확인하기 위해 사용하며 반대로,

서버는 신뢰할 만한 클라이언트인지 확인하기 위해 클라이언트의 공개키 인증서를 요구할

수도 있다.

메시지 무결성 서비스(3)

내부적으로 누군가 데이터 전송을 방해할 수 없도록 하거나 재전송 공격에 이용할 수없도록

데이터의 기밀성을 제공하는데 키를 사용하는 기법, MAC (Message Authentication Code)

을 함께 이용하여 데이터 변조 여부를 확인할 수 있다.

라 프로트콜의 동작. SSL

- 190 -

은 크게 암호 알고리즘 압축 방법 및 키 등의 정보를 공유하기 위해 클라이언트와 서SSL ,

버가 서로 협상하는 핸드쉐이크 프로토콜 단계와 이 정보를 이용하여 보안 서비스를SSL

제공하는 레코드 프로토콜 단계로 구분되고 프로토콜들은 각 프로토콜의 구성요SSL SSL

소를 가지고 동작한다.

핸드쉐이크 프로토콜(1) SSL

그림 핸드쉐이크 프로토콜( 6-2) SSL

- 191 -

한 세션동안 이용되는 암호 매개변수는 핸드쉐이크 프로트콜에 의해서 생성되는데 이SSL ,

것은 레코드 계층의 위에서 동작한다 이 프로토콜은한 세션에서 사용되는 비밀정보를SSL .

공유하기 위해 이용된다 클라이언트와 서버가 처음으로 통신을 시작할 때 서로 프로. SSL

토콜 버전을 확인하고 암호알고리즘을 선택하고 선택적으로 서로를 인증하고 공유할 비밀, ,

정보를 생성하기 위해 공개키 암호 기법을 사용한다 이러한 처리는 그림 와 같은 핸드. ( 6-2)

쉐이크 프로토콜에서 수행된다.

가( ) Hel1o Request

이 메시지는 서버가 클라이언트에게 보낼 수 있는 메시지이지만 핸드쉐이크 프로토콜이 이

미 진행 중이면 클라이언트는 이 메시지를 무시해 버린다.

나( ) Client Hello

클라이언트는 서버에 처음으로 연결을 시도할 때 메시지를 통해 클라이언트ClientHello

버전 클라이언트에서 생성한 임의의 난수 세션 식별자 리스트 클라이SSL , , , Cipher Suit ,

언트가 지원하는 압축방법 리스트 등의 정보를 서버에 전송한다.

다( ) Server Hello

서버는 메시지를 처리한 후 메시지 또는Client Hello Handshake Failure Alert Sewer

메시지를 전송하게 된다 이 단계에서 서버는 서버의 버전 서버에서 생성한Hello . SSL ,

임의의 난수 세션 식별자 클라이언트가 보낸 리스트 중에서 선택한 하나의, , Cipher Suit

클라이언트 압축 방법리스트에서 선택한 압축 방법 등의 정보를 클라이언트에Cipher Suit,

보낸다.

- 192 -

라( ) Server Certificate or Server Key Exchange

서버 인증을 위한 자신의 공개키 인증서를 가지고 있다면 메시지를 즉. Server Certificate

시 클라이언트에 전송한다 일반적으로 인증서를 사용한다 인증서가 없거나 인. X.50g v3 . ,

증서를 서명용으로만 사용할 수 있다면 인증서 서명용 인증서의 경우 또는(DSS , RSA )

키 교환을 사용한다면 메시기를 전송한다 단 서버Fortezza/DMS Server Key Exchange .

인증서에 매개 변수가 포함되어 있다면 이 메시지는 사용되지 않는다 이Diffie-Hellman .

단계에서 사용되는 인증서의 종류 또는 키 교환에 사용되는 알고리즘은 메시Sewer Hello

지의 에 정의된 것을 사용한다Cipher Suit .

마( ) Certificate Request

서버는 기본적으로 클라이언트에게 서버 자신을 인증할 수 있도록 한다 이와 마찬가지로.

서버는 클라이언트의 인증서를 요구하여 신뢰할 수 있는 클라이언트인지 확인할 수 있다.

이 단계는 선택적으로 동작하지만 단계와 단계를 통해 클라이언트와 서버는 상호인증이4 5

가능하게 된다.

바( ) Server Hel1o Done

서버에서 보낼 메시지를 모두 보냈음을 의미한다 이 메시지를 클라이언트에 보내는 이유는.

단계의 메시지가 보내질 수도 있고 생략될 수도 있기 때문이다 따라서 이 메시지를 받은5 , .

클라이언트는 서버로부터 더 이상의 메시지 전송이 없음을 알 수 있게 된다.

사( ) Client Certificate

서버로부터 클라이언트의 인증서를 보내라는 요청이 있을 경우 클라이언트 자신의 인증서를

보내야 한다 만약 인증서가 없다면 메시지를 보낸다. No Certificate Alert .

- 193 -

아( ) Client Key Exchange

이 단계에서 클라이언트는 세션키를 생성하는 데 이용되는 임의의 비밀정보인 바이트48

를 생성한다 그런 뒤 선택된 공개키 알고리즘에 따라pre_master_secret .

정보를 암호화하여 서버에 전송한다 이때pre_master_secret . , RSA, Fortezza,

중 하나를 이 용하게 된다Diffie-Hellman · .

자( ) Certificate Verify

서버의 요구에 의해 전송하는 클라이언트의 인증서를 서버가 쉽게 확인할 수 있도록 클라이

언트는 핸드쉐이크 메시지를 전자서명하여 전송하게 된다 이 메시지를 통해 서버는 클라이.

언트의 인증서에 포함된 공개키가 유효한지 확인하여 클라이언트 인증을 마치게 된다.

차( ) Change Cipher Specs, Finished

메시지는 핸드쉐이크 프로토콜에 포함되지 않지만 클라이언트는Change Cipher Specs

마지막으로 메시지를 서버에 전송하여 이후에 전송되는 모든 메시지Change Cipher specs

는 협상된 알고리즘과 키를 이용할 것임을 알리게 된다 그런 후 즉시 메시지를. Finished

생성하여 서버에 전송한다 따라서 이 메시지에는 협상된 알고리즘 및 키가 처음. Finished

으로 적용된다.

카( ) Finished, Change Cipher Specs

서버는 클라이언트가 보낸 모든 메시지를 확인한 후 메시지를 클라Change Cipher Specs

이언트에게 보낸 후 즉시 메시지를 생성하여 전송함으로써 핸드 쉐이크 프로Finished SSL

토콜 단계를 종료하게 된다.

핸드쉐이크 프로토콜의 마지막 단계에서 클라이언트와 서버는 메시Change Cipher Specs

지를 보낸 후 서로 공유하는 세션 정보를 이용해 메시지에 보안 서비스가 처음으Finished

로 적용되게 된다.

- 194 -

레코드 프로토콜(2) SSL

핸드쉐이크 프로토골 단계에서 암호 알고리즘 키 등의 정보를 협상에 의해서 클라이SSL ,

언트와 서버가 공유한 후 한 세션동안 그 정보는 레코드 계층에서 계속적으로 이용된, SSL

다 그림 과 같이 레코드 계층은 상위 응용 계층으로부터 임의의 크기의 데이터를. ( 6-3) SSL

전달받는다 그러면 전송할 메시지를 에서 처리할 수 있는 데이터 블록 크기만큼씩 단. SSL

편화하고 경우에 따라서는 압축을 한 후 와 암호화를 계산하여 계층으로 전달한, MAC TCP

다 이러한 데이터를 수신하면 복호화하고 에 대한 유효성을 조사한 후 다시 압축 해. , MAC

제를 하고 단편화된 데이터 조각을 모은다 이렇게 처리된 데이터는 응용계층의 클라이언, .

트에게 전달된다.

그림 레코드 프로토콜( 6-3) SSL

- 195 -

가 단편화( ) (Fragmentation)

레코드 계층은 응용 계층에서 전달한 데이터를 214바이트 또는 고 이하의 크기로 분할하여

레코드를 생성한다SSLPlaintext .

나 레코드 압축 과 해제( ) (Compression) (Decompression)

모든 레코드는 현재의 세션 상태 에 정의되어 있는 압축 알고리즘을 사용하(session state)

여 압축된다.

다 메시지 인증 암호화 복호화( ) (MAC), /

모든 레코드는 현재의 에 정의된 암호 알고리즘과CipherSpec MAC(Message

알고리즘을 사용하여 보호된다 항상 은 활성화되어 동작Authentication Code) . CipherSpec

하지만 초기에 을 로 설정하면 어, CipherSpec.ciper_type SSL_NULL_WITH_ NULL_NULL

떠한 보안 기능도 제공되지 않는다 일단 핸드쉐이크 프로토콜이 완료되면 클라이언트와. ,

서버는 메시지를 암호화하고 를 계산할 수 있는 비밀정보를 공유하게 된다 암호화와, MAC .

오퍼레이션을 수행하기 위해 사용되는 기법은 에서 정의되고MAC CipherSpec ,

에 의해 유지된다 암호 함수와 함수는 데CipherSpec. ciper_type . MAC SSL Compressed

이터 구조를 데이터 구조로 변환한다 또한 전송은 순서번호를 포함하는데SSLCiphertext . ,

전송 오류의 발생이나 변경 또는 그 외의 메시지를 감지할 수 있게 한다 데이터의 암호는_ .

스트림 암호 또는 블록 암호를 선택적으로 이용할 수 있다 은 데이터를 암호화하기. MAC

전에 계산된다 스트림 암호는 을 포함하여 블록 전체를 암호화 한다. MAC .

- 196 -

마 에서 이용되는 알고리즘. SSL

에서는 전자서명과 키 교환을 위해 또는 알그리즘을 이용할 수 있도록 하고SSL RSA DH ,

암호 알고리즘은 등을 이용할 수 있다RC4, RC2, IDEA, DES .

표 에서 이용되는 암호 알고리즘[ 6-1] SSL

분석3. TLS(Transport Layer Security)

가 의 개요. TLS

는 이 발표된 이후 년 초에 에서 라는 이TLS SSL v3.0 1996 IETF TLS WG(Working Group)

결성되어 이에 대한 표준화를 진행했다 이것은 과 마찬가지로 계층 바로.[10.22] SSL TCP

위에 위치하여 다양한 응용 프로토콜의 채널 자체를 보호하는 기능을 하며 클라이언트 서, /

버 인증 비밀성 무결성 등과 같은 보안 서비스를 제공한다 그러므로 의 보안 서비스, , . TLS

를 이용하고자 하는 어플리케이션은 수정 없이 사용 할 수 있다.

의 장점은 응용 프로토콜과 독립적이라는 것이다 계층을 기반으로 개발되TLS . Transport

었기 때문에 어떠한 응용 프로그램이라도 를 이용하여 안전한 통신 기반을 구축할 수TLS

있도록 지원하고 있다.

- 197 -

상위 계층의 프로토콜은 프로토콜 위에서 동작할 수 있으며 보안 메커니즘을 사TLS , TLS

용하여 응용프로그램의 보안성을 향상시킬 수 있다 따라서 개발자는 초. TLS Handshaking

기화와 교환되는 인증 정보의 해석 방법 등을 자율적으로 정할 수 있다.

는 에 비하여 향상된 문서화 의 사용 의 추가 등이 추가TLS SSL , HMAC , optional data field

되었다.

나 의 구조. TLS

는 두 개의 통신 응용프로그램 사이에서 개인의 정보보호와 데이터의 무결성을 제공하TLS

기 위해 만들어 졌고 레코드 프로토콜과 핸드쉐이크 프로토콜로 구성되어 있으, TLS TLS

며 그림 과 같다( 6-1) .

레코드 프로토콜은 계층의 바로 위에 위치하여 호스트 사이의 통신 연결 시 보TLS TCP

안을 제공하며 와 서비스를 제공한다 레코드 프로토콜은 상위계층, Privacy Reliability . TLS

프로토콜의 캡슐화를 위해 사용된다 이러한 프로토콜 중의 하나가 핸드쉐이크 프로토. TLS

콜이다 핸드쉐이크 프로토콜은 서버와 클라이언트가 데이터를 전송하기 전에 서로 인증할.

수 있도록 해주며 사용할 암호화 알고리즘과 암호 키를 협상하도록 해준다, .

의 암호화 기능TLS▶

전자서명 스트림 암호화 블록 암호화 공개키 암호화 방식이 사용된다- , , , .

과 의사난수 함수HMAC▶

레코드와 핸드쉐이크 계층에서 많은 동작들은 을 필요로 하는데 사용- TLS keyed MAC ,

되는 비밀정보 없이 을 위조하는 것은 불가능하다MAC .

- 198 -

여기서 사용하는 구조를 이라고 하는데 핸드쉐이크에서는 와 을 사용한HMAC , MD5 SHA-1

다 레코드 데이터를 위해서는 다른 해쉬 알고리즘이 사용될 수 있다. .

함수 는 을 입력으로 받아서 임의의 길이의 결과Pseudo-random (PRF) .secret, seed, label

값을 출력한다 에서는 안전성을 보장하기 위해 두 개의 해쉬 알고리즘을 사용한다. PRF .

다 핸드쉐이크 프로토콜. TLS

핸드쉐이크 프로토콜은 보안 인수의 결정 인증 협상된 보안인수의 설명 에러조건의TLS , , ,

보고를 위한 프로토콜 프로토콜 핸드쉐이크 프로토콜로 구성Change cipher spec , Alert ,

되고 기본적인 흐름은 과 같다 그림 와 같다SSL .[ 2] .

암호 스펙 교환 프로토콜(1)

에서 암호화되고 압축된 하나의 메시지로 되어 있다 메current state . Change cipher spec

시지는 클라이언트와 서버 양쪽에 의해 전송되며 뒤따라오는 레코드가 새로이 협상된,

과 키에 의해 보호 될 것임을 알러준다 이 메시지를 받은 후에 레코드 계층은CipherSpec .

를 로 복사하게 되고 를read pending state read current state , write pending state write

로 바꾼다active state .

프로토콜(2) Alert

치명적은 수준의 메시지에 의해 연결이 차단되며 실패한 세션에 의해서는 다른 새로alert ,

운 연결이 설정되지 않는다 메시지 또한 암호화되고 압축되어 전송된다. alert .

- 199 -

핸드쉐이크 프로토콜(3)

핸드쉐이크 프로토콜은 암호 인수를 생성하며 레코드 계층의 상위계층에서 동작한다, TLS .

이 프로토콜은 세션의 보안속성을 협상하기 위해 사용된다 핸드쉐이크 메시지는 레코. TLS

드 계층으로 전달되고 그것들은 구조로 캡슐화되며 다음과 같은 종류들이 있TLSPlaintext

다.

클라이언트와 서버 사이에 암호 해쉬 압축 알고리즘 등 보안을 위한 정Hello messages , ,

보를 교환하기 위해 사용된다 새로운 세션이 시작되면 위의 값들은 모두 으로 초기화되고. 0

협상이 재개된다 서버는 메시지 이후에 바로. Server certificate server hello certificate

를 보낸다 는 설정된 키 교환 알고리즘에 적절해야 하며 일반적으로. certificate , X.509 v3

가 사용된다 또한 반드시 키 교환 방법에 부합하는 키를 포함하고 있어야 한다certificate . .

라 레코드 프로토콜. TLS

레코드 프로토콜은 계층적 프로토콜이며 각각의 계층에서 메시지는 길이 설명 내용TLS , , ,

을 위한 필드를 가질 수 있다 레코드 프로토콜은 메시지를 전송하고 데이터를 블록으로. ,

나눈다 경우에 따라서는 데이터를 압축하고 을 적용해서 암호화하고 그 결과를 전송할. ,MAC

수 있다 전송 받은 데이터는 암호화 검증 압축해제 재결합하여 상위 계층의 클라이언트에· , , ,

게 보내준다 레코드 프로토콜의 클라이언트에는 핸드쉐이크 프로토콜 프로토콜 암. , alert ,

호 스펙 교환 프로토콜 응용 데이터 프로토콜이 있다 그림 과 같다, .( 6-3) .

- 200 -

(1) Connection state

여기에서는 압축 알고리즘 암호 알고리즘 알고리즘을 지정한다 이 상태는 다시, , MAC .

상태 상태 등 네 가지의 상태로 나누어진다 모든current read/write , pending read/write .

레코드는 상태에서 처리되며 상태를 위한 보안 인수는current read/write , pending TLS

핸드쉐이크 프로토콜에 의해서 정해진다.

핸드쉐이크 프로토콜은 상태를 상태로 바꿀 수 있다 현재상태로 변하기pending current .

위해서는 보안 인수에 의한 초기화가 선행되어야 하며 상태는 상태로 바뀌, pending empty

게 된다 일단 보안 인수가 정해지면 키가 생성되고 가 된다 는. current state . current state

각각의 레코드 수행을 위해 갱신된다.

단편화(2) (Fragmentation)

레코드 계층은 응용 계층에서 전달한 데이터를 214바이트 또는 그 이하의 크기로 분할하여

레코드를 생성한다SSLPlaintext .

레코드 압축 과 해제(3) (Compression) (Decompression)

모든 레코드는 현재의 세션 상태 에 정의되어 있는 압축 알고리즘을 사용하(session state)

여 압축된다 압축 알고리즘은 구조를 구조로 변환시킨다. TLSPlaintext TLSCompressed .

마 과 의 비교분석. SSL TLS

는 과 기능적 차이는 거의 없으나 몇 가지 차이점을 갖고 있다 와 의 차TLS SSL . TLS SSL

이점은 다음 표 와 같다[ 6-2] .

- 201 -

표 과 의 비교 분석[ 6-2] SSL TLS

- 202 -

국내 표준 알고리즘 분석4.

가 암호 알고리즘. (SEED)

암호 알고리즘은 암 복호화에 사용되는 키의 특성에 따라 암 복호화 키가 같은 대칭키 암ㆍ ㆍ

호 알고리즘과 암 복호화 키가 서로 다른 공개키 암호 알고리즘으로 크게 구분할 수 있으ㆍ

며 대칭키 암호 알고리즘은 데이터 처리 형식에 따라 스트림 암호 알고리즘과 블록 암호,

알고리즘으로 나눌 수 있다.

는 대칭키 암호 알고리즘으로 블록 단위로 메시지를 처리하는 블록 암호 알고리즘이SEED ,

다.

대칭키 블록 암호 알고리즘은 비밀성을 제공하는 암호시스템의 중요 요소이다 비트 블록. n

암호 알고리즘이란 고정된 비트 평문을 같은 길이의 비트 암호문으로 바꾸는 함수를 말n n

한다 비트 블록 크기 이러한 변형 과정에 암 복호키가 작용하여 암호화와 복호화를 수(n : ). ㆍ

행한다.

블록 암호 알고리즘은 대부분 구조로 설계된다 예Feistel ( : DES, FEAL, LOKI, MISTY,

등 구조란 각각 비트인Blowfish, CAST, Twofish ). Feistel t L0, R0 블록으로 이루어진 2t

비트 평문 블록 (L0, R0 이 라운드) r (γ≥ 1 를 거쳐 암호문) (Lr, Rr 으로 변환되는 반복 구조)

를 말한다 반복 구조란 평문 블록이 여러 라운드를 거쳐 암호화되는 과정을 말한다 라운드. (

함수 ( i( 1≥ i≥γ)란 암호키 K로부터 유도된 각 서브키 Ki 라운드 키라 불림 를 중요 입력( )

으로 하여 L i=R i- 1,R i=L i- 1 ⊕ f(R i- 1,K i)를 통해 (Li-1, Ri-1) (Li, Ri 로 바꾸어 주는)

함수를 말한다 또한 전체 알고리즘의 라운드 수는 요구되는 비도와 수행 효율성의 상호). ,

절충적 관계에 의해 결정된다 보통 구조는 라운드 이상이며 짝수 라운드로 구성. Feistel 3 ,

된다.

다음은 구조의 특징이다Feistel .

- 203 -

라운드 함수에 관계없이 역변환이 가능하다 즉 암 복호화 과정이 같음.( , )▶ ㆍ

두 번의 수행으로 블록간의 완전한 이 이루어진다diffusion .▶

알고리즘의 수행속도가 빠르다.▶

및 로 구현이 용이하다H/W S/W .▶

아직 구조상의 문제점이 발견되고 있지 않다는 장점을 지니고 있다.▶

는 정보처리시스템 및 정보통신망 환경에서 임의의 키 비밀키 를 사용하여 블록단위로SEED ( )

데이터를 변환하는 블록 암호 알고리즘이다.

비트 블록 암호 알고리즘 는 비트 입력키를 사용하여 비트블록 단위로 데128 SEED 128 128

이터를 암 복호화하는 암호 알고리즘으로 데이터의 비밀성등과 같은 기능을 제공하기 위해ㆍ

사용될 수 있다 를 통해 전자상거래 전자 금융거래 무역업무 자동화 등 비밀성 기. SEED , ,

능을 요구하는 각종 정보통신응용 서비스에 가 활용될 수 있을 것으로 기대된다SEED .

알고리즘 전체 구성도SEED▶

본 알고리즘의 전체 구조는 구조로 이루어져 있으며 비트의 평문 블록단위당Feistel , 128

비트 키로부터 생성된 개의 비트 라운드 키를 입력으로 사용하여 총 라운드를128 16 64 16

거쳐 비트 암호문 블록을 출력한다 다음 그림 는 알고리즘의 전체구조를 도128 . ( 6-4) SEED

식화한 것이다.

- 204 -

그림 전체 구조도( 6-4) SEED

나 해쉬 알고리즘. (HAS160)

해쉬 알고리즘은 임의의 길이의 코드로 압축시키는 알고리즘으로써 비트 열을 고정된 길이

의 출력 값인 해쉬 다음의 성질을 만족한다.

주어진 출력에 대하여 입력 값을 구하는 것이 계산상 불가능하다.▶

주어진 입력에 대하여 같은 출력을 내는 또 다른 입력을 찾아내는 것이 계산상▶

불가능하다 암호학적 응용에 사용되는 대부분의 해쉬 알고리즘은 위의 두 성질뿐만 아니라.

이보다 강한 충돌저항성을 지닐 것이 요구된다.

같은 출력을 내는 임의의 서로 다른 두 입력 메시지를 찾는 것이 계산상▶

불가능하다 암호학적 해쉬 알고리즘의 충돌 저항성은 전자서명에서(collision-resistance).

송신가 외의 제 자에 의한 문서위조를 방지하는 부인봉쇄 서비스를 제공하기 위한3

필수적인 요구조건이 된다.

- 205 -

해쉬 알고리즘은 크게 와 같은 블록 암호알고리즘에 기초한 해쉬 알고리즘과 전용 해DES

쉬 알고리즘으로 나눌 수 있다 블록 암호를 이용한 해쉬 알그리즘은 이미 구현되어 사용되.

고 있는 블록 암호를 사용할 수 있다는 이점이 있으나 대부분의 블록 암호알고리즘의 속도,

가 그리 빠르지 않을 뿐더러 이를 기본함수로 이용한 해쉬 알고리즘의 경우 블록암호보다도

훨씬 더 속도가 떨어지므로 현재는 대부분의 응용에서 전용 해쉬 알고리즘이 주로 이용된

다.

대부분의 전용 해쉬 알고리즘은 덧붙이기 분할 반복연산의 과정을 거쳐 계산된다 임의의, , .

길이의 메시지 를 입력단위의 배수가 되도록 덧붙이기 하여 개의 입력 블록X t (X1,···,Xt 으로)

분할한다 해쉬 코드는 각 불록. Xi에 대해 연쇄변수를 주어진 초기값 으로 초기화한 후(IV)

압축함수를 반복적으로 적용하여 계산되며 그 처리과정은 다음과 같이 기술할 수 있다, .

여기서 f는 h의 압축함수이며, Hi는 단계 i 과 단계-1 i의 중간 계산 값이다.

에서 규정되는 해쉬 알고리즘은 정보처리시스템 또는 정보통신망 환경에서 인증HAS160 ,

무결성 및 부인봉쇄 등의 정보보호 서비스를 제공하는 전자서명에 활용할 수 있다 또한 이.

표준에 따르는 정보통신기기 및 관련 응용 개발 시 구현결과의 구현적합성 여부를 확인하는

데 이용할 수 있다.

- 206 -

알고리즘 전체 구성도HAS160▶

알고리즘은 다음 그림 과 같은 계산 과정을 통해 메시지를 다이제스트 한다HAS160 ( 6-5) .

그림 구조도( 6-5) HAS-160

- 207 -

설계 및 구현5. SecureSSLLib

가 설계 구조.

기존의 은 을 모두 지원하고 에서OpenSSL SSL v1.0, SSL v2.0, SSL v3.0 IETF SSL

을 표준화하기 위해 제안한 보안 프로토콜인 를 지원하여 네트워크 환경에서 안정v3.0 TLS

한 통신 채널을 형성함으로써 신뢰성 있고 안정한 통신을 제공한다 본 논문에서는 기존의, .

암호 라이브러리에 국내에서 개발된 암호 알고리즘으로 해쉬 알고리즘으OpenSSL SEED,

로 을 적용하여 국내 실정에 맞게 활용할 수 있도록 그림 와 같이 구성하였HAS160 ( 6-6)

다.

그림 국내 암호 알고리즘을 적용한 설계( 6-6) OpenSSL

국내 암호 알고리즘을 적용한 의 설계 시 다음과 같은 기능들을 고려한다OpenSSL .

- 208 -

국내 알고리즘을 적용한 의 기능OpenSSL▶

네트워크 환경에서 통신을 하는 두 응용프로그램 사이에 안진한 채널을 형성하여 통신-

내용의 보안성을 지켜줌

응용프로그램과 사이에서 수행되므로 특정 용용프로그램에 종속되지 않고- TCP TCR/IP

를 사용하는 모든 응용프로그램들을 지원

두 응용간 기밀성 서비스 제공-

클라이언트와 서버 인증 서비스 제공-

메시지 무결성 서비스 제공-

보안 서비스를 제공하기 위해 국내에서 개발된 암호 알고리즘 포함-

나 국내 암호 알고리즘을 적용한 구현. OpenSSL

본 과제에서는 국내 실정에 맞게 신뢰성 있는 안전한 통신 프로토콜로 설계된 국내 암호 알

고리즘을 적용한 를 구현한다 기존 분석 결과 기존 은OpenSSL SecureSSLLib . SSL SSL

보안 프로토콜로 클라이언트와 서버간에 안전한 채널을 형성하여 신뢰성 있는 통신을 제공

했다 그러나 에 사용되는 알고리즘 사용의 제약이 따르고 제한되어 있었다. SSL .

는 이러한 기존 의 제약 사항을 개선하여 국내 암호 알고리즘이 사용될SecureSSLLib SSL

수 있도록 구현되었다.

국내 암호 알고리즘을 적용한 의 구조(1) OpenSSL

국내 암호 알고리즘을 적용한 구현 시 가장 고려해야 할 부분은 이다 이OpenSSL EVP .

에서는 각 암호 알고리즘들 정의하고 에서 사용되는 암호 알고리즘 해쉬 알고리EVP SSL ,

즘 서명 알고리즘의 표준 구조를 정의하고 있다 사용자는 의 사용자 인터페이스를 통, . SSL

해서 원하는 작업을 요구하고 사용자 인터페이스에서 를 통해 지정된 알고리즘에, SSL EVP

연결된다.

- 209 -

지정된 알고리즘은 요구된 작업을 마치고 다시 사용자 인터페이스에 결과를 반환하거나 파,

일을 생성한다 그림 은 국내 암호 알고리즘을 적용한 의 전체 구성도이다. ( 6-7) OpenSSL .

그림 국내 암호 알고리즘을 적용한 의 구성도( 6-7) OpenSSL

- 210 -

구현 환경(2)

구현 환경에 관한 사항은 다음 표 에서 제시한다[ 6-3] .

표 구현환경[ 6-3]

구현 과정(3)

구현 과정은 다음 표 에서 정리한 것과 같다[ 6-4] .

표 구현 과정[ 6-4]

단계 내 용

단계1 기존 분석SSL

단계2 국내 알고리즘 분석 및 독립적인 실행SEED, HAS160

단계3알고리즘을 기존 에서 지정하는 알고리즘 형태로 구조SEED, HAS160 SSL

변경 함수명 파라미터 구조체등( , , )

단계4 을 암호 알고리즘들이 존재하는 곳에 추가SEED, HAS160

단계5이 기존 에서 동작할 수 있도록 하기 위해 필요한 연동SEED, HAs160 SSL

작업

단계6 추가된 국내 알고리즘들이 기존 에 정확한 동작을 하는지SSL Testing

단계7작업 완료 결과 openssl.exe, ssleay32.lib, ssleay32.dll, seedtest.exe,

파일이 생성되는지 확인has160test.exe

- 211 -

각 암호 알고리즘 선언과 암호 알고리즘 표준 구조를 정의한 다음 그림 은EVP ( 6-8)▶

가 에서 사용되는 암호 알고리즘의 표준 구조를 정의하고 각 암호EVP SecureSSL

알고리즘들의 선언을 보여준다.

- 212 -

그림 의 암호 알고리즘 정의( 6-8) EVP

각 해쉬 알고리즘 선언과 해쉬 알고리즘 표준 구조를 정의한 다음 그림 는FVP ( 6-9)▶

가 에서 사용되는 해쉬 알고리즘의 표준 구조를 정의하고 각 해쉬EVP SecureSSL

알고리즘들의 선언을 보여준다.

- 213 -

그림 의 해쉬 알고리즘 정의( 6-9) EVP

국내 알고리즘 추가 시 추가할 파일과 수정해야 할 파일명과 각 파일의 기능▶

- 214 -

표 구성 요소 기능[ 6-5] OpenSSL

- 215 -

다 구현 결과.

구현 결과 기존의 에 국내 알고리즘을 적용하여 국내 암호 알고리즘을OpenSSL OpenSSL

프로토콜에서 사용할 수 있다 이 절에서는 기존의 인터페이스와 국내 알고리즘. OpenSSL

이 적용된 의 인터페이스를 비교하여 보여준다OpenSSL .

실행 화면OpenSSL▶

그림 실행 화면( 6-10) Openssl.exe

다음 그림 과 그립 을 비교해보면 와( 6-11) ( 6-12) , Message Digest Commands Cipher

에 각각 과 네 가지 모드별 알고리즘이 추가된 것을 확인할 수 있Commands has160 seed

다.

- 216 -

그림 기존 초기화면( 6-11) OpenSSL

국내 알고리즘이 적용된 실행시 화면OpenSSL▶

그림 와 이 추가된 초기화면( 6-12) SEED HAS160

- 217 -

실행 화면has160▶

다음 그림 은 국내 암호 알고리즘을 적용한 에서 추가된 알고리즘을( 6-13) OpenSSL has160

이용해 라는 임의의 파일을 다이제스트 한 결과를 보여주는 화면이다 을test.txt . OpenSSL

이용할 때는 커맨드에서 제공하는 커맨드를 사용하여 기능을 실행한OpenSSL OpenSSL,

다.

그림 파일을 으로 해쉬한 화면( 6-13) testtxt has160

실행 화면SEED▶

는 운용 모드가 있다 따라서 운용 모드별로 에 적용하SEED cbc, cfb, ecb, ofb . OpenSSL

였다 실제로 를 적용할 때 필요에 따라 각운용 모드별로 암호화와 복호화를 제공한. SEED

다.

다음 그림 은 의 모드로 파일을 암호화 하기위한 화면으로 모든 암( 6-14) SEED ecb 111.txt

호 알고리즘을 사용할 때는 암호 패스워드를 입력하고 패스워드 검증을 위해다시 한번 패스

워드를 입력한다.

- 218 -

그림 모드로 파일을 암호하기 위한 초기화면( 6-14) seed ecb 111.txt

다음 그림 는 위에서 모드로 파일을 암호화했을 때 처리되어 암호( 6-15) seed ecb 111.txt

화된 결과를 보여준다 그림 과 그림 은 파일을 모드로 암호화.( 6-16) ( 6-17) 333.txt seed ofb

해서 결과 파일로 암호화된 파일과 복호화된 파일을 생성한다333.ofben 333.ofbde .

- 219 -

그림 모드로 를 암호시 결과 화면( 6-15) seed ecb 111.txt

그림 모드로 파일 암호해서 결과파일 생성( 6-16) seed ofb 333.txt 333.ofben

- 220 -

그림 암호화된 파일을 복호한 로 결과 파일 생성( 6-l7) 333.ofben 333.ofbde

라 성능분석.

테스트 방식(1)

테스트는 와 두 가지로 나누어서 테스트를 실행한다 는 별도의 테스SEED HAS160 . SEED

트 프로그램을 작성하여 테스트하고 은 독립적인 결과 화면을 제시하여 테스트한HAS160

다.

테스트 결과에 따른 국내 암호 알고리즘을 적용한 의 유효성을 검증한다OpenSSL .

테스트 시나리오(2)

에 추가된 를 동한 암호화와 복호화 결과 그리고 에 추가된OpenSSL SEED , OpenSSL

을 통한 다이제스트 결과를 한다HAS160 test .

- 221 -

가 테스트( ) SEED

테스트 할 파일을 작성하여 테스트용 파일을 국내 암호 알고리즘이 적용된 의OpenSSL①

로 암호화 하여 암호화된 파일을 생성한다SEED .

암호화된 파일을 복호화 하여 복호화된 파일을 생성한다.②

테스트를 위한 원본 파일과 복호화된 파일을 비교한다.③

테스트 프로그램 결과 화면▶

그림 테스트 프로그램 인터페이스( 6-18)

- 222 -

그림 테스트를 위한 테스트 원본 파일을 한 화면( 6-19) open

그림 암호화한 파일을 한 화면( 6-20) open

- 223 -

그림 복호화된 파일을 한 화면( 6-21) open

그림 복호화 성공화면( 6-22)

테스트 결과 기존의 에 추가된 의 유효성이 검증되었다 따라서 국내 암호OpenSSL SEED .

알고리즘이 적용된 에서는 알고리즘을 사용하여 기밀성을 제공할 수 있다OpenSSL SEED .

- 224 -

나( ) HAS160 testing

을 실행시키고 을 이용하어 테스트 파일을 다이제스트한다SecureSSL has160 .①

독립적으로 실행되는 알고리즘을 이용하여 동일한 파일을 다이제스트 한다has160 .②

각 다이제스트 결과를 통해 두 개의 결과가 같은지를 검사한다.③

테스트 프로그램 결과 화면▶

그림 에서 을 옵션으로 다이제스트 한 화면( 6-23) OpenSSL has160 hex

그림 독립적으로 실행되는 알고리즘으로 다이제스트 한 화면( 6-24) has160

- 225 -

테스트 결과 국내 암호 알고리즘이 적용된 에서 추가된 을 이용하어 다이OpenSSL has160

제스트 한 결과 값과 독립적으로 실행되는 알고리즘으로 다이제스트 한 결과 값이has160

일치했다 따라서 기존 에 적용된 의 유효성이 검즘되었다. OpenSSL has160 .

- 226 -

제 절2 SecureCertLib

는 인증서 기반의 인증 및 권한 인증서 생성 요청 검증 등의 기SecureCertLib X.509 v3 , ,

능을 제공하는 라이브러리로 서버와 클라이언트 응용SecureSSO SecureSSO , SecureSSO

서버의 핵심기능을 제공한다.

기능 구성1. SecureCertLib

그림 는 의 주요 기능을 나타내고 있다( 6-25) SccureCertLib .

그림 주요기능( 6-25) SecureCerLib

- 227 -

가 관리. SSO

관리는 사용자 과 암호화된 개인키 인증서 인증서 정책 정보 디렉토리 서버 정SSO DN , , ,

보 암호화 툴킷 정보 등을 관리하는 기능을 제공한다, .

나 공개키 암호화 툴킷.

공개키 암호화 툴킷은 공개키쌍 생성 인증서 검증 전자 서명 전자서명 검증 메시지 암복, , , ,

호화 등을 위한 표준화된 인터페이스를 제공한다 시스템요구사항에 따라 구체적인 툴킷을.

적용할 수 있으며 본 과제에서는 기본 툴킷으로서 마이크로 소프트의 툴킷을 적용하였고 아

울러 국내 공인인증기관과의 연동을 위하여 한국 정보인증의 툴킷을 적용하였다.

다 인증 프로토콜 메시지 처리.

인증 프로토콜 메시지 처리는 사용자 인증 프로토콜 메시지 AC_REQ, AC_REP, AP_REQ,

생성 및 검증 자료추출 등을 지원한다AP_REP , .

라 권한 인증서 처리.

권한 인증서 처리는 권한 인증서를 생성하고 검증하는 기능을 제공한다.

시스템 구현환경2.

운영체제▶

Windows2000 Server/Professional, Windows 98, Windows NT 4.0

개발도구▶

Visual C++ 6.0

공개키 암호화 툴킷▶

- 228 -

한국정보인증 툴킷 라이브러리Microsoft Crypto API 2.0,

클래스 설계 및 구현3.

가 클래스 설계.

그림 클래스 관계 다이어그램( 6-26)

- 229 -

그림 클래스 세부 속성 다이어그램( 6-27)

- 230 -

나 클래스 구현.

(1) CISSSOManager

클래스는 사용가의 과 비밀키 암호화용 인증서 및 개인키 서명용 인CISSSOManager DN , ,

증서 및 개인기와 같은 사용자에 대한 정보를 관리하며 사용자 인증 프로토콜 메시지를 생

성하고 검증하는 기능을 제공한다.

는 가상담수 를 통해 이를 상속받는 클래스CISSSOManager Initialize() CISSSOServMnger,

가 각각의 역할과 환경에 맞게 초기화 할 수 있도CISSSOClientMnger, CISSSOAppMnger

록 한다.

- 231 -

- 232 -

- 233 -

- 234 -

- 235 -

(2) CISMessage

는 사용자 인증 프로토콜에 교환되는 메시지의 생성 및 파싱 검증을 지원하는CISMessage ,

클래스로 상속받는 클래스 CISMsgACREP, CISMsgACREQ, CISMsgAPREP,

가 가상함수 를 통해 프로토콜 특성에CISMsgAPREQ MakeMsgItems(), ParseMsgItems()

적합한 데이터를 생성하거나 파싱 할 수 있도록 설계되었다.

- 236 -

- 237 -

- 238 -

- 239 -

(3) CISAttrCertificate

는 권한 인증서의 정보를 포함하는 클래스로 권한 인증서의 세부 정보를CISAttrCertificate

포함하는 와 서명 알고리즘을 나타내는 과 실제 서명값CISAttrCertInfo m_nSigAlgorithm

로 구성되어 있다 특히 의 권한 속성값을 나타내는m_Signature . CISAttrCertInfo

는 소속변수 을 통해CISAttribute m_hHandle AttCertIssuer, AttCertValidityPeriod,

를 저장할 수 있도록 설계되었다SvceAuthInfo, IetfAttrSyntax, Role .

- 240 -

- 241 -

- 242 -

- 243 -

동작 시나리오4.

가 클라이언트. SecureSSO

그림 클라이언트 동작 시나리오( 6-28) SecureSSO

- 244 -

나 인증서버. SecureSSO

그림 인증서버 동작 시나리오( 6-29) SecureSSO

- 245 -

다 응용 서버. SecureSSO

그림 응용 서버 동작 시나리오( 6-30) SecureSSO

- 246 -

제 절 인증 서버3 SecureSSO

인증 서버는 사용자의 인증서를 통해 사용자를 인증하고 사용자가 요청하는 서SecureSSO

비스의 권한 인증서롤 발급한다.

특히 초기 인증일 경우 사용자의 접근 권한에 따라 서비스 목록을 제공해 주며 인증시 마,

다 루그를 남겨서 사용자를 추적할 수 있도록 한다.

인증 서버 기능 구성1. SecureSSO

그림 는 인증 서버의 주요 기능을 나타내고 있다( 6-31) SecureSSO .

그림 인증 서버 주요기능( 6-31) SecurSSO

- 247 -

가 권한 인증서 발급.

인증 서버는 사용자가 원하는 응용 서비스에 대한 권한 인증서를 발급한다 권SecureSSO .

한 인증서에는 사용자의 역할 정보와 시스템을 위한 사용자 아이디와 패스워드 정legacy

보가 암호화되어 포함된다.

나 인증서 기반의 사용자 인증.

인증 서버는 권한 인증서를 발급하기 이전에 사용자에 대한인증을 수행하며 이SecureSSO

러한 인증은 사용가가 프로토콜 메시지에서 제시하는 형태의 인증서를AC_REQ X.509 v3

통해 이루어진다.

다 인증내역 로깅.

인증 서버는 사용자의 권한 인증서 요청이 발생할 때마다 그 내역을 로그에 남SecureSSO

겨서 사용자의 활동을 추적할 수 있도록 한다.

라 접근 가능 서비스 목록 제공.

인증 서버는 테이블 을 통해 사용자SecureSSO ISRoleInfo, ISServiceInfo, ISRoleServRel

의 역할에 따른 접근 가능 서비스 목록을 제공한다.

시스템 구현환경2.

운영체제▶

Windows 2000 Server/Professional, Windows NT 4.0

개발도구▶

Visual C++ 6.0

데이터 베이스 시스템▶

SQL Server 2000

- 248 -

웹 서버▶

IIS Server

공개키 암호화 툴킷▶

한국정보인증 툴킷 라이브러리Microsoft Crypto API 2.0,

인증 서버 구조3.

그림 인증 서버 구조( 6-32) SecureSS0

인증 서버는 그림 와 같이 형태의 와 형태의( 6-32) NT Service Main Part CGI Sub Part,

웹서버로 구성된다SecureDB, .

- 249 -

가. Main Part

는 형태로 구현되며 인증 서버의 핵심기능을 수행하며 각각의 요Main Part NT Service AC

청에 대해 멀티 쓰레드 형태로 동작한다.

처리모듈은 사용자 정보와 권한정보 서비스 정보 등을 데이터베이스 시스템으SecureDB ,

로부터 조회하거나 혹은 갱신하기 위해서 사용되는 모듈이며 쓰레드 관리자는 각 요청별로

실행되는 작업 쓰레드를 관리하는 모듈이고 는 메시지를 점증하는 동SSOCertLib AC_REQ

시에 인증서 기반의 사용자 인증을 제공하고 권한 인증서 처리에 대한 기본 기능을 제공한

다.

권한 인증서 발급모듈은 사용자가 요청한 서비스에 대한 권한 인증서를 발급하는 모듈이고

로그 처리 모듈은 사용자의 접속 내역을 로그에 기록하는 모듈이며 통신처리 모듈은 클라이

언트의 요청을 로부터 전송받고 메시지를 다시 로 전송해주는Sub Part AC_REP Sub Part

역할을 한다.

나. Sub Part

는 형태로 구현되며 사용자 맞춤 페이지 생성 서빗 접근 요청 등 주로Sub Part CGI , Main

의 웹 인터페이스를 제공해 주는 가교 역할을 한다Part .

사용자 맞춤 페이지 생성 모듈은 사용자의 초기 인증시 로부터 사용자 정보와 사SecureDB

용자의 역할에 해당하는 서비스 정보를 조회하여 사용자에 적절한 맞춤형 페이지를 생성하

는 모듈이고 서비스 요청 처리 모듈은 사용자가 자신의 맞춤 페이지로부터 선택한 서비스

요청 프로토콜 메시지 형태로 됨 이나 에서 진송한 프로토콜(AC_REQ ) Main Part AC_REP

메시지를 처리하는 역할을 한다 통신 처리 모듈은 사용자가 생성한 메시지나. AC_REQ

에서 생성한 메시지를 와 주고받는 역할을 한다Main Part AC_REP Main Part .

- 250 -

동작 시나리오4.

가. Main Part

의 동작 시나리오는 그림 과 같다Main Part ( 6-33) .

그림 인증 서버 실행흐름( 6-33) SecureSSO Main Part

- 251 -

나. Sub Part

는 사용자의 맞춤형 페이지가 생성되는 초기 인증 부분과 서비스요청 처리 부분으Sub Part

로 나뉘어 진다 그림 와 그림 는 각각 초기 인증부분과 서비스 요처 처리의 동.( 6-34) ( 6-35)

작 시나리오를 나타내고 있다.

그림 초기 인증 동작시나리오( 6-34) SecureSSO Sub Part

- 252 -

그림 서비스 요청 처리 동작 시나리오( 6-35) SecureSS0 Sub Part

- 253 -

제 절 클라이언트4 SecureSSO

클라이언트는 웹 브라우저에 플러그인 형태로 동작하는 시스템으로서 기본적으SecureSSO

로 와 프르토콜 메시지를 생성하고 와 메시지를 검증하AC_REQ AP_REQ AC_REP AP_REP

는 기능을 제공한다.

클라이언트 기능 구성1. SecureSSO

그림 은 클라이언트의 주요 기능을 나타내고 있다( 6-36) SecureSSO .

그림 클라이언트 주요기능( 6-36) SecureSSO

- 254 -

가 사용자 맞춤형 페이지 제공.

클라이언트는 사용자가 초기에 포털에 접근할 매 초기 인증후 사용자의SecureSSO SSO ,

점근 가능 서비스 목록과 기타 정보로 구성된 맞춤형 페이지를 제공한다.

나 인증 프로토콜 메시지 처리.

클라이언트는 사용자가 접근하고자 하는 서비스에 대한 권한인증서를 얻고 서SecureSSO

비스에 접근하기 위해 메시지와 메시지를 생성하고 메시지와AC_REQ AP_REQ AC_REP

메시지를 검증하는 기능을 제공한다 이를 위해서 클라이언트는AP_REP . SecureSSO

를 적용한다SecureCertLib .

다 권한 인증서 캐슁.

인증 서버로부터 권한 인증서를 발급 받은 후 클라이언트는 인증 서버의 개입, SecureSSO

없이 권한 인증서를 통해서 응용 서비스에 접속할 수 있어야 하며 이를 위해 권한 인증서의

캐슁이 지원되어야 한다 클라이언트는 윈도우즈 레지스트리를 통해 권한 인증. SecureSSO

서 캐슁기능을 제공한다.

라 로그인 자동화.

클라이언트는 응용 서버가 학되지 못할 경우를 위해서 로그인 자동화 기능SecureSSO SSO

을 제공한다.

시스템 구현환경2.

운영체제▶

Windows 2000 Server/Professional Windows NT 4.0, Windows 98

- 255 -

개발도구▶

Visual C++ 6.0, Java Script, HTML

웹 브라우저▶

Internet Explorer

공개키 암호화 툴킷▶

한국정보인증 툴킷 라이브러리Microsoft Crypto API 2.0,

클라이언트 구조3. SecureSSO

클라이언트의 구조는 그림 과 같다SecureSSO ( 6-37) .

그림 클라이언트 구조( 6-37) SecureSSO

- 256 -

동작 시나리오4.

가 플러그인 프로그램 인터페이스. (Plug-In)

클라이언트의 플러그인 인터페이스는 다음과 같다SecureSSO .

int InitSecureSSOClient()▶

기능 클라이언트 라이브러리를 초기화하는 함수- : SecureSSO

반환값 호출 프로그램에 할당된 이상의 핸들 값 이하이면 오류이며 이때 반환값은 오- : 1 , 0

류코드를 나타냄

int FreeSecureSSOClient(int Handle)▶

기능 할당된 핸들을 해제하는 함수- :

인수 은 로부터 얻은 값임- : Handle InitSecureSSOClient

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

int SetUserCertificate(int Handle, String UserDN)▶

기능 사용자 인증서와 개인키 를 선택하는 함수- : CAPubs

인수 은 로부터 얻은 값이고 은 사용자의 을 나- : Handle InitSecureSSOClient UserDN DN

타냄 만일 이 이면 인증서를 선택할 수 있는 인터페이스가 호출됨. UserDN NULL,

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 ,0

String Make_InitAuth_Msg(int Handle)▶

- 257 -

기능 인증 서버에 초기 인증을 위한 인증 메시지를 생성하는 함수- :

인수 은 로부터 얻은 값임- : Handle InitSecureSSOClient

반환값 이면 실패를 나타내며 이 아니면 메시지의 값을 나타냄- : NULL, NULL

int IsThereAttrCertInCache(int Handle, String ServiceName)▶

기능 클라이언트에 입력된 을 갖는 권한 인증서가 있는지를 확인하는 함수- : ServiceName

인수 은 로부터 얻은 값이며 은 권한 인증서의- : Handle InitSecureSSOClient ServiceName

서비스 이름임

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

String Make_AC_REQ_Msg(int Handle, String ServiceName)▶

기능 프로토콜 메시지를 생성하는 함수- : AC_REQ

인수 은 로부터 얻은 값이며 은 서비스 이름임- : Handle InitSecureSSOClient ServiceName

반환값 이면 실패를 나타내며 이 아니면 메시지의 값을 나타냄- : NULL NULL

int Verify_AC_REP_Msg(int Handle, String AC_REP)▶

기능 메시지를 검증하는 함수- : AC_REP

인수 은 로부터 얻은 값이며 는 인증 서버로부터 받- : Handle InitSecureSSOClient AC_REP

은 프로토콜 메시지임

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

- 258 -

String Make_AP_REQ_Msg(int Handle. String ServiceName)▶

기능 프로토골 메시지를 생성하는 함수- : AP_REQ

인수 은 로부터 얻은 값이며 은 서비스 이름- : Handle InitSecureSSOClient . ServiceName

임

반환값 이면 실패를 나타내며 이 아니면 메시지의 값을 나타냄- : NULL, NULL,

int Verify_AP_REP_Msg(int Handle, String AP_REP)▶

기능 메시지를 검증하는 함수- : AP_REP

인수 은 로부터 얻은 값이며 는 응용 서버로부터 받- : Handle InitSecureSSOClient AP_REP

은 프로토콜 메시지임

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

int DoLoginAutomation(int Handle, String ServiceName)▶

기능 로그인 자동화 기능을 수행하는 함수- : ㆍ

인수 은 로부터 얻은 값이며 는 로그인 자동화- : Handle InitSecureSSOClient ServiceName

를 적용하기 위한 서비스의 이름이다.

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

String ViewAttrCertificateList()▶

- 259 -

기능 시스템에 등록된 인증서를 조회하는 함수- :

반환값 이 아니면 원하는 인증서의 을 반환한다- : NULL DN .

String GetErrString(int nErrCode)▶

기능 각 함수가 반환한 오류 코드의 오류문자열을 반환하는 함수- :

반환값 이면 실패를 나타내며 이 아니면 해당하는 오류의 문자열값을 나타- : NULL NULL

낸다.

나 초기 인증.

클라이언트에서의 초기 인증 과정은 그림 과 같다 초기인증을 통해 사용SecureSSO ( 6-38) .

자에게 접근 가능 서비스 목록으로 구성된 사용자 맞춤 페이지가 전송된다.

그림 클라이언트 초기 인증( 6-38) SecureSSO

- 260 -

그림 초기 인증 화면( 6-39)

그림 사용자 맞춤형 페이지 화면( 6-40)

- 261 -

다 서비스 요청 및 접속.

클라이언트의 서비스 요청 및 접속처리 과정은 그림 과 같다SecureSSO ( 6-41) .

그림 클라이언트 서비스 요청 처리( 6-41) SecureSSO

- 262 -

그림 서비스 접속 화면 예( 6-42) 1

그림 서비스 접속 화면 예( 6-42) 2

- 263 -

제 절 응용 서버5 SecureSSO

응용 서버는 기존 응용 서버의 화를 위해 및 에이전트를SecureSSO SSO SecureSSOSDK

지원한다.

응용 서버 기능 구성1. SecureSSO

그림 는 응용 서버의 주요 기능을 나타내고 있다( 6-44) SecureSSO .

그림 응용 서버 주요기능( 6-44) SecureSSO

- 264 -

가 인증서 기반의 사용자 인증.

인증 서버는 인증서를 이용하여 사용자의 전자서명을 검증함으로써 사용자 인SecureSSO

증기능을 제공한다.

나 권한 인증서 검증 및 처리.

응용 서버는 사용자 인증후에 메시지에 포함된 권한인증서를 검증하SecureSSO AP_REQ

며 권한 인증서에 포함된 사용자의 권한 속성을 통해 사용자 권한을 검증하는 기능을 제공

한다.

다 인증 프로토콜 메시지 처리.

응용 서버는 메시지를 검증하고 메시지를 생성하는 기능을SecureSSO AP_REQ AP_REP

제공한다,

라 시스템 지원. Legacy

응용 서버는 화 할 수 없는 기존 응용 시스템의 지원을 위해 권한 인증서SecureSSO SSO

에 포함된 사용자 아이디와 패스워드를 추출하여 사용자를 대신하여 인증할 수 있는 기능을

제공하며 동시에 시스템에서 정의된 권한 속성을 응용 서버의 권한 시스템에 매핑하는SSO

기능을 제공한다.

시스템 구현환경2.

운영체제▶

Windows 2000 Server/Professional, Windows NT 4.0

개발도구▶

Visual C++ 6.0, HTML, ASP, PHP

웹 서버▶

- 265 -

IIS Server, Apache

공개키 암호화 툴킷▶

한국정보인증 툴킷 라이브러리Microsoft Crypto API 2.0,

시스템 구조3.

응용 서버의 구조는 그림 와 같다 응용 서버는 응용 서버가SecureSSO ( 6-45) . SecureSSO

화 될 수 있다면 모듈 형태로 구현되어 응용 서버 내에 포함되고 화 될 수 없다면SSO SSO

에이전트 형태로 구현된다.

그림 응용 서버 구조( 6-45) SecureSSO

동작 시나리오4.

가 응용 서버 인터페이스. SecureSSO SDK

응용 서버 인터페이스는 다음과 같다SecureSSO SDK .

int InitSecureSSOAppServer()▶

기능 응용 서버 라이브러리를 초기화하는 함수- : SectlreSSO

- 266 -

반환값 호출 프로그램에 할당된 이상의 핸들 값 이하이면 오류이며 이때 반환값은 오- : 1 , 0

류코드를 나타냄

int FrceSecureSSOAppSerer(int Handle)▶

기능 할당된 핸들을 해제하는 함수- :

인수 은 로부터 얻은 값임- : Handle InitSecureSSOClient

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

int SetServerCertificate(int Handie, char* UserDN)▶

기능 사용자 인증서와 개인키 를 선택하는 함수- : CAPubs

인수 은 로부터 얻은 값이고 은 사용자의 을 나- : Handle InitSecureAppSerer UserDN DN

타냄 만일 이 이면 인증서를 선택할 수 있는 인터페이스가 호출됨. UserDN NULL

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

int Make_AP_REP_Msg(int Handle, char* sMsg, int* len)▶

기능 프로토콜 메시지를 생성하는 함수이며 가 일 경우 이 가- : AP_REP sMsg NULL len

르키는 변수에 메시지의 크기를 반환함

인수 은 로부터 얻은 값이며 는 반환될 프로토콜 메시- : Handle InitSecureAppServer sMsg

지의 포인터를 나타내고 있으며 은 프로토콜 메시지의 길이를 나타내는 변수의 포인터임len

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

- 267 -

int Verify_AP_REQ_Msg(int Handle, char* AP_REQ)▶

기능 메시지를 검증하는 함수- : AC_REP

인수 은 로부터 얻은 값이며 는 인증 서버로부터- : Handle InitSecureAppServer AC_REP

받은 프로토콜 메시지임

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

int GetAttrCert(int Handle, char* AttrCert, int* 1en)▶

기능 권한 인증서를 가져오는 함수로 가 일 경우 이 가르키는 변수에- : AttrCert NULL len

권한 인증서의 크기를 반환한다.

인수 은 로부터 얻은 값이며 는 권한 인증서가 반- : Handle InitSecureAppSewer AttrCert

환될 인수이고 은 권한 인증서의 크기가 반환될 인수임len

반환값 이면 성공 이외의 값이면 실패로 이때 반환값은 오류코드를 나타냄- : 0 , 0

char* GetErrString(int nErrCode)▶

기능 각 함수가 반환한 오류 코드의 오류 문자열을 반환하는 함수- :

반환값 이면 실패를 나타내며 이 아니면 해당하는 오류의 문자열값을 나타- : NULL NULL

낸다.

- 268 -

나 응용 서버의 사용자 인승 및 권한검증. SecureSSO

그림 응용 서버의 사용자 인증 및 권한 검증( 6-46) SecureSSO

- 269 -

제 절 사용자 관리 시스템6 SecureSSO

사용자 관리 시스템은 시스템 운영을 위해 필수적인 사용자 정보 및 그룹 정보 역할SSO ,

정보 응용 서비스 정보 권한 속성 정보 등을 관리하며 동시에 사용자 접속 로그를 통해, ,

사용자의 접속내역을 조회할 수 있는 기능을 제공한다.

사용자 관리 시스템 기능 구성1. SecureSSO

그림 은 사용자 관리 시스템의 주요 기능을 나다내고 있다( 6-47) SecureSSO .

그림 사용자 관리 시스템 주요기능( 6-47) SecureSSO

- 270 -

시스템 구현환경2.

운영체제▶

Windows 2000 Server/Professional, Windows NT 4.0, Windows 98

개발도구▶

Visual C++ 6.0

데이터베이스 시스템▶

SQL Server 2000

시스템 구조3.

사용자 관리 시스템의 구조는 그림 과 같다 시스템은 주요 관리 모듈과 사용자 인터( 6-48) .

페이스 접근 모듈로 이루어진다, DB .

그림 사용자 관리 시스템 구조( 6-48) SeucreSSO

- 271 -

동작 시나리오3.

사용자 관리 시스템은 대부분의 기능이 데이터베이스와 연동되기 때문에 동작 시나리오를

나타내기 위해서 데이터 흐름도를 사용하였다.

가 사용자 정보 관리.

사용자 관리 시스템은 사용자의 역할 소속 그룹 틀린 횟수 최근 로그온 시간 로그온DN, , , , ,

가능 위치 및 기타 신상정보를 관리하며 특히 시스템 지원을 위한 서비스 별 인증, Legacy

정보를 관리하고 있어서 통합된 사용자 계정관리가 가능하다 그림 는 사용자 정보 관. ( 6-49)

리의 데이터 흐름도이다.

그림 사용자 정보 관리 데이터 흐름도( 6-49)

- 272 -

그림 초기 실행 화면( 6-50)

그림 사용자 정보 관리 화면( 6-51)

- 273 -

그림 서비스별 인증정보 조회( 6-52)

나 그룹 정보 관리.

그림 그룹 정보 관리 데이터 흐름도( 6-53)

- 274 -

그룹 정보 관리는 그룹 속성 소회 수정 추가 및 삭제 기능을 제공하고 그룹에 속한 사용, ,

자 리스트를 조회를 제공하며 또한 그룹의 역할속성은 제공한다 데이터 흐름도는 그림. (

과 같다6-53) .

그림 그룹 정보 관리 화면( 6-54)

다 역할 정보 관리.

사용자 관리 시스템은 역할 정보를 관리하며 역할에 속한 권한 속성 리스트 조회 및 추가,

삭제를 제공하며 역할에 속한 서비스 정보 조회 및 추가 삭제 기능을 제공한다 역할 정보, .

관리의 데이터 흐름도는 그림 와 같다( 6-55) .

- 275 -

그림 역할 정보 관리 데이터 흐름도( 6-55)

그림 역할 정보 관리 화면( 6-56)

라 기타 정보 관리.

사용자 관리 시스템은 앞서 언급된 정보 외에 서비스 정보 권한 속성 정보 회사 정보 부, , ,

서 정보 직급 정보를 관리한다, .

- 276 -

그림 기타 정보 관리( 6-57)

사 접속 사용자 조회 기능.

그림 접속 사용자 조회 데이터 흐름도( 6-58)

사용자 관리 시스템은 인증 서버가 로그 데이터 베이스에 남긴 사용자 인증 내역을 조회하

여 접속 사용자를 조회하는 기능을 제공한다 그림 은 접속 사용자 조회 데이터 흐름도.( 6-58)

이다.

- 277 -

그림 접속 사용자 조회 화면( 6-59)

- 278 -

제 장 결론 및 향후 연구과제7

본 장에서는 에 대한 연구개발 내용을 요약하고 장에서 제시한 설계목표의 관SecureSSO 3

점에서 시스템을 분석하는 동시에 기존 연구와의 비교를 통해 개발 시스템을SecureSSO

분석하며 마지막으로 본 과제의 향후 연구과제를 제시하면서 곁론을 맺고자 한다.

제 절 연구 개발 요약 및 시스템 분석1

본 과제에서는 단일 인증의 편이성과 통합적이고 효율적인 사용자 관리기능 이외에 공개키

기반 구조와의 연계를 통해 강력한 보안기능을 제공하며 다양한 응용 시스템에 쉽게 적용

가능한 시스템인 시스템을 개발하였다SSO SecureSSO .

의 개발을 위해서 사용자 인증 기법 및 공개키 기반 기술과 같은 관련 연구와SecureSSO

기존의 시스템을 분석하였으며 그 결과를 토대로 강력한 초기 인증 통합된 접근통제SSO ,

시스템 다양한 응용 시스템에 쉽게 적용할 수 있는 유연성 있는 구조 기반의 시스템, , PKI ,

통합된 사용자관리 지원 개방된 표준과 기술규격 지원으로 구성된 시스템 설계 목표를 제,

안하였다.

제안된 설계 목표를 통해 본 과제에서는 통합된 접근통제 시스템을 지원하는 의X.509 v2

기반 구조와 다양한 웹 환경에 쉽게 적용할PMI(Privilege Management Infrastructure)

수 있도록 웹 기반의 유연성 있는 구조를 갖는 시스템을 설계하였으며 또한SecureSSO ,

인증서 기반의 신뢰성 있는 프로토콜을 제시하였고 통합된 사용자 계정관리 및 권한 인SSO

증서 발급을 위한 를 설계하였다SecureDB .

- 279 -

표 설계목표와 시스템 구조[ 6-6] SecureSSO

설계목표 시스템SecureSSO

강력한 초기인증

당사의 제품인 토큰USB SecureKey 를 지원하기 때문에

인증을 제공하며 동시에 인증서 기반의 사용자 인증을2-factor

제공함

통합된 접근통제관리

시스템

발급자인 서버를 중심으로 기반의 통합된 접AC SecureSSO PMI

근통제 기능 제공

기능제공SSO

인증초기에 사용자의 개인키를 접근하기 위한 번호입력을- PIN

단한번 요청함

시스템을 위해 에 로그온 정보를 추가하여 응용서- Legacy AC

버에 전달함

유연성있는 구조

서버측면과 클라이언트측면에서 여러 가지 상황을 고려한 유연-

성 있는 구조제공

웹 환경에 적용이 용이한 구조제공-

기반의 시스템PKI전자서명을 통한 기반의 강력한 사용자 인증과 상호인증 부PKC ,

인봉쇄지원

통합된 사용자관리

지원

서버의 자체 데이터베이스인 에 사용자 신SecureSSO SecureDB

상정보 및 서비스별 로그온 정보등을 관리함으로써 통합되고 일

관된 사용자 관리기능을 지원

사용자별 주문형

인터페이스초기 인증시 사용자 맞춤형 페이지를 제공함

개방된 표준과

기술규격지원

에서 제시된 및 구조 지원 및 국내 공인인증기관X.509 PKI PMI

과의 연동을 위하여 한국정보인증의 툴킷 적용

시스템은 라이브러리를 국내 설정에 맞게 개선한 암호화 통신 라이SecureSSO OpenSSL

브러리 와 인증서 기반의 사용자 인증 라이브러리SecureSSLLib SecureCertLib,

인증 서버 클라이언트 응용 서버 사용SecureSSO , SecureSSO , SecureSSO , SecureSSO

자 관리 시스템으로 구성되며 이들 구성요소를 중심으로 개발되었다.

- 280 -

특히 는 다양한 인증서 처리 툴킷을 기원할 수 있도록 확장성 있는 구소로, SecureCertLib

설계되었으며 사설 인증기관 지원을 위해서 을 적용하였고 국내 공인인MS CryptoAPI 2.0

증기관과의 연계를 위해 한국정보인증의 툴킷을 적용하였다.

표 은 장에서 제시된 시스템의 설계목표의 관점에서 시스템을 분석하고[ 6-6] 3 SecureSSO

있으며 시스템이 주어진 설계목표를 만족함을 보이고 있다SecureSSO .

또한 표 은 주어진 설계목표를 만족하는 시스템을 기존연구와 비교했을 때,[ 6-7] SecureSSO

시스템이 기존 시스템보다 기반구조 로그온 자동화 유연성 있는 구조 등SecureSSO PMI , ,

에서 우수함을 보여주고 있다.

표 시스템과 기존연구의 비교[ 6-7] SecureSS0

비교항목SecureSS

O커버러스 SESAME SuiteSpot WDAI RSA Keonⓡ

통합된 접근통제 O O O O

기반구조PMI O

기반의PKC

사용자 인증O O O O O O

초기 인증생략 O O

상호인증 O O O O O O

부인봉쇄 O O O O O

Legacy

시스템지원O O

유연성있는

구조SSOO O

로그온 자동화

기능지원O

통합된

사용자관리지원O O O O O O

주문형

인터페이스O O

- 281 -

제 절 향후 연구 과제2

본 과제의 추후 연구과제는 다음과 같다.

첫째로 실제 사이트에서 수 차례에 걸친 시스템 구축을 통해 의 구SecureSSO SecureSSO

조와 인증 프로토콜의 효율성 및 보안성이 평가되고 개선되어야 한다.

둘째로 다양한 웹 환경에 쉽게 적용될 수 있는 범용의 에이전트 구조가 연구되어야 한다.

셋째로 에는 단기간의 온라인 를 고려한 구조이기 때문에 별도로 의 유효SecureSSO AC AC

성 검증 방식을 두지 않았다 하지만 엄격한 정책이 적용되거나 장기간의 오프라인 가. AC

적용될 경우를 위해 별도의 효율성 있는 유효성 검증방안이 연구되어야 한다.

넷째로 작업부하가 집중될 서버의 확장성과 한 특성을 지원하기SecureSSO fault-tolerant

위한 연구가 이루어져야 한다.

- 282 -

참 고 문 헌

[1] A. Aresenault, S. Turner, "Internet X.509 Public Key Infrastructure,"

draft-ietf-pkix -roadmap-06.txt, 2000.

[2] S. Farrell, P. Housley, "An Internet Attribute Certificate Profile for

Authorization," draft- ietf-pkix -ac509prof-05.txt, 2000.

[3] Sumner Blount, "Secure Portal Managenient,"

http://www.eaijounal.com/SystemManagement/Secureportal.asp, 2000

[4] netegrity, "SiteMinder Affiliate Agents White

Paper,"http://www.netegrity.com/pdf/AffiliateWhitePaper.pdf, 2000

[5] P. Ashley, M. Vandenwauver, J. Claessens, "Using SESAME to Secure Web

Based Application on an Intranet," Secure Information Networks, Proceedings of the

IFIP TC6/TC11 Joint Working Conference on Communications and Multimedia,

CMS'99, Lenven, Belgium, pp303-317, 1999.

[6] Jose Kahan, "WDAI a simple World Wide Web distributed authorization

infrastructure," http://decweb.ethz.ch/WWW8/data/2153/html/ 1999.

[7] Hursti, "Single Sign-On," Proceeding of the Seminar on Network Security 1997,

Helsinki University of Technology, <http://www.tml.hut

fi/Opinnot/Tik-110.501/l997/single-sign -on.html>,1997.

[8] Philip Carden, "The New Face of Single Sign-On,"

<http://www.planetjt.com/techcenters/docs/networking/technology/PIT19990421S0013/

1 .htm>. 1999.

- 283 -

[9] microsoft, Single Sign-On in Windows 2000 Networks, white Paper,

<http://www.rnicrosoft.corn/TechNet./Win2000/Win2ksrv>

홍익대과학기술연구소 기반의 전상망 보안시스템 개발 위탁연구[10] , “ Single Sign-On ,”

과제개발보고서, 1999.

[11] Camillo, "Unified Single Sign-On,"

http://www.europe.datafellows.com/staff/ged/own/NetSec-1998, 1998.

[12] Fred L. "Secure Single Sign-On in a Multi-Platform Environment,"

<http;//www.redbooks.ibm.com/abstracts/gg244282.html>, 1998.

[13] RSA Security, "RSA Keonⓡ Advanced PKI: A security architecture for enabling

e-business solution white paper,

http://www.rsasecurity.com/products/keon/Whitepapers/advpkiwp/Keon_v5_architectur

e_WP.pdf

[14] RSA Security, "Security Services Provided by the RSA Keonⓡ Desktop v5.5

white paper,"

http://www.rsasecurity.com/products/keon/Whitepapers/desktop/rsa_keon_desktopwp.p

df

[15] RSA Security, "Application Integration using the RSA Keonⓡ Agent SDK v5.1

arid Developed Agents,"

http://www.rsasecurity.com/products/keon/whitepaers/sdk_app-lication_integration/rsa

_keon_agent_sdk_wp.pdf

[16] Netscape, "Single Sign-On Deployment Guide,"

http://developer.netscape.com/docs/manuals/security/SSO/-contents.htm

[17] Novell, "Novell Single Sign-on."

- 284 -

http://www.novell.com/documentation/lg/sso2/docui/index.html

[18] EVIDIAN, "Web SSO features."

http://www.bullsoft.com/accessmaster/websso/features.htm

[19] Cylink, "Cylink PrivateWire 3.0,"

http://www.cylink.com/products/internetvpn/privatewire/-privatewire.htm

[20] I/O Software, Ine., "SecureSession" http://www.iosoftware

com-/products/consumer/securesuite/s-session.htm

[21] Symantec, "PassGo," http://enterprisesecurity.Symantec.com/products

[22] M. Sirbu, J. Chuang. "Distributed Authentication in Kerberos Using Public Key

Cryptography," Syinposium On Network and Distributed System Security, 1991.

[23] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, J. Trostle.

"Public Key Cryptography for Initial Authentication in Kerberos," Internet Draft,

1999

[24] J. Kohl, C. Neuman. "The Kerberos Network Authentication Service (VS),"

Request for Comments 1510.

[25] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld, A. Medvinsky, M.

Hur. "Public Key Cryptography for Cross-Realm Authentication in Kerberos,"

Internet Draft

[26] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman, "Public Key

Utilizing Tickets for Application Servers (PKTAPP)," Internet Draft

[27] M. Vandenwauver, R. Govaerts, J. Vandewalle, "Overview of Authentication

Protocols: Kerberos and SESAME," Proceedings 31st Annual IEEE Carnahan

Conference on Security Technology, pages 108-113, 1997.

- 285 -

[28] M. Vandenwauver, R. Govaerts, J. Vandewalle, "How Role Based Access

Control is implemented in SESAME," Proceedings of the 6-th Workshops on

Enabling Technologies: Infrastructure for Collaborative Enterprises, pages 293-298,

IEEE Computer Society Press, 1997.

[29] M. Vandenwauver, JR. Govaerts, J. Vandewalle, "Role based access control in

distributed systems," Communications and Multimedia Security, volume 3, pages

169-177, 1997.

[30] M. Vandenwauver, R. Govaerts, J. Vandewalle, "Public key extension used in

SESAME V4," Presented at Public Key Solutions PKS'97, 1997.

[31] P. Ashley, "Authorization For a Large Heterogeneous Multi-Domain System,"

Australian Unix and Open Systems Group National Conference, 1997.

[32] European Computer Manafactures' Association, "Authentication and Privilege

Attribute Security Application with Related key distribution functions," EGMA

Standard 219, 1994.

- 286 -

기술개발결과 내역o

구분

총참여

인력

(M/Y)

국내특허 국제특허 논문

시제품 S/W

기타

기술문서:

등TM,TD )출원 등록 출원 등록

SCI,

SSCI

국제

학술

국내

학술

차년도1 5.7 0 0 0 0 0 0 2 0 6기술문서

건7

차년도2 0 0 0 0 0 0 0 0 0 0

총 계 명5.7 건0 건0 건0 건0 건0 건0 건2 건0 건6기술문서

건7

지적재산권 명세o

구분 제목 성명 국명 출원번호 출원일 등록번호 등록일 비고

국내외 특허 실용신안 의장등록 저작권 컴퓨터프로그램보호권등으로 구분, , , ,※