"暗号技術入門"読書メモ。
#amazon||>
<iframe src="http://rcm-jp.amazon.co.jp/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=glamenvseptze-22&o=9&p=8&l=as1&m=amazon&f=ifr&md=1X69VDGQCMF7Z30FM082&asins=4797350997" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
||<
非常に分かりやすい「入門書」で、おすすめです。
まず図が豊富で文章も簡潔丁寧。あまり詳細まで踏み込まず、基本コンセプトに絞って解説してくれているので概要を把握するにはもってこいです。
そしてなにより、「なぜこの技術が開発されたのか？」「他の技術とどう関連して使われているのか？」「どういう課題が発生するのか？」「その課題を克服するためにどういう技術が編み出されたのか？」という、技術の目的とその積み重ねを丁寧に追っていく点が素晴らしいです。

例えばPKIとは何かという疑問に対して、「PKIとは○○だよ」と教えてくれる資料はたくさんあります。
しかし、「なぜPKIが必要だったのか？PKIで克服しようとした課題はなんだったのか？PKIを導入しても解決できない課題はなにか？」という部分まで解説してくれるのが本書です。
さらに、それら要素技術がどのように組み合わされて実用化されているのか、PGPやSSLを例に応用例を分かりやすく示してくれています。

どの技術も、それまでの技術の積み重ね、「巨人の肩に乗った」成果ではあります。そしてこの本は、暗号技術に付いての積み重ねを分かりやすく俯瞰し、把握できるよう工夫されています。

個別の要素技術について調べていっても、どう繋がっているのか全体像が見えづらくてモヤモヤしている方に、特におすすめです。
#more||
以下、自分用の抜き書き、メモ。
#outline||
----
* 暗号化：対称暗号と公開鍵暗号

まず、根っこには「メッセージを暗号化して送信したい」というのがある。
で、自分と相手とで暗号化・復号化で同じ鍵を使うのが「対鍵暗号」。DESとかAESとかはこちらの技術に属している。長いメッセージをブロックに分割し、ブロックごとに暗号化する方法がいくつかあり、それが「ブロック暗号モード」でCBCとかCTRとか、アルファベット三文字＋「モード」の名前がそれ。

じゃぁその鍵をどうやって送ればいいの？というところで、「ならそもそも、暗号化に必要な鍵と復号化に必要な鍵を分ければよくね？」っていう使い方が出来るのが「公開鍵暗号」。

公開鍵暗号では、「秘密鍵」と「公開鍵」ペアを使う。ペアを作るときに使われる数学的な理論がRSAとかそんなの。
AliceがBobにメッセージを送るとき、Bobの公開鍵を予め教えてもらっておく。
で、AliceはBobの公開鍵を使ってメッセージを暗号化する。これを復号化するにはBobの秘密鍵を使うしか無いが、Bobの秘密鍵はBobしか持ってないはずなので、Bobしか復号化出来ないはず。

で、公開鍵暗号での暗号化は結構大変で時間がかかる。ので、現実的には「メッセージは対称鍵で暗号化し、対称鍵を秘密鍵で暗号化して相手に渡す」方法が取られる。対称鍵のビット数は、メッセージに比べれば短く、公開鍵暗号でも問題なく処理できる大きさ。で、対称鍵自体は「セッション鍵」とも呼ばれて、そのメッセージの送信一回限りの使い捨てにしちゃう。

* 改ざん検出：メッセージ認証コードとデジタル署名

AliceがBobから公開鍵を教えてもらう時、それが改ざんされていないことを検証したい。公開鍵も電子データで贈る以上はビット列であるから、つまりは「メッセージが改ざんされていないことを確認する」技術が必要。
「メッセージ認証コード(MAC)」でハッシュ値を使うHMACの場合は、事前に共有しておいた鍵を使ってメッセージのハッシュ値を生成し、それをメッセージと共に相手に送る。相手も同じ手順でメッセージ本体に対してハッシュ値を生成し、一致していればオッケー。ただし、これには鍵をどうやって安全に共有するかが課題となる。
もう一つが「デジタル署名」。AliceからBobにメッセージを送信するとき、メッセージに対して「デジタル署名」を付けるシーンを想定すると、
+ AliceはAliceの秘密鍵を使ってメッセージのハッシュ値を暗号化し、それを「署名」としてメッセージと共にBobに送信。
+ BobはAliceの公開鍵を使って「署名」を復号化し、メッセージのハッシュ値を比較する。一致していればオッケー。

ここでは公開鍵暗号での鍵ペアの数学的な対称性が活用されている。
メッセージを暗号化する場合と、デジタル署名を作成する場合とで受け手・送り手がそれぞれの秘密鍵・公開鍵のどちらを使うのかが反転している点に注意する。
: メッセージの暗号化 : Alice(Sender)が、Bob(Receiver)の公開鍵を使って暗号化し、Bob(Receiver)はBob(Receiver)の秘密鍵を使って復号化する。
: メッセージのデジタル署名 : Alice(Sender)が、Alice(Sender)の秘密鍵を使ってデジタル署名を作成し、Bob(Receiver)はAlice(Sender)の公開鍵を使って検証する。

よって、メッセージ本体の暗号化とデジタル署名の両方を使いたい場合は、Alice(Sender)はBob(Receiver)の、BobはAliceの、それぞれの公開鍵を貰っておく必要がある。

* その公開鍵は信用しても大丈夫？ : 証明書と認証局と公開鍵基盤(PKI)

公開鍵暗号を使ってメッセージの機密性を確保し、デジタル署名でもって改ざんチェックをしたい。それには公開鍵をGETしなくちゃいけないんだけど、メモリーカードなり電子メールなりURLからのダウンロードなりでGETしたBobの公開鍵、これ本当にBobのなの？

これを保証するための技術の一つが、「なら、公開鍵に対してさらに信頼できる筋からのデジタル署名をつければよくね？」という視点で作られた「公開鍵証明書(Publick Key Certificates; PKC)」。単に「証明書(Certificate)」とも呼ばれる。
じゃぁ「信頼できる筋」って何者よ、ということで編み出された概念というか主体が「認証局(Certification Authority or Certifying Authority; CA)」。

Bobの公開鍵証明書には、Bobの名前やメールアドレスなど個人情報＋Bobの公開鍵が書かれている。で、それに認証局の秘密鍵で作成された「デジタル署名」がセットになる。デジタル署名は秘密鍵で作成され公開鍵で検証される。認証局は、自分の公開鍵を入手可能としておく。で、Aliceは、認証局の公開鍵を使うことでBobの証明書のデジタル署名を検証し、めでたくBobの公開鍵をGETできる。

・・・いや、じゃぁ認証局の公開鍵はどうやって検証すればいいのさ？
というときには、さらに上位の認証局がその公開鍵のデジタル署名を作成し、証明書とする。
・・・なら、その上位の認証局の公開鍵を検証するには？
・・・という感じで切りがなさそうなんだけど、まぁVerisignなどの大手企業なり、自社内で独自に構築した認証局なりが「ルートCA」、つまり「この認証局の公開鍵だけは無条件で信じてくれ～！！」として存在することになる。

証明書の書式とか、認証局の連鎖とか、もろもろの規格の総称が「公開鍵基盤(Publick Key Infrastructure; PKI)」。
実際の規格は、団体や企業などが中身を決めちゃってもよくって、RSA社が定めているのが「PKCS(Public Key Cryptography Standards)」。RFCにもPKI関連の文書がある。
"PKCS#12"とか、頭に「PKCS#」が付いてる番号などがPKCS。OpenSSLとかPGPとかSSLとかで証明書とか公開鍵とか秘密鍵とかをやり取りするときに、そのデータフォーマットを規定してたりするので、メッチャ頻出する。

代表的なのはggrks. PKCSでWikipediaでも漁ってろ。あと"X.509"っつーのも証明書の規格。PKCSとの関連についてはWikipedia漁れ、ggrks.

世界的に有名なルートCAの証明書は、大抵WebブラウザとかOSに含まれてたりするので、特に手動でGETする必要はない。実験で使うオレオレ証明書とか、社内独自に構築した認証局の証明書などは手動でGET + OSなりWebブラウザにインポートしなくちゃダメ。

クライアントプログラムを作る上では、ちゃんと「証明書破棄リスト」(Certificate Revocation List; CRL)もチェックするようにしましょう。

* 秘密鍵も、念のため暗号化しておきたい：鍵の保管

秘密鍵を平文のまま保存しておくのはやっぱり怖い。
ということで、大抵はPBE(Password Based Encryption)で暗号化・復号化してる。

考え方としては、
+ メッセージ(=Contents)を暗号化する鍵が必要だ(Contents Encryption Key; CEK)。
+ まぁ対称鍵なり公開鍵ペアの秘密鍵なりをCEKとして使うとしておく。
+ で、CEKも暗号化して保存しておきたい。
+ とゆーことで、鍵を暗号化する鍵(Key Encryption Key; KEK)が必要だ。

ということで、KEKの実現方法の一つがPBE。乱暴にまとめると、人間が覚える「パスフレーズ」のハッシュ値とランダムなソルト(salt)を組み合わせたのをKEKとして、この鍵でCEKを対称暗号で暗号化しちゃう。
こうしておけば、例えば秘密鍵を保存しておいたHDDを盗まれたとしても、そのままでは使えず、秘密鍵を復号化するためのパスフレーズを知っていないとダメということになる。

もちろんPBEを使うかどうかはあくまでも秘密鍵を保管するユーザーの好みになるので、パスフレーズ無しでそのまま保存することも可能。まぁ、バッチ処理などでパスフレーズ無しで使いたい時以外は、大抵はPBEかけて保管しておきましょー。

* 誰を信用するのか、決めるのはオレだ！ : 世界を信用できない時はPGP

メッセージ本体の暗号化やデジタル署名の検証に必要な公開鍵。で、公開鍵が「本当に所有者のものなのか？」を証明する仕組みがPKIな訳ですが、そもそも戦争やスパイ合戦などの場面で、「無条件で信用しないとPKIが成り立たないルートCAすら信用できない」という状況にも対応できるようにしたのがPGP。

非常に乱暴にまとめると、「オレの信じる公開鍵がルートCAだ！」という思想をベースにしていて、自分の所有する公開鍵に対して「この公開鍵はオレの中でのルートCAに等しい！」とか、「この公開鍵自体は信用できるけど、他の公開鍵をデジタル署名できるルートCAほどには信用できない」などランク付けできるようになってる。
PKIの認証局では、企業なり政府なり社会的に周知されている団体が認証局のチェインを形成するが、それに依存しないPGPの場合は「知り合い・友達」の公開鍵と、それによるデジタル署名が信用のネットワークを形成する。

デメリットとしては、公開鍵の管理をある程度手動で行わないとならない点。「Aさんがデジタル署名してくれた公開鍵は無条件で信用できる」とか、「BさんとCさんの両方がデジタル署名してくれた公開鍵なら信用できる」とか、ランク付けを手動で管理しないとダメという点。

勿論、商用製品になればそうした管理を一極集中したりある程度自動化してくれるので、組織的に導入するならそうした商用製品を使ってもOK。

規格としてはOpenPGP、フリーな実装としてはGnuPGPがあり、商用製品としては 2002年 - 2010年まで PGP Corporation から提供されていた。2010年にPGP Corporation はSymantec に買収され、Symantec製品に統合された模様。

- The Leader in File Encryption Software, Hard Drive Encryption, and Enterprise Security - PGP Corporation
-- &pre(){http://www.pgp.com/} -> 2010年5月に Symantec に買収 : https://internet.watch.impress.co.jp/docs/news/365570.html
- 現在は OpenPGP が各種PGP関連情報を集約しているので、こちらを参照したほうが良さそう。
-- https://www.openpgp.org/
- The GNU Privacy Guard - GnuPG.org
-- http://gnupg.org/

* PGPはメンドクサイ、でも公開鍵で、メールを手軽に暗号化したりデジタル署名したい：S/MIME

PGPだと公開鍵の管理とかがメンドクサイ。もう普通のルートCAを信用しちゃっていいから、とにかく公開鍵使ってメール暗号化＋デジタル署名をしちゃいたい、というのがS/MIME。
公開鍵でメッセージ暗号化＋デジタル署名という組み合わせ自体はPGPと一緒で、公開鍵を信用する仕組みが違う。PGPは自分たちで誰を信用するのかを決定するが、S/MIMEの場合はPKIを活用してルートCAを頂点とする認証局のチェインを信用する。

詳細はggrks.
- 【コラム】最新IT用語解説 (23) GnuPG＆S/MIME(The GNU Privacy Guard＆Secure/Multipurpose Internet Mail Extensions) | エンタープライズ | マイコミジャーナル
-- http://journal.mycom.co.jp/series/ityougo/023/
- S/MIMEでセキュアな電子メール環境をつくる！
-- http://www.atmarkit.co.jp/fsecurity/special/04smime/smime01.html
- 適当メモ - maple4estry - >> Mozilla Thunderbird で S/MIME を使った電子署名と暗号化をしてみる
-- http://www.geocities.jp/maple4estry/smime.html
- Latest topics > ThunderbirdでS/MIMEのテスト - outsider reflex
-- http://piro.sakura.ne.jp/latest/blosxom/mozilla/thunderbird/2008-08-28_smime.htm