공개키 기반 구조(PKI)

공개키 기반 구조 개념

• 공개키 기반 구조 (PKI, Public Key Infrastructure)는 메시지의 암호화 및 전자서명을 제공하는 복합적인 보안 시스템 환경
• 공개키 암호 시스템을 사용하여 데이터의 기밀성 및 인증을 제공하는 기반 구조
• 전자상거래를 위한 필수 요소 ex) 전자정부, 인터넷 뱅킹 등

사용자는 공개키와 개인키 두 가지의 정보를 사용한다

공개키는 다른 누군가에 의해서 쉽게 위변조 될 수 있다.

그래서 받는 사람이 사용자가 사용하는 공개키가 자신이라는 것을 확인할 수 있어야함.

즉, 공개키를 안전하게 사용할 수 있도록 제공해주는 것이 공개키 기반 구조이다.

 

공개키 암호 시스템

• 기밀성 (Confidentiality) 
  • 데이터의 정보를 감춤
  • 암호 알고리즘 : ElGamal, RSA 등
• 인증 (Authentication)
  • 데이터 인증 : 데이터 무결성 인증 / 데이터의 위변조 여부 인증
  • 사용자 인증 : 데이터의 생성자 인증
  • 전자서명 : DSA, RSA 등

 

공개키 사용의 문제점

Man in the Middle of Attack | 중간자 공격

악의적인 공격자가 공개키를 위변조할 수 있음

Bob은 \(P_A\)가 Alice의 것임을 어떻게 믿을 수 있을까?

=> 공개키에 대한 인증 또는 증명(Certification) 필요

 

공개키 기반 구조

목적 : 그 공개키가 누구의 공개키인지 인증서를 발급해주는 것

• 인증서 (Certificate) : 각 사용자의 공개키에 대한 증명서
• 인증기관 (CA) : 각 사용자의 공개키에 대한 인증 및 증명서 발급
• PKI (Public-Key Infrastructure) : 사용자 + 공개키 + 인증서 + 인증기관으로 구성

인증서

누구나에 의해서 확인될 수 있어야하기 때문에 표준이 존재함

• 국제 표준 : x.509
• 국내 표준 : 전자서명 인증서 프로파일 규격

인증서의 호환성 : 서로 다른 인증 기관이 발급한 인증서 상호 호환

인증서 발급의 용이성 : 인증서 발급, 갱신 및 관리가 쉬워야함

 

인증 기관 (CA)

계층적 인증 구조

용도 

• 인증서 사용 용도 상이 ex) 개인, 사업자, 공공
• 용도에 따른 발급 정책 상이
• 인증 기관 분리

조직 구성의 차이 : 발급 정책에 따른 업무 분담

지리적 차이 : 실제 인증 기관들이 분산되어 위치

로드 균형 조정 : 대량의 인증서를 분산 발급 및 관리

• PAA (정책 승인 기관) 
  • 공인인증서에 대한 정책을 결정
  • 하위 기관의 정책을 승인하는 기관
  • 과학 기술 정보 통신부
• PCA (정책 인증 기관)
  • Root CA : 모든 인증서의 기초가 되는 인증서 보유
  • 기본 정책을 수립 : 범용, 공용 또는 개인, 기관용 인증서 관리 정책
  • KISA 한국 인터넷 진흥원
• CA (인증 기관)
  • 인증서 발급과 취소 등의 실질적인 업무 담당
  • CA는 상호간 신뢰 : 별도의 상호 인증서 발행 불필요
  • 금융결제원, 한국 정보 인증, 한국 전자 인증
• RA (등록 기관)
  • 사용자의 신분 확인 : 신분증, 사업자 등록증, 인감 증명서
  • 등록 대행 기관 : 은행 영업점, 한국 전자 인증, 상공회의소 등

 

공인인증서

역할 

• 공개키와 소유자를 연결시켜주는 전자 문서
• 1978년 펠더가 제안
• 인증기관 (CA)가 발급 : 인증서 + 발급기관의 전자서명
• 표준 규격 : x.509버전 3 표준

 

X.509

구성

• 데이터 : 기본 영역 + 확장 영역
• 전자서명 : 데이터 영역을 발급자의 개인키로 전자서명

인증서의 기본 영역

• 버전 : 인증서의 형식 구분
• 일련번호 : 인증서 발급한 인증기관 내의 인증서 일려번호
• 서명 알고리즘 : 인증서를 발행 시 사용한 서명 알고리즘 ex) sha1RSA : 해시로는 sha1 서명은 RSA
• 발급자 : C(Country), O(Organization), OU(Organization Unit 조직), CN(Common Name 일반적인 이름)
  ex) C= KR, O(yessign), OU(AccreditedCA), CN (yessignCA)
• 유효기간(시작, 끝) : 인증서를 사용할 수 있는 기간으로 시작일과 만료일을 기록 (초단위까지 표시)
• 주체 : 인증서 소유자의 DN - C,O,OU,CN
• 공개키 (1024bit) : 사용자의 공개키 값

 

인증서의 기능

• 누구나 사용자의 인증서를 획득 -> 공개키 획득
• 인증기관 외에는 인증서를 수정/발급 불가
• 같은 인증 구조 내의 사용자는 상호 인증서 신뢰

 

폐기 인증서 관리

• 유효기간이 남아있는 인증서의 사용 금지
  • 공개키에 대한 개인키 유출
  • 공개키 또는 인증서 갱신
• 인증서의 폐기
  • 인증기관은 폐시된 인증서 목록을 주기적으로 발급
  • 인증서 폐기 목록 (CRL) : X.509 표준
    인증기관이 전자서명을 하여 발급한다. (bad-list : 폐기된 인증서에 관한 정보만 유지)(good-list : 목록에 포함된 인증서만 사용)

 

인증서의 사용

인증서 : 기본 영역 + 인증기관의 개인키로 서명된 전자서명 

CA의 전자서명 인증 

-> CA의 공개키에 대한 인증이 필요함 -> CA의 공개키에 대한 인증서 발급 

-> CA의 공개키 + 인증서 + PCA의 개인키로 전자서명

 

즉, 인증서는 사용자 인증서 + CA 인증서 + PCA인증서이다.

Verify (PCA 공개키, CA 인증서) -> 

Verify (CA 공개키, 사용자 인증서) ->

Verify (사용자 공개키, 사용자 전자서명)

 

우리나라 인증 기관은 많지 않기 때문에 CA 공개키를 미리 저장해서 알고 있으면 검증하기가 더 쉬움

 

 

정리해보자

A가 M에 대해서 서명을 생성한다 : Sig(H(M), A의 개인키)

서명 검증을 위해 A의 인증서 제공

 

이 서명을 검증하고자 하는 검증자는

1. 인증서의 유효성 검증 -> 인증서의 전자서명이 맞는지 확인
2. 인증서로부터 A의 공개키를 얻을 수 있음
3. Verify (공개키, sig)

이때 메세지가 같으면 검증한게 맞다는 것을 확인할 수 있음

 

 

전자 봉투 (하이브리드 암호 스킴)

A가 B에게 어떤 메세지를 암호화해서 보내고 싶다.

이 메세지를 암호화하기 위해 공개키 암호 시스템을 사용하고자 하면 시간이 너무 오래 걸린다. 

따라서, 메세지 자체를 암호화하기 위해서는 대칭키를 사용한다. 이 대칭키를 SK라고 하자

그럼 어떻게 둘만 아는 대칭키를 생성하는가?

1. A는 대칭키 SK를 랜덤하게 선택한다.
2. PKE(B의 공개키, SK)
3. E(SK, M + sig(A의 개인키, H(M)) + 인증서) -> 3DES, AES같은 대칭키로
   A가 생성한것이 맞는지 검증하기 위해 전자 서명과 인증서도 생성해서 보냄
4. PKD(B의 개인키, PKC) -> SK 복호화
5. D(SK, C) -> 원문 메세지, 서명, 인증서 확인 가능
6. 서명이 A에게 만들어진 것이 맞는지 인증서를 검증
7. 인증서의 공개키로 서명 검증

-> 인증서의 문서가 변화가 없고 A가 생성한 것이 맞다는 것을 확인할 수 있음

 

철수 -> 영희

* 이때 영희의 공개키도 영희의 인증서로부터 얻는다. (보내기 전에 부탁하는..,,)

 

서명과 인증서는 암호화 시키지 않고 보내도 상관 없음