暗号化技術講義ノート

２０１０年１１月

株式会社サイバー創研

本資料は、独立行政法人情報処理推進機構（ IPA）「オープンソフトウェア利用促進事

業」の一環で、株式会社サイバー創研が受託し、実施した「第３回 OSS モデルカリキュラ

- 1 -

ム導入実証」の講義に基づき、株式会社サイバー創研が作成したものです。

- 2 -

暗号化技術

１．講義概要

　暗号化技術の講義は、以下のスケジュールで実施します。

　第 1 回　セキュリティ機能と暗号化の位置づけ

　第 2 回　暗号化の方式・共通鍵暗号方式

　第 3 回　暗号化の方式・公開鍵暗号方式

　第 4 回　情報システムにおける暗号化適用の方式

　第 5 回　電子証明書の仕組み

　第 6 回　認証と暗号化

　第 7 回　無線 LAN の暗号化

　第 8 回　OSS の活用シーンと暗号化

　第 9 回　IPsec による暗号化通信

　第 10 回　SSH によるトンネリング

　第 11 回　SSL プロトコルの仕組み

　第 12 回　VPN 通信の構築

　第 13 回　PKI(公開鍵暗号化基盤)の仕組み

　第 14 回　認証基盤構築実習

　第 15 回　暗号化・これからの活用シーンと課題

２．講義目標

オープンソースソフトウェア（OSS)アプリケーションのセキュリティ保持に必須の暗号

化技術について、実際の開発・運用の際に必要な管理知識・手法の種類と特徴、内容を理解

する。暗号化基盤として、実際にインターネット上で暗号化を担当する暗号化基盤の仕組み

を理解する。

暗号化の基本技術を理解する

暗号化の必要シーンと必要条件を理解する

オープンソースシステムを運用する際に必要となる暗号化セキュリティの知識を、

マシン実習を含めて習得し、安全な暗号化の仕組みを導入できる

公開鍵認証方式を用いた暗号化通信、及び VPN の設定ができる

上記の知識を、実業務に対応づけて活用できるようになる

- 3 -

第 1 回　セキュリティ機能と暗号化の位置づけ

OSS におけるセキュリティの基本概念と全体像を概説する。

1.　オープンソースソフトウェア（OSS）とは

　オープンソースとはソースコードが利用可能であることを意味している。オープンソース

ソフトウェアはソースコードを利用し、複製・修正して再配布することが可能である。さら

に配布されるソフトウェアは無料または有料にて提供される。仮にエンドユーザがソフトウ

ェアに変更を加えたとしたら、それらの変更を個人的なものとして保持しておくことも、将

来的にその変更がソフトウェアに反映されるようにコミュニティに還元することも選択可能

である。

　例で示すように、OS、デスクトップ、Internet、言語等沢山ある。

例）

・OS　　　 Linux（各種）

・デスクトップ

　電子メール ThunderBird　Web ブラウザ FireFox・Internet　Web サーバ Apache　電子メール sendmail/Postfix/qmail・言語

　　Java、PHP、Perl、Ruby　　

　　等・・・・・・・

1.1　OSS の定義

オープンソースとはソースコードが利用可能であることを意味している。オープンソース

ソフトウェアはソースコードを利用し、複製・修正して再配布することが可能である。さら

に配布されるソフトウェアは無料または有料にて提供される。仮にエンドユーザがソフトウ

ェアに変更を加えたとしたら、それらの変更を個人的なものとして保持しておくことも、将

来的にその変更がソフトウェアに反映されるようにコミュニティに還元することも選択可能

である。正確なオープンソースのライセンスは、オープンソース・イニシアティブ（ OSI）によって定義されている。OSI は法人化されていない非営利の研究・教育機関であり、オー

プンソースのトレードマーク定義・所有、およびオープンソースソフトウェアの推進を押し

進める役割を持つ団体である。OSI の定義によれば、以下の 9 つの項目が定義されている。

OSS の定義　ｂｙ：オープンソース・イニシアティブ（OSI）OSI, http://www.opensource.org/

- 4 -

1. 再頒布の自由

2. ソースコード

3. 派生ソフトウェア

4. 作者のソースコードの完全性 (integrity)5. 個人やグループに対する差別の禁止

6. 利用する分野(fields of endeavor)に対する差別の禁止

7. ライセンスの分配 (distribution)8. 特定製品でのみ有効なライセンスの禁止

9. 他のソフトウェアを制限するライセンスの禁止

2.　OSS のセキュリティリスクとは

　ソフトウェアのセキュリティ問題について言及する多くのサイトがインターネット上に

は存在する。これらはセキュリティに関する問題を取りまとめ、一般に公開している。これ

らの情報を参照すると、オープンソースソフトウェアを含めたソフトウェアのセキュリテ

ィが年々重要な問題となってきている。

　オープンソースソフトウェアのセキュリティ問題をソフトウェアに内在するリスクとし

て捉え、利用者側で積極的にこれらのリスクを把握・低減・管理していく必要がある。

IBM の HP：http://www.ibm.com/developerworks/jp/linux/では OSS のセキュリティ

リスクに対し、次のような見解を示している。

①ソースコードにアクセスできれば、ユーザがシステムのセキュリティを改善できるよ

うになる。

②限られたテストでは一部のケースしか指摘できないが、オープンソースのライフサイ

クルをもってすれば、悪意の無い欠点に対して、より脆弱さが少ないシステムを構築で

きる。

③3 つのオペレーティングシステムを数年間調査したところ、12 か月に渡ってパッチが

無い状態で既知の脆弱性をさらした日数が、2 つの商用システムよりも、残り 1 つのオ

ープンシステムの方が短かかった、という結果になった。

④行き詰まっているのはオープンではない商用システムの開発モデルの方である。シス

テムとは手間をかけて維持、サポートして行くことでより安全になるということ、手間

をかけないシステムは安全ではないが利益は上がる、という相反する問題であるからで

ある。

　OSS はソースコードが公開されている。コミュニティにより開発される長所・短所は次

のとおりである。

長所：

　・セキュリティに関する問題は、一般に公開されている

- 5 -

　・活発な開発がされている OSS では、セキュリティの問題へ　の対応は素早く行える

短所：

　・セキュリティの保証主体が明確ではない

　・十分なメンテナンスやサポートのない OSS にはセキュリティ脆弱性のリスクがある

→　開発者だけでなく、利用者にもセキュリティの評価・検討を行うことが求められる

2.1　脆弱性の種類

　ソフトウェアの脆弱性は、以下のように 8 つに分類される。

（１）バッファーオーバーフロー攻撃

　プログラムのメモリ領域を溢れさせて、不正なコードを実行させる攻撃

（２）フォーマット・ストリング・バグ攻撃

　 printf()関数などのフォーマット定義を悪用して、不正なコードを実行させる攻撃

（３）レースコンディション又はシンボリックリンク攻撃

　/tmp 等に不適切なアクセス権でファイルを作成するアプリケーションなどを利用し

て、パスワードファイルなど重要なファイルのアクセス権を奪取する攻撃

（４）ファイルパス名の悪用による攻撃

　ファイルのパス名に不正なコードを入力して、不正にファイル等にアクセスする攻撃

（５）リソースリーク

　リソースへのアクセス権が適切に設定できていないために、リソース情報を不正に入

手される攻撃

（６）アクセス権の不適切な設定をついた攻撃

　プログラムの設定などによってファイル等のアクセス権が不十分な部分をついて、不

正に情報を読み出す攻撃

（７）不適切な入力による攻撃

　不正な入力 CGI などを通じて、不正な入力を送り込み、不正にコマンド等を実行する

攻撃

（８）その他

　上記攻撃に分類できない攻撃

2.2　脆弱性とインシデントの関係

　インシデントと脆弱性との間には強い関係があることが示されている。脆弱性のライフサ

イクルモデルが定義されている。このモデルは脆弱性が検出されてから、広く公開されるま

でインシデントは徐々に増大し、パッチのリリース後緩やかにインシデントが減少していく。

脆弱性が改善されたとしても、インシデントが収まるまでには非常に長い期間を要する。1つの脆弱性が長い時間に渡って多くのインシデントを発生することがわかる。

- 6 -

3.　OSS に求められるセキュリティ機能とは

　OSS の利用におけるセキュリティの確保において最も重要なことは、オープンソースソ

フトウェアの問題点を自己の管理において把握し、対象のシステムに応じて適切に問題点を

把握し、低減の手段を講じていくことである。

第１段階：ソースコード検査

　OSS では商用ソフトウェアと違い、ソースコードを利用することができる。そのため、

利用者サイドでこのソースコードを利用して、ソフトウェアに含まれるバグや脆弱性のチェ

ックを行うことができる。この結果に従い、脆弱性の評価を行い、ソフトウェアのセキュリ

ティ上の問題点を把握する。

第 2 段階： 脆弱性対応

　ソースコードを検査し脆弱性を検出できたとしても、利用者側で検出された脆弱性を修正

することは困難である。把握された問題点に対して、ソースコードの修正無しに、脆弱性を

保護し、リスクを軽減するための技術的な方策が必要である。脆弱性を自動的に検出、保護

してくれる仕組みを導入することで、第一段階で認識した問題点を低減し、OSS のセキュ

リティを確保することが可能となる。これまではこの脆弱性への対応が主に叫ばれてきたが、

問題点の把握とあわせて本段階を実行することで、より適切な対策を講じることが可能とな

ると考えられる。

第 3 段階 運用管理

　上記の通り脆弱性を評価し、対応を行ったとしても、対処しきれない問題点は存在する。

対処できない問題点に関しては運用管理という方法でその問題点を管理していくことが必要

となる。OSS の運用は、自由度が高く、場合よっては利用者に運用作業の多くを強いるもの

もある。例えば、バグに関する情報などは利用者本人が自分で収集しなければならない場合

もある。いかに OSS の運用管理をしていかなければならないのかは、OSS を利用する上で、

避けて通れない問題である。

3.1　OSS の運用

　OSS では、利用者側でバージョンアップ情報を把握し、適切にソフトウェアのバージョ

ンを実施しなければならない。また、利用しているソフトウェアのセキュリティ問題など

は、利用者で積極的に情報を収集し、対応していく必要がある。OSS を情報インフラとして

利用していくためには、セキュリティを十分考慮した運用管理が必要になってくる。

セキュリティ管理者が自組織のみでオープンソースソフトウェア情報をコミュニティ、あ

るいはセキュリティ情報提供組織から収集し、その対応を行う。

　　(1) セキュリティ情報の収集

　　(2) セキュリティ情報への対応（パッチ適用等）

　　(3) インシデントへの対応

- 7 -

4.　暗号化の意義と課題

　OSS に限らず一般にセキュリティに対する脅威としては、情報の漏洩が起こる盗聴、情

報が書き換えられる改竄、送信者の偽装をされるなりすまし、後から当事者でないと宣言す

る否認、とが挙げられる。

　4.1 暗号化の処理形態

　暗号化する前のメッセージである平文を暗号化することで、意味のわからない暗号文にな

る。暗号文を復号化すると、元の平文に戻る。暗号化の手順を暗号アルゴリズムと呼び、暗

号アルゴリズムには鍵（キー）が必要となる。鍵は非常に大きな数列からなる。

　例は次のとおり。

送信者（アリス）は、メールを暗号化して受信者（ボブ）に送る。

ボブは、暗号化されたメールを復号してメールを読む。

メッセージを平文といい、メッセージの内容を隠すような形に変える処理を暗号化という 。

暗号化したメッセージを暗号文という。暗号文を元の平文に戻す処理を復号という。

　4.2　暗号化でどのような対応が可能か

　脅威に対する防衛のための暗号技術として特に重要な役割を持つものに、対称暗号（共通

鍵暗号）、公開鍵暗号、一方向ハッシュ関数、メッセージ認証コード、デジタル署名、擬似

乱数生成器が挙げられる。

　4.3　暗号化処理の種類

暗号化と復号の手順を暗号アルゴリズム(方式）といい、暗号化と復号時には、鍵を使用

する。

　4.4 暗号化の注意点と課題

暗号化に関して注意すべき点は次の通り。

秘密のアルゴリズムを使わずに、実績のある暗号を使った方が、結果的には高い強

度の暗号化につながる

弱い暗号により、利用者が機密性に対して過信し、危険性の意識を下げるのであれ

ば、暗号化の意味がない

絶対に解読されない現実的な暗号は存在しない

暗号化暗号はセキュリティのほんの一部にすぎず、結局利用者の意識が低ければ意

味をなさない

4.5　歴史上の暗号

太古からさまざまな方法で暗号が作られてきた。

- 8 -

　基本的には、ある文字を別の文字へ変換する「換字」と 2 つの文字の場所を入れ替える

「転置」を組み合わせて、より少ない計算機資源で効率よく安全な乱数表を擬似的に実現す

ることが必要となる。

　アルファベット順をずらした（つまり、換字を使った）だけのシーザー暗号から始まり、

第 2次世界大戦で使われたエニグマ暗号や紫暗号がある。

　安全な共通鍵暗号というのは、秘密鍵を知らなければ、擬似的に作られる乱数表を部分的

にせよ、作り出すことができないことを意味する。また、優れた共通鍵暗号は、そういった

安全な乱数表を、より少ない計算機能力でより高速に作り出せる計算方法ということになる。

・シーザー暗号（換字）

　平文で使われているアルファベットを、一定の文字数ずらすことで「暗号化」する。ずら

す文字数が鍵である。

　映画「2001 年宇宙の旅」での“HAL”コンピュータは？

　解読法は、全ての鍵の組み合わせを試みる

　　　ブルート・フォース・アタック、

　　　全数探索、総当たり法

・単一換暗号（転置）

　アルファベット 26文字に対して一対一の対応関係を作り、平文をその対応関係で別のア

ルファベットへ変換する。

　解読法は、文字の頻度分析を使用

5.　第 1 回のまとめ

オリエンテーション

講義の目的は、OSS のアプリケーションのセキュリティ保持の暗号化技術

OSS（オープンソースソフトウェア）とその定義

OSS のセキュリティリスクは、ソースが公開されている長所・短所、脆弱性

OSS に求められるセキュリティ機能は、利用者にもセキュリティ評価・検討、運用上の

対応が必要

暗号化の意義と課題、暗号化の処理形態、暗号化技術、暗号の歴史を概説

- 9 -

第２回　暗号化の方式・共通鍵暗号方式

共通鍵暗号（対称暗号）の基本概念と仕組み、特徴、利点と欠点、OSS における利用状況

について説明する。

1.　共通鍵暗号の基本概念

　共通鍵暗号方式とは、暗号化と復号に同じ鍵を用いる暗号方式のことを言う。秘密鍵暗号、

対称暗号とも呼ばれる。

2.　共通鍵暗号の動作原理

・平文と暗号文の関係を「第三者には一対一写像の乱数表で関係付ける」

・「換字」と「転置」組み合わせて効率良く安全な乱数表を擬似的に実現

・「換字」と「転置」組み合わせて効率良く安全な乱数表を擬似的に実現する暗号アルゴリ

ズム

3.　共通鍵暗号方式の特徴

十分に大きな鍵空間を持つ

アルゴリズムの脆弱性が発見されていない共通鍵暗号を用いると、平文の機密性を

維持することができる

高速な暗号・復号処理ができる

共通鍵暗号を利用した通信を行う場合、鍵を安全に共有する方法に問題が残る

4.　共通鍵暗号の種類

(1)　バーナム暗号(使い捨てパッド・ワンタイムパッド）

　メッセージ（平文）をランダムなビット列と XOR をとる

　絶対に解読できない暗号

(2)　ブロック暗号

　メッセージ（平文）を一定の長さのブロック単位ごとに換字や転置を行いながら暗号化処

理を行う

(3)　ストリーム暗号

　擬似乱数生成器から出力される鍵系列を利用して暗号処理をする

　4.1　バーナム暗号

（１）XOR（排他的論理和）演算

（２）1ビットの XOR　　0 XOR 0 = 0　⇒　0 　　 0 = 0　

　　0 XOR 1 = 1 ⇒ 0 1 = 1

- 10 -

　　1 XOR 0 = 1　⇒　1 0 = 1　　1 XOR 1 = 0 ⇒　1 1 = 0 (3) バーナム暗号の原理

　　暗号化する平分以上の長さの秘密鍵用意し、平文とビット対応に XOR演算する（秘密

鍵はランダムであること）。

暗号の「安全」性について、NTT　R&D　情報セキュリティシリーズ　「最新　暗号技

術」　NTT 情報プラットフォーム研究所　著　P.80　より

暗号における「安全」は、以下の観点で評価される。

・情報理論的に安全

無限の計算能力を仮定した場合でも、秘密鍵がなければ暗号の解読が不可能であること

を情報理論的に示せる　→　バーナム暗号

・計算量的／学術的に安全

理論上は、必ず暗号の解読ができるが、実現可能な有限の計算能力では解読が不可能で 、

暗号を利用する目的を安全に実現できる

・量子力学の原理に基づく安全

伝送中に盗聴行為が加わると、量子力学の不確定性原理により情報が変化することを根

拠として、盗聴されていないことを保証できる

・実装攻撃に対して安全

アルゴリズムとして安全で、かつ実装した暗号処理中において、外部観測によって得ら

れる暗号器の内部処理の動作情報を利用しても解読が不可能である

　4.2　ブロック暗号

　ブロック暗号は、秘密鍵から副鍵（拡大鍵ともいう）と呼ばれるデータを生成する「鍵生

成部」と実際にメッセージの暗号化を行う「データ撹拌部」で構成される。データ撹拌部で

は、メッセージを分割したブロックと生成した副鍵とで換字や転置を段間関数により複数段

繰り返し処理し暗号文を得る。段関数の設計と繰り返し回数が暗号化の速度と暗号の安全性

を決めるが、セキュリティパラメータとしては、秘密鍵の大きさを決める「鍵長」とメッセ

ージを分割するブロックの大きさを決める「ブロック長」がある。

共通鍵暗号、とりわけブロック暗号に対する解読法は 1990 年代に急速に進展し、それに伴

い暗号の設計法や安全性評価方法なども大きく変わった。このため、暗号解読に対する安全

性が大幅に向上しているうえ、処理速度もより高速になったため、今後の主軸暗号として、

国際的に 64bit ブロック暗号から 128bit ブロック暗号への移行が推奨されている。

- 11 -

　4.3　ストリーム暗号

　ストリーム暗号は、一般に秘密鍵を初期値として鍵系列を作り出す「擬似乱数生成器」と、

鍵系列とメッセージの「排他的論理和で暗号化する部分」とで構成される。

　ストリーム暗号の安全性及び処理性能は、擬似乱数生成器から出力される鍵系列とメッセ

ージとの排他的論理和によって暗号化されることから、擬似乱数生成器の安全性及び処理性

能そのものに大きく依存する。

　ストリーム暗号メッセージへの攻撃は、攻撃者が得た鍵系列から秘密鍵を求めるか、攻撃

者が得た鍵系列（過去の擬似乱数系列）から（秘密鍵を求めることなく）未知の鍵系列（将

来の擬似乱数系列）を予測するものである。

　ブロック暗号と同様に、鍵長は鍵全数探索攻撃に対する安全性を決めるパラメータで、十

分な耐性を待たせるために 128 bit 以上の鍵長を一般に使う。

　ストリーム暗号では、一組のメッセージと暗号文の組からその時利用した鍵系列を求める

ことができる。同じ秘密鍵からは同じ鍵系列が、擬似乱数生成器から出力されることとなる

ので、求めた鍵系列から別の暗号文の復号ができてしまう。このため、メッセージごとに秘

密鍵の更新が必要となる。

　4.4　暗号化の処理速度

共通鍵暗号と公開鍵暗号との比較では、一般に、同じ程度の機密性を持つ鍵長を選んだ場

合、公開鍵暗号は、共通鍵暗号よりも何百倍も遅くなるので長いメッセージの暗号化するの

には不向きである。目的に応じて、共通鍵と公開鍵暗号の両者を使い分ける。

共通鍵暗号でのストリーム暗号とブロック暗号との速度を比較すると、一般的には、スト

リーム暗号は、擬似乱数生成器のセットアップ性能に依存するが、ブロック暗号より高速で

ある。ブロック暗号の処理時間は、ブロック長単位での暗号化処理を行うためメッセージ長

に比例する。

最近は、ブロック暗号の速度が向上している。

　4.5　ブロック暗号とストリーム暗号の比較

ブロック暗号とストリーム暗号は、構成の違いで特性が異なる。

　4.6　共通鍵暗号の国際標準化

共通鍵暗号には、ブロック暗号とストリーム暗号がある。

ISO/IEC18033 で国際標準化されている共通鍵暗号の説明を行う。

5.　鍵交換の課題

　秘密鍵を安全に配送、もしくは安全に共有するため、共通鍵暗号で利用する秘密鍵を（セ

ッション鍵、一時鍵）を暗号化して配送する。技術的には、任意の情報を暗号化できるもの

- 12 -

の実際には「情報＝秘密鍵」として暗号化を行う方式と、もともと情報は暗号化はできずに

秘密鍵の配送・共有だけに限定されている方式とがある。

6.　AES (Advanced Encryption Standard)の概要

　米国では政府標準の共通鍵暗号が選定されている。これまで標準とされていた DES (Data Encryption Standard, 1977) に代わって、新しい標準となる AES （Advanced Encryption Standard）が 2000 年に選定された。AES では複数候補の中から Rijndael（ラインダール）という暗号アルゴリズムが採用されている。

　AES の暗号強度は、現在のところRijndael に対する有効な攻撃は見つかっていない。

AES (Advanced Encryption Standard)暗号

NIST が全世界に公募し約 5 年間、安全性と処理性能を評価

Daemen と Rijmen（ベルギー）が提案した Rijndael アルゴリズム

米国政府標準暗号(FIPS197)　2001 年登録

鍵長　　128/192/256ビット

構造　　SPN 構造

適用領域　ソフトウェア、IC カード、高速ハードウェア

技術的論点

　　　安全性がほぼ正確に見積もられている

　　・　10段中 7段まで(128ビット鍵)　　・　14段中 9段まで(256ビット鍵)

SPN 構造

　128ビットの 16 バイトを 1 バイトごとに ByteSub 処理その値をインデックスとして、

256 個の値を持っている換字表（副鍵）から 1 個の値を得る。

7.　OSSへの実装状況

OSSへの暗号の実装は、SSL プロトコル・TLS プロトコルの OSS 実装である OpenSSLがある。

中心となっているライブラリ（C 言語で書かれている）は基本的な暗号化関数と

様々なユーティリティ関数を実装している

OpenSSL が利用可能なプラットフォームは、ほぼ全ての Unix 系（Solaris やLinux、Mac OS X、BSD を含む）、OpenVMS、そして Microsoft Windows であ

る

OpenSSL は以下の暗号化アルゴリズムをサポートする

　　暗号方式 （共通鍵暗号）

　　Blowfish、Camellia、DES、RC2、RC4、RC5、SEED、IDEA、AES

- 13 -

SSH プロトコルの OSS 実装である OpenSSH がある。

SSH サーバおよび SSH クライアントを含む

BSD ライセンスで公開

8.　まとめ

共通鍵暗号の基本概念

　　　暗号化と復号化に同じ鍵を用いる暗号方式

共通鍵暗号の種類

　　　バーナム暗号、ブロック暗号、ストリーム暗号

暗号化の処理速度・安全性

共通鍵暗号の国際標準化

鍵交換の課題

　　　鍵（秘密鍵）を安全に共有する（配送する）方法

AES の概要

OSSへの実装状況

OpenSSL、OpenSSH

- 14 -

第 3 回　暗号化の方式・公開鍵暗号方式

公開鍵暗号（非対称暗号）の基本概念と仕組み、特徴、利点と欠点、OSS における利用状

況について説明する。

　インターネット利用時の暗号化方式として公開鍵暗号方式がなぜ重要なのか議論する。

1.　公開鍵暗号とは

公開鍵暗号方式とは、公開鍵で暗号化し、プライベート鍵（秘密鍵）で復号する暗号方式

のことをいう。

非対称暗号とも呼ばれる。

2.　公開鍵暗号方式の特徴

公開鍵暗号は、暗号化鍵（公開鍵）と復号鍵（秘密鍵）は異なる鍵を用いる。

暗号化鍵からは、復号鍵を求めることが計算量的に困難である暗号化鍵を公開する。

公開鍵暗号で利用する数学的未解決問題についても説明する。

　2.1　RSA による暗号

RSA（Rivest-Shamir-Adleman）暗号は素因数分解問題で大きな数の素因数分解が

難しいという数学的問題を安全性の根拠として構成

RSA による暗号化

　　暗号文＝平文 E mod N (平文を E乗して N で割った余り)- E と N の組が公開鍵

- N = p × q (p、q は素数）

- 1 < E < L　で　gcd(E, L) = 1　E と L との最大公倍数は１(互いに素数）

　　ここで　L = lcm(p-1, q-1) (L は p-1 と q-1 の最小公倍数）

RSA による復号

　　平文＝暗号文D mod N (暗号文を D乗して N で割った余り)- D と N の組がプライベート鍵

- D と E と L の関係は、　　1 < D < L、 　E × D mod L = 1　2.2　他の公開鍵暗号

ElGamal 方式

- mod N で離散対数を求める困難性を利用

- 暗号文が平文の 2倍になる欠点

- 暗号ソフトウェア　GnuPG　に実装

楕円曲線暗号方式

- 楕円曲線上での離散対数を求める困難性を利用

- RSA 方式に比べて短い鍵長で同等の安全性が実現

- 15 -

- PSEC（ Provably Secure Elliptic Curve encryption）

- ECDSA（Elliptic Curve Digital Signature Algorithm）

Rabin 方式

- mod N で平方根を求める困難性を利用

- 素因数分解を行うだけの困難さ

3.　公開鍵暗号方式の暗号化の動作仕様

公開鍵暗号方式では以下の手順でメッセージが送信される。送信者を Alice 、受信者を

Bob とする。

（Bob） 鍵ペア（公開鍵とプライベート鍵）の作成

（Bob） 公開鍵を暗号化に利用してもらうために Alice に送付（Alice） Bob の公開鍵を使って、メッセージを暗号化

（Alice） 暗号文を Bob に送付（Bob） プライベート鍵で暗号文を復号

4.　公開鍵暗号方式の利点／欠点

公開鍵暗号方式の利点は、公開鍵暗号を使う場合、復号のための鍵を受信者に送る必要が

なくなり、共通鍵暗号を利用する際に起こる鍵共有の問題を回避できる。

公開鍵暗号の問題は、公開鍵が本当に正しいかわからないという認証である。また、共通

鍵暗号より数百倍遅いという処理速度である。

　安全性については、RSA 方式の現状は、鍵長 1,024bit 以上が一般的である。安全性を向

上させるために鍵長 2,048bit 以上が推奨されている。また、楕円曲線暗号では、224ビッ

ト以上が推奨されている。

5.　デジタル署名とは

デジタル署名は、印鑑の捺印に相当する手法であり、改竄やなりすまし、否認の検出がで

きる。メッセージの受信者はデジタル署名を検証することで改竄やなりすまし、否認の検出

ができる。

改竄とは、誰か悪意のあるものによってメッセージ内容が書き換えられることである。

なりすましとは、誰か悪意のあるものによってメッセージの送信者が書き換えられること

である。

否認とは、送信者がメッセージの内容や存在を否定することである。

5.1　デジタル署名とメッセージ認証コード

　デジタル署名とは、書面上の手書き署名のセキュリティ特性を模倣するために用いられる

公開鍵暗号の一種である。デジタル署名は通常 3 つのアルゴリズムからなる。一つは公開鍵

- 16 -

ペアを生成する鍵生成アルゴリズム。もう一つは、利用者の秘密鍵を用いて署名を生成する

アルゴリズム、それと利用者の公開鍵を用いて署名を検証するアルゴリズムである。署名生

成処理で作り出されたデータも"デジタル署名"と呼ぶ。デジタル署名は"メッセージ"の認証

機能を提供する。メッセージは、電子メール、契約書、あるいはより複雑な暗号プロトコル

で送受されるデータでも何でも良い。

　認証行為は認証対象よって分類され、認証対象が人間である場合には相手認証（本人認

証）、メッセージである場合にはメッセージ認証、時刻の場合には時刻認証と呼ぶ。単に認

証と言った場合には相手認証を指す場合が多い。

・相手認証とはある人が他の人に自分が確かに本人であると納得させることをいう。 A氏が B氏に自分が本当に A であることを証明するとき、B は A を認証すると言い、A を被認証

者、B を認証者と呼ぶ。 被認証者、認証者のことを証明者(prover)、検証者(verifier)とも

呼ぶ（A が本当に A であることを「証明」し、その証明が正しいかどうかを B が「検証」す

るので）。

相手 認 証 は そ の 方 法 に よ っ て Certification （ サ ー テ ィ フ ィ ケ ー シ ョ ン ） と

Authentication（オーセンティケーション）とに分類される。

・Certification は被認証者が認証場所に直接アクセスして行う認証の事

・Authentication は被認証者が認証場所に直接アクセスすること無く遠隔地から電子的

に受ける認証のことである。

6.　デジタル署名の仕組み

デジタル署名は公開鍵暗号を逆に使うことで実現される。メッセージをプライベート鍵で

暗号化することが署名に相当し、公開鍵で復号することが、署名の検証に相当する。プライ

ベート鍵で暗号化した暗号文は、対応する公開鍵でのみ正しく復号できる(プライベート鍵

による暗号化）。

　6.1　メッセージに直接署名する方法

　アリスがメッセージに署名して、ボブが署名を検証する。

　6.2　メッセージのハッシュ値に署名する方法

　アリスがメッセージのハッシュ値に署名して、ボブが署名を検証する。

7.　OSSへの実装状況

SSL プロトコル・TLS プロトコルの OSS 実装は、OpenSSL が提供している。OpenSSLは以下の暗号化アルゴリズムをサポートする。

・公開鍵暗号方式

RSA 暗号、DSA、Diffie-Hellman 鍵共有

- 17 -

・ハッシュ関数方式

MD5、MD2、SHA、MDC-2

SSH プロトコルの OSS 実装は、OpenSSH が以下の機能を提供している。

・rlogin と telenet の通信暗号化（rcp､ftp も含む）

・共通鍵暗号の共通鍵の暗号化

・パスワード認証、公開鍵認証、ワンタイムパスワード

8.　インターネットでの公開鍵暗号方式の重要性と利用

（１）インターネットでの暗号化の条件

インターネットにおいては、盗聴やなりすましなどが問題となる。共通鍵暗号方式の際に

は鍵を事前に共有する際に盗聴のリスクが非常に大きかった。

（２）公開鍵暗号方式の利点

公開鍵を用いることで、鍵の盗聴リスクを回避できる利点がある。

（３）暗号化の現状

公開鍵で鍵共有の問題を解決し、共通鍵の高速な暗号通信を用いるハイブリッド方式が利

用される。

　8.1　公開鍵暗号への攻撃

（１）暗号文から平文を求める（RSA 暗号）

ブルート・フォース・アタック

プライベート鍵の候補となる数(D)を順番に試し、復号する

公開鍵を素因数分解し、素数の組（p、q）を求める

（２）Man-in-the-middle攻撃 能動的攻撃者(マロリー) 送信者(アリス)に対しては受信者(ボブ)のようにふるまう

受信者(ボブ)に対しては送信者(アリス)のようにふるまう

　8.2　ハイブリッド暗号方式

　メッセージを暗号化に使用した共通鍵(セション鍵)を公開鍵で暗号化して送信する。

９.　まとめ

公開鍵暗号の基本概念

　暗号化と復号に異なる鍵を用いる暗号方式

公開鍵暗号の種類

　RSA 暗号、 ElGamal 方式、楕円曲線暗号、Rabin 方式

- 18 -

公開鍵暗号方式の利点・欠点

デジタル署名

メッセージに署名、ハッシュ値に署名

インターネットでの公開鍵暗号方式の重要性と利用

ハイブリッド方式（鍵を安全に共有する方法）

OSSへの実装状況

OpenSSL、OpenSSH

- 19 -

第 4 回　情報システムにおける暗号化適用の方式

実際の情報システムにおいて、暗号化がどのようなところで活用されているか、その目的

と特徴、実装方法を理解する。

1.　情報システムに対する暗号化の適用

OSやミドルウェア、アプリケーションで暗号化処理を実装している。

・ハードウェアレベルでの暗号化

・ネットワークにおける暗号化

2.　ソフトウェア情報の暗号化

業務で使われるソフトウェアは機密情報やプライバシーにかかわる情報を扱うことが多い

情報漏洩を防ぎ、信頼性を維持するためにソフトウェア情報の暗号化は重要である。OS、

データベース、および機密データを扱うアプリケーションのそれぞれにデータを暗号化して

処理する枠組みが用意されている。

OSS で配布されるソフトウェアの信憑性は、公開鍵を使用する暗号シグネチャでスクリ

プト検証する。

データベースに対してファイルやファイルフォルダの暗号化する。

暗号化アプリケーションやライブラリで暗号化する。

データの暗号化やメールの暗号化に適用

PGP( Pretty Good Privacy) :OpenPGP(RFV4880)、GnuPG Open-SSL Open-SSH

　2.1　コンテンツの暗号化

コンテンツ暗号化の目的は、情報漏洩を防ぎ、信頼性を維持するためである。また、コン

テンツの著作権の保護も行う。

暗号化の対象コンテンツとしては、機密情報、プライバシーにかかわる情報、著作権が保

護されるコンテンツ、映画、楽曲、デジタル書籍、ソフトウェアが有る。

暗号化方法の適用方法としは、機密性が高いコンテンツに対しては、共通鍵暗号 (ブロッ

ク暗号）が、情報量が多いコンテンツに対しては、共通鍵暗号 (ストリーム暗号）が一般的

に使用される。

　2.2　データの暗号化

（１）SSH（セキュアシェル）

クライアント/サーバ方式間に透過的な暗号経路を提供する。コンピュータからネットワ

ークに流れるデータを自動的に暗号化し、宛先に届いたデータを自動的に復号する。以下の

- 20 -

用途に使用される。

セキュアなリモートログイン

セキュアなファイル転送

セキュアなリモートマシンでのコマンド実行

公開鍵による認証

アクセス制御、ポート転送

（２）OpenSSL暗号・PKI・SSL/TLS ライブラリである。以下の用途に使用される。

EVP API を利用した暗号化、復号

Web サーバの Apache での SSL使用

　2.3　メールの暗号化

（１）PGP 共通鍵暗号による暗号化と復号（ハイブリッド暗号）

公開鍵暗号方式、公開鍵基盤を使用しない

デジタル証明、一方向性ハッシュ、証明書、データ圧縮

Mozilla Thunderbirad による電子メールの暗号化

（２）S/MIME(Secure Multipurpose Internet Mail Exchange) 公開鍵暗号方式、公開鍵基盤(PKI:Public Key Infrastructure)発行の電子証明書を使

用し、信頼性を確立

OpenSSL の smime コマンド

（３）SSL による IMAP と POP の暗号化

POPや IMAP のパスワードに加えて、SSL で暗号化

（４）Sendmail を使った TLS による SMTP の暗号化

転送中の電子メールを暗号化

3.　通信路の暗号化

通信の安全性・機密性を高めるための暗号化する。ネットワークレベルの暗号化には

IPsec、SSL/TLS などの選択肢がある。

ネットワーク暗号化では以下の利点／欠点を考慮する。

通信路の機密性は保たれる

処理コストがかかるため、ネットワーク性能のボトルネックになることもある

　3.1　VPN 方式

　VPN 方式は、公衆ネットワーク上に暗号化技術を用いて仮想ネットワークを作る。

- 21 -

　3.2　IPsec 方式の概要

　IPsec には、以下の 2 種類ある。

トランスポートモード（送信側でデータを暗号化し、IPヘッダ付加し転送）

トンネルモード（IPsecＧＷで IPヘッダも含め暗号化し、ヘッダを付加し転送）

4.　デバイスレベルでの暗号化

ソフトウェアのみで情報が改竄されないことを担保するのは、原理的にも実際的にも困難

である。主記憶、ハードディスク、外部記憶媒体といったハードウェアにおける暗号化も行

われる。

ハードウェア回路を使った暗号の例

SSL アクセレータ

暗号化モジュール

CMVP( Cryptographic Module Validation Program )認証制度

FISP140-2　　物理的セキュリティ、操作環境、暗号鍵管理、電磁障害・干渉、セルフテスト

USB メモリの暗号化ハードウェア

IC カード

Clipperチップ

Intel　Westmere プロセッサでの AES データ暗号化／復号化命令セット

　4.1　ハードディスク、外部記憶媒体の暗号化

ハードディスクや外部記憶媒体に送られてきたデータをすべて暗号化して書き込む技術も

商品化されている。暗号化処理は、ハードウェア回路を使って実行している。

（１）暗号化ハードディスクドライブ（商品：シーゲイト、日立 GST）

専用の暗号化チップを搭載していて、暗号化処理がシステムのパフォーマンスには影響を

与えない。セキュリティ機能の強化、ディスクのあらゆるデータの保護を可能とする。

（２）媒体認証と暗号化

　パッケージの著作権保護のために媒体認証と暗号化が適用される。

DVD-Video ：CSS ( Content Scramble System) BD ：AACS (Advanced Access Content System) DVD-R/RAM/RW 、 SD カ ー ド ： CPRM (Content Protection for Recordable

Media)

　4.2　ハードウェア暗号化の利点／欠点

ハードウェア暗号化による暗号化処理は、高速、高信頼に実行できる利点がある。反面、

暗号化回路が必要となり比較的高価になる、暗号化回路の信頼性を確保しなければならない

- 22 -

という欠点がある。

5.　まとめ

情報システムに対する暗号化の適用

OSやミドルウェア、アプリケーション、ハードウェアでの暗号化処理

ソフトウェア情報の暗号化

コンテンツ暗号化、データ暗号化、メール暗号化

OSS の適用

通信路の暗号化

IPsec、SSL/TLSIPsec の概要

デバイスレベルでの暗号化

ハードディスク、外部記憶媒体の暗号化

ハードウェア暗号化の利点／欠点

- 23 -

第 5 回　認証の仕組みと OSS（1）電子証明書の仕組み

　インターネットビジネスに必須のセキュリティ機能である電子証明書の仕様、仕組み、役

割、必然性、利点などを理解する。

1.　電子証明書とは

電子証明書は暗号通信の際に使われる公開鍵が正しいものであることを証明するものであ

る。公開鍵暗号方式を使用する際には、第三者が通信相手になりすまして公開鍵を送信する

可能性がある（公開鍵配布時のなりすまし）。

　1.1　公開鍵の認証モデル

　認証モデルには以下の 2 種類がある。

PGP モデル：公開鍵の所有者を信頼できる人物に保証してもらう方法

認証局モデル：信頼できる第三者機関 に公開鍵の所有者を保証してもらう方法

1.2　認証局モデルにおける公開鍵の交換方法

　認証局(CA)が発行した公開鍵証明書で公開鍵を交換する。

2.　電子証明書の仕様

　電子証明書は、サーバ証明(VPN, Web)、クライアント証明、メール証明、ソフトウェア

証明などに使用される。証明書の標準規格としては X.509 が存在しており、多くのアプリ

ケーションでサポートされている。X.509 は公開鍵のバージョン番号、証明書のシリアル

番号、公開鍵情報、証明書を発行した認証局情報、証明書の有効期間、証明される主体者の

情報、拡張領域といった項目で構成される。

　2.1　X.509 電子証明書

証明書（公開鍵証明書）の国際標準として、ITU-T が策定した、X.509 がある。IETF では、

(RFC2459、RFC3280)が相当する。

X.509 証明書のフォーマット表記方法は、ASN.1 を使用している。

識別子：値に含まれるデータの種別（データ型）

データ長：値に含まれるデータの長さ

値：データの内容

証明書の所有者や CA の名前を、DN (Distinguished Name) とよばれる形式で表現する。

国(c)、組織(o)、組織単位(ou)、名前(cn)

- 24 -

　2.2　電子証明書の種類

公開鍵証明書(Public Key Certificate)は、公開鍵とその所有者を証明する。

CA 証明書は、CA に対して発行する証明書で、CA 自身の秘密鍵で署名した自己署名証明

書と、他の CA に発行された証明書がある。

エンドエンティティ証明書は、PKI ユーザに対して発行する証明書で、Web クライアン

トやWeb サーバ、VPN ルータなどに利用する。

属性証明書(Attribute Certificate)は、公開鍵証明書で証明された人に対して権限や役割

を証明するもので、公開鍵証明書と組み合わせて使用する。

特定証明書(Qualified Certificate)は、人（自然人）に対して発行することを目的とした

証明書で、電子署名に使用する。

　2.3　X.509 証明書のプロファイル

X.509 証明書は、以下の構造である。

（１）証明書 (Certificate) の構造

署名前証明書 (tbsCertificate)- 証明書の所有者

- 公開鍵

- 有効期間

署名アルゴリズム (signatureAlgorithm) 署名値(signatureValue) - 署名前証明書 (tbsCertificate) に対する CA のデジタル署名

（２）証明書を Internet Explorer にて表示した例

証明書のシリアル番号、発行者名などが表示されている。

　2.4　公開鍵使用目的の種類

　鍵使用目的(keyUsage)で指定される公開鍵の用途が規定されている。

4.　証明書発行に関わる当事者と発行までの流れ

　公開鍵基盤(PKI: Public-Key Infrastructure)

　4.1　証明書発行に関わる当事者

PKI を構成する主な要素を以下に示す。

（１）認証局 (CA： Certification Authority)証明書所有者(Certificate Holder)に証明書を発行

（２）登録局 (RA： Registration Authority)発行権限の分散管理を可能にして運用コストを削減

- 25 -

（３）リポジトリ (Repository)証明書および CRL を格納し、PKI ユーザへ公開

（４）アーカイブ (Archive)証明書の長期保存や秘密鍵をバックアップ

（５）証明書所有者 （Certificate Holder）証明書を発行される人（エンティティ）

（６）証明書利用者 （Relying Party）

証明書を入手し、デジタル署名の検証や文書の暗号化を行う

　4.2　発行までの手順

①証明書申請者は、登録局(RA)経由で認証局(CA)に公開鍵を提出し証明書の登録を申請

②認証局は、証明書申請者の本人性を確認して公開鍵を発行

③認証局は、証明書利用者の公開鍵に認証局のデジタル署名を付けたものを証明書とし

てリポジトリに保存

④登録局(RA)は、秘密鍵、公開鍵証明書をアーカイブにバックアップ

⑤証明書利用者は、リポジトリから証明書をダウンロードし利用

5.　CA 局による電子証明書発行、暗号化通信

ベリサインの無料お試しサービスの演習

https://www.verisign.co.jp/personal/trial/(1)　証明書の作成

名前：　　　　： First Name、Last Name メールアドレス：　Your E-mail Address パスフレーズ　：　　Challenge Phrase 製品版／試用版の選択

(2)　電子メールを確認

(3)　デジタル ID を取得

(4)　証明書をインストール

(5)　デジタル ID を確認

(6)　メールソフトに証明書を設定

５．まとめ

電子証明書は暗号通信の際に使われる公開鍵が正しいものであることを証明するもの

証明書の標準規格としては X.509 が存在しており、多くのアプリケーションでサポー

ト

- 証明書の種類と用途

- 26 -

- 証明書の構造、プロファイル

- 公開鍵使用目的

証明書発行の際には認証局を利用

- 公開鍵基盤（PKI)と要素

- 証明書発行までの一連の流れ

- 27 -

第 6 回　認証と暗号化

ネットワークにおける認証の実現方式と暗号化の役割、必然性、利点などを理解する。

1.　認証とは

ネットワーク利用においてユーザや文書の正当性を証明する「認証」の基本的な仕組みと

実現方式として、認証を実現するうえで暗号化をどう利用しているか、その具体的な方法を

説明する。

　1.1　なりすましのリスク

なりすましは、他人のユーザ ID などを盗用してネットワーク上で活動し、機密情報の流

出や、濡れ衣を着せられるなどのリスクがある。

（１）スプーフィング(Spoofing) 他人のユーザ IDやパスワードの盗用し不正アクセス

他人の名前やメールアドレスを使用しなりすましメール

発信元 IP アドレスを偽装したパケットを相手サーバに送り付ける

（２）フィッシング (phishing)金融機関などからの正規のメールやWeb サイトを装い、暗証番号やクレジットカード番

号などを詐取する詐欺する。

（３）Man-in-the-middle攻撃送信者と受信者の間に入りこみ両者を偽装する。

　1.2　認証の仕組み

　認証には、エンティティ認証とメッセージ認証の 2 種類がある。

（１）エンティティ認証

通信相手が意図した正しい通信相手であることを確認する。 ISO/IEC による規格化（ISO/IEC 9798、JIS X 5056、IETF)されている。

共通鍵暗号アルゴリズムに基づく方式(9798 ｰ 2) 電子署名に基づく方式(9798 ｰ 3) ゼロ知識証明を用いた方式(9798 ｰ 4) 手動データ転送を用いた方式(9798 ｰ 5) SASL（Simple Authentication and Security Layer） (IETF RFC4422) Kerberos(IETF RFC4120、RFC4121)その他、One-time Password がある。

　認証されるユーザが正規の秘密鍵(秘密情報）を所有していることを検証することで、権

限を有するユーザであることを確認する。

チャレンジ・アンド・レスポンス(ブロック暗号）

- 28 -

デジタル署名（公開鍵暗号）

システムにログインする際のアカウント ID の認証方法として以下のものがある。

パスワード認証

共通鍵暗号を用いた認証

公開鍵暗号を用いた認証

公開鍵証明書を用いた認証

（２）メッセージ認証

メッセージが送信時のまま届いたかを確認する。

メッセージ認証コード MAC （Message Authentication Code）

メッセージ完全性符号 MIC （Message Integrity Code）

チェックサム

　一方向メッセージダイジェスト（ハッシュ）関数である MD5、SHA などを用いて、メッ

セージ送受信の前後のメッセージダイジェスト（ハッシュ値）を比較する。メッセージダイ

ジェストの変化の有無によりメッセージ改竄の有無を判定する

　1.3　暗号化による認証の仕様

一方向メッセージダイジェスト（ハッシュ）関数は、任意長のメッセージに対して一定長

のハッシュ値を作る関数であり、MD5、SHA系がある。

（１）ハッシュ関数に求められる性質

①一方向性(Onewayness)　求めるハッシュ値になるような元のメッセージを求めることが困難であること

②第 2原像計算困難性(Second preimage resistance) 　同じハッシュ値となるような元のメッセージ（第 1原像）とは異なる別のメッセージ（第

2原像）を求めることが困難であること

③衝突困難性(Collision-free Collison resistance) 　同じハッシュ値となるような、2 つの異なるメッセージを求めることが困難であること

（２）ハッシュ関数の基本構造

MD/SHA　ハッシュ関数での基本構造は、メッセージ拡張関数と圧縮関数（撹拌関数の集

合）で構成される。

（３）MD5、SHA について

MD5（Message Digest Algorithm 5)は、入力に対して 128ビットのハッシュ値を出力

するハッシュ関数である。Linux では md5sum、FreeBSD では md5 というコマンドを用

意されている。電子署名を必要とするアプリケーション向けで、ファイル配布時にそのファ

イルの MD5ハッシュ値（いわゆる MD5チェックサム）も同時に配布等に使用されている。

- 29 -

しかし、理論的な弱点が存在として、APOP の脆弱性が指摘されている。

SHA(Secure Hash Algorithm)米国政府標準ハッシュ関数は、NIST(National Institute of Standards and Technology)で開発されている。SHA-1 は 160 ビットのメッセージダ

イジェストを持つが、衝突困難性が満たされていないとして、SHA-1 から SHA-2への移行

計画(2010 年) が進められている。SHA-2 は、SHA-256、SHA-384、SHA-512 がある。ま

た、NIST は、次世代ハッシュ関数 SHA-3 を公募し、選定中である。

1.4　ダイジェストとは

　メッセージから一方向ハッシュ関数を用いて一意に求まる値をメッセージダイジェストと

呼ぶ。メッセージダイジェストはメッセージの同一性の確認に利用できる。メッセージダイ

ジェストの値は常に固定サイズである。メッセージダイジェストがデジタル署名対象となる。

2.　メッセージダイジェストによる認証／改ざん防止機能

メッセージダイジェストの機能と効果は、認証／改ざん防止に公開鍵暗号方式を適用され

ており、次の特徴がある。

公開鍵暗号方式での暗号化・復号は処理速度がかかる

メッセージをハッシュ関数で圧縮化することで処理量削減できる

プライベート鍵でメッセージダイジェストを暗号化し、プライベート鍵所有者の公

開鍵で復号できれば公開鍵の所有者のエンティティ認証が可能となる

受信したメッセージのメッセージダイジェストと復号した、公開鍵で復号したメッ

セージダイジェストを比較することでメッセージ認証が可能となる

メッセージダイジェストプロトコルは、改ざんの検出やパスワード認証への適用に適用さ

れ、HMAC (Keyed-Hashing for Message Authentication)、デジタル署名がある。

　2.1　メッセージダイジェストの機能と効果

メッセージダイジェストを公開鍵で暗号化するので、処理量が少ない。

　2.2　メッセージダイジェストプロトコル

一方向ハッシュ関数によるメッセージダイジェストは、以下の用途がある。

（１）改ざんの検出

ハッシュ関数は、元ファイルのダイジェストを保存しておくことで、そのファイルに変更

が加えられたか否かを確認できる。データ量が節約でき、さらに改ざんの検出も容易になる。

（２）パスワード認証への適用

パスワードのダイジェストをサーバ上に保存し、認証時にはユーザが投入したパスワード

のダイジェストと比較、パスワード漏洩の危険性を回避できる。

（３）HMAC (Keyed-Hashing for Message Authentication)

- 30 -

共通鍵暗号方式とセキュアハッシュ関数を組み合わせて、メッセージの完全性を保証する

（RFC2104)。（４）デジタル署名

公開鍵暗号方式とセキュアハッシュ関数を組み合わせて、メッセージの完全性と送信者の

認証を実現する。

3.　メッセージ認証で確認されること

メッセージ認証での共通鍵暗号とデジタル署名の適用については、以下の事項を確認し

YES が多ければ共通鍵暗号を採用する。

検証者が被検証者の秘密鍵を保持していても問題無いか

認証時点で、検証者が被検証者やメッセージの完全性を確認できれば十分か

認証後に紛争が発生した場合、認証時の通信データそのものでなく、アクセスログ

など別の情報をだけで認証の事実・正当性を第三者に納得してもらえるか

高速な認証である必要があるか

実サービス運用上、秘密鍵の漏えいリスクを低いと判断してよいシステムか

4.　まとめ

認証とは

なりすましのリスク

認証の仕組み

暗号化による認証の仕様

ダイジェストとは

メッセージダイジェストによる認証／改ざん防止機能

メッセージダイジェストの機能と効果

メッセージダイジェストプロトコル

メッセージ認証で確認されること

- 31 -

第 7 回　無線 LAN の暗号化

無線 LAN における暗号化の仕様、必然性、利点/欠点、運用仕様などを理解する。

1.　無線 LAN のセキュリティ

無線 LAN はオフィスや家庭などでその利便性から広範に利用される。標準化が進み接続

性が向上しており、市販 PC での無線 LAN インタフェースの標準搭載されるようになった。

LAN の配線不要でロケーションフリーな作業環境が実現でき、公衆 LAN サービスの普及し

ている。

しかし、無線 LAN には以下の危険性がある。

通信路上に流れるデータの盗聴

通信システムへ侵入しシステム内の機密情報を盗む

通信サービスの妨害

無線 LAN の安易な設定でのリスク、無線 LAN のセキュリティ対策の理解、WEP 暗号化の

弱点が原因である。

　1.1　無線 LAN の概要

無線 LAN は、免許の不要な周波数帯（2.4GHz、5GHz）の電波を使用して通信を行う。

（１）通信モード

無線 LAN には、以下の 2 種類の通信モードがあるが、アクセスポイント（ルータやブリ

ッジ機能をもつ）経由の通信ではインフラストラクチャ・モードを使用する。

インフラストラクチャ・モード：パソコンがアクセスポイント経由で通信

アドホック・モード：パソコン同士が直接、データを転送しあう。

（２）無線によるパソコン間の通信

パソコンどうしは、アクセスポイントを介して無線で通信を行う。アクセスポイントと同

時に通信できるコンピュータは、1台（同じ周波数の電波を使用するため）であり、同時に

アクセスするパソコンが多いほど、速度が低下する。

（３）無線 LAN 種別

世界の無線 LAN は、IEEE802.11 仕様で一本化されている。

無線 LAN の標準化は、IEEE802.11委員会が中心となり進められ、世界の無線 LAN は、

IEEE802.11 仕様（物理レイヤに相当する IEEE802.11b、a および g）に一本化されている。

更に MIMO 技術を使い 100Mbps を超える伝送速度の IEEE802.11n が標準化された。通

信距離は、それぞれ数 10m あるとされている。

2.4GHz帯域無線 LAN(IEEE802.11b/g)は、ISM バンドを使用しているので電子レンジや

Bluetooth 等と同一の周波数を使用しており周囲の機器からの干渉が大きくまた、チャネル

数は 14 あるが重ならない条件であると 4チャネルとなる。

5GHz帯域無線 LAN(IEEE802.11a)は、遮蔽物での電波減衰が多いが、気象レーダとの干

- 32 -

渉を避けるための動的周波数選択機能（DFS）および送信電力制御機能（TPC）を備えてい

る。室内限定利用でチャネル数は 5.2GHz と 5.3GHz の 2 つの帯域合わせて 8チャネル、

5.6 GHz帯域は屋内外利用で 11チャネルとなっている（2005 年 5 月総務省令改正）。

　1.2　無線 LAN におけるセキュリティの脅威

無線 LAN 導入するに当たって、無線 LAN を適切に利用しないと発生する脅威として、

「通信内容の傍受（盗聴）」、「無線 LAN の不正利用」、「無線 LAN アクセスポイントの

なりすまし」がある。

（１）通信内容の傍受（盗聴）

　無線 LAN でやりとりされるデータは、電波を利用して送受信される。そのため無線 LAN のセキュリティ技術を適切に利用しないと正規の利用者の目の届かない所で容易にデータを

傍受することが可能となり、通信内容が傍受され通信が盗み見られる可能性がある。

　最近では、WEP 方式で暗号化していても 1分程度で 128bit（104bit）の WEP キーが解

析されてしまう。現在では、WPA 方式が推奨されている。

（２）無線 LAN の不正利用（不正アクセス）

　セキュリティ設定を行わない無線 LAN アクセスポイントは、利用可能範囲にあるどんな

パソコンからの接続も許可する。このことは、無線 LAN を用いて他の人が通信を行うこと

も可能であることを意味する。Windows ではワイヤレスネットワーク接続でネットワーク

の 一 覧 を 表 示 で き る 。 ま た 、 フ リ ー ソ フ ト の NetStumbler （ http://www.netstumber.com/）は、周囲にあるアクセス ポイントを探索し、･ ESS-ID、チャネル、

MAC アドレス、無線 LAN の規格などを表示できる。

（３）無線 LAN アクセスポイントのなりすまし（不正無線アクセスポイント）

　従来の無線 LAN 端末は、接続先の無線 LAN アクセスポイントが本来接続すべき正当な無

線 LAN アクセスポイントであるか否かを確認することができない。このため、近隣に同一

の設定を施した不正無線 LAN アクセスポイントが設置され、気づかずに重要な情報を不正

な無線 LAN アクセスポイントのネットワークに、搾取されてしまう可能性がある。

　アクセスポイントの無線 LAN コントローラによっては、不正アクセスポイントを検出し、

通信を強制切断パケットにより、通信を妨害する機能を装備しているものがある。

　1.3　無線 LAN のセキュリティ対策と暗号化

無線 LAN 機器は、機種が異なっても接続が可能である。利用者が無線 LAN 機器のセキュ

リティ設定を実施する。無線のセキュリティ機能としては、以下のものがある。

①　暗号化

通信内容を簡単に盗聴されない。

②　アクセス認証

通信開始手続きで許可された利用者・端末のみ通信を可能とする。

- 33 -

③　なりすましの防止

別の通信相手が通信中の相手のふりをして通信を行う。送信フレームのシーケンス番号、

送信者による個別署名で確認する。

④　鍵の安全な共有

予め関連した鍵を端末と基地局間で共有する。

2.　無線 LAN 暗号化プロトコル

無線通信における暗号の利用時には、無線だから盗聴の可能性は当然であり、安全性の高

い暗号方式の採用が必要である。

通信データを大量に入手でき、暗号解読のサンプルが多い

無線 LAN 機器は入手が容易であり盗聴のために容易に転用が可能

通信中のデータパケットはパソコンのドライバソフトが処理するので、暗号解読処

理が容易

企業ネットワークでの利用では、価値の高い情報が多い

　2.1　WEP 暗号化方式

（１）暗号方式

WEP（Wired Equipment Privacy)は、以下の暗号方式である。

鍵管理　　初期ベクトル２４ビットと固定の秘密鍵 40ビット

暗号方式　RC4(Rivest Cipher 4)：平文 1 バイトごとに暗号化処理を行う

（２）WEP の脆弱性

RC4自体の安全性は、2001 年にシャミア(Shamir)が解読している。WEP 暗号方式は、鍵

解読のフリーソフトが出回っており、IPA(情報処理推進機構)でもセキュリティ上の問題を

指摘している。http://www.ipa.go.jp/security/txt/2008/07outline.html　WEP には、以下の脆弱性がある。

鍵長（鍵の秘密鍵部分）が 40ビットと短い→現行 104ビット

WEP では、初期ベクトル（IV)は無線区間を暗号化されず

鍵の一部が拡張鍵の特定の部分に出現する可能性が高い

IPパケットのヘッダ部分などに既知の情報が大量に含まれている

秘密鍵は固定で繰り返し使用される

改竄検知ができない

　2.2　WPA 暗号化方式

WPA(Wireless Protected Access)は、WEP の代わりとして考えられた方式で以下の特

徴がある。

TKIP（Temporal Key Integrity Protocol：一時鍵）

- 34 -

48ビット化された初期ベクトル

MIC（Message Integrity Check：メッセージの完全性検査）

PSK（Pre-Shared Key） 簡易認証方式

WPA2（Wi-Fi Protected Access 2）は、WPA の改良版で、AES 暗号を採用している。

　2.3　TKIP の仕様

TKIP は、初期ベクトルの拡張（24ビットから 48ビットに拡張）し、フレームごとに初

期ベクトルの値を変更する。

　2.3　無線 LAN のアクセス認証

　無線 LAN のアクセス認証は、RADIUS サーバを使用する。

　3.　無線 LAN の設定

　無線 LAN のルータ設定は、WPA での設定：「TKIP＋PSK」で、WPA-２の使用を推奨され

る。

4.　まとめ

無線 LAN のセキュリティ上の脅威

不正アクセス

通信路データの盗聴

無線 LAN のセキュリティ対策

アクセス認証

鍵の安全な共有

通信路の暗号化

無線 LAN 暗号化プロトコル

WEP 暗号化プロトコル方式と問題点

WPA 暗号化プロトコル

無線 LAN のアクセス認証

- 35 -

第 8 回　OSS の活用シーンと暗号化

OSS におけるセキュリティの基本概念とそこでの暗号化の役割、必然性、利点などを理

解する。

1.　オープンソース OS と暗号化

　オープンソース OS の活用されているサーバおよびクライアントにおいても暗号化機能は

様々なシーンで活用される。

　1.1　OS の活用シーンと暗号化

Linux ではカーネルにも暗号化モジュールが組み込まれている。暗号化ファイルシステム

といった機能も提供される。

サーバ向けとしては、イントラネットサーバ・インターネットサーバとして稼働する際に

SSL/TLS は標準的に利用されている。また、SSH によるアクセスを受け付ける際にも用い

られる。

クライアント向けとしては、SSL/TLS、SSH でサーバにアクセスする際、およびディス

クデータの暗号化などが行われる。

　1.2　暗号化の有効性評価

暗号化の有効性評価で、いくつかの確認すべき項目がある。

（１）暗号アルゴリズムの評価

電子政府推奨暗号であるか。暗号技術評価プロジェクト CRYPTREC (Cryptography Research and Evaluation Committees) などの機関で推奨する暗号を利用しているか。

（２）暗号モジュールの評価

　暗号モジュールの評価は以下の標準化がある。

暗号モジュールの評価(米国・カナダ：CMVP)、（日本： JCMVP) 暗号モジュールセキュリティ要求事項：FIPS 140-2、ISO/IEC 19790

JCMVP：Japan Cryptographic Module Validation Program（３）IT セキュリティ評価及び認証制度（CC (Common Criteria)：コモンクライテリア）

CC は、国際規格となっている。 (ISO/IEC15408) 　IT セキュリティ評価及び認証制度（ ISO/IEC15408、CC）

　2.　OSS における暗号化の実装

（１）オープンソース OS Linux ではカーネルにも暗号化モジュールが組み込まれている。暗号化ファイルシステム

といった機能も提供される。多くの Linux ディストリビューションには OpenSSL が標準で

導入されている。OpenSSL では以下に示す暗号化機能を提供している。

- 36 -

SSL に対応したアプリケーションで暗号化通信

SSH でセキュアなリモートログイン

暗号化通信のプロトコルを実装

（２）OSS ミドルウェア

データベースなどで暗号化を実装している。

（３）アプリケーション

電子メールソフトウェア、Web ソフトウェアで暗号化を実装している。

業務用アプリケーションでは、開発用言語で OpenSSL ライブラリ暗号化を実装している、

Java、Perl、Ruby が使用される。

　2.1　OS における暗号化の実装

Linux カーネルには、IPsec が実装されている。また、Linux ディストリビューションに

暗号化ライブラリを SSH、OpenSSL が実装されている。

（１）SSH暗号化通信を使ってリモートホストにログインし、各種処理を行うためのツール群

（sshd、ssh、ファイル転送；scp および sftp、認証；ssh-keygen, ssh-agent, ssh-add, ssh-askpass）がある。公開鍵と秘密鍵によって生成される共通鍵で通信を暗号化する。

（２）OpenSSLSSL/TLS 通信、SSL-VPN（Stunnel)が実現できる。

　2.2　ミドルウェアにおける暗号化の実装

OSS のミドルウェアに暗号化が実装されている。

（１）データベースソフトウェア

暗号化関数、復号関数、SHAハッシュ関数では、OpenSSL などの外部ライブラリを利用

している。

MySQL ProstgreSQL

（２）運用管理ソフトウェア

リソース管理、AP プロセス管理、ログ管理、サービス・ポート管理、SNMP 管理、ファ

イル監視などのログデータ、バックアップデータで暗号化している。

GroundWork Monitor Hinemos

（３）信頼性、性能向上ツール

　2.3　アプリケーションにおける暗号化の実装

（１）ネットワークアプリケーション

- 37 -

電子メール

Sendmail(サーバ）　　　　　：TLS による SMTP の暗号化

Thunderbird（クライアント）：電子メールの暗号化

Web のセキュリティ

Apache(サーバ) 　　　　　　:SSL の導入（OpenSSL)サーバ認証、クライアント認証、通信経路の暗号化を実現

Firefox（クライアント） : SSL の導入

（２）汎用業務アプリケーション

WS-Security では、SOAP メッセージを拡張し、エンドツーエンドのセキュリティを保証

する。また、SOAP メッセージ交換で、認証、メッセージ完全性、メッセージ暗号化してい

る。

Kerberos 認証、X.509 認証

XML Signature、XML Encryption

5.　まとめ

様々な OSS 活用シーンにおける暗号化の必要性

サーバ

クライアント

OSS による暗号化処理の実装例

OSS の活用されている多くのサーバソフトウェアにおいて暗号化処理が実装されてい

る

暗号化の有効性評価

電子政府推奨暗号、CRYPTREC、コモンクライテリア、暗号モジュール評価

OS、ミドルウェア、アプリケーションでの実装

OSレベルでは、Linux カーネル、OpenSSH、OpenSSL ミドルウェア

- データベースソフトウェア

- 運用管理ソフトウェア

- 信頼性、性能向上ツール

アプリケーション

- ネットワークアプリケーション

- 汎用業務アプリケーション

- 38 -

第 9 回　IPsec による暗号化通信

新しいオープンソースネットワーク基盤における VPN のもととなる IPsec プロトコルについ

て、仕様、課題、役割、必然性、利点などを理解する。

1.　VPN の構成

　VPN とは公衆網であるコンピュータネットワークを利用して結ぶ仮想専用ネットワークであ

る。

　1.1　VPN（Virtual Private Network）とは

　VPN とは公衆網であるコンピュータネットワークを利用して、ポイント間を認証化や暗号化

手法で結ぶ仮想専用ネットワークである。

　VPN を用いてポイント間を接続すれば、同じ LAN 環境を共有することができる。

VPN を実現する手段として主に以下の方式がある。

IPsec を用いた IPsec-VPN SSL を用いた SSL-VPN SSH によるトンネリング

L2TP(Layer 2 Tunneling Protocol)を用いた IP-VPN 通信業者が提供している広域イーサネット VPN

　1.2　VPN の構成

VPN 方式の概要、特徴、および留意点を説明する。

　1.3　トンネリングとは

（１）リモートアクセスの場合

トンネリングではネットワークに仮想的なトンネルを作る。暗号化によりトンネルを流れる

パケットの機密性を守る。

（２）通信トンネルができるまで

　制御用トンネルを使って、上り下りのトンネルを同時に作る。

1.4　VPN の仕様

　RFC ドキュメント構成

2.　IPsec IPSec ではＩＰヘッダの後ろにアタッチする拡張ヘッダを利用して暗号化機能と認証機能を

実装する。つまり拡張ヘッダにより暗号情報、認証情報をやりとりする。

（１）暗号化・認証情報の作成手順

- 39 -

①まずデータ＋IP ヘッダがあるとする。データを暗号鍵で暗号化する。これをデータ部

に戻した後に、暗号化されたことを明示する暗号化ヘッダを、データ部と IP ヘッダの間

に挿入する。この暗号化データ＋暗号化ヘッダ＋ IP ヘッダを ESP(Encapsulated Security Payload)という。

②ESP に対して認証鍵を用いて認証ヘッダを作成する。これを AH(Authentication Header)という。AH を、暗号化ヘッダと IP ヘッダの間に挿入する。この暗号化データ

＋暗号化ヘッダ＋AH＋IP ヘッダの一体となったパケットを通信するホストに送信する。

（２）復号化・認証情報のチェックの仕組み

①送信元から受け取ったパケットから AH を除いた暗号化データ＋暗号化ヘッダ＋IP ヘッダについて、認証鍵を用いて新たに認証ヘッダを作成する

②この新たに作成した認証ヘッダと AH を比較し、改竄の有無をチェックする

③ESP から IP ヘッダと暗号化ヘッダを取り除き、暗号化ヘッダの情報に基づき、暗号

鍵を用いて復号化する

　2.1　IPsec の仕組み

　以下の項目を説明する。

（１）暗号化・認証情報の作成と復号化・認証チェック

（２）トンネルモード

（３）トランスポートモード

（４）ヘッダの種類と特徴 (AH)　AH は次の機能を持っている。

1) データの完全性

2) データの発信元認証

3) データの再送検出

AH は、SPI、シーケンス番号、認証データから構成される。SPI には、認証データを生成する

のに使ったハッシュ関数や認証鍵の情報が入っている。認証データは、トンネルモードの場合

は IPヘッダ、TCPヘッダ、データを、また、トランスポートモードの場合は TCPヘッダ、デー

タをハッシュ関数に通して、得られる。

（５）ヘッダの種類と特徴 (ESP)　ESP は、データの機密性を確保するため、暗号化(カプセル化)の機能を提供する。図に示すよ

うに、トンネルモードの場合は、IPヘッダ、TCPヘッダ、データが、また、トランスポートモ

ードに場合は、TCPヘッダとデータが暗号化される。暗号化されたデータをペイロードデータ

と言いる。ESP は、ペイロードデータと SPI(Security Parameter Index)、シーケンス番号、

認証データ(AH を指定した時)から構成される。

SPI に は 、 暗 号 化 に使用 し た ア ルゴリズムや暗 号 鍵 が格納さ れ て い る SA(Security Association)を指すインデックスが入っている。シーケンス番号はパケットに付けられた通し

- 40 -

番号で、不正な再送を防ぐために用意されている。

（６）SA の設定

lPsec では、暗号化や認証に使用するアルゴリズムを限定せず、様々な種類のアルゴリズムの

中から選択できるようにしている。例えば暗号化アルゴリズム（実装必須 DES、以下オプショ

ン IDEA、Blowfish、RC5、3DES、CAST、AES）だけでも、多数存在する。

これは、どんなに強固な暗号であっても、コンピュータの計算能力の向上によって、次第に

安全とはいえなくなってしまうことを踏まえての設計方針であると言える。なお、IPsec では、

暗号化方式として共有鍵暗号化方式が採用されている。これは、公開鍵暗号化方式より共有鍵暗

号化方式のほうが、暗号化・復号処理をより速く行えるからである。

IPsec では、通信を行う前に、オフラインか、IKE を使ってオンラインで行うかの方法で、暗

号化アルゴリズム、ハッシュアルゴリズム、暗号鍵、等を決定し、互いにその情報を共有して

おく必要がある。この情報を保持するために、IPsec では SA（Security Association）を利用

する。SA には、表のようなパラメータ情報が保持される。

（７）認証データの生成と検証

トランスポートモードでのデータの送信側での認証データの生成、データの受信側での認証

データの検証を示している。送信側では、IPヘッダ、SPI、シーケンス番号、TCPヘッダ、デー

タから、可変のデータ（通信途中で変わるデータで、ヘッダのチェックサム、パケットの存続

時間などがある）を除いて、ハッシュ関数の入力とする。その際、事前に送信側と受信側で決

めておいた秘密鍵も使われる。こうして得られた認証データ、使用したハッシュ関数や秘密鍵

の情報(SPI)を AH に設定し、送信する。受信した側では、AH 内の SPI から、使用するハッシュ

関数、秘密鍵を決定し、送信側と同じ様に認証データを作成し、その値と受信した認証データを

比較し、一致した時、通信途中でのデータ改ざんが無いと判断する。また、このような認証デ

ータを生成できるのは、認証データ生成に必要な情報、すなわち、ハッシュアルゴリズム、秘

密鍵、SPI を知っている通信相手だけなので、送信者は正しい相手と判断でき、ユーザ認証が実

現されていることになる。

　2.2　VPN 構築への利用

　VPN の利用の仕方は、一般的な利用法として 2 種類ある。

①トランスポートモード（送信側でデータを暗号化し、IPヘッダ付加し転送）は端末と

端末間で利用する。

②トンネルモード（IPsecＧＷで IPヘッダも含め暗号化し、IPヘッダを付加し転送）は、

ルータとルータ間で利用する。

2.3 IPsec の利点／欠点

（１）利点

アプリケーションが VPN を意識する必要がない

- 41 -

送受信パケットの最後の認証データで改ざんの検出

（２）欠点

暗号化/認証化には暗号鍵、認証鍵が必要であるが、これはホスト間で予め設定されて

いる必要がある

IPsec でカプセル化されたパケットは元のパケットより長くなる

ルータのアドレス変換機能（NAT)越えの通信ができない、IP マスカレードなど VPN 対

応ルータを使用する

LAN同士で Ipsec で接続したネットワークの機器でアドレスが重複する可能性がある

2.4 IPsec を使えるシステム

IPsec を用いて VPN を通信する場合、VNP トンネルをファイアウォールの外に確立するか、

それともファイアウォールの中から確立するかで、アウトサイドトンネル/インサイドトンネル

という二つのタイプがある。

インサイドトンネルの場合、あたかも同じ LAN 環境になったかのように振る舞うことができ、

LAN で利用できるアプリケーションはすべて利用できる。通常同じ会社の異なる拠点間を接続

する場合に用いる。

アウトサイトトンネルの場合、トンネルを通じた通信がファイアウォールに阻まれるために、

ファイアウォールが許可するアプリケーションの通信だけが利用できる。取引先企業との接続

を行う場合はこの接続形態になる。

2.5 IKE の機能

　IPsec による暗号化通信は、SA の内容について事前設定しておく必要がある。事前設定の方

法には、手動で行う方法と自動で行う方法がある。実装が必須になっている手動の方法は、フ

ロッピーディスクや IC カード等、オフラインで SA を設定する。しかし、通信当事者で合意し

た SA を手動で設定するのは、作業が大変であるだけでなく、通信相手が遠くにあったり、数が

多かったりすると、実質的には困難だったりする。また、安全性を向上させるために、暗号鍵

を定期的に変更したりする場合には、自動的に SA を交換する手法が望ましいといえる。

　IPsec が SA の自動交換のために用意しているプロトコルが、 IKE(Internet Key Exchange)である。IKE による鍵交換はポート番号 500 の UDP を使って、ふたつのフェーズで行われる。

　フェーズ 1 では、IPsec で用いる SA を準備するためのフェーズで、３つのステップを踏みる。

1) ISAKMP(Internet Security Association and Key Management Protocol) -SA の確立

　送信側から、幾つかの SA が提案され、その中のひとつが受信側で選ばれる。

2) マスターキー確立

　送信側で、フェーズ 2 のデータ暗号化で使う暗号化の鍵(共通鍵暗号方式の共通鍵)を生成し、

受信側に送る。その際、共通鍵は DH(Diffie-Hellman)という公開鍵暗号アルゴリズムを応用し

- 42 -

た方式で送信される。

3) 相互認証

　マスターキーの送信に相手の公開鍵を使う。その公開鍵の証明書が正しいか、認証局に問い合

わせて、検証を行う。この検証作業は、送信局だけでなく、受信局も行う。

　フェーズ 1 が完了すると、ISAKMP-SA、セッションキーを、IPsec の ESPや AH で使えるよ

うになる。フェーズ 2 では、送信側から受信側に幾つかの SA 提示がされ、受信側で幾つかが選

ばれるといったステップを踏む。

3.　セキュアな MPLS による IP-VPN　MPLS とは、IETF が標準化を進めている、ラベルスイッチング方式を用いたパケット転送技

術。現在インターネットで主流となっている、ルータを用いたバケツリレー式のデータ転送を、

より高速・大容量化する技術である。

　本来、ルータが他のルータから受け取ったパケットを別のルータに転送する際には、ルーテ

ィング(経路選択)情報として IPヘッダを利用するが、MPLS ではこれの代わりに「ラベル」と

呼ばれる短い固定長の識別標識を利用する。

　MPLS 対応ルータ(Label Switching Router : LSR)によって構成されたネットワーク内では、

パケットの行き先に応じて次にどのルータに転送するかという情報を各ルータが保持しており、

それぞれの経路はラベルによって識別される。

　このネットワークの入口にあるルータ(エッジルータ)にパケットが届くと、パケット内の経

路情報にラベルを付加して、次のルータに転送する。次のルータは、パケットについているラ

ベルを見て、どのルータに転送すべきかを判断し、適切な転送先にパケットを送る。外部ネッ

トワークへの出口にあるエッジルータは、到着したパケットからラベルを取り除き、外のルー

タへ転送する。

　LSR同士は LDP(Label Distribution Protocol)というプロトコルを用いて経路情報の交換を

行ない、経路が変更されるとラベルの再割り当てが行われる。

　このようにラベルをもとにした転送を行なうことにより、転送処理と経路計算処理の分離が

可能となり、個々のルータの負担が軽減され、処理の高速化が実現される。

　また、第 3層(ネットワーク層)のプロトコルである IP と、第 2層(データリンク層)の ATM な

どの諸技術との緊密な連携により、IP では不可能な高度な通信品質制御(QoS)や、ネットワーク

構成に依存しないプライベートネットワーク(IP-VPN)の構築などが可能となる。

　同様の技術に、Cisco Systems 社の「Tag Switching」や、Ipsilon Networks 社(現 Nokia社)の「IP Switching」、東芝の「CSR」(cell switch router)、IBM 社の「ARIS」などがある。

出典：http://e-words.jp/w/MPLS.html

3.1 IP-VPN のセキュリティ

IP-VPN に代表される VPN サービス提供のひとつである。キャリア内に共有型の IP／MPLS網

- 43 -

を構築して、ユーザ毎に論理的に分割された VPN網を提供する。ユーザ側は、MPLS を意識す

ることなく従来のルータをそのまま使用することができ、さらには異なるユーザで同一の IP ア

ドレスを重複して使うことができる。

3.2 MPLS によるトンネル

ラベルはスタックして付けることができる。LSR は外側のラベルしか見ないので、このスタ

ックにより階層的な LSP を作ることができる。外側の LSP により内側の LSP をトンネルさせる

と言った使い方が可能だ。このスタックラベルは MPLS による VPN の提供などで多用される。

フォワーディング動作では外側のラベルが優先され、内側のラベルは無視される。

4.　まとめ

VPN とは公衆網であるコンピュータネットワークを利用して、ポイント間を認証化や

暗号化手法で結ぶ仮想専用ネットワークである。

VPN を実現する手段として主に IPsec を用いた IPsec-VPN と SSL を用いた SSL-VPN、通信業者が提供する IP-VPN がある。

IPSec ではＩＰヘッダの後ろにアタッチする拡張ヘッダを利用して暗号化機能と認証機

能を実装する。

暗号化データ＋暗号化ヘッダ＋IP ヘッダを ESP (Encapsulated Security Payload)という。

IPsec を用いた VPN には、アウトサイドトンネル/インサイドトンネルという二つのタ

イプがある。

- 44 -

第 10 回　SSH によるトンネリング

SSH を用いたクライアント／サーバ間の暗号化通信の仕組み、特徴、実装手順について

理解する。

1. SSH とは

SSH は通信経路の暗号化や認証を強化したネットワーク越しの処理を可能とする、トラン

スポート層のプロトコルであり、透過的な暗号路を提供する。

　接続要求、ファイル転送要求、リモート実行要求などに適用される。

1.1 SSH の機能と特徴

SSH を用いることで、ネットワーク経由のログイン、ファイルコピーなどがデータを暗

号化・圧縮した状態で行うことができる。リモートホストにログインする slogin、リモー

トのシェルを利用する ssh、リモートホスト間でのファイルコピーを行う scp や、FTP を代用するための sftp が用意されている。従来のプロトコル通信を暗号化するポート転送機

能も有している。非常に普及した OSS であり、以下の多くの UNIX系ディストリビューシ

ョンで実装されている。

Mac OS X Sun Solaris OpenBSD FreeBSD Linux の各ディストリビューション

1.2 OpenSSHSSH プロトコルを実装するデファクトの OSS である。OpenBSD プロジェクトにより開

発・メンテナンスされている。機能を実装したクライアント側の実装と、サーバ側の実装と

が配布されている。

OpenSSH は以下の特徴がある。

オープンソース・プロジェクト

フリーのライセンス

強力な暗号化機能 (3DES, Blowfish, AES, Arcfour) X11 転送 (X Windows ウインドウシステムの通信を暗号化) ポート転送 (従来プロトコルの通信を暗号化) 強力な認証 (公開鍵、One-Time パスワード と Kerberos 認証) エージェント転送 (Single-Sign-On) 相互運用 (SSH リモートプロトコル・スタンダード 1.3, 1.5, および 2.0 に準拠) SFTP クライアントおよびサーバのサポート (SSH1 および SSH2 プロトコル)

- 45 -

データ圧縮

1.3 SSH クライアントコマンド

　SSH クライアントは以下の機能を持つ。

ssh(1) - rlogin/rsh ライクの基本的なクライアントプログラム

ssh_config(5) - ssh クライアント設定ファイルの説明

sshd(8) - ログインするためのデーモン

sshd_config(5) - sshd デーモン設定ファイルの説明

ssh-agent(1) - 秘密鍵を保持するための認証エージェント

ssh-add(1) - 認証エージェントに鍵を登録するツール

scp(1) - rcp(1) に似たファイルコピープログラム

sftp(1) - SSH1 および SSH2 プロトコル上で動作する FTP ライクなプログラム

ssh-keygen(1) - 鍵生成ツール

sftp-server(8) - SFTP サーバサブシステム (sshd が自動的に起動する) ssh-keyscan(1) - いくつかのホストからホスト公開鍵を収集するツール

ssh-keysign(8) - ホストベース認証を使うときの補助プログラム

ssh-rand-helper(8) - 乱数生成用の補助プログラム

1.4 公開鍵認証

（１）SSH における identity（ID、身元証明書）

公開鍵暗号のプライベート鍵と公開鍵のワンセット

プライベート鍵はローカルに持つ、自身のみアクセス可能

公開鍵は、公開し SSH サーバのアカウントにも置く

（２）認証時

クライアントがサーバに接続要求

サーバからチャレンジデータを送信

クライアントは、チャレンジデータをプライベート鍵で暗号化しサーバにレスポン

ス（認証子）を送信

サーバは認証子をクライアントの公開鍵で復号し、チャレンジデータと一致すれば

接続を認める

（３）設定

公開鍵暗号は（RSA または DSA）

プライベート鍵と公開鍵の鍵ペア、プライベート鍵を保護するためのパスフレーズ

が必要

SSH サーバ側にあらかじめ公開鍵のインストールが必要

暗号通信は、共通鍵暗号（3DES、Blowfish、AES、Arcfour など）の共通鍵を暗号化し

- 46 -

て鍵交換を行う。通信自体は高速な共通鍵暗号を用いる。

2. SSH における通信路の暗号化

SSH による通信路の暗号化は以下の手順となる。

①　事前に作成してあるホスト公開鍵をサーバからクライアントに送る。

②　クライアント側、サーバ側、それぞれで公開鍵・秘密鍵ペアを作成する。

③　それぞれの公開鍵を交換する。

④　共通の秘密鍵を作成し Diffie-Hellman 法によりこの鍵を交換する。

⑤　公開鍵暗号化アルゴリズムを決定する。

⑥　共通鍵暗号化アルゴリズムを決定する。

⑦　メッセージ認証アルゴリズムを決定する。

⑧　メッセージダイジェストアルゴリズムを決定する。

2.1　SHH のアーキテクチャ

クライアント鍵：非対称鍵(サーバに対してユーザを識別する) ホスト鍵 ：非対称鍵(サーバ/マシンを識別する) セション鍵 ：対称鍵(SSH クライアント/サーバ通信を暗号化）

2.2　公開鍵暗号鍵ペアの生成・管理及び変換

（１）鍵ペアの生成

ssh-keygen コマンド：鍵ペアの生成・管理及び変換

公開鍵認証を使うため、自分が使用する公開鍵とプライベート鍵との鍵ペアを生成

する（ｰ t　鍵種類指定：DSA か RSA）

キーボード入力のタイミングで内部乱数生成器を初期化

プライベート鍵ファイルは指定したパスフレーズ(最低でも 10～15文字が必要)で暗号化

SSH 用ディレクトリに保存 (id_dsa と id_dsa.pub)（２）公開鍵の SHH サーバへのインストール

サーバの /.ssh/authorized_keys　を編集

ssh-copy-id コマンド：公開鍵をリモートサーバにコピー

（３）SSH エージェント

メモリにプライベート鍵を保持し、必要に応じて SHH 通信

shh-agent コマンド、shh-add コマンド

2.3　SSH を使った VPNssh は、仮想プライベートネットワーク (VPN) のトンネリングをサポートする。

- 47 -

異なる 2 つのネットワークを安全に結合することが可能

sshd_config (5) ファイルにある PermitTunnel 設定項目は、サーバがこの機能を

サポートするかどうか、およびサポートするレベル (レイヤ 2 あるいはレイヤ 3)を指定

　SSH 経由の VPN は大きなオーバーヘッドをともなう。ワイヤレス VPN などの、一時的

な設定にのみ使うのが望ましい。長期的な VPN 接続は、ipsecctl (8) や isakmpd (8) とい

ったツールを使うほうが優れている。

3.　まとめ

SSH は通信経路の暗号化や認証を強化したネットワーク越しの処理を可能とする、

トランスポート層のプロトコルである。

OpenSSH は SSH プロトコルを実装するデファクトの OSS ある。

ネットワークを介してリモートホストへのログインや処理を行う場合、セキュリテ

ィの観点と使い勝手の良さから SSH が多くの場合利用されている。

SSH の各種コマンドにより、ネットワーク経由のログイン、ファイルコピーなどが

データを暗号化した状態で行うことができる。

リモートホストにログインする slogin、リモートのシェルを利用する ssh、リモー

トホスト間でのファイルコピーを行う scp や、FTP を代用するための sftp が用意

されている。

- 48 -

第 11 回　SSL プロトコルの仕組み

インターネット暗号化の仕組みの中核をなすプロトコルである SSL について、その仕様、

課題、役割、必然性、利点などを理解する。

1. SSL の概要

SSL (Secure Socket Layer)/TLS（Transport Layer Security) は世界で最も利用されて

いる暗号通信の方法である。HTTP による Web サーバの通信を暗号化時に利用され、

SSL/TLS により、通信相手を認証し、通信内容の機密性を確保する。

SSL は 1994 年に Netscape 社によって作られたプロトコルであり、TLS は SSL3.0 を元に、IETF によってつくられたプロトコルである。OpenSSL は SSL/TLS の OSS デファ

クト実装となっている。

1.1 SSL の機能と位置づけ

　SSL はトランスポート層とアプリカーション層の間で動作しアプリケーション層に、セキ

ュリティ機能を提供するプロトコルである。

1.2 SSL のネットワークでの役割と利点

SSL は、ネットワーク層、トランスポート層のプロトコルである TCP/IP とその上位のア

プリケーション層(メールの SMTP、WWW の HTTP、等)の中間で動作するように作られた

セキュリティプロトコルである。

アプリケーション層でセキュリティを確保しようとすると、 SMTP、HTTP、それぞれの

仕様をアップして、セキュリティを確保するか、あるいは、SSL の方式になる。

SSL の方式は、上位のプロトコルに依存せずに、全てのアプリケーションに適用できるこ

とを目的として作られたセキュリティプロトコル である。

　1.3 SSL の種類と特徴

SSL と TLS の違い

（１）SSL (Secure Socket Layer) 1994 年　Netscape 社によりNetscape Navigator 用に開発

1995 年　Version 3.0　その後　3.1 に改版

（２）TLS（Transport Layer Security) SSL3.0 をベースに IETF によって作られたプロトコル

1999 年　RFC2246 で TLS 1.0 を発表(SSL3.1相当) 2006 年　RFC4346 で TLS 1.1

　　　　　　　CBC アタックへの対策、対称暗号方式 AES を追加

- 49 -

2. SSL/TLS の仕様

SSL の仕様については IETF では、TLS という。TLS プロトコルは、「TLS レコードプロ

トコル」と「TLS ハンドシェイクプロトコル」という 2 つのプロトコルからなる。

(1)　TLS レコードプロトコル

　TLS レコードプロトコルは、TLS ハンドシェイクプロトコルの下にあり、共通暗号を用

いて暗号化されたメッセージ通信を行う部分である。

(2)　 TLS ハンドシェイクプロトコル

　TLS ハンドシェイクプロトコルは、暗号方式の決定、暗号方法の変更、エラー発生通知、

データ転送という機能を持つ 4 つのプロトコルからなる。

2.1 TLS の仕様構造

　TLS は、階層化されたプロトコルである。

2.2 TLS プロトコル仕様

（１）TLSレコードプロトコル

メッセージを複数のフラグメントに分割、フラグメント毎に圧縮

メッセージ認証コードに MAC値を付加（改ざん対策）

対称暗号でメッセージを暗号化

データタイプ・バーション番号・圧縮した長さからなるヘッダを付加

（２）TLSハンドシェイクプロトコル

ハンドシェイクプロトコルは、以下の

クライアントとサーバ間で暗号方式、圧縮方式、鍵交換方式を取り決め

証明書の認証（公開鍵方式の場合）

鍵交換(公開鍵方式または、Diffie-Hellmann 鍵交換）

　　　プレマスターシークレット、クライアントランダム、サーバランダム

　　　一方向ハッシュ関数(MD5 と SHA-1)による擬似乱数生成器を使用

　　　対称暗号の鍵、メッセージ認証コードの鍵、CBC モードの初期ベクトル

（２）暗号仕様変更プロトコル(change cipher spec protocol)暗号方式(暗号スイート）の変更

（３）警告プロトコル(alert protocol)TLSハンドシェイクプロトコルでエラー発生時に通信相手に伝える

（４）アプリケーションデータプロトコル

アプリケーションのデータを通信相手とやりとりする

2.3 TLS の処理シーケンス

　クライアントとサーバ間の TLS のハンドシェイクプロトコル（処理シーケンス）を説明

- 50 -

する。

3. SSL の安全性

　SSL/TLS に関しては以下の攻撃があり、対応策が実装されている。

（１）個々の暗号技術への攻撃

SSL/TLS は特定の暗号技術に依存していない

暗号スイートの選択

（２）擬似乱数生成器に対する攻撃

擬似乱数発生プログラムのバグ

乱数発生シード（時刻、プロセス番号）

（３）証明書の隙を突く攻撃

認証局のサーバ証明書の検証

最新版の CRL(証明書失効リスト)の取得

（４）その他の注意

証明書の相手が信用できるか

暗号化通信前後のデータは守られない

3.1 サポートする暗号化アルゴリズム

　TLSハンドシェイクプロトコルで使われている暗号技術、TLSレコードプロトコルで使わ

れている暗号技術を説明する。

3.2 セキュリティ強度

　暗号方式のセキュリティ強度を高める危殆化対策を示す。

（1） 共通鍵暗号

　共通鍵暗号として，ISO で標準化され日本政府推奨暗号にも採用された Camelliaや米国政府標準暗号である AES（Advanced Encryption Standard）などがあり、Web ブラウザ

とサーバ間での通信やファイル、ストレージの暗号化に広く利用されている。

　DES 暗号は脆弱性が証明されたており、 ISO で標準化され日本政府電子政府推奨暗号

（AES、 Camellia、3DES）の使用に移行される。

（2） 公開鍵暗号・署名

　公開鍵暗号・署名では， R S A 暗号・署名やDSA（Digital Signature Algorithm）など

があり，TLS 通信やサーバ証明書によるサーバ認証、電子メールの暗号化や改ざん防止など

で利用されている。また、NTT が開発した高速に署名生成が可能な ESIGNPSSや、現在公

開鍵暗号において最高の安全性だとされる IND-CCA2、日本政府推奨暗号にも採用されてい

る PSEC-KEM なども公開鍵暗号・署名の１つである。

　RSA 公開鍵では、1024ビット鍵長の使用を停止、2048ビットに移行している。また、

- 51 -

鍵長が短くても強度の高い楕円曲線暗号も使用されている。

（3） ハッシュ関数

　ハッシュ関数では、米国家安全保障局（NSA）が設計し、米国国立標準技術研究所

（NIST）が規格化した米国政府標準ハッシュ関数 SHA-224，SHA-256，SHA-384，SHA-512 などが現在広く利用されている。

　ＭＤ５の脆弱性が証明され、SHA-1 についても安全性が問題視されている。SHA ｰ 1 から

SHA-2への移行が進められている。

4. OpenSSLOpenSSL は、無償で入手可能で、SSL の全ての機能を実装している暗号ライブラリと SSLツールキットで構成されている。次に示す HP でソース形式でダウンロードできる。

http://www.openssl.org/（１）SSL ライブラリ

TLSｖ１を含む全バージョンを実装している。

（２）暗号ライブラリ

共通鍵暗号方式、公開鍵暗号方式

ハッシュ、メッセージダイジェストにおける一般的アルゴリズム

擬似乱数生成器

一般的な証明書のフォーマットの操作

鍵の素材管理

暗号化技術に関するアクセラレータ

4.1 OpenSSL の基本操作

OpenSSL のライブラリは、コマンドラインツールを使用しており、デフォルト設定用の

設定ファイルが付属している。（ca、req、x509）

メッセージダイジェストアルゴリズムは以下から選択できる。

ハッシュ関数：MD2、MD4、MD5、MDC2、SHA1(DSS1)、RIPEMD-160 電子署名：RSA（アルゴリズムを指定）、DSA（DSS1 を使用)

共通鍵暗号方式は、Blowfish、CAST5、DES、3DES、IDEA、RC2、RC4、RC5、AES か

ら選択できる。

公開鍵暗号方式は以下から選択できる。

DH：鍵交換の機密性を提供、暗号化や真正性は保証しない

DSA:電子署名の作成や検証、暗号化や機密性は保証しない

RSA:機密性、真正性、暗号化

S/MIME は、電子メールの認証と暗号化を提供している。

公開鍵生成時には、パスワードとパスフレーズが擬似乱数生成器のシードとなる。

- 52 -

4.2 SSL の暗号アルゴリズム（NTT 暗号基盤）

　SSL/TLS で使用する暗号アルゴリズムは、国際標準が進められていることを説明する。

5.　まとめ

インターネット暗号化の仕組みの中核をなすプロトコルである SSL について、その

仕様、課題、役割、必然性、利点などを理解する。

SSL/TLS((Secure Socket Layer/Transport Layer Security)は世界で最も利用さ

れている暗号通信の方法である。HTTP による Web サーバの通信を暗号化する際に

利用されている。

SSL/TLS により、クライアントの送信する機密情報の盗聴を防と改竄を防ぐ。また、

送信先の Web サーバが本物の送信相手である確認をすることもできる。

TLS の仕様構造、TLS プロトコル仕様、SSL の処理シーケンスを理解した。

サポートする暗号化アルゴリズム、セキュリティ強度により、SSL の安全性が依存

する。

SSL の OSS 実装として OpenSSL がある。OpenSSL は、暗号ライブラリと SSLツールキットで構成されている。

- 53 -

第 12 回　VPN 通信の構築（講義＋実習）

IPsec を用いた VPN を設定構築し、その手順、機能効果、暗号化の状況などを理解する。

1. OSS における IPsec の設定

Linux ディストリビューションである Red Hat Enterprise Linux 4 を例に IPsec 設定方

法を説明する。ホスト A とホスト B とを IPSec トンネルを使ってお互いに接続する。

　以下の手順で実施する。

①　環境整備：すべての IPsec ホスト(ホスト間設定を使用する場合)又は、 ルータ(ネットワーク間設定を使用する場合)上に ipsec-toolsRPM パッケージをインストール

②　IPsec ホスト間 (Host-to-Host) 設定の情報収集

③　暗号化鍵の指定（PSK：pre-shared-key)④　設定内容の確認（SA)⑤　IPsec接続開始

⑥　IPsec接続状態の確認

1.1 IPsec インストール

IPsec を実装するには、すべての IPsec ホスト(ホスト間設定を使用する場合)又は、 ルー

タ(ネットワーク間設定を使用する場合)上に ipsec-toolsRPM パッケージをインストールす

る必要がある。RPM パッケージには基本のライブラリ、 デーモン、及び IPsec 接続の設定

に役立つ設定ファイルが入っている。そして 以下を含む。

/lib/libipsec.so ? Red Hat Enterprise Linux で使用される IPsec 実装と Linux カ

ーネル間の PF_KEY 信頼キー管理ソケットインターフェースを含むライブラリであ

る。

/sbin/setkey ? カーネル内 IPsec のキー管理とセキュリティ属性を 処理する。この

実行可能ファイルは racoon キー管理デーモンにより 制御される。setkey につい

ての詳細は、setkey(8) manページを参照のこと。

/sbin/racoon ? IKE キー管理デーモンで、 Ipsec接続されたシステム間でのキー共

有 と セ キ ュ リ テ ィ関連を 管 理 /制御す る の に使用 す る 。 こ の デ ー モ ン

は /etc/racoon/racoon.conf ファイ ル を編集す る と 設 定 す る こ と が で き る 。

racoon についての詳細は、 racoon(8) manページを参照のこと。

/etc/racoon/racoon.conf ? 接続内で使用される認証方法や暗号化アルゴリズムな

ど、IPsec接続の各種事項を 設定するのに使用される racoon デーモン設定ファイ

ルである。 使用できるディレクティブの総合一覧は、racoon.conf(5) manページ

を 参照のこと。

http://www.redhat.com/docs/manuals/enterprise/RHE...anual/ja/security-guide/s1-ipsec-generalconf.html

- 54 -

1.2 IPsec ホスト間 (Host-to-Host) 設定の情報収集

　IPsec は、ホスト間接続の方法であるデスクトップまたはワークステーションから 別のデ

スクトップまたはワークステーションに接続するよう設定することができる。このタイプ

の接続は、各ホストが接続されるネットワークが両ホストをつなげるセキュアなトンネル

を作成するために使用する。ホスト間接続に必要なことはほとんどなく、各ホストでの

IPsec 設定も同様に行うことはあまりない。 ホストにはキャリアネットワークヘの専用接続

(インターネットなど)と、 IPsec接続を作成するための Linux があれば十分である。

　接続を作成するには、まず、各ワークステーションからシステムとネットワークの情報を

収集する。 ホスト間接続には、次のような情報が必要である。

両ホストの IP アドレス

IPsec 接続を識別し、他のデバイスや接続と区別するための独自の名前 (例、

ipsec0) 1 つの固定暗号化キーか racoon で自動的に生成されるキー

接続を開始しセッション中に暗号化キーを交換するのに使用される pre-shared 認

証キー

　例えば、ワークステーション A とワークステーション B とを IPSec トンネルを使ってお

互いに接続するとする。ワークステーションは 値 foobarbaz を持つ pre-shared key を使

い接続し、 ユーザは racoon で各ホスト間の認証キーを 自動生成、共有することに同意す

る。両方のホストユーザは コネクション名を ipsec0 とした。

1.3 暗号化鍵の指定（PSK：pre-shared-key)　以下にワークステーション B とのホスト間 IPsec 接続の為のワークステーション A 用の

ifcfg ファイ ル を 示 す 。 こ の 例 の接続を 識別す る 個 有名は ipsec0 で 、 ファイ ル名

は/etc/sysconfig/network-scripts/ifcfg-ipsec0 になる。

　　DST=X.X.X.X　　TYPE=IPSEC　　ONBOOT=yes　　IKE_METHOD=PSK　ワークステーション A では X.X.X.X にワークステーション B の IP アドレスを入れるが、

ワークステーション B では X.X.X.X にワークステーション A の IP アドレスを入れる。起動

時に接続が開始するよう設定され (ONBOOT=yes)、pre-sahred key 認証方法を使う

(IKE_METHOD=PSK)。　以下に、/etc/sysconfig/network-scripts/keys-ipsec0 と呼ばれる、事前共有鍵ファイル

の内容を示す。両方のワークステーションがお互いを認証するのに使う。このファイルの内

容は両方のワークステーションで同じでなければならず、また、root ユーザのみがこのフ

- 55 -

ァイルの読み取り/書き込みをできる状態であるべきものである。

　　IKE_PSK=foobarbaz　root ユーザだけがファイルを読み取り、編集できるよう、 keys-ipsec0 ファイルを変更

するには、ファイルを作成したら次のコマンドを実行する。

　　chmod 600 /etc/sysconfig/network-scripts/keys-ipsec0　認証キーを変更するためには、両方のワークステーション上で keys -ipsec0 ファイルを

編集する。正常な接続には、両方のキーが同じでなければならない。

1.4 設定内容の確認（SA) （１）リモートホストへの第１段階接続設定ファイル：X.X.X.X.conf　以下の例は、リモートホストへの段階１接続のための特殊設定である。ファイル名は

X.X.X.X.conf になる(X.X.X.X には、リモート IPsec ルータの IP アドレスを入れる)。この

ファイルは、IPsec トンネルが起動されると自動的に生成されるため、直接編集しないよう

に注意する。

　　;　　remote X.X.X.X　　{　　exchange_mode aggressive, main;　　my_identifier address;　　proposal {　　encryption_algorithm 3des;　　hash_algorithm sha1;　　authentication_method pre_shared_key;　　dh_group 2 ;　　}　　}　 IPsec 接続が開始された時のデフォルトの第１段階設定ファイルには、 Red Hat Enterprise Linux の IPsec 実装で使用する以下の文章が含まれている。

　・remote X.X.X.X　この設定ファイルの結果となるスタンザが、X.X.X.XIP アドレスで識別されたリモートノ

ードにのみ適用されることを示す。

　・exchange_mode aggressive　Red Hat Enterprise Linux 上の IPsec 用のデフォルト設定は攻撃的な認証モードを使用

し、これが 複数のホストとの幾つかの IPsec 接続設定を許可しながら、接続オーバーヘッ

ド を低減する。

　・my_identifier address

- 56 -

　ノードの認証時に使用する識別手法を定義する。Red Hat Enterprise Linux はノードの

識別に IP アドレスを使用する。

　・encryption_algorithm 3des　認証中に使用する暗号法を定義する。デフォルトでは、3DES(Triple Data Encryption Standard)を使用する。

　・hash_algorithm sha1;　ノード間の第１段階交渉の間に使用するハッシュアルゴリズムを指定する。デフォルトで

は、Secure Hash Algorithm のバージョン１が使用する。

　・authentication_method pre_shared_key　ノード交渉中に使用する認証法を定義する。Red Hat Enterprise Linux はデフォルトで

は、 認証に事前共有キーを使用する。

　・dh_group 2　動的生成のセッションキーを確立する為の Diffie-Hellman グループ番号を指定する。デ

フォルトでは、1024 ビットグループが使用される。

（２）IPsec 接続が起動したときの racoon.conf ファイル

　/etc/racoon/racoon.conf ファイルは、include “/etc/racoon/X.X.X.X.conf” ステート

メントを除いて、全ての IPsec ノード上で同一でなければならない。このステートメント

は (及び、参照するファイル)は、IPsec トンネルが起動すると生成される。ワーク ステー

ション A では、include ステートメントの X.X.X.X をワークステーション B の IP アドレ

スにする。ワークステーション B はその逆である。以下に、IPsec 接続が起動したときの

一般的な racoon.conf ファイルを示す。

　　# Racoon IKE daemon configuration file.　　# See 'man racoon.conf' for a description of the format and entries.　　path include "/etc/racoon";　　path pre_shared_key "/etc/racoon/psk.txt";　　path certificate "/etc/racoon/certs";　　sainfo anonymous　　{　　pfs_group 2;　　lifetime time 1 hour ;　　encryption_algorithm 3des, blowfish 448, rijndael ;　　authentication_algorithm hmac_sha1, hmac_md5 ;　　compression_algorithm deflate ;　　}　　Include "/etc/racoon/X.X.X.X.conf"　このデフォルトの racoon.conf ファイルには、IPsec 設定用の 定義されたパス、事前共

- 57 -

有鍵、及び証書が含まれている。

・sainfo anonymous のフィールド

　 IPsec ノード間の第２段階 SA を説明している。IPsec 接続の性格(使用されるサポート

付暗号化アルゴリズムを含む)交換鍵の方法で、次のリストは第２段階のフィールドを定義

している。

・sainfo anonymous　IPsec 信用証書が合致する限り、どのピアとでも無記名で SA が開始することを示す。

・pfs_group 2　Diffie-Hellman 鍵交換プロトコルを定義し、これは、IPsec ノードが IPsec 接続の第２

段階の為に相互に臨時のセッション鍵を確立する方法を決定する。デフォルトでは、Red HatEnterprise Linux の IPsec 実装は Diffie-Hellman 暗号化鍵交換グループのグループ２

(いわゆる modp1024)を使用する。グループ２は、 1024 ビットモジュラーべき乗を使い、

これはプライベート鍵が侵略されても、以前の IPsec送信に対する攻撃者からの解読を防止

する。

・lifetime time 1 hour　このパラメータは、SA のライフサイクルを指定し、時間、又はデータのバイト数で、 数

量化できる。Red Hat Enterprise Linux の IPsec 実装は１時間の寿命を指定する。

・encryption_algorithm 3des, blowfish 448, rijndael　 第 ２段階用 に サポー ト さ れ た 暗 号 法 を指定 す る 。 Red Hat Enterprise Linux は

3DES、448-ビット Blowfish、 及び Rijndael(AES、いわゆる Advanced Encryption Standard で使用される暗号表記) をサポートしている。

・authentication_algorithm hmac_sha1, hmac_md5　サポートされる認証用のハッシュアルゴリズムをリストする。サポートのモード は、

sha1 と md5 のハッシュメッセージ認証コードである(HMAC)。・compression_algorithm deflate　IPCOMP(IP Payload Compression)サポート用の収縮コンプレッションアルゴリズムを

定義して、これにより低速な接続上で IP データグラムのかなり高速な転送がでる。

（３）SA(Security Association)lPsec では、暗号化や認証に使用するアルゴリズムを限定せず、様々な種類のアルゴリズ

ムの中から選択できる。例えば暗号化アルゴリズム（実装必須 DES、以下オプション

IDEA、Blowfish、RC5、3DES、CAST、AES）だけでも、多数存在する。

　これは、どんなに強固な暗号であっても、コンピュータの計算能力の向上によって、次第

に安全とはいえなくなってしまうことを踏まえての設計方針であると言える。なお、 IPsecでは、暗号化方式として共有鍵暗号化方式が採用されている。これは、公開鍵暗号化方式よ

り共有鍵暗号化方式のほうが、暗号化・復号処理をより速く行えるからである。

　IPsec では、通信を行う前に、オフラインか、IKE を使ってオンラインで行うかの方法で、

- 58 -

暗号化アルゴリズム、ハッシュアルゴリズム、暗号鍵、等を決定し、互いにその情報を共有

し て お く 必 要 が あ る 。 こ の 情 報 を 保 持 す る た め に 、 IPsec で は SA （ Security Association）を利用すう。SA には、パラメータ情報が保持される。

1.5 IPsec接続開始

接続を開始するには、ワークステーションを再起動（ONBOOT=yes の場合）するか次の

コマンドを root として各ホストで実行する。

　　/sbin/ifup ipsec0

2.　暗号化の状態確認

ping6 コマンドを利用して IPsec による通信の暗号化を実際に体験するには次の手順を行

う（プロトコルアナライザによる通信の観測）。

①　暗号鍵、認証鍵や暗号化アルゴリズムの方法を記述した security policy (SP)を記

述し、送信側受信側で、setkey コマンドでその SP を設定する

②　受信側で tcpdump で監視③　送信側で ping6 コマンドを発行

④　もしも IPsec が動作していれば、ダンプされるパケットには icm ヘッダがなく、

単に ESP という暗号化ヘッダの文言だけが表示される

2.1 IPsec接続状態の確認

　IPsec接続をテストするには、tcpdump ユーティリティを実行して ホスト(またはネット

ワーク)間で転送されているネットワークパケットを表示し、 IPsec で暗号化されているこ

とを確認する。パケットには AHヘッダが含まれ、 ESPパケットとして表示されていなけ

ればならない。ESP であれば暗号化されている 。例えば、次のように表示する。

　　17:13:20.617872 pinky.example.com > ijin.example.com: 　　\AH(spi=0x0aaa749f,seq=0x335):

ESP(spi=0x0ec0441e,seq=0x335) (DF)

2.2 IPsec による暗号化の確認方法

　ping6 の暗号なし通信と、ping6 を IPsec で暗号化して通信した場合の確認を行った例を

図示し説明する。

3.　まとめ

動作モードの設定や Security Association (SA)の設定など、IPsec の具体的な設定につ

いて解説する。さらに、IPsec により通信路が実際に暗号化されている状態を確認する方法

についても説明する。

- 59 -

1. OSS における IPsec の設定

1.1 IPsec インストール

1.2 IPsec ホスト間 (Host-to-Host) 設定の情報収集

1.3 暗号化鍵の指定（PSK：pre-shared-key) 1.4 設定内容の確認（SA) 1.5 IPsec接続開始

2.　暗号化の状態確認

2.1 IPsec接続状態の確認

2.2 IPsec による暗号化の確認方法

- 60 -

第 13 回　PKI(公開鍵暗号化基盤)の仕組み

暗号化を運用する重要な基盤である PKI について、仕様、課題、役割、必然性、利点、実

際の運用仕様、代表的な PKI などを理解する。

1. PKI の仕組みと特徴

　PKI はユーザ同士の本人認証を、事前の直接的なコンタクトなしに、実現するコンピュー

タシステム基盤である。コンタクトなしに認証を実現するためには、信頼できる第三者機関

(TTP:Trusted Third Party)が信頼関係を確立するための重要な責をもっている。

　認証局モデルは、信頼できる第三者機関 (TTP： Trusted Third Party)に公開鍵の所有者

を保証してもらう方法である。TTP は、公開鍵の所有者の本人性をなんらかの方法で確認し、

公開鍵とその所有者を保証する証明書(Certificate) を発行する。証明書には、公開鍵とその

所有者を証明する情報が記載され、改ざんを防ぐために TTP の署名が付与される。証明書

を発行する TTP のことを、認証局 (CA：Certification Authority)という。

1.1 公開鍵暗号を利用した電子認証のメカニズム

　PKI は公開鍵暗号方式を用いて、本人認証を行う仕組みであり、PKI モデルの要素は次の

通りである。

(1)　認証局(CA: Certification Authority)　秘密鍵と公開鍵の鍵ペアの所持者に対して公開鍵証明書を発行する機関である。CA が証

明書を発行する際には RA の審査が終了していることが必要である。CA は証明書を発行す

る際に、自分自身の鍵を用いて、所持者の証明書に署名をして、リポジトリに登録する。こ

れをもって CA が所持者に信頼を与えたとする。

(2)　登録局(RA: Registration Authority)　公開鍵証明書を発行するために資格審査を行う要素である。

(3)　リポジトリ

　公開鍵証明書を保管、開示するための手段である。

(4)　公開鍵証明書

　公開鍵ペアの所持者であることを証明した情報である。CA により署名がされている。

(5)　失効リスト（CRL: Certificate Revocation List）　有効期限切れや資格喪失等により証明できない証明書一覧を記述したリストである。CRLは CA により署名される。

(6)　証明書有効性検証機関(VA: Validation Authority)　公開鍵証明書が有効であるかどうかを検証する要素である。信頼された CA により署名が

行われていること、CRL に載っていないこと、そして有効期限内であることの検証が行わ

れる。

(7)　証明書利用者

- 61 -

　秘密鍵の所有者で、公開鍵証明書を利用する人やプログラムである。

1.2 PKI の必要条件

（１）概要

　セキュリティポリシーとセキュリティ要件を説明する。

（２）セキュリティポリシー

情報システムのセキュリティを保つために必要な文書化された基本方針である。具体的な

行動やシステムの個別設定を直接記述するものでない場合が多い。情報システムのセキュリ

ティに関するすべての人、組織、建屋、機器、ソフトウェア、ネットワークの、セキュリテ

ィとしてあるべき姿を記述する。ISO17799 の国際標準に沿うことが多い。

セキュリティポリシーを作成する際は、物理環境・組織の制約、運用及びコストの制約、

そしてシステム要件のバランスをとりながら、個別のシステムに合致させることが必要で

ある。

・セキュリティとしての組織のあり方

・資産の分類と管理

・スタッフのセキュリティ規範

・物理的および環境的要因のセキュリティ基準

・通信および運用管理に関する方針

（３）セキュリティ要件

セキュリティ要件はセキュリティポリシーに沿って具体的な要件を定義するものであり、

以下の項目を含む。

・アプリケーションと選定の検討

・鍵用途の検討

・public CA を利用するか、private CA を利用するか

・運用及び技術的要件の定義

・公開鍵証明書のライフサイクルの明示と安全な鍵の配送方法

・CA 秘密鍵の管理運用

・CA 局を設置する物理環境の設計

・証明書の設計

・CRL の設計

・リポジトリの設計

・CA 局を運用する組織と役割の検討

セキュリティ要件には、日本電子商取引組合(ECOM)がガイドラインとして提示している、

次の三つのレベルがある。

①　低レベル：暗号電子メールなどをイントラネット内で構築するレベル

②　中レベル：比較的少額の取引が行われる環境に該当するレベル

- 62 -

③　高レベル：組織間取引において高額な取引が行われる環境に該当するレベル

セキュリティ要件は、信頼が喪失されたときの損害の大きさに基づいて策定されるべきであ

る。

1.3 PKI 適用分野

　PKI の適用分野は e-commerce、ドキュメントのリーガルドキュメント化、原本証明、

公的機関への入札等の本人証明が必要なすべての分野に渡る。

　PKI の運用状況は、Web においては SSL、メールの暗号化・署名に S/MIME、PDF などの電子文書の署名、スマートカードの本人認証、電子マネーの本人認証、無線 LAN の認証

等がある。

　PKI アプリケーション(PKI-Enable Application)について概要、機能、構造等を解説する。

PKI アプリケーションとしては、Web の暗号化と認証を行う「TLS/SSL)」、電子メール

の暗号化とデジタル署名を行う「S/MIME」、ネットワークの暗号化を行う「VPN」、XML文書へのデジタル署名を行う「XML 署名」 および Web で公開されるプログラム（アプレ

ット）の認証を行う「コードサイニング」を取り上げる。

　TLS/SSL は、Web (HTTP) において最もよく利用されている。TLS/SSL の主な利用目的

を以下に示す。

・通信の暗号化と完全性の保証

　サーバとクライアントの通信を暗号化することにより、クレジットカード番号や個人情報

などの重要な情報をネットワークの盗聴から保護する。暗号化と同時に改ざんの検出を行う

ため、通信内容（データ）の完全性も保たれる。

・ サーバの認証

　Web における電子商取引(EC)を利用する際には、利用者はアクセスする Web サーバが

本当に信頼できるかを確認する必要がある。ドメインは誰でも取得できるため、URL に含

まれるドメイン名は必ずしも信用の根拠とすることはできない。

　TLS/SSL を利用することで、アクセスしている Web サーバを証明書によって認証するこ

とができる。

・ クライアント認証

　Web サーバにアクセスするクライアントに対して、証明書を利用した認証を要求するこ

とができる。従来利用されている ID とパスワードによる認証よりも、強固な認証が実現で

きる。Web では、サーバのみが証明書を持つ片方向認証と、サーバとクライアントが証明

書を持つ双方向認証が利用されている。

　S/MIME (Secure/MIME) は、証明書を利用して電子メールに暗号化とデジタル署名のセ

キュリティを提供する。S/MIME は、既存の技術である MIME を利用しているため、既存の

メールサーバ (MTA) で動作する。S/MIME は、電子メールに限らず、MIME を扱える他の

プロトコル(HTTP など)でも利用することができる。S/MIME の初期版である S/MIME v2

- 63 -

は、米国の RSA Security 社によって提唱され、RFC2311, RFC2312 として公表された。

S/MIME v2 は使用できるアルゴリズムが限られていたため、IETF によってより汎用性を持

たせた S/MIME v3 が策定され、RFC2632(English), RFC2633(English) として公表され

た。S/MIME を利用すると、メールの暗号化（暗号メール）とデジタル署名の付与（署名メ

ール）が実現できる。また、証明書の送付にも利用できる。

　VPN (Virtual Private Network) は、インターネット上を利用しながら安全な仮想的私設

網を実現する技術である。VPN では、双方のネットワークに VPN 装置を設置し、パケット

を暗号化して送受信する。VPN を用いると、コストを抑えながら遠隔のネットワークを接

続することができる。暗号化と復号は双方の VPN 装置で透過的に行われるので、利用者は

特段意識することなく 2 つのネットワークを同じネットワークとして利用できる。VPN 装置としては、専用機器、ルータ、ファイアウォール、端末用のソフトウェアなどがある。

　 XML 署名は 、 イ ン タ ー ネ ッ ト 上 で の 情 報交換の た め の文書 フォー マ ッ ト の

XML（eXtensible Markup Language）文書に対する改ざん、なりすましを防ぐデジタル

署名の機能である。現在、XML にデジタル署名を付与するための規格として、W3C (World Wide Web Consortium) において「XML 署名(XMLSignature)」の標準化が進めら

れている。XML の署名要件(RFC2807)、XML署名構文と処理(RFC3075)、XML の正規化

(RFC3076) が RFC として公表されている。XML 署名では、署名データは XML 形式で表現

される。

　コードサイニングは配布するプログラムにデジタル署名を施すことで、配布元の認証と第

三者による改ざんを検出する技術である。利用者は、プログラムに付与されたデジタル署名

と証明書から、プログラムが信頼できる配布元によって作られたものに相違ないことを確認

できる。

1.4 代表的な PKI の種類と特徴

（１）信用モデル

　現実世界では様々な組織が様々なポリシーで運営されている。PKI においても同様に、

様々な CA が様々なポリシーのもとで運営されている。CA が影響を与える信用の範囲を

「CA ドメイン」と呼ぶ。

　現実の組織がそれぞれ連携して機能するように、PKI においても、それぞれの CA が連携する場合がある。CA 同士の連携は、相手の CA に証明書（CA 証明書や相互認証証明書）を

発行することによって行われる。CA が連携するということは、その CA が相手の CA を信

用していることを意味する。このような信用関係のモデルを「信用モデル」という。PKI の信用モデルとして、「単独 CA モデル」、「階層型モデル」、「Web モデル」、「メッシ

ュモデル」、「ブリッジ CA モデル」がある。

単独 CA モデル ：1 つの CA が全てのユーザに証明書を発行する方式

階層型モデル　 ：複数の CA を階層型（ツリー構造）に構成する方式

- 64 -

Web モデル ：予めクライアントのアプリケーションにルート CA の一覧を埋

め込む方式

メッシュモデル ：複数の CA を相互認証により接続する方式

ブリッジ CA ：モデル複数の CA がブリッジ CA を介して接続する方式

（２）政府認証基盤(GPKI: Government PKI)　電子申請の本人確認と電子申請文書の改ざん防止の機能を提供するために、PKI に基づく

電子署名、電子認証を導入している。

1.5 オープンソースとの関わり

（１）OpenSSL　認証局システムで利用可能な OSS プロダクトの中で、もっともポピュラーものは

OpenSSL である。OpenSSL は、世界標準の暗号プロトコルである Secure Sockets Layer と Transport Layer Security を実装した高機能な OSS であり、基本の暗号ツール

キットとして広く利用されている。なお、OpenSSL ツールキットのライセンスについては、

OpenSSL ライセンスとオリジナルの SSLeay ライセンスの両方が適用される。

SSL/TSL を実装した高機能な OSS 基本の暗号ツールキットとして広く利用

コマンドラインツールの CA 機能を装備

（２）OpenCA　http://www.openca.org/ OpenCA PKI v1.1.0　認証局システムのカテゴリでは、OpenCA、ElyCA 等、OpenSSL をベースとしたフロン

トエンド機能を持った OSS も出回っている。

OpennSSLベースとしたフロントエンド機能を持つ

（３）EJBCA http://ejbca.org/ EJBCA, J2EE PKI Certificate Authority一方、本格的な認証局システムという意味では、 J2EEベースのターンキーソリューショ

ンとして EJBCA が存在する。透明性、公共性、および相互運用性に優れているという OSSの利点に加え、柔軟性に富み、複数 CA およびレベルの違う CA の基盤を EJBCA で、単一筐

体内に構築が可能である。RSA4096bit 及び楕円暗号をサポートし、ハッシュ関数では

MD5、SHA-1SHA-256 をサポート、OCSP 及び CRL、XKMS インタフェース、HSM によ

る CA 管理、及び監査ログ(改ざん検知可能)、及び管理者権限分離と必要な機能が、ほぼ最

新の仕様で揃っている。

J2EEベースで CA に必要な機能がほぼ最新の仕様で揃っている

　　RSA4096bit 及び楕円暗号、ハッシュ関数では MD5、SHA-1、SHA-256 、OCSP 及び CRL、XKMS インタフェース、HSM による CA 管理、監査ログ(改ざん検知可能)、管

理者権限分離

相互運用性に優れ海外での電子政府用 PKI として構築実績有り

- 65 -

商用では Entrust 社、RSASecurity 社など多数存在している。

2. CA局の仕組みとその機能

CA 局は PKI で利用される公開鍵証明書の信頼性を保証する役割を担っている。また、他

の CA局と相互認証を行うことにより、PKI の信頼性基盤を構築する礎となる。

（１）CA局の種類

Public CA　：第三者により発行される証明書で本人性を証明

Private CA：組織内や限られた範囲で利用

（２）CA局の機能

証明書の発行

発行した証明書の登録

CA局の公開鍵は公開

CRL の発行

他の CA と信頼関係を結ぶ

2.1 CA局とは

　CA局の役割とその機能を説明する。

2.2 CA局のソフトウェア構成

　CA局の構成例を示す。CA局には以下の機能を実現する。

管理機能：セキュリティポリシー設定、起動・終了/バックアップ/リストア、運用

者・監査者のアカウント管理

運用機能：証明書発行管理、鍵・証明書一括発行、CRL の発行管理

監査機能

（１）CA サーバ、管理者マシン

　CA サーバは、プライベート CAビルダーの本体になる。OS のサービス（デーモン）とし

て動作する。このマシンには CA の鍵ペアや発行した証明書など大切な情報が保存されてい

るので、マシン自体の管理にも十分な注意が必要となる。管理者が CA サーバに対して操作

するアプリケーションとして管理者用管理コンソールがある。

（２）運用者マシン

　運用者が CA サーバに対して操作するアプリケーションとして運用者用管理コンソールが

あります。CA サーバのマシンは管理者だけが操作できるようにし、運用者用管理コンソー

ルは CA サーバとは別のマシンから遠隔で操作するようにする。運用者は管理者が作成した

運用者アカウントで運用者用管理コンソールにログインできる。運用者は複数設定でき、ま

た複数の運用者が同時に運用者用管理コンソールを起動し、CA サーバを操作できる。証明

- 66 -

書の一括発行で鍵ペアと証明書をファイルに出力する場合、鍵ペアと証明書は CA サーバと

運用者のマシンに保存される。IC カードなどのハードウェアに鍵ペアや証明書を書き込む

場合、ハードウェアは運用者のマシンに接続されている必要がある（一括発行時）。

（３）監査者マシン

　監査者が CA サーバに対して操作するアプリケーションとして監査者用管理コンソールが

ある。運用者と同様に、監査者用管理コンソールは CA サーバとは別のマシンから遠隔で操

作するようにする。監査者は管理者が作成した監査者アカウントで監査者用管理コンソール

にログインできる。監査者は複数存在でき、また複数の監査者が同時に監査者用管理コンソ

ールを起動し、CA サーバを操作できる。

（４）利用者マシン

　利用者とは、プライベート CAビルダーから証明書を発行してもらうユーザである。取得

した証明書を用いて、SSL でアクセス制限されている Web サーバのサイトを閲覧する。

（５）ディレクトリサーバ（オプション）

　ディレクトリサーバがある場合は、ディレクトリサーバ内を検索して他人の証明書を取得

し、S/MIME による暗号メールをやりとりすることができる。

（６）Web サーバマシン

　SSL でアクセス制限したい、情報の盗聴を防止したい場合に、運用者が Web サーバに対

して証明書を発行する。Web サーバに証明書をインポートすると、SSL が必要なサイトを

作成できる。

出典：http://www.ntt-electronics.com/product/security/pri_kousei.html

2.3 CA局の運用環境と暗号化の手順

CA 局は、PKI の基盤に則り公開鍵証明書を発行し、第三者として本人性を保証する仕組

みを提供する。CA 局の暗号化手順は下記のとおりである。

①　利用者の公開鍵に対して、CA 局の秘密鍵を用いて電子署名を行い、これを公開鍵証明

書として発行する。

②　発行した公開鍵証明書はリポジトリに登録され、利用者が証明書を受けることができる

ようにする。証明書を保証するために以下を実施する。

・CA 局の公開鍵は、公開鍵証明書の検証のために公開される。

・公開鍵証明書の失効したリスト(CRL)を発行する。

・信頼モデルに基づいて他の CA と信頼関係を取り結ぶ。

・CA 局の秘密鍵は、PKI の信頼性基盤を形づくる上で最重要の要素であるために、厳重に

保管されなければならない。

2.4 CA局による暗号化手法

　CA 局では暗号化手法として、米国 RSA 社の提唱する PKI を実現するための技術仕様のグ

- 67 -

ループである PKCS（Public Key Cryptography Standards）に実質的に準拠しているとい

える。現在、PKCS #1 から PKCS#15 までが策定されている。

PKCS#1 など、IETF（Internet Engineering Taskforce）の RFC といった標準技

術団体に採用されているものもある。

PKCS #1 RSA 暗号標準 RFC 3447参照。RSA 暗号鍵、公開鍵および秘

密鍵のフォーマットの規定。Not encrypted. PKCS #3 Diffie-Hellman 鍵共有標準 お互いに事前知識を持たない

2 つの組織が連携して安全でない通信チャンネルを上でも共通鍵を確立できるよう

にする暗号プロトコル

PKCS #5 パスワードに基づく暗号化の標準 RFC 2898 お よ び PBKDF2 を参照。

PKCS #6 拡張された証明書構文の標準 古い X.509v1 証明書の仕様に

対する拡張を規定。X.509v3 により破棄

PKCS #7 暗号メッセージ構文標準 RFC 2315参照。PKI の下でメッセー

ジを署名や暗号化するのに使用される。証明書の配布のためにも用いられる(例えば、

PKCS #10 メッセージの応答として)。現在、RFC 3852 に基づいている S/MIMEの基礎を構成し、暗号メッセージ構文標準(CMS)として更新されている。

PKCS #8 秘密鍵情報構文の標準 RFC 5208参照。Apache で証明書の

秘密鍵をロードするために使用される。Not encrypted. PKCS #9 選択された属性タイプ PKCS #6 証明書拡張、PKCS #7 デジ

タル署名メッセージ、PKCS #8 秘密鍵情報、および PKCS #10 証明書署名要求で

利用される属性タイプの選択された定義

PKCS #10 証明書署名要求 RFC 2986参照。公開鍵の認証を要求するため

に認証局へ送信されるメッセージのフォーマット。証明書署名要求を参照

PKCS #11 暗号トークンインタフェース (Cryptoki) 暗号トークンへの汎

用インタフェースを定義する API(ハードウェアセキュリティモジュールも参照のこ

と) PKCS #12 個人情報交換構文の標準 パスワードに基づく鍵(暗号)により保

護された秘密鍵と、それに関連する公開鍵証明書を保管するために一般に利用され

るファイルフォーマットの定義。PFX は PKCS#12 の旧称である。

これは、複数の組み込みオブジェクト、例えば複数の証明書を格納できるコンテナ

フォーマットである。通常、パスワードにより保護/暗号化される。 Java の鍵スト

アのフォーマットとして利用できる。Tomcat では利用できるが Apache では利用

できない。

PKCS #13 楕円曲線暗号の標準 　

PKCS #14 擬似乱数 　

- 68 -

PKCS #15 暗号トークン情報フォーマットの標準 暗号トークンのユー

ザが、アプリケーションの Cryptoki の実装 (PKCS #11)や他の API に依存せず、

アプリケーションに対し自身を特定できるようにするための標準の規定。RSA は、

この標準の IC カードに関する部分を ISO/IEC 7816-15 に対し譲渡した。

3. CA局の運用

CA 局の運用環境や CA 局の運用に必要な事項について解説する。また電子証明書の発行

許可を与える Registration Authority (RA 局、登録局)や、電子署名の有効性を確認する

Validation Authority (VA 局、検証局)、実際に電子証明書の発行を行う Issuing Authority (IA 局、発行局)といった違いを説明する。

CA 局の運用環境やCA 局の運用に必要な事項

認証局運用規定(CPS: Certificate Practice Statements)は、 CA 局の運用規程と

して策定され、CA 運用の信頼性を高めるために利用される。

電子証明書の発行許可を与える Registration Authority (RA 局、登録局) 電子署名の有効性を確認する ValidationAuthority (VA 局、検証局) 実際に電子証明書の発行を行う Issuing Authority (IA 局、発行局)

3.1 認証局運用規程（CPS)CA 局の運用は、認証局運用規定(CPS: Certificate Practice Statements)として策定され、

CA 運用の信頼性を高めるために利用される。

　CPS には以下の項目が必要である。

・CA 局の義務と責務、資産の責任、解釈と実行、料金、公開とリポジトリ、準拠するべ

き監査、機密に関するポリシー、知的財産権に関する情報

・CA やRA に関して適用される認証手順要件

・CA, CA 証明書、RA、利用者に関する運用要件

・物理的な手続き、スタッフのセキュリティに関しての制御要件

・CA 局の暗号鍵、リポジトリに関する保護要件

・証明書と CRL のフォーマット要件

・CPS 自体の仕様書の管理要件

3.2 RA局、VA局、IA局の仕組み

（１）RA(Registration Authority ) 局 登録機関

申請に基づき電子証明書の発行許可を与える

（２）VA(Validation Authority )局 検証機関

- 69 -

CA 局とは別に電子証明書の有効性を保証する役割を担う

（３）IA(Issuing Authority )局 発行機関

RA 局の許可に基づき電子証明書を発行する

独自の基準で電子証明書を発行したい組織向けに各局の運営を支援するサービスが多くの

ベンダから提供されている。

　3.3　公開鍵証明書のライフサイクル

　信頼性の担保という観点から、CA によって発行された公開鍵証明書にはライフサイクル

という考え方をすることが重要である。ライフサイクルには証明書の発行からはじまり、失

効、そして再発行に至るまでの証明書の各状態と CA 局の関わりが決められなければならな

い。

信頼性の担保という観点から、CA 局によって発行された証明書にはライフサイクルとい

う考え方をすることが重要である。

①　鍵ペア生成：公開鍵と秘密鍵のペアの生成。利用者であるエンドエンティティで行

う場合もある。

②　証明書発行：RA 局の審査後に行う。有効期限を含める。

③　証明書配付：安全な手段で証明書を配布する。

④　証明書開示：リポジトリへ利用者の証明書を開示する。

⑤　証明書活性化：利用者により証明書を活性化する。配布時点で活性化する運用もあ

る。

⑥　証明書利用

⑦証明書失効：秘密鍵の信頼性の喪失、CA 秘密鍵の信頼性の喪失等により、有効期限

前に証明書を失効させること。

⑧　有効期限切れ：証明書に記述された有効期限を超過すると証明書は失効する。

⑨　再発行・更新：失効した証明書を新たに発行すること。有効期限切れの場合は鍵は

そのままで、期限だけを書き換えて更新する場合もある。

　公開鍵証明書の状態遷移を説明する。

4.　まとめ

　暗号化を運用する重要な基盤である PKI について、仕様、課題、役割、必然性、利点など

を理解する。また、実際の運用仕様、代表的な PKI についても理解する。

1. PKI の仕組みと特徴

1.1 公開鍵暗号を利用した電子認証のメカニズム

1.2 PKI の必要条件

1.3 PKI 適用分野

- 70 -

1.4 代表的な PKI の種類と特徴

1.5 オープンソースとの関わり

2. CA局の仕組みとその機能

2.1 CA局とは

2.2 CA局のソフトウェア構成

2.3 CA局の運用環境と暗号化の手順

2.4 CA局による暗号化手法

3. CA局の運用

3.1 認証局運用規程（CPS) 3.2 RA局、VA局、IA局の仕組み

　3.3　公開鍵証明書のライフサイクル

- 71 -

第 14 回　認証基盤構築実習

B to C 形態および B to B 形態での認証構造を理解する。PKI の仕組みを OpenSSL によ

って実際に構築し、その動作仕様や暗号化の様子を検証する。

1. B to C 形態での認証構造の構築

　BtoC 型の認証構造を構築し、PKI の仕組みを検証する。CA 局を構築するソフトウェアに

よりCA 局を作成し、サーバに対するサーバ証明書とクライアントに対するクライアント証

明書発行の動作や仕組みを解説する。

1.1 B to C型認証構造

　BtoC 型の認証構造は、ルート証明書をクライアント側にインポートすることを期待でき

ないモデルであり、クライアントソフトウェアにプリインストールされたルート証明書を

利用する。サーバ側は一般的には商用のルート証明サービスを利用し、サーバ証明書を商用

の証明書サービスに発行依頼をするか、自局の CA 局を商用のトラスティッドツリーに組み

込むサービスを利用するかのいずれかの手段をとる。

クライアント側は商用のルート証明書をプリインストールされている。その商用ルート

CA の信頼性モデルに基づいてサーバのサーバ証明書の認証検証を行う。商用のルート CA としてベリサイン、グローバルトラスト、クロストラスト等会社があり、それぞれの会社

が信頼できる第三者機関として、サーバの運営者を審査し、サーバ証明書を発行する。

　1.2 B to C型の信頼モデル

　BtoC 型の信頼モデルは一般には次のような形をとる。

・商用のルート CA はお互いの信頼性を相互認証している

・商用ルート CA からサーバ証明書が発行される

・クライアントはサーバ証明書の検証を、プリインストールされた商用ルート CA の証

明書を利用する

・プリインストールされた商用ルート証明書を利用するということは、クライアント側

の信頼の根拠は、PKI を利用するアプリケーションのメーカが選定する商用ルート CA の基準にあるということである

1.3 SSLSSL 通信は、BtoC 型の認証構造の典型的な例は、WWW で頻繁に利用されている。

（１）SSL 通信と特徴

相手認証および鍵交換には公開鍵暗号方式を利用している。メッセージ認証にはマスター

シークレットキーを利用した共通鍵暗号を利用して高速化する。

サーバ・クライアント間のハンドシェイクプロトコルは、次の手順となる。

- 72 -

お互いの証明書を交換してメッセージ認証のマスターシークレットキーを生成

レコード層とそれ以外の二層に分割

レコード層をハンドシェイクプロトコルから生成されたマスターシークレットキー

を用いて暗号化しメッセージ認証とする

2. B to B 形態での認証構造の構築

　B toB 型の認証構造を構築し、PKI の仕組みを検証する。具体的な手順として、相互認証

する相手認証局に対して相互認証証明書を相互に発行することで、サーバ間の相互認証を行

う仕組みについて解説する。

2.1 B to B型認証構造

　BtoB 型の認証構造は相互認証モデルと呼ばれる認証構造をもつ。

相互認証には大きく分けて次の二種類がある。

①　階層型：相互証明書の発行方向は一方向である。階層型相互認証の下階層に位置する

CA を中間CA と呼ぶことがある。

②　並列型：相互証明書の発行方向は双方向である。

並列型相互認証は認証ドメインの役割に応じて更に次の二種類の構造に分けられる。

・メッシュ型ドメイン

・ブリッジ型ドメイン

相互認証において発行される証明書を相互証明書という。相互認証を行うためには、当該

の二つの CA が共通に信頼できる認証ポイントが必要であるか、証明書要求の発信元を確認

するなんらかの手段である。

　相互認証モデル

図を用いて説明する。

2.2 相互証明書(X-Cert)相互証明書は同一認証ドメインであるかどうかによって次の二種類に分かれる。

①　ドメイン間相互証明書

②　ドメイン内相互証明書

各 CA が持つのは相手が署名した相互証明書と自己署名証明書である。

相互証明書の subject には認証された CA の名前が入り、isuuer には認証した CA の名前が入る。

　2.3　認証パスの構築とポリシーの検証

　相互認証を行うときに重要なのは、利用者が安全に信頼ポイントまでの認証パスを構築す

- 73 -

ることである。認証パスを構築するには、鍵や証明書のライフサイクルが万全な CA を信頼

ポイントとしなければならない。

CA 間の相互認証においては、各 CA ポリシー同士のマッピングが十分であることが必要

である。このポリシーマッピングが各 CA 間で同等に行われるかどうかという検証が、ポリ

シー検証である。ポリシーマッピングの状況は、CA 証明書の PolicyMapping 拡張領域に

記述される。

3. CA 局ソフトウェアを用いた CA局の構築実習　　

　実習手順に基づき CA局の構築実習を行う。

　項目は以下のとおりである。

（１）OpenSSL のインストール確認

（２）サーバのサーバ証明書の発行

（３）クライアントの証明書発行

4.　まとめ

（１）BtoC 型の認証構造

ルート証明書をクライアント側にインポートすることを期待できないモデルであり、

クライアントソフトウェアにプリインストールされたルート証明書を利用する。

BtoC 型の認証構造の信頼モデルの根拠は、PKI を利用するアプリケーションのメ

ーカが選定する商用ルート CA の基準にある。

BtoC 型の認証構造の典型的な例は、WWW で頻繁に利用される SSL 通信である。

（２）BtoB 型の認証構造

相互認証モデルと呼ばれる認証構造をもつ　

相互認証はお互いの CA 局について相互認証証明書（X-Cert）を発行して、信頼モ

デルを構築する。

相互認証を行うときに重要なのは、利用者が安全に信頼ポイントまでの認証パスを

構築することである。

（３）実習

CA 局ソフトウェア（OpenSSL）を用いた CA局の構築実習し、各種の公開鍵証明書を発

行する。

- 74 -

第 15 回　暗号化・これからの活用シーンと課題

新しいオープンソースネットワーク基盤における暗号化のニーズとその仕様、課題、役割

必然性、利点などを概説する。

1. 暗号化の新しい活用シーン

　オープンソースソフトウェアの新しい活用基盤である近傍無線技術、ユビキタスネットワ

ーク、及び IPv6 等の新しいネットワーク環境における暗号化の位置付けや意義、実装の仕

様、課題、役割、必然性、メリットやデメリットについて説明する。

2. ユビキタスネットワークでの暗号化

ユビキタスネットワークでは、情報の秘匿や改ざん検知で暗号化技術が必須となってきて

いる。情報の秘匿や改ざん検知などに使われる暗号技術は，ICT 社会基盤に欠かせないセキ

ュリティ技術の要であり，さまざまなシステムやサービスの中で使われている。

2.1 近傍無線技術での活用

近傍無線技術・ユビキタスネットワークの暗号化の例と課題（無線 LAN）を示す。

無線 LAN 技術においてセキュリティ上の問題点は 3 つある。アクセスポイントが発見さ

れやすい、通信データが傍受されやすい、関係ないユーザに使われやすい、という点である。

特に二点目のデータの漏洩に対して、暗号化技術が適用される。

無線 LAN における暗号化規格として、業界団体である Wi-Fi Alliance が 2004 年 9 月に

発表した WPA2 がある。2002 年 10 月に発表された WPA に比べ、改良版の WPA2 では強

力な暗号化方式である AES をベースにした、CCMP と呼ばれるプロトコルを使用している。

なお、WPA は IEEE802.11i が策定される以前に Wi-Fi Alliance によって作成されたので準

拠していなかったが、WPA2 は IEEE 802.11i を準拠している。2006 年 3 月より、WPA2 をサポートすることが Wi-Fi 認定ロゴを製品に添付する条件になった。

2.2 活用シーンとセキュリティリスク

　ホットスポットでは、ノート PCやDA を携帯して営業活動等を行うビジネスワーカーを

サービス導入期の主なターゲットとしている。外出先でのメールの送受信やインターネット

接続による情報収集、社内イントラネットへの高速接続による機動的なビジネススタイルと 、

新しいライフスタイルの確立をサポートする。ビジネスワーカーの利用が多く見込まれる首

都をはじめとした主要都市重点エリアのカフェ、レストラン、ホテルロビー、空港、貸会議

室、コンビニエンスストアを中心にサービスエリアを展開している。

　無線 LAN サービスにおいて認証・セキュリティへの取り組みは非常に重要であり、サー

ビス提供事業者の大きな課題の１つである。ホットスポットでは、万全のセキュリティを確

保し、かつ高い利便性を実現するために、利用実験を通じて把握したお客さまのニーズを基

- 75 -

に①発展性、②端末・OSへの非依存性、③トータルセキュリティをコンセプトとしてセキ

ュリティを提供している。

2.3 暗号化の仕様

IEEE802.11i（セキュリティ）の標準化における WPA（Wi-Fi Protected Access）2 の

認証の状況を説明する。

2.4 暗号化の課題

　近傍無線技術には、メリットとデメリットがある。メリットとして、無線であることから

利便性が高いことが上げられる。デメリットとしては、メリットの裏返しとなるが無線であ

るが故に意図しない他者による傍受の危険性にさらされている点があげられる。このため常

に通信の暗号化の強化が求められている。

　通信の暗号化の強化、OSS のドライバや SDK の存在が必須となる。近傍無線技術では、

クライアント用に無線 LAN や Bluetooth の Linux スタックである BlueZ などが提供され

利用されている。

ユビキタスネットワークにおいては、OS やミドルウェアなどの基盤としてオープンソー

スソフトウェアが利用されている。暗号化の実現にあたって、特定のハードウェアやソフト

ウェアに依存する仕様の場合には、利用したいオープンソースソフトウェアに対応したドラ

イバや SDK の存在が必須なため制約となる場合がある。

具体的には、無線 LAN の WEP 暗号化については脆弱性が指摘されている。最近は、1分程度で 128bit（104bit）の WEP キーが解析してしまう WEP 暗号の解読ツールがフリーソ

フトで出回っている。この為、WPA2 での AES 暗号に移行している。

無線 LAN のの不正利用対策必要である。NetStumbler は、周囲にあるアクセス ポイン･トを探索し、ESS-ID、チャネル、MAC アドレス、無線 LAN の規格などを表示してしまう。

この為、 アクセスポイントの SSID のステルス化が必要である。

無線 LAN アクセスポイントのなりすましにたいしては、本来接続すべき正当な無線 LAN アクセスポイントであるか否かを、IEEE801.1x 認証、公開鍵証明書による認証する。

2.5 携帯通信の暗号化仕様

（１）無線通信の暗号化

　米国の GSM ネットワークで広く使われている A5/1 アルゴリズム。この技術の弱点はこ

れまでにも指摘されていたが、実際に攻撃を仕掛けるためには相当の手順を踏む必要があっ

た。

　しかし、今回披露された方法では 30分足らずで暗号を解除でき、「リアルタイム」の暗

号解読が可能になる。プレゼンテーションを行ったグループは、暗号を高速解除できるハー

ド製品の販売も計画しているという。この技術が悪用されれば、スパイなどの違法行為が簡

- 76 -

単にできてしまうことにもなりかねない。

アディ・シャミアら研究グループが、A5/3 と知られ、KASUMI (ベースは三菱電機の

MISTY) とも呼ばれ、GSMや 3G 携帯で使われている暗号を解読する新しい攻撃方法を開発

したそうで、その論文「A Practical-Time Attack on the A5/3 Cryptosystem Used in Third Generation GSM Telephony」が公開された。KASUMI は Fiestel 構造のブロック暗

号で同一ラウンド関数を繰り返す暗号になっていて、8段から構成されている。 攻撃には関

連鍵攻撃 (relayted-key attack) と知られる戦法を用い、彼らはそれをサンドイッチ攻撃と

呼んでいる。まず、distinguisher を使って、7段目までに平均差分確率/平均線形確率を 2-14 という高い確率まで上げ、残りの 1段を解析し、4 つの関連鍵、226 データ、230 バイ

トのメモリそして、232時間を使って、KASUMI の全ての拡大鍵を引き出すようだ。

（２）携帯電話の SIM（UMI)カードの暗号化

携帯電話の SIM は 、 ３ GPP （ 3rd Generation Partnership Project) の 標準準拠

TS23.048で規格化され、公開鍵基盤 PKI 機能の搭載、SMS送信、データの改ざん防止の認証アルゴリ

ズムの搭載している。

（３）ｉアプリの暗号化

（４）電子認証サービス FirstPass（ファーストパス）

FirstPass は従来の ID／パスワード認証に代わる「PKI（公開鍵暗号基盤）」というインタ

ーネット標準技術を使った FOMA の電子認証サービスである。面倒な入力が必要なく、携帯

でも PC でもドコモから取得したユーザ証明書（データ）を FirstPass 対応サイトへ送信す

るだけで簡単に認証が行える。

　また、i アプリを利用して電子署名をすることで電子文書が改ざんされていないことを確

認することができる。FirstPass により「盗聴」「なりすまし」「改ざん」を防ぐことがで

き、安全で信頼性のあるデータ通信が可能となる。

　2.6　ユビキタスネットワーク（FeliCa）

　FeliCa は SONY が開発した非接触 IC カード技術で、現在日本では最も普及している。 リ

ーダ／ライタによる処理は、IC カードの検出、相互認証、データの読み書きという順序で

行われ、FeliCa では、相互認証にはリーダ／ライタによる処理は、 IC カードの検出、相互

認証、データの読み書きを使用し、通信データの暗号化には DES を使用している。

特に通信データの暗号化鍵は、相互認証時に乱数を生成させ、それを利用することで、動的

に鍵は生成し、「なりすまし」を避けている。共通鍵暗号化方式を使用する理由としては、

ラッシュ時における Suica の利用に見られるように、高速処理が求められるという点が挙

げられるが、より安全性が高い暗号化方式として公開鍵方式が挙げられるが、一般的に処理

に時間がかかってしまうという欠点がある。

- 77 -

3. IPv6 での暗号化仕様

（１）IPv4 での IP アドレス枯渇対策

　2010 年には IPv4 での IP アドレスは枯渇するといわれている。IPv4 のアドレス数を拡張

するために、IPv6 が検討され、標準化された。

（２）IPv6 における IPsec　IPsec は、IP パケットの安全性と信頼性を高めるプロトコルである。IPv6 において IPsec は標準で実装される。それに対して、IPv4 においては標準ではない。IPv4 においては IP アドレスが不足しているため、一般には NAT ルータにおいてプライベートアドレスとグロ

ーバルアドレスの変換が行われている。しかし、このように通信経路でアドレス変換が行わ

れてしまうと、認証ヘッダが食い違い IPsec を使用できない。

　IPsec では安全性を確保するために暗号化機能を持つ。また信頼性を確保するために、デ

ータが改竄されていないかを調べる認証機能を持つ。これらの機能はそれぞれ暗号化ヘッダ

と認証ヘッダ(AH)と呼ばれる個別の拡張ヘッダを使用する。暗号化ヘッダのアルゴリズム

として、対称型暗号に基づいた鍵付きメッセージ認証コードである DES やトリプル DES が使用される。認証ヘッダのアルゴリズムとして、一方向ハッシュ関数である SHA-1 やMD5 が使用される。

3.1 活用シーンとセキュリティリスク

（１）活用シーン

　IPv6 は、事実上無限の数の IP アドレスが付与できる。アドレス（「グローバル IP アドレ

ス」）を、コンピュータの他に携帯端末から家電製品まですべての装置に割り当て可能であ

る。

（２）IPv6 におけるセキュリティ上の問題について

IPv6 における IPsec は暗号化に使われる鍵の交換方法は規定されていない。そのため、

鍵配送には手作業かあるいは自動になる。最近では、IPv6 用の集中証明書サーバとして、

IKEv2 プロトコルをサポートするサーバによって簡略化された。

エンドツーエンドの IPsec は IPv6 の大きな利点である。しかし、そのためにエンドポイ

ント間に置かれた機器が、暗号化されたパケットを復元して検査することが不可能になって

しまう。もし、すべての暗号鍵を検査のために集中管理させてしまうと、今度はそこにクラ

ッカーが侵入されるとすべての暗号鍵が盗まれてしまうという脆弱点ができてしまう。これ

に対しては、中央のサーバに侵入検知パターンなどのデータベースを持たせ、クライアント

は常時それを参考にしてパケットをチェックするという手段が提案されている。

すべてのベンダによる IPsec における ESP の実装が守秘性機能をサポートしているとは

限らない。IPv6 の実装は歴史が浅いため、IPv6 ネットワークのセキュリティ監査ツールが

まだなく、実装の中には、まだ十分なテストを経ていないコードも含まれている。

アドレス空間が広いことと、MAC アドレスによる自動設定のため、逆引きの管理が困難

- 78 -

であり、逆引きを要求されるケースで困ることがある（逆引きできないホストからの接続を

拒否するサーバなど）。

3.2 暗号化の局面

　従来の IPv4 ネットワークにおいては、境界にファイアウォールを設置し、NAT が使用さ

れるセキュリティモデルが使用されてきた。しかし、 IPv6 ネットワークではエンドツーエ

ンドの透過性を確保しつつネットワーク全体のセキュリティを高める必要がある。ネットワ

ーク規模に応じた二つの分散型セキュリティモデルが、この目的に対し挙げられる。

ファイアウォールをエンドポイントに分散したモデルでは、セキュリティ管理サーバが

ネットワーク上のエンドポイントを認証し、それらにファイアウォールポリシーを配布す

る。このポリシーの中には IPsec の鍵なども含まれる。つまり、エンドポイント自身が自分

のセキュリティを確保する。

　ハイブリッド型の分散ファイアウォールモデルでは、同様に管理サーバがエンドポイント

を認証し、ポリシーを配布する。しかし、サーバはエンドポイントそれぞれにセキュリテ

ィレベルを決定し、それに基づいてポリシーを決定する。この場合、簡単なアクセス制御以

上の複雑な制御は各エンドポイントで行われる。

3.3 暗号化の仕様

IPｖ６パケットでの Ipsec 位置付けを下記の項目について説明する。

AH、ESP の各プロトコルヘッダは、IPv6 の拡張ヘッダとして仕様化

認証(AH) セキュリティペイロードカプセル化（ESP)

3.　まとめ

近傍無線技術の実用例としては、無線 LAN やBluetooth、ユビキタスネットワーク

の例としては非接触スマートカードや RFID などがあり、オープンソースソフトウ

ェアでも利用されている。

共通の特徴として無線であることから、利用者の利便性が高いといえるが、意図し

ない他社の傍受の危険性も高く、常にセキュリティの強化が求められている。

特定のベンダによる技術に依存している場合や電波を利用することによる法制面で

の規制も配慮する必要がある。

- 79 -