어제, 오늘 그리고 내일

#. NPKI (National Public Key Infrastructure) : 국가 공개키 기반 구조

#. CA (Certificate Authority) 

- 인증 기관 

- 5대 인증 기관(코스콤, 한국전자인증, 한국정보인증, 금융결제원, 한국무역정보통신)

[출처] 한국전자인증(https://www.crosscert.com/solution/03_1_02.jsp)

#. RA (Registration Authority) 

- 등록 기관 

- 공인인증서의 접수 및 등록 등의 일을 수행

- 은행, 증권회사, 인증기관(한국전자인증, 한국정보인증)

- 사용자 인증서 관리(등록, 재등록,정보 수정, 정보 삭제, 정보 조회)

- 공인인증서 관리(효력정지, 효력회복, 폐지)

#. PKI (Public Key Infrastructure)

# OCSP (Online Certificate Status Protocol)

- 온라인 인증서 상태조회 프로토콜

- CRL을 통한 검증 메커니즘

- 사용자의 실수 또는 고의로 폐기된 인증서가 사용되는 것을 방지하기 위해 CA를 통해 발급된 인증서의 유효성(폐기) 여부를 실시간 검증하여 폐지 및 정지된 인증서에 대한 정보를 실시간으로 제공하는 서비스

- 인증서가 유효한지 1분마다 체크

[출처] 한국전자인증(https://www.crosscert.com/solution/03_1_05.jsp)

# CRL (Certificate Revocation List)

- 인증서 폐기목록 리스트

- 인증서가 유효한지 12~48시간 마다 체크

# LDAP

- 조직이나 개체 그리고 인터넷이나 기업 내의 인트라넷 등 네트워크 상에 있는 파일이나 장치들과 같은 자원 등의 위치를 찾을 수 있게 해주는 프로토콜

#. 인증의 3요소 (암기시 무.부.인)

- 무결성, 부인방지, 인증

이번 포스팅은 대칭키 암복호화 중 가장 많이 사용하는 AES 알고리즘 암복호화에 대하여 알아보도록 하겠습니다.

1. 암호화

public byte[] Encrypt(String text, String key) throws Exception {

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

byte[] keyBytes= new byte[16];

byte[] b= key.getBytes("UTF-8");

int len= b.length;

if (len > keyBytes.length) len = keyBytes.length;

System.arraycopy(b, 0, keyBytes, 0, len);

SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

IvParameterSpec ivSpec = new IvParameterSpec(keyBytes);

cipher.init(Cipher.ENCRYPT_MODE,keySpec,ivSpec);

byte[] results = cipher.doFinal(text.getBytes("UTF-8"))

return result;

}

2. 복호화

public String Decrypt(String text, String key) throws Exception {

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

byte[] keyBytes= new byte[16];

byte[] b= key.getBytes("UTF-8");

int len= b.length;

if (len > keyBytes.length) len = keyBytes.length;

System.arraycopy(b, 0, keyBytes, 0, len);

SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

IvParameterSpec ivSpec = new IvParameterSpec(keyBytes);

byte [] results =cipher.init(Cipher.DECRYPT_MODE,keySpec,ivSpec);

        return results;

 }              

이번 포스팅은 Proguard 사용 시 생성되는 파일 목록과 내용에 대하여 알아보도록 하겠습니다.

기본적으로 프로젝트 생성을 하면 아래와 같은 파일이 생성이 됩니다.

- proguard-project.txt  = Proguard 설정 파일

- project.properties = 프로젝트 설정 파일

project.properties 프로젝트 세팅 파일에  프로가드 사용 여부 주석을 해제합니다.

#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt

해제 방법은 #을 삭제

Proguard를 실행하여 프로젝트를 빌드를 하게 되면 아래와 같은 파일 목록들이 생성이 됩니다.

해당 파일과 그 역할에 대하여 알아보도록 하겠습니다.

    ▶ dump.txt : 어플리케이션에서 사용중인 클래스들의 내부 구조에 대한 대략적인 정보

    ▶ mapping.txt : 난독화 과정에서 기존 Class 혹은 method가 어떤 난독화된 새로운 이름으로 매핑되었는지 그 목록. 난독화 된 어플리케이션에 발생하는 Log나, StackTrace 등 프로젝트 론칭하여 빌드 시 오류 및 디버깅 시 분석하기 위해서 꼭 챙겨 두셔야 합니다.

    ▶ seeds.txt : 난독화 되지 않은 클래스와 멤버들의 목록입니다.

    ▶ usage.txt : 사용되지 않기 때문에, apk 파일에서 제거된 코드들의 목록입니다. 혹시 제거되서는 안 되는 method나 Class가 제거되었는지 확인할 필요가 있습니다.

  


이제 Proguard 설정 파일인 proguard-project.txt 파일의 내용들에 대하여 알아보도록 하겠습니다.

-libraryjars libs/android-support-v4.jar // 라이브러리 추가

-libraryjars libs/json-simple-1.1.1 .jar

// org.apache.http. 하위 클래스중 public method 만 난독화 하지 않음

난독화 후 어플리케이션 실행하여 돌려보면서 난독화 범위를 적용해야 합니다.

Reference

1. https://leejiheg.tistory.com/entry/Android-Proguard-설정법-libs-라이브러리-포함 [지똥이]

이번 포스팅은 바이너리 데이터 통신 시 많이 사용하는 Base64에 대하여 알아보도록 하겠습니다.

Base64의 개요

Base64란 Binary Data를 Text로 바꾸는 Encoding(binary-to-text encoding schemes)의 하나로써 Binary Data를 오직 공통 ASCII 영역의 문자로 Character Set에 영향을 받지 않는 이루어진 문자열로 바꾸는 Encoding입니다.

핵심은 "Base64 Encoding은 Binary Data를 Text로 변경하는 Encoding이다." 입니다.

Base64를 글자 그대로 직역하면 컴퓨터에게는 조금 특별한 64진법이라는 뜻입니다. 특별한 이유는 64가 2의 제곱수(64=2^6) 이며, 2의 제곱수에 기반한 진법 중 화면에 표시할 수 있는 ASCII 문자들로 나타낼 수 있는 가장 큰 진법이기 때문입니다. (ASCII에는 제어문자가 다수 포함되어 있기 때문에 화면에 표시되는 ASCII 문자는 128개가 되지 않습니다.)

Base64 변환 과정

변환하는 방식을 간략하게 설명하면 Binary Data를 6 bit씩 자른 뒤 6 bit에 해당하는 문자를 위의 Base64 색인표에서 찾아 치환합니다. (실제로는 Padding을 더해주는 과정이 추가됩니다.)

1. 문자열을 ASCII로 치환

   (M -> 77)

2. 치환한 ASCII 값을 binary 데이터로 치환

  (77 -> 01001101) (01001101는 십진수로 77)

3. binary 데이터 값을 이은 후 6bit씩 자른 후 Base64 색인표에 나와 있는 데이터로 치환

  (01001101 -> 010011 01.....(다음 데이터와 이어짐)

  (010011 -> T (19)

아래 그림을 보시면 자세히 설명이 되어 있습니다.

Reference

1. https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464

2. https://beankhan.tistory.com/28

이번 포스팅은 전자서명에 대하여 알아보도록 하겠습니다.

전자 서명 ( Digital Signature )

전자서명은 내가 얻은 메시지가 어떤 사람이 작성한 것인지를 확인하는 인증 작업입니다. 즉, 메시지와 메시지를 생성한 사람과의 인증입니다. 다시 말해 계약서에 이름을 적고 도장을 찍거나 사인을 함으로써 그 사람이 계약서를 작성한 것이 맞다는 것을 인증하는 것과 같습니다.  

 

 

계약서에 도장을 찍거나 사인을 해서 그 사람이 계약서의 내용을 작성했다는 것을 인증하는 것처럼 전자 데이터로 되어있는 메시지에도 도장 또는 사인처럼 전자적인 사인을 할 수 있습니다. 이것을 전자 서명 (Digital Signature) 이라고 합니다. 전자 서명은 계약서에 쓰여진 사인과 같은 역할을 하게 됩니다.

 

 

 

  

전자 서명 알고리즘

---

전자 서명을 가능하게 한 것은 공개키 암호화 알고리즘입니다. 이 공개키 암호화를 사용하여 할 수 있는 것들은 다음의 두 가지였습니다.

 

▶ 메시지를 암호화하고, 복호화 할 수 있는 기밀성을 제공

▶ 비밀키를 안전하게 교환 

 

다시 말해, 공개키로 메시지를 암호화하여 전달하고, 받은 암호문을 개인키로 복호화 함으로써 기밀성을 제공 할 수 있었습니다. 그리고 공개키로 비밀키를 암호화해서 전달한 후, 개인키로 복호화하는 방법으로 비밀키를 안전하게 교환 할 수 있었습니다.

 

이번에는 공개키로 할 수 있는 또 다른 중요한 기능인 전자 서명에 대해 알아보겠습니다.

 메시지에 전자 서명을 하고, 이 전자 서명을 통해 전자 인증을 할 수 있는 기능을 제공

위에서 전자 인증이라는 것은 지금까지 설명한 메시지와 메시지를 작성한 사람과의 인증입니다.

 

전자 서명은 앞에서도 설명하였듯이, 계약서의 도장이나 사인과 같은 역할을 합니다. 단지 물리적인 종이가 아니라 전자적인 데이터에 찍히는 도장 혹은 사인입니다. 그럼, 전자 서명은 어떻게 만들까요?

 

전자 서명을 만드는 열쇠는 공개키 암호화 알고리즘입니다. 다음 그림을 보시길 바랍니다.

  

 

 

앨리스는 메시지를 자신의 개인키로 암호화하여 암호문을 생성합니다. 앨리스에게는 원본 메시지와 자신의 개인키로 암호화 한 암호문이 있습니다. 이 두 개를 밥에게 보냅니다.

  

 

 

밥은 앨리스에게 받은 메시지와 메시지가 암호화된 암호문을 받습니다. 그리고 밥은 쉽게 구할 수 있는 앨리스의 공개키로 암호문을 복호화 합니다. 암호문은 원본 메시지를 암호화 한 것이므로, 암호문을 복호화 하면 원본 메시지를 얻을 수 있을 것입니다. 밥은 앨리스에게 받은 원본 메시지와 자신이 복호화 해서 만든 메시지를 비교합니다. 만약 이 두 개가 같다면, 메시지는 엘리스가 보낸 것이 확실하다고 생각 할 수 있습니다.

 

 

 

 

앞에서도 설명하였듯이 앨리스의 개인키로 암호화 한 메시지를 복호화 할 수 있는 것은 오직 앨리스의 공개키 뿐입니다.  다른 사람의 공개키로 복호화를 했다면, 원래 암호화 한 메시지와는 다른 엉뚱한 값이 생성될 것입니다. 따라서 앨리스가 보낸 암호화 하기 전의 메시지와, 앨리스가 같이 보낸 암호문을 앨리스의 공개키로 복호화하여 생성한 메시지가 같다면, 메시지는 앨리스가 보낸 것이라고 확신 할 수 있습니다.

 

앨리스가 원본 메시지와 함께 보낸 암호문이 바로 전자 서명입니다.

 

하지만 실제의 전자 서명 알고리즘에서는 원본 메시지를 그대로 개인키로 암호화 하지 않고, 메시지 압축 함수로 압축 한 후에 그 값을 개인키로 암호화합니다. 이것이 보통의 전자 서명 입니다. 압축해서 암호화하는 이유는 메시지의 크기가 너무 클 수 있기 때문에 암호화와 복호화에 걸리는 시간이 너무 길어질 수 있기 때문입니다. 다음에 설명할 RSA 전자 서명 알고리즘과 DSA 전자 서명 알고리즘에서 메시지 압축 함수를 전자 서명을 위해 사용 하는 것을 볼 수 있을 것입니다.

 

전자 서명의 3요소 (무. 부. 인)

---

무결성

전자 서명을 통해 메시지가 변경되지 않았다는 것을 알 수 있습니다. 원본 메시지가 변경되었다면, 메시지와 메시지의 전자 서명 값이 서로 일치되지 않을 것입니다.

 

인증

전자 서명을 함으로써 메시지를 보낸 사람의 인증을 할 수 있다는 것은 계속 설명 했던 내용입니다.

 

부인 방지

앨리스의 전자 서명은 오직 앨리스의 개인키로만 만들 수 있습니다. 따라서, 앨리스가 나중에 자신이 보낸 메시지가 아니라고 부인해도 상관 없습니다. 앨리스의 전자 서명은 오직 앨리스만이 만들 수 있기 때문입니다.

 

그럼 이제 전자 서명 알고리즘으로 가장 많이 사용 되는 RSA 전자 서명 알고리즘과, DSA 전자 서명 알고리즘을 살펴 보겠습니다.

 

RSA 전자 서명 알고리즘

---

RSA 전자 서명 알고리즘은 앞에서 설명한 앨리스와 밥의 전자 서명 교환, 그리고 인증 과정과 같습니다. 다만 다른 것은 메시지를 원본 그대로 개인키로 암호화 하여 전자 서명 값을 만들지 않고, 원본 메시지를 메시지 압축 함수로 압축 한 후, 그 압축 해시값을 암호화 하여 전자 서명 값을 만듭니다.

 

인증 시에는 받은 메시지를 메시지 압축 함수로 압축하고, 받은 전자 서명 값을 복호화 합니다. 그리고 이 둘의 값을 비교 하여 인증을 하게 됩니다. 만약 같다면 인증 할 수 있습니다.

 

다음 그림을 보면 이해가 쉽게 되실 것입니다.

 

 

 

 

DSA 전자 서명 알고리즘

---

DSA 는 (Digital Standard Algorithm) 의 약자입니다. 이 DSA 알고리즘도 RSA 전자 서명 알고리즘처럼 많이 쓰이는 전자 서명 인증 알고리즘 입니다.

 

DSA 알고리즘도 메시지를 압축하고, 그 압축 값을 개인키로 암호화 해서 전자 서명 값을 만드는 것은 RSA와 같습니다. 그러나 인증 방법이 약간 다릅니다. 위에서 설명한 RSA 전자 서명 알고리즘은 메시지를 인증 할 때 메시지를 압축 해시값으로 만들고, 복호화한 전자 서명 값과 비교하여 인증을 했지만, DSA 알고리즘은 검증 결과가 바로 예 또는 아니오로 나오게 되어 있습니다. 이 것은 DSA가 전자 서명/인증만을 위한 알고리즘 이기 때문입니다.

 

 

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

공개키 인증서 ( Public Key Certificate )

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

우리 주위의 인증서

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

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

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

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

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

운전면허증

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

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

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

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

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

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

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

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

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

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

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

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

신용카드

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

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

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

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

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

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

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

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

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

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

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

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

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

인증서 안의 항목들의 역할

1) 발급자

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

2) 소유자

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

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

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

4) 유효기간

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

5) 일련 번호

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

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

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

7) 발급자의 서명

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

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

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

공개키 인증서

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

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

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

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

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

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

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

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

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

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

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

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

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

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

실제로 컴퓨터 환경에서 사용되는 인증서의 형식은 물론 위의 형식과는 다릅니다. 하지만  항목들과 그 항목의 의미는 거의 같다고 할 수 있습니다. 실제로 현실 세계에서 사용되는 인증서의 각 항목들의 표기 방법이나 구성은 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