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

질문 :

전자서명과 암호화를 동시에 하는 방법? : Sign crypto. 어디까지나 학문적인 것.
CA 인증서 업데이트 방법? : 국제 표준 CTL 규격으로 CA 를 업데이트 가능.
개인키 유출의 위험을 최소화 하는 방법? :
 - 보안토큰 등에 보관.
 - Perfect Forward Secrecy (DH)
 - 키를 폐기 가능하도록 할 것.

키 관리 등급
ISO/IEC 24759 에서는 보안 등급 별 키 관리 기능을 명시 하고 있음.
FIPS 140-2 보안 등급에서 S/W 로는 아무리 잘 만들어도 1등급 이다.
보안등급 3 이상을 받기 위해서는 개인키가 암호화 되어 있거나
지식 분산 절차를 사용해 주입 / 출력 되어야 함.

기본적으로 난수 발생, 키생성, 키 합의, 키 분배, 키 주입/출력, 키 저장, 키 제로화 제공

레벨 2 : EAL 2 이상 OS, 물리적 수준은 보안스티커 .
레벨 3 : EAL 3 이상 OS, 물리적 수준은 에폭시 발라서 뜯으면 키가 파괴됨.
레벨 4 : EAL 4 이상 OS, 물리적 수준은 EFP (Environmental Failure Protection) / EFT (Environmental Failure Testing)

HSM - Black Box
SW - White Box - 키를 못찾게 하는 것은 기술력이며, 표준이 없다. 깨진 사례가 많다.
다만, 두 구조 모두 인증을 넣는 개념이 필요하다.

PKI 와 관련 표준의 이해

ASN.1 (RFC 표준 中 매우 기본적인 것)

상대방에게 전달하기 위해서 어떤 방법을 사용 할 것인가?

Decimal / HEX / Big Endian / Little Endian / WIDE String / UTF-8 / ASCII ???

즉, ASM.1 은 추상적인 타입과 값에 대한 표기법이다.

Object ID : 전 세계 유일한 ID

EXPLICIT / IMPLICIT / ANY(VOID) / CHOICE (UNION)

IMPLICIT : 타입을 생략하므로 데이터는 그만큼 줄어듬.
EXPLICIT :  TLV 전체가 VALUE 가 된다. 항상 구조체이다.

ASN.1 : TAG(1byte), LENGTH(가변), VALUE(가변). (TLV)

ASN.1 Notation

BOX :: = SEQUENCE {

    a Integer = 3,

    b Integer = 9

}

ASN.1 DER 

(HEX) : 30 06 02 01 03 02 01 09

TAG : 30

LENGTH : 06

TAG : 02

LENGTH : 01

VALUE : 03

TAG : 02

LENGTH 01

VALUE : 09

TAG

+---------+---------+---------+---------+---------+---------+---------+

|      CLASS(2)        |Structure|          LOW TAG NUMBER(5)          |

+---------+---------+---------+---------+---------+---------+---------+

CLASS : 0 - Universal, 1 - Application, 2 - Context, 4 - Private

STRUCTURE : 0 - Primitive, 1 - Constructed

LOW TAG NUMBER

Universal Tag Number	Description
0	reserved for BER
1	BOOLEAN
2	INTEGER
3	BIT STRING
4	OCTET STRING
5	NULL
6	OBJECT IDENTIFIER (전세계 유일)
7	ObjectDescriptor
8	INSTANCE OF, EXTERNAL
9	REAL
10	ENUMERATED
11	EMBEDDED PDV
12	UTF8String
13	RELATIVE-OID
16	SEQUENCE, SEQUENCE OF (순서)
17	SET, SET OF
18	NumericString
19	PrintableString
20	TeletexString, T61String
21	VideotexString
22	IA5String
23	UTCTime
24	GeneralizedTime
25	GraphicString
26	VisibleString, ISO646String
27	GeneralString
28	UniversalString
29	CHARACTER STRING
30	BMPString

LENGTH

데이터가 11 22 33 44 ... x Byte 인 경우 어떻게 표시할까?

Short Form
04 7F 11 22 33 44 .... 127 Byte

Long Form
Value 의 길이가 128 바이트 이상 일 경우

+---------+---------+---------+---------+---------+---------+---------+

|      1     |                     LENGTH 정보 필드의 크기                    |

+---------+---------+---------+---------+---------+---------+---------+

04 81 80 11 22 33 44 .... 128 Byte

04 82 03 E8 11 22 33 44 .... 1000 Byte

100000 = 186A0
04 83 01 86 A0 11 22 33 44 ..... 100000Byte

INTEGER
2의 보수는 음수이며, 최상위 비트가 1이면 음수로 표현
1의 보수로 만든 다음 1을 더하면 된다.
FF = 1111 1111 -> (-) 0000 0000 -> (-) 0000 0001 = -1

5 : 02 01 05
255 : 02 02 00 FF ( 00을 넣는 이유는 음수가 아님을 표현하기 위해서 )

OID
1.2.840.113549 : 06 06 2A 86 48 86 F7 0D
1.2.840.113549.1 : 06 07 2A 86 48 86 F7 0D 01

1.2.840.113549.1.7 : 06 08 2A 86 48 86 F7 0D 01 07

ASN.1 실습 :

[1] EXPLICIT NULL
A1  02        05 00

[1] IMPLICIT NULL
81 00

[2] EXPLICIT SEQUENCE {}
=> A2 02 30 00

[3] IMPLICIT SEQUENCE {}
=> A2 00
1 0 1 0 0 0 1 0 = A2

BER

Integer 3 =
DER/BER : 02 01 03
      BER : 02 80 03 00 00

BER :  모호한 길이 표현 가능.
0x80 을 넣고 끝에 00 00 을 붙여준다.
30 80 02 01 03 02 01 09 00 00

이제 ASN.1의 DER 인증서를 읽어보자 !

30 으로 시작하니 EXPLICIT SEQUENCE 이고 8이니까 LONG. 2는 길이가 2바이트.
뒤쪽 05 bd 는 VALUE의 크기다. = 1469

더 읽어보기 전에 RFC 2459/3280/5280 문서를 확인해 보자.

4.1.  Basic Certificate Fields

   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

   CertificateSerialNumber  ::=  INTEGER

   Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time }

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   UniqueIdentifier  ::=  BIT STRING

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

수동으로하면 귀찮으니 ASN.1 Editor 로 확인 하면 순서대로

 TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,

version = 2
serialNumber = 18578931 = 01 1B 7D F3
signature = 1.2.840.113549.1.1.11 = sha256WithRSAEncryption

정말인지 인증서 뷰어로 확인 해 보자.

잘 읽은 것을 알 수 있다.

보안 관련 표준을 쉽게 이해하는 노하우

• 이 표준의 목적이 무엇인가 ?
• 종류는 ? ( 데이터 규격 / 인터페이스 / 알고리즘 / 프로토콜 )
• 데이터 기밀성 만족이 필요한지, 방법은 ?
• 데이터 무결성 만족이 필요한지, 방법은 ?
• 개체에 대한 인증이 필요한가 ? 방법은 ?
• 프로토콜이라면 어떤 보안 기능 (재전송 공격 차단 등) 이 있는가?

RFC 는 대부분 하위 호환성을 잘 지키도록 되어 있다.

인증서 검증

기본 검증

• X509 규격에 맞는지?
• 신뢰된 CA로 발급 되었는지?
• 인증서 경로상 서명 검증 결과가 유효한지?
• 인증서가 유효 기간 內 사용되고 있는지
• 인증서의 주체가 올바른지?

확장 검증

• 계층 별 인증서가 올바른지? ( CA / USER )
• 올바른 키 용도로 사용되고 있는지? ( 암호화 / 부인방지 / 전자 서명 등 )
• 올바른 정책 (OID) 으로 사용되고 있는지? ( 은행용 / 증권용 / 보험용 등 )
• 폐기 또는 효력 정지 되었는지? ( OCSP / CRL )

국내 공인인증 확장 검증

• 인증서와 주민번호가 서로 일치하는지?

주민번호는 실제 주민번호를 저장하는것은 아니고 SHA2(SHA2(주민번호|RANDOM)

그러나 Random 값만 알 수 있다면 5시간이면 주민번호 찾을 수 있다.

Random 값은 개인키와 함께 암호화 되어 있는데, 보관에 유의해야 한다.

인증서 상태 검증.. 

하루에 국내에서만 공인인증서 로그인이 5600만건이 이루어지며

비용이 매우 비싸서 자체적으로 LDAP을 통해 인증서 상태 검증 프로세스를 수립하고

당행 발급 인증서가 아닌경우 RA에 쿼리, 타기관이면 금결원 OCSP에 쿼리한다.

문제는 폐기된 타기관 인증서로 계속 은행이나 사이트에 요청하면
돈이 엄청나게 청구되게 된다.
그래서 먼저 가입자 조회부터 하고 인증서 확인 하도록 해야 한다.

X509 확장

기관 키 식별자 : CA의 인증서를 찾는데 IssuerDN 만으로는 부족하므로
CA의 공개키를 해시한 값, CA 인증서 시리얼 번호를 함께 기록함.

주체 키 식별자 : SubjectDN은 얼마든지 동일할 수 있으므로 키를 통해 사용자를 식별하는데 사용. 공개키를 SHA1으로 해시 한 값을 명시.

키 사용 용도 : 공개키와 개인키에 용도를 제한.

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                        -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

예를 들어 C0 = 1100 0000 이므로, 전자서명과 부인방지 용도로 쓸 수 있다.

인증서 정책 : 정책에 따라 범용/은행/보험/카드사/증권사 등의 정책이 존재.

인증서 경로 검증

1. 검증대상 사용자 인증서
2. CA 인증서 저장소
3. 인증 경로의 최대 길이 ( max_path_length ) - 순환 구조인 인증서가 있을 수 있음.
4. 현재 시간 (GMT)
5. 최상위 인증기관 정보 (최상위 인증기관, 공개키 알고리즘, 공개키, 파라미터)
6. 사용자 초기 정책 집합 ( OID, 자식 인증서가 가능한 OID 리스트 등 )
7. 초기 정책 매핑 금지 여부 ( 인증서 내 명시된 인증 정책 매핑 금지 여부 )
8. 초기 명시 정책 여부 ( 사용자 초기 정책 집합과 유효 정책 트리를 비교 할지 여부 )
9. 초기 모든 정책 금지 여부 ( anyPolicy 정책을 허용할지 말지.)

DN 비교 룰
Text 가 같아도 인코딩 형식이 다르면 다르다.
PrintableString 에 한해서 대소문자 구별 안함.
PrintableString은 trim 하여 공백을 없애고 하나 이상의 공백은 공백 하나로 처리.

인증서 키 용도 검증 : 버전 3부터 새로 생겼다.

기본 제한 (Basic Constraints)

CA 인증서인 경우, 현재 인증서로부터 발급 가능한 CA 인증서 계층 수를 제한 가능.
경로 길이 : 0 인 경우, 사용자 인증서만 발급가능. None인 경우 제한 없음.
예를 들어 중간 CA의 Path Length 1인데 하위 CA기관에도 1로 발급 할 경우,
경로 검사가 실패하므로 클라이언트가 이 인증서를 믿지 않게 된다.

KISA에 표준문서가 있다.