【特集】S/MIMEでセキュアな電子メール環境をつくる！
〜実は危ない電子メール、安全性を実現するS/MIMEの詳細解説〜

澤野弘幸
オレンジソフト
2001/5/30

2.　S/MIMEの仕組み

　メールでのセキュリティの必要性、そして代表的な2つの通信方式S/MIMEとPGPの仕組みと違いについて、ご理解いただけたでしょうか？ 本章では、S/MIMEの仕組みについてさらに踏み込んで解説していきます。

2.1　S/MIMEを使った、メールメッセージの形式

　S/MIMEのメールメッセージ作成の手順は下記のようになります。

(1) メールメッセージをMIME化します。つまり、通常のメールのヘッダ部のうち、あて先や送信元のメールアドレスを除いたものをつけます

(2) MIME化したメッセージを入力として署名データまたは暗号文データを作成します。このデータのフォーマットはRFC2315 "PKCS #7 : Cryptographic Message Syntax Version 1.5" で決まっています

Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit こんにちは、 明日の打ち合わせの件ですが、 ……

(3) 署名データ、暗号データはバイナリのファイルと同じです。画像データやワープロの文章を送るように、このファイルをメールの添付ファイルにします

(4) RFC2311 "S/MIME Version 2 Message Specification"で決まっているメールのヘッダ情報を付けて、S/MIMEメールのでき上がりです

2.2　電子署名と検証の仕組み

　電子署名のPKCS #7形式のデータは、下の表のような構成になっています。

フォーマットのバージョン 電子署名のアルゴリズムの識別子 メッセージ本文 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit こんにちは、 明日の打ち合わせの件ですが、 …… 署名者の証明書（オプション） 署名情報 署名者の証明書の識別子 メッセージダイジェスト関数の識別子 いろいろな属性情報 公開鍵暗号方式のアルゴリズムの識別子 ダイジェストを、署名者の私有鍵をキーとして公開鍵暗号方式で暗号化したデータ

　肝心なのは太字のところです。そのほかの部分も大事ですが、今回は説明を省きます。検証することは2つあります。

• 署名者の証明書の識別子から、署名に使われた私有鍵に対応する公開鍵証明書が分かります。その公開鍵証明書は上記の表のように添付されてくる場合のほか、ディレクトリサーバなどから取得する場合もあります。検証することは、その公開鍵証明書が本物かどうか
  
  
• その公開鍵を使って、暗号化されたダイジェストを復号したものと、受け取ったメッセージ本文からダイジェストを作成したものとを比較して、一致しているか

　また、上記の表のようにメッセージ本文をこの中に含むタイプと、分離しているタイプの2つがあります。それぞれ、出来上がったメールメッセージの形も違ってきます。下記にその例を紹介します。前者がメッセージ本文を中に含んでいるタイプ、後者が外に分離しているタイプです。分離しているタイプでは、PGPでも使われる、multipart/signedという形式になっています。S/MIME対応のメーラでは、アイコンの表示で電子署名が付いていることが分かるようになっています。

例1　メッセージ本文をPKCS#7データに含むタイプ

例2　電子署名をつけたメールの例（分離しているタイプ）

2.3　暗号化の仕組み

　暗号化のPKCS #7形式のデータは、下の表のような構成になっています。

フォーマットのバージョン 受信者情報 受信者の証明書の識別子 公開鍵暗号方式のアルゴリズムの識別子 暗号文の作成に用いた、秘密鍵を受信者の公開鍵をキーとして公開鍵暗号で暗号化したデータ 電子署名のアルゴリズムID（公開鍵暗号方式のID） （受信者情報が受信者数ぶん並ぶ） 共通鍵暗号方式のアルゴリズムの識別子 暗号文（メッセージを共通鍵暗号で暗号化したもの）

　まず、メーラは受信者の証明書の識別子を見て、自分の証明書と一致するものを探します。証明書があれば、その部分の暗号化されたデータを復号することで、秘密鍵が分かります。その秘密鍵を使って、暗号文を共通鍵暗号方式で復号するのです。

　でき上がったメールメッセージは以下のようになります。

例3　暗号化メールの例

2.4　証明書の取得方法

　証明書の取得には、幾つかの方法がとられているようです。

(1) Webサイトにアクセス
　商用の認証サービスを提供していたり、自社内で認証局を運営している場合なら、認証局の機能を持ったソフトウェアが稼働しているサーバにアクセスして、Webブラウザの中で私有鍵、公開鍵を作成することができます。作成した私有鍵は手元のHDDの中に保管しておき、公開鍵は名前やメールアドレスなどと一緒に認証局に送信します。認証局では規定に沿って本人確認が済むと、証明書を発行します。

(2) 電子メールで送信
　認証局によっては、電子メールでの証明書発行要求を受け付けるサービスを行っています。その場合は、作成した公開鍵は名前やメールアドレスなどと一緒に添付ファイルにして、電子メール経由で認証局に送ります。

(3) 証明書署名要求のデータ
　(1) (2)で認証局に送っているデータは、下の表のような形式になっています。

フォーマットのバージョン 名前や電子メールアドレス 公開鍵情報 公開鍵暗号方式のアルゴリズムの識別子 公開鍵 属性情報 Challenge passwordなど 電子署名のアルゴリズムの識別子 属性情報までをあなたの私有鍵で電子署名したデータ

　認証局では、このようなデータを受け付けて、認証局の方針に沿って本人確認を行い、問題がなければ、証明書を発行することになります。表中の「Challenge password」について、詳細は省きますが、 証明書を破棄するときに必要になるパスワードです。

(4) 私有鍵と証明書の保管と移動
　でき上がった私有鍵と証明書は大事なものなので、バックアップをとっておいた方がよさそうです。ところが、製品のベンダごとに独自の形式で内部的に管理しているので、そのままでは共用ができません。そこで便利なのが、私有鍵と証明書とを合わせてファイルにまとめる仕様、PKCS#12です。この形式のファイルでエクスポートして、別の製品でインポートすればいいわけです。これにより、異なるベンダ間の製品で私有鍵と証明書とを共用することができます。

例4　Outlook Expressでの証明書のエクスポートの例。「証明書／個人」の「エクスポート」ボタンをクリックすると、証明書のエクスポートウィザードが起動する（画面をクリックすると拡大表示します）

2.5　電子署名から見たPKI

(1) 証明書の形式
　公開鍵証明書のフォーマットは、X.509と呼ばれる仕様で決まっています。X.509にもバージョンがあり、現在使われている証明書はほとんどが1996年に出たバージョン3です。2001年に入ってX.509 エディション4というのも発表されましたが、証明書自体はバージョン3のままです。

　バージョン3からは、拡張属性と呼ばれるものが使えるようになり、自由度が高まった結果、現実的な運用に適するものになりました。バージョン3の拡張属性については、また後ほど解説します。

　バージョン3のフォーマットは、下記のようになっています。

フォーマットのバージョン 証明書シリアル番号 電子署名のアルゴリズムの識別子 証明書発行者（認証局）の名前 有効期間 証明書の所持者（主体者）の名前 公開鍵情報 公開鍵暗号方式のアルゴリズムの識別子 公開鍵 X.509 V3 拡張属性 電子署名のアルゴリズムの識別子 X.509 V3 拡張属性までをあなたの私有鍵で電子署名したデータ

　詳細は省きますが、「名前」はX.500のディレクトリサービスにおけるDNと呼ばれるものにあてはまります。「電子メールアドレス」は、X.500のRDNと呼ばれる名前付けの識別子としては存在しませんが、別に識別子を定義して、このDNの中に入れています。

(2) X.509 拡張属性
　下記の表のようになっています。

フィールド識別子 解釈必要フラグ フィールドの値

　「解釈必要フラグ」とは、「アプリケーションが証明書を扱う際に、このフィールドの意味をきちんと解釈して処理をすべきか」どうかを示します。フィールドとしては以下のようなものがあります。

基本制限 （BasicConstraints） CAなのかユーザーなのか 鍵使用法 （KeyUsage） 公開鍵の用途を限定します 主体者の別名 （subjectAltName） DNとして定義されない名前。メールアドレスなど 発行者の別名 （issuerAltName） DNとして定義されない名前。メールアドレスなど 主体者の鍵識別子 （SubjectKeyIdentifier） 公開鍵を識別します CRL配布ポイント （CRLDistributionPoints） CRLのURL Netscape社の 拡張証明書種別 （NetscapeCertType） 本来Netscape社がSSLのために用意したフィールド

　CRLとは、破棄された証明書のシリアル番号が載っているリストのことです。CRLの詳細については、連載：PKI基礎講座 第5回「証明書の有効性」を参照してください。

(3) 鍵使用法（KeyUsage）
　ビットのON／OFFで公開鍵の使用目的を示します。RSAの公開鍵で電子署名と暗号化とを同時に使うのであれば、0と2のビットがONになります。

(4) NetscapeCertType
　ビットのON／OFFで公開鍵を使用するアプリケーションを示します。SSL用の証明書とか、S/MIME用の証明書など、分かりやすいですね。

　ActiveXやJavaアプレットに付いている証明書は3のビット、Object SigningがONになっているのが分かるでしょう。今年の3月ごろに問題となった、ベリサインが誤って第三者に発行してしまったマイクロソフトのActiveX用の証明書も、このビットが立っていたのだと思います。

2.6　ほかの人の公開鍵証明書の集め方

(1) ディレクトリサーバへアクセス
　商用の認証サービスを提供している会社では、同時に、ディレクトリサービスも提供しているため、そこから探してくることが可能です。また、認証局を構築するためのソフトウェアでも、ディレクトリサービスを提供するソフトウェアとセットになっていることが多いようです。

(2) Webサイトの検索サービスを使う
　ディレクトリサーバと同様に、Webサイトで検索のサービスも提供されているようです。

(3) 電子署名に添付されてくる
　電子署名のデータ形式のオプションですが、証明書を添付して送ることもできます。

(4) エクスポートした証明書ファイルをもらう

拡張子cer	1つの証明書のみ
拡張子 p7c／p7b	複数の証明書を格納できます。従って、証明書パス上の認証局の証明書を含めることもできます

　

「メーラごとのS/MIMEの設定」 へ

Index
【特集】 S/MIMEでセキュアな電子メール環境
	1. メールになぜセキュリティが必要か？ 電子メールのリスク リスクを回避する方法 暗号の分類 電子署名と暗号化の手順 公開鍵をいかにして信頼するのか S/MIMEとPGPの使い道
	2. S/MIMEの仕組み S/MIMEを使った、メールメッセージの形式 電子署名と検証の仕組み 暗号化の仕組み 証明書の取得方法 電子署名から見たPKI ほかの人の公開鍵証明書の集め方
	3. メーラでのS/MIMEの利用方法 Outlook Express Netscape Messenger Orangesoft Winbiff

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）