어제, 오늘 그리고 내일

이번 포스팅은 대칭키 암복호화 중 가장 많이 사용하는 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-라이브러리-포함 [지똥이]

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

전자 서명 ( 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

이번 포스팅은 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 항목은 중요한 것만 설명했습니다..

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

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

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

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

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