[Kisa] 암호의 이해와 키 관리 실무 - 3일차 PKI 관련 표준 - PKCS

PKI 관련 표준

CLR 

서버가 받은 인증서의 'CLR 배포 지점' 항목에서 LDAP URL(ldap://) 을 추출해
LDAP DB에 직접 쿼리.
CA에서는 LDAP DB를 항상 갱신함.
폐기된 인증서라도 만료일이 지나면 CLR목록에서 제외.

OCSP

실시간 인증서 상태 검증 프로토콜 (RFC 2560)

• 인증서 폐기 후, 그 즉시 폐기 여부 조회 가능
• 하나의 요청 트랜젝션에 여러 인증서의 상태 요구 가능
• 통신에 대한 무결성을 보증 받을 수 있음
• 인가된 사용자에게만 OCSP 서비스를 제공할 수 있음.
• 프로토콜 자체 보안 기능(Replay Attack)을 제공

서버가 받은 인증서의 'Authority Info Access' 항목에서 OCSP URL을 추출해 OCSP 서버에 쿼리.

OCSP 서버가 LDAP 에 직접 폐기 여부를 조회하고, 조회 결과를 서버에 보내준다.

CA에서는 LDAP DB를 항상 갱신한다.

타기관 LDAP DB와 동기화 된다.

OCSP 서버가 대신하는거 말고 차이가 없어 보이는데...

REPLAY Attack 을 막기 위해 Nonce 를 랜덤하게 생성해서 보낸다. 

암호화 통신을 안한다면 Nonce 가 의미가 있는건지?,

CMP

• 클라이언트에 인증서에 대한 실시간 관리(발급/갱신/폐기) 가능
• CA간 상호인증 등 온라인 서비스 구현 가능
• 통신에 대한 무결성 보증 가능
• 통신 상대방 인증 가능
• 프로토콜 자체 보안 기능 제공

사용자가 인증서 발급 신청을 하면, RA (은행 등) 에서 CA에 발급신청을 하고, 

CA에서는 RA로 인가 코드를 전송한다. 사용자는 이후 공개키 개인키를 생성하고 

RA로부터 전달 받은 인가 코드로 요청 자체를 HMAC 돌려서 CA에 보낸다.

이후 CA는 인증서를 발급 하고, LDAP 에 갱신한다.

결국 CMP 나 PKCS #10 이나 인증서 발급에는 다음과 같은 정보가 필요하다.

CRMF (사용자 식별 정보, 공개키, PoP(Proof of Possession))

POP란 서버에서 보낸 Random 값을 클라이언트의 개인키로 사인한 값이다.

CMP 인증서 발급시 패킷

CMP 인증서 갱신시 패킷
kur 에는 공개키, 개인키 Random 값을 서버의 공개키로 암호화, POP(signature)
+ extraCerts 안에 기존 인증서를 보냄.

발급(ip)과 갱신(kup)시 차이는?

PKCS

PKCS# 1 RSA Standard(PKCS­2/PKCS­4포함) 1.5 1993. 11 

PKCS# 3 Diffie­Hellman Key­Agreement Standard 1993. 11 

PKCS# 5 Password­Based Encryption Standard 1.5 1993. 

PKCS# 6 Extended­Certificate Syntax Standard 1.5 1993. 11

PKCS# 7 Cryptographic Message Syntax Standard 1.5 1993. 11

PKCS# 8 Private­Key Information Syntax Standard 1.2 1993. 11

PKCS# 9 Attribute Types 1.1 1993. 11

PKCS#10 Certification Request Syntax 1.0 1993. 11

PKCS#11 Cryptographic Token Interface Standard 2.01 12

PKCS#12 Personal Information Exchange Syntax Standard 1.0(Draft) 1997. 

PKCS#13 Elliptic Curve Cryptography Standard Project 진행중

PKCS#14 Generator Standard Project 진행중 

PKCS #1 : RSA Cryptography Standard

RSA 암호화/서명 방법과 공개키/개인키에 대한 ASN.1 표기법이 설명되어 있음.

• RSA Public Key /Private Key : ASN.1 표기법 설명
• 데이터 변환 방법 설명 : Integer를 OCTET String 으로 변환하는 방법 설명
• RSAEP/RSADEP : 수하적인 공개키 암호화 스킴 설명
• RSAES-PKCS1-V1_5 : 단순한 패딩 기법을 활용한 RSA 암호화 스킴 설명
• RSASSA-PKCS1-V1_5 : 단순한 패딩 기법을 활용한 RSA 전자서명 스킴 설명
• RSASP1/RSADVP1 : 수학적인 전자서명 스킴 설명
• RSAES-OAEP : RSA 에 대한 공격에 안전한 암호화 스킴 설명(확률적 암호화)
• RSASSA-PSS : RSA 에 대한 공격에 안전한 전자서명 스킴 설명

c = m^e mod n 인데 message가 홀수라면 결과가 홀수가 나오게 된다.

즉, cipher 만 봐도 message가 홀수인지 짝수인지 알게 된다.

그러므로 Padding 과 Encoding 수행.

OAEP 에서 파라미터에 MGF 알고리즘 등이 들어가므로 잘 확인해봐야한다.

PKCS #5 : Password Based Encryption

• PBKDF1/PBKDF2 : 패스워드를 통해 대칭키에서 사용가능한 key와 IV를 추출

 - SALT, ITERATION COUNT( 해시 횟수. 표준은 1024~2048인데 지금은 10만번해야...)

• PBES1/PBES2 : PBKDF1,2 와 대칭키 암호 알고리즘 결합
• PBMAC1 : 메시지 무결성 확인을 위한 MAC 값 생성 프로세스 설명

PKCS #7 : Cryptographic Message Syntax Standard

다양한 암호메시지를 표현하는 표준 (RFC2630)

• Data : 일반 OCTET_STRING 데이터 타입
• Enveloped-Data : 전자봉투 데이터 타입(키 교환정보+암호화된 메시지)
• Signed-Data : 전자서명 데이터 타입 - 다자간 서명을 지원 함
• Signed-and-Enveloped-Data : 전자봉투+전자서명 데이터 타입
• 기타 Useful Type : 인증서, CRL
• Digested-Data : 메시지 축약 타입
• Encrypted-Data : 암호화된 메시지 타입

Signed Data - 전자서명 데이터를 담는 포맷

SignedData ::= SEQUENCE {
     version Version,
     digestAlgorithms DigestAlgorithmIdentifiers, - 원본을 Hash 할 알고리즘
     contentInfo ContentInfo, - 원본 데이터
     certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, - 인증서들
     crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, - 인증서 폐기 목록
     signerInfos SignerInfos - 서명자 정보(서명자 ID(발급자정보+시리얼), 추가 의견, 전자 서명

}

SignerInfo - 전자서명 주체에 대한 정보를 담는 포맷 (전자서명 포함)

    

SignerInfo ::= SEQUENCE {

     version Version,
     issuerAndSerialNumber IssuerAndSerialNumber, - 주체 식별자
     digestAlgorithm DigestAlgorithmIdentifier, - 전자서명에 사용할 해시 알고리즘
     authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, - 전자서명 대상 원문
     digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, - 전자서명 알고리즘
     encryptedDigest EncryptedDigest, - 전자서명 값
     unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL - 기타 정보

}

issuerAndSerialNumber는 주체 식별자로, 

  인증서 목록 중 해당 인증서를 찾는 Key 로 사용된다.

DigestAlgorithm 은 SignedData의 digestAlgorithms 중 하나를 선택.

AuthenticatedAttribute 가 없을 시 SignedData의 contentInfo 를 서명한다.

SignedData 검증 및 거래 처리 (PKCS #7)

거래 요청 전문 과 PKCS #7 SignedData를 따로 전송하기 때문에 

실제 거래 내역과 P7 값이 동일한지 확인을 해야 한다.

예 ) 전문 처리

 s_acct=1002777

 r_acct=2222333

 money=100000

전자서명 데이터(법원)

 입금 계좌=1002777

 출금 계좌=2222333

 입금 금액=10 원

위처럼 거래 전문을 수정하는 공격이 실제로 있어 왔고, 

전자 서명 데이터만 법적인 효력을 지님.

따라서 아래와 같이 검증을 해야 한다.

1. SignerInfo-Cert 쌍이 거래 요청자와 일치하는지 비교
2. 전자서명 원문 필드(ContentInfo) Hash
3. SignerInfo 의 Authenticated Attribute 에 있는 원문 Hash 값과 동일한지 비교
4. 서명 시간(Signing Time) 이 있을 경우 허용 시간 내 있는지 확인
5. 서명 검증 (PKCS #1 RSA Verify)
6. PKCS #7의 ContentInfo 에서 거래 데이터 추출 == 거래 요청 전문인지 확인

PKCS #8 - Private-key Information Syntax Standard

다양한 비대칭키 암호 알고리즘의 개인키를 저장하는 규격을 명시.

파일 형태로 보관되는 개인키의 안전한 보호를 위해 PKCS #5 를 이용해 

패스워드 기반의 암호화 된 형태로 개인키를 보관 가능.

PrivateKeyInfo ::= SEQUENCE {
        version                   Version,
        privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
        privateKey                PrivateKey,
        attributes           [0]  IMPLICIT Attributes OPTIONAL  - vid=Hash(Hash(주민번호|Random))

}
      Version ::= INTEGER
      PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
      PrivateKey ::= OCTET STRING
      Attributes ::= SET OF Attribute

잘못된 Private key Pasword를 입력했는지 어떻게 확인 하는가?

PKCS #5 Padding Remover 의 특성으로 복호화가 되었는지 안되었는지 확인.

1. 키가 달라도 1/256 확률로 패딩 체크를 넘어감 (끝이 01로 끝나면)
2. 개인키는 길기 때문에 30 82 가 맞는지. (81 이하일 수 없다.)

30 82 ..... 쓰레기 .... 01 형태가 되면 키가 잘못 되어도 복호화가 된다.

이것은 1/1600만 확률.

PKCS #10 - Certification Request Syntax Standard

인증서 발급 과정에서 사용자가 CA로 전달하는 "인증서 요청서" 에 대한 규격

SubjectDN 과 공개키, 개인키 소유 여부 확인을 위한 서명 정보로 구성되어 있음.

CertificationRequest : 인증서 요청 규격 (SubjectDN + 공개키 + 서명)

PKCS #11 - Cryptographic Token Interface Standard

암호화 장치를 접근하기 위한 C API 규격.

각 암호화 장치를 Slot 으로 구분하고, PIN 번호를 통해 장비에 로그인 한 후 

장비가 제공하는 기능을 사용 할 수 있다.

자바는 JCE 표준을 따른다

PKCS #11 은 모든 상황을 고려해서 설계되어 있지만, 

HSM 모듈/드라이버가 모든 기능을 다 제공 해야 할 의무는 없다.

PKCS #11 Interface - PKCS#11 Driver - HSM

C = AES_CBC_ENC(Key, IV, M) -> 대용량 데이터는 암호화 할 수 없다.

따라서 하기와 같은 식으로 구현되어 있다.

C_Init(Alg, Key, IV)

C_Update(M1)

C_Update(M2)

C_Update(M3)

C_Update(......)

C_Final(M) => C(Padding)

다만 개발자들이 HSM을 먼저 만들고 PKCS #11 을 Wrapping 하도록 만들기 때문에

HSM 성능보다 100% 를 사용 못하는 경우가 많다. 

암호 함수 호출 과정

1. 드라이버 로드 (libpkcs11.so)
2. 드라이버 초기화 (Multi-Thread or not)
3. Slot 리스트 확인
4. Slot 선택 및 Token 얻기
5. 세션 열기 (From Token)
6. 암호 연산 ... 
7. 세션 닫기

PKCS #12 - Personal Information Exchnage Syntax

사용자 개인정보 (인증서 / 개인키) 등을 안전학 전달 하기 위한 규격.

PKCS #5 와 유사한 PBE 기반의 암호화 방법과 PKCS #7 /#8 규격의 데이터 타입을 지원.

  PFX ::= SEQUENCE {
       version     INTEGER {v3(3)}(v3,...),
       authSafe    ContentInfo, - PKCS #12 규격으로 암호화된 PKCS #7 데이터
       macData     MacData OPTIONAL
   }

-MacData 로 패스워드가 제대로 입력되었는지 확인 할 수 있다. 

PKCS #8 에서 PKCS #5 를 이용하는 것과 달리 단순히 패딩이나 헤더만 보는것이 아니다.

   MacData ::= SEQUENCE {
       mac         DigestInfo,
       macSalt     OCTET STRING,
       iterations  INTEGER DEFAULT 1
       -- Note: The default is for historical reasons and its
       --       use is deprecated.
   }

Local Key ID : 개인키와 인증서 쌍을 확인 할 수 있도록 해 줌.

TSP (Time-Stamp Protocol) 표준

시점 확인 프로토콜( RFC 3161 )

전자 서명 시점을 신뢰된 TSA(Time-Stamp Authority) 가 보증해 줌으로써

전자 문서의 생성 시간을 명확히 확인 (공증) 할 수 있음.

단순히 시간만 증명하는 것이 아니라 이런 문서가 있었다 라는 것을 공증.

원문에 대한 해시값과 시간 정보를 함께 서명한 값 + 시간 정보