J2H's Blog: 1월 2016

2016년 1월 10일 일요일

PKCS#12

요즘 보안관련된 문서를 접하다보니 익숙한 것 같지만 또 잘 모르는 그런 용어들이 많이 나타납니다.

오늘은 PKCS#12 에 관해서 정리해보겠습니다.

우선, PKCS 자체의 의미는 공개 키 암호 표준(Public-Key Cryptography Standard) 를 의미하고, 공개 키 암호에 대한 사용 방식을 정의한 프로토콜입니다.

이중 #12 의 경우 "Personal Information Exchange Syntax Standard" 라는 이름을 가지고 있네요.

wikipedia를 참고하면, ( https://en.wikipedia.org/wiki/PKCS_12 )

In cryptography, PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with itsX.509 certificate or to bundle all the members of a chain of trust.^[1]

라고 합니다.

많은 경우에 흔히 말하는 인증서와 키가 합쳐진 형태로 이해하기도 합니다.

PKCS#12 형태의 파일을 만드는 절차에 인증서와 키가 필요합니다.

http://www-01.ibm.com/support/knowledgecenter/SSWHYP_4.0.0/com.ibm.apimgmt.cmc.doc/task_apionprem_generate_pkcs_certificate.html?lang=ko 를 참고로 설명하겠습니다.

PKCS#12 파일을 생성하기 위해서는

필요한 것: 개인키(ex> key.pem), 인증 기관에서 서명한 인증서(ex> certificate.pem), CA기관의 하나 이상의 인증서(중간 CA인증서라고도 함)

프로시저

중간 CA 인증서가 있는 경우 이를 pem파일과 연결시켜 caChain을 빌드

cat ca1.pem ca2.pem ca3.pem > caChain.pem

개인키, 서명된 인증서, 1단계에서 작성한 CA파일을 포함하는 PKCS#12 파일

openssl pkcs12 -inkey key.pem -in certificate.pem -export -out certificate.p12 -CAfile caChain.pem -chain

실제 자세한 내용은 복잡하다고 하고, 이정도만 우선 알아도 될 것 같습니다.

2016년 1월 6일 수요일

ELF (Executable and Linkable Format)

자주 접해온 키워드인 ELF. 이참에 뭔지 좀 자세하게 알아봤습니다.

다음을 참고하여 정리합니다.

https://ko.wikipedia.org/wiki/ELF_%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D
http://egloos.zum.com/recipes/v/5010841
http://devanix.tistory.com/182

ELF(Executable and Linkable Format)는 실행 파일, 목적 파일, 공유 라이브러리 그리고 코어 덤프를 위한 표준 파일 형식입니다.

하나의 ELf 헤더와 파일 데이터로 이루어지며 다음을 포함합니다.

0개 또는 그 이상의 세그먼트들을 정의하는 프로그램 헤더 테이블
0개 또는 그 이상의 섹션들을 정의하는 섹션 헤더 테이블
프로그램 헤더 테이블 또는 섹션 헤더 테이블의 엔트리들에 의해 참조되는 데이터

여기서 섹션과 세그먼트는 다음을 포함합니다.

섹션: 링킹과 재배치에 필요한 중요 정보를 포함
세그먼트: 파일의 런타임 실행에 필요한 정보를 포함

전체 파일의 어떤 바이트도 최대 1개의 섹션에 의해 소유되며, 섹션에 소유되지 않는 바이트도 존재할 수 있습니다.

위에서 기술한 프로그램 헤더 테이블과 섹션 헤더 테이블에 따라 ELf 파일은 두가지 관점을 가집니다. 프로그램 헤더는 런타임시 사용되는 세그멘트를, 섹션 헤더는 바이너리 섹션들의 집합을 나열합니다.

실제 헤더의 구조는 위키를 참고하세요.

이중 ELF header는 다음과 같은 형태이며 일부만 기술합니다.

(Offset, 길이, 의미 순서입니다)

0x00, 4, "0x7F 0x45 0x4C 0x45" 라는 매직넘버로 기술됩니다. ".ELF" 라는 의미 입니다.
0x04, 1, 비트 정보로, 64bit or 32bit 인지를 알려줍니다.
0x05, 1 , Big/Little Endian 구별을 해줍니다.

.text와 .rodata는

.text: 실제 코드들이 들어갑니다. push, mov 등의 명령이 있습니다.
.rodata: Read-only Data segment로 읽기만 가능한 데이터 영역입니다. static이나 const 같은 값이 들어갑니다.

헤더 이하의 해석은 Link 전(.o)과 후의 관점에 따라 아래와 같습니다.

자세한 설명은 http://egloos.zum.com/recipes/v/5010841 를 참고하면 되고, 대략적으로 저런 모양이구나 하는 것을 확실하게 알아두면 좋을 것 같습니다.

2016년 1월 5일 화요일

ASN.1 (Abstract Syntax Notation One)

문서를 뒤적이다가 알듯 말듯한 형태로 적혀있는 코드가 있었습니다. 알아보니 ANS.1 Type에 대한 이해가 필요하기에 여기저기서 습득한 자료를 바탕으로 정리해봅니다.

참고한 사이트는 다음과 같습니다.
http://girlsy7.tistory.com/129
https://support.microsoft.com/ko-kr/kb/252648
http://fly32.net/446

ITU-T에서 정의한 네트워크상의 데이터 교환을 정의한 프로토콜로 데이터 구조를 기술하는데 사용되는 표현 기법을 의미합니다.
특정 장치, 데이터 표현방식, 언어, 플랫폼에 종속되지 않습니다.
인코딩/디코딩 규칙까지 규정합니다.

좀 더 구체적으로 다음을 정의합니다.

"형식" 정의
"모듈" 정의 및 표시 방법
INTEGER 정의
BOOLEAN 정의
"구조체 형식" 정의
특정 키워드(예: BEGIN, END, IMPORT, EXPORT, EXTERNAL) 의 의미
적절히 인코딩할 수 있도록 형식을 "태그"하는 방법

이를 이용하여 서로 다른 환경을 가진 시스템끼리 통신하기에 적합합니다.

이 부분에 대해서 좀 더 설명을 하자면, 동일한 Data라고 해도 Window와 Sun Application에서의 해석은 다를 수 있습니다.
32 bit integer를 기준으로 '100'이라는 값은 Little Endian 으로 [64 00 00 00] 으로 인식되지만, Big Endian으로는 [00 00 00 64] 로 인식됩니다.
때문에 어떻게 인코딩을 해야 하는지도 확실히 정해줘야하는데 이것을 정의한 것이라고 생각하면 됩니다. (기술한 것과 같이 인코딩 이외에도 정의하는게 많습니다)

Abstract Syntax와 Transfer Syntax의 개념에 대한 이해가 필요한데,
Abstract Syntax는 C에서의 Type으로 이해하면 쉽고, Transfer Syntax는 위에 기술한 예제와 같이 어떻게 인코딩을 하는지를 기술하는 것으로 이해하면 됩니다. 이런 Transfer Syntax에는 BER(Basic Encoding Rules), PER(Packing Ending Rules), CER(Canonical Encoding Rules)등이 있습니다.
ITU-T 권고안 X.209, 부록 I의 예제를 바탕으로 BER과 ASN.1을 비교하겠습니다.

다음의 '직원 데이터 레코드'가 있습니다.

   Name:             John P Smith
   Date of Birth:    17 July 1959
   (other data)

이를 ASN.1 설명으로 기술하면 이렇습니다.

   PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET {
       Name,
       title [0]       VisibleString,
       dateOfBirth [1]          Date,
       (other types defined)          }

   Name ::= [APPLICATION 1] IMPLICIT SEQUENCE {
       givenName       VisibleString,
       initial         VisibleString, 
       familyName      VisibleString  }

응용 프로그램은 직원 데이터를 직원 레코드 구조(ASN.1 데이터 형식)에 매핑한 다음 ASN.1 데이터에 BER(Basic Encoding Rules)를 적용합니다. 이름이 ASCII로 변환되는 것을 제외하면 다음과 같이 표시됩니다.

Personnel
  Record     Length   Contents
  60         8185
                      Name     Length  Contents
                      61       10
                                       VisibleString  Length  Contents
                                       1A             04      "John"
                                       VisibleString  Length  Contents
                                       1A             01      "P"
                                       VisibleString  Length  Contents
                                       1A             05      "Smith"

                       DateofBirth     Length  Contents
                       A0              0A
                                               Date    Length  Contents
                                               43      08      "19590717"

모든 것이 표현되고 완료되면 실제 전송되는 데이터 부분은 다음과 같습니다.

60 81 85 61 10 1A 04 ....
....  0A 43 08 19 59 07 17