4 th EDITION NETWORK SECURITY ESSENTIALS 네트워크보안에센셜
제 7 장전자메일보안 7.1 Pretty Good Privacy 7.2 S/MIME 7.3 도메인키확인메일
7.1 Pretty Good Privacy Phil Zimmermann 제작 PGP 는전자메일과파일저장응용에필요한기밀성과인증을제공 3
PGP 1. 가장쉽게얻을수있는암호알고리즘으로구성 2. 이알고리즘을범용응용프로그램안에집약 플랫폼에무관하게사용 운영체제나프로세서와무관하게사용가능 사용편리 소수명령어만가지고도쓸수있을만큼사용이용이 3. 패키지화 소스코드공개 무료제공 4. 저가상업용버전제공 업체 ( 지금은 Network Association 이된 Viacrypt) 와동의하여완벽한호환성과저렴한가격대의상업용 PGP 버전을제공 4
PGP 가널리사용되는이유 다양한플랫폼에서동작되고무료 공개적검증을거친알고리즘을기반으로하고있어서매우안전 다양한응용성 기득권에대한저항성 인터넷표준화과정에있지만기존상업용패키지와는차별화 5
기호 K s = 대칭암호구조에서사용되는세션키 PR a = 공개키암호구조에서사용되는사용자 A 의개인키 PU a = 공개키암호구조에서사용되는사용자 A 의공개키 EP = 공개키암호화 DP = 공개키복호화 EC = 대칭암호화 DC = 대칭복호화 H = 해시함수 = 이어붙여쓰기 Z = ZIP 알고리즘을이용한압축 R64 = 기수 (radix) 64 ASCII 형식으로변환 6
동작과정 5 가지서비스구성 인증 기밀성 압축 전자메일호환성 단편화 7
인증 1. 송신자가메시지를생성 2. SHA-1 으로메시지의 160- 비트해시코드생성 3. 이해시코드를송신자의개인키를이용한 RSA 로암호화하고그결과를메시지에첨부 4. 수신자는수신메시지를송신자의공개키를이용해 RSA 로복호화하여해시코드를회수 5. 수신자는메시지에대한해시코드를새로생성한다음단계 4 에서회수한해시코드와비교 만약두개가일치하면메시지를인증한것으로간주 8
PGP 서비스요약 9
PGP 암호함수 10
기밀성 대칭암호 CAST-128 을사용 대신 IDEA 나 3DES 사용가능 64- 비트 CFB 모드사용 각대칭키는오직한번만사용 각메시지마다 128- 비트새키생성 세션키라고했지만사실일회용키 세션키는메시지에붙여서함께전송 세션키보호를위해수신자의공개키로이키를암호화 11
세션키처리단계 1. 송신자는메시지를생성하고이메시지의세션키로사용할 128- 비트랜덤넘버생성 2. CAST-128( 혹은 IDEA 나 3DES) 과세션키를이용해메시지를암호화 3. 수신자의공개키를이용해서 RSA 로세션키를암호화한다음메시지에붙인다 4. 수신자는자신의개인키를이용해 RSA 로복호화해서세션키를회수 5. 수신자는세션키를이용해메시지를복호화 12
기밀성과인증 먼저평문에대한서명을생성해서메시지에첨부 평문메시지와서명을대칭암호알고리즘 CAST-128( 혹은 IDEA 나 3DES) 로암호화하고세션키는 RSA( 혹은 ElGamal) 로암호화 다시말해서 우선메시지를자신의개인키로서명 세션키로메시지를암호화 세션키를수신자의공개키로암호화 13
압축 서명후암호화하기전에메지시를압축 이렇게하면전자메일전송과파일저장에있어서저장공간을줄일수있는장점 14
서명생성을압축보다먼저하는두 가지이유 압축되지않은메시지를서명하는편을더선호 압축후에해시함수와서명을적용하면압축에사용했던알고리즘버전과똑같은알고리즘버전만이압축을풀수있게되어결국 PGP 기능을충분히활용하지못하고사용에제한을받는다 15
압축과압축풀기위치 암호적보안성을높이기위해압축을먼저하고그뒤에메시지를암호화 압축된메시지는원래평문보다중복되는비트가적기때문에암호해독을하기가더어렵다 16
전자메일호환성 PGP 를사용할때전송할블록이있다면적어도그블록의일부분을암호화해야한다 서명서비스만필요한경우 메시지다이제스트를암호화 ( 송신자의개인키로 ) 기밀성서비스가필요한경우 메시지와서명을암호화 ( 일회용대칭키로 ) 결과로나오는블록의일부혹은전체는 8- 비트옥텟 (octet) 스트림 17
기수 64 활용 많은전자메일시스템에서는오직 ASCII 문장으로이뤄진블록만사용해야하는제약 이런제약때문에 PGP 는 8- 비트 2 진스트림을인쇄용 ASCII 문자스트림으로변경하는서비스를제공 이런목적으로기수 -64(radix-64) 변환을사용 이변환을이용하면 3 개의옥텟으로이루어진 2 진데이터한세트를네개의 ASCII 문자로변환가능 18
PGP 메시지 전송 19
PGP 메시지 수신 20
단편화와재조립 전자메일최대메시지길이 : 50,000 옥텟 큰메시지는단편화 기수 64 변환이후에수행 세션키부분, 서명부분은첫번째단편의앞부분에오직한번만등장 수신자는재조립 21
암호키와키고리 4 종류의키사용 일회용세션대칭키 공개키 개인키 패스문-기반 (passphrase-based) 대칭키 22
키의 3 가지필수조건 추측불가능한세션키생성방법필요 사용자가공개키 / 개인키쌍을복수로소유 자신의공개키 / 개인키쌍보관파일필요 23
세션키생성 암호화 / 복호화알고리즘 128 비트키사용알고리즘 CAST-128 IDEA 168 비트키 3DES CAST-128 을가정하고설명 24
CAST-128 을이용한세션키생성 입력 128 비트랜덤넘버생성 랜덤넘버스트림으로작성 랜덤넘버스트림은키보드입력에의해작성 이를 2 개의 64 비트평문블록으로분리 CAST-128 입력으로사용 CFB 모드활용 출력 CAST-128 의출력인 64 비트암호문 2 개 이어붙여서 128 비트세션키생성 25
CAST-128 을이용한세션키생성 키보드입력 랜덤넘버스트림 (128 비트 ) IV 64 비트 64 비트 Key CAST-128 Key CAST-128 64 비트 64 비트 세션키 (128 비트 ) 26
키식별자 각사용자가공개키 / 개인키를단한쌍만사용한다면수신자는세션키를복호화하기위해어떤키를사용해야하는지당연히안다 복수의공개키 / 개인키를사용한다면구별방법이필요 각공개키에식별자 (identifier) 첨부 사용자 ID 와키 ID 병기 27
키식별자부여방법 한사용자의각공개키에유일하도록 ( 확률적으로보아유일할확률이아주크도록 ) 키 ID 를지정 키 ID 는그공개키의최하위 64 비트 (least significant 64bits) 로구성 공개키 PU a 의키 ID 는 (PU a mod 2 64 ) 이다. 키 ID 중복가능성이매우희박 28
일반유형 PGP 메시지 (A 에서 B 로 ) 29
서명요소 타임스탬프 (Timestamp): 서명이이루어진시점 메시지다이제스트 (Message digest): 송신자의개인서명키로암호화된 160- 비트 SHA-1 다이제스트 메시지다이제스트의맨앞의두옥텟 (Leading two octets of message digest): 인증을위해메시지다이제스트를복호화하는데정확한공개키가사용되었는지아닌지를수신자가판단가능 30
서명요소 송신자공개키의키 ID(Key ID of sender's public key): 메시지다이제스트를복호화하는데사용해야할공개키를구별하고메시지다이제스트를암호화하는데사용한개인키를구별 31
키고리 개인키고리 (private-key ring) 공개키고리 (public-key ring) 32
개인키고리 33
개인키고리필드 타임스탬프 (Timestamp): 이키쌍이생성된날짜 / 시간 키 ID(Key ID): 이항목에대한공개키의낮은 64 비트유효자리 공개키 (Public key): 키쌍의공개키부분 개인키 (Private key): 키쌍의개인키부분, 이필드는암호화 사용자 ID(User ID): 사용자전자메일주소 예를들면 stallings@acm.org 34
개인키의안전한저장 개인키를암호화할패스문 (pathphrase) 선택 시스템이 RSA 로새공개키 / 개인키쌍을생성할때, 시스템은사용자에게패스문질의. SHA-1 을이용해서패스문으로부터 160- 비트해시코드를생성하고패스문삭제 시스템은해시코드 128 비트를키로 CAST- 128 을사용해서개인키를암호화. 해시코드를삭제하고암호화된개인키를개인키고리에저장 35
개인키안전한저장절차 패스문 사용후저장하지않음 SHA-1 해시 (160 비트 ) 128 비트 개인키 CAST-128 암호화알고리즘 키 ID 와연동하여저장 암호화된개인키 개인키고리 36
개인키회수절차 패스문 개인키고리 ID 와연동하여불러오기 암호화된개인키 SHA-1 해시 (160 비트 ) CAST-128 복호화알고리즘 128 비트 키 개인키 37
개인키회수방법 패스문입력 암호화된키회수 패스문의해시코드생성 이해시코드와 CAST-128 을이용해암호화되개인키를복호화 38
공개키고리 39
공개키고리필드 타임스탬프 (Timestamp): 이항목이생성된날짜 / 시간 키 ID(Key ID): 이항목에대한공개키의 64 비트유효자리 공개키 (Public key): 이항목의공개키 사용자 ID(User ID): 이키소유자를식별 여러개의사용자 ID 가하나의공개키에연결 40
PGP 메시지생성 (A 가 B 에게전송 ) 41
송신자의메시지처리단계 1. 메시지서명 (Signing the message) a. PGP 는 your_userid 를목록으로이용해서송신자의개인키를개인키고리로부터회수 b. PGP 는평문개인키를구하기위해사용자에게패스문을입력을요구 c. 메시지의서명요소가구성 2. 메시지암호화 (Encrypting the message) a. PGP 는세션키를생성하여메시지를암호화 b. PGP 는 her_userid 를목록으로이용해서수신자의공개키를공개키고리로부터회수 c. 메시지의세션키요소가구성 42
PGP 메시지복구 (B 의절차 ) 43
수신자의암호문처리단계 1. 메시지복호화 (Decrypting the message) a. PGP는메시지의세션키요소에있는키 ID 필드를목록으로수신자의개인키를개인키고리로부터회수 b. PGP는암호화되지않은개인키를구하기위해사용에게프롬프트를주어사용자로하여금패스문입력요구 c. PGP는그후세션키를회수하여메시지를복호화 2. 메시지인증 (Authenticating the message) a. PGP는메시지의서명키요소에있는키 ID를목록으로송신자의공개키를공개키고리로부터회수 b. PGP는전송된메시지다이제스트를회수 c. PGP는수신된메시지에대한메시지다이제스트를계산하고, 그것을수신된메시지다이제스트와비교하여인증 44
공개키관리 올바른공개키획득방법이중요한문제 45
공개키관리방법 공개키획득방법 물리적전달 전화이용방법 신뢰하는제 3자활용 신뢰하는인증기관활용 ( 인증서활용 ) 46
신뢰이용 특별한규칙은없음 신뢰를이용 신뢰와공개키를연관 신뢰정보를이용 신뢰플래그바이트 (trust flag byte) 구조활용 키합법성필드 (key legitimacy field) 서명신뢰필드 (signature trust field) 소유자신뢰필드 (owner trust field) 47
공개키고리항목 키합법성필드 (key legitimacy field) PGP 가해당사용자의확실한공개키라고신뢰하는정도 이필드는 PGP 가계산 이항목에키고리소유자가수집한서명을연관시킨다 없을수도있고이인증서서명에사용된여러개가될수도있음 필드값 모름또는정의되지않음 (unknown or undefined trust) 키소유신뢰안함 (key ownership not trusted) 키소유부분신뢰 (marginal trust in key ownership) 키소유완전신뢰 (complete trust in key ownership) 48
공개키고리항목 서명신뢰필드 (signature trust field) 이 PGP 사용자가공개키를인증하기위해서명자를신뢰하는정도 항목안의서명신뢰필드집합에의해키합법성필드가만들어짐 49
공개키고리항목 소유자신뢰필드 (owner trust field) 다른공개키인증서를서명하기위해이공개키가신뢰되는정도 이신뢰정도는사용자가결정 서명신뢰필드는다른항목에속한소유자신뢰필드의저장된복사본 50
소유자신뢰필드값설정방법 A 가 i 의공개키를자신의공개키고리에추가할때, PGP 는이공개키의소유자신뢰필드 (owner trust field) 에다음절차에따라값 (trust_flag i ) 을부여 소유자가 A 자신일때 (i=a) 신뢰필드자동적으로다음값부여 최우수신뢰 (ultimate trust): this key is present in secret key ring 소유자가 A 가아니고다른소유자일때 (i A) PGP 는 A 에게이공개키의소유자에게어떤값을부여할지질의 A 는적정레벨을입력, 소유자에대해다음중하나선택 정의되지않음 (undefined trust) 모름 (unknown): unknown user 신뢰안함 (untrusted): usually not trusted to sign other keys 부분적신뢰 (marginally trusted): usually trusted to sign other keys 완전신뢰 (completely trusted): always trusted to sign other keys 51
서명신뢰필드값설정방법 새공개키추가시여러개의서명이그공개키에붙어있을수있다 새공개키에서명한서명자를자신의공개키안에존재하는지확인한뒤서명신뢰필드 (signature trust field) 에다음값을부여 존재할경우 해당소유자의 owner trust field 의값을부여 존재하지않을경우 모르는사용자 (unknown) 값을부여 52
키합법성필드값설정방법 키합법성필드의값계산 서명신뢰필드 (signature trust field) 를기초로작성 적어도한개서명이서명신뢰값으로최우수신뢰 (ultimate trust) 를가지고있을경우 완전신뢰로설정 기타경우 신뢰값의가중합 (weighted sum) 으로설정 53
신뢰값가중합계산방법 완전신뢰 =1/X 부분신뢰 =1/Y X 와 Y 는사용자가조절하는매개변수 키 / 사용자 ID 조합을소개한소개자의총가중치가 1 이되면키합법성값을완전신뢰로세팅 서명중절대신뢰가없는경우 적어도 X 개의완전신뢰서명필요 Y 개의부분신뢰서명필요 혹은이두종류의합이 1 이되게하는서명조합필요 54
PGP 신뢰모델예 55
신뢰모델예에따른공개키고리 가중합 > ¼ 일경우에합법적으로판정 가중합계산예 : 완전신뢰 = 1/X=1/2, 부분신뢰 =1/Y=1/4 타임스탬프 키 ID 공개키소유자신뢰사용자 ID 키합법성 PU A 부분신뢰 A PU B 부분신뢰 B PU C 신뢰안함 C PU D 완전신뢰 D PU E 완전신뢰 E PU F 완전신뢰 F PU G 신뢰안함 G PU H 신뢰안함 H PU I 신뢰안함 I 완전신뢰 ( 합법적 ) 완전신뢰 ( 합법적 ) 완전신뢰 ( 합법적 ) 완전신뢰 ( 합법적 ) 완전신뢰 ( 합법적 ) 완전신뢰 ( 합법적 ) 신뢰안함 ( 합법적이지않음 ) 완전신뢰 ( 합법적 ) 신뢰안함 ( 합법적이지않음 ) 가중합 서명 E[PR You, PU A ] E[PR You, PU B ] E[PR You, PU C ] E[PR You, PU D ] E[PR You, PU E ] E[PR F, PU E ] E[PR You, PU F ] E[PR?, PU F ] 서명신뢰 ( 서명자에대한신뢰 ) 최우수신뢰 최우수신뢰 최우수신뢰 최우수신뢰 최우수신뢰 완전신뢰 최우수신뢰 모름 1/4 E[PR A, PU G ] 부분신뢰 0 E[PR?, PU G ] 모름 1/4 E[PR A, PU H ] 부분신뢰 1/4 E[PR B, PU H ] 부분신뢰 0 E[PR?, PU I ] 모름 0 E[PR C, PU I ] 신뢰안함 56
신뢰모델예에따른공개키고리 가중합 > ¼ 일경우에합법적으로판정 가중합계산예 : 완전신뢰 = 1/X=1/2, 부분신뢰 =1/Y=1/4 타임스탬프 키 ID 공개키소유자신뢰사용자 ID 키합법성 PU J 신뢰안함 J PU K 신뢰안함 K PU L 완전신뢰 L PU M 신뢰안함 M PU N 신뢰안함 N PU O 신뢰안함 O 신뢰안함 ( 합법적이지않음 ) 신뢰안함 ( 합법적이지않음 ) 부분신뢰 ( 합법적 ) 부분신뢰 ( 합법적 ) 부분신뢰 ( 합법적 ) 부분신뢰 ( 합법적 ) 가중합 서명 서명신뢰 ( 서명자에대한신뢰 ) 0 E[PR C, PU J ] 신뢰안함 0 E[PR C, PU K ] 신뢰안함 1/2 E[PR D, PU L ] 완전신뢰 1/2 E[PR E, PU M ] 완전신뢰 1/2 E[PR E, PU N ] 완전신뢰 1/2 E[PR E, PU O ] 완전신뢰 57
신뢰모델예에따른공개키고리 가중합 > ¼ 일경우에합법적으로판정 가중합계산예 : 완전신뢰 = 1/X=1/2, 부분신뢰 =1/Y=1/4 타임스탬프 키 ID 공개키소유자신뢰사용자 ID 키합법성 PU P 신뢰안함 P PU Q 신뢰안함 Q PU R 신뢰안함 R PU S 신뢰안함 S 부분신뢰 ( 합법적 ) 부분신뢰 ( 합법적 ) 신뢰안함 ( 합법적이지않음 ) 모름 ( 합법적이지않음 ) 가중합 서명 서명신뢰 ( 서명자에대한신뢰 ) 0 E[PR J, PU P ] 신뢰안함 1/2 E[PR L, PU P ] 완전신뢰 1/2 E[PR L, PU Q ] 완전신뢰 0 E[PR M, PU Q ] 신뢰안함 0 E[PR N, PU R ] 신뢰안함 0 E[PR?, PU R ] 모름 0 E[PR?, PU R ] 모름 0 E[PR?, PU S ] 모름 0 E[PR?, PU S ] 모름 58
You 공개키 / 사용자 ID/ 서명트리구조 Bob Cathy Dan Eve Fred? 사용자 ID 색키합법성 Alice@dju.kr 합법적이아님 Alice Alice@dream.uk A@netbook.com 합법적 합법적이아님 타임스탬프 키 ID 공개키 소유자신뢰 사용자 ID 키합법성 가중합 서명 서명신뢰 ( 서명자에대한신뢰 ) Alice@dju.kr 합법적이아님 0 E[PR Bob, PU Alice ] 신뢰안함 1/4 E[PR Eve, PU Alice ] 부분신뢰 PU Alice 신뢰안함 Alice@dream.uk 합법적 0 E[PR Bob, PU Alice ] 신뢰안함 1/2 E[PR Cathy, PU Alice ] 완전신뢰 0 E[PR?, PU Alice ] 완전신뢰 A@netbook.com 합법적이아님 1/4 E[PR Fred, PU Alice ] 부분신뢰 0 E[PR Dan, PU Alice ] 모름 59
공개키 / 사용자 ID/ You 서명트리구조 Bob Cathy Dan Eve Fred? Alice 사용자 ID 색 키합법성 Alice@dju.kr 합법적이아님 1/4 Alice@dream.uk 합법적 1/2 A@netbook.com 합법적이아님 1/4 합법적이라고판단한다. 왜냐하면 1 4 + 1 2 + 1 4 3 = 1 3 > 1 4 60
공개키취소 소유자가자신이서명한키취소인증서 (key revocation certificate) 를발행 공개키취소를위한인증서는취소하려는공개키의쌍인개인키를이용해서서명 61
7.2 S/MIME S/MIME(Secure/Multipurpose Internet Mail Extension) RSA 데이터보안 (RSA Data Security) 기술을이용해 MIME 인터넷전자메일형식표준을보안적으로강화시킨것 우선 MIME 에대한이해가필요 62
RFC 5322 RFC 5322 일반적으로사용되는전통적인전자메일형식표준 메시지구성 봉투 (envelope) 내용 (content) 수신자에게배달될객체 (object) 63
메시지구성 헤더 (header) 키워드 송신자 (From), 수신자 (To), 제목 (Subject), 데이터 (Data) 콜론 키워드내용 본문 (body) 헤더와본문사이는한줄을뗀다 메시지는 ASCII 문서 첫번째빈줄위의줄은모두헤더로서이줄은메일시스템의사용자에이전트 (user agent) 가사용 64
메시지의예 Date: October 8, 2009 2 : 15 : 49 PM EDT From: "William Stallings" <ws@shore.net> Subject: The Syntax in RFC 5322 To: Smith@Other-host.com Cc: Jones@Yet-Another-Host.com 헤더 (header) Hello. This section begins the actual message body, which is delimited from the message heading by a blank line. 본문 (body) 65
MIME MIME(Mulipurpose Internet Mail Extensions) SMTP(Simple Mail Transfer Protocol) 혹은다른메일전송프로토콜과전자메일용 RFC 821 을사용하는데나타난문제점과제약을중점적으로다룬 RFC 5322 구조를확장한것 66
MIME 의한계 SMTP 는실행파일이나 2 진데이터를전송하지못함 SMTP 는국제언어문자를포함하는문서데이터를전송하지못함 SMTP 서버는특정크기이상되는메일메시지를처리하지못하고거부 67
MIME 의한계 ASCII 와문자코드 EBCDIC 를전환해주는 SMTP 게이트웨이는전환시문제발생 X.400 전자메일네트워크로연결되는 SMTP 게이트웨이는 X.400 메시지에포함되는비문서데이터 (nontextual data) 를다루지못함 어떤 SMTP 구현은 RFC 821 에정의된 SMTP 표준에완벽하게작동하지못함 68
MIME 개요 5 개의새로운메시지헤더필드정의 RFC 5322 헤더에포함 메시지본문에대한정보제공 여러내용형식이정의 멀티미디어전자메일을지원하는표현을표준화 전송부호화를정의 임의의내용형식을메일시스템이수정하지못하는형태로전환가능 69
5 가지헤더필드 MIME- 버전 (MIME-Version): 내용 - 유형 (Content-Type): 내용 - 전송 - 부호화 (Content-Transfer- Encoding): 내용 -ID(Content-ID): 내용 - 설명 (Content-Description): 70
MIME 내용유형 멀티미디어환경에서아주다양한정보표현을다루는표준필요 (7 가지유형 ) 71
MIME 내용유형 72
간단한멀티파트메시지의예 From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary This is the preamble. It is to be ignored, though it is a handy place for mail composers to include an explanatory note to non- MIME conformant readers. --simple boundary This is implicitly typed plain ASCII text. It does NOT end with a linebreak. --simple boundary Content-type: text/plain; charset=us-ascii This is explicitly typed plain ASCII text. It DOES end with a linebreak. --simple boundary-- This is the epilogue. It is also to be ignored. 73
멀티파트 4 가지서브유형 멀티파트 / 혼합서브유형 (multipart/mixed subtype) 멀티파트 / 병렬서브유형 (multipart/parallel subtype) 멀티파트 / 대체서브유형 (multipart/alternative subtype) 멀티파트 / 다이제스트서브유형 (multipart/digest subtype) 74
멀티파트 / 대체서브유형예 From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii 동일한정보를다른방법으로표현한것... plain text version of message goes here... --boundary42 Content-Type: text/enriched... RFC 1896 text/enriched version of same message goes here... --boundary42-- 75
메시지유형 (message type) 메시지 / 부분서브유형 (message/partial subtype) 메시지 / 외부 - 본문서브유형 (message/external-body subtype) 응용유형 (application type) 76
MIME 전송부호화 메시지본문에대한전송부호화를정의 전송부호화의목적 광범위한네트워크환경에서신뢰성있는전달 두가지데이터부호방법 인용 - 인쇄 (quoted printable) 기수 64(base64) 77
내용 - 전송 - 부호화필드값 78
인용 - 인쇄 (quoted-printable) 전송 부호화 대부분의데이터가인쇄할수있는 ASCII 문자에대응되는옥텟으로구성된경우적합 안전하지않은문자를그문자에해당되는부호의 16 진법표기로나타낸다 메시지행을 76 개의문자로제한하기위해되돌릴수있는 (reversible) 행나눔 (line break) 기능을제공 79
base64 전송부호화 기수 -64 부호화 일반적으로임의의 2 진데이터를부호화하는데사용하는방법 이방법으로부호화를하면메일전송프로그램이부호화처리를할때발생할수있는데이터변경에매우강함 PGP 에서도사용 80
멀티파트의예 이메시지는직렬로된다섯개의파트로구성 시작평문파트 시작평문파트 하나의내장된멀티파트메시지 하나의리치문 (richtext) 파트 하나의비 -ASCII 문서집합으로된종료캡슐화문서메시지 81
멀티파트의예 (1/2) MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1...some text appears here... [Note that the preceding blank line means no header fields were given and this is text, with US ASCII. It could have been done been done with explicit typing as in the next part.] --unique-boundary-1 Content-type: text/plain; charset=us-ascii This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts. --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64...base64-encoded 8000 Hz single-channel mu-law-format audio data goes here... 82
멀티파트의예 (2/2) --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64...base64-encoded images data goes here... --unique-boundary-2-- --unique-boundary-1 Content-Type: text/enriched This is <bold><italic>richtext.</italic></bold><smaller>as defined in RFC 1896</smaller> Isn't it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (adderss in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=iso-8859-1 Content-Transfer-Encoding: Quoted-printable...Additional text in ISO-8859-1 goes here... --unique-boundary-1 83
정규형식 정규형식 (Canonical form) 시스템사이에사용하기위해표준화된형식으로서내용유형에적합 기본형식 (native form) 과대조적 84
기본형식과정규형식 85
S/MIME 기능 S/MIME 은 PGP 와매우유사 두가지다메시지를서명하고암호화하는기능을제공 86
기능 봉함된데이터 (Enveloped data): 서명된데이터 (Signed data): 명문 - 서명데이터 (Clear-signed data): 서명되고봉함된데이터 (Signed and enveloped data): 87
암호알고리즘 S/MIME 에서사용하는암호알고리즘 (Cryptographic Algorithm) MUST: 필수 SHOULD: 권장 88
S/MIME 메시지 S/MIME 은표 7.7 에나타난여러가지새로운 MIME 내용유형을이용 모든새로운응용유형은 RSA 연구소에서제시 S/MIME 용으로만든공개키암호명세 (PKCS: public-key cryptography specifications) 라고하는지정된 PKCS 를사용 89
MIME 개체보호 S/MIME 은서명, 암호혹은두가지를모두이용해서 MIME 개체 (MIME entity) 를안전하게한다 MIME 개체는다음을의미 메시지전체 메시지의한개혹은여러서브파트 (subpart) MIME 내용유형이멀티파트인경우 90
MIME 개체보호절차 MIME 개체준비 MIME 개체와보안에관계된데이터 ( 알고리즘식별자와서명 ) 를합하고 S/MIME 으로처리하여 PKCS 객체라고알려진것을만들어낸다 PKCS 객체는메시지내용으로간주되고 MIME 에의해포장 적절한 MIME 헤더붙이기 91
MIME 개체보호절차 전송될메시지는정규형식으로변환 전송부호화실행 일반적으로 base64 로 92
S/MIME 내용유형 봉함데이터 서명데이터 명문서명 등록요청 인증서용메시지 93
봉함데이터 봉함데이터 (envelopeddata) MIME 개체준비 1. 특정대칭암호알고리즘 (RC2/40 이나 3DES) 에서사용할의사랜덤 (pseudorandom) 세션키를생성 2. 각수신자를위해수신자의 RSA 공개키로세션키를암호화 3. 각수신자를위해수신자정보 (RecipientInfo) 라고알려진블록을준비 수신자의공개키인증서식별자 세션키암호에사용된알고리즘식별자 암호화된세션키 4. 세션키로메시지내용을암호화 94
봉함데이터 5. 암호화된내용을수신자정보뒤에첨부 6. 수신자정보는 base64로부호화 메시지예 : Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m rfvbnj756tbbghyhhhuujhjhjh77n8hhgt9hg4vqpfyf467ghigfhfyt6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8hhgtrfvhjhjh776tbb9hg4vqbnj7567ghigfhfyt6ghyhhhuujpfyf4 0GhIGfHfQbnj756YT64V 95
봉함데이터복호화 수신자는우선 base64 부호화처리 수신자의개인키로세션키를회수 세션키를이용해서메시지내용을복구 96
서명데이터 서명데이터 (signeddata) MIME 개체준비 1. 메시지다이제스트알고리즘을선택 (SHA 혹은 MD5). 2. 서명될내용의메시지다이제스트나해시함수값을계산 3. 서명자의개인키를이용해서메시지다이제스트를암호화 4. 서명자정보 (SignerInfo) 라고알려진블록을준비 서명자의공개키인증서 메시지다이제스트알고리즘식별자 메시지다이제스트암호화에사용한알고리즘식별자 암호화된메시지다이제스트 97
서명데이터예 Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfyT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75 98
서명된메시지복호화와서명확인 수신자는우선 base64 부호화를처리 서명자의공개키를이용해메시지다이제스트를복호화 서명확인을위해독립적으로메시지다이제스트를계산하고그것을복호화한메시지다이제스트와비교 99
명문서명 명문서명 (clear signing) 은서명된서브유형을갖는멀티파트내용유형을사용하여얻을수있다 서명될메시지를변환하지않는다 MIME 기능은있지만 S/MIME 기능이없는수신자도수신메시지를읽어볼수있다 100
멀티파트 / 서명메시지구성 첫째파트 모든 MIME 유형가능 송신자로부터전송되는도중에변경되지않아야함 7 비트유형이아니면 base64 나인용인쇄로부호화 서명데이터처리와동일하게처리 메시지내용필드가비어있는서명데이터형식의개체생성 이객체는별도서명 Base64 로부호화 두번째파트 MIME 내용유형의응용과서브유형 pkcs7-signature 101
예 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. 사용된메시지다이제스트유형을나타냄 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyhhhuujhjhjh77n8hhgtrfvbnj756tbb9hg4vqpfyf467ghigfhfyt6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrvvbnj n8hhgtrfvhjhjh776tbb9hg4vqbnj7567ghigfhfyt6ghyhhhuujpfyf4 7GhIGfHfYT64VQbnj756 --boundary42-- 두파트명문서명을나타냄 102
서명확인방법 수신자는첫번째파트의메시지다이제스트를택해그것을두번째파트의서명으로부터회수한메시지다이제스트와비교하여서명을확인한다 103
등록요청 응용프로그램이나사용자가공개키인증서를인증기관에요청 application/pkcs10 S/MIME 개체를이용해서인증서요청을전송 인증서요청에포함되는사항 인증서요청정보 (certificationrequestinfo) 블록 인증서주체 ( 인증될공개키의소유자 ) 의이름 사용자의공개키비트열 공개키암호알고리즘식별자 송신자의개인키로서명된인증서요청정보블록의서명 104
인증서용메시지 등록요청의응답 오직인증서만포함된메시지 오직인증서취소목록 (CRL: certificate revocation list) 만을가지고있는메시지 응답메시지는초기상태 (degenerate) 의 smime-type 매개변수를가진 application/pkcs7-mime type/subtype 이다 이단계에서서명데이터메시지를만드는것과동일한방법으로처리 105
S/MIME 인증서처리 S/MIME 은 X.509 버전 3 규정을준수하여공개키인증서활용 키관리시스템 X.509 원래의인증서계층구조와 PGP 의웹형태신뢰구조를혼합한형태 S/MIME 관리자와사용자는각클라이언트에게신뢰할수있는키목록과인증서취소목록을제공하여클라이언트를구성 106
사용자에이전트역할 S/MIME 사용자가수행할키관리기능 키생성 (Key generation): 등록 (Registration): 인증서저장과검색 (Certificate storage and retrieval): 107
베리사인인증서 베리사인은 S/MIME 와다양한다른응용프로그램과호환되도록하는 CA 서비스를제공 베리사인은제품이름베리사인 Digital ID 와함께 X.509 인증서를발행 108
디지털 ID 에포함되는내용 소유자의공개키 소유자의이름혹은별칭 (alias) 디지털 ID 의만료일자 디지털 ID 의순서번호 디지털 ID 를발행한인증기관의이름 디지털 ID 를발행한인증기관의디지털서명 추가로사용자가제공하는정보 주소 전자메일주소 기본적등록정보 ( 국가, 우편번호, 나이그리고성별 ) 109
베리사인공개키인증서보안레벨 클래스 1 과클래스 2 는온라인으로처리 처리절차 클래스 1 PIN 과디지털 ID 를찾는정보를신청자가보낸전자메일주소로보내사용자의전자메일주소를확인 110
베리사인공개키인증서보안레벨 처리절차 클래스 2 클래스 1 디지털 ID 와연관된것을검사 고객데이터베이스와자동화된비교를통해신청서의정보를확인 최종적으로사용자에게디지털 ID 가사용자의이름으로발행되었다는사실을알려주는확인정보를신청자가보내온우편주소로보낸다 111
베리사인공개키인증서보안레벨 처리절차 클래스 3 엄격한수준의신원확인을요구 개인은자신의신분을공증한신용장을제공하여신청하거나본인이직접찾아가서신청해야만한다. 112
VeriSign 공개키인증서클래스 113
VeriSign 공개키인증서클래스 114
강화된보안서비스 서명된수령증 (Signed receipts): 보안레이블 (Security labels): 안전한우편목록 (Secure mailing lists): 115
7.3 도메인키확인메일 도메인키확인메일 (DKIM: DomainKeys Identified Mail) 암호학적으로서명한전자우편메시지를위한명세 서명도메인 (signing domain) 이메일스트림에서메시지에대한책임을주장할수있게한다 메시지수신자는적절한공개키를검색하기위해서명자의도메인에직접질의하여서명을검증할수있다 서명도메인에대한개인키를소유한개체에의해서메시지가인증되었다는것을확인할수있다 116
인터넷메일구조 사용자영역 메시지사용자에이전트 (MUA: Message User Agent) 형태 전송영역 메시지처리서비스 (MHS: Message Handing Service) 형태 117
MHS 메시지전송에이전트 (MTA: Message Transfer Agent) 로구성 한사용자로부터메시지를받아들여서한명이상의다른사용자에게가상의 MUA-to- MUA 교환환경을만들어메시지를전달 3 가지유형의상호운용성 사용자간의직접상호운용 MUA 와 MHS 사이의상호운용 MTSdyth 간의상호운용 118
인터넷메일구조의핵심요소 메시지사용자에이전트 (MUA): 메일제출에이전트 (MSA: Mail Submission Agent): 메시지전송에이전트 (MTA): 메일배달에이전트 (MDA: Mail Delivery Agent): 메시지저장소 (MS: Message Store): 119
인터넷기능모듈및표준프로토콜 120
추가개념 2 가지 ADMD(Administrative Management Domain) 인터넷전자우편제공자 로컬우편중계 (MTA) 를운용하는부서 기업우편중계를운용하는 IT 부서 공공공유전자우편서비스를운용하는 ISP DNS(Domain Name System) 인터넷에서호스트의이름과수치주소간에매핑을제공하는디렉터리검사서비스 121
전자메일위협 잠재적공격자의특징, 능력, 위치관점에서 DKIM 에의해다루어져야하는위협 122
공격자의특징 공격자의 3 가지위협수준 가장낮은수준 수신자가원하지않는전자우편을전송하길원하는공격자 중간수준 대량의스팸메일을발송하는전문적인송신자 교묘한수준 금전적인사취를위한메시지송신자 전자우편기반의사기수법을통해금전적이익을얻으려고하는공격자 123
공격자의능력 1. 인터넷상의여러곳에있는 MTA와 MSA에게메시지전송 2. 메일링리스트, 재송신자, 다른우편에이전트로위장하는것을포함하여, 임의의메시지헤더필드를구성 3. 공격자통제하의도메인을대신하여메시지에서명 4. 서비스거부공격에사용될수있는서명되지않거나분명히서명된메시지를다수생성 5. 도메인에의해이전에서명되었던메시지를재전송 6. 원했던봉인정보를사용하여메시지를전송 7. 손상된컴퓨터로부터의메시지에대해인가된제출자인것처럼행동 124
공격자의능력 8. IP 라우팅을조작 특정 IP 주소또는추적하기어려운주소에서온메시지를보내기위해, 또는특정도메인으로가는메시지가전달되도록하는데사용 9. 캐시포이즈닝 (cache poisoning) 과같은메커니즘을이용하여 DNS 의일부분에제한된영향을준다. 이것은메시지라우팅에영향을주거나또는 DNS 기반키나서명의광고를위조하기위해사용될수있다. 10. 중요한컴퓨팅자원에접근한다. 예를들면, 웜바이러스에감염된 좀비 컴퓨터를모아 나쁜행위자 (bad actor) 가다양한유형의전수공격을수행 11. ( 아마무선네트워크에서 ) 기존트래픽도청능력 125
공격자의위치 외부의공격자는대부분수신측 MTA 가임의의위치에서로컬도메인으로오는메시지를받아들이는전자우편의 any-to-any" 특성을이용 서명이없는부정확한서명을가지거나, 거의추적가능성이없는도메인으로부터정확한서명을가진메시지를생성 메일링리스트, 인사카드, 또는다른개체대신메시지를합법적으로송신또는재송신하는다른에이전트로위장 126
DKIM 전략 사용자의전자우편메시지는전자우편발신지관리도메인의개인키로서명 서명은메시지의내용전체와 RFC 5322 메시지헤더의일부를포함 수신측에서 MDA 는 DNS 를통해해당공개키에접근하여서명을검증 127
DKIM 개발근거 1. S/MIME 은 S/MIME 을사용하는송신사용자와수신사용자모드에의존 거의모든사용자에대해, 수신되는메시징의대부분은 S/MIME 을사용하지않음 사용자가전송하기원하는메시지의대부분은 S/MIME 을사용하지않는수신자에게전송 2. S/MIME 은메시지내용만을서명 출처에관련된 RFC 5322 헤더정보손상가능 128
DKIM 개발근거 3. DKIM 은클라이언트프로그램 (MUA) 에구현되지않음 사용자에게투명 사용자는추가적인다른동작을할필요없음 4. DKIM 은협력도메인으로부터의모든우편에적용 5. DKIM 은착한송신자가특정메시지를전송하지않았다는것을증명할수있게하고위조범이착한송신자로가장하는것을방지할수있게한다. 129
DKIM 배치의간단한예 130
DKIM 기능흐름 기본메시지처리 서명 서명 ADMA 내모듈로수행 키저장소의개인정보사용 발신 ADMD 내에서 MUA, MDA, MTA로기능 검증 검증 ADMA 내모듈로수행 전달 ADMD 내에서 MTA, MDA, MUA로기능 키저장소의공개공보사용 131
DKIM 기능 흐름도 132
Dkim-Signature 헤더정보예 Dkim-Signature: v=1; a=rsa=sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mimeversion:recei ved:date:messageid:subject :from:to:content-type:con tent-transfer-encoding; bh=5mzvqdycruylb1y28k4zgs2mpoemftodbgvbj 7GO90s=; b=pcuvpsdygb4ya5dyj1rbzgp/vyriscuaz7ttgj5qw5 slm+klv6kcfydgdhzevjw+z FetuPfH1ETOVhELtwH0zjScc0yPkEibl0f6gILObm3DDR m3ys1/fvrbhvola+/jh9aei uiiw/5ifnrbsh6qpdvv/bedqqawqfa/wf705k= 133
서명필드 v = DKIM 버전 a = 서명생성을위해사용된알고리즘 rsa-sha1 또는 rsa-sha256 중의하나 c = 헤더와 Body 에사용된정규화방법 d = 사람또는조직의신분을나타내는식별자로사용되는도메인이름. DKIM 에서는 SDID(signing Domain IDentifier) 라고함. 앞의예에서이필드는송신자가 gmail 주소를사용하고있음 s = 동일서명도메인에대해다양한상황에서다른키가사용될수있도록 DKIM 은선택자를정의. 이것은서명검증과정에서검증자가적절한키를검색하기위해사용 h = 서명된헤더필드. 서명알고리즘에제시된헤더필드를식별하는콜론 (:) 으로구분된헤더필드이름리스트. 앞의예에서서명은 domainkey-signature 필드를포함. bh = 메시지의정규화된 Body 부분의해시. 이것은서명검증실패를진단하기위해추가적인정보를제공 b = base64 형식의서명데이터. 이것은암호화된해시코드. 134