2006年度
企業個人の情報セキュリティ対策事業
電子メールのセキュリティ
”電子メールの安全性を高める技術の利用法”
平成 19 年 3 月 株式会社 オレンジソフトi
目次
はじめに ... 1 1. 電子メールを取り巻く環境 ... 2 1.1. 電子メールの「いま」 ... 2 1.2. 電子メールのリスクと必要な安全性 ... 3 1.3. 電子メールのセキュリティ技術 ... 28 1.4. セキュリティ技術の使い分け ... 41 2. 不正とその検出方法 ... 43 2.1. 公開鍵証明書の有効性 ... 43 2.2. 電子メールにおけるデジタル署名による不正の検出 ... 51 2.3. 暗号化の注意事項 ... 60 3. セキュリティトークン ... 61 3.1. セキュリティトークンの標準仕様 ... 61 3.2. セットアップと証明書の取得方法 ... 64 4. 電子メールソフトの設定 ... 69 4.1. 公開鍵証明書の入手方法 ... 69 4.2. 証明書ファイル ... 79 4.3. 公開鍵証明書の管理 ... 81 4.4. 電子メールソフトの設定と送受信方法 ... 85 5. FAQ ... 148 5.1. Q1：公開鍵証明書はどのように入手できますか？ ... 148 5.2. Q2:メールソフトでセキュリティのエラーの警告が表示されます ... 150 5.3. Q3：公開鍵証明書のバックアップ方法についておしえてください ... 151 5.4. Q4：S/MIME 非対応の電子メールソフトではどうなりますか？ ... 158 5.5. Q5：S/MIME と PGP との違いはなんですか？ ... 159 5.6. Q6：ルート証明書についてセキュリティの警告画面が表示されます ... 160 6. まとめ ... 161 7. 資料 ... 162 7.1. S/MIMEのメールメッセージ ... 162 7.2. 証明書の実例 ... 167ii
7.3. 証明書チェーンの実例 ... 168 7.4. その他の公開鍵管理機構 ... 171 おわりに ... 174
iii
図表目次
図 1-1ネットワーク上で盗聴される様子 ... 3 図 1-2ネットワーク上で「なりすまし」を行っている様子 ... 4 図 1-3ネットワーク上でデータを改ざんする様子 ... 4 図 1-4金融機関を装ったWEBサイトを使ったフィッシング詐欺 ... 5 図 1-5専用電子メールソフトとWEBメール ... 6 図 1-6暗号化方式の基本 ～暗号化の流れ～ ... 7 図 1-8公開鍵暗号方式を使った、暗号化と復号 ... 8 図 1-10 メッセージの暗号化の仕組み（共通鍵暗号と公開鍵暗号を組み合わせて使います。） 11 図 1-11 デジタル署名の仕組み （メッセージダイジェスト関数と公開鍵暗号を組み合わせて使 います。） ... 13 図 1-12PKI での公開鍵の保証と検証の仕組み ... 15 図 1-13WINDOWSの証明書プロパティでの拇印の表示 ... 16 図 1-14WINDOWSでルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面 ... 17 図 1-15 公開鍵証明書の中身 ... 17 図 1-16 通信相手の公開鍵証明書にある公開鍵を、デジタル署名の検証や、暗号化を行います ... 19 図 1-17FIREFOX、THUNDERBIRD の証明書ビューアでの証明書ポリシーの表示 ... 20 図 1-18WINDOWS証明書ストアで証明書ポリシーがあり「発行者のステートメント」が有効に なっている。 ... 21 図 1-19WINDOWSでの証明書チェーン（証明のパス）の表示 ... 22図 1-20MOZILLA FIREFOX、MOZILLA THUNDERBIRDでの証明書チェーン（証明書の階層）の表 示 ... 23 図 1-21CRL の中身 ... 24 図 1-22CRL 配布点に記載された CRL のある URI ... 25 図 1-23 証明書署名要求のデータ(PKCS#10)の中身 ... 26 図 1-24PGP の公開鍵の信頼のモデル ... 27 図 1-25 暗号化されたメールメッセージの中身 ... 29 図 1-26 デジタル署名のついたメールメッセージの中身 ... 30 図 1-27 デジタル署名と暗号化の組み合わせ ... 31 図 1-28 デジタル署名したデータと暗号化をしたデータをくっつける。 ... 32 図 1-29 「IP アドレス方式」を用いた送信ドメイン認証の流れ ... 34 図 1-30 「電子署名方式」を用いた送信ドメイン認証の流れ ... 35 図 1-32SSL/TLS、ドメイン認証、S/MIME それぞれがカバーする領域 ... 42 図 2-1 証明書にある認証局のデジタル署名が正しくなかった場合 ... 44
iv 図 2-2信頼しているルート認証局まで、証明書チェーンができない場合 ... 45 図 2-3証明書チェーンができない場合の表示 ... 46 図 2-4証明書チェーンができた場合の表示 ... 46 図 2-5有効期限内にない証明書 ... 47 図 2-6 証明書ポリシー ... 48 図 2-7証明書の鍵使用法 ... 49 図 2-8失効している証明書 ... 50 図 2-9マイクロソフトOUTLOOK EXPRESSバージョン6 でのデジタル署名の不正を検出した画 面 ... 51 図 2-10 マイクロソフト OUTLOOK 2007 でのデジタル署名の不正を検出した画面 ... 51 図 2-11MOZILLA THUNDERBIRDでのデジタル署名の不正を検出した画面 ... 52 図 2-12 マイクロソフト OUTLOOK EXPRESS でメッセージの改ざんを検出した場合 ... 53 図 2-13 マイクロソフト OUTLOOK EXPRESS で検証時に有効期間にない証明書でのデジタル署 名を検証した結果 ... 54 図 2-14 マイクロソフト OUTLOOK EXPRESS で検証に必要な証明書が見つからないため、証明 書チェーンを確認できない場合の画面 ... 55 図 2-15 マイクロソフト OUTLOOK EXPRESS送信者メールアドレスと証明書記載のメールアド レスの相違する場合の画面 ... 56 図 2-16 失効している証明書の表示 ... 57 図 2-17 マイクロソフト OUTLOOK 2007 でデジタル署名に使った証明書の鍵使用法の問題を警 告している画面 ... 59 図 3-1アプリケーション、CRYPTOAPI、CSP、セキュリティトークンの関係 ... 62 図 3-2WINDOWSのレジストリのCSP の情報 ... 63 図 3-3セクリティトークンのユーティリティプログム ... 64 図 3-4 INTERNET EXPLORERで鍵生成のデバイスを選択するところ ... 65 図 3-5FIREFOX PKCS#11 デバイスの追加画面 ... 66 図 3-6FIREFOX PKCS#11 デバイスマネージャ画面 ... 66 図 3-7FIREFOXセキュリティトークンへPIN 入力画面 ... 67 図 3-8FIREFOXセキュリティデバイスの選択画面... 67 図 4-1WEBサイトでの証明書の申請 ... 71 図 4-2WEBサイトで証明書の申請の完了 ... 73 図 4-3WEBサイトでの証明書の申請が完了し、その後の手順について、電子メールでの確認な どを促している画面 ... 74 図 4-4証明書の発行が完了した旨を告げる電子メール ... 74 図 4-5WEBサイトから証明書のインストール ... 75 図 4-6米国コモドの証明書発行サービスのWEBサイト ... 76
v 図 4-7PEM 形式の証明書 ... 80 図 4-8WINDOWSの証明書管理 ... 82 図 4-9 WINDOWSの証明書の詳細表示画面 ... 83 図 4-10WINDOWSでのCRL（失効リスト）の表示画面 ... 84 図 4-11WINDOWSメールのセキュリティ設定画面 ... 86 図 4-12WINDOWSメールのセキュリティの詳細設定画面 ... 87 図 4-13WINDOWSメールのアカウントごとの設定 ... 89 図 4-14WINDOWSメールの証明書の選択画面 ... 90 図 4-15WINDOWS アドレス帳の連絡先の人のプロパティの証明書のページ ... 91 図 4-16WINDOWSメールで、ディレクトリサーバーの検索条件を入力する画面 ... 92 図 4-17 WINDOWSメールでディレクトリの検索結果から証明書を確認します。 ... 93 図 4-18WINDOWSメールでメッセージの作成でデジタル署名を指定します。 ... 94 図 4-19WINDOWSメールでメッセージの作成で暗号化を指定します。 ... 94 図 4-20WINDOWSメールでメッセージの作成でデジタル署名と暗号化を指定します。 ... 95 図 4-21WINDOWSメールでデジタル署名付きメールを受信したときの画面 ... 95 図 4-22WINDOWSメールで暗号化されたメッセージを受信したときの画面 ... 96 図 4-23WINDOWSメールでデジタル署名と暗号化されたメッセージを受信したときの画面 ... 96 図 4-24 WINDOWSメールでデジタル署名と暗号化されたメッセージの内容画面 ... 97 図 4-25WINDOWSメールの証明書の確認画面 ... 99 図 4-26WINDOWSメールで不正なメッセージを受信したときの画面 ... 100 図 4-27OUTLOOK 2007 のセキュリティ設定画面 ... 101 図 4-28OUTLOOK 2007 のセキュリティの詳細設定画面 ... 102 図 4-29OUTLOOK 2007 のセキュリティラベルを付けるためのポリシーモジュール選択画面 103 図 4-30OUTLOOK 2007 アドレス帳の証明書のページでは証明書のインポートが可能です。105 図 4-31OUTLOOK 2007 のメッセージ作成画面でのデジタル署名と暗号化の指定 ... 106 図 4-32OUTLOOK 2007 のメッセージ作成画面でのメッセージオプションのセキュリティ設定 ... 107 図 4-33OUTLOOK 2007 でデジタル署名付きメッセージを表示しています。 ... 108 図 4-34OUTLOOK 2007 で暗号化されたメッセージを復号して表示しています。 ... 109 図 4-35OUTLOOK 2007 でデジタル署名と暗号化されたメッセージを復号して表示しています。 ... 110 図 4-36OUTLOOK 2007 の メッセージのセキュリティのプロパティ画面 ... 111 図 4-37OUTLOOK 2007 で表示される受信したメッセージの暗号化の情報 ... 112 図 4-38OUTLOOK 2007 で表示される受信したメッセージのデジタル署名の情報 ... 113 図 4-39THUNDERBIRD の証明書管理 ... 114 図 4-40THUNDERBIRDの証明書マネージャ ... 115
vi 図 4-41MOZILLA THUNDERBIRDの証明書の信頼性の設定 ... 116 図 4-42THUNDERBIRDでの認証局証明書の信頼性の設定 ... 117 図 4-43THUNDERBIRDの失効リストマネージャ ... 117 図 4-44THUNDERBIRDのCRL の取得先 URI の指定画面 ... 118 図 4-45THUNDERBIRDのCCRL 自動更新の設定画面 ... 118 図 4-46THUNDERBIRDのOCSP の利用に関する設定 ... 119 図 4-47THUNDERBIRDのセキュリティデバイスの設定... 120 図 4-48THUNDERBIRD のアカウント設定のセキュリティ設定 ... 121 図 4-49THUNDERBIRDでデジタル署名用、暗号化用の証明書の選択画面... 122 図 4-50THUNDERBIRDのメッセージ作成画面でのデジタル署名と暗号化の指定 ... 123 図 4-51THUNDERBIRDでデジタル署名付きで暗号化されているメッセージを表示しています。 ... 124 図 4-52THUNDERBIRDで受信したメッセージのデジタル署名と暗号化の情報を表示 ... 124 図 4-53THUNDERBIRDで受信したメッセージのデジタル署名で不正が検出された場合 ... 125 図 4-54THUNDERBIRDで受信したメッセージのデジタル署名の不正の説明 ... 125 図 4-55 メイン画面とメール作成画面の「ツール」メニューにS/MIME の指定があります。 ... 126
図 4-56BECKY!INTERNET MAILのS/MIME 設定 ... 127
図 4-57BECKY!INTERNET MAILで「S/MIME:署名と暗号化」を実行したところ ... 128
図 4-58BECKY!INTERNET MAILで「S/MIME: 暗号化」または「S/MIME: 署名と暗号化」を実 行した後、SMIME.P7Mという添付ファイルが追加される ... 128
図 4-59BECKY!INTERNET MAILで「S/MIME:署名」を実行した後、SMIME.P7Sという添付フ ァイルが追加される ... 128
図 4-60BECKY!INTERNET MAILで受信したメッセージのデジタル署名と暗号化の情報を表示 ... 129
図 4-61BECKY!INTERNET MAILで受信したメッセージの改ざんを検出 ... 129
図 4-62BECKY!INTERNET MAILで信頼しているルート認証局までの証明書チェーンがつながら ない場合。 ... 130
図 4-63BECKY!INTERNET MAILで証明書が添付されていないデジタル署名を検証した結果 130 図 4-64WINBIFF＋S/GOMA ユーザー設定／暗号画面 ... 131
図 4-65WINBIFF＋S/GOMA証明書一覧 ... 132
図 4-66WINBIFF＋S/GOMA セキュリティ設定／S/MIME オプション設定画面 ... 133
図 4-67WINBIFF＋S/GOMA セキュリティ設定／詳細画面 ... 135
図 4-68 WINBIFF＋S/GOMA セキュリティ設定／ディレクトリサーバー画面 ... 136
図 4-69 WINBIFF＋S/GOMAの認証局一覧画面 ... 138
vii 図 4-71WINBIFFの「送信の確認」画面 ... 141 図 4-72WINBIFFの暗号化、デジタル署名の結果確認画面 ... 142 図 4-73 WINBIFF +S/GOMAでの復号や署名検証の結果の確認画面 ... 143 図 4-74WINBIFF +S/GOMAでの復号や署名検証の結果の確認画面で不正な電子署名であった場 合 ... 144 図 4-75MAC OSX キーチェーンの公開鍵証明書管理機能 ... 145 図 4-76MAC OSX の“MAIL”で新規メッセージ画面での暗号化、デジタル署名の指定 ... 146 図 4-77 MAC OSX の“MAIL”で復号や署名検証の結果の表示 ... 147 図 4-78MAC OSX の“MAIL”で復号や署名検証の結果、不正な電子署名であった場合 ... 147 図 5-1WINDOWS 証明書ストアの一覧表示 ... 151 図 5-2プライベート鍵と証明書を一緒にエクスポートします。 （WINDOWSではプライベート 鍵を秘密キーと表記しています） ... 152 図 5-3証明書チェーン上の証明書も一緒にエクスポートします。 ... 153 図 5-4エクスポートするプライベート鍵を、パスワードを鍵として暗号化して保護します。 ... 154 図 5-5最後にエクスポートするファイル名を指定します。 ... 155 図 5-6MAX OS Ⅹのキーチェーンアクセス ... 156 図 5-7THUNDERBIRDの「証明書の表示」 ... 157 図 5-8S/MIME に対応していない電子メールソフトでは添付ファイル付きのメールとして扱わ れる。... 158 図 5-9WINDOWSでルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面 ... 160 図 7-1処理の流れと標準仕様 ... 164 図 7-2J2RE の証明書管理機能 ... 172 図 7-3J2RE の証明書の詳細表示画面... 173 表 1-1X.509V3 拡張項目 ... 18 表 1-2公開鍵の使用法 ... 19 表 1-3SSL/TLS を使った電子メールのプロトコル名 ... 39 表 4-1公開鍵証明書やプライベート鍵などのデータを扱うファイルの形式 ... 79 表 7-1 証明書の実例 ... 167
1
はじめに
電子メールの原型となるシステムが開発された際には、研究所等の閉鎖的なネットワーク 内で通信するためのツールとして用いられていましたが、そうした信頼出来る仲間同士の 通信手段であればセキュリティに対する考慮の必要性は皆無でした。 その後UNIX 等によるネットワーク間の接続技術の進展とともに電子メールの利用は拡 大し、今や、コンピュータ及びインターネット利用環境の普及と共に、電子メールによる 通信は大企業のみならず小規模事業者や個人ユーザー等のエンドユーザーにとっても非 常に身近な存在となっています。 しかし、利用者の拡大とともに、開発当初には考慮する必要が無かった「なりすまし」や 「盗聴」、「改ざん」等のセキュリティ上の被害事例も散見され、何ら対策を施さなけれ ば、時間と空間を越えたコミュニケーション技術のメリットは、同時にそれを悪用したハ イテク犯罪を生み出す温床となりかねない状況です。 そこで、本書では、エンドユーザー、そして企業内の利用者をバックアップする立場にあ るネットワークの管理者向けに、電子メールのセキュリティ対策として暗号技術の利用方 法にポイントを置いて解説しています。 （編集の前提とするOS とバージョンについて）本書の内容は、エンドユーザー向けのOS として、Windows XP SP2、Windows Vista、Mac OS 10.4 のクライアント OS をご利用の方を対象にしています。
2
1. 電子メールを取り巻く環境
1.1. 電子メールの「いま」 電子メールは、今やビジネス、プライベートを問わずコミュニケーションのツールとして、 欠かすことのできないものとなっています。しかし、コミュニケーションには意図しない 第三者というリスクがつきまといます。電子メールも例外ではありません。 電子メールシステムを利用した通信というのは、郵便葉書を使ったメッセージのやりとり に似ています。電子メールのメッセージは、葉書の裏に書かれた文章が、まったく隠され ずに運ばれているのと同じように、内容が簡単に見える形でいくつものコンピュータを経 由して相手に運ばれていきます。通信の経路上に関わっている人たちが（郵便局員と同じ ように）良心を持ち合わせて、他人のメッセージの内容に関与するようなことはしないと いうことによってなりたちます。3 1.2. 電子メールのリスクと必要な安全性 1.2.1. 電子メールが持つリスク 意図しない第３者の存在により発生する電子メールの危険性には、以下のようなものがあ ります。 盗聴 なりすまし 改ざん それぞれどんな危険性なのかを説明します。また、なりすましを利用したフィッシング詐 欺や不特定多数に電子メールを送りつけるスパムメール、ブラウザを利用して電子メール の送受信を行うWeb メールシステムの危険性についても触れておきましょう。 1.2.1.1. 盗聴 「アリス」が「ボブ」に電子メールでメッセージを送る場合、メッセージの先頭に宛名と して、ボブの（電子メール）アドレスを付けて送信します。このメッセージがボブに届く までに、いくつものコンピュータを経由しています。 この途中に経由しているコンピュータの操作者は、簡単にアリスの電子メールのメッセ－ ジをみることができます。 図 1-1 ネットワーク上で盗聴される様子 1.2.1.2. なりすまし 「アリス」と「ボブ」の電子メールを知っている「イブ」は、送り元アドレスに「アリス」 のメールアドレスを記入することによって、「アリス」と偽って「ボブ」に電子メールを 送ることが簡単にできます。 いわゆる『フィッシング詐欺』にも利用される手段です。
4 図 1-2 ネットワーク上で「なりすまし」を行っている様子 その他にも、「イブ」は、メーリングリストやニュースグループなど、不特定多数の相手 の目に触れる場に対して、「アリス」と偽って発言することも可能です。 1.2.1.3. 改ざん 「イブ」は「アリス」が送信した電子メールを盗聴し、書かれた内容を変更して「ボブ」 に送ることもできます。｢アリス｣にも｢ボブ｣にも内容が書き換えられたことは判りません。 これを「改ざん」と呼びます。 図 1-3 ネットワーク上でデータを改ざんする様子
5 1.2.1.4. フィッシング詐欺 メールにURL を記載することで偽装されたサイトに誘導し機密情報を搾取するものです。 典型的には正規の金融機関などを装った電子メールで、フィッシングを意図したWeb サ イトへのURL を埋め込んだメッセージを送り、偽装した Web サイトに誘導します。正規 のWeb サイトを装いながら、ポップアップウィンドウなどで暗証番号やクレジットカー ド番号を入力させます。 図 1-4 金融機関を装った Web サイトを使ったフィッシング詐欺 1.2.1.5. スパムメール 公開されているWeb サイトに記載されているメールアドレスを機械的に読み取り、営利 目的のメールを大量に送信するものです。インターネットの利用目的が多様化した結果、 生じた現象と考えられます。スパムメールの発信者アドレスの蓄積や、メッセージの特性 によるフィルタリングなどが対策として用いられています。 1.2.1.6. Web メールのセキュリティ1 電子メールを閲覧する仕組みとして、電子メールソフトのほかに「Web メール」と呼ばれ るシステムが普及しています。 Web メールは、専用の電子メールソフトを使うのではなく、Web ブラウザを使って、電 子メールソフトと同様な操作を可能とする仕組みです。利用者はWeb メールシステムで 表示されるWeb サイトにアクセスし、電子メールを閲覧（あるいは送信）します。送受 1 本書では電子メールに内在するリスクとして「盗聴」、「なりすまし」、「改ざん」を取り上げ、その 対策について説明しています。「Web メール」にはこれらのリスクとは別にシステムの仕組みに内在する リスクが存在します。本節では、簡単にその点を取り上げます。
6 信の操作もWeb サイトに用意されたアイコンをクリックして行います。Web サイトにア クセスするだけで電子メールの一連の操作が可能ですので、利用者は個々のクライアント PC に特別な設定をすることなく利用できます。Web ブラウザを使える環境であれば場所 や機器を選びません。 このようにWeb メールは簡便である反面、専用の電子メールソフトを使った場合の仕組 みとは別に安全性への配慮が必要となります。以下にWeb メール利用の注意事項を簡単 に説明します。 SSL で保護された Web サイトで運用されている Web メールを使いましょう。それに より、サイトの認証と伝送路上にある電子メールデータの暗号化が可能となります。 メールサーバーが一極集中で管理することになるので、Web メールのサーバーの運用 では、電子メールの可用性、機密性など十分な対策が必要となります。利用者はこの 点を十分踏まえ、重要なメールはクライアントに転送するなどしてサーバーには残さ ない、といった注意をしましょう。 利用者としての注意すべき点は、Web ブラウザに Web メールにアクセスしたキャッシ ュが残ることにより、盗み見などが容易となることです。使い終わったらキャッシュ をクリアするようにしましょう。 サーバー側にすべてのデータを置く仕組みであるため、デジタル署名や暗号化などの 利用者固有の情報に基づく保護の仕組みを組み込むことが困難となります。 図 1-5 専用電子メールソフトと Web メール
7 1.2.2. 暗号で電子メールの安全性を確保する このように多くのリスクがある電子メールによるコミュニケーションにおいて、安全性を 確保するために私たちにできることはなんでしょうか。それは暗号技術を使って電子メー ルのメッセージを暗号化し意図しない他人に読まれることを防ぐことやメッセージに電 子的な署名（デジタル署名）を付けて自分が書いた文章であることを保証することが考え られます。 次に、メッセージの暗号化やデジタル署名に使われている暗号技術の方式に ついて説明します。 1.2.2.1. 暗号方式の基本 暗号化とは、特定の決まりにしたがって、文章やファイルのデータの並び替えを行うこと です。 この特定の決まりとして、数学的な処理（暗号アルゴリズム）や「鍵」とよばれ る特別なパスワードを使います。また、もとのメッセージ（平文と呼びます）を並び替え て、別のメッセ－ジ（暗号文）に変換することを暗号化といい、逆に暗号文をもとの平文 に戻すことを復号といいます。 図 1-6 暗号化方式の基本 ～暗号化の流れ～ 電子メールに適応される暗号技術は、鍵の使い方や処理方式によって、大きく次の３つに 分類することができます。 共通鍵暗号方式 公開鍵暗号方式 メッセージダイジェスト関数 これらを組み合わせて、暗号化とデジタル署名を行います。 1.2.2.2. 共通鍵暗号方式 メッセージを暗号化するときと、復号するときに同一鍵を使う方法を共通鍵暗号と呼びま す。秘密鍵暗号方式、または対称暗号方式などとも呼ばれます。 この方式に基づく暗号 アルゴリズムには、RC2、RC5、DES、Triple-DES、IDEA などがあります。
8 図 1-7 共通鍵暗号方式を使った、暗号化と復号 この方式では、暗号化を行う相手ごとに秘密鍵を用意する必要があります。また、復号の ために必要となる秘密鍵をどのようにして安全に相手に伝えるかが大きな問題です。 1.2.2.3. 公開鍵暗号方式 メッセージを暗号化するときと、復号するときで、異なる鍵を使う暗号アルゴリズムのこ とを公開鍵暗号方式と呼びます。この方式では、暗号化用の鍵を公開し、復号用の鍵を自 分だけが秘密に保持します。そのため、暗号化用の鍵を公開鍵（public key）、復号用の 鍵をプライベート鍵（private key）と呼びます。 また、この方式は、非対称暗号方式とも呼ばれます。 この方式を基づく暗号アルゴリズムには、RSA、DSA、Diffie-Hellman、ECC(楕円関数) などがこの方式です。 図 1-8 公開鍵暗号方式を使った、暗号化と復号 この方法では、プライベート鍵がなければ復号できないため、プライベート鍵を自分一人 が安全に持っていれば、暗号化に必要な公開鍵は誰に知られても構いません。この方式の 弱点は、処理が複雑なため、データを暗号化や復号する際に時間がかかりすぎることです。 もう1 つ大きな問題は、公開鍵の持ち主、つまり対になるプライベート鍵を持っている人 が誰かということです。暗号化して送ったときに、それを復号できるのが意図した人でな
9 ければ困ります。公開鍵の持ち主が保障された状態で入手できなければなりません。それ を解決するのが、後述するPKI（公開鍵認証基盤）です。 1.2.2.4. メッセージダイジェスト関数 メッセージダイジェスト関数は、任意の長さのデータを固定長のデータに変換する関数を メッセージダイジェスト関数と呼びます。また、関数によって計算した結果の固定長のデ ータをハッシュ値と言います。元のデータが尐しでも異なると、ハッシュ値は全く違った ものとなり、計算結果のハッシュ値から元のデータを逆算しにくいものを、特にメッセー ジダイジェスト関数と呼びます。メッセージダイジェスト関数の計算結果のハッシュ値を ダイジェスト(または、メッセージダイジェスト)と呼びます。 メッセージダイジェスト関数としては、MD2(ハッシュ値は 16 バイト)、MD5(16 バイト)、 SHA-1(20 バイト) 、SHA-224(28 バイト)、SHA-256(32 バイト)、SHA-512(64 バイト) などがあります。 図 1-9 メッセージダイジェスト関数によるダイジェストの計算と、逆算の困難さ メッセージダイジェスト関数によって作成されたダイジェストからは、もとのメッセージ を復号することはできません。 鍵を使う暗号方式とは異なりますが、このようなメッセージダイジャスト関数の性格を使 い、送信データと送信データのハッシュ値を相手におくることによりデータの改ざんが検 出可能になります。したがって、安全にハッシュ値を送ることが重要です。
10 1.2.3. 暗号技術を使ったリスクの回避 前節で説明した３つ暗号方式を電子メールに適用することによって、以下の3 つのセキュ リティを確保します。 メッセージの秘匿性－メッセージを暗号化することによって盗聴を防御 認証―電子メールの送信者がメッセージにデジタル署名を加えることで送信者を保証 メッセージの完全性－メッセージにデジタル署名を加えることで、メッセージに改ざんがな いことを保証 暗号技術を電子メールへ適用する手順の代表的なものは、S/MIME や PGP があります。 暗号方式を組み合わせて使うことで、それぞれの弱点、問題点をカバーしています。次節 以降では、これらの手順で、どのように暗号方式を使い３つのセキュリティが可能となる のかを見てみましょう。 1.2.3.1. メッセージの暗号化 暗号化は共通鍵暗号と公開鍵暗号を組み合わせて使います。組み合わせて使うことで、共 通鍵暗号の秘密鍵の共有の問題と、公開鍵暗号の処理時間の問題を解決しています。 アリスからボブへメッセージを暗号化して送信する場合の、送信側と受信側の処理の流れ をみてみましょう。 (1) 送信側での暗号化（アリス） i. メッセージを共通鍵暗号方式で、暗号化し暗号文を作成します。 ii. i で用いた秘密鍵を、受信者の公開鍵を鍵として使って公開鍵暗号方式で暗号化しま す。→ 受信者の数だけ、同様の操作をします。 iii. i の暗号化の結果のデータと ii の結果のデータをメールで送ります。 (2) 受信側での復号（ボブ） iv. 送られて来たデータの中から、自分宛のパートの暗号文を自分のプライベート鍵を鍵 として使って公開鍵暗号方式で復号します。その結果、共通鍵暗号方式の秘密鍵を獲 得します。 v. iv で得た、秘密鍵を使って暗号文を復号し元のメッセージを得ます。
11
図 1-10 メッセージの暗号化の仕組み（共通鍵暗号と公開鍵暗号を組み合わせて使います。）
このように鍵データ自身を公開鍵暗号化方式で暗号化することにより、共通鍵暗号で困難 な秘密鍵配布の問題を解決しています。また、公開鍵暗号化方式を小さな鍵データの暗号 化に使用することによって、暗号化にかかる処理時間の問題を解決しています。
12 1.2.3.2. デジタル署名 メッセージダイジェスト関数と公開鍵暗号方式を組み合わせて使います。アリスがメッセ ージにデジタル署名を加えて、ボブに送る場合のデジタル署名の作成からデジタル署名の 検証の処理の流れを見てみましょう。 (1) 送信側でのデジタル署名（アリス） i. メッセージダイジェスト関数を使って本文のダイジェストを作成します。 ii. プライベート鍵をキーとしてダイジェストを公開鍵暗号化方式で暗号化します。 → 署名データの作成 iii. 本文と署名データ( ii の結果)をメールで送ります。 (2) 受信側のデジタル署名の検証（ボブ） iv. 発信者と同様に、メッセージダイジェスト関数を使って本文のダイジェストを計算し ます。 v. 署名データを発信者の公開鍵をキーとして公開鍵暗号化方式で復号します。 その結 果、発信者の作った、ダイジェストを獲得します。 vi. iv と v の結果を比較して、同一であれば、以下の 2 つのことが保証されます。 アリスが作成したこと 公開鍵とプライベート鍵はペアになっています。ある公開鍵で復号できた暗号データを 作れるのは、ペアになっているプライベート鍵をもっている人だけです。この場合では、 復号につかった公開鍵と対応するプライベート鍵をもっているのはアリスです。したが って、アリスが iii を作ったことが保証されます。 改ざんがされていないこと 復号して得たダイジェストと、本文から計算したダイジェストが一致するからです。本 文を改ざんされた場合、受け取った本文から計算したダイジェストは異なるものなりま す。2 つが一致するということは、改ざんされていない証拠となります。
13
14 1.2.4. 公開鍵を信頼するために 公開鍵を使った暗号方式では公開鍵の所有者が、誰なのか信頼できる仕組みが必要です。 もし、イブが作った公開鍵を、「アリスの公開鍵です」と偽って公開し、みんなが信頼し てしまうと、アリスだけが復号できるつもりで作成した暗号文がイブによって復号され、 メッセ－ジを盗み見られてしまいます。あるいは、イブは、アリスがデジタル署名をした ことにして、メッセージを送信することができてしまいます。 したがって、「暗号化」と「デジタル署名」が有効に機能するためには、持ち主が保証さ れた公開鍵の入手が前提となります。ここでは、持ち主を保証して、信頼できる公開鍵の 流通を助けるの組みをとして、PKI と PGP を紹介します。 1.2.4.1. PKI（公開鍵基盤）2 (1) 信頼のモデル HTTP の通信でセキュリティを高めるために、PKI は、よく使われている技術です。Web サイトを認証して、Web サイトとブラウザ間の伝送データが暗号されます。 PKI は公開鍵の持ち主を保証するために、認証局とよばれる、データを送受信する当事者 とは別に第三者機関を導入した仕組みです。認証局では、公開鍵の持ち主を確認して、公 開鍵と持ち主の情報の組み合わせにデジタル署名をします。これを公開鍵証明書と呼びま す。以下にPKI における認証の仕組みを示します。 i. 利用者はルート認証局（最上位の署名者）の公開鍵を絶対安全な方法によって入手し、（あ らかじめ持っていて）信頼しています。 ii. ルート認証局は、下位の認証局の公開鍵に署名を付けた公開鍵証明書を発行します。 このような環境を前提として、利用者は次のように公開鍵を配布します。 iii. A さんは、認証局 A に公開鍵を提出します。認証局 A は、提出した人が A さんであるこ とを確認した後、A さんの公開鍵と名前などの持ち主情報を組み合わせたデータにデジタ ル署名を付けた電子データを作成します。これが、A さんの公開鍵証明書となります。 iv. A さんの公開鍵証明書を受け取った B さんや C さんは、まず認証局 A の公開鍵証明書の 署名を手元にあるルート認証局の公開鍵を使って検証します。認証局A の公開鍵として正 しいことがわかったなら、次にA さんの公開鍵証明書の署名を認証局 A の公開鍵を使って 検証します。 このように、認証局によって公開鍵の持ち主を保証する仕組みがPKI です。認証局がデジ 2 http://www.ipa.go.jp/security/pki/index.html
15 タル署名をつけることを、「証明書を発行する」と言います。認証局は、その証明書に示 されるデータが間違いなく本人のものであることを確認してから証明書を発行すること により、証明書の正しさを保証しているのです。 図 1-12 PKI での公開鍵の保証と検証の仕組み (2) ルート認証局 ルート認証局の公開鍵も、デジタル署名された公開鍵証明書によって流通します。しかし、 他の公開鍵証明書とことなり、ルート認証局の公開鍵証明書はルート認証局自身のプライ ベート鍵によってデジタル署名されたものです。これを自己署名などと呼びます。自己署 名なので、他の公開鍵を使って検証することはできません。別の信頼できる手段で入手す る必要があります。 後述するWindows や Java では、初期状態でいくつかのルート証明書が予めインストール されます。 新たなルート証明書を配布する場合、次項の拇印(thumbprint , fingerprint)を使って確認 する方法が使われます。 (3) 拇印(thumbprint)、指紋(fingerprint) 公開鍵証明書をSHA.1 や MD5 などのメッセージダイジェスト関数の入力にして、得られ
16 たダイジェスト値を「拇印（thumbprint）」または「指紋(fingerprint)」と呼びます。SHA1 を使った場合、ダイジェスト値は20 バイト(160bit)なので、16 進の数字として表示する と、40 文字になります。 ダイジェスト値は、その入力データから一意にきまるので、初めて受け取った公開鍵証明 書は、その拇印の40 文字を、公開鍵の持ち主に問い合わせるなどして、公開鍵証明書の 正しさを確認することが出来ます。公開鍵証明書を扱うアプリケーションではほとんどの 場合、拇印を表示するユーザーインターフェイスがあります。 図 1-13 Windows の証明書プロパティでの拇印の表示
17 ルート認証局の公開鍵証明書を受け取ったときなどは、拇印を確認することが有効です。 そのためWindows では、図 1-13 のようにルート認証局の公開鍵証明書をシステムに取 り入れるときには確認画面が表示されます。画面に拇印が示されています。 図 1-14 Windows でルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面 (4) 証明書(公開鍵証明書、デジタル ID(R) a. X.509 公開鍵証明書 PKI で用いる公開鍵証明書は ITU-T で策定された X.509 に基づいています。X.509 は ISO/IEC で国際標準となっています。現在、広く流通している証明書は X.509 バージョ ン3（X.509v3）の仕様に準拠しています。また、X.509 をインターネットで利用するにあ たり、IETF が標準化を行い RFC32803が公開されています。 公開鍵証明書の中身ですが、図にあるように、公開鍵とその持ち主の情報が示されていま す。他に、発行元の認証局の名前、有効期間などが示されています。 図 1-15 公開鍵証明書の中身 X.509v3 拡張項目は、以下のような構造になっていて、証明書には複数の拡張項目を入れ ることができます。 3 http://www.ietf.org/rfc/rfc3280.txt ①証明書のシリアル番号 ②認証局の名前 ③証明書の有効期間 ④公開鍵の所有者の名前、メールアドレス等 ⑤公開鍵 ⑥X.509v3 拡張項目 ①～⑥までのダイジェストに認証局の秘密鍵をキーとし て公開鍵暗号で暗号化したデータ（認証局のデジタル署 名）
18 表 1-1 X.509v3 拡張項目 拡張項目の要素 内容 項目ID 拡張項目の識別子です 重要性 （重要または非重要） 重要となっていた場合、この項目の意味に応じ た処理が要求されていることを示します 値 項目の値です。 X.509v3 拡張項目では、公開鍵の使用法、次節でのべる失効リスト（CRL）がどこから入 手できるのかなどが示されています。 b. 公開鍵証明書の識別 暗号化データやデジタル署名データを受信した場合、だれ宛の暗号文か、だれがデジタル 署名をしたのか判断をする必要があります。そのためには、公開鍵証明に使われている「認 証局の名前」と「証明書のシリアル番号」の組み合わせで識別します。暗号化データやデ ジタル署名と一緒にこの識別データを送ることで、どの公開鍵証明書を使って復号するの か、デジタル署名の検証を行うのかわかる仕組みとなっています。 c. 基本制約 X.509v3 拡張項目の１つとしてよく使われるものに「基本制約」があります。これは、TRUE ／FALSE で表され、認証局である場合、TRUE となっています。認証局でない、通信の 当事者である利用者やSSL サーバーなどの要素はエンドエンティティと呼ばれます。エン ドエンティティの証明書の場合、この基本制約がないか、値がFALSE となっています。 d. 公開鍵の使用法 電子メールやWeb ブラウザなどのアプリーケーションソフトウェアでは下の図のよう に、証明書から公開鍵を取り出し、デジタル署名の検証や暗号化に使っています。
19 図 1-16 通信相手の公開鍵証明書にある公開鍵を、デジタル署名の検証や、暗号化を行います PKI の枠組みでは、認証局は公開鍵を何に使用できるのか証明書に示しています。これを 鍵使用法と言います。最近の公開鍵証明書ではX.509v3 拡張項目の１つとしてこの鍵使用 法が示されています。その場合、証明書利用者（アプリケーション）では、鍵使用法の範 囲で利用しなければなりません。 表 1-2 公開鍵の使用法 識別名称 意味 digitalSignature デジタル署名の検証に利用します。 nonRepudiation 否認防止を目的とした、デジタル署名の検証に利用します。 keyEnciperment 秘密鍵（共通鍵）などの鍵の暗号化に利用します。 dataEncipherment データの暗号化に利用します。
keyAgreement Diffie-Hellman 公開鍵アルゴリズムなどによる鍵合意(Key Agreement) に利用します。
keyCertSign 証明書の署名を検証するために利用します。認証局の証明書のみ有効で す。
20 (5) 証明書ポリシー
公開鍵証明書を発行するとき、認証局の証明書に関するポリシーを証明書に記載します。 X.509 v3 拡張の「証明書ポリシー」に、ポリシーの識別子やポリシーを示している Web サイトのURL などが記載されます。
Mozilla Firefox や Mozilla Thunderbird では図のように X.509 v3 拡張の「証明書ポリシ ー」の内容が表示されます。
図 1-17 Firefox、Thunderbird の証明書ビューアでの証明書ポリシーの表示
Windows の証明書ストアでは「証明書ポリシー」の URL がある場合、「発行者のステー トメント」ボタンが有効になり、クリックするとアクセスします。
21
22 (6) 証明書チェーン（Certificate Chain）
PKI では、最上位にルート認証局を持った階層構造になっています。ルート認証局 － 認証局 － ユーザー のように、階層的なつながりで、下位の公開鍵証明書を発行して います。これを「証明書チェーン」あるいは「認証パス」などといいます。
図 1-19 は Windows での認証パスの表示です。図 1-20 は Mozilla Firefox、および Mozilla Thunderbird での証明書チェーンの表示です。Windows では「証明のパス」、Mozilla Firefox、および Mozilla Thunderbird で「証明書の階層」と表現していますが同じもので す。
23
24 (7) 証明書の失効 プライベート鍵を紛失したり、盗難にあったり、公開鍵証明書に記載されている内容に変 更があったり、公開鍵証明書の信頼性が損なわるケースがあります。そのような場合、” 失効”を利用されないようにしなければなりません。認証局によって定められた所定の手続 きによって、失効の申請を行います。失効された証明書については、認証局が発行する失 効リスト（CRL）にシリアル番号を記載して周知されます。
(8) CRL(Certificate Revocation List、証明書失効リスト)
失効した証明書の存在を周知させるための電子データのことです。CRL には失効した証明 書のシリアル番号の一覧に、認証局がデジタル署名をしています。 一つのエントリは、認証局が証明書ごとに割り振ったシリアル番号とそのシリアル番号の 証明書が無効になった日付の組み合わせによりなります。失効の理由が記載されているも のもあります。 図 1-21 CRL の中身 ②と③に示されている日付が、CRL の有効期間を示します。③の示す時点で新しい、CRL が発行されます。したがって、ユーザーは常に有効なCRL を入手する必要があります。 CRL も公開鍵証明書と同様に ISO/IEC X.509 に基づいています。 ①CRL の発行者の名前 ②CRL の発行日 ③次回CRL 発行日 ④証明書のシリアル番号 ⑤無効になった日付 ④と⑤の組み合わせが無効になった証明書の数だけ続く ⑥電子署名上のデータのダイジェストに認証局の秘密鍵を鍵として公開鍵暗号で暗号 化したデータ
25 (9) CRL 配布点 CRL は通常は定期的に発行され、最新の失効の情報を通知します。利用者のアプリケーシ ョンは最新のCRL を入手する必要があります。そのために、認証局では、FTP や HTTP を使って、最新のCRL をネットワーク経由で取得できるように公開しています。CRL の 公開場所は証明書のX.509v3 拡張項目に「CRL 配布点」として URI が示されています。 図 1-22 CRL 配布点に記載された CRL のある URI
26 (10) 証明書署名要求(Certificate Signing Request)
利用者は、公開鍵データと自身の情報を認証局に提出し、公開鍵証明書の発行を依頼しま す。最初に利用者が認証局へ公開鍵を提示して証明書の作成を依頼することを、証明書署 名要求(Certificate Signing Request)と呼びます。証明書署名要求には PKCS#10 という標 準のフォーマットのデータを作成して提出します。
図にPKCS#10 のデータの中身を示します。ここで「付随する情報」としては、失効のと きに当事者であることを認証するために使うパスワードなどがあります。
後述するWeb ブラウザを使って開鍵証明書を取得する方法では、PKCS#10 のデータを自 動的に作成して、認証局のWeb サイトに送信しています。
(11) 証明書、失効リストのエンコード：ASN.14とBER5、DER6
証明書や失効リストの書式はX.509 で規定されています。X.509 で書式を示すのに使われ ている記法がASN.1 です。X.509 の書式に従い作成される公開鍵証明書は BER または DER と呼ばれる機種に依存しないエンコード方式でエンコードされバイナリデータとな ります。
ASN.1 の仕様は ITU-T X.680、X .681、X .682、X .683 で、BER と DER は X .690 です。 これらは、いずれも、ISO/IEC として国際標準となっています。
4 Abstract Syntax Notation One 5 Basic Encoding Rules
6 Distinguished Encoding Rules
所有者の名前、メールアドレスと公開鍵の組み合わせデータ に、所有者のプライベート鍵を使ったデジタル署名 所有者の名前、メールアドレス等 所有者の公開鍵 付随する情報 図 1-23 証明書署名要求のデータ(PKCS#10)の中身
27 1.2.4.2. PGP PGP とは、次節で紹介する S/MIME と同様に、メッセージを暗号化、メッセージにデジ タル署名を付加えたりする手順ですが、独自の公開鍵の信頼の仕組みを持ちます。 PGP での公開鍵の持ち主を保証する仕組みの概要を以下に示します。 i. A さんは B さんの公開鍵に署名します。 ii. A さんと C さん、D さんはお互いによく知っていて、公開鍵が間違いなく本人のものだと わかっています。 iii. C さん、D さんは、よく知らない B さんの公開鍵を初めて受けとります。本当に B さんの ものとして信頼していいのかわかりません。ですが、そこにはよく知っているA さんの署 名が付いています。そこで、この公開鍵は間違いなくB さんのものだと判断します 図 1-24 PGP の公開鍵の信頼のモデル このように、PGP はアプリケーションと一体となり鍵管理を行います。そのため、PKI のようにOS など稼働環境レベルではサポートされていません。
28 1.3. 電子メールのセキュリティ技術 ここでは、電子メールを保護するための3 つの技術について紹介します。 S/MIME S/MIME は電子メールのメッセージを暗号化したり、メッセージにデジタル署名を加え たりするインターネット標準のプロトコルです。電子メールのメッセージはS/MIME の 手順で暗号化、デジタル署名され、加工されたデータが電子メールとして送信されます。 ドメイン認証 ドメイン認証とは、メールを送信しているドメイン間で信頼性を保証するための技術の 総称です。ここのプロトコルについては、1.3.2 で解説します。 SSL メールサーバーの認証、メールサーバー利用者（クライアント）の認証を行い、伝送デ ータを暗号化するインターネット標準のプロトコルです。S/MIME とことなり、サーバ ーとクライアントの間の伝送データのみが暗号化されます。回線上は暗号化されていま すが、メールサーバーで転送、蓄積されるメッセージは暗号化されていません。 S/MIME と SSL は、いずれも PKI に基づく公開鍵証明書を使ったプロトコルです。
29 1.3.1. S/MME S/MIME は、先に述べた PKI による公開鍵証明書を使って暗号化やデジタル署名を行う プロトコルです。暗号化されたデータのフォーマット、デジタル署名のデータのフォーマ ットを取り決め、それをMIME と呼ばれる電子メールの書式に適応させる手順を規定し たインターネット標準のプロトコルです。7 a. 暗号化されたメールメッセージの中身 暗号化されたメールメッセージは、図 1-25 のような形式になっています。 受信者ごとのデータから識別データが自分宛のものを探し出し、そこについている暗号文 の作成に使った共通鍵暗号の秘密鍵を暗号化したデータを、プライベート鍵を使って復号 し、秘密鍵を得ます。次に秘密鍵を使って、暗号文を復号して平文を得ます。 図 1-25 暗号化されたメールメッセージの中身 b. デジタル署名のついたメールメッセージの中身 デジタル署名をつけたメッセージは、図 1-26 のような形式になっています。 署名者を識別するデータの証明書発行者名とシリアル番号から署名者の証明書が明らか になり、その証明書に含まれる公開鍵によって、暗号化されたデータを復号してダイジェ ストを得ます。それとは別に、平文から所定のメッセージダイジェスト関数を使ってダイ 7 （最新の仕様は、RFC3850、RFC3851、RFC3852 です。） http://www.ietf.org/rfc/rfc3850.txt、http://www.ietf.org/rfc/rfc3851.txt、 http://www.ietf.org/rfc/rfc3852.txt 暗号文 受信者ボブを識別するデータ (証明書発行者名+シリア ル番号) 暗号文の作成に用いた、暗号キーを受信者ボブの公開鍵を キーとして公開鍵暗号で暗号化したデータ 受信者アリスを識別するデータ (証明書発行者名+シリ アル番号) 暗号文の作成に用いた、暗号キーを受信者アリスの公開鍵 をキーとして公開鍵暗号で暗号化したデータ
30 ジェストを計算します。この2 つのダイジェストを比べ、一致していれば「メッセージの 作成者に偽りのないこと」「改ざんのないこと」が保証されます。 図 1-26 デジタル署名のついたメールメッセージの中身 c. デジタル署名と暗号化を組み合わせて使う 1 つのメッセージにデジタル署名と暗号化を行うともに行う場合の、送信側と受信側の処 理の流れをみてみましょう。 送信側 i. デジタル署名をします。 ii. デジタル署名のついたメッセージを入力として暗号化します。 受信側 iii. 受信したメッセージを復号して、デジタル署名されたメッセ－ジを得ます。 iv. デジタル署名を検証します。 メッセージ（平文） 署名者の識別データ (証明書発行者名+シリアル番号) ダイジェストを署名者のプライベート鍵を鍵として公開鍵暗 号方式で暗号化したデータ 署名者の証明書 （オプション）
31 図 1-27 デジタル署名と暗号化の組み合わせ d. デジタル署名と暗号化を組み合わせる 2 つの方法 デジタル署名と暗号化を1 つのメッセージに対して行う場合、２通りの方法が考えられま す。 (1) デジタル署名したデータを入力として暗号化（Sign-Then-Envelop） 受信側では、暗号文を復号しデジタル署名されたデータを得ます。その後、デジタル署名 の検証を行います。 図ではこの方法について説明しています。S/MIME ではこの方法が使われます。 (2) デジタル署名したデータと暗号化をしたデータを連結（Sign-And-Envelop） 受信側では、暗号文を復号して平文を得ます。 平文のダイジェストとデジタル署名中の暗号化されたダイジェストを復号し、比較および
32 検証を行います。
この方式は、PEM と呼ばれる S/MIME に似た古い手順で利用されており、S/MIME では PEM との互換のためにのみ用いられます。 e. 電子メールソフトでのサポート 後述するように、S/MIME は電子メールを保護するための標準の仕様として、多くの電子 メールソフトでサポートされています。利用者は、公開鍵証明書の取得し初期設定を行う だけで、デジタル署名や暗号化は設定に従って自動的に行われます。受信側のデジタル署 名の検証や暗号文の復号もほとんどのソフトウェアでは自動化、あるいはメニューのコマ ンドを1 つ実行するだけで実行され、その結果を知ることができます。 受信者ボブを識別するデータ (証明書発行者名+シリアル番 号) 暗号文の作成に用いた、暗号キーを受信者ボブの公開鍵をキ ーとして公開鍵暗号で暗号化したデータ 暗号文 署名者の識別データ (証明書発行者名+シリアル番号) ダイジェストを署名者のプライベート鍵を鍵として公開鍵暗 号方式で暗号化したデータ 署名者の証明書 （オプション） 図 1-28 デジタル署名したデータと暗号化をしたデータをくっつける。
33 1.3.2. ドメイン認証 a. フィッシング詐欺を防止するために 個人情報を盗用するフィッシング詐欺などでは、まず「なりすましメール」を送信して、 Web サイトに誘導する手法が多く使われています。「なりすましメール」を正しく検知 することができれば、電話などの方法で電子メールの送信元に内容を確認する必要性に思 い至るため、フィッシング詐欺の被害に会い難くなります。 電子メールは、そのシステム上本文はもとより送信者のメールアドレスなど、容易になり すますことができます。したがって電子メールを安全に利用するためには、より高度な技 術を利用して電子メール送信者の身元を保証する必要があります。 b. 送信ドメイン認証技術とは？ 「送信ドメイン認証技術」とは、電子メールを安全に利用するための方法の一つで、主に 「なりすましメールを防止する」ために用いられます。 正しく運用されているメールサーバーでは、そのメールサーバーで取り扱うべきメールア ドレスのメールの配送しか行なう事ができないように設定されています。このように正し く運用されているメールサーバーでは他人に｢なりすます｣ことができず、「なりすましメ ール」の送信者は、別のメールサーバーを使用せざるをえません。この「別のメールサー バーが利用された」事を検知する仕組みが「送信ドメイン認証技術」です。 送信ドメイン認証技術を利用すれば、受信者が「なりすましメール」の可能性のあるメー ルかどうかを判断する事も容易になりますし、また受信側のメールサーバーで受信を拒否 する事もできますので、電子メールのシステム全体として「なりすましメール」自体が送 りにくくなります。 c. 「送信ドメイン認証」の方式 現在利用されている「送信ドメイン認証」は、大きく分けて以下の二つの方式があります。 IP アドレス方式
SPF(Sender Policy Framework)/SenderID 電子署名方式
DomainKeys/DKIM(DomainKeys Identified Mail)
d. IP アドレス方式 送信者側
あらかじめ自分のドメインで使用するメールサーバーのリストを DNS を用いて公開 します。
34 受信者側 送信してきたメールの送信者アドレスのドメイン部分を基に、DNS からそのドメイン のメールサーバーのリストを得ます。 実際に送信してきたメールサーバーが DNS から受け取ったリストの中にあるかない かを判断します。 図 1-29 「IP アドレス方式」を用いた送信ドメイン認証の流れ ここで受信者側のメールサーバーは、不正なメールの場合に受信を拒否する事もできます し、受信したメールのヘッダーに認証結果を追加して、その判断を受信者に委ねる事もで きます。 認証結果を表示したヘッダーの例 Authentication-Results: spf=pass (SPF 認証に成功したメール) Authentication-Results: spf=fail (SPF 認証に失敗したメール) Authentication-Results: spf=none (送信者側が SPF を使っていないメール) 実際には、認証結果のほかに「認証を行ったサーバー」「メールの送信元サーバー」「そ の他の認証方法の結果」などが含まれています。
35 e. 電子署名方式 送信者側 自ドメイン用のプライベート鍵と公開鍵の組を作成します。 作成した公開鍵を DNS を用いて公開します。 作成したプライベート鍵をメールサーバーにインストールします。 電子メールを送信する際には、送信側のメールサーバーがプライベート鍵を用いて電子 メールに署名を行います(署名情報のメールヘッダーを追加します)。 受信者側 署名の部分からドメイン情報を抽出します。 抽出されたドメイン情報から DNS を用いてそのドメインの公開鍵を取得します。 取得した公開鍵で署名を検証します。 図 1-30 「電子署名方式」を用いた送信ドメイン認証の流れ ここで受信者側のメールサーバーは、不正なメールの場合に受信を拒否する事もできます し、受信したメールのヘッダーに認証結果を追加して、その判断を受信者に委ねる事もで きます。 認証結果を表示したヘッダーの例 Authentication-Results: domainkey=pass (署名が正しく認証できたメール) Authentication-Results: domainkey=neutral (署名が存在しないメール) Authentication-Results: domainkey=permerror (設定が間違っているため認証できない メール) 実際には、認証結果のほかに「認証を行ったサーバー」「メールの送信元サーバー」「そ
36 の他の認証方法の結果」などが含まれています。 f. 「送信ドメイン認証技術」の利用例 これらの「送信ドメイン認証技術」は、現在では多くの ISP 等で採用されています。 SPF/SenderID を利用している主な ISP Yahoo! Hotmail i モード EZweb WILLCOM IIJ ぷらら BIGLOBE DomainKeys/DKIM を利用している主な ISP Yahoo! Gmail IIJ 図 1-31 Yahoo!メール での送信ドメイン認証の結果表示 g. その他の「送信者認証」との比較 「なりすましメール」を防止する方法としては、その他にも「S/MIME, PGP(GPG)」と いった電子メールそのものを検証する技術があります。これらの技術も、電子メールの送 信者が正しいかどうかを特定する事ができますので、「なりすましメール」などの対策に
37 は非常に有効です。また、「送信ドメイン認証」では、ドメイン単位での検証しか行う事 ができませんが、これらの手法では個々の送信者ごとの検証を行う事ができます。 ただし、これらの手法の場合、受信者側が電子メールの発信者の公開鍵を入手し、電子メ ールの検証を行うことになります。専用ソフトウェアなどの導入も必要になりますので、 全てがサーバー側の処理で検証が行われる「送信ドメイン認証」の方が、導入が容易とい えます。
38 1.3.3. SSL/TLS (1) SSL/TLS8の概要 Web サイトのセキュリティ対策として、サーバーの認証と伝送路の暗号化のために使われ るSSL/TLS プロトコルは、同様に電子メールのサーバーとクライアント（電子メールソ フト）の間でも利用されます。 クライアントはサーバーが用意したSSL/TLS に対応した通信ポートに接続を試みます。 すると認証、暗号化用の秘密鍵の交換が行われ、アプリケーションの通信が始まります。 このステップをSSL/TLS のネゴシエーションと呼びます。以下に SSL/TLS のネゴシエー ションの概要を説明します。 a. サーバー認証 SSL/TLS では、Web サイトとのデータの送受信やメールサーバーとのデータの送受信に 先立ち、サーバー、クライアント双方の認証を行います。クライアントの認証はオプショ ンですが、サーバー認証は必須です。サーバーはデジタル署名データを送り、デジタル署 名データを受信したクライアントでは、デジタル署名を検証し、サーバーの認証を行いま す。 b. クライアント認証 通信の開始にあたり、サーバーはクライアントを認証するために、クライアントにもデジ タル署名を要求する場合があります。この場合、サーバーは信頼している認証局の名称を クライアントに送ります。クライアントでは、該当する認証局が発行した証明書でデジタ ル署名をして、そのデータをサーバーに送ります。サーバーでは受信した署名データを検 証することによりクライアントの認証を完了します。クライアントが、要求された認証局 が発行した証明書を持っていない場合、クライアント認証は失敗し、以降の通信は成立し ません。 c. 伝送データの暗号化用の秘密鍵の交換 認証のフェーズが完了し信頼できる相手の公開鍵を入手すると、次は、以降の暗号化通信 に使う秘密鍵を公開鍵で暗号化して送ります。以降は復号したその秘密鍵を使って、双方 から発信する伝送データを暗号化します。 まずSSL/TLS では通信の開始にあたり、認証を完了し、秘密鍵を交換します。これによ 8 SSL は Netscape 社が考案したプロトコルです。TLS は、SSL バージョン 3 の仕様をもとにインターネ ット標準化組織IETF で策定されたプロトコルです。基本的な手法は同じため、SSL/TLS のように併記さ れますが、実際にはSSL あるいは TLS いずれかのプロトコルに沿って通信が実施されます。
39 り交換した秘密鍵を使って、以降の伝送データを暗号化します。SSL/TLS 自体はアプリケ ーションのプロトコルではないので、通信する双方の認証が完了し暗号化する準備ができ ると、HTTP、SMTP、POP3、IMAP、LDAP などのアプリケーションのプロトコルで通 信するデータが用意され、データが暗号化されて通信経路上を伝わっていきます。 このようにSSL/TLS は、S/MIME やドメイン認証と異なりアプリケーションのデータを 暗号化するものではなく、サーバーとクライアントのノード間の伝送データを暗号化する ものです。したがって、SSL/TLS をサポートした SMTP サーバーを使って電子メールを 送った場合、送信者とSMTP サーバーとの間の経路上は暗号化されたデータが伝わります が、SMTP サーバーからの先の相手に届くまでのまいだに経由する伝送路では暗号化され ません。 (2) SSL/TLS の電子メールプロトコルへの適用 電子メールにSSL/TLS を適用させた標準のプロトコルを表に示します。 表 1-3 SSL/TLS を使った電子メールのプロトコル名 メールサーバー SSL/TLS を使ったプロトコル名 ポート番号 送信（SMTP）サーバー SMTP over SSL 465 送信（SMTP）サーバー STARTTLS 25
受信（POP）サーバー POP over SSL 995
受信（POP）サーバー STARTTLS 110
受信（IMAP4）サーバー IMAP over SSL 993
受信（IMAP4）サーバー STARTTLS 143
a. SMTP over SSL、POP over SSL、IMAP4 over SSL
Web サイトのアクセスに使われる HTTP と HTTPS の関係と同様です。 これらをサポートするサーバーは、標準のポート以外にSSL 用のポートを別に用意します。 クライアントは、接続先にSSL ポートを指定し最初から SSL のポートにアクセスします。 アクセス時にサーバーとクライアントの間でSSL のネゴシエーションを実施します。 ネゴシエーションが完了すると、サーバーはSSL のポートで受けた暗号化データを復号し ます。復号した結果のデータはアプリケーションのポートに転送され、アプリケーション は必要な処理をするとSSL のポートを経由してクライアントに送ります。 b. STARTTLS SMTP、POP、IMAP4 などで利用されており、標準のプロトコルに機能を追加したもの です。ここではSMTP を例として処理の概要を説明します。 クライアントがSMTP の標準のポート(25)にアクセスし SMTP セッションの開始をする 際、サーバーはSTARTTLS をサポートしていることを通知します。（運用ポリシーによ
40
っては、STARTTLS のみに制限する場合もあります）クライアントが STARTTLS をサ ポートしていれば、TLS のネゴシエーションを開始します。ネゴシエーションが完了する と、TLS による暗号化通信を開始します。
41 1.4. セキュリティ技術の使い分け 前節で紹介したそれぞれの技術の適用箇所を電子メールのエンドツーエンドでみると図 のようになります。 S/MIME 電子メールのメッセージ自体を暗号化あるいはデジタル署名を付けてメッセージを加 工した結果を送信します。そのため受信者に加工されたメッセージが届き、復号や署名 の検証を実施するのは受信者です。このようにエンドツーエンドでメッセージが保護さ れています。反面、通信の当事者が公開鍵証明書を入手する必要があり、導入後の管理 や有効期限ごとに更新の手続きなどの煩雑さもあり、導入を困難にする面があります。 ～ゲートウエイ型S/MIME 処理～ 前述のように、企業などでS/MIME を導入しようとすると、エンドユーザーが個々に公 開鍵証明書を管理することになります。そのような困難さを解決するためにメールサー バーと連動してS/MIME 処理を行うゲートウエイ型の製品がいくつかあります。 これらの製品では、証明書やプライベート鍵の管理もサーバーで行うことで、利用者の 電子メールソフトの設定に何ら変更をくわえることなく、送受信した電子メールに対し、 S/MIME によるデジタル署名や暗号化の処理が行われます。9 ドメイン認証 電子メールを中継したドメインを保証する仕組みです。信頼できないドメインからのメ ールをドメイン単位で拒絶することができます。これはドメインを信頼するための仕組 みですので、転送されてくるメール自体は保護されません。 SSL/TLS メールサーバーとクライアントの間で認証をし、メールサーバーとクライアントの間の 伝送データを暗号化する仕組みです。回線上は暗号化されていますが、メールサーバー で蓄積されるメッセージや、外部のサーバーに転送されるメッセージ自体は暗号化など の保護はされません。 いずれも公開鍵暗号を使った仕組みで、S/MIME と SSL/TLS は、ともに PKI に基づく公 開鍵証明書を使った仕組みです。 ドメイン認証、SSL/TLS がサーバー側の対策であるのに対して S/MIME は利用者が行う 9 製品によって、送信メールにデジタル署名をするものもから、送信メールに暗号化を行うもの、受信し たS デジタル署名メールの検証、暗号化メールの復号までを行いものまであります。
42
対策です。以降、本書では、通信の当事者同士が安全なコミュニケーションを確立する方 法として、S/MIME を中心に説明します。
