[Kisa] 암호의 이해와 키 관리 실무 - 3일차 정보보안 Compliance

정보보안 Compliance 의 과거와 현재

전자정부법 시행령 ( 2014. 12. 09 )에 따르면

제69조 (전자문서의 보관·유통 관련 보안조치) 
① 행정기관의 장은 정보통신망을 이용하여 전자문서를 보관·유통할 때에는 법 제56조제3항에 따라 국가정보원장이 안전성을 확인한 다음 각 호의 보안조치를 하여야 한다.
1. 국가정보원장이 개발하거나 안전성을 검증한 암호장치와 정보보호시스템의 도입·운용
2. 전자문서가 보관·유통되는 정보통신망에 대한 보안대책의 시행
② 행정기관의 장이 제1항의 보안조치를 이행하는 경우에는 미리 국가정보원장에게 보안성 검토를 요청하여야 한다.
③ 제1항 및 제2항에서 규정한 사항 외에 정보통신망을 이용한 전자문서의 보관·유통 관련 보안조치에 관하여 필요한 사항은 국가정보원장이 따로 지침으로 정할 수 있다.

공공기관에 들어가는 시스템은 인증 받아야 한다.

그렇다면 각 웹 브라우저 벤더가 개발 또는 탑재한 HTTPS 는 어떻게 할 것인가?

그들이 CC인증 받는가? 아니다.. 하지만 예외 조항을 두기 시작하면 끝이 없음.

전자금융감독규정

공인 인증서 - 37조

예전에는 반드시 공인 인증서를 사용하도록 되어 있었다.

그러는 와중에 천송이 코트 사건이 터져버렸다.

-> 공인인증서와 ActiveX 때문에 중국인들이 천송이 코트를 못사서 엄청난 피해를 입음.

다만 이것은 공인 인증서 문제는 아니고 그 쇼핑몰이 해외 PG 를 연동하지 않았던 이슈다.

해외 카드를 쓴다면 그 회사의 인증 Compliance 를 따른다. 

즉 해외 PG 를 연동하면 굳이 공인인증서 안써도 되는 거임.

물론 한국인이라면 해외에서 공인인증서 발급이 어려워 문제가 있었을 것이다.

제37조(인증방법 사용기준) 금융회사 또는 전자금융업자는 전자금융거래의 종류·성격·위험수준 등을 고려하여 안전한 인증방법을 사용하여야 한다.

-> 결론적으로 이렇게 수정되었다.

안전한 기준은? 결국 금융회사가 떠안게 된다.

그러나 사실상 페이팔 사고가 0.9% -> 0.3% 

한국은 0.0001% 정도...굉장히 안전한 편이다.

보안 프로그램

하나은행에서 가장 먼저 아이폰 출시와 함께 최초로 인터넷 뱅킹을 출시했다.

다만 그때 법 규정이 없어서 전자 금융 감독원에서 매우 당황하게 된다.

2011년 -

이제서야 '이용자 PC' 가 아니라 '전자적 장치' 로 명시하여 

보안 프로그램을 설치하도록 했다. 

그리고 현재는 이런 규정마저 삭제하여 보안 프로그램을 설치하던 말던 상관없고

대신 사고나면 너네 책임이라고 규정을 바꾸었다.

매체 분리의 법칙 - 34조

예전에는 스마트폰에 OTP 못 넣었다.

이제는 삭제되었고 MOTP 사용 가능해짐. 요새는 스마트폰에 스마트 OTP 사용 가능.

보안카드

예전에 파밍을 이용해 보안카드 몇개만 입력하라고 하고, 

해커는 원하는 보안카드 번호가 나올 때까지 계속 F5 를 입력해서 돈을 빼감.

그래서 규정이 새로 생겼다. 은행에서 한번 물어본 번호를 또 물어보라고

그런데 이후에 이걸 역이용한 메모리 해킹 사례가 발생.

해커가 보안 카드 번호를 가로챈 다음 사용자에게는 에러메시지 띄우고,

실제로 해당 보안 카드 번호를 이용해 돈을 빼감.

그래서 문구 삭제. 사고나면 너네 책임.

웹 어플리케이션 취약점 - 13조

2006년 -

SQL Injection, 업로드 취약점, Cookie Injection, XSS, BOF, 

부적절한 파라미터, 접근통제 취약점, 적절한 환경설정 취약점에 대해서 막으라고 나왔다.

매우 선구적인 사람들이었음. 그 당시에는 한글 문서도 없었고 아는 업체도 없었다.

2015년 -

알아서 해킹 공격에 노출 되지 않도록 대응 조치 해야한다고 수정 함.

홈페이지 관리 - 17조

2011년 - 

관리자 모드에 대한 인증 강화 ( 아이디 / 비밀번호 + 공인인증서 등 )

2015년 - 

공인인증서나 포트 관련 문구 삭제

보안성 심의 - 36조

2015년 - 공공기관은 보안성 심의 좀 면제되도록 수정

2015년 6월 - 자체 보안성 심의 후 결과 보고서를 금감원에 제출하도록 변경.

전자금융거래법

책임 - 9조

1차적으로 금융회사나 전자 금융업자의 책임

2015년 - 

고의나 중대한 과실이 있는 경우 

책임 전부나 일부를 이용자가 부담하게 할 수 있다.

왜냐하면 처음에는 은행에서 다 부담했지만 워낙 파밍이 기승을 부리자

캠페인도 많이 하고 노력해서 사용자에게 알렸음에도 

불구하고 보안카드 번호를 다 입력한 건 사용자 부주의로 볼 수 있음.

전기통신금융사기 피해 환급에 관한 특별법

환급

2014년 - 

ㆍ전기통신금융사기죄 신설 (10년이하 / 1억원 이하)

ㆍ온라인 대출 신청 및 저축상품 해지 시 

금융회사의 본인확인 의무화 (전화인증, 휴대폰 SMS)

ㆍ금융회사는 FDS를 통해 사기임을 탐지한 경우 이체/송금을 지연 및 일시 정지

ㆍ사기이용계좌(대포통장) 명의인에 대해 전자금융거래 제한

모든 전자금융 사기의 핵심에는 대포통장이 있다.

Compliance

많은 Compliance 가 있는데 지금은 가이드 하는 식이다.

하지만 결국 자율과 책임 위주로 가게 될 것이다.

Read More

[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) 가 보증해 줌으로써

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

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

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

Read More

[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에 표준문서가 있다.

Read More

[Kisa] 암호의 이해와 키 관리 실무 - 1일차 (암호학의 기초)

1일차 암호학의 기초

Kerckoff : 결국, 암호 알고리즘을 알아도 키를 모르면 깰 수 없도록 해야 한다.

대칭키

XOR :  같으면 0, 다르면 1

OTP - One Time Pad ( 암호화 )

   - 키 길이와 평문의 길이가 동일함.

   - 가장 빠르고 가장 안전한데 비효율적.

   

OTP - One Time Password ( 인증 )

블럭 암호화 (DES, 3DES, Blowfish, AES, SEED ...)

 - 암호문의 길이는 블록의 배수 ( 16Byte 블록이라면 1Byte 암호화해도 16Byte가 나옴 )

패딩 : 0x남은게 몇 비트인지?

단, 패딩 리무버는 반드시 작동하므로, 평문이 딱 블록의 배수가 된다고 해도

블록 단위가 16Byte 일 때 16을 16개로 채워서 복호화 하는 사람을 배려 한다.

(즉, 16Byte 를 암호화 해도 32Byte 가 나온다.)

스트림 암호화 (RC2, RC4 ...)

 - Key -> Key Derive Function -> Key Stream . 이후 1bit 씩 암호화

AES 

   - AES 192, AES 256 Bit 의 안정성이 실제 키 사이즈 보다 낮음을 증명

     특히 AES 256 은 오히려 AES 128 보다 낮다.

     https://eprint.iacr.org/2009/317.pdf

DES - Feistel 구조

   - 암호화와 복호화 로직이 동일함. 다만 키 스케줄링 순서가 반대일 뿐

   - 그렇다면 대칭성을 가진 키가 있다면 ? 암호화 한번 더 하면 자연히 복호화 된다.

   - Brute Force 에 취약하다고 밝혀져 3-DES 가 나오게 됨.

암호화 모드 (https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)

IV - CBC, CFB, OFB, CTR

암호문의 길이를 평문 길이에 맞춤 : CFB, OFB, CTR

암호문 변조 확인 : GCM, CCM

CBC : 그것만 없으면 가장 안전함.

ECB 모드(Key, Padding) : 상당히 짧은 데이터를 암호화 할 때 정도만 쓰인다. 

왜냐하면 한개의 블록만 해독되면 나머지도 해독 됨.

CBC 모드(Key, IV, Padding) : 가장 안전하고 가장 많이 쓰는데 ...

PKCS5  패딩 오류가 결합되면 가장 취약함. 

처음 IV로 XOR 하고 키 알고리즘으로 암호화 한다. 

이후는 나온 암호문 블록이 IV가 되서 반복한다.

CFB 모드(Key, IV, NOP) : CBC 다음으로 안전한데, 구현이 좀 어렵다.

블록 암호화를 스트림 암호화 처럼 구성해 Padding 필요 없음

IV를 암호화 한 다음 스트림 단위로 자르고, 평문이랑 XOR 한다. 

이후 이 스트림이 다시 IV가 됨.

OFB 모드(Key, IV, NOP) : 한번 더 암호화 하면 평문 나와서 취약함. 좀 속도가 빠르긴 함.

Padding 필요 없음

CTR 모드(Key, IV, NOP): 한번 더 암호화 하면 평문 나옴. 

다만 이렇게 되지 않도록 Shift 등, 보완해서 쓴다. 

다른 모드에 비해 평문 수정이 쉽다. 

IV를 1씩 증가시켜서 암호화 시킨 다음, 평문과 XOR 한다.

GCM 모드(Key, IV,  AAD, NOP) : 

CTR과 동일한데,

Additional Auth Data 로 암호문 블록을 계속 XOR 해서 Auth Tag를 만들어 낸다.

이걸로 무결성 검증이 가능하다.

CCM 모드(Key, Nonce, AAD, Tlen, NOP)

CTR과 동일한데 안쓴다.

문제 : IV 를 찾아라 !

암복호화 엔진을 변경하려고 하는데, CBC모드를 사용하고 있어
기존에 사용되던 Key 와 IV를 알아내야 한다.
그러나 IV는 해당 엔진 내에 화이트박스 처리 되어있어 알 수 없는 상황.
즉,
Encrypt (Key, IV, 평문) -> 암호문
이 아니라
Encrypt (Key, 평문) -> 암호문

이렇게 CBC 모드의 IV 가 함수 자체에 내장되어 있는 경우 어떻게 IV를 찾는가?

0을 CBC 로 암호화 하게되면 

0 XOR IV == IV -> enc (IV)

따라서 다시 ECB dec 하면 IV 가 나오게 된다.

Oracle Padding (CBC)

패딩 오류가 안나고 통과할 때 까지 두번째 블록을 변경해서 날려본다.

결론 : AES 128bit GCM 쓰면 된다. 

비대칭키

RSA (2048) : 소인수 분해. 암호화, 전자서명

DSA (1024) : 이산대수. 전자서명

DH (1024) : 이산대수. 키 교환

ELGamal (1024) : 이산대수. 암호화. 전자서명

ECDH (256) : 타원곡선 상의 이산대수. 키 교환

ECDSA (256) : 타원곡선 상의 이산대수. 전자서명

KCDSA (1024) : 이산대수. 전자서명

키 길이가 괄호 bit 이상이면 안전하다 라고 알려져 있음.

적당히 작은 e를 써야하는데 65537 을 쓴다. 너무 작은 값을 사용하면 취약하다.

RSA - 암호문은 확률적으로 계속 변경된다. 어떻게?

( 하나의 평문에 대응하는 암호문이 많다 )

-> 패딩을 쓰레기값으로 넣어줘서 전체 값이 랜덤하게 변경되도록 한다.

10 G 메시지가 있다고 치자.

이거 RSA로 암호화 하면 너무 오래걸린다. -> 해시해서 쓴다.

MD5 - 알고리즘 자체에 취약점이 발견되어 사용 불가.

SHA1 에서 2^80 메시지만 갖고 있어도 100% 충돌을 발견 할 수 있다.

 전자 서명에서 사용 할 수 없다. 

SHA2 에 256비트 많이 쓰는데 알고리즘 취약점이 나올 확률이 있다.

SHA3 - SHA2 보다 3배정도 느리지만 앞으로 많이 쓰일 것으로 보인다.

서명 : 메시지를 해시 하고 개인키로 암호화해서 메시지와 함께 보내면 

공개키 연산이 더 빠르다 -> 작은 소수를 썼기 때문이다.

Random Generator 가 실제 난수가 아니기 때문에

컴퓨터가 랜덤한 Seed 를 만들지 못하고 Sha 도 다양성이 낮으면

낮은걸 따라가므로 128비트 정도의 안정성 밖에 없다.

Read More