반응형

이번 포스팅은 공개키 인증서에 대하여 알아보도록 하겠습니다.

 

공개키 인증서 ( Public Key Certificate )

 

공개키 인증서는 PKI 에서 없어서는 안될 중요한 PKI의 요소입니다. 그럼 공개키 인증서는 무엇일까요? 단어만으로 해석하면 공개키를 인증하는 문서라고 할 수 있습니다. 이것은 맞는 말입니다. 공개키 인증서가 무엇인지 자세히 알아 보기 전에 우리 주위에서 흔히 볼 수 있는 인증서들을 살펴 보겠습니다. 

 

우리 주위의 인증서


우리 주위에서 흔히 볼 수 있는 인증서로는 주민등록증, 운전면허증, 그리고 신용 카드를 예로 들 수 있습니다. 이것 이외에도 등기부 등본이나 학생증, 여권, 재직 증명서 등 수도 없이 많은 인증서가 우리 주위에 있습니다.

 

인증서의 역할은 신분을 인증하는 것입니다. 주민등록증은 주민등록증 상에 있는 사람이 주민임을 인증하며, 운전면허증은 그 사람이 운전을 해도 된다는 것을 인증합니다. 그리고 신용카드는 신용카드의 주인이 물건을 구입해도 된다는 것을 인증하며, 학생증은 학생증 안의 사람이 해당 학교의 학생임을 인증합니다. 마찬 가지로 여권은 여권에 기입되어 있는 사람이 여행 할 수 있는 권한이 있다는 것을 인증하며 등기부 등본은 그 안의 사람이 집이나 건물의 주인 이라는 것을 인증합니다. 재직 증명서는 그 안의 사람이 해당 회사에 재직 하고 있다는 것을 인증합니다.

 

이렇듯 우리 주위에는 많은 인증서를 볼 수 있습니다. 그리고 인증서들은 각자 인증 하는 것이 다르다는 것을 알 수 있습니다.

 

그럼 더 자세히 인증서에 대해서 예와 함께 알아 보겠습니다. 

위에서 설명한 많은 종류의 인증서를 전부 예로 들 수는 없고 운전 면허증과 신용 카드를 예로 들겠습니다.

 

운전면허증

 


운전면허증은 이 것을 가지고 있는 사람이 운전을 할 수 있는 자격이 있음 증명, 혹은 인증 하는 기능을 합니다.

운전면허증에는 다음과 같은 항목들을 볼 수 있습니다.

 

항목
인증서 명 자동차 운전 면허증
면허 종류 2종 보통
면허 번호 서울 92-142423-45
성명 홍 길 동
주민 번호 720504-10XXXXX
주소 서울시 서초구 방배동 4231
사진  
적성 검사 기간 2005.11.03 ~ 2006.02.04
발급 날자 1999.01.23
발급 자 서울 지방 경찰청장
발급 자 도장 도장과 홀로그램

 

운전면허증의 각 항목은 모두 의미가 있는 것입니다.  각 항목들은 다음과 같은 의미가 있습니다.

인증서 명은 운전면허증이란 이 명함처럼 생긴 카드가 어떤 것인지를 표시 합니다.

성명, 주민번호, 주소는 운전면허증의 소유자의 정보를 표시합니다.

일련 번호는 발급한 많은 운전면허증 중에서 이 운전면허증을 유일하게 식별합니다.

면허 종류는 이 운전 면허증의 권한을 표시 합니다. 즉, 2종 보통인 면허 종류가 표시된 운전 면허증으로는 1종 운전을 할 수 없습니다.

발급 날짜 와 적성검사 기간은 기타 정보를 표시합니다.

발급자는 이 운전 면허증을 발급한 곳을 표시합니다.

사진은 이 운전면허증을 소지 하고 있는 사람이 정말 이 운전면허증에 표시된 소유자가 맞는 지를 증명 하는 역할을 합니다.

발급자 도장은 이 운전 면허증이 정말 발급자로부터 발급 된 것인지를 증명하는 역할을 합니다.

 

그리고, 또 다른 예로 신용 카드도 살펴 보겠습니다.

 

신용카드

 


신용카드는 이 것을 가지고 있는 사람이 물건을 살 수 있는 자격을 부여 받았다는 것을 증명, 혹은 인증 하는 기능을 합니다.

신용카드에는 다음과 같은 항목들을 볼 수 있습니다.

 

항목
인증서 명 삼성 카드
카드 종류 골드 카드
카드 번호 1234-5678-1234-5678
성명 홍 길 동
유효 기간 11/2004
서명 사인과 비밀 번호
발급 자 삼성 카드
발급 자 서명 홀로그램

 

신용카드 역시 각 항목은 모두 의미가 있습니다.

인증서 명은 이 인증서가 어떤 것인지를 표시합니다.

성명은 신용카드의 소유자의 정보를 표시합니다.

카드 번호는 발급한 많은 신용카드 중에서 이 신용카드를 유일하게 식별합니다.

카드 종류는 이 신용카드의 권한을 표시합니다. 일반 카드 보다는 골드 카드가 더 많은 물건을 살 수 있습니다.

유효 기간은 이 신용카드를 사용 할 수 있는 기간을 표시합니다.

서명은 이 신용카드를 소지 하고 있는 사람이 정말 이 신용카드에 표시된 소유자가 맞는 지를 증명 하는 역할을 합니다.

발급자는 이 신용카드를 발급한 곳을 표시합니다.

발급자 서명은 이 신용카드가 정말 발급자로부터 발급 된 것 인지를 증명하는 역할을 합니다.

 

지금 까지 운전면허증과 신용카드라는 인증서와 그 안에 들어 있는 항목에 대해서 살펴 보았습니다. 

다음엔 이 항목들이 하는 역할을 좀더 자세히 알아 보겠습니다.

 

인증서 안의 항목들의 역할

 


1) 발급자

인증서는 인증서를 발급하는 발급자 혹은 발급 기관을 통해 얻을 수 있습니다. 우리가 인증서를 보고 인증서의 내용을 믿을 수 있는 이유는 우리가 그 인증서를 발급한 발급자를 믿고 신뢰하기 때문입니다. 운전면허증이나 신용카드 안의 내용을 신뢰하는 것은 우리가 그것들을 발급한 해당 경찰청이나 카드사를 신뢰하기 때문입니다. 따라서 인증서 안에도 발급자의 정보가 있게 됩니다.

 

2) 소유자

인증서에는 그 인증서의 소유자의 정보가 있습니다.  그 소유자 정보로 인증서의 주인이 누구인지를 알 수 있습니다. 운전면허증에는 성명과, 주민번호, 주소가 있었습니다. 그리고 신용카드에는 성명이 있습니다.

 

3) 인증서의 권한 혹은 정책

인증서에는 그 인증서의 권한과 그 인증서로 할 수 있는 것의 정보가 있습니다. 운전면허증에는 면허 종류가 있었고 신용카드에는 카드 종류가 있었습니다. 이런 정보를 통해 해당 인증서로 할 수 있는 것을 알 수 있습니다. 2종 보통의 운전 면허증으로는 1종 운전을 못 합니다. 그리고 보통 카드로는 골드 카드와 같이 많은 금액의 물건을 사지 못 합니다. 이런 것은 인증서의 권한을 나타낸다고 할 수 있습니다. 그리고 신용카드 중에는 주유 카드나 백화점 카드 같이 일부의 곳에서만 사용 가능한 카드가 있습니다. 이런 것은 권한 보다는 신용카드로 할 수 있는 것의 종류를 나타낸다고 할 수 있겠죠.

 

4) 유효기간

인증서에는 유효기간이 있습니다. 운전면허증같이 없는 인증서도 있지만, 대부분의 인증서에는 유효 기간이 있습니다. 신용카드에는 유효기간이 있음으로 해서 해당 신용카드를 사용 할 수 있는 기간을 정합니다. 즉, 신용카드라는 인증서는 인증서 안에 적힌 유효기간 내에만 유효하고, 그 기간 외에는 인증서로서 사용 할 수 없습니다.

 

5) 일련 번호

인증서에는 발급자가 발급한 같은 종류의 인증서 중에서 해당 인증서를 유일하게 식별 할 수 있는 일련 번호가 있습니다. 운전 면허증에는 면허 번호가 있으며 신용카드에는 카드 번호가 있습니다. 이 일련번호로 인증서를 식별하게 됩니다.

 

6) 소유자임을 입증 하는 정보

인증서에는 그 인증서의 소유자임을 증명 할 수 있는 정보가 있습니다. 운전면허증의 경우에는 사진이 있었고, 신용카드의 경우에는 카드 뒷면의 사용자 서명과 비밀번호가 있습니다. 이외에도, 주민등록증은 뒷면의 지문이 이런 역할을 합니다. 이런 인증서의 소유자임을 증명 할 수 있는 정보가 있는 이유는 인증서의 남용을 방지하기 위해서입니다. 예를 들어 운전면허증을 누군가 몰래 가져가서 운전면허증의 권리를 행사할 수 있는 경우가 발생할 수 있을 것입니다. 이를 방지하기 위해서 인증서에는 실제 소유자임을 입증할 수 있는 정보가 있습니다.

 

7) 발급자의 서명

인증서에는 그 인증서가 인증서에 있는 발급자로부터 진짜 발급된 것인지 증명하는 정보가 있습니다. 운전면허증의 경우에는 경찰청장의 도장과 홀로그램이 있으며, 신용카드의 경우는 카드사의 홀로그램이 있습니다. 이 정보는 매우 중요한 것입니다. 우리가 인증서를 신뢰하는 이유는 그 인증서를 발급한 발급자를 신뢰하기 때문이라고 했습니다. 따라서 발급자를 사칭한 누군가가 인증서를 발급한다면 우리는 그 인증서를 믿을 수 밖에 없을 것입니다. 이를 방지하기 위해 발급자를 인증할 수 있는 정보가 인증서 안에 들어있는 것입니다.

 

그리고 이 외에도 인증서에는 필요한 기타 정보들이 있을 수 있습니다.

 

지금까지 운전면허증과 신용카드라는 인증서의 예를 통해서 인증서 내용 중 중요한 7가지 종류의 항목을 살펴 보았습니다. 여기서 설명한 내용은 다음에 설명할 공개키 인증서에 그대로 적용됩니다. 공개키 인증서는 운전면허증 같은 보통의 인증서들의 개념에서 많은 부분을 채용했기 때문입니다.

 

공개키 인증서

 


공개키 암호화의 가장 큰 문제는 암호화 통신을 하고 싶은 상대방의 공개키를 어떻게 알 수 있는가, 혹은 공개키에 맞는 개인키를 가지고 있는 사람이 누구인지 아는 것입니다. 이것을 해결하기 위해 PKI가 있는 것이고 여기서 가장 중요한 핵심은 공개키 인증서 입니다.

 

모든 인증서의 역할은 무엇인가를 인증하는 것이라고 했습니다. 공개키 인증서는 바로 공개키를 인증하기 위한 인증서입니다. 공개키를 인증한다는 것을 더 자세히 말하면 공개키와 공개키에 맞는 개인키를 소유하고 있는 사람이 서로 맞다는 것을 인증하는 것입니다. 

 

앞서 살펴본 다른 인증서들의 항목과 같이 공개키 인증서도 많은 항목으로 구성되어 있습니다. 이 항목들은 앞서의 다른 인증서들과 크게 다르지 않습니다. 공개키 인증서의 목적은 공개키가 해당 소유자의 것임을 인증하는 것이라는 것을 염두에 둔다면, 운전면허증이나 신용카드 같은 보통의 인증서와 비교해서 인증의 대상만 차이가 있을 뿐 다른 것들은 크게 차이가 없습니다.

 

그럼, 앞서 살펴본 주위의 인증서에 있는 여러 가지 항목에 해당되는 공개키 인증서의 항목을 살펴 보겠습니다. 공개키 인증서를 간단히 인증서라고도 합니다. 앞으로는 공개키 인증서를 간단히 인증서라고 하겠습니다.

 

- 발급자 정보에는 인증서를 발급한 인증 기관의 정보가 있습니다.

- 소유자 정보에는 공개키의 주인, 즉 공개키에 해당되는 개인키를 가지고 있는 사람의 정보가 있습니다.

- 공개키 정보에는 공개키가 있습니다. 주로 공개키는 16진수의 숫자로 표현됩니다. 왜냐하면 바이너리보다는 글자로 표현 하기 쉬운 16진수가 보기 편하기 때문입니다.

- 유효기간 정보에는 인증서가 유효한 시간 정보가 있습니다. 유효 기간은 시작 기간과 종료 기간으로 되어 있습니다.

- 인증서의 권한 또는 역할 정보에는 이 인증서의 신용 등급과 이 인증서를 사용하는 용도에 관한 정보들이 있습니다.

- 일렬 번호 정보에는 인증 기관이 발급한 인증서에 붙인 시리얼 번호가 해당됩니다.

- 발급자 임을 증명 할 수 있는 정보에는 발급자의 전자 서명 값이 있습니다.

- 소유자 임을 증명 할 수 있는 정보에 대한 항목은 공개키 인증서에는 들어 있지 않습니다. 대신 소유자가 가지고 있는 개인키가 그러한 역할을 합니다.

 

각 항목에 대한 예를 보이면 다음과 같습니다.

 

항목
발급자 정보 NEW CA Company
소유자 정보 홍 길 동
인증서 권한 또는 역할 High Level, 모든 목적용
유효 기간 2003-05-08 ~ 2004-05-08  
소유자 임을 증명 할 수 있는 정보 소유자의 개인키(인증서에 표시 되지는 않음)
발급자 인을 증명 할 수 있는 정보 발급자의 전자 서명
일련 번호 2924452834
공개키 정보  00:b1:07:8d:54:a6:7c:ed:d7:99:43:
 82:53:2d:5c:0b:58:e8:c0:fc:c6:f8:
 70:8b:1b:77:1d:8f:1f:20:96:71:fb:
 6e:fb:7c:aa:b4:93:b5:0c:31:f9:a4:
 8f:b7:db:49:b8:47:8f:9f:86:bc:e6:
 4b:9f:48:ba:9d:bb:d9:3d:08:c0:f6:
 7c:36:38:5d:b5:2e:0e:eb:82:4c:1f:
 80:4b:46:0e:de:ed:1c:5c:96:fa:65:
 6a:72:23:d7:ce:4d:77:2c:d8:10:a0:
 ad:64:f1:cd:8d:3a:8b:23:89:8c:18:
 5b:ff:f9:e7:59:e2:8d:a6:c2:26:75:
 40:51:06:7e:31:69:7e:f9

 

인증서는 하나의 전자적인 문서로 위와 같은 항목으로 구성되어 있습니다. 비록 운전면허증이나 신용카드와 같이 물리적인 것은 아니지만 형식은 비슷하다는 것을 알 수 있습니다. 예로 가상적인 인증서를 만들어 본다면, 다음 형태로 되어 있는 전자 문서일 것입니다.

 

--인증서
소유자 정보
    이름 : 홍길동
    회사 : 미래 주식회사
    주소 : 서울시 서초구 서초동 1111-111
    이메일 : hong@company.com
발급자 정보
   이름 : New CA Company
   주소 : 서울시 강남구 역삼동 212-121
   이메일 : ca@cacompany.com
일련 번호 : 2924452834
역할 : High Level, 모든 목적용
유효 기간
   시작 기간 : 2003-05-08
   종료 기간 : 2004-05-08
공개키  00:b1:07:8d:54:a6:7c:ed:d7:99:43:82:53:2d:5c:0b:58:e8:c0:fc:c6:f8:
          70:8b:1b:77:1d:8f:1f:20:96:71:fb:6e:fb:7c:aa:b4:93:b5:0c:31:f9:a4:
          8f:b7:db:49:b8:47:8f:9f:86:bc:e6:4b:9f:48:ba:9d:bb:d9:3d:08:c0:f6:
          7c:36:38:5d:b5:2e:0e:eb:82:4c:1f:80:4b:46:0e:de:ed:1c:5c:96:fa:65:
          6a:72:23:d7:ce:4d:77:2c:d8:10:a0:ad:64:f1:cd:8d:3a:8b:23:89:8c:18:
          5b:ff:f9:e7:59:e2:8d:a6:c2:26:75:40:51:06:7e:31:69:7e:f9
서명
          8f:b7:db:49:b8:47:8f:9f:86:bc:e6:4b:9f:48:ba:9d:bb:d9:3d:08:c0:f6:
          7c:36:38:5d:b5:2e:0e:eb:82:4c:1f:80:4b:46:0e:de:ed:1c:5c:96:fa:65:
          6a:72:23:d7:

 

실제로 컴퓨터 환경에서 사용되는 인증서의 형식은 물론 위의 형식과는 다릅니다. 하지만  항목들과 그 항목의 의미는 거의 같다고 할 수 있습니다. 실제로 현실 세계에서 사용되는 인증서의 각 항목들의 표기 방법이나 구성은 X.509 라는 표준을 따릅니다. 그래서 공개키 인증서를 흔히 X.509인증서 라고도 부릅니다.  X.509 형식의 인증서에 대해서는 다른 글에 포스팅 하였습니다. 이번에는 공개키 인증서에 대한 개념과 인증서 안에 들어가는 항목, 그리고 항목의 의미에 대해서만 잘 파악 하시길 바랍니다.

 

공개키 인증서가 사용 되는 방법

 


이제 공개키 인증서가 무엇인지, 그리고 공개키 인증서 안에는 어떤 내용들이 들어가는지 아셨을 것입니다. 이번 절에서는 공개키 인증서를 어떻게 사용하는지에 대해 알아 보겠습니다.

 

공개키 인증서의 목적은 공개키가 그 소유자의 것이 맞다는 것을 인증하는 것이라고 했습니다. 때문에 인증서 안에는 공개키와 소유자의 정보가 있습니다. 만약 철수영희의 인증서를 가지고 있다면 그 인증서 안에는 영희의 공개키와 영희의 정보가 들어있을 것이므로 인증서 안의 공개키는 영희의 것이라는 것을 알 수 있습니다. 그리고 인증서는 발급한 발급자가 넣은 전자 서명 값이 있기 때문에 철수가 인증서의 발급자를 신뢰한다면 그 인증서의 내용을 신뢰할 수 있을 것입니다.

 

근본적으로 인증서는 어떤 사람의 공개키를 쉽게 얻기 위해서, 또는 어떤 사람이 그 공개키의 소유자라는 확신을 얻기 위해서 사용합니다.

 

아주 간단하지만, 이 기능은 많은 파생 효과를 가져 올 수 있습니다. 하지만 실제적으로 인증서를 사용하는 목적은 다음 두 가지의 경우 입니다.

 

인증을 하기 위하여 사용

▶ 암호화 통신을 위한 키 교환을 하기 위하여 사용

 

이 두 가지의 목적은 공개키 암호화가 주로 사용되는 목적이랑 같습니다. 그 이유는 공개키 인증서는 공개키 알고리즘을 사용 하기 위한 기반 구조를 위해 존재하는 것이므로 인증서를 사용하는 목적과 공개키 알고리즘을 사용하는 목적이 같은 것은 당연하다고 하겠습니다.

 

인증서가 사용되는 상황을 자세히 살펴 보겠습니다.

 

키 교환을 위한 인증서 사용

 


1. 비밀키 암호화 통신을 하기 위해 상대방과 자신은 같은 비밀키를 공유해야 합니다. 공유할 비밀키를 얻기 위해서 공개키 알고리즘을 사용한 키 교환을 하려고 합니다.

 

2. 나는 비밀키를 생성합니다. 그리고 암호화 통신을 할 상대방의 공개키를 얻기 위해 상대방의 인증서를 얻습니다. 인증서의 내용은 발급자가 보증하므로 인증서의 공개키는 상대방의 것이라고 확신 할 수 있습니다.

 

3. 인증서를 통해 얻은 상대방의 공개키로 비밀키를 암호화해서 상대방에게 보냅니다. 중간에 누군가가 그 내용을 몰래 가로 챘다고 해도 공개키로 암호화 되어 있으므로 안심 할 수 있습니다.

 

4. 상대방은 자신의 개인키로 암호문을 복호화 해서 비밀키를 얻습니다. 이제 비밀키가 공유되었으므로 이 비밀키를 사용 해서 암호화 통신을 하면 될 것입니다.

 

5. 하지만 나는 내가 보낸 비밀키 암호문을 받은 사람이 내가 생각한 그 상대방이 맞는지는 확신 할 수 없습니다. 왜냐하면 인증서는 누구나 얻을 수 있으므로 다른 사람이 상대방을 사칭해서 2 ~ 4 번 과정을 수행 한 후 나와 비밀키 암호화 통신을 할 수도 있기 때문입니다. 이를 위해서는 다음에 설명할 인증서를 통한 인증 과정을 거쳐야 합니다.

 

인증을 위한 인증서 사용

 

여기서 의미 하는 인증은 사용자에 대한 메시지 인증과 사용자 신원 인증으로 나눌 수 있습니다.

메시지 인증과 사용자 인증 중에서 메시지 인증을 위해 인증서가 사용 될 때의 시나리오를 먼저 예상해 보겠습니다.

 

사용자에 대한 메시지 인증

 

1. 상대방은 나에게 보내려고 하는 메시지에 메시지 서명 값을 넣어서 메시지와 함께 보냅니다. 물론 서명 값은 상대방의 개인키로 만들 것입니다.

 

2. 나는 상대방의 인증서를 얻고, 그 인증서에서 상대방의 공개키를 얻습니다. 인증서의 내용은 발급자가 보증 하므로 인증서의 공개키는 상대방의 것이라고 확신 할 수 있습니다. 그리고 인증서를 통해 얻은 상대방의 공개키를 사용해 받은 메시지와 서명 값에서 메시지를 인증합니다.

 

3. 인증서를 통하여 상대방의 공개키가 맞는다는 것을 확신 할 수 있으므로 받은 메시지 서명이 인증되었다면, 보내온 메시지는 상대방이 보냈다는 것을 확신 할 수 있습니다.

 

사용자 신원 인증

 

그럼, 사용자 인증을 위해 인증서가 사용될 때의 시나리오를 예상해 보겠습니다. 

두 가지의 시나리오가 있습니다. 첫 번째의 시나리오는 다음과 같습니다.

 

1. 나는 상대방 인증을 위하여 Random 값을 생성합니다. 이 값은 문구(Challenge) 라고 부릅니다. 이 값을 상대방에게 보냅니다.

 

2. 상대방은 받은 문구 값을 자신의 개인키로 암호화해서 나에게 보냅니다.

 

3. 나는 이 암호문을 상대방의 인증서 안의 공개키로 복호화합니다. 복호화 한 값이 내가 처음 상대방에게 보냈던 문구 값과 같으면 상대방이 맞다는 것을 알 수 있습니다.

 

4. 인증서의 공개키와 맞는 개인키를 가진 사람은 인증서의 소유자밖에 없으므로 이런 인증 과정은 옳다고 생각 할 수 있습니다.

 

5. 인증서는 상대방의 공개키가 맞는다는 것을 확신시켜 주므로 이런 인증 과정을 확신시켜 줍니다.

 

그리고 두 번째의 인증 시나리오는 다음과 같습니다. 이 두 번째의 방법은 주로 첫 번째 방법과 함께 사용 되어서 사용자 인증의 확신을 높이는 역할을 합니다.

 

1. 영희 인증서 안에 자신을 나타낼 수 있는 이름을 기타 항목에 넣어 인증서를 발급합니다. 주로 자신의 네트워크 주소나 도메인 네임(ex. outphoto.com) 같은 DNS명을 넣습니다.

 

2. 영희는 철수에게 자신임을 인증하기 위하여 자신의 인증서를 보냅니다. 영희의 인증서는 인증서를 발급한 기관에 의해 증명된 것이므로 철수영희가 보낸 인증서의 내용이 옳다는 것을 확신할 수 있습니다.

 

3. 인증서 안의 영희의 주소가 들어 있는 DNS 항목과 영희가 접속한 실제 주소를 비교해 본 후 둘이 일치하다면 인증서를 보낸 사람이 영희라는 것을 확신할 수 있습니다.

 

지금까지 인증서를 사용하여 할 수 있는 일을 설명하였습니다.

 

정리해서 말하면, 인증서가 할 수 있는 일은 공개키로 할 수 있는 일과 같습니다. 하지만 인증서는 공개키를 제공 한다는 것에 덧붙여서 공개키와 그 소유자를 인증시켜 주는 중요한 기능을 제공해 줍니다.

 

 

Reference

1. https://blog.naver.com/nttkak/20130244771

 

 

 

반응형
반응형

이번 포스팅은 x.509 인증서에 대하여 알아보도록 하겠습니다.

 

1. X.509 인증서 정의

 


 

CA가 인증서를 발급할 때, 인증서에 들어가는 항목의 종류와 항목의 값들을 CA 나름대로 기입한다면 인증서를 사용하는 사용자마다 다른 형식의 인증서를 가지고 있을 것이기 때문에 인증서의 내용을 이해하는데 문제가 있을 것입니다.

 

따라서 인증서를 작성함에 있어서 어떤 표준이 있어야 합니다. 현재 가장 널리 사용되고 있는 공개키 인증서의 표준은 X.509 형식 입니다. X.509라는  것은 표준 번호입니다. 그래서 이 형식대로 작성된 인증서를 X.509 라고 부르는 것입니다.

 

X.509 인증서란 이름은 1988년에 CCITT에서 발행된 문서로부터 처음 알려지게 되었습니다. 현재 X.509 인증서는 버전 3까지 발표된 상태입니다. 버전 3 X.509 인증서를 X.509 v3”이라고. 그리고 이 X.509 인증서는 IETF에 의해 현재 인터넷의 표준 인증서 형식으로 정해지게 되었습니다.

 

2. X.509 인증서 항목


현재 X.509 인증서의 버전은 3이라고 했습니다. 이 버전3 X.509 인증서와 이전의 X.509 인증서와 다른 점은 버전 3에는 Extension이라고 하는 섹션이 추가되었다는 것입니다.  Extension 섹션은 여러 개의 항목으로 구성되어 있는데, 필수 적인 항목이 아니라 추가적인 사항을 나타내는 항목들로 구성되어 있습니다.

 

그럼 자세히 X.509 인증서(버전 3)에 들어가는 항목을 알아보겠습니다. Extension 항목은 중요한 것만 설명했습니다..

 

항목명 필수/옵션 여부 설명
필수 정보
Version 필수 인증서의 버전으로 v3의 값이 들어간다
SerialNumber 필수 인증서 고유의 일련 번호
Signature 필수 발급자의 서명
Issuer 필수 발급자의 정보
DN (distinguished name)형식으로 들어갑니다.
Validity 필수 인증서의 유효 기간. 
시작 날자와 종료 날자가 함께 들어 갑니다.
Subject 필수 주체의 정보
DN (distinguished name)형식으로 들어갑니다.
SubjectPublicKeyInfo 필수 주체의 공개키
Extension
SubjectAltName 필수/옵션 주체의 다른 이름을 나타냅니다. 
여기서는 DN형식이 아니라 어떤 종류의 값이라도 들어갈 수 있습니다. 
주로 주체의 도메인 네임이 들어갑니다.
PolicyMappings 옵션 정책 정보를 다른 정책들과 연결 할 수 있는 정보를 제공합니다.
NameConstraints 옵션  
PolicyConstraints 옵션 인증서 경로의 제약 사항을 정합니다.
IssuerAltName 옵션 발급자의 다른 이름. 
여기서는 DN형식이 아니라 어떤 종류의 값이라도 들어 갈 수 있습니다. 
주로 발급자의 도메인 네임이 들어갑니다.
AuthorityKeyIdentifier 옵션 발급자의 키를 나타낼 수 있는 키의 이름을 정합니다.
SubjectKeyIdentifier 옵션 주체의 키를 나타낼 수 있는 키의 이름을 정합니다.
BasicConstraints 필수/옵션 제약 사항. 
주로 이 인증서가 다른 인증서를 발급 할 수 있는 권한이 있는지 없는지를 나타냅니다.
CRLDistributionPoints 옵션 이 인증서의 CRL을 얻을 수 있는 곳을 정합니다.
KeyUsage 옵션 인증서에 기입된 공개키가 사용되는 보안 서비스의 종류를 결정합니다. 보안 서비스의 종류는 서명, 부인방지, 전자 서명, 키교환 등이 있습니다.

 

위의 표의 항목 중에 주체의 정보와 발급자의 정보에 해당하는 항목이 있습니다. 이 항목에는 DN (distinguished name) 형식으로 주체와 발급자의 정보를 넣게 됩니다. DN의 항목들과 설명은 다음 표와 같습니다.

 

항목 설명 DN 항목
countryName 2자리의 국가를 나타내는 코드를 넣습니다. C KR
stateOrProvinceName 주 이름을 넣는데, 우리나라는 주가 없으므로 도나,시정도를 넣습니다. ST <st1:city w:st="on">SEOUL</st1:city>
 
localityName 시 이름을 넣으면 됩니다. 편한대로 구이름을 넣어도 됩니다. L SOCHO
 
organizationName 소속 기관명을 입력합니다. O SearchCast
organizationalUnitName 소속 부서명을 입력합니다. OU Web Dev
commonName 주체를 나타낼수 있는 이름을 입력합니다. CN NTT_Test_CA
emailAddress 이메일 주소를 입력합니다. emailAddress ntt@searchcast.net

 

위 표의 예를 사용해서 실제로 X.509 인증서에 들어가는 subject 항목에 대한 값을 구성하면 다음과 같습니다.

 

Subject: C=KR, ST=<st1:city w:st="on">SEOUL</st1:city>, L=SOCHO, O=SearchCast, OU=Web Dev, CN=NTT_Test_CA/emailAddress=ntt@searchcast.net

 

이런 형식으로 주체와 발급자의 정보를 인증서안에 표시하게 됩니다.

 

앞서 설명한 X.509 인증서의 항목에 대한 값들이 실제 인증서에 어떻게 들어가 있나 살펴보시기 바랍니다.

 

--------------------------------------------------------------------
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=KR, ST=<st1:city w:st="on">SEOUL</st1:city>, L=SOCHO, O=SearchCast, OU=Web Dev, CN=NTT_Test_CA/emailAddress=ntt@searchcast.net
        Validity
            Not Before: Jan 22 05:45:36 2003 GMT
            Not After : Jan 22 05:45:36 2004 GMT
        Subject: C=KR, ST=<st1:city w:st="on">SEOUL</st1:city>, O=TestCompany, OU=TestDep, CN=TestCert/emailAddress=test@testcompany.co.kr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c7:97:b3:f2:2b:b2:7f:b4:d4:ec:ce:a4:4d:aa:
                    c6:0c:08:ab:02:62:9a:ad:f6:c3:b5:b1:0a:fa:ca:
                    d1:a2:8f:e6:e7:76:04:ca:dc:da:cd:d9:ef:dc:cc:
                    f2:ba:d0:8c:e6:13:86:7c:36:b9:f8:86:10:4c:80:
                    3b:9f:93:a6:aa:6a:3c:18:a8:20:80:27:c9:24:e0:
                    b5:41:f5:14:12:07:4b:13:f6:bb:87:48:cf:ef:b4:
                    e6:e0:9c:52:aa:3b:f4:f0:f0:c0:94:06:98:9d:ba:
                    f7:6e:89:ad:48:fe:a7:9b:e2:6c:c3:b0:58:76:8e:
                    1c:b9:43:be:8b:3a:79:18:cb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
            CA:FALSE
            Netscape Comment:
            OpenSSL Generated Certificate by NTT
            X509v3 Subject Key Identifier:
            DF:F6:BC:5F:80:D9:C7:AB:58:FB:94:42:92:B0:26:1E:F0:59:C8:1C
            X509v3 Authority Key Identifier:
            DirName:/C=KR/ST=SEOUL/L=SOCHO/O=SearchCast/OU=Web Dev/CN=NTT_Test_C
A/emailAddress=ntt@searchcast.net
            serial:00
 
    Signature Algorithm: sha1WithRSAEncryption
        88:ff:26:1a:7f:a2:59:8d:19:31:fc:b8:cf:8b:b8:9a:8d:7f:
        db:82:45:51:f9:94:df:08:05:b2:7d:16:56:ed:7d:60:30:bf:
        e1:7c:27:bf:24:b2:f8:88:36:70:db:7a:4d:de:7c:55:82:7f:
        94:30:0a:82:d1:9d:ae:ae:48:a0:88:47:e2:f7:2e:88:bb:46:
        31:8a:2b:b0:ab:93:15:94:71:3d:88:90:12:85:01:51:39:87:
        66:8f:d1:7c:86:23:ed:d6:33:b3:d2:a0:82:7b:5b:e7:ac:a7:
        24:59:00:97:9d:06:f0:79:2f:d0:49:4c:a9:33:90:f6:b4:85:
        5b:dc
 -----END CERTIFICATE----------------------------------------------------------

 

3. X.509 인증서가 저장되는 여러 가지 형식들


앞에서 X.509 인증서의 실제 모습을 보았습니다. 하지만 사실 X.509 인증서는 앞에서 본 모습대로 저장되는 것은 아닙니다.

 

앞에서 본 인증서의 모습은 사람이 보기 편하게 X.509 인증서의 내용을 재 구성한 것입니다. 하지만 실제의 인증서는 위의 예에서처럼 사람이 보기 편하게 텍스트 형식으로 저장되지 않습니다.

 

X.509 표준의 인증서 형식은 ASN.1 (Abstract Syntax Notation One)이라는  명명 규칙을 따릅니다. 그런데 이 ASN.1 표기 방식은 매우 복잡합니다. ASN.1  C 언어 같은 프로그래밍 언어와 비슷합니다. 많은 변수 형식이 있고, 많은 구조체 데이터 저장 형식이 있습니다. 인증서의 각 항목은 OID라는 일련번호로 나타낼 수 있으며 항목의 데이터는 ASN.1 타입의 데이터로 표현됩니다..

 

이러한 이유로 ASN.1 형식에 대한 자세한 설명은 하지 않겠습니다. X.509 인증서의 각 항목의 내용은 ASN.1의 형식에 맞게 저장된다고만 알아 두시면 되겠습니다.

 

대신 실제로 우리가 앞으로 인증서를 사용할 때 자주 보는 파일 저장 형식에 관해서 설명하겠습니다.그것은 PEM 형식과 DER 형식입니다.

 

ASN.1 형식으로 되어 있는 X.509 인증서의 내용을 파일로 저장할 때 주로 두 가지 종류의 형식으로 저장합니다. 

첫 번째는 X.509 인증서 내용을 base64 encoding으로 인코딩하여 저장하는 것입니다. 

두 번째는 X.509 인증서 내용을 바이너리 형태로 저장하는 것입니다. 

첫 번째 형식을 PEM, 두 번째 형식을 DER이라고 합니다.

 

원래 PEM은 암호화된 메일을 나타내는 확장자입니다. DER PEM의 차이는 위에서 설명했던 ASN.1 형식으로 되어 있는 X.509 인증서 내용을 base64 encoding으로 인코딩하여 저장하는 것 과 X.509 인증서 내용을 바이너리 형태로 저장 하는 것의 차이입니다..

그럼 실제로 어떤 모습으로 저장되는지 보겠습니다.

 

 

 

 

PEM 형식은 영문자와 숫자, 그리고 몇 개의 기호로만 저장되기 때문에 사람이 보기에 편하고 다루기 쉽다는 장점이 있습니다. 따라서 앞으로 우리가 인증서나 공개키 같은 내용을 파일로 저장할 때에는 주로 PEM형식으로 저장하게 될 것입니다.

 

 

Reference

1. https://blog.naver.com/nttkak/20130245553

반응형
반응형

이번 포스팅은 대칭키 암호화에 대하여 좀 더 알아보도록 하겠습니다.

 

1.  패딩 (Padding)


패딩에 대하여 알아보기에 앞서 PKCS#5과 PKCS#7은 패딩(Padding)에 관련된 표준이라는 사실을 알아두고 시작하는 것이 좋습니다.

 

"Padding"은 데이터를 특정 크기로 맞추기 위해 그 크기보다 부족한 부분을 뭔가로 채워넣는 작업을 가리키는 일반 용어입니다.

 

PKCS#5는 Password 기반 암호화 표준(Password-based Encryption Standard)라고 명명되어 있고, 현대 공인인증 방식은 이 PKCS#5 표준에 따라 개인 Password를 그 근간으로 하고 있습니다. 즉, Password로 표현할 수 있는 Key를 사용하는 암호화 표준이라는 것입니다.

 

Password란 우리가 보통 알고 있는 영문, 숫자, 특수문자를 포함해서 키보드 상에서 [input type="password"] 형식으로 쓸 수 있는 모든 문자를 말합니다. 넓은 의미로는 1 바이트로 표현 가능한 모든 문자, 즉 ASCII 코드로는 0~255 (이진수로 00000000부터 11111111까지)에 해당됩니다. (그러나 앞 부분의 컨트롤 문자와 뒷부분의 확장 문자 코드를 빼면 32~126 사이의 문자 코드만 해당된다.) 이걸 이진수로 표현하면 최대 8자리의 숫자로 표현되기 때문에 8진 문자열(Octet string) 이라고도 표현합니다.

 

즉, "1 바이트 = 1 octet" 이 되는 것입니다. 

이 8진 문자열을 사용하는 것에 대한 표준이 바로 PKCS#5입니다.

 

[참조] PKCS#5 - Password-based Encryption Standard (rfc 2898 문서)

 

위 참조 문서의 6.1.1 부분에 그 핵심 내용이 들어있습니다.

 

바로, 패딩(padding)입니다. 8바이트 기준 패딩입니다. 이것이 PKCS#5의 핵심입니다. 

즉, 평문의 길이가 8바이트의 배수를 기준으로 모자라는 수 만큼의 숫자를 채워서 8바이트의 배수로 길이를 맞추는 작업에 대한 것입니다.

 

여기서 주의해야 할 점은 이 Padding은 반드시 발생야 한다는 것을 잊어버리고 8바이트보다 작은 경우에만 적용하는 실수를 하는 경우가 있습니다.  8바이트의 배수인 경우에도 Padding은 무조건 해야 합니

 

위 문서의 6.1.1 부분에도 명시되어 있지만 한글로 더 잘 설명된 내용이 아래 링크에 있습니다.

 

[참고] http://manual-archive.blogspot.kr/2012/03/pkcs-padding-method_19.html

 

예제까지 포함하여 설명된 내용이 아래 링크에 있습니다.

 

[참고] http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.csfb400/pkcspad.htm

 

 

이 PKCS#5는 DES, TripleDES 등 8바이트 블럭 암호화 기반 기존 알고리즘들에 잘 적용되었던 표준입니다. 그런데 이후 128비트(16바이트) 이상의 블럭 암호화 알고리즘들이 속속 발표되면서 이 패딩 방식에 대한 표준도 확장이 필요하게 되었습니다. 그래서 나온 것이 PKCS#7 입니다.

 

[참조] PKCS#7 - Cryptographic Message Syntax Standard (rfc 2315)

 

위 참조 문서의 핵심 내용은 10.3 부분에 있습니다.

 

즉, 암호화 블럭 크기가 k바이트인 경우 k바이트보다 작거나 같은 경우 패딩을 적용하라는 것입니다. 

AES의 경우 16바이트 암호화 블럭이 사용되는 알고리즘이므로 16바이트 패딩이 적용됩니다.

 

 

2. 모드(Mode) / IV(초기화 벡터; Initialization Vector)


Mode는 간단히 이야기면, 블럭 암호화 순서 및 규칙에 대한 표준입니다.

 

Mode에 대한 설명은 아래 링크에 중요한 내용이 다 나와 있으니 참조하시면 됩니다.

 

[참조] http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

 

위 링크에 자세히 나와 있지만 일반적으로 가장 많이 쓰이는 CBC(Cipher-Block Chaining) 모드에 대해 간단히 반복 설명하자면, 최초 평문 1블럭과 IV(초기화 벡터)를 XOR 연산한 다음 암호화하고, 다음 평문 1블럭은 앞에서 암호화된 결과 블럭과 XOR 연산하여 다시 암호화합니다.

 

위의 과정을 끝까지 반복하는 것이 CBC 모드입니다.

(평문 마지막 블럭은 패딩된 블럭입니다.)

 

CBC 모드는 IV를 사용하지 않고, 즉 XOR 연산 없이 각 블럭을 암호화만 하는 모드인 ECB 모드에 비해 훨씬 더 강력한 암호화 기법입니다.

 

Reference

https://mm4mm.tistory.com/m/27

반응형

+ Recent posts