S/MIME (Secure/Multipurpose Internet Mail Extension) - 2

S/MIME (Secure/Multipurpose Internet Mail Extension) - 1 에서는 S/MINE을 시작하기에 앞서 MINE은 어떻게 구성되어 있는지 알아보고, 마지막에 S/MINE이 어떤 것인지 알아봤다. 이제 본격적으로 S/MINE에 대해 알아보자!

 

 

S/MINE은 Secure  + MIME으로, MINE에 Signature, Encryption이 고려된 것을 말한다. S/MIME는 PKCS를 통해 Algorithm indentifier 이나 certificate 등을 처리한다. 

 

PKCS는 Message content를 통해 처리되며, MIME 형식으로 header를 통해 제공된다.

 

S/MIME Content Type

PGP에서 다뤘듯, Content Type은 중요하다! 대부분의 서비스가 Content Type을 통해 이뤄진다. 마찬가지로, encrypt등을 하게되면 Binary data가 생성되므로, 인코딩도 역시 사용된다(Base64)

 

#EnvelopedData

 

EnvelopedData는 아래와 같은 순서로 제공된다(EnvelopedData는 암호화한 데이터 정도로 해석하면 될 것 같다).

1. 대칭키 암호화(RC2/40이나 3DES)를 위한 pseudo random session key를 생성한다.
2. 수신자의 RSA public-key로 session-key를 암호화 한다(수신자는 여러명이 될 수도 있으며, 이때는 각각 수신자의 public-key로 암호화)
3. RecipientInfo block을 준비한다. RecipientInfo는 수신자의 public-key certificate에 대한 식별자와 session key를 이용하여 암호화한 Algorithm, 그리고 암호화된 session key로 이루어져있다.
4. Message content를 암호화 한다. 

pseudo random에 대해 정확한 정의를 알아봤다. pseudo는 '의사'라고 해석하며 뜻은 가짜이다. 즉 pseudo random은 의사 랜덤이라고 하는데 random에 왜 pseudo를 붙이는지 궁금했는데, 네이버 지식 백과에서 다음과 같은 글을 찾을 수 있었다. 왠지 구글에서 찾은게 아니면 죄책감이 들긴 하지만, 아래에 설명에서는 내가 궁금한 부분을 잘 설명한 것 같아 가져왔다.

 

"처음에 주어지는 초깃값을 이용하여 이미 결정되어 있는 메커니즘(의사 난수 생성기)에 의해 생성되는 수. 난수는 생성 방법이 결정되어 있지 않으며, 다음에 생성될 값을 전혀 예측할 수 없으나 의사 난수 생성기에 의해 생성되는 수는 초깃값을 알면 계산될 수도 있으므로 진짜 난수와 구별하여 의사 난수라 부른다."
[네이버 지식백과] 의사 난수 [pseudo random number, 擬似亂數] (IT용어사전, 한국정보통신기술협회)

 

 

RecipientInfo 예제

RecipientInfo를 처리하는 방법은 다음과 같은 순서로 이뤄 진다.

 

1. Base64 decoding
2. Recipient의 Private-key로 session key를 decrypt
3. (2)에서 복원한 session key로 message content decrypt

#SignedData

 

SignedData는 다음과 같은 순서로 준비된다.

1. Message Digest Algorithm을 선택한다(SHA-1과  MD5가 있다)
2. 서명할 내용을 위에서 선택한 Algorithm을 이용해 Message Digest를 계산한다.
3. (2)에서 생성한 Message Digest를 Sender의 Private-key로 암호화 한다.
4. SignerInfo block을 생성하며, SignerInfo는 Signer의 public-key certificate, message diget algorithm에 대한 identifier, message digest를 암호화 할때 사용한 algorithm(암호화한 algorithm), 암호화한 message digest 값으로 구성 되어있다.

위에서 언급한 것 처럼 SignedData는 Message Digest algorithm identifier와 signed message, 그리고 SignerInfo로 구성되어 있다. 

 

SignedData 예제 

위의 예제를 복원하려면 다음과 같은 절차를 거쳐야 한다.

 

1. Base64 decnoding
2. signer의 public-ket를 이용해 message digest를 복호화
3. 받은 메세지 내용 decrypt하고 이 내용을  message digest한 후 받은 message digest와 비교 

 

#Clear Signing

 

Clear Signing는 Message에 대한 암호를 적용하지 않아, 평문으로 전송된다.

 

만약 Recipient가 MIME는 지원하는데 S/MIME를 지원하지 않는 경우 이 메세지를 읽을 수 있다(Signing에 대한 확인을 거치지 않고, 받아들이는듯 하다, Protocol간의 호환성을 위해 사용되는 듯!).

 

multipart/signed는 두가지 부분으로 나뉘는데 첫번째는 모든 MIME의 type이 올 수 있고, 두번째는 위에서 언급했던 signedData field가 오는데, 이때 signedData field에서 content field는 아무것도 들어가지 않는다(위에서 평문으로 전송하였기 때문)

clear-signed 예제

위처럼 처음엔 평문의 메세지가 오게 되며 아래에는 그 메세지에 대한 digest의 내용이 암호화 되어 전송된다. micalg는 messaga digest를 만드는데 사용한 Algorithm을 명시하여 수신자 측에서 위의 평문 메세지와 아래 내용을 비교할 수 있도록 하였다.

 

#Registration Request

 

application/pkcs10 S/MIME entity는 certification request를 전송하는데 사용된다. 

 

certification request는 certification requestInfo 블록을포함하여, 여기에는 Public-key를 이용해 encrpytion을 한 Algorithm의 identifier(즉 public-key로 암호화 할때 쓴 알고리즘)와, Sender의 private-key로 서명한  certificationReqeustInfo block의 서명이 들어가며 certificationRequestInfo에는 certificate subject의 이름과 user의 public-key를 bit-string형태로 표현한 내용이 들어간다.

 

#Certificates-Only Message

 

registration request에 대한 응답으로 메세지에 certificate나 CRL(Certificate Revocation List)만 보낼 수 있으며, 이 메세지는 application/pkcs7-mime type/subtypsmime-type에 degenerate parameter로 보낼 수 있으며, signedData를 보낼때와 마찬가지로 보내면 되는데, signerInfo와 message content는 비워둔 상태로 보낸다.

CRL은 인증서 폐기에 대한 정보를 얻어오는 것으로, 유효성을 검사할 수 있고 인증서를 발급한 CA로 부터 정보를 얻어오는데, 주기적으로 업데이트 되어 즉시 확인되지 않을 수도 있다. 기본적으로는 인증서 만료에 대해 인증서에 있는 유효기간으로 확인이 가능하지만, 인증서의 유효기간이 유효하더라도 폐기될 수 있으므로 확인해야 한다. 발급한 CA에게 인증서에 적혀있는 URL을 검사하며, Serial number로 관리 하여 비교한다.

 

 

 

 

#S/MIME Certificate Processing

 

S/MIME은 X.509의 ver.3을 public-key certificate로 이용하며, key-management scheme로는 X.509와 PGP의 web of trust를 사용한다. S/MIME manager 또는 유저는 각 client에 대한 신뢰할 수 있는 key list나 인증서 폐기 목록에 대한 것은 Local에서 관리해야 한다.

 

X.509는 public-key와 identitiy ( hostname또는 organization, individual)을 포함하고있는 인증서이고, CA나, self-signing이 되어있다. 만약 인증서가 신뢰할수 있는 CA나 검증된 다른사람으로부터 서명된 경우, secure communicataion을 설정하거나. private-key로 서명된 document를 증명할 수 있다. 

 

Web of Trust는 PGP에서 사용하는 방식으로, 누군가가 공개키를 배포할때 MITM등의 방식으로 공개키를 다른 사용자의 것으로 바꿔치기 할 수 있는 상황을 배제할 수 없다. 이 경우 가장 안전한 방법은 직접 받는 방법인데, 직접 받을 바에야 대칭키를 이용하는게 간편하다. 이 경우 Web of Trust에서는 내가 신뢰하는 다른 사용자가 어떠한 공개키에 대해 신뢰할 수 있다고 sign한 경우 나도 그 공개키가 유효하다고 믿는 것을 말한다. 즉, 내가 믿는 사람이 맞다고하면 믿는거다! 그리고 signed된 수가 많을 수록 더욱더 신빙성이 증가 된다. 어떻게 보면 Block chain에서 비잔틴 문제를 해결한 Consensus와 비슷한 부분이 있는 것 같기도하고...

 

User Agent Role

 

• Key generation
  • 어떤 시스템에 대한 관리자들은 반드시 Diffie-Hellman과 DSS Key pair를 생성할 수 있어야 하고, RSA Key를 Generate 할 수 있어야 한다 각 key pair는 완벽한 random으로 인해 생성되어야 하고 기밀성이 유지되어야 한다. 반면 사용자는 768-1024bit의 RSA key를 generate할 수 있어야 하고, 512bit 이하의 key를 생성하면 안된다.

찾아보니 RSA 512bit는 1999년에 3년만에 6년만에 깨졌다고 한다. 그리고, 768bit 또한 3년만에 깨졌다고하니 최대한 긴 길이를 사용하자. 현재 SP 800-57에서는 2048bit나 3072bit를 권장하고 있고, 현재 1024bit는 깨지지 않았지만, 권장되진 않는 듯 하다.

• Registration
  • User의 public-key는 X.509 public-key 인증서를 받기 위해 CA에 등록을 해야함
• Certificate storage and retrieval
  • 사용자는 받은 메세지의 signature verify 및 송신시 encrypt를 위해 local에 있는 certificate 목록에 접근할 필요가 있다. 이 목록은 유저 개인이나 관리자가 대신 관리할 수 도 있다.

 

#Verisign Certificates

 

유명한 CA가 있지만 저자는 그중 Verisign에 대해 언급하고 있다. 가장 많이 쓴다고 한다. 

 

Versign은 Digital ID라는 X.509 certificate를 선보였는데, 그것에 대해 알아보자.

 

• 소유자의 Public-key
• 소유자의 이름이나 별칭
• Digital ID의 만료 기한
• Digital ID의 Serial number
• Digital ID를 발행한 CA의 이름
• Digital ID를 발행한 CA의 Digital signature

또한, optional하게 아래의 정보도 제공할 수 있다고 한다.

 

• 주소
• 이메일 주소
• 기본 등록 정보 (나라, 우편번호, 나이 ,성별 등등)

아까부터 계속 CA 및 Digital signature에 대해 등장하고 있는데, 무엇인지 알아보자.

 

CA가 등장하게 된 배경을 생각해보자. RSA의 등장으로 기존 암호화 방식인 대칭키 알고리즘에서 Key exchange의 문제가 사라졌다. 그러나 , 한가지 상황을 가정해 볼 수 있는데, 공개키를 배포할때 MITM으로 해커의 공개키를 주고 해커가 중간자 공격을 하면 어떻게 될까? 예상한 것 처럼 공개키 알고리즘의 보안과는 별개로 공격이 가능해진다. 그러면 이때 공개키에 대해 해커가 아닌 통신하고자 하는 상대방의 공개키라고 믿을 수 있을 만한 인증이 필요하다. 그 인증을 해주기 위해서는 스스로가 인증을 하거나, 신뢰할 수 있는 누군가로부터 그 공개키는 "그 사람것이 맞다."라고 보증을 해 줘야한다. 그래서  CA라고하는 인증 기관이 등장하게 되었다.

 

인증 받고자 하는 공개키(Certificate)를 해쉬를 한 후 CA에 주면, CA는 해당 공개키(Certificate)에 대해 자신의 Private-key로 암호화 하여, 인증서를 돌려준다.

 

그리고 처음 상황으로 돌아가서 A와 B가 암호화 통신을 하기 위해 공개키를 전달해야하는 상황에서 마찬가지로 악의의 사용자 C가 MITM을 시도 하려한다고 하자.

 

B가 A와 통신을 하기 위해 그냥 Public-key를 주는 대신 위에서 Sign한 인증서를 주면, A는 인증서를 받고 그 인증서를 Sign한 CA의 

공개키를 이용해 인증서를 복호화 한다. 정상적으로 복호화가 된다면 CA가 Sign한 것이라는게 인증되었다.

 

그리고 복호화한 인증서에는 공개키에 대한 Hash 값이 있는데 그 값과 인증서 들어있는 (B가 자신의 것이라고 주장하는)공개키를 Hash하여 비교한다. 값이 일치한다면, CA가 공개키에 대해 보증을 하였기 때문에 신뢰할 수 있는 공개키라고 믿을 수 있다.

 

이때 신뢰할 수 있는 CA는 기존에 알고있어야 하며, 브라우저의 경우 Static하게 브라우저 내에 저장되어 있다(브라우저 마다 신뢰할 수있는 CA가 조금씩 상이하다).

 

해커가 공격을 시도한다고 가정을 해볼때, 자신의 공개키를 인증서에 넣고 그 값을 신뢰할 수 있는 CA의 Private-key로 암호화 해야 하는데(A는 CA의 Public-key로 복호화를 시도하기 때문) 해커가 CA의 Private-key로 암호화 할 수 없기 때문에 올바른 인증서를 만들지 못한다. 

 

해커가 자신이 CA이 되어 Signed된 인증서를 발급할 수 는 있으나, 인증되었다고 해서 모두 받아들이는 것이 아니라, "신뢰할 수 있는 CA"가 서명한 인증서만이 사용하도록 하기 때문에 위에서 가정한 공격을 감행할 수 없다.

 

위의 과정에서 B의 공개키를 CA가 암호화한 값을 Digital signature라고 한다.

 

 

 

#Enhanced Security Services

 

• Signed receipts
  • SignedData form에 의해 요청할 수 있고, 메세지를 전달했다는 증거로사용할 수 있고, third part에게 recipeint가 메세지를 받았다는 것을 증명할 수 있다. .기본적으로 원본 메세지와 sender의 signatre에 자신의 서명을 추가해 새 S/MIME를 작성한다
• Security Labels
  • Security label은 SignedData의 속성 중 하나로 S/MIME에 포함된 내용에 대한 민감도를 나타낸다. 이 label은 access control에 사용되거나 priorty , rolo based등 다양한 목적으로 사용된다.
• Secure Maling lists
  • 동시에 같은 메일을 다른 사용자에게 보낼때, 각 수신자에 대한 정확한 처리가 필요하게 되며 이때  각 수신자에 대한 public-key를 포함해야 한다. 이때 S/MIME MLA(Mail List Agent)을 이용해 안정성있게 이 처리를 할 수 있으며, MLA는 하나의 메세지를 받아 각 수신자가 복호활 수 있도록 암호화 해주고, 전송해준다. 따라서 Sender는 MLA의 Public-key를 이용하여 MLA에게 메세지를 보내기만 하면 MLA가 다~ 알아서해준다! 

 

 

여기까지 작성하고 다음으론 S/MIME에 DKIM에 대해 알아보도록 하자!