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. 証明書の実例 ............................................................................................................ 167

ii

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-12 PKI での公開鍵の保証と検証の仕組み .......................................................................... 15

図 1-13 WINDOWS の証明書プロパティでの拇印の表示 ............................................................. 16

図 1-14 WINDOWS でルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面 ... 17

図 1-15 公開鍵証明書の中身 ...................................................................................................... 17

図 1-16 通信相手の公開鍵証明書にある公開鍵を、デジタル署名の検証や、暗号化を行います

........................................................................................................................................ 19

図 1-17 FIREFOX、THUNDERBIRD の証明書ビューアでの証明書ポリシーの表示 .................... 20

図 1-18 WINDOWS 証明書ストアで証明書ポリシーがあり「発行者のステートメント」が有効に

なっている。 ................................................................................................................... 21

図 1-19 WINDOWS での証明書チェーン（証明のパス）の表示 .................................................. 22

図 1-20 MOZILLA FIREFOX、 MOZILLA THUNDERBIRD での証明書チェーン（証明書の階層）の表

示 ..................................................................................................................................... 23

図 1-21 CRL の中身 .................................................................................................................... 24

図 1-22 CRL 配布点に記載された CRL のある URI .................................................................. 25

図 1-23 証明書署名要求のデータ(PKCS#10)の中身 .................................................................. 26

図 1-24 PGP の公開鍵の信頼のモデル ....................................................................................... 27

図 1-25 暗号化されたメールメッセージの中身 ......................................................................... 29

図 1-26 デジタル署名のついたメールメッセージの中身 ........................................................... 30

図 1-27 デジタル署名と暗号化の組み合わせ ........................................................................... 31

図 1-28 デジタル署名したデータと暗号化をしたデータをくっつける。 ................................. 32

図 1-29 「IP アドレス方式」を用いた送信ドメイン認証の流れ .............................................. 34

図 1-30 「電子署名方式」を用いた送信ドメイン認証の流れ .................................................... 35

図 1-32 SSL/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-11 MOZILLA 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-2 WINDOWS のレジストリの CSP の情報 ........................................................................... 63

図 3-3 セクリティトークンのユーティリティプログム ............................................................. 64

図 3-4 INTERNET EXPLORER で鍵生成のデバイスを選択するところ ....................................... 65

図 3-5 FIREFOX PKCS#11 デバイスの追加画面 ......................................................................... 66

図 3-6 FIREFOX PKCS#11 デバイスマネージャ画面 ................................................................. 66

図 3-7 FIREFOX セキュリティトークンへ PIN 入力画面 ............................................................ 67

図 3-8 FIREFOX セキュリティデバイスの選択画面..................................................................... 67

図 4-1 WEB サイトでの証明書の申請 ......................................................................................... 71

図 4-2 WEB サイトで証明書の申請の完了 .................................................................................. 73

図 4-3 WEB サイトでの証明書の申請が完了し、その後の手順について、電子メールでの確認な

どを促している画面 ........................................................................................................ 74

図 4-4 証明書の発行が完了した旨を告げる電子メール ............................................................. 74

図 4-5 WEB サイトから証明書のインストール ........................................................................... 75

図 4-6 米国コモドの証明書発行サービスの WEB サイト ........................................................... 76

v

図 4-7 PEM 形式の証明書 .......................................................................................................... 80

図 4-8 WINDOWS の証明書管理 ................................................................................................... 82

図 4-9 WINDOWS の証明書の詳細表示画面 ............................................................................... 83

図 4-10 WINDOWS での CRL（失効リスト）の表示画面 ........................................................... 84

図 4-11 WINDOWS メールのセキュリティ設定画面 .................................................................... 86

図 4-12 WINDOWS メールのセキュリティの詳細設定画面 ......................................................... 87

図 4-13 WINDOWS メールのアカウントごとの設定 .................................................................... 89

図 4-14 WINDOWS メールの証明書の選択画面 ........................................................................... 90

図 4-15 WINDOWS アドレス帳の連絡先の人のプロパティの証明書のページ ........................... 91

図 4-16 WINDOWS メールで、ディレクトリサーバーの検索条件を入力する画面 ..................... 92

図 4-17 WINDOWS メールでディレクトリの検索結果から証明書を確認します。 ................... 93

図 4-18 WINDOWS メールでメッセージの作成でデジタル署名を指定します。 ........................ 94

図 4-19 WINDOWS メールでメッセージの作成で暗号化を指定します。 ................................... 94

図 4-20 WINDOWS メールでメッセージの作成でデジタル署名と暗号化を指定します。 .......... 95

図 4-21 WINDOWS メールでデジタル署名付きメールを受信したときの画面 ............................ 95

図 4-22 WINDOWS メールで暗号化されたメッセージを受信したときの画面 ............................ 96

図 4-23 WINDOWS メールでデジタル署名と暗号化されたメッセージを受信したときの画面 ... 96

図 4-24 WINDOWS メールでデジタル署名と暗号化されたメッセージの内容画面 ................... 97

図 4-25 WINDOWS メールの証明書の確認画面 ........................................................................... 99

図 4-26 WINDOWS メールで不正なメッセージを受信したときの画面 ..................................... 100

図 4-27 OUTLOOK 2007 のセキュリティ設定画面 .................................................................... 101

図 4-28 OUTLOOK 2007 のセキュリティの詳細設定画面 ......................................................... 102

図 4-29 OUTLOOK 2007 のセキュリティラベルを付けるためのポリシーモジュール選択画面 103

図 4-30 OUTLOOK 2007 アドレス帳の証明書のページでは証明書のインポートが可能です。105

図 4-31 OUTLOOK 2007 のメッセージ作成画面でのデジタル署名と暗号化の指定 ................. 106

図 4-32 OUTLOOK 2007 のメッセージ作成画面でのメッセージオプションのセキュリティ設定

...................................................................................................................................... 107

図 4-33 OUTLOOK 2007 でデジタル署名付きメッセージを表示しています。 ......................... 108

図 4-34 OUTLOOK 2007 で暗号化されたメッセージを復号して表示しています。 ................. 109

図 4-35 OUTLOOK 2007 でデジタル署名と暗号化されたメッセージを復号して表示しています。

...................................................................................................................................... 110

図 4-36 OUTLOOK 2007 の メッセージのセキュリティのプロパティ画面 ............................... 111

図 4-37 OUTLOOK 2007 で表示される受信したメッセージの暗号化の情報 ............................ 112

図 4-38 OUTLOOK 2007 で表示される受信したメッセージのデジタル署名の情報 ................. 113

図 4-39 THUNDERBIRD の証明書管理 ....................................................................................... 114

図 4-40 THUNDERBIRD の証明書マネージャ ............................................................................. 115

vi

図 4-41 MOZILLA THUNDERBIRD の証明書の信頼性の設定 ...................................................... 116

図 4-42 THUNDERBIRD での認証局証明書の信頼性の設定 ....................................................... 117

図 4-43 THUNDERBIRD の失効リストマネージャ ..................................................................... 117

図 4-44 THUNDERBIRD の CRL の取得先 URI の指定画面 ....................................................... 118

図 4-45 THUNDERBIRD の CCRL 自動更新の設定画面 ............................................................. 118

図 4-46 THUNDERBIRD の OCSP の利用に関する設定 ............................................................. 119

図 4-47 THUNDERBIRD のセキュリティデバイスの設定........................................................... 120

図 4-48 THUNDERBIRD のアカウント設定のセキュリティ設定 ............................................... 121

図 4-49 THUNDERBIRD でデジタル署名用、暗号化用の証明書の選択画面.............................. 122

図 4-50 THUNDERBIRD のメッセージ作成画面でのデジタル署名と暗号化の指定 ................... 123

図 4-51 THUNDERBIRD でデジタル署名付きで暗号化されているメッセージを表示しています。

...................................................................................................................................... 124

図 4-52 THUNDERBIRD で受信したメッセージのデジタル署名と暗号化の情報を表示 ........... 124

図 4-53 THUNDERBIRD で受信したメッセージのデジタル署名で不正が検出された場合 ........ 125

図 4-54 THUNDERBIRD で受信したメッセージのデジタル署名の不正の説明 .......................... 125

図 4-55 メイン画面とメール作成画面の「ツール」メニューに S/MIME の指定があります。

...................................................................................................................................... 126

図 4-56 BECKY! INTERNET MAIL の S/MIME 設定 ................................................................... 127

図 4-57 BECKY! INTERNET MAIL で「S/MIME:署名と暗号化」を実行したところ ................. 128

図 4-58 BECKY! INTERNET MAIL で「S/MIME: 暗号化」または「S/MIME: 署名と暗号化」を実

行した後、SMIME.P7M という添付ファイルが追加される ........................................... 128

図 4-59 BECKY! INTERNET MAIL で「S/MIME: 署名」を実行した後、SMIME.P7S という添付フ

ァイルが追加される ...................................................................................................... 128

図 4-60 BECKY! INTERNET MAIL で受信したメッセージのデジタル署名と暗号化の情報を表示

...................................................................................................................................... 129

図 4-61 BECKY! INTERNET MAIL で受信したメッセージの改ざんを検出 ................................ 129

図 4-62 BECKY! INTERNET MAIL で信頼しているルート認証局までの証明書チェーンがつながら

ない場合。 .................................................................................................................... 130

図 4-63 BECKY! INTERNET MAIL で証明書が添付されていないデジタル署名を検証した結果 130

図 4-64 WINBIFF＋S/GOMA ユーザー設定／暗号画面 ............................................................. 131

図 4-65 WINBIFF＋S/GOMA 証明書一覧 .................................................................................... 132

図 4-66 WINBIFF＋S/GOMA セキュリティ設定／S/MIME オプション設定画面 ..................... 133

図 4-67 WINBIFF＋S/GOMA セキュリティ設定／詳細画面 ...................................................... 135

図 4-68 WINBIFF＋S/GOMA セキュリティ設定／ディレクトリサーバー画面 ....................... 136

図 4-69 WINBIFF＋S/GOMA の認証局一覧画面 ..................................................................... 138

図 4-70 WINBIFF＋S/GOMA のディレクトリサーバーへの検索の流れ ..................................... 140

vii

図 4-71 WINBIFF の「送信の確認」画面 .................................................................................. 141

図 4-72 WINBIFF の暗号化、デジタル署名の結果確認画面 ..................................................... 142

図 4-73 WINBIFF + S/GOMA での復号や署名検証の結果の確認画面 ...................................... 143

図 4-74 WINBIFF + S/GOMA での復号や署名検証の結果の確認画面で不正な電子署名であった場

合 ................................................................................................................................... 144

図 4-75 MAC OS X キーチェーンの公開鍵証明書管理機能 ...................................................... 145

図 4-76 MAC OS X の“MAIL”で新規メッセージ画面での暗号化、デジタル署名の指定 .......... 146

図 4-77 MAC OS X の“MAIL”で復号や署名検証の結果の表示 ................................................ 147

図 4-78 MAC OS X の“MAIL”で復号や署名検証の結果、不正な電子署名であった場合 .......... 147

図 5-1 WINDOWS 証明書ストアの一覧表示 .............................................................................. 151

図 5-2 プライベート鍵と証明書を一緒にエクスポートします。 （WINDOWS ではプライベート

鍵を秘密キーと表記しています） ................................................................................ 152

図 5-3 証明書チェーン上の証明書も一緒にエクスポートします。 ......................................... 153

図 5-4 エクスポートするプライベート鍵を、パスワードを鍵として暗号化して保護します。

...................................................................................................................................... 154

図 5-5 最後にエクスポートするファイル名を指定します。 .................................................... 155

図 5-6 MAX OS Ⅹのキーチェーンアクセス ............................................................................. 156

図 5-7 THUNDERBIRD の「証明書の表示」 ............................................................................... 157

図 5-8 S/MIME に対応していない電子メールソフトでは添付ファイル付きのメールとして扱わ

れる。............................................................................................................................ 158

図 5-9 WINDOWS でルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面 ... 160

図 7-1 処理の流れと標準仕様 ................................................................................................... 164

図 7-2 J2RE の証明書管理機能 ................................................................................................ 172

図 7-3 J2RE の証明書の詳細表示画面...................................................................................... 173

表 1-1 X.509V3 拡張項目 ............................................................................................................ 18

表 1-2 公開鍵の使用法 ................................................................................................................ 19

表 1-3 SSL/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

図 1-11 デジタル署名の仕組み （メッセージダイジェスト関数と公開鍵暗号を組み合わせて使います。）

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 証明書の署名を検証するために利用します。認証局の証明書のみ有効で

す。

cRLSign CRL(証明書失効リスト)の署名を検証するために利用します。

20

(5) 証明書ポリシー

公開鍵証明書を発行するとき、認証局の証明書に関するポリシーを証明書に記載します。

X.509 v3 拡張の「証明書ポリシー」に、ポリシーの識別子やポリシーを示している Web

サイトの URL などが記載されます。

Mozilla Firefox や Mozilla Thunderbird では図のように X.509 v3 拡張の「証明書ポリシ

ー」の内容が表示されます。

図 1-17 Firefox、Thunderbird の証明書ビューアでの証明書ポリシーの表示

Windows の証明書ストアでは「証明書ポリシー」の URL がある場合、「発行者のステー

トメント」ボタンが有効になり、クリックするとアクセスします。

21

図 1-18 Windows証明書ストアで証明書ポリシーがあり「発行者のステートメント」が有効になっている。

22

(6) 証明書チェーン（Certificate Chain）

PKI では、最上位にルート認証局を持った階層構造になっています。ルート認証局 －

認証局 － ユーザー のように、階層的なつながりで、下位の公開鍵証明書を発行して

います。これを「証明書チェーン」あるいは「認証パス」などといいます。

図 1-19 は Windows での認証パスの表示です。図 1-20 は Mozilla Firefox、および Mozilla

Thunderbird での証明書チェーンの表示です。Windows では「証明のパス」、Mozilla

Firefox、および Mozilla Thunderbird で「証明書の階層」と表現していますが同じもので

す。

図 1-19 Windows での証明書チェーン（証明のパス）の表示

23

図 1-20 Mozilla Firefox、 Mozilla Thunderbird での証明書チェーン（証明書の階層）の表示

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 を中心に説明します。

図 1-32 SSL/TLS、ドメイン認証、S/MIME それぞれがカバーする領域

43

2. 不正とその検出方法

2.1. 公開鍵証明書の有効性

デジタル署名や暗号化に使われる公開鍵は、『持ち主』つまり対応するプライベート鍵を

持っていて暗号データの復号ができる人間が『誰であるか』が保証されなければなりませ

ん。この保証は、PKI という枠組みを使い認証局が本人確認をしたのち公開鍵証明書を発

行するという手順により実現されています。

本人確認10は認証局の役割ですが、証明書のデジタル署名に問題がないか確認するのは利

用者側のアプリケーションの役割です。また、認証局は公開鍵証明書を発行するにあたり

いくつかの制約をつけることがあります。その制約に則ったものが有効な公開鍵証明書で

あり、その制約に従って使われなければなりません。

ここでは、有効性を確認するポイントと利用者側のアプリケーションが無効な証明書をど

のように表すかを示します。利用者側のアプリケーションとして、Windows 標準の証明

書管理機能11を使って説明します。

10証明書発行のサービスを運営する場合、本人確認の確実性の度合いに応じてサービスを分けて運営するこ

とがあります。ベリサイン社では、本人確認の確実性の度合いを 4 つに分類し、簡単なレベルから順にク

ラス 1 からクラス 4 に分けています。 11 Windows での証明書管理機能の詳細は 「4.3.1. マイクロソフト Windows での証明書の管理」を参照

してください。

44

(1) 認証局のデジタル署名が正しいか

証明書には、認証局のデジタル署名がついています。証明書の所有者名などの記載内容が

改ざんされているような場合、このデジタル署名は不正となります。そのような場合、図

のように証明書に不整合があることが通知されます。

図 2-1 証明書にある認証局のデジタル署名が正しくなかった場合

45

(2) 信頼しているルート認証局まで、証明書チェーンができているか

Windows 標準の証明書管理機能には、証明書のデータベースがあります。対象とする証

明書から、ルート認証局までの階層上のすべての証明書が証明書データベースに存在しな

い場合、証明書の署名が検証できないので、証明書の正しさが確認できません。その場合、

その証明書は信頼することはできません。図では、対象とする証明書の発行元の認証局の

証明書がデータベースに存在しないため、情報不足として警告を表示しています。

図 2-2 信頼しているルート認証局まで、証明書チェーンができない場合

証明書チェーンが確認できないので、「証明書のパス」タブのページで図のように表示さ

れます。

46

図 2-3 証明書チェーンができない場合の表示

証明書チェーンができていると、「証明書のパス」タブのページで図の用に証明書チェー

ン上の認証局名がツリー状に表示されます。

図 2-4 証明書チェーンができた場合の表示

47

(3) 証明書が有効期間内であるか

証明書には、発行元の認証局の認めた有効期間の開始日時と終了日時が示されています。

システムの時刻がその範囲にない場合、無効な証明書として判断します。

図 2-5 有効期限内にない証明書

48

(4) 証明書ポリシー（CP）と認証実施規定（CPS）が適切であるか

認証局では証明書を発行する業務にあたり、所有者確認の程度など信頼性の保証の度合い

を決め、証明書発行のポリシーとして策定します。このポリシーを識別するために、ユニ

ークなオブジェクト ID を決めます。また、そのポリシーを成立させるための運用規定を

定めます。これを CPS（Certification Practice Statement）と呼び、Web で公開するな

どオープンにする必要があります。当該のポリシーに基づき発行された証明書には、証明

書ポリシーがオブジャクト ID として記載され、CPS へのアクセスが URI として示されま

す。証明書ポリシーがある証明書では、「全般」タブのページの「発行者のステートメン

ト」ボタンが有効となります。このボタンをクリックすると、Web ブラウザが起動し当該

の URI が表示されます。

図 2-6 証明書ポリシー

49

(5) 認証局が制約した鍵の使用法に則っているか

鍵使用法（キー使用法）には、Digital Signature, Key Encipherment などのように記載

されています。Digital Signature はデジタル署名の作成とデジタル署名の検証に使えると

いうことであり、Key Encipherment はメッセージの暗号化に使った暗号化されている秘

密鍵を復号するために使うことができるよいうことを示しています。

図 2-7 証明書の鍵使用法

50

(6) 証明書が失効していないか

対象となる証明書発行元（認証局）が発行した失効リスト（CRL）を確認し、失効されて

いないことを確認します。アプリケーションは、証明書の CRL 配布点を参照して最新の

CRL を取得します。CRL を所得する手順については、「1.2.4.1 PKI（公開鍵基盤）」の

「(9)CRL 配布点」を参照してください。

図 2-8 失効している証明書

51

2.2. 電子メールにおけるデジタル署名による不正の検出

デジタル署名とは、A さんが「私が電子メールを送る際にはメールにデジタル署名をつけ

るので、私のデジタル署名がない場合には、仮に私が発信者のように見えてもそのメール

を信頼しないでね。」と宣言することから始まります。以降、その人からのメールでデジ

タル署名がない場合、フィッシングメールなど偽りのメールと判断できます。

では、デジタル署名がされていれば、全て信頼できるのでしょうか？ いえ、そうではあ

りません。デジタル署名がされていた場合でも、不正なメールはあります。そのため、電

子メールソフトでは、不正なデジタル署名を検出する仕組みが組みこまれています。

Outlook Express 6 では、デジタル署名されたメールで不正を検出すると、本来メッセー

ジの本文が表示される画面が「セキュリティ警告」画面となります。電子メールソフトご

とのデジタル署名の検証結果の表示方法については、「4.4」のそれぞれの電子メールの節

を参照してください。

図 2-9 マイクロソフト Outlook Express バージョン 6 でのデジタル署名の不正を検出した画面

Outlook 2007 では、メッセージの題名、送信者名の表示に続いて「署名者」欄が表示され、

そこに「署名に問題があります」というメッセージと警告のアイコンが表示されます。

図 2-10 マイクロソフト Outlook 2007 でのデジタル署名の不正を検出した画面

Mozilla Thunderbird では、デジタル署名の不正を検出すると、図 2-11 のようなアイコ

52

ン（ペンにバツ印）が表示されます。

図 2-11 Mozilla Thunderbird でのデジタル署名の不正を検出した画面

不正なデジタル署名には、2 つのケースが考えられます。

デジタル署名自体が適切でない

メッセージが改ざんされていることになります。次の(1)が該当します。

デジタル署名に使われた公開鍵証明書が適切でない

無効な公開鍵証明書を使っているか、信頼できない公開鍵証明書を使っているケースで

す。次の(2)、(3)、(4)、(5)、(6) が該当します。

ここでは、Windows の電子メールソフト Outlook Express 6 と Outlook 2007 を使って、

不正なデジタル署名のパターンとその検出の様子をみてみましょう。

53

(1) メッセージが改ざんされていないか

メールの送信者がデジタル署名した後、第三者によって添付ファイルやメッセージの内容

に変更が加えられると、電子メールソフトは受信したメールの内容とデジタル署名の不整

合を検出し、メール改ざんの警告を表示します。

図 2-12 マイクロソフト Outlook Express でメッセージの改ざんを検出した場合

54

(2) 有効期限内にある証明書でデジタル署名されているか

受信したメールのデジタル署名を検証した時点で、証明書の有効期限の期間内（開始日時

と終了日時の間）でない場合、電子メールソフトはデジタル署名が有効期限内でないこと

を警告します。図 2-13 のように Outlook Express では「失効している」というメッセー

ジですが、証明書が失効しているのではなく、有効期間にないのです。

図 2-13 マイクロソフト Outlook Express で検証時に有効期間にない証明書でのデジタル署名を検証し

た結果

55

(3) 署名者の証明書を含む証明書チェーン上の証明書が全て確認できたか

送信者がデジタル署名に使った証明書が、証明書データベースに見つからない、あるいは

ルート証明書までの証明書チェーン上の証明書が見つからない場合、図 2-14 のように証

明書の確認ができない旨の警告が表示されます。

図 2-14 マイクロソフト Outlook Express で検証に必要な証明書が見つからないため、証明書チェーンを

確認できない場合の画面

56

(4) 送信者メールアドレスと証明書記載のメールアドレスが一致しているか

S/MIME の仕様では、送信者のメールアドレス（メッセージのヘッダーの From に記載さ

れているアドレス）と証明書中のメールアドレスが一致するかをチェックします。ふたつ

のメールアドレスが相違する場合、図 2-15 のようにアドレスの不一致を警告します。

この例では、デジタル署名に使った証明書のメールアドレスが”info@orangesoft.co.jp”で

あるにもかかわらず、メッセージのヘッダーの From に記載されたメールアドレス

が”sales@orangesoft.co.jp”となっていたことを通知しています。

図 2-15 マイクロソフト Outlook Express 送信者メールアドレスと証明書記載のメールアドレスの相違す

る場合の画面

57

(5) デジタル署名に使われた証明書が失効していないか

受信側アプリケーションでは、デジタル署名に使われた証明書が失効していないかを確認

します。これは、証明書のシリアル番号が、CRL（証明書失効リスト）に記載されていな

いかをチェックする処理です。

デジタル署名をした送信者の証明書が失効していた場合、証明書を確認すると図 2-16 の

ように失効が通知されています12。

図 2-16 失効している証明書の表示

12 Outlook Express では 4.4.1.（1）で示すように「デジタル ID が取り消されているかどうかを確認する」

で「オンラインのときのみ」が選択されている場合、署名社の証明書にしめされた CRL-DP（失効リスト

の配布場所）にしめされた URL から取得して失効のチェックがされます。

58

(6) X.509 鍵使用法に示された用途以外で使わないか

～鍵使用法に digitalSignature が含まれているか～

受信側アプリケーションでは、送信者がデジタル署名に使った証明書を使ってデジタル署

名の検証をします。しかし、証明書の鍵使用法にデジタル署名を許可していない場合、デ

ジタル署名自体が正しくとも、用途が不正なので、そのデジタル署名は不正なものと判断

されます。

注意：

しかし、Outlook Express 6 では、受信したデジタル署名したメッセージの送信者の証明

書の鍵使用法に digitalSignature が含まれていない場合でもそのことを通知しません。

ここでは、Outlook 2007 での 鍵使用法が不正な場合の警告の画面について図 2-14 に示

します。

59

図 2-17 マイクロソフト outlook 2007 でデジタル署名に使った証明書の鍵使用法の問題を警告している

画面

60

2.3. 暗号化の注意事項

暗号化された電子メールは、発信者が意図した受信者だけが復号して元のメールを読むこ

とがでます。デジタル署名は受信者がその正当性を確認しましたが、暗号化の場合には正

当な受信者は問題があるかどうかを調べる必要はありません。

暗号化では、デジタル署名とは逆に暗号化する側、つまり、送信者が正しく暗号化する必

要があります。この場合、正しくとは「2.1 公開鍵証明書の有効性」で説明したように、

有効な受信者の公開鍵証明書を選択して暗号化することです。また、宛先の電子メールア

ドレスと証明書中の電子メールアドレスが一致していることを確認します。

これらチェックの処理は、ほとんどの場合、電子メールソフトが自動的に行います。

61

3. セキュリティトークン

近年、IC チップの搭載された ID カードが、社員証や入館証などに使われるようになって

きました。また、IC チップの搭載された USB トークンを PC のアクセス制御の認証に利

用する場合もあります。これらの IC カードや USB トークンのようなセキュリティトーク

ンの中には、PKI に対応した製品13があります。本章では、これらセキュリティトークン

を PKI のデバイスとして、電子メールソフトで利用するための手順を紹介します。取り扱

う内容は以下のとおりです。

IC カード、USB トークンなどのセキュリティトークンの標準仕様について

PC/SC と Microsoft Cryptographic Service Provider

PKCS#11

セキュリティトークンのセットアップと証明書の取得方法

セキュリティトークンを利用するためには、まずセキュリティトークンでプライべート鍵と

公開鍵のペアを作成します。作成した鍵ペアで証明書を取得するには Web ブラウザを使い

ます。それぞれの仕様に対応した Web ブラウザを使って証明書を取得した後、電子メール

ソフトでセキュリティトークンを利用することが可能になります。

Internet Explorer：PC/SC に対応した Web ブラウザ

Windows メール、Outlook Express、Outlook などを使う場合

Mozilla Firefox：PKCS#11 に対応した Web ブラウザ

Mozilla Thunderbird を使う場合

3.1. セキュリティトークンの標準仕様

ここでは、セキュリティトークンとアプリケーションとのインターフェース標準の仕様に

ついて、2 つ紹介します。

3.1.1. PC/SC14と Windows の Cryptographic Service Provider

どちらもマイクロソフトが提唱し Windows で標準的に採用されている方式です。PC/SC

はインターフェース部分の仕様にとどまらず、セキュリティトークンを含む利用環境全体

を規定しています。Windows では。アプリケーションンは CryptoAPI と呼ばれる OS の

13 PKI 対応のセキュリティトークンとは、PKI で使われる、公開鍵暗号、共通鍵暗号、メッセージダイジ

ェスト関数などのアルゴリズムが実装されており、公開鍵やプライベート鍵、秘密鍵の生成や保存、加え

て公開鍵証明書の管理が出来るものをいいます。 14 PC/SC の標準化団体の URL は http://www.pcscworkgroup.com/

62

基本機能をとおしてセキュリティトークンを扱います。セキュリティトークンのベンダー

は、セキュリティトークンへのインターフェースモジュールを CSP（Cryptographic

Service Provider）と呼ばれる標準仕様にそって実装します。CSP によって個々のハード

ウェアの特性は吸収され、アプリケーションは CryptoAPI の一連の関数群を使って

Windows 証明書ストアをアクセスすることによって自動的にセキュリティトークン内の

証明書を使った処理が行われます。（図 3-1）

したがって、Windows 証明書ストアを使っている Internet Explorer15 や、Outlook をは

じめとする電子メールソフトは CSP を提供しているセキュリティトークンを使って暗号

化やデジタル署名の処理が可能です。

図 3-1 アプリケーション、CryptoAPI、CSP、セキュリティトークンの関係

セキュリティトークンのセットアッププログラムを事項した後に、レジストリを確認する

と、CSP が登録されていることが確認できます。（図 3-2）キーは

HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Cryptography¥Defaults¥Provid

er です。Image Path キーで示されているファイルが、選択されているセキュリティトー

クンの CSP です。

15 Internet Explorer では、証明書ストア経由の処理以外にも鍵生成など CSP を使って特殊な操作を行っ

ています。

63

図 3-2 Windows のレジストリの CSP の情報

Windows XP では、いくつかの IC カード用の CSP が標準で登録されています。また、ソ

フトウェアとして暗号アルゴリズムを実装したモジュールも CSP として提供されていま

す。図 3-2 の中で“Microsoft”で始まるキーが該当モジュールです。

3.1.2. PKCS#1116

米国 RSA セキュリティ社が策定した仕様です。Windows 以外の OS でもサポートされて

います。Netscape 社の Web ブラウザや電子メールソフトがサポートしていました。現在

も Mozilla Firefox や Mozilla Thunderbird がサポートしています。Java のアプリケーシ

ョンからセキュリティトークンを利用するために、JNI17を使って PKCS#11 モジュールを

扱うライブラリも用意されています。ベンダーは、DLL ファイルなど OS に沿った実行形

式で PKCS#11 仕様を実装したドライバを提供します。OS が標準でサポートしているも

のではないため、個々のアプリケーションごとに PKCS#11 ドライバを登録する必要があ

ります。アプリケーションでは、登録された PKCS#11 ドライバのパスを元に実行時にド

ライバをロードし、C_Initialize、C_Digest などといった PKCS#11 仕様の既定の関数を

呼び出して利用します。PKCS#11 を扱うアプリケーションは CryptoAPI のような抽象化

16 https://www.rsa.com/rsalabs/node.asp?id=2124 17 Java Native Interface Java のプログラムから OS の基本機能や、他の言語（C や C++など）

で開発されたプログラムを呼び出すための手法

64

したレイヤを経由せず、PKCS#11 の仕様をベンダーが実装したドライバを直接呼び出す

ため、仕様への準拠の度合い、仕様の網羅度を吸収した実装とする必要があります。

3.2. セットアップと証明書の取得方法

3.2.1. セキュリティトークンのセットアップ

セキュリティトークンをクライアントで利用するためには、IC カードリーダや USB トー

クンに付属するセットアッププログラムを実行し、セキュリティトークンのセットアップ

を行う必要があります。

Windows の場合、CSP や PKCS#11 のドライバがセットアッププログラムによって、

Windows のシステムディレクトリ（システムフォルダ）にインストールされます。ユー

ザーは次に、セキュリティトークンのパスワードを扱うためのユーティリティプログム

（ツール）をインストールします。セキュリティトークンのパスワード（PIN）は出荷時

に初期値がセットされてくるので、このユーティリティプログムによって変更します。図

は米国 Athena 社の ASECard のユーティリティプログムです。「Change PIN」ボタンを

クリックすると PIN の変更画面が表示されます。

セットアッププログラムを完了し、PIN の変更が済んだら、各アプリケーションから利用

可能になります。

図 3-3 セクリティトークンのユーティリティプログム

65

3.2.2. Internet Explorer：PC/SC に対応

(1) 公開鍵証明書の取得

Internet Explorer を使って公開鍵証明書を取得しようとすると、「図 3-4 Internet

Explorer で鍵生成のデバイスを選択するところ」のように、鍵生成を行うデバイスの選択

肢にセットアップした CSP が追加されます。

公開鍵証明書の取得手順は 4.1.1 を参照してください。

図 3-4 Internet Explorer で鍵生成のデバイスを選択するところ

(2) 既存の証明書を Windows 証明書ストアへ登録

Windows 証明書ストアを使ったアプリケーションでは、セキュリティトークンの識別が

不要ですが、逆に、別の PC で証明書を取得した場合など既にセキュリティトークンに証

明書がある場合は、あらかじめ Windows 証明書ストアへ登録しておく必要があります。

登録しておくことにより、処理に使う証明書の保管先を OS が自動で判断します。

ほとんどの場合、セットアップしてセキュリティトークンのユーティリティプログムは、

セキュリティトークンに保存されている証明書を Windows 証明書ストアへ登録する機能

が搭載されています。

3.2.3. Mozilla Firefox：PKCS#11 に対応

(1) PKCS#11 モジュールファイルの追加

Netscape で PKCS#11 を利用する場合、製品によってはインストーラが PKCS#11 モジュ

ールの設定を済ませているものもあります。しかし、Firefox で利用するには、ほとんど

の場合、利用者が「PKCS#11 デバイスの読み込み」をあらかじめ実施しておく必要があ

66

ります。Firefox の「ツール」メニューから「オプション」画面を開き、カテゴリ「詳細」

の「暗号化」タブのページで「セキュリティデバイス」18をクリックして「デバイスマネ

ージャ」画面を開きます。「追加」ボタンをクリックして、「PKCS#11 デバイスの追加」

（図 3-5）でセキュリティデバイスの PKCS#11 モジュールの DLL ファイルを指定しま

す。ファイル名はマニュアルなどで確認しましょう。ほとんどの場合、Windows のシス

テムディレクトリ（システムフォルダ） C:¥Windows¥system32 にインストールされて

います。

図 3-5 Firefox PKCS#11 デバイスの追加画面

追加が完了してログインすると、「デバイスマネージャ」画面は図 3-6 のようになります。

図 3-6 Firefox PKCS#11 デバイスマネージャ画面

Firefox では起動後、初めてセキュリティトークンへのアクセスが必要になったときに図

3-7 のように PIN を入力する画面が表示されます。

18 Mozilla の電子メールソフト Thunderbird ではツール」メニューから「オプション」画面を開き、カテ

ゴリ「プライバシー」の「セキュリティ」タブのページで「セキュリティデバイス」をクリックします。

67

図 3-7 Firefox セキュリティトークンへ PIN 入力画面

(2) セキュリティデバイスの選択

公開鍵証明書データの形式のひとつ、PKCS#12 ファイルをインポートするときなどは、

図 3-8 のようにどこに保存するか確認する画面が表示されます。

図 3-8 Firefox セキュリティデバイスの選択画面

(3) 公開鍵証明書の取得

Firefox では、「4.1.1 公開鍵証明書の取得手順」に示す操作の情報登録画面で、CSP を選

択する代わりに「Encryption Strength」欄で公開鍵の長さを「2048(高強度の暗号化)」か

「1024(中強度の暗号化」から選択します。セキュリティトークンによってサポートして

いる鍵の長さには違いがあるので、マニュアルなどで確認しておきましょう。サポートし

68

ていない鍵長を選択するとエラーになります。

69

4. 電子メールソフトの設定

公開鍵証明書の入手と電子メールソフトでの利用

ここでは、公開鍵証明書の入手方法と、その管理方法について取り上げます。次に、S/MIME

に対応した電子メールソフトでの設定と S/MIME の利用方法について説明します。取り上

げる電子メールソフトは以下のとおりです。

Windows メール (Windows Vista）、Microsoft Outlook Express (Windows XP）

Microsoft Outlook 2007(Windows）

Mozilla Thunderbird (Windows、Mac 、Linux）

RimArts Inc. “Becky! Internet Mail” (Windows）

オレンジソフト “Winbiff +S/Goma ”(Windows）

Mac メール

4.1. 公開鍵証明書の入手方法

デジタル署名や暗号を利用するためには、公開鍵証明書が必要になります。ここでは、認

証機関から公開鍵証明書を取得する手順について説明します。

公開鍵証明書はデジタル ID などともよばれ、認証サービスを行っている会社などから取

得することが可能です。

日本でも日本ベリサイン株式会社 (http://www.verisign.co.jp)などが、S/MIME で利用可

能な公開鍵証明書を発行するサービスを行っています。

4.1.1. 公開鍵証明書の取得手順

ここではオンラインで公開鍵証明書の取得できる米国ベリサインの Web サイトを使った

例を示します。

米国ベリサインの Web サイトにある公開鍵証明書の購入ページ

http://www.verisign.com/products-services/security-services/pki/pki-application/email-

digital-id/index.html

にアクセスします。19

（ベリサインサイトのトップページからは、

i. ”Product & Services”をクリックします。

19米国ベリサインの Web サイトはマイクロソフト Internet Explorer と、Netscape 系の Mozilla Firefox

もサポートされています。Firefox を使えば、Linux や Mac OS X でも証明書の取得が可能です。

70

ii. ”Product & Services”のページで、“Security Services”の一覧から“Managed PKI Services

をクリックします。

iii. ” Managed PKI Services“のページで”PKI Applications”をクリックします。

iv. “PKI Applications ”のページで” Digital IDs for Secure Email”をクリックしま

す。” Digital IDs for Secure Email”のページにある"Buy Now"アイコンをクリックする

と “Digital ID Enrollment” ページが表示されます。再度、”Buy Now”アイコンをクリッ

クします。

71

(1) 申請者の情報の入力

ブラウザ選択ページが表示されるので、利用するブラウザの種類を選択すると、情報入力

ページが表示されます。

入力は、すべて半角英数字で行います。

Contents of Your Digital ID

の入力

First Name: 「名」を入力します。

Last Name: 「姓」を入力します。

Your E-mail Address: 「電子メールア

ドレス」を入力します。

Challenge Phrase の入力

ここで指定した、Challenge Phrase は

証明書を無効にしたいときなどに、確

認されることになります。

Choose a Full-service Class1 Digital ID, or a 60-day Trial Class 1 Digital ID の選択

I'd like a one-year, full-service Digital ID for only US$19.95 per year.

一年間有効のフルサービスになります。

US$19.95 のクレジットカード決済となります。

「Billing Information の入力」に進みます。

図 4-1 Web サイトでの証明書の申請

72

I'd like to test drive a 60-day trial Digital ID for free.:

60 日間無料のお試し版になります。

破棄、再取得、更新など諸々のサービスがありません。

「Option の選択」に進みます。

Billing Information の入力（フルサービスを選択した場合）

クレジットカードの情報を入力します。

Card Type: 「カードの種類」を選択します。

Card Number: 「カード番号」を入力します。

Expiration Date: 「カードの有効期限」を選択します。

Name on Card: 「カードに登録の名前」を入力します。

- 〒154-0004 東京都世田谷区太子堂 1-4-14 萩籐ビル３階 の場合 -

Street Address: 1-4-24 Taishido

Apartment/Unit Number: Hagitou Bldg 3F

City: Setagaya-Ku Tokyo

State/Province: JP

ZIP/Postal Code: 154-0004

Country: Japan

Optional の選択

Internet Explorer の場合

「Microsoft Base Cryptographic Provide v1.0」を選択します。

Mozilla Firefox の場合

「1024」または「2048」を選択します。

Additional Security for Your Private Key の選択（Internet Explorer の場合のみ）

Check this Box to Protect Your Private Key:

チェックボックスをチェックすることにより、プライベート鍵にパスワードを設定することがで

きます。

Digital ID Subscriber Agreement の確認

読んで、同意できたら、「Accept」を押します。 「Accept」をしなければ、先に進みません。

(2) 電子メールアドレスの確認

電子メールアドレスを確認し、「OK」を押します。

73

セキュリティモジュールへのパスワード設定（Mozilla Firefox の場合のみ）

Communicator Certificate DB にパスワードを設定します。

(3) 申請の終了

図 4-2 のようなページが表示されれば、公開鍵証明書の申請は完了です。

図 4-2 Web サイトで証明書の申請の完了

74

(4) 電子メールを確認します

一時間以内には電子メールが届きます。

図 4-3 Web サイトでの証明書の申請が完了し、その後の手順について、電子メールでの確認などを促し

ている画面

図 4-4 証明書の発行が完了した旨を告げる電子メール

電子メールの、以下の２点の記載を確認します。

「https://･････」と記述された URL

「Your Digital ID PIN IS: ･･･」と記述された PIN 番号

75

(5) 再度、ブラウザを使い Web サイトにアクセスし、デジタル ID をインストールします

電子メールで確認した URL にアクセスします。PIN 番号を入力し、「Submit」ボタンを

押します。

図 4-5 Web サイトから証明書のインストール

「INSTALL」ボタンを押すと、あなたのパソコンにデジタル ID が取り込まれます。

(6) その他の S/MIME 用公開鍵証明書発行サービス

日本ベリサイン

ここでは、米国ベリサインの認証局が発行するデジタル ID を取得する手順を説明しましたが、

日本ベリサイン発行のデジタル ID は、日本ベリサインの販売代理店から購入することができま

す。日本ベリサインの Web サイト

http://www.verisign.co.jp/personal/partner.html#class1

に販売代理店の一覧があり、各販売代理店へリンクしています。

76

米国コモド

米国コモドの Web サイトでは、フリーの公開鍵証明書発行サービスがあります。米国ベリサイ

ンのサービスと同様の手順で証明書が発行されます。

http://www.comodogroup.com/products/certificate_services/email_certificate.html

ここで発行される公開鍵証明書はルート認証局「AddTrust External CA Root」のものです。ル

ート認証局「AddTrust External CA Root」の公開鍵証明書は、Windows の証明書ストアや

Mozilla Firefox、Thunderbird であらかじめバンドルされています。20

図 4-6 米国コモドの証明書発行サービスの Web サイト

20 コモドのサイトで証明書取得をサポートしているのは Internet Explorer だけです。

77

4.1.2. 他人の公開鍵証明書を入手するには

電子メールの暗号化には、他人（送信先）の公開鍵証明書が必要です。デジタル署名を行

う場合には、自分の公開鍵証明書があればよいのですが、暗号化は他人の公開鍵を利用す

るため、通信の相手の公開鍵証明書を入手する必要があるのです。他人の公開鍵証明書を

入手するには、いくつかの方法があります。

a. デジタル署名のデータから取り出す

暗号化通信に先立ち、デジタル署名をしたメッセージを相互に送ります。

デジタル署名した場合、署名した人の公開鍵証明書がデジタル署名データに添付されて

います。S/MIME に対応した電子メールソフトでは、自動（あるいは手動）でデジタル

署名データから公開鍵証明書を抜きだし、オペレーティングシステムの証明書データベ

ースにインポートできます。証明書データベースに公開鍵証明書が組み込まれたあとは、

通信相手のメールアドレスに対応する公開鍵証明書を使って送信する電子メールを暗

号化できます。事前に当事者同士の通信が可能であれば、この方法が最も簡単でしょう。

b. 証明書のファイルをメールに添付して送ってもらう。

証明書管理ツールを使ってエクスポートした自分の証明書データを、電子メールに添付

して送信します。受信者は、受信したファイルを、証明書管理ツールを使ってインポー

トします。この方法は、管理者などがまとめていくつかの証明書を配布するような場合

に用いられます。

c. ディレクトリサーバーを利用する。

ディレクトリサービスで、公開鍵証明書を属性の 1 つとして格納しておきます。利用者

は、ディレクトリサービスの検索結果から目的とする人の公開鍵証明書をえることがで

きます。アドレス帳などで LDAP21をサポートしている場合、ディレクトリサービスを

使って組織内のアドレス情報の一元管理に公開鍵証明書も加えることができます。

d. Web サーバーで検索する

認証局によっては、この Web サーバー上で証明書の検索を可能にしている場合があり

ます。

例えば、米国ベリサインの場合、

https://onsite.verisign.com/services/VeriSignJapanKKVeriSignClass1CAIndividualS

ubscriber/client/search.htm

21 ディレクトリサービスにアクセスするためのインターネットの標準の手順です。公開鍵証明書の属性名

も標準として定義されています。

78

にアクセスし、電子メールアドレスか名前で検索すれば、目的とする人の公開鍵証明書

を見つけられます。検索結果からアプリケーションに応じたフォーマットの公開鍵証明

書をダウンロードできます。

79

4.2. 証明書ファイル

作成した公開鍵証明書は、ファイルに保存（エクスポート）して他の環境で利用可能にす

ること（インポート）ができます。このときに使われるファイルの形式について説明しま

す。

表 4-1 公開鍵証明書やプライベート鍵などのデータを扱うファイルの形式

データの種類 ファイルの拡張子 説明

X.509 証明書 cer X.509 証明書が 1 つだけ入ったファイルです。

PKCS#7 証明書 p7b または p7c デジタル署名のフォーマットでは、証明書を添付す

ることが可能ですが、そのフォーンマットでデジタ

ル署名データがなく、証明書のみが格納されたファ

イルです。

この場合、複数の証明書を格納することができま

す。

PKCS#12 p12 または pfx PKCS#12 はプライベート鍵と公開鍵証明書をペア

で格納するフォーマットです。このフォーマットで

はパスワードを鍵とした暗号化を行います。

PEM 形式22 pem データ自体は、その内容に応じたフォーマットで作

成され、作成したバイナリデータを BASE64 エン

コードして、前後に所定のタグを付けたものです。

X.509 証明書を PRM 形式にした場合、拡張子を cer

とする場合もあります。

22 S/MIME の前身となった古い電子メールの暗号化プロトコル PEM（RFC 1421～1424）での

データの表現方法が元になっています。現在でも、オープンソースの SSL プロトコル実装であ

る OpenSSL で使われています。http://www.openssl.org/

80

-----BEGIN CERTIFICATE-----

MIICYDCCAcmgAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJKUDEY

MBYGA1UEChMPT3Jhbmdlc29mdCBJbmMuMRAwDgYDVQQLEwdUZXN0IENBMRkwFwYD

VQQLExBFLU1haWwgU2VjdXJyaXR5MB4XDTA3MDIwMzEyNDgwMFoXDTA4MDIwMzEy

jxdkFEGgG/LzpjhzRl+sHYEqQlX5FyqQcpmba76H1UMWPL9LwGMrZylTx10OsrXM

zZy2/ohZdLd7v+7HWMGwZeeftKOmQDMlF0Pja1FaXtsBzEyHBr5gq1D9yR4YW6er

sdtSGdNza3UCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC

AcYwHQYDVR0OBBYEFIGHK03263Bk75gNZbuwkeg+W5PeMA0GCSqGSIb3DQEBBQUA

A4GBACR9gmXphz615y4YHJpzjCgr2M+H9g5B0ieT7mtc3ESwdcrrowq5zCuRgUhL

/KBEOohzvLR4fsatNxfZ8+sUfA9uEpjD7lVhvdNx8hqzA6SqWzNL/ohHOm0bDHOv

KQ53zyqWioPhNitJrGVH1JeztP97BOHH4Fec8iVIkYb0PQ2Y

-----END CERTIFICATE-----

図 4-7 PEM 形式の証明書

81

4.3. 公開鍵証明書の管理

PKI は、Windows や Java などアプリケーションの稼働環境が、標準でサポートしている

技術です。これらの環境では、公開鍵証明書はシステムで実装されている証明書のデータ

ベースに保存されています。このデータベースを Windows では「証明書ストア」、Java

では「キーストア」と呼びます。

Windows にも Java にも、証明書データベースを通して証明書を管理するためのツールが

付属しています。それぞれの証明書管理のツールをみてみましょう。

4.3.1. Windows での証明書管理

(1) 証明書の一覧

Windows のコントロールパネルにあるインターネットオプションの「コンテンツ」タブ

にある証明書ボタンをクリックすると、証明書ダイアログボックスが表示され、インスト

ールされている証明書が一覧表示されます。証明書の種類によってタブごとに分類されて

一覧表示されます。23

「個人」には、公開鍵とプライベート鍵をペアでもっている自分の公開鍵証明書が表

示されます。

「ほかの人」には、認証局の公開鍵証明書ではない、通信相手となる利用者の公開鍵

証明書が表示されます。

「中間証明機関」には、ルート認証局から利用者（エンドエンティティ）の証明書ま

でをつなぐ、中間の認証局の証明書が表示されます。

「信頼されたルート証明機関」には、ルート認証局の証明書が表示されます。

23 Windows の MMC（Microsoft Management Console）を起動して、「証明書」スナップインを使うと、

より詳細に証明書ストアの管理ができます。

82

図 4-8 Windows の証明書管理

83

(2) 証明書の表示

一覧から証明書を選択して「表示」をクリックすると図 4-9 のような画面で証明書の内容

が確認できます。

図 4-9 Windows の証明書の詳細表示画面

84

(3) CRL（失効リスト）の表示

後述するような CRL ファイルを「開く」と、図 4-10 のように CRL の内容を確認できま

す。発行元の認証局の名前があります。「失効リスト」タブのページでは、失効した証明

書のシリアル番号と失効した日時が一覧表示されています。

図 4-10 Windows での CRL（失効リスト）の表示画面

85

4.4. 電子メールソフトの設定と送受信方法

4.4.1. Microsoft Windows メール (Windows Vista）、Microsoft Outlook Express (Windows

XP）

Windows Vistaに付属している電子メールソフト” Windowsメール” でのデジタル署名お

よび暗号化に関する設定について説明します。Windows メールは、Vista 以前の Windows

に付属していた”Outlook Express”の後継の製品です。したがって、Windows メールと

Outlook Express は、ほぼ同じ設定方法/操作方法です。

取り上げるバージョンは、Windows Vista（Microsoft Windows 6.0 ビルド 6000）に付属

しているバージョンのものです。24

(1) 設定

Windows メール、および Outlook Express では、複数のメールアカウントを利用できま

す。したがって、S/MIME に関する設定も全アカウントで共通の設定と、アカウントごと

の設定があります。

全アカウント共通の S/MIME の設定

Windows メールの「ツール」メニュー／「オプション」の「セキュリティ」タブのペー

ジで設定を行います。

24 ” Windows メール”自体にプログラム固有のバージョン情報はありません。

86

図 4-11 Windows メールのセキュリティ設定画面

「デジタル ID」ボタン

クリックすると証明書の一覧が表示され「個人」のページであなたの証明書が確認できま

す。

「デジタル ID の取得」ボタン

クリックすると、Web ブラウザが起動し”Digital ID – Office Marketplace” Web サイトに

アクセスします。このサイトでは、オンラインで証明書の入手可能な認証局サービスを行

87

っている会社が紹介されています。

「詳細設定」ボタン

クリックすると表示される図 4-12 のような画面で、S/MIME に関する詳細な指定ができ

ます。

図 4-12 Windows メールのセキュリティの詳細設定画面

e. 暗号化のオプション

「暗号化されたメッセージが以下の強度以下の場合に警告する」

相手によって、暗号化の際に利用する共通鍵暗号方式の鍵長が制限される場合がありま

す。鍵長がこのオプションで指定した長さ以下になってしまうとき、警告するよう設定

できます。受信した暗号メールに使われた鍵の長さについても、同様に設定できます。

「暗号化された送信メッセージを自分向けにも暗号化する」

このオプションをチェックすると、暗号化の際に送信先の証明書に加え、あらかじめ選

択されている自分の証明書も使って暗号化されます。

88

f. デジタル署名のオプション

「署名付きメッセ－ジにデジタル ID を追加する」

これをチェックすると、デジタル署名の際に署名に使った証明書を添付します。送り先

の方があなたの証明書を持っていない場合があるので、通常はチェックしておいたほう

が便利です。

「署名する前にメッセージをエンコードする」

このオプションをチェックすると、デジタル署名の際に平文を付けた multipart/signed

形式にせず、平文と署名データの両方を PKCS#7 のバイナリデータにして、添付ファイ

ルとして送信します。

「差出人の証明書を Windows アドレス帳に追加する」

このオプションをチェックすると、署名付きメッセ－ジに公開鍵証明書が付いていれば、

Windows 証明書ストアに自動的に証明書をインポートします。通信相手の証明書が自動

的に入手出来るので、暗号化する際に、新たに証明書を入手する手間がかからないので

便利です。

g. 公開鍵証明書の失効の検証のオプション

「デジタル ID が取り消されているかどうかを確認する」

最新の失効リストを取得して検証するかどうかどうかを選択するオプションです。「オ

ンラインのときのみ」をチェックしておくと証明書の CRL 配布点が参照され、ネット

ワークから最新の CRL を取得し、署名者の証明書が失効していないか確認されます。

アカウントごとの S/MIME の設定

「ツール」メニュー／「アカウント」の「プロパティ」ボタンをクリックすると、図 4-13

のような画面が表示されます。この「セキュリティ」タブのページでアカウントごとに

S/MIME の設定をします。

89

図 4-13 Windows メールのアカウントごとの設定

90

図 4-14 Windows メールの証明書の選択画面

「署名の証明書」

証明書

「選択」ボタンをクリックすると図 4-14 のような署名に利用可能な証明書が表示され

るので、選択します。

暗号化の設定

デジタル署名の際、ここで指定した内容が、暗号化する際に使ってほしいあなたの証明

書と、使ってほしい共通鍵暗号のアルゴリズムとして、デジタル署名のデータの中に挿

入されます。

証明書

「選択」ボタンをクリックすると図 4-14 のような暗号化に利用可能な証明書が表示さ

れるので、選択します。署名の証明書と暗号化の証明書は同じでもかまいません。

アルゴリズム

暗号化に使う共通鍵アルゴリズムを指定します。

(2) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手に、

デジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、

通常はデジタル署名には署名者（すなわち通信相手）の証明書が添付されています。

Windows メールでは証明書を自動的に保管するので、あなたが必要なときに使うことが

できます。

91

アドレス帳でインポートする

Windows アドレス帳で通信相手のプロパティを開き、「証明書」のページを表示します。

「インポート」ボタンをクリックし証明書ファイルを指定すれば、通信相手の証明書を

アドレス帳に取り込めます。

図 4-15 Windows アドレス帳の連絡先の人のプロパティの証明書のページ

92

ディレクトリサーバーから検索する

Windows メールには、高機能なアドレス帳が付属しています。このアドレス帳は、ディ

レクトリサーバーと呼ばれるインターネット上のアドレス帳ともいえるサービスにア

クセスして、個人の情報を取り出してくることができます。

認証局によっては、このディレクトリサーバーに証明書も一緒に保管している場合があ

ります。以下では、ディレクトリサーバーから証明書を取り出してくる操作について説

明します。

「メッセージの作成」画面で「宛先」をクリックすると「受信者の選択」画面が表示さ

れます。「検索」をクリックすると「人の検索」画面が表示されるので、「条件の定義」

に条件を指定して「追加」をクリックします。検索の条件は複数指定出来ます。必要な

条件がそろったら「検索開始」をクリックします。

図 4-16 Windows メールで、ディレクトリサーバーの検索条件を入力する画面

検索結果が一覧表示されます。リストの中から該当する人を選択し「プロパティ」をク

リックすると、「人のプロパティ」画面の「ID」ページで証明書が確認できます。一覧

画面で「アドレス帳に追加」や「宛先」をクリックして、証明書を収集します。

93

図 4-17 Windows メールでディレクトリの検索結果から証明書を確認します。

(3) メッセージの送信

デジタル署名を付けて電子メールを送る

「メッセージの作成」ウィンドウで「ツール」メニュー／「デジタル署名」を選択しま

94

す。デジタル署名を表すリボンのアイコンが表示されます。

デジタル署名を選択した場合、あわせて「セキュリティで保護された確認メッセージの

要求」を選択することができます。これは、受信側にデジタル署名された受信確認のメ

ールの送信を要求するもので、S/MIME バージョン 3 の拡張機能です。サポートして

いる電子メールソフトは尐ないのですが、Windows メール、Outlook Express、Outlook

などではサポートされています。

図 4-18 Windows メールでメッセージの作成でデジタル署名を指定します。

暗号化して電子メールを送る

「メッセージの作成」ウィンドウで「ツール」メニュー／「暗号化」を選択します。暗

号化を示す鍵のアイコンが表示されます。

図 4-19 Windows メールでメッセージの作成で暗号化を指定します。

デジタル署名と暗号化を組み合わせて使う

前項の２つをともに選択しておくと、デジタル署名と暗号化を組み合わせて行えます。

95

図 4-20 Windows メールでメッセージの作成でデジタル署名と暗号化を指定します。

(4) メッセージの受信

デジタル署名付きメッセージを受ける

デジタル署名付きメッセージを受けると、メッセージの本文表示前に本文が表示される

領域に図 4-21 のような警告が表示され、デジタル署名が付いていることがわかります。

「続行」をクリックすると、デジタル署名の検証が行われた後メッセージが表示されま

す。

図 4-21 Windows メールでデジタル署名付きメールを受信したときの画面

暗号化されたメッセージを受ける

暗号化されたメッセージを受け取ると、メッセージの本文表示前に本文が表示される領

域に図 4-22 のような警告が表示され、暗号化されていることがわかります。「続行」

をクリックすると、復号されてメッセージが表示されます。

96

図 4-22 Windows メールで暗号化されたメッセージを受信したときの画面

デジタル署名と暗号化されたメッセージを受ける

デジタル署名と暗号化されたメッセージを受け取ると、メッセージの本文表示前に本文

表示領域に図 4-23 のような警告が表示され、デジタル署名と暗号化がなされているこ

とがわかります。「続行」をクリックすると、復号とデジタル署名の検証が行われ、メ

ッセージが表示されます。

図 4-23 Windows メールでデジタル署名と暗号化されたメッセージを受信したときの画面

97

デジタル署名と暗号化の情報の確認

デジタル署名または暗号化のアイコンをクリックすると、メッセージのプロパティ画面

の「セキュリティ」ページが開き、デジタル署名と暗号化に関する情報が確認できます。

図 4-24 Windows メールでデジタル署名と暗号化されたメッセージの内容画面

「セキュリティ」ページでは、以下が確認できます。

デジタル署名の署名者

デジタル署名の検証の結果（改ざんされていないこと）

証明書の検証の結果

セキュリティで保護された配信メッセージの要求：S/MIME V3 ESS 拡張の「デジタル

署名付き受信確認メッセージ」の要求の有無を表示します。

デジタル署名の失効確認の実施の有無とその結果

セキュリティラベル：S/MIME V3 ESS 拡張の「セキュリティラベル」があった場合に

表示されます。

暗号化の有無

暗号化のアルゴリズム：暗号に使った共通鍵のアルゴリズムが表示されるところです。

現在、いずれの場合も n/a と表示されるようです。

98

「セキュリティ」ページで「証明書の表示」をクリックすると、図 4-25 の画面が表示

され証明書に関する情報を確認できます。

99

図 4-25 Windows メールの証明書の確認画面

署名の証明書

メッセージの送信者がデジタル署名に使った送信者の証明書が確認できます。

暗号の証明書

メッセージの送信者が暗号に使ったあなたの証明書が確認できます。

推奨する暗号化のアルゴリズム

メッセージの送信者が要求している暗号化のアルゴリズムが確認できます。

差出人の証明書

メッセージの送信者が要求している暗号化用の証明書が確認できます。

アドレス帳に追加

メッセージの送信者が要求している設定や証明書をアドレス帳に保存します。

100

不正なメッセージを受信すると

不正なメッセージを受けた場合、「続行」ボタンを押した後などに、図 4-26 のような

画面になります。この例では、メッセ－ジに改ざんがあったことがわかります。

図 4-26 Windows メールで不正なメッセージを受信したときの画面

101

4.4.2. Microsoft Outlook 2007(Windows XP）

マイクロソフト Office に含まれる電子メールソフト” Outlook” について説明します。

取り上げるバージョンは Outlook 2007 です。25

(1) 設定

Outlook 2007 では、複数のメールアカウントを利用できますが、S/MIME に関する設定

は全アカウントで共通です。

図 4-27 のような「ツール」メニュー／「セキュリティセンター」の「電子メールのセキ

ュリティ」のページで設定を行います。

図 4-27 Outlook 2007 のセキュリティ設定画面

a. 電子メールの暗号化

「送信メッセージの内容と添付ファイルを暗号化する」

作成するメッセージは初期状態で「暗号化」を選択します。

「送信メッセージにデジタル署名を追加する」

作成するメッセージは初期状態で「デジタル署名」を選択します。

「署名されたメッセージを送信する際は、クリアテキストで送信する」

デジタル署名の際に平文を付けた multipart/signed 形式にします。チェックをはずと平

文と署名データの両方を PKCS#7 のバイナリデータにして、添付ファイルとして送信し

25 ” Outlook 2007”自体にプログラム固有のバージョン情報はありません。

102

ます。

「すべての S/MIME 署名されたメッセージの確認メッセージを要求する」

デジタル署名して送信した場合に、受信者にデジタル署名付きの受信確認メッセージを

要求します。

「規定の設定」

「設定」ボタンをクリックすると、図 4-28 のような画面が表示するので、署名に使う

証明書などを選択して設定に名前をつけて保存します。「規定の設定」のコンボボック

スに設定の一覧が表示されるので選択します。

図 4-28 Outlook 2007 のセキュリティの詳細設定画面

「セキュリティ設定名」

この画面で設定した内容に任意の名称を付けます。

暗号化の形式

S/MIME と Exchange Server Security が選択可能です。S/MIME を選択します。

この暗号化メッセージ形式の規定のセキュリティ設定として使用する

103

すべての暗号化メッセージの規定のセキュリティ設定として使用する

セキュリティラベル

S/MIME V3 ESS 拡張の「セキュリティラベル」の設定をします。クリックすると図 4-29

のような画面が表示されてセキュリティラベルを付与するための「ポリシーモジュー

ル」が表示されます。標準では「ポリシーモジュール」はインストールされていません

26。

図 4-29 Outlook 2007 のセキュリティラベルを付けるためのポリシーモジュール選択画面

「新規作成」

クリックすると設定を新規に作成します。

「削除」

クリックすると設定を削除します。

署名証明書

「選択」をクリックすると、利用可能な証明書が表示されるので、デジタル署名に使う

証明書を選択します。

署名アルゴリズム

デジタル署名に使うメッセージダイジェスト関数を選択します。

暗号証明書

「選択」をクリックすると、利用可能な証明書が表示されるので、暗号化に使う証明書

を選択します。

暗号アルゴリズム

暗号化の際に使う共通鍵暗号のアルゴリズムを選択します。

署名済みメッセージで証明書を送信する。

26 「Outlook におけるセキュリティ ラベルおよび署名付き確認メッセージのサポート」

http://www.microsoft.com/japan/office/ork/2003/three/ch11/OutF01.htm を参照のこと

セキュリティモジュールの開発手順は

http://msdn2.microsoft.com/en-us/library/aa140148(office.10).aspx を参照のこと

104

チェックをすると、デジタル署名の際に自分の証明書を添付します。

105

(2) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手にデ

ジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、通

常はデジタル署名には署名者（すなわち通信相手）の証明書が添付されています。

Outlook では証明書を自動的に保管するので、あなたが必要なときに使うことができま

す。

アドレス帳でインポートする

アドレス帳：連絡先で通信相手のプロパティを開き「証明書」のページを開いて、「イ

ンポート」ボタンをクリックします。証明書ファイルを指定して、通信相手の証明書を

アドレス帳に取り込みます。

図 4-30 Outlook 2007 アドレス帳の証明書のページでは証明書のインポートが可能です。

106

(3) メッセージの送信

メッセージ作成画面には、デジタル署名のアイコンと暗号化のアイコンがあるので、必要

に応じてクリックして選択してから送信します。

図 4-31 Outlook 2007 のメッセージ作成画面でのデジタル署名と暗号化の指定

107

メッセージオプション画面で「セキュリティ設定」ボタンをクリックすると、「セキュ

リティプロパティ」画面が表示されます。ここでは、予め設定したセキュリティの設定

内容を変更することができます。

図 4-32 Outlook 2007 のメッセージ作成画面でのメッセージオプションのセキュリティ設定

108

(4) メッセージの受信

デジタル署名付きメッセージを受ける

Outlook では、閲覧ウィンドウに電子メールのメッセージ本文が表示されますが、デジ

タル署名付きメッセージを受けると図 4-33 のようにタイトル欄にリボンのアイコンが

表示されデジタル署名が付いていることがわかります。

図 4-33 Outlook 2007 でデジタル署名付きメッセージを表示しています。

109

暗号化されたメールを受ける

暗号化されたメッセージは、閲覧ウィンドウでは表示されません。図 4-34 のようなメ

ッセージウィンドウで表示します。図 4-34 のようにタイトル欄に鍵のアイコンが表示

され、暗号化されていたことがわかります。

図 4-34 Outlook 2007 で暗号化されたメッセージを復号して表示しています。

110

デジタル署名と暗号化されたメッセージを受ける

デジタル署名と暗号化されたメッセージも、メッセージウィンドウで表示します。図

4-35 のようにタイトル欄に鍵のアイコンとリボンのアイコンが表示されており、暗号化

とデジタル署名がなされていたことがわかります。

図 4-35 Outlook 2007 でデジタル署名と暗号化されたメッセージを復号して表示しています。

111

鍵かリボンのアイコンをクリックすると、図 4-36 のようなメッセージのセキュリティ

のプロパティ画面が表示されます。

図 4-36 Outlook 2007 の メッセージのセキュリティのプロパティ画面

112

「暗号化層」を選択して「詳細の表示」をクリックすると、図 4-37 のような画面で暗

号化の詳細情報が確認できます。

図 4-37 Outlook 2007 で表示される受信したメッセージの暗号化の情報

113

「暗号化層」を選択して「詳細の表示」をクリックすると、図 4-38 のような画面でデ

ジタル署名の詳細情報が確認できます。

図 4-38 Outlook 2007 で表示される受信したメッセージのデジタル署名の情報

114

4.4.3. Mozilla Thunderbird

電子メールソフトの” Mozilla Thunderbird” について説明します。

取り上げるバージョンは 1.5.09 です。

現在(2007 年 3 月)、Thunderbird が稼働する OS は以下のとおりです。

Window： 98 、98SE 、ME 、NT 4.0、2000、XP (推奨) 、2003 Server

Linux ：Linux カーネル 2.2.14 以降

Mac OS X：Mac OS X v10.2.x 以降

ここでは Windows XP での動作を取り上げています。

(1) 公開鍵証明書の管理

米国 Mozilla CorporationからWebブラウザ”Firefox”と電子メールソフト”Thunderbird”

が提供されています。2 つのソフトウェアの日本語版は Mozilla Japan より提供されてい

ます。”Firefox”と”Thunderbird”は共有する公開鍵証明書の管理機能をも持ちますが、こ

こでは、”Thunderbird”を使った公開鍵証明書の管理機能について説明します。

図は、「ツール」メニュー／「オプション」で「プライバシー」の「セキュリティ」のペ

ージです。

図 4-39 Thunderbird の証明書管理

115

b. 証明書を表示

Thunderbird の証明書データベースの内容を表示します。それぞれのタブでは以下のよう

に証明書を分類して表示します。

図 4-40 Thunderbird の証明書マネージャ

「あなたの証明書」

プライベート鍵とペアで持っている証明書が表示されます。ここで「インポート」をク

リックすると PKCS#12 形式のファイルからプライベート鍵と証明書をインポートでき

ます。「バックアップ」では、選択した証明書とペアのプライベート鍵を PKCS#12 形

式のファイルに保存します。

「他の人の証明書」

通信相手の証明書です。

「インポート」をクリックすると X.509 証明書形式のファイル（拡張子 CER のファイ

ル）から証明書をインポート可能です。

「設定」をクリックすると図 4-41 のような画面が表示されます。Thunderbird では、

図 4-41 のように証明書の信頼性を証明書チェーンにかかわらず設定することが可能で

す。

116

図 4-41 Mozilla Thunderbird の証明書の信頼性の設定

「サイト証明書」

SSL サーバー証明書です。「インポート」「設定」では、「他人の証明書」ページと同

様の操作が可能です。

「認証局証明書」

認証局の証明書です。ルート認証局と中間認証局の証明書がともにここで表示されます。

「インポート」では、「他人の証明書」ページと同様に X.509 証明書ファイルから証明

書を取り込むことが可能です。

「設定」をクリックすると図 4-42 のような画面が表示されます。Thunderbird では、

図 4-42 のように認証局の証明書の信頼性の用途を明示的に指定することが可能です。

この証明書を Web サイトの同定に使用する

SSL サーバー証明書の発行元として信頼します。

この証明書をメールユーザーの同定に使用する

電子メール用に証明書の発行元として信頼します。

この証明書をソフトウェア製作者の同定に使用する

ソフトウェアの発行者の公開鍵証明書（コードサイニング証明書）の発行元として信頼しま

す。

117

図 4-42 Thunderbird での認証局証明書の信頼性の設定

c. 失効リスト

図 4-43 のような CRL マネージャが表示されます。

図 4-43 Thunderbird の失効リストマネージャ

「インポート」をクリックすると CRL の取得先を追加します。

118

図 4-44 Thunderbird の CRL の取得先 URI の指定画面

取得先からインポートが完了すると、自動更新を実施するか確認されます。CRL マネージ

ャでリストから CRL を選択して「設定」をクリックした場合も同様に自動更新の設定が

可能です。

図 4-45 Thunderbird の CCRL 自動更新の設定画面

d. 検証

図 4-46 のような画面でオンラインの失効検証プロトコルである OCSP の利用に関して設

定します。

証明書の検証に OCSP を利用しない

OCSP プロトコルによる失効の確認は行いません。

証明書に OCSP27レスポンダの URL が記載されている場合にのみ利用する

証明書の X.509V3 拡張属性には認証機関アクセス情報 (AIA: Authority Information

Access) というものがあります。OCSP サーバーが用意されている認証局ではこの属性

27 Online Certificate Status Protocol：オンラインでクライアントが証明書の失効の確認を要求して、サ

ーバーが回答するプロトコルです。クライアントが CRL を直接確認すのではなく、サーバーが確認した結

果を受信して判断します。

119

に OCSP サーバーの URI を記載して証明書を発行します。この設定では AIA を参照し

てアクセスする OCSP サーバーを決めます。

次の OCSP レスポンダを利用してすべての証明書を検証する。

証明書の AIA の有無にかかわらず、固有の OCSP サーバーを利用します。

図 4-46 Thunderbird の OCSP の利用に関する設定

120

e. セキュリティデバイス

Thunderbird では、プライベート鍵や証明書にはセキュリティデバイスと呼ばれる機構を

通してアクセスします。デバイスマネージャでは、登録されているセキュリティデバイス

が表示されます。

セキュリティデバイスとしては、IC カードなどのハードウェアもありますが、標準ではソ

フトウェアとして実装されたセキュリティデバイス（Software Security Device）があり

ます。ユーザーは、利用に先立ってこのセキュリティデバイスの初期設定としてパスワー

ドを設定します。以降、プライベート鍵へのアクセスの際などは、図 4-47 のようにパス

ワードの入力が要求されます。

図 4-47 Thunderbird のセキュリティデバイスの設定

121

(2) 設定

Thunderbird では、複数のメールアカウントを利用できますが、S/MIME に関する設定は

アカウントごとに行います。

図 4-48 のような「ツール」メニュー／「アカウント設定」で「セキュリティ」のページ

で設定を行います。

図 4-48 Thunderbird のアカウント設定のセキュリティ設定

電子署名

「選択」をクリックすると「証明書の選択」画面が表示され、証明書マネージャの「あ

なたの証明書」に表示される証明書がコンボボックスから選択可能です。このアカウン

トでデジタル署名に使う証明書を選択します。メッセージ作成画面の初期値としてデジ

タル署名をする場合は「メッセージに電子署名をする」をチェックしておきます。

暗号化

「選択」をクリックすると「証明書の選択」画面が表示されるので、このアカウントで

122

暗号化と復号に使う証明書を選択します。メッセージ作成画面の初期値として暗号化を

する場合は「暗号化をする」を選択しておきます。

図 4-49 Thunderbird でデジタル署名用、暗号化用の証明書の選択画面

(3) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手にデ

ジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、通

常はデジタル署名には署名者（すなわち通信相手）の証明書が添付されています。

Thunderbird では証明書を自動的に保管するので、あなたが必要なときに使うことがで

きます。

証明書マネージャでインポートする

「証明書マネージャ」で「他の人の証明書」のページで証明書ファイルからインポート

します。

123

(4) メッセージの送信

メッセージ作成画面で、「セキュリティ」アイコンをクリックして暗号化とデジタル署名

の指定をします。

「セキュリティ情報を見る」をクリックすると、作成中のメッセージのデジタル署名の有

無と暗号化に必要な送信先の証明書が揃っているかを確認できます。

図 4-50 Thunderbird のメッセージ作成画面でのデジタル署名と暗号化の指定

124

(5) メッセージの受信

正常なメッセージの場合

図 4-51 のようにメッセージがデジタル署名されている場合はペンのアイコン、暗号化

されている場合は鍵のアイコンが表示されます。

図 4-51 Thunderbird でデジタル署名付きで暗号化されているメッセージを表示しています。

アイコンをクリックすると、図 4-52 のような画面でセキュリティに内容が表示されま

す。

図 4-52 Thunderbird で受信したメッセージのデジタル署名と暗号化の情報を表示

125

不正なメッセージの場合

受信したメッセージのデジタル署名に問題があると、図 4-53 のようにペンにバツ印の

付いたアイコンとなります。

図 4-53 Thunderbird で受信したメッセージのデジタル署名で不正が検出された場合

アイコンをクリックすると、問題点について確認できます。ただし、現状の Thunderbird

ではデジタル署名の不正は原因にかかわらず同じ内容のメッセージが表示されます。

図 4-54 Thunderbird で受信したメッセージのデジタル署名の不正の説明

126

4.4.4. RimArts Inc. “Becky! Internet Mail” (Windows XP）

Becky! Internet Mail Ver. 2.0 は標準では S/MIME をサポートしていませんが、プラグイ

ンとして” Becky! S/MIME plug-in Ver.1.09”をインストールすると S/MIME が利用可能

となります。

Becky! Internet Mail は Windows 標準の証明書ストアを使っています。

(1) 設定

S/MIME plug-in をインストールすると図 4-55 のように、メイン画面の「ツール」メニ

ューに「S/MIME: 復号と検証」、「S/MIME: 設定」が追加されます。メール作成画面に

は「S/MIME: 暗号化」「S/MIME: 署名」「S/MIME: 署名と暗号化」が追加されます。

図 4-55 メイン画面とメール作成画面の「ツール」メニューに S/MIME の指定があります。

127

メイン画面の「S/MIME: 設定」で表示される図 4-56 の画面で設定を行います。証明書ス

トアに自分と通信相手の証明書がすでにあることが前提になっています。ここでの設定は、

初期値のままでも問題ありません。

自分用に暗号化あるいはデジタル署名する場合に使用する証明書は、「送信メールの From

フィールド」あるいは指定したメールアドレスから証明書ストアを検索して見つけた有効

な証明書が自動的に利用されます。

図 4-56 Becky! Internet Mail の S/MIME 設定

(2) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手にデ

ジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、通

常はデジタル署名には署名者（すなわち通信相手）の証明書が添付されています。

Becky! Internet Mail では署名の検証で証明書が証明書ストアにない場合、保存の確認

メッセージが表示されるので、信頼しているルート認証局までの証明書チェーンが確立

されている場合は保存しましょう。あなたが必要なときに使うことができます。

Windows の証明書管理機能でインポートする。

Windows の証明書管理機能を使って通信相手の証明書をファイルで入手し、あらかじめ

インポートしておきます。

(3) メッセージの送信

メール作成ウィンドウで、宛先の指定とメッセージの作成が完了したら、「ツール」メニ

ューから「S/MIME: 暗号化」「S/MIME: 署名」「S/MIME: 署名と暗号化」を実行しま

128

す。暗号化やデジタル署名が成功すると、図 4-57 のように使用した証明書の情報などが

表示されます。宛先の証明書が見つからない場合など処理が失敗した場合には、その旨の

メッセージが表示されます。ただし、暗号化で、複数の宛先のすべての証明書が見つから

ない場合、見つかった証明書のみで暗号化して処理を継続することもできるので気をつけ

ましょう。

図 4-57 Becky! Internet Mail で「S/MIME:署名と暗号化」を実行したところ

処理が完了すると、図 4-58 のように添付ファイル付きのメッセージとして表示されます。

図 4-58 Becky! Internet Mail で「S/MIME: 暗号化」または「S/MIME: 署名と暗号化」

を実行した後、smime.p7m という添付ファイルが追加される

図 4-59 Becky! Internet Mail で「S/MIME: 署名」を実行した後、smime.p7s という添

付ファイルが追加される

129

(4) メッセージの受信

正常なメッセージの場合

メイン画面の「ツール」メニューに「S/MIME: 復号と検証」を実行すると図 4-60 のよう

に暗号化とデジタル署名の情報が表示されます。

図 4-60 Becky! Internet Mail で受信したメッセージのデジタル署名と暗号化の情報を表示

不正なメッセージの場合

受信したメッセージのデジタル署名に問題があると、「S/MIME: 復号と検証」を実行す

ると図 4-61 のようにメッセージが表示されます。

図 4-61 Becky! Internet Mail で受信したメッセージの改ざんを検出

130

図 4-62 Becky! Internet Mail で信頼しているルート認証局までの証明書チェーンがつながらない場合。

注意点

デジタル署名では、署名データに署名者の証明書を添付せずに証明書の識別子だけを送

る場合ありますが、そのような場合 Becky! Internet Mail では、検証に失敗し図 4-63

のようなメッセージを表示します。Windows の証明書ストアに署名者の証明書があった

としても参照されないため同じ結果となります。

図 4-63 Becky! Internet Mail で証明書が添付されていないデジタル署名を検証した結果

131

4.4.5. オレンジソフト “Winbiff +S/Goma ”(Windows XP）

オレンジソフト “Winbiff”は標準では S/MIME をサポートしていませんが、プラグインと

して” S/Goma”をインストールすると S/MIME が利用可能となります。本項では、Winbiff

と S/Goma の組み合わせで S/MIME を利用する様子を説明します。

取り上げるバージョンは以下のとおりです。

Winbiff バージョン 2.50

S/Goma バージョン 3.1

S/Goma は Windows 標準の証明書ストアを使っています。したがって、Internet Explorer

で取得した公開鍵証明書がそのまま使えます。

(1) 設定

S/Goma をインストールして、メイン画面の「ツール」メニューの「ユーザー設定」ウィ

ンドウで、図 4-64 のような「暗号」のページを開きます。ここで、S/MIME の 設定を行

います。S/MIME の枠の中の各設定項目のボタンをクリックするとそれぞれ画面が表示さ

れます。

ただし、「新規鍵の作成」は S/Goma V.3.1 ではサポートされていないため、クリックす

ると未サポートを通知するメッセージが表示されます。「新規鍵の作成」は以前のバージ

ョンの S/Goma がインストールされている場合に有効な機能で、互換性のために残されて

いるものです。

図 4-64 Winbiff＋S/Goma ユーザー設定／暗号画面

132

a. 証明書一覧

証明書一覧では、Windows 証明書ストアが以下のように対応づけられて表示されます。

あなたの証明書

Windows 証明書ストアの「個人」です。公開鍵とプライベート鍵をペアでもっている自

分の公開鍵証明書が表示されます。

他人の証明書

Windows 証明書ストアの「ほかの人」です。認証局の公開鍵証明書ではない、通信相手

となる利用者の公開鍵証明書が表示されます。

図 4-65 Winbiff＋S/Goma 証明書一覧

「署名用」ボタン、「暗号用」ボタン

証明書を選択して、「署名用」ボタン、「暗号用」ボタンをクリックすると、送信時に使う用途

を指定できます。

「詳細」ボタン

証明書プロパティウィンドウが開き、証明書の内容が詳細に確認できます。

「削除」ボタン

Windows 証明書ストアから削除します。

133

「インポート」ボタン

一覧から証明書を選択して「インポート」をクリックしファイルにエクスポートします。複数の

証明書を選択して PKCS#7 ファイルにエクスポートすることも可能です。

「あなたの証明書」タブでは、PKCS#12 形式へのインポートも可能です。

「エクスポート」ボタン

「エクスポート」をクリックし、証明書ファイルを指定して、ファイルからインポートします。

「あなたの証明書」タブでは、PKCS#12 形式のファイルからのインポートが可能です。

b. 環境設定

関連する稼働中のプログラムのバージョンなどが表示されます。

c. セキュリティ設定

S/MIME オプション

図 4-66 Winbiff＋S/Goma セキュリティ設定／S/MIME オプション設定画面

証明書を添付する

デジタル署名をする場合に証明書を添付します。Windows メール、Outlook Express

の「署名付きメッセ－ジにデジタル ID を追加する」と同じ意味です。

134

分離署名

デジタル署名の際に、メッセージをエンコードです。メールの本文として送信します。

Windows メール、Outlook Express の「署名する前にメッセージをエンコードする」の

反対です。

電子署名に利用する証明書

送信時にデジタル署名に使う証明書の初期値を決めておきます。

受信者として自分を加える。

暗号化のとき、送信先の証明書に加え、予め選択されている自分の証明書を使って暗号化さ

れます。Windows メール、Outlook Express の「暗号化された送信メッセージを自分向け

にも暗号化する」に相当します。

利用する暗号の方式

デジタル署名データの中には、通信相手が暗号化をする時に使ってほしい共通鍵暗号のアル

ゴリズムを指定できます。そのため、ここでアルゴリズムを選択し、デジタル署名データに

含めます。

詳細

ソフトウェアとしての動作の指定をします。

135

図 4-67 Winbiff＋S/Goma セキュリティ設定／詳細画面

暗号化のとき、S/MIME のオプションを毎回確認する

送信時に、暗号化のオプションを確認します。

暗号化のとき、アルゴリズムを毎回確認する

送信時に、暗号化のオプションを確認する画面で、メッセージを暗号化するアルゴリズムを

選択できるようにします。

受信した証明書をインポートする

電子署名のデータに証明書が添付されていた場合、自動的に証明書データベースに取り込み

ます。

Content-Type を旧式で表現する

x-pkcs7-mime、x-pkcs7-signature などのように、x-をつけます。

メールの From ヘッダーのアドレスをチェックする

受信した電子署名付きのメールで、署名者の証明書のメールアドレスと、メッセージヘッダ

ーの From のアドレスが一致しているかを確認します。

無効な証明書を使う

送信時、暗号化先に無効な証明書も指定可能にします。

136

証明書失効リストをチェックする

Windows 標準の失効検証ルーチンを使って、証明書の失効が確認されます。

ディレクトリサーバー

証明書の検索に使う、ディレクトリサーバーを登録しておきます。

図 4-68 Winbiff＋S/Goma セキュリティ設定／ディレクトリサーバー画面

名前

ディレクトリサーバーを識別する任意の名前です。

ホスト名

ディレクトリサーバーのホスト名です。

標準

○印が付いているサーバーが、検索画面の初期状態で選択されているディレクトリサーバー

です。

[プロパティ]ボタン

ディレクトリサーバーの登録情報を確認します。

「標準」ボタン

137

選択したディレクトリサーバーを「標準」に変更します。

「追加]ボタ

ディレクトリサーバーを追加します。

「削除」ボタン

登録されているディレクトリサーバーをリストから削除します。

ディレクトリサーバーのプロパティ

ディレクトリサーバーのプロパティとして以下のような内容を指定します。

サーバー名

アクセス可能なディレクトリサーバーのホスト名を入力します。

ポート

ディレクトリサーバーの LDAP アクセスのポート番号を入力します。通常は 389 です。

サーチルート

検索のベースとなる、ポインポートを指定しておきます。

検索のタイムアウト

ディレクトリサーバーと通信時間に制限を与えます。

検索の表示件数の上限

検索結果が多いと、通信に時間がかかり、処理が遅くなるので、制限を設けます。

d. 認証局一覧

認証局一覧では、Windows 証明書ストアが以下のように対応づけられて表示されます。

CA の証明書

Windows 証明書ストアの「中間証明機関」です。ルート認証局から利用者（エンドエン

ティティ）の証明書までをつなぐ、中間の認証局の証明書が表示されます。

ルート証明書

Windows 証明書ストアの「信頼されたルート証明機関」です。ルート認証局の証明書が

表示されます。

図でわかるように、無効な証明書にはアイコンにバツ印がついています。

138

図 4-69 Winbiff＋S/Goma の認証局一覧画面

「詳細」ボタン

証明書プロパティウィンドウが開き、証明書の内容が詳細に確認できます。

「削除」ボタン

Windows 証明書ストアから削除します。

「インポート」ボタン、「エクスポート」ボタン

PKCS#12 形式でプライベート鍵と証明書のインポートやエクスポートを行います。

(2) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手にデ

ジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、通

常はデジタル署名には署名者（すなわち通信相手）の証明書が添付されています。Winbiff

＋S/Goma では署名の検証で送信元の証明書が証明書ストアにない場合、自動的に

Windows 証明書ストアに保存します。あなたが必要なときに使うことができます。

Windows の証明書管理機能でインポートする

Windows の証明書管理機能を使って通信相手の証明書をファイルで入手し、あらかじめ

インポートしておきます。

139

ディレクトリサーバーから検索する

Winbiff＋S/Goma にはディレクトリサーバーの検索機能があります。

認証局がディレクトリサーバーに証明書も一緒に保管していれば、ディレクトリサーバ

ーから証明書を取り出して証明書ストアにインポートできます。

以下、その操作について説明します。

「証明書一覧」画面の「他人の証明書」ページで「ディレクトリ検索」をクリックする

と「ディレクトリの検索」画面が表示されます。

「ディレクトリの検索」画面では、「セキュリティ設定」で登録しておいたディレクト

リサーバーが選択可能です。メールアドレスや名前など、検索の条件を指定して「検索」

をクリックします。

「証明書」画面には検索に該当した証明書が一覧表示されます。

140

図 4-70 Winbiff＋S/Goma のディレクトリサーバーへの検索の流れ

141

(3) メッセージの送信

暗号化、デジタル署名の指定

メールの作成画面で、「ツール」メニューの「暗号化＋電子署名」あるいは「電子署名」

を選択します。「送信の確認」画面でも同様に「暗号化＋電子署名」、「電子署名」を

指定できます。

図 4-71 Winbiff の「送信の確認」画面

「セキュリティ設定／詳細」で、「暗号化のとき、S/MIME のオプションを毎回確認す

る 」や「暗号化のとき、アルゴリズムを毎回確認する」をチェックしていると、毎回、

暗号化時に使う相手の証明書やデジタル署名に使う自分の証明書を確認できます。その

さいには他に利用可能な証明書があれば、そちらに変更して使うことも可能です。

142

暗号化、デジタル署名の結果確認

処理が完了すると図 4-72 のような画面で処理結果を確認します。「OK」をクリックし

てからサーバーへ送信します。

図 4-72 Winbiff の暗号化、デジタル署名の結果確認画面

143

(4) メッセージの受信

Winbiff＋S/Goma では受信した、暗号文の復号や電子署名の検証は「メール」メニューの

「暗号の復号」を選択して行います。

正常なメッセージの場合

図 4-73 のように復号や署名検証の結果が表示されます。

図 4-73 Winbiff + S/Goma での復号や署名検証の結果の確認画面

144

不正なメッセージの場合

受信したメッセージのデジタル署名に問題があると、図 4-74 のように人物にバツ印の

付いたアイコンとなり、説明の文章の部分が赤い背景となり警告します。

図 4-74 Winbiff + S/Goma での復号や署名検証の結果の確認画面で不正な電子署名であった場合

145

4.4.6. Mac メール

Mac OS X の標準の電子メールソフト”Mail”では標準で S/MIME をサポートしています。

取り上げるバージョンは Mac OS X 10.2 です。

(1) 公開鍵証明書の管理

Mac OS X では、パスワードなどを管理するキーチェーンという機能がありますが、証明

書もキーチェーンで管理されます。Mail は、このキーチェーンの証明書を使って S/MIME

の処理をします。

図 4-75 のように、「ログイン」キーチェーンの分類「証明書」に認証局の証明書を含む

証明書が管理されています。信頼されたルート認証局の証明書はこれとは別に

「X509Anchors」キーチェーンにインストールされています。

図 4-75 Mac OS X キーチェーンの公開鍵証明書管理機能

(2) 設定

Mail では事前の設定はありません。証明書に記載されているメールアドレスと一致するメ

ールのアカウントを使うと、自動的にデジタル署名が可能になり、暗号化の宛先のメール

アドレスからキーチェーンにある証明書が自動的に採用されます。

146

(3) 他人の証明書の収集

デジタル署名付きのメールを受信する

他人の証明書を入手するためのもっとも簡単な方法は、暗号メールを送りたい相手にデ

ジタル署名したメールを送ってもらうことです。オプションの指定にもよりますが、通

常はデジタル署名に署名者（すなわち通信相手）の証明書が添付されています。Mail

では、署名の検証で送信元の証明書がキーチェーンにない場合、自動的にキーチェーン

に保存し必要なときに使うことができます。

キーチェーンでインポートする

通信相手の証明書をファイルで入手して、キーチェーンの「ファイル」メニューの「読

み込み」を使って、あらかじめインポートしておきます。

(4) メッセージの送信

暗号化、デジタル署名の指定

新規メッセージ作成画面で、利用可能な証明書を持つメールアカウントがある場合、図

4-76 のように鍵のアイコンとチェックマークのアイコンが表示されます。

鍵のアイコンをクリックすると暗号化を、チェックマークのアイコンをクリックするとデ

ジタル署名をします。

暗号化の指定をしても送信先の証明書がない場合、「送信」を実行したあと、暗号化をせ

ずに送信するか確認されます。

図 4-76 Mac OS X の“Mail”で新規メッセージ画面での暗号化、デジタル署名の指定

147

(5) メッセージの受信

Mail では、受信したメッセージが暗号化やデジタル署名がされている場合、自動的に復号

および署名の検証がされます。

正常なメッセージの場合

図 4-77 のように復号や署名検証の結果が表示されます。

図 4-77 Mac OS X の“Mail”で復号や署名検証の結果の表示

不正なメッセージの場合

受信したメッセージのデジタル署名に問題があると、図 4-78 のようにメッセージの上部

に警告が表示されます。「詳細情報を表示」をクリックすると、理由が表示されます。「?」

をクリックすると詳しい説明が表示されます。

図 4-78 Mac OS X の“Mail”で復号や署名検証の結果、不正な電子署名であった場合

148

5. FAQ

5.1. Q1：公開鍵証明書はどのように入手できますか？

S/MIME メールを利用するために必要な自分の公開鍵証明書は、以下のような方法で入手

できます。

i. 公開されている認証サービスを利用する

公開鍵を発行することをサービス（認証サービス）として提供している会社があるので、こ

れを利用する方法です。

参考までにいくつかの URL を示します。日本ベリサイン のものは 1 個ずつ購入すること

ができます。

セコムトラストシステムズ「パブリック CA 署名サービス」

http://www.secomtrust.net/service/ninsyo/index.html

富士ゼロックス「SDES」http://www.fujixerox.co.jp/product/service/sdes/

日本ベリサイン 「個人用電子証明書」http://www.verisign.co.jp/personal/index.html

サイバートラスト「Cybertrust Shared PKI」

http://www.cybertrust.ne.jp/shared_pki/index.html

日本ジオトラスト「トゥルークレデンシャル エクスプレス」

http://www.geotrust.co.jp/pki/products.html

米国コモド

http://www.comodogroup.com/products/certificate_services/email_certificate.ht

ml

ii. 専用の認証局を立ち上げる

自分の所属する組織内の利用者へ専用の認証局から証明書を発行します。これは、さらに 2

つの方法に分けられます。

a. 外部のルート認証局の配下に自分の所属する組織用の中間認証局を設ける

認証サービスを提供している会社では、個々の利用者に直接公開鍵証明書を発行するサービ

スとは別に、希望する組織に中間認証局を立ち上げ、組織内の利用者の公開鍵証明書を組織

内に立ち上げた中間認証局から発行できるサービスを提供しています。このようなサービス

は「マネージド PKI」と呼ばれています。

セコムトラストシステムズ「パブリック CA 署名サービス」

http://www.secomtrust.net/service/ninsyo/publicca.html

日本ベリサイン 「マネージド PKI」

http://www.verisign.co.jp/mpki/index.html?ps=mpki

149

サイバートラスト「Cybertrust Managed PKI」

http://www.cybertrust.ne.jp/managed/index.html

日本ジオトラスト「トゥルークレデンシャル」

http://www.geotrust.co.jp/pki/products.html

b. 自分でルート認証局を立ちあげる

認証局を構築するソフトウェアを使って自分でルート認証局を作り、利用者用の公開鍵証明

書を発行することもできます。ルート認証局の証明書を各利用者に配布する必要があります

が、安全な経路で多くの利用者に配布する手順を十分な検討が必要です。（他の方法では、

Web ブラウザや電子メールソフトがルート認証局の証明書を証明書ストアにもっているの

で問題がありません。）

認証局を構築するソフトウェアとしては、オープンソースのプロジェクトで「OpenSSL 」

http://www.openssl.org/などがあります。そのほかにも商用の製品が多数存在します。

150

5.2. Q2:メールソフトでセキュリティのエラーの警告が表示されます

電子メールソフトでは、受信したデジタル署名付きのメッセージについて 2 種類の検証を

行います。

署名データが正しいか、つまり、メッセージが改ざんされていないか

送信者（署名者）が署名に使った公開鍵証明書が信頼できるものであるか、つまり、送信者

が信頼できるか

これらの検証を行った結果、セキュリティ上の問題が検出されると画面にメッセージを表

示します。

改ざんの検出を通知するメッセージの場合

メッセージの送り主に確認しましょう。

公開鍵証明書の問題の検出を通知するメッセージの場合

メッセージを開く前に警告がでる場合は、開くのをやめましょう。あるいは、メッセージを

開いた後に警告が表示される場合、添付ファイル付きのメッセージでは、添付ファイルを開

くことや、実行することはやめましょう。

セキュリティ上の問題を検出した場合の画面について、詳細は「2.2 電子メールにおける

デジタル署名による不正の検出」を参照してください。

151

5.3. Q3：公開鍵証明書のバックアップ方法についておしえてください

ほとんどのソフトウェアには、公開鍵証明書のバックアップ機能とバックアップしたファ

イルを取り込む（リストア）機能があります。

バックアップするファイル形式には、いくつかの標準的な仕様があり、ほとんどのソフト

ウェアではそれらの形式をサポートしています。したがって、安全のために公開鍵証明書

を退避させるだけでなく、アプリケーションのバックアップ機能を利用すれば、公開鍵証

明書を別の環境に取り込んで移行することも可能です。ファイルの形式については、「4.2

証明書ファイル」を参照してください。

それぞれの環境でのバックアップと取り込みの手順を説明します。

a. Windows

Windows では、コントロールパネルにあるインターネットオプションの「コンテンツ」タブで証明書

をクリックすると、図 5-1 の画面でインストールされている証明書が一覧で確認できます。ここで「エ

クスポート」を実行すると公開鍵証明書をファイルに保存することでバックアップすることができま

す。「インポート」を実行してバックアップしてあるファイルを指定すると、システムに取り込むこ

とができます。

図 5-1 Windows 証明書ストアの一覧表示

152

証明書の種類によってタブ付きのページに分類されて一覧表示されています。自分の証明書は「個人」

のタブで表示されています。

エクスポートの手順

「個人」タブメニューでは、自分のプライベート鍵と証明書をペアでバックアップできます。証明書

を選択して「エクスポート」をクリックしてウィザードを起動し、以下の手順でバックアップします。

i. 「証明書のエクスポートウィザード」画面が表示されて、開始の確認画面が表示されるの

で「次へ」をクリックします。

ii. 「秘密キーのエクポート」画面では、公開鍵証明書と対応するプライベート鍵を一緒にエ

クスポートするので、「はい、秘密キーをエクスポートします」をチェックします。

図 5-2 プライベート鍵と証明書を一緒にエクスポートします。

（Windows ではプライベート鍵を秘密キーと表記しています）

153

iii. 「エクポートファイルの形式」画面では、証明書パス上の認証局の証明書も合わせてエク

スポートするので、「証明のパスにある証明書を可能であればすべて含む」をチェックし

ます。

図 5-3 証明書チェーン上の証明書も一緒にエクスポートします。

154

iv. 「パスワード」画面では、パスワードを指定してください。PKCS#12 形式のファイルに

プライベート鍵をエクスポートする際には、パスワードを使って鍵を暗号化します。作成

したファイルから取り込む際には、このパスワードが確認されます。

図 5-4 エクスポートするプライベート鍵を、パスワードを鍵として暗号化して保護します。

155

v. 「エクスポートするファイル」ではファイル名を入力または指定します。

図 5-5 最後にエクスポートするファイル名を指定します。

vi. 「証明書エクスポートウィザードの完了」画面では「完了」をクリックして処理を実行し

ます。次に処理の完了の通知メッセージが表示されたら「OK」をクリックすると完了です。

156

b. Mac OS Ⅹ

「キーチェーンアクセス」を起動します。証明書を選択して「ファイル」メニューの「書き出し」で

ファイルにバックアップできます。システムへの取り込みは「ファイル」メニューの「読み込み」で

ファイルを指定して実行します。

図 5-6 Max OS Ⅹのキーチェーンアクセス

157

c. Mozilla Thunderbird あるいは Mozilla Firefox

「ツール」メニュー／「オプション」で表示されるウィンドウで「プライバシー」設定

の「セキュリティ」のページに「証明書を表示」をクリックします。

証明書を選択し「バックアップ」をクリックします。バックアップしたファイルを取り

込む場合は「インポート」をクリックします。

図 5-7 Thunderbird の「証明書の表示」

158

5.4. Q4：S/MIME 非対応の電子メールソフトではどうなりますか？

Windows の各種メールソフト、Mac Mail、Mozilla Thunderbird などによって、ほとん

どの OS で S/MIME メールを利用することが可能ですが、一部の電子メールソフトは

S/MIME に対応していません。その場合、S/MIME のメールを受信すると、不明の添付フ

ァイル付きのメールとして扱われます。ファイル名は以下のようになっています。これは

S/MIME の仕様で決められています。

デジタル署名の場合は smime.p7s

暗号の場合は smime.p7m

図 5-8 S/MIME に対応していない電子メールソフトでは添付ファイル付きのメールとして扱われる。

159

5.5. Q5：S/MIME と PGP との違いはなんですか？

S/MIME も PGP も、ともに公開鍵暗号方式を使って電子メールにデジタル署名と暗号化

の機能を加えるプロトコルです。この二つは公開鍵の信頼の手順が異なります。そのため

配布される公開鍵のフォーマットも異なり、電子メールに適用した場合のフォーマットも

別の形式となります。

「1.2.4.1PKI（公開鍵基盤）」の「(1) 信頼のモデル」と「1.2.4.2PGP」を参照してくだ

さい。

160

5.6. Q6：ルート証明書についてセキュリティの警告画面が表示されます

PKI における信頼のモデルの最上位に位置するルート認証局の公開鍵証明書は自身のプ

ライベート鍵でデジアル署名しています。ルート認証局の公開鍵証明書を受け取ったとき

はデジタル署名の検証とは別の確認方法が必要です。そのような場合、拇印を確認するこ

とが有効です。そのため、Windows では、ルート認証局の公開鍵証明書をシステムに取

り入れるとき、図 1-13 のような確認画面が表示されます。拇印が示されていますので、

その拇印が、インストールしようとしているルート認証局の証明書の拇印として正しいこ

とを確認してからインストールしなければなりません。拇印の確認は信頼できる情報の伝

達手段により十分に安全な方法で行う必要があります。

図 5-9 Windows でルート認証局の公開鍵証明書をシステムに取り入れるときの確認画面

161

6. まとめ

当初は特定の相手との電子的なコミュニケーションが主な目的であった電子メールです

が、近年では、例えばオンラインコマースや不特定多数の参加者により構成されるオンラ

インコミュニティーなどのようにインターネットの利用方法の多様化にともない、電子メ

ールにも多様な情報を伝送する手段としての役割が求められています。こうした用途の変

化により、特定の相手が発信者であるようなメッセージのみならず、未知の発信者からの

メッセージも重要な情報である場合も出てきました。反面、問題となるのがフィッシング

メールやウィルス付きメール、スパムメールです。重要な情報やそうでない情報が混在す

る環境では、電子メールの受信者がメッセージの受信とともにその選別を行うことになり

ます。例えば、ウィルス付きメールであればウィルスチェックソフトによる電子メールの

監視、スパムメールならばスパムフィルタなどのようにシステム的な対応も可能です。し

かし、尐なからず人為的な労力による選別も必要となっています。

一方、Windows や Mac OS X などでは OS レベルで PKI がサポートされています。これ

は Web ブラウザでの SSL による認証とデータの暗号化の必要性が大きな要因として考え

られますが、PKI の普及に伴い、多くの電子メール環境で S/MIME メールのサポートが

なされることとなり、S/MIME の利用環境は整いつつあります。

このような状況の中、電子メールの発信者はメッセージにデジタル署名を付けて信頼性を

明確にすることで、受信者の負担を軽減することが考えられます。受信側での防御ではな

く、発信側での保証が S/MIME の特徴です。

そういった取り組みが、都市銀行や、携帯電話会社、政府系の登録ユーザーへのニュース

メールなどに見られることができます。今後、さらに重要となるインターネットのコミュ

ニケーションにとって、電子メールの信頼性は重要な問題となります。そこでは S/MIME

などの電子メールの保証の仕組みが有効な手段となりうるでしょう。

162

7. 資料

7.1. S/MIME のメールメッセージ

7.1.1. 標準仕様

(1) RSA 暗号アルゴリズム

RFC 3560 "Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic

Message Syntax (CMS)"

RSA 公開鍵暗号方式を使った暗号化の処理について記述しています。

RFC 4056 "Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message

Syntax (CMS)"

RSA 公開鍵暗号方式を使ったデジタル署名の処理について記述しています。

(2) 暗号データのフォーマット

RFC 3852 “Cryptographic Message Syntax (CMS)”

デジタル署名データ、暗号化データのフォーマットについて記述しています。RSA Data

Security Inc.が公開した仕様 PKCS#7 をベースに作成されているため、慣例的

に”PKCS#7”と呼ばれることもあります。

(3) S/MIME の電子メールメッセージのフォーマット

RFC 2311 "S/MIME Version 2 Message Specification"

RFC 2633 "S/MIME Version 3 Message Specification"

RFC 3851 "S/MIME Version 3.1 Message Specification"

CMS のオプションと S/MIME のメールメッセージについて記述しています。

(4) アプリケーションでの証明書と失効リストの取扱方法

RFC 2312 "S/MIME Version 2 Certificate Handling"

RFC 2632 "S/MIME Version 3 Certificate Handling"

RFC 3850 "S/MIME Version 3.1 Certificate Handling"

(5) S/MIME V3 の拡張機能

セキュリティラベル、デジタル署名付き受信確認メッセージの仕様です。

RFC 2634 "Enhanced Security Services for S/MIME"

(6) 証明書署名要求

RFC2986" PKCS #10: Certification Request Syntax Specification Version 1.7"

認証局への証明書署名要求データのフォーマットについて記述しています。

(7) 公開鍵証明書と失効リスト

RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"

163

(8) PKCS(Public-Key Cryptography Standards)28

もともと、S/MIME は米国の RSA Data Security Inc.29が中心なって開発された、電子メ

ールの暗号プロトコルです。そのため、S/MIME で用いられる暗号文のデータフォーマッ

トは PKCS(Public Key Crypt System)と呼ばれる RSA Data Security Inc.が開発して仕

様を基本にしているのです。

28 https://www.rsa.com/rsalabs/node.asp?id=2124 29 RSA Data Security Inc.は 2006 年 6 月、EMC に買収されて EMC の 1 部門となった。

164

7.1.2. 標準仕様と電子メール作成までの処理の流れ

S/MIME のメールメッセージは図 7-1 のように RFC に基づき処理されます。

図 7-1 処理の流れと標準仕様

i. 元メールから所定のダイジェスト関数でダイジェスト値の計算をします。あるいは、秘密

鍵を生成し共通鍵暗号を使って暗号化します。

ii. RFC 4056、RFC 3560 に従い、デジタル署名のダイジェスト値、暗号化の共通鍵を入力と

して RSA 公開鍵暗号の処理をします。

iii. RSA公開鍵暗号で作成したデータと付随する情報をRFC 3852に規定されたフォーマット

にします。

iv. 作成した CMS データを BASE64 にエンコードして、RFC 3851 に規定されている、MIME

ヘッダーをつけた添付ファイルにします。ただし、S/MIME は Internet Draft であった段

階からアプリケーションが存在したため、一部の古い電子メールソフトでは、Internet

165

Draft の段階で定義されていた MIME ヘッダーを使っています。

7.1.3. MIME ヘッダー

7.1.3.1. メールの MIME ヘッダー

(1) 暗号化または、デジタル署名を含む暗号化されたメッセージ

RFC

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m

Internet Draft

Content-Type: application/x-pkcs7-mime; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m

(2) デジタル署名

RFC

Content-Type: application/pkcs7-mime; smime-type=signed-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m

Internet Draft

Content-Type: application/x-pkcs7-mime; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m

(3) クリアデジタル署名

RFC

Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s

Internet Draft

Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s

(4) 証明書

RFC

Content-Type: application/pkcs7-mime; smime-type=cert-only; name=smime.p7c Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7c

Internet Draft

Content-Type: application/x-pkcs7-mime; name=smime.p7c Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7c

166

7.1.4. S/MIME メールメッセージの例

(1) クリアデジタル署名 multipart/signed の場合

To: Hiroyuki Sawano <sawano@orangesoft.co.jp > From: Taro Yamada <yamada@orangesoft.co.jp > Subject: Digital Sign MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8B7876C5A4971B52E1D24E61" This is a cryptographically signed message in MIME format. --------------ms8B7876C5A4971B52E1D24E61 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit こんにちは、 明日の打ち合わせの件ですが、（JISコード） --------------ms8B7876C5A4971B52E1D24E61 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQDwYJKoZIhvcNAQcCoIIQADCCD/wCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dn0wggnHMIIJMKADAgECAhA4kcRP4QGC7RTq2FZKZF0TMA0GCSqGSIb3DQEBBAUAMGIxETAP （中略） MjQ2MzRaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAE QBOPytJm3nmFp6lYXCZHlDyG9VULk8hhgyU0vAHELLV/9Grx4+5fVbeerP/YXSmoZx8G6CTw J7/hi+ooJvN4cuM= --------------ms8B7876C5A4971B52E1D24E61--

(2) PKCS#7 signedData の場合

To: Hiroyuki Sawano <sawano@orangesoft.co.jp > From: Taro Yamada <yamada@orangesoft.co.jp > Subject: Digital Sign MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAaCAJIAEbkNv bnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVk （中略） hvcNAQkEMRIEEFE6IM/MZQmTGdlaAG17hE4wDQYJKoZIhvcNAQEBBQAEQC+f4FYqZiV4QgzS3BAB YpazDyMF61HtuVOU5rZ9lguQzFB/nH6K+G0cF1+hAmaGdpFkC3lCVh0Py2XnMPg5TvoAAAAAAAAA AA==

(3) 暗号化

To: Hiroyuki Sawano <sawano@orangesoft.co.jp > From: Taro Yamada <yamada@orangesoft.co.jp > Subject: Digital Envelop MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgc8wgcwCAQAwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDEgQ0Eg （中略） Bh0SaWCqCd9p0OpbNnHyi2G3tvMEuC74u+nvWjZT8fXeBAggdxGjYOObZQQIUHE0vqb2lnIA AAAAAAAAAAAA

167

(4) デジタル署名+暗号化

To: Hiroyuki Sawano <sawano@orangesoft.co.jp > From: Taro Yamada <yamada@orangesoft.co.jp > Subject: Digital Sign And Digital Envelop MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgc8wgcwCAQAwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDEgQ0Eg LSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEDiRxE/hAYLtFOrYVkpkXRMwDQYJKoZIhvcNAQEB （中略） BJ/HfTc8/7A5BBBpHHa3fZXWmE4T/uRhx4NiBDCGvxP7QFMih9lWyt6FPuCfmwwHJOrjqBkQ eORM8+HsW8F50a47Pk7VZ6cEBs7NXw8ECIhY5KF/fCVhAAAAAAAAAAAAAA==

7.2. 証明書の実例

米国ベリサインが発行したエンドユーザー向けの証明書の中身を表 7-1 に示します。

表 7-1 証明書の実例

項目 値（例）または説明

証明書フォーマット

のバージョン

V3

証明書のシリアル番

号

‎5d 8b 76 e6 41 c9 8b 9a dc 45 a3 f7 b3 85 c5 10

デジタル署名のアル

ゴリズム

md5withRSAEncryption

証明書発行者（認証

局）名 DN

CN = Application Service CA

OU = Class 1 OnSite Individual Subscriber CA

OU = Terms of use at https://www.verisign.co.jp/rpa (c)03

OU = VeriSign Trust Network

O = VeriSign Japan K.K.

有効期限 開始 2006 年 11 月 14 日 9:00:00

終了 2007 年 12 月 15 日 8:59:59

証明書所持者名 DN E = sawano@orangesoft.co.jp

CN = Hiroyuki Sawano

T = Nippon Jimuki CO.,LTD.

OU = 1 - 808016

OU = VS - 100035273

OU = for - Seplus Secure Mail

168

OU = Terms of use at www.verisign.co.jp/rpa (c)03

OU = Application Service CA

O = VeriSign Japan K.K.

証明書所持者名の公開鍵情報

アルゴリズムの ID RSA(1024 ビット)

公開鍵 30 81 89 02 81 81 00 B4 B6 30 57 A5 57 C9 40 9C

B4 DA 47 50 5B D3 13 6F 30 E4 1E 6F 36 97 5D 59

….

73 1A 05 67 D5 AC FF F1 06 86 4D EB 63 2F 57 70

X.509 V3 拡張

基本制限 Subject Type=End Entity

Path Length Constraint=None

証明書ポリシー Policy Identifier=2.16.840.1.113733.1.7.23.1

[1,1]Policy Qualifier Info:

Policy Qualifier Id=CPS

Qualifier:

https://www.verisign.co.jp/rpa

キー使用法 Digital Signature , Key Encipherment(A0)

Netscape Cert Type SSL クライアント認証(80)

CRL 配布ポイント URL=http://onsitecrl.verisign.co.jp/VeriSignJapanKKApplicationServ

iceCA/LatestCRL.crl

拡張キー使用法 電子メールの保護 (1.3.6.1.5.5.7.3.4)

クライアント認証 (1.3.6.1.5.5.7.3.2)

署名

アルゴリズムの ID md5withRSAEncryption

署名データ 49 AB 1D AC 7A BF 6D 54 09 E0 53 0C DB CF 53 8E

32 7D 0E 1E EB 17 F9 A6 BC 5B 12 D2 8A 6D C3 DE

….

CC 7C 4B 47 A9 20 DA 31 3F B9 C6 50 46 26 31 36

7.3. 証明書チェーンの実例

階層形モデルのＣＡの構造をもつ証明書チェーンの例として、米国ベリサインの構造を以

下に示します。

169

米国ベリサインでは、セキュリティのレベルに応じて、クラス 1～4 の４つのルート認証

局が存在します。

それぞれのルート認証局を根として、以下のような階層構造が実現されています。

証明書を発行する際の本人確認の仕方などによって、Class1(簡易)～Class4(厳密)に分れ

ています。例えば、Class1 では受信したメール中の送信元メールアドレスと認証データ中

のメールアドレスが一致していれば、OK となります。

図 7-2 証明書チェーンの例

A) ルート証明書の所持者の X.500 名前

OU = VeriSign Trust Network

OU = (c) 1998 VeriSign, Inc. - For authorized use only

OU = Class 1 Public Primary Certification Authority - G2

O = VeriSign, Inc.

C = US

B) 中間の CA の証明書の所持者の X.500 名前

CN = VeriSign Japan Class 1 CA - G2

OU = VeriSign Trust Network

O = VeriSign Japan K.K.

170

C) 中間の CA の証明書の所持者の X.500 名前

CN = Application Service CA

OU = Class 1 OnSite Individual Subscriber CA

OU = Terms of use at https://www.verisign.co.jp/rpa (c)03

OU = VeriSign Trust Network

O = VeriSign Japan K.K.

D) エンドユーザーの証明書の所持者の X.500 名前

E = sawano@orangesoft.co.jp

CN = Hiroyuki Sawano

T = Nippon Jimuki CO.,LTD.

OU = 1 - 808016

OU = VS - 100035273

OU = for - Seplus Secure Mail

OU = Terms of use at www.verisign.co.jp/rpa (c)03

OU = Application Service CA

O = VeriSign Japan K.K.

米国ベリサインの 証明書チェーンの階層の詳細は米国ベリサインの Web サイト

「Repository /VeriSign PKI Hierarchy」

http://www.verisign.com/repository/hierarchy/hierarchy.pdf

を参照してください。

171

7.4. その他の公開鍵管理機構

～Java の証明書管理～

「4.3.1Windows での証明書管理」 や「4.4.6Mac メール」で取り上げた OS での証明書

管理や「4.4.3Mozilla Thunderbird」で取り上げたアプリケーションでの証明書管理の他

に、アプリケーションの動作環境である Java にも証明書管理機構もあります。ここでは、

J2RE（Sun Java 2 Runtime Environment）の証明書管理機構について紹介します。

(1) 証明書の一覧

下図は、Java コントロールパネルでルート認証局の証明書一覧を表示しているところです。

172

図 7-2 J2RE の証明書管理機能

(2) 証明書の表示

一覧から証明書を選択して「詳細」をクリックすると、図 7-3 のような画面で証明書の内

容が確認できます。Windows の証明書表示と異なり、認証局のデジタル署名も確認でき

ます。図 7-3 の例では、ルート認証局の証明書ですから「発行者」と「被認証者」が同じ

自己署名となります。

173

図 7-3 J2RE の証明書の詳細表示画面

174

おわりに

この啓発資料「電子メールのセキュリティ“電子メールの安全性を高める技術の利用法”」

は、エンドユーザーが電子メールを利用する際に行えるセキュリティ対策の参考資料とし

て、電子メール利用時における脅威の概要とそれへの対処法を適切に対応付けることによ

り、安心してコンピュータを利用出来ることを目標にとりまとめました。

電子メールの標準仕様はインターネット黎明期に善意に拠った古き良き行動様式を前提

に定められたものであるため、利用者の拡大とともに開発当時には想定されていなかった

悪意ある者による「なりすまし」、「盗聴」、「改ざん」等の脅威により、電子メールの

安全な利用が脅かさる状況になっています。

このような脅威の存在を理解頂いた上で、送受信する情報の取扱いを注意するほか、技術

面での根本的な対策として S/MIME 等の規格を利用して認証や暗号化を行うことにより、

安心して電子メールを利用出来ることを紹介しています。

本書は、制作を株式会社オレンジソフトに依頼し、制作の過程で有限責任中間法人 Mozilla

Japan の瀧田佐登子様、富士ゼロックス株式会社の稲田龍様のお二人に監修を御願いいた

しました。この場をお借りして、監修の謝意を申し上げます。

本書が、利用者の方々が安心してコンピュータを利用出来る環境づくりの一助になれば幸

いです。

2007 年 4 月

独立行政法人 情報処理推進機構 セキュリティセンター

（発行・公表）独立行政法人 情報処理推進機構

（制作）株式会社オレンジソフト