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

S/MIME은 RSA Data Security의 기술을 이용해  MIME의 Internet e-mail format stanard의 보안을 증가시키기 위해 고안되었다.

 

S/MIME은 RFCs 3370, 3850, 3851, 3852에 정의되어 있다. S/MINE을 이해하기 위해서는 MIME이라고 불리는 e-mail format에 대한 이해가 필요하다. 

 

MIME을 이해하기 위해서는 아직도 종종 사용되는 RFC 822부터 살펴볼 필요가 있다. 

 

RFC 5322는 가장 최신 버전의 Internet Message Format에 대해 설명하고 있다.

 

 

# RFC 5322

 

RFC 5322는 e-mail의 text message 에 대한 format을 정의하고 있다. 여기서 Message는 envelope와 contents로 나눠지고, envelope는 mail이 전송될 정보를 담고 있으며,  contents는 recipient에게 전달 될 내용으로 구성되어있다.

 

RFC 5322에서는 Contents만 다루고 있으나, 이 표준에는 envelope를 만드는데 필요한 header field set을 포함하고 있으며,  이 문서에서는 Message를 Header와 body부분으로 나누며, 둘의 구분은 blank line(빈줄)으로 한다.

 

Contents는 ASCII Text이고, 첫번째 blank line이 등장할때 까지의 모든 line은 Header로 간주한다. 

 

Header는 keyword와,  keyword에 대한 arguments로 이루어져 있으며 ':' 으로 구분된다. 

 

가장 자주 사용되는 키워드는 From, To, Subject와 Date이며, 아래에 Header의 예시가 있다.

 

 	 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
         
         Hello. This section begins the actual
         message body, which is delimited from the
         message heading by a blank line.

또한, Message-ID에 대한 field도 header에서 자주 볼 수 있는데, 이것은 message에 대한 unique identifier라고 한다.

 

MIME은 RFC 821에 정의된 SMTP(Simple Mail Transfer Protocol) 또는 다른 mail transfer protocol과 RFC 5322 e-mail 대한 문제를 해결하기 위한 것이다.

 

[PARZ06]에는 SMTP/5322 에 관한 제한 사항이 있다.

 

1. SMTP는 실행가능한 파일(exe)이나 binary object를 보낼 수 없다.  따라서, Binary file을 text형태로 바꾸기 위해 여러가지 schemes(UNIX UUencode / UUdecode 등)를 사용하고 있으나, 이러한 Schemes은 표준이 아니다. 

 

2.  SMTP는 다른 국가의 언어를 보낼 수 없다. 왜냐하면, SMTP는 7-bit의 ASCII로 표현을 하기 때문

 

3. SMTP의 server는 size를 넘는 경우 메일을 reject 한다.

 

4. ASCII와 EBCDIC을 변환하는 SMTP의 gateway가 일괄된 mapping set을 사용하지 않아 변환문제가 발생한다.

 

5. SMTP X.400 gateways는 nontextual data를 처리할 수 없다. 

 

6. SMTP의 RFC 821에 정의되어있는 standard를 정확히 구현하지 않아 생기는 문제가 있다:

• carriage return 및 line feed의 삭제, 추가, 재정렬에 대한 문제
• 76자 이상에 대한 잘림 문제
• tab과 space에 대한 white space 제거 문제
• 같은 메세지 길이에 대한 line padding 문제
• tab과 여러개의 space에 대한 변환 문제 

MIME의 spec

1. RFC 5322 header를 포함해서 body에 대한 정보를 제공하는 5개의 새로운 header field가 추가 되었으며, MIME-Version, Content-Type, Content-Transfer-Encoding field는 무조건 포함해야 하며 Content-ID와 Content-Description field는 선택적으로 추가할 수 있다(필수적이지 않다).

• MIME-Version : 값으로는 1.0을 가져야 하며, RFC 2045 2046를 따르는 것을 나타낸다.
• Content-Type : body가 포함하는 data에 대해 수신시에 데이터를 표현하거나 적절한 방식으로 처리할 수 있는 세부 정보를 포함하는field, 이며 boundary도 여기에 포함
• Content-Transfer-Encoding : body에서 사용하는 encoding이나 charset을 표시함
• Content-ID: MIME의 entity를 식별하는데 사용되는 고유 id
• Content-Description: audio data와 같은 body에 대한 object 설명으로 object가 읽을 수 없을 때 유용

2. multimedia 표현을 표준화 하는 몇가지 content format이 정의 되었다.

3. 어떤 content format과도 변환할 수 있도록 전송 인코딩이 정의 되었다.

 

 

# MIME Content Type

 

MIME의 specificationd은 대부분 다양한 형태의 content type의 정의와 관련있는데, 이는 multi-media 환경에서 다양한 정보 표현의 처리를 할 수 있는 표준화된 방법을 제공해야할 필요성을 반영한다.

 

 

RFC 2046에 정의된 Content Type. 7개의 type과 15개의 subtype으로 나눠져 있다.

• Text type : 정보를 얻는데 특별한 소프트웨어가 필요하지 않은 형식. subtype으로는 plain과 enriched가 있으며, ASCII 또는 ISO 8859 charset이며, Enriched을 이용해 format의 유연성을 향상 시킬 수 있다.
• enriched를 사용하면, rich text format을 사용할 수 있으며, 아래에 예제가 있다.
• multipart type :  body에 대해 여러가지 정보가 담겨 있을 경우 사용되며 body는 Content-Type에 명시된 boundary 문자열에 의해 구분됨.
   따라서, boundary는 message의 어디에도 들어가면 안되며 각 새로운 boundary는 newline과 함께 --[boundary value]와 같은 형태로 이루어 져있으며, 마지막 boundary는 --[boundary value]--와 같은 형식으로 이루어져있다.

    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.

 

• multipart subtype
  • mixed  : 서로 다른 독립된 부분을 한번의 전송으로 처리하며, 수신자는 순서에 따라 처리해야함(순서가 있음)
  • parallel : mixed와 동일하나 특별한 순서가 필요치 않을때, 상황에 따라 병렬로 처리할 수 있음(e,g. 사진 또는 text가 음성 설명과 함께 제공되는 경우)
  • digest : RFC 5322 message header를 포함하는 경우, 이 subtype을 이용해 개인 메시지를 작성할 수 있음
  • alternative : 둘중에 하나만 선택되며 아래의 상황에서는 enriched가 우선적으로 선택되며 그렇지 않은 경우 plain이 선택 됨

    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—

• • rfc822 subtype: body가 header와 body를 포함한 전체 메세지를 나타냄. subrtype임에도 불구하고  그냥 메시지일 수도 MIME 메세지일 수도 있음.
  • partial subtype: 큰 메세지를 여러 부분으로 분할할 수 있으며, 수신지에서 재조립해야한다. 이 경우 세가지 parameter가 Content-Type에 지정되며 조각난 메세지에 대해 같은 id, 각 seqeunce number 및 전체 조각 메세지의 number가 있다.
  • external-body: 실제 data가 body에 없는 subtype을 의미하며 대신, body에는 data에 access하는 데 필요한 정보가 있다. outer header와 encapsulated된 own header가 있고, outer field는 message형식이 message/external-body형식이라는 것을 Content-Type에 표시하기 위해만 사용된다.
    이때 access-type parameter(FTP와 같은 acesss 방식)이 명시되어 있어야 한다. own header에서는 ecapsulated message에 대한 header의 정보가 있다.
  • application-type: 해석되지 않은 binary data 또는 mail-based application에서 처리 될 다른 종류의 데이터를 나타낸다. message type: MIME에서 여러가지 중요한 기능을 제공함

#Examples

 

Example of multipart

 

위의 그림에서 하나씩 볼 수 있도록 하자.

 

 

MIME 1

MIME1 에서는 처음등장하는 Content-Type으로는  multipart/mixed가 등장하며 boundary로는 'unique-boundary-1'을 사용한다고 명시되어 있다.

 

그 후 This ...~ 으로 시작하는데 이때 boundary가 시작되지 않은 영역이므로, 정상적으로 multipart를 지원하는 경우에선 This ...~ 와 같은 text는 읽지 못할 것이다. 다만, MIME(multipart)를 지원하지 않는 경우  This ...~를 읽게 되어 출력해준다.

 

그 후 newline과 --[boundary value]로 part를 시작하게 되며, MIME 1에서는 첫줄을 공백으로 시작한다. 이 말은 header field가 없다는 것을 의미하며, 기본적으로 text에 charset으로는 US ASCII를 사용한다.

 

MIME 2

 MIME 2에서는 MIME 1 마지막에서 봤던 part를 명시적으로 적어놓은 부분이다. 그리고 multipart/parallel로 명시된 부분이 나오는데,  parallel은 위에 설명한 것 처럼 mixed와 달리 순서가 상관이 없고 동시에 실행가능하다. 위의 경우에선 audiodㅘ image가 상황에 따라 동시에 실행 될 수 도 있을 것 이다.

 

MIME 3

 

예제의 마지막 부분인 MIME 3를 보자. text/enriched를 사용하며, Richtext format을 사용하였다. Richtext의 사용은 조금더 다양하고 보기 좋은 글을 만들 수 있다.

 

Richtext

그리고, 마지막 part에선 type을 message/rfc822로 정의하고 있다. 위에 언급한 것 처럼 일반 텍스트가 올수도 있고 MIME형식의 텍스트가 올 수 있는데 아래에는 MIME 형식의 메세지가 있어, 또다른 메세지를 보낼 수 있다. 아래 형식에서는 아래에서 설명할 quoted-printable 인코딩을 사용한 Text/plain type의 메세지이다.

 

# MIME Transfer Encoding

Content-Transfer-Encoding field에는 아래와 같은 6개의 값이 있다.

 

MIME Content-Transfer-Encoding Field

 

7bit, 8bit, binary는 encoding이 되지 않았음을 나타 내며, 원래의 정보를 나타낸다. SMTP 통신에서는 7bit encoding을 사용하는게 안전하며(호환성) 8bit와 binary encoding도 다른 mail transport contexts에서 사용하다. 

•  x-token
  • nonstandard encoding을 뜻하며, vendor-specifc하거나, application-specific한 scheme를 말한다.
• Base64
  • Binary등의 출력 불가능한 데이터를 영어 대 소문자 + 숫자 + '+, /, = '를 포함한 64개의 ASCII로 바꿔주는 encoding으로 PGP에서 다뤘던 Radix-64와 비슷하다(Radix-64의 경우 '=' 뒤에 에러를 체크할 수 있는 CRC 값이 있다). 마찬가지로 데이터양이 33% 증가한다(3바이트를 4바이트로 치환함).
• quoted-printable
  • ASCII의 범위에서 표현하지 못하는 값들을 HEX값과 =기호를 이용해서 전달할 수 있도록 하는 인코딩 방식이며 '='을 표현할 경우 '=3D'로 표현함

   

원본 문자열

위문자열을 quoted-printable을 적용할 경우 아래와 같다 (출처: Wikipedia)

 

quoted-printable encoded strings

위에서 처음 등장하는 =C3=A9에 대한 문자열 대해 찾아보자. 위의 문자열은 UTF-8형식으로 인코딩되어 있다.

 

아래는 UTF-8 코드표를 찾아본 결과 이다.

 

C3A9에 해당하는 문자는 é임을 알수있고 원본 문자열과 비교해보면 해당 위치에 é가 들어가야함을 알 수 있다. 

이와 같이, 기존의 ASCII를 이용해 HEX value를 표시하는 방법으로 ASCII 범위로 표현하지 못하는 문자를 인코딩으로 표현할 수 있도록 하는 것이 quoted-printable encoding 방식이다.

 

 

#S/MIME

 

S/MIME는 3가지 public-key algorithm을 이용한다.

1. DSS(Deigital Signature Standard)
2. Diffie-Hellman (ElGamal 등)
3. RSA

 

Function	Requirement
Digital signature 생성을 위한 Message Digest	필수  Sender ->SHA-1   권장  Receiver - > Agent에서의 MD5(호환성)
Digital signature 암호화	필수  Sender, Receiver ->DSS   권장  Sender -> RSA         Receiver -> RSA verification ( key size : 512~1024 bits)
Session key 암호화	필수  Sender, Receiver -> RSA Encryption ( key size : 512~1024 bits)   권장 Sender, Receiver -> Diffie-Hellman
one-time session key로 메세지 암호화	필수 Sender, Receiver -> 3DES encryption   권장 Sender -> AES encryption, RC2/40 encryption
MAC(Message Authentication Code) 생성	필수 Receiver -> HMAC, SHA-1   권장 Sender -> HMAC, SHA-1

 

 

S/MIME에서 Sender는 message를 보내기 위해 2가지를 결정해야하는데, 처음으로는 Reciver가 Sender가 사용하는 Encryption Algorithm에 대해 decrypt를 할수있는지를 알아야하고, 만약 Recevier가 취약한 Encrypt Algorithm만 사용할 수 있는 경우, Sender는 그 Algorithm을 사용하여 보낼지 결정해야 한다.

 

Sender(Sender의 Agent)는 아래의 순서를 따라야한다.

1. Receiver가 Decrypt 할 수 있는 Algorithm에 대한 목록을 이미 Sender가 보유하고 있다면, 목록에 있는 Algorithm을 첫번째로 사용하도록 설정해야 한다.
2. 위와 같은 목록이 존재하지는 않으나, 하나 이상의 메세지를 Recipient로 부터 받은 경우, Sender는 메세지를 보낼때 마지막으로 Signed되고 Encryption한 것 과 같은 Ecrpytion algorithm을 사용해야 한다(간단히 말해, 정보가 없으므로 받은 메세지로 부터 정보를 획득해 사용한다). 
3. Sender가 Receiver가 사용하는 Decrpyt 가능한 Algorithm에 대한 정보가 없는 경우, 그리고 Receiver가 message를 decrypt 할 수 없는 위험을 감수할 수 있는 경우에,  3DES를 사용한다(사용할 수 있다).
4. 위의 상황에서 decrypt할 수 없는 위험을 감수할 수 없는 경우, 즉 decrypt 가 꼭 진행되어야 하는 경우 RC2/40을 사용 한다(사용해야한다).

 

여러명의 사용자에게 Message를 보내야 할때, 모두가 함께 사용하는 Algorithm을 사용할 수 없는 경우(각자 지원하는 Algorithm이 다른데, 공통된 게 없는 경우) 2개로 나누어 보내야 하는데, 이때 상대적으로 보안이 낮은 Algorithm에 의해 보안에 취약해지는것에 주의해야 한다.

 

보안에서 자주 등장하는 weakest link chain, 정확한 이론의 이름은 기억이 안나지만, 보안에 있어 보안 수준은 가장 약한 부분이 전체 서비스의 보안 수준이라는 의미

 

 

 

 

 

내용이 너무 길어지므로 다음 글에서 S/MIME에서 실제로 어떻게 사용되는지 알아 보도록 하자!

 

Reference : Cryptographpy and Network Security, Sixth Ed