어제, 오늘 그리고 내일

이번 포스팅은 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

이번 포스팅은 Android Build 오류에 대하여 알아보도록 하겠습니다.

Keystore의 'ABC' 라는 alias를 가진 Key를 그대로 두고 그 키를 새로운 'DEF' 라는 alias에 Key를 저장을 하려고 하였습니다.

< Error >

< Solution >

1. Keystore의 setEntry 설명 문서를 살펴보니 동일한 Key를 새로 저장할 수 없고 만약 이미 등록된 alias가 있다면 동일한 alias로 조회시 새로운 Key로 대체가 된다고 설명이 되어 있었습니다.

2. 즉, Keystore에 동일한 Key를 그대로 두고 다른 alias로 중복 저장을 할 수가 원칙적으로는 없습니다.

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

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