키 관리와 인증서

키관리와인증서 컴퓨터시스템보안 금오공과대학교컴퓨터공학부 최태영

목차 비밀키관리 비밀키개인관리 키관리센터 (KDC) 공개키관리 공개키관리의필요성 공개키인증서및공개키기반구조 인증서철회목록 공개키암호화표준 (PKCS) OpenSSL 을이용한인증서관리 2

비밀키개인관리 비밀키도난방지를위해비밀키를암호화하여보관하는것이안전 KEK (Key Encryption Key) 키암호화에사용되는키 KEK는보관되지않고필요할때생성됨 KEK의생성 : 패스워드와같이사용자가기억하는정보를해싱이나암호화를통해생성 3

KEK 생성및사용과정 패스워드 Hash KEK 비밀키 암호화 암호화된비밀키 4

키관리센터 Key Distribution Center (KDC) 신뢰할만한제 3자로서키관리및분배를책임지는주체 사용자들간의비밀통신을보장 KDC에대한사용자등록과정 1. 사용자A는KDC에등록신청 2. KDC는 A의신분확인 3. KDC는 A와의비밀키 K A 를 A에게전달, (A,K A ) 를저장 등록된사용자는각각 KDC와의비밀키를가지고있음 5

KDC 를통한키공유 1. 사용자 A는 KDC에 B와공유할비밀키요청 2. KDC는 A의신원확인뒤 E(K AB P B, K A ) 를 A에게전송 P B = E(K AB A, K B ) 3. A는위암호문을 K A 로풀어서 K AB 를얻고, P B 를 B에게전송 4. B는 P B 를K B 로풀어서 K AB 를얻음 왜 P B 를직접 KDC 가 B 에게보내지않는가? 6

KDC 를이용한키공유 1. 비밀키요청 KDC 2. E(K AB P B, K A ) A 3. P B = E(K AB A, K B ) B 7

KDC 분석 KDC 의단점 단일실패지점 (SPoF, Single Point of Failure) KDC 가고장나면전혀서비스를할수없음 해결책 : 미러서버 (mirror server) 가동 서버와미러간의일관성 (consistency) 문제발생가능 KDC 가공격되면모든비밀키가노출될수있음 KDC 의신뢰성이매우중요함 KDC 에대한병목현상 (bottleneck) 발생 KDC 의장점 비밀키방식은비교적속도가빠름 서버를사용하지않는경우보다키관리를쉽게해줌 8

공개키관리의필요성 N 명사용자에대해 N 쌍의키가필요하므로비밀키에비하여관리가용이 개인키관리 공격에의한노출을막기위해 KEK 를통한암호화가바람직 공개키관리 소극적인공격만있는경우에는인터넷과같은공개채널을이용하여전달이용이함 적극적공격에는안전하다고할수없음 밥이앨리스에게보낸밥의공개키를공격자트루디가중간에자신의공개키로바꾸어앨리스에게전달 앨리스는트루디의공개키로자신의메시지를암호화하여밥에게전달 트루디는밥에게전달되는메시지를복호화하여볼수있음 공개키전달시에인증과무결성이보장되어야함 전달될공개키에대한전자서명이필요함 누구의개인키로서명을할것인가? 9

공개키인증서 Public key certificate 공개키에전자서명을첨부한것 X.509 표준에포함 X.509 : International Telecommunication Union (ITU) 에서제안한공개키기반구조 (Public Key Infrastructure, PKI) 표준의일부 현재 Version 3 이사용 Version 에따른필드추가 Ver.2 : 발행인및공개키소유자고유번호추가 Ver.3 : 발행인키구분자, 소유자키구분자, 키사용범위, 개인키사용기간, 인증서정책, 소유자별명, 발행인추가정보, 소유자의인증기관여부, 이름제한, 정책제한추가 10

공개키인증서구조 버전 (Version) 일련번호 (Certificate Serial Number) 서명알고리즘 (Signature Algorithm) 발행인이름 (Issuer Name) 유효기간 (Validity) 공개키소유자 (Subject Name) 공개키 (Subject Public Key Information) 발행인고유번호 (Issuer Unique Identifier) f I A K O A m 공개키소유자고유번호 (Subject Unique Identifier) 확장필드 (Extensions) 서명 f(m, K P I ) 11

인증서각필드설명 Certificate Serial Number : 인증서가발행된순서 Signature Algorithm : 어떠한공개키알고리즘을사용했는지를기입 Issuer Name : 인증서에서명한사람또는기관의이름 Validity : 인증서내의공개키가유효한기간 키가닳기전에무효화시키야함. 유효기간이지난공개키인증서는효력이없음 Subject Name : 인증서내공개키의소유자 Subject Public Key Information : 공개키 Issuer Unique Identifier (v2) : 서명한사람을식별하기위한고유번호 ( 여러사람이한공개키를서명할수있음 ) Subject Unique Identifier : 공개키소유자의고유번호 서명 : 위의정보들에대한서명 위의내용들을발행인 (Issuer) 의개인키를이용하여위에서언급한서명알고리즘으로서명한전자서명 12

공개키인증서체인 공개키인증서를검증하기위해서는발행자의공개키가있어야함 보통발행자의공개키는그발행자의공개키인증서에있음. 최종공개키인증서를얻을때까지이러한과정을되풀이함 밥의공개키인증서 톰의서명 톰의공개키인증서 X 의서명 X 의공개키인증서 X 의서명 밥의공개키서명검증톰의공개키서명검증 X의공개키서명검증 3 2 1 13

자기서명인증서 Self-signed certificate 발행자가공개키의소유자와동일한인증서 발행자의개인키로발행자의공개키를서명한인증서 루트인증서 (Root certificate) 인증기관 (Certificate Authority, CA) 가발행한자기서명인증서 공개키인증서체인의마지막에존재하는인증서 신뢰할수있는상대로부터신뢰할수있는안전한채널을통해받아야함 직접전달받거나, Fingerprint 를통해검증함 14

공개키기반구조 Public Key Infrastructure (PKI) 인증기관 (Certificate Authority, CA) PKI에참여하고있는회원들의공개키를관리 공개키보관, 인증서작성, 인증서제공 PKI에서상대방의공개키획득과정 1. CA의루트인증서획득 ( 또는회원등록 ) 2. CA로부터밥의공개키인증서획득 3. CA의공개키로밥의공개키인증서검증 PKI에대한회원가입과정 1. CA 또는등록기관 (Registration Authority, RA) 에신원확인 2. CA의루트인증서획득 3. 자신의공개키와개인키를생성하여공개키와인증서신청서를제출 4. CA는공개키인증서를생성 15

PKI 공개키인증서검증과정 ( 루트인증서소유시 ) 1. CA 의공개키인증서검증 2. 상대방의공개키인증서를 CA 의공개키로검증 3. 상대방의공개키인증서내유효기간을확인 4. 상대방의공개키인증서가인증서철회목록 (Certificate Revocation List, CRL) 에없는지확인 해싱 비교 ( 검증 ) 해싱 비교 ( 검증 ) CA 의공개키인증서 CA 의공개키 CA 의서명 공개키복호화 밥의공개키인증서일련번호유효기간밥의공개키 CA의서명 공개키복호화 유효기간확인 CRL 확인 16

인증서철회목록 Certificate Revocation List (CRL) 이미철회된인증서들의일련번호모음 Version Signature Algorithm Identifier Issuer name This Update Next Update Serial Revocation date Extensions 2220002 2009/03/08 개인키노출 2221001 2009/03/09 회원탈퇴 Signature 17

CRL 공개키가철회되는이유 사용자의개인키가도난과같은이유로노출되었다고의심되는경우, 공개키인증서의발급과정에서문제가발생한경우, 새로운공개키쌍사용, 또는 자신의직위가바뀜에따라그직위에부여된공개키가더이상사용되지않는경우. CRL 전달방법 offline: 주기적으로사용자에게 email등의방법으로전달 online : 공개된서버에 CRL을게시 18

Offline CRL Management CRL 은주기적으로발송되어 CA 가오프라인이라도키관리가가능하도록설계 PKI 는 CA 가오프라인이라도가동할수있게구성된시스템 유효기간이지난공개키는 CRL 에포함되지않음 항상유효기간과 CRL 을같이검토해야함 공개키를사용하는시스템은항상 CRL 을보관해야함 카드결제시스템같은소형시스템도포함됨 시스템의용량과성능에대한부하증가 CRL 전달시 CA 의병목현상 (bottleneck) 유발 Delta CRL : 병목현상감소목적으로개발 19

Delta CRL Base CRL 과 Delta CRL 로구성 Base CRL : 처음발송되는 CRL Delta CRL : 이전에발송한 CRL 과의차이만포함된 CRL Delta CRL 은별도의필드가있어야함 Delta CRL 여부를알려주는필드 장점 CRL 의양이줄어들기때문에병목현상이완화됨 단점 Delta CRL 들중하나만빠져도일관성없는목록이됨 각사용자시스템의부하는줄어들지않음 20

Delta CRL CRL 1246 1743 1845 Base CRL 1246 1743 1845 CRL 1743 1845 1943 Delta CRL 1943 CRL 1743 1845 1943 Delta CRL 21

Offline CRL CRL 발행후에철회된공개키는확인하지못함 오프라인으로서의문제점 Ex) CRL 이 3/10 에발급되었고공개키인증서가 3/14 에무효화되면, 3/15 에그인증서를받은사람은무효화된인증서를이용하게됨 갱신될내용이없어도다음 CRL 이발급되어야함 주기적갱신으로서의문제점 유효기간이남아있는철회된공개키인증서목록이모두발급됨 Delta CRL 로어느정도부하를줄일수는있음 22

온라인인증서철회관리 오프라인방식을온라인방식으로변경 Online Certificate Status Protocol (OCSP) 검증시마다인증서의철회여부를서버에게문의 OCSP responder 가철회된인증서의목록을관리하며질의에응답함 OCSP response : 인증서의상태 (good, revocated, unknown), 일시, ( 철회이유,) 전자서명 http 또는 email 같은기존의인터넷통신프로토콜사용 Simple Certificate Validation Protocol (SCVP) Delta CRL 과인증서체인에필요한목록제공 23

OCSP 1. 사용자는 OCSP 응답자에게한인증서의정당성여부를묻는요청 (OCSP request) 를보낸다. 2. OCSP 응답자는자신의 X.500 디렉토리에들어있는해당인증서의유효여부를검사한다. 3. OCSP 응답자는검사결과를 OCSP response의형태로사용자에게돌려준다. 사용자 1 OCSP request OCSP 응답자 3 OCSP response 2 유효성검사 X.500 24

공개키인증서의종류 이메일인증서 서버측인증서 사용자측인증서 코드인증서 로밍인증서 25

공개키인증서 ( 계속 ) 이메일인증서 이메일의신원을보장하기위해사용 VBR (Vouch by Reference) : 제 3 자가이메일발송지의신원을보장하는방법 서버측인증서 서버가자신에게암호문을보낼수있도록클라이언트에게보내는인증서 서버의신원을보장하는용도로도사용 사용자측인증서 서버가클라이언트의신원을확인하기위해사용 26

공개키인증서 ( 계속 ) 코드인증서 자바애플릿이나액티브 - 액스는트로이목마의가능성을포함하고있음 다운로드받은프로그램의신뢰성을보장해주기위해사용 프로그램의서명과그서명을검증할수있도록첨부된공개키인증서 로밍인증서 (Roaming certificate) 인증서를휴대하지않고도외부에서필요한인증서를얻는방법 27

로밍인증서 신임장서버 (Certificate server) 에공개키인증서와개인키를저장해두고필요할때마다접속하여인증서를획득 사용자컴퓨터 앨리스 1. 등록 개인키, 공개키인증서 신임장서버 Id, pw, 공개키인증서, 개인키.. 2. Id / pw 3. 개인키, 공개키인증서 터미널 앨리스 28

개인키관리 개인키관리의어려움 개인컴퓨터에보관된개인키는공격자의컴퓨터침입에대비해야함 휴대하는개인키는분실또는복제의위험성에노출됨 개인키공격에대한방어 패스워드 : KEK 등을이용하여개인키를암호화함, 패스워드추측공격을당할수있음 암호화한이동형저장장치 : 저장장치의내용에접근하기위해서 pin 등으로암호화함 PKCS#12 는개인키와인증서를암호화하여저장하는표준임 29

개인키관리 ( 계속 ) 복호화를위한개인키와서명을위한개인키는구분할필요가있음 (8 장에서다룸 ) 용도에따른개인키보관시기가다름 복호화용개인키 인증서가무효화되었더라도보관해야함 무효화되기이전에생성된암호문이무효화된이후에도착할수있음, 또는이전에저장된암호문이나중에참조될수있음 서명용개인키 인증서가무효화되는즉시폐기해야함 ( 악용가능성 ) 공개키인증서 유효기간이지나더라도 CA 에서보관 소송등의증거로사용됨 30

공개키암호화표준 Public Key Cryptography Standard (PKCS) RSA Laboratories 에서제안 공개키기반구조 (PKI) 표준 15 개의항목으로구성 메시지포맷, 알고리즘, API 등을포함 2 개항목은개정과정에서통합되었으며 2 개항목은개발중임 X.509 Telecommunication Standardization Sector (ITU-T) 에서제안한 X.500 표준의일부 공개키인증서, CRL, attribute certificate (AC, authorization certificate) 등을주로다룸 AC : 특정자원이나서비스를이용할수있는허가서 31

PKCS#1 (RSA Encryption Standard) 공개키쌍의수학적특성기술 RSA 암호화및복호화알고리즘 패딩방식 전자서명및검증알고리즘 PKCS#2 (PKCS#1 에포함됨 ) PKCS#3 (Diffie-Hellman Key Agreement Standard) PKCS#4 (PKCS#1 에포함됨 ) PKCS#5 (Password-based Encryption Standard) KEK 생성알고리즘 PKCS#6 (Extended Certificate Syntax Standard) X.509 v3 이이를대체함 PKCS#7 (Cryptographic Message Syntax Standard) 암호화, 서명등을포함하는경우와포함하지않는경우의메시지표준양식이포함됨 32

PKCS#8 (Private-Key Information Syntax Standard) 개인키를 ( 휴대하고 ) ( 암호화하여 ) 보관하는방식 PKCS#9 (Selected Attribute Types) PKCS#6 의확장된인증서, PKCS#7 의전자서명메시지, PKCS#8 의개인키정보, PKCS#10 의인증서 - 서명요구에관련된특성들에대한정의를다룸 PKCS#10 (Certification Request Standard) 인증서요구메시지의양식과프로토콜 PKCS#11 (Cryptographic Token Interface, Cryptoki) 암호화토큰에대한 API 표준 PKCS#12 (Personal Information Exchange Syntax Standard) 공개키인증서, 개인키, 공개키저장을위한파일포맷 PKCS#13 (Elliptic Curve Cryptography Standard) PKCS#14 (Pseudo-random Number Generation) PKCS#15 (Cryptographic Token Information Format Standard) 암호화토큰의사용자가자신의신분을토큰에게알리는방법 33

OpenSSL 을이용한인증서관리 OpenSSL command line 명령어를사용 인증기관 CA와사용자 Alice 간의파일생성및교환을다룸 1. 공개키 / 개인키생성 2. 자기서명인증서생성 CA 5. 인증서발송 4. 인증서서명요구서발송 앨리스 3. 공개키 / 개인키생성 34

루트인증서생성 CA 의공개키인증서 (root certificate) 생성의예 $ openssl genrsa -out CAPriv.pem 1024 $ openssl req -new -key CAPriv.pem -out CAReq.pem $ openssl x509 -req -days 3650 -in CAReq.pem -signkey \ CAPriv.pem -out CACert.pem 공개키인증서는인증서요청서 (CAReq.pem) 를통해생성함 35

OpenSSL req command 인증서서명신청서작성명령어 PKCS#10 표준을따름 -new : 새로운서명신청서를만든다는옵션 -key <file> : 신청서에는공개키도포함되고신청서내용에대한서명이첨부됨 서명은공개키소유자의개인키로서명됨 -out <file> : 신청서파일명 -in <file> : 기존의신청서파일내용을참조함을의미함 -newkey arg : 새로운키를만들어사용함을의미함 Ex) newkey rsa:1024 -nodes : 새로운개인키를만들었을경우이를암호화하여저장하지않겠다는의미 -subj arg : 인증서소유자관련정보가포함됨 36

Subject 정보입력예 $ openssl req -new -key CAPriv.pem -out CAReq.pem Country Name (2 letter code) [AU]:KR State or Province Name (full name) [Some-State]:CA-State Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hanti Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Gil-Dong Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: 37

OpenSSL x509 command 인증서내용을보여주거나, 다른형식으로변환하거나, 서명을하여인증서를만드는명령어 -req : 인증서서명신청서를입력으로받아들임을뜻하는옵션 -days <day> : 현재시각부터 <day> 까지를만들어질인증서의유효기간으로함을뜻함 -signkey <file> : 개인키가들어있는파일을가리킴 ex) signkey CAPriv.pem -fingerprint : 인증서의 DER 형식에대한 digest (or hash) 를출력한다. $ openssl x509 -noout -in CACert.pem -fingerprint SHA1 Fingerprint=90:45:5F:BF:BC:C1:15:32:BB:A2:35:7B:3F: 19:57:54:14:90:32:8C 38

공개키인증서의검증 $ openssl verify -CAfile CACert.pem CACert.pem verify command 공개키인증서로다른공개키인증서를검증 위예는 root 인증서를검증한경우 -CAfile : 인증서를검증할공개키가들어있는인증서 위예의마지막파라미터는검증될공개키인증서 -CApath <dir> : 신뢰할만한인증서가 hash.0 이란이름을가질경우그디렉터리를 <dir> 에기입하면인증서파일명을적을필요가없음 -untrusted <file> : 신뢰하지못하는인증서들이있을때이들의이름을여기에기입함 39

개인사용자를위한인증서발급 $ openssl req -new -keyout AlicePriv.pem -subj \ '/C=KR/ST=CA-State/O=Hanti/CN=Alice' -out AliceReq.pem Generating a 1024 bit RSA private key...++++++...++++++ writing new private key to 'AlicePriv.pem' Enter PEM pass phrase: Alice is making cert Verifying - Enter PEM pass phrase: Alice is making cert ----- req command : 사용자의개인키와인증서서명신청서를한꺼번에만들수있는명령어 -subj : 파라미터로인증서소유자의정보를입력할수있음 pass phrase : password 대용으로사용되는비밀문장 40

개인사용자용인증서발급 사용자는서명신청서를 CA 에게발송 CA 는서명신청서가본인인지확인 사용자가직접 CA 를방문하여신청서제출 전화등을통해신청서일부의일치여부확인 CA 는서명신청서를바탕으로공개키인증서를생성 CA 의개인키로사용자의인증서에서명함 사용자의인증서서명신청서, CA 의개인키와인증서가필요함 41

CA 의사용자인증서생성 $ openssl x509 -req -days 365 -CA CACert.pem -CAkey \ CAPriv.pem -CAcreateserial -in AliceReq.pem -out AliceCert.pem Signature ok subject=/c=kr/st=ca-state/o=hanti/cn=alice Getting CA Private Key -CA <file> : 서명에사용될개인키에대응되는인증서, 즉 CA의 root certificate -CAkey <file> : 서명에사용될개인키파일 위예제에서 CA의개인키가사용됨 -CAcreateserial : 일련번호부여파일생성 인증서파일명에따라파일명생성 : 인증서파일 CACert.pem에대해 CACert.srl 일련번호파일이생성됨 -CAserial <file> : <file> 을일련번호부여를위해사용 한번씩사용될때마다값이1씩증가함 42

사용자의인증서검증 $ openssl verify -CAfile CACert.pem CACert.pem $ openssl verify -CAfile CACert.pem AliceCert.pem CA 에등록할때받은 root certificate CACert.pem 과 CA 에게신청하여받은자신의인증서 AliceCert.pem 을검증 43

새로운사용자에대한인증서발급 Bob: $ openssl req -new -keyout BobPriv.pem -subj \ 'C=KR/ST=CA-State/O=Hanti/CN=Bob' -out BobReq.pem \ -nodes CA: $ openssl x509 -req -days 365 -CA CACert.pem \ -CAkey CAPriv.pem -CAserial CACert.srl in \ BobReq.pem -out BobCert.pem $ openssl x509 -text -noout -in BobCert.pem req command 의 -nodes : 생성되는개인키를암호화하지않고저장함 x509 command 의 text : 인증서파일의내용을읽을수있는형태로출력함 -CAserial <file> : 일련번호가있는 <file> 에서일련번호를읽어사용하고그값을 1 증가시킴 44

문서를서명하고검증하는예 Alice: $ openssl smime -sign -in test.txt -inkey AlicePriv.pem \ -signer AliceCert.pem -out mail.msg Bob: $ openssl smime -verify -in mail.msg -signer AliceCert.pem \ -CAfile CACert.pem -out recover.txt Alice 가평문 mail.msg 를서명한문서 mail.msg 를 Bob 에게보내고, Bob 은이를검증함 -sign : 전자서명을생성 -inkey <file> : 서명에사용될개인키파일 -signer <file> : 서명자의공개키인증서파일, 서명자의정보를서명에기입하기위해필요 -CAfile <file> : root certificate filename 45

인증서를이용한메시지서명및 암호화 Alice 의서명및암호화 $ openssl smime -sign -in test.txt -signer AliceCert.pem -inkey AlicePriv.pem -text -out signed.msg $ openssl smime -encrypt -in signed.msg -out sien.msg - from Alice -to Bob -subject "Sign and Encryption test" -aes128 BobCert.pem smime command : 파일서명및암호화수행명령어 -encrypt : 입력파일을암호화함, 받을사람의공개키인증서필요 -from <ID> : 메일을보낼사람의 ID 나 email address -to <ID> : 받을사람의 ID 나 email address -subject <str> : 메일의제목 -[cryptography algorithm] : 암호알고리즘 [certificate] : 받을사람의공개키인증서 ( 전자봉투작성에사용 ) 46

서명및암호화된메시지처리 Bob 의복호화및검증 $ openssl smime -decrypt -in sien.msg -out decryp.msg -recip BobCert.pem -inkey BobPriv.pem $ openssl smime -verify -in decryp.msg -out verif.txt -signer AliceCert.pem -CA file CACert.pem 관련된 smime parameter -decrypt : 복호화작업을수행할것을지시함 -recip <file> : 받는사람의공개키인증서, 자신이그메시지의수신자인지확인하기위해필요 -inkey <file> : 개인키파일, 암호화된대칭키 ( 비밀키 ) 의복호화를위해필요 47

Project P4a 난이도 : 높음 (OpenSSL 홈페이지의매뉴얼을참조해야함 ) 내용 : 작은 CA 서버와클라이언트구축. Hint : 유닉스의 system() 함수와 OpenSSL 커멘드라인명령어를이용하여구현. CA 서버가하는일 사용자프로세스가 CA 의루트인증서를요청하면그인증서를전달한다. 사용자프로세스가인증서서명신청서를제출하면이를검증하고공개키인증서를생성하여보내준다. 사용자프로세스가어떤사용자의공개키인증서를요구하면그공개키인증서를보내준다. 만약그인증서가없으면없다는답변을보낸다. 인증서를모두보관한다. 48

P4a (Cont.) 사용자프로세스가하는일은다음과같다. 사용자프로세스는사용자의정보를보관하고있으며사용자의키보드입력에따라위의작업을수행한다. 자신의공개키인증서가없으면자신의개인키와인증서서명신청서를작성하여 CA 에게신청한다. 자신의또는다른사용자의공개키인증서를신청하여받으면다음과정을통하여검증한다. 루트인증서가없으면 CA 에게요청하여받는다. 루트인증서를검증한다. 상대방의공개키인증서를검증한다. Hint : OpenSSL 커멘드라인에서 ca 명령어는 CA 서버의인증서생성과리스트관리를도와주므로 CA 서버관리를보다용이하게하는명령어임 49

Project P4b 난이도 : 매우높음 (OpenSSL 홈페이지의매뉴얼을참조해야함 ) P4a 의기능에다음을추가하시오. CA 서버의경우 : 사용자프로세스가자신의인증서유효기간보다빨리새로운인증서서명신청서를제출하면그사용자의인증서를 CRL 에넣고새로운인증서를생성하여보내준다. 사용자프로세스가 CRL 을요구하면이를보내준다. 유효한인증서와폐기된인증서를모두보관한다. 사용자프로세스의경우 : P4a 에서 3 단계의검증과정중다음을포함한다. CRL 을요청하여받은후공개키인증서가 CRL 에포함되어있는지확인한다. 50