2019-06-24 Updated: 2020-08-06

暗号技術入門(新版)

本書を読むきっかけ

普段の業務で、「APIにアクセスしているクライアントがTLS/1.2をサポートしているかどうか、また利用可能なCipherSuiteを教えてください」と連絡がきた。
あれ？どう調べていいか全くわからない…となってしまったので、SSL/TLSをしっかり理解するためにまずは家に積読されていた暗号技術入門を読むことに。
これをきっかけに暗号周りの技術的な基礎をしっかりと学びなおそうと思います。

全体の構成

暗号技術入門は全体で3部構成になっていて、1部は共通鍵暗号・公開鍵暗号・ブロック暗号などの暗号技術、暗号アルゴリズムについて詳しく説明されています。
2部では認証について記載されています。認証とは、ダウンロードしたファイルが正しいものかどうか？このメッセージを書いたのは誰か？などの本物かどうかを確認できる仕組みです。一方向ハッシュ関数・メッセージ認証コード・デジタル署名・証明書について詳しく説明されています。
3部では鍵とは一体何なのか？など、普段疑問に思わないところを深掘りしています。とてもおもしろい部分ではあります。

ちなみに暗号技術入門は第3版が出ています。こちらはブロックチェーンなど比較的新しい技術にも言及しています。あとで読む予定。

1部暗号

1章は暗号技術をさらっとまとめていて全体を把握するようにしています。

2章は古くから伝わる暗号の歴史を紐解いています。歴史に興味のある人は読むとおもしろいかもしれませんね。

3章から本格的な暗号技術を見ていきます。と言っても対称暗号(共通鍵暗号)はあまり出番がなさそうですね…CipherSuiteとしてDES, 3DES, AESなどは出てくるので名前を覚えておくというのと、今後どの対称暗号を利用すればよいかをわかっておけばよいでしょう。(今後利用するならAESがよいと記載されています)
共通鍵暗号で問題になるのが、「鍵配送問題」というもので、共通鍵暗号なのでお互い共通の鍵を使うわけですが、その鍵をどうやって共有するか？共有する際に誰かに盗み取られないか？という問題です。これを解決するために「鍵交換プロトコルを利用する」方法と「公開鍵暗号方式を利用する」方法など複数あります。こういった問題が含まれているということも知っておくとセキュリティリスクを考える上で参考になります。

4章ではブロック暗号というあまり馴染みのないものです。といってもDES, AESもブロック暗号で、固定長ビットの平文しか暗号化できないのです…任意の長さの平文を暗号化するにはブロック暗号を繰り返し使う必要があったのです。そのブロック暗号を繰り返す方法のことをブロック暗号のモードといいます。モードの種類でCBCは聞いたことあるかもしれませんね。

5章ではやっとなじみのある公開鍵暗号方式が出てきます。まずはじめに先ほどの対称暗号を利用するときに問題になる「鍵配送問題」について触れ、その解決方法を4つ紹介しています。
次に公開鍵暗号方式の仕組み、通信の流れ、そして公開鍵暗号方式だけでは解決できない問題を提示しています。
公開鍵暗号といえばSSHの鍵を作成するときに利用される暗号化方式ですね。id.rsaが秘密鍵でid.rsa.pubが公開鍵です。公開鍵をログインしたいサーバーに配置してパスフレーズを入力してログインするのが公開鍵認証です。パスワード認証よりはセキュアですね。
鍵作成時にパスフレーズを入力しなければ、毎回パスフレーズなしでSSHログインできるので、よくログインするサーバには必ず公開鍵を置いておきます。本当に便利ですよね。ただ、そんな便利な公開鍵暗号方式にも欠点があり、暗号に利用する公開鍵が本当にその人が作った公開鍵なのかどうかがわからないという問題があります（公開鍵の認証）。情報を盗み取りたい人が作成した公開鍵で暗号化してしまうと、盗み取りたい人が復号化できてしまうという問題があります（man-in-the-middle攻撃）。それを解決するのが次の6章で紹介されるハイブリッド暗号システムです。

6章では対称暗号と公開鍵暗号のそれぞれの問題点を解決するためのハイブリッド暗号システムの仕組みを紹介しています。
まずそれぞれの暗号方式の問題点をまとめています。

対称暗号方式
- 鍵配送問題
公開鍵暗号方式
- 対称暗号に比べて処理がずっと遅い
- man-in-the-middle攻撃に弱い
  ハイブリッド方式は対称暗号方式の鍵配送問題と公開鍵暗号の処理の遅さを解決する方法です。（man-in-the-middle攻撃に関しては認証の問題で第2部で解説があります）

ハイブリッド暗号方式は

メッセージは対称暗号で暗号化する
対称暗号の暗号化で使うセッション鍵は擬似乱数生成器で生成します
セッション鍵は公開鍵暗号で暗号化します
公開鍵暗号の暗号化で使う鍵は、ハイブリッド暗号システムの外部から与えます

という仕組みで成り立っています。
公開鍵認証方式の遅さを暗号化するデータを小さくすることで補っており、大量データの暗号化は速い対称暗号方式で暗号化するというメリットを最大限に利用する暗号化方式です。

2部認証

認証とは何かによって対象(データ)が正しいということを確認することです。
2部は7,8,9,10章から成り立っています。

7章ではデータが正しいことを証明するのに利用されている一方向ハッシュ関数を学びます。Webサイトからデータをダウンロードする際に付いている64文字の文字列はこの関数で生成されています。64文字の文字列はこの関数で生成されています。64文字の文字列はこの関数で生成されています。64文字の文字列はこの関数で生成されています。64文字の文字列はこの関数で生成されています。64文字の文字列はこの関数で生成されています。一方向ハッシュ関数では改竄は防げるものの、なりすましを防ぐことはできません。

8章ではメッセージ認証コードについてです。
メッセージ認証コードを利用すると、先ほどの一方向ハッシュ関数では防げなかったなりすましを防ぐことができます。
メッセージ認証コードは送信者と受信者が共有する鍵とメッセージを元にして固定ビット長の出力を計算する関数です。なので、メッセージ認証コードは鍵に依存した一方向ハッシュ関数と考えると理解しやすいです。
データを送った人、データを受け取った人それぞれで共有鍵を利用しMAC値を算出、同じだったら認証成功というわけです。比較的シンプルですが共有鍵を利用しているので、鍵配送問題が起こります。鍵配送には3章に記載の鍵交換プロトコルなどを利用します。
メッセージ認証コードはIPSecやSSL/TLSなどで用いられています。
HMACという名前を聞いたことがあるかもしれません。HMACは一方向ハッシュ関数を用いてメッセージ認証コードをさ構成する手法です（RFC2104で定義されています）。HMACの具体的な手順は割愛しますが、いかにも暗号技術と言う手順で作成しているので、興味のあるかたはぜひ！ https://www.ipa.go.jp/security/rfc/RFC2104JA.html

メッセージ認証コードで解決できない問題

第三者に対する証明ができない
第三者がMAC値を検証するには共通鍵を知る必要がある。仮に教えたとしても、そのMAC値を作ることができる人を特定することはできない（共通鍵を知っている人なら作成可能）
これを解決するには9章でお話しするデジタル署名を利用します。
否認防止ができない
ボブがMAC値付きのメッセージを受け取ったとします。ボブはアリスと共有している鍵を使って計算したものであれば、これがアリスからだとわかります。
しかしこれを第三者に対して証明することができません。つまり、アリスは「私はそんなメッセージを送っていない」と第三者に対して主張できてしまうことになります。このような主張のことを否認といいます。MAC値からではボブとアリス、どちらの主張が正しいのか判断できません。このような問題にもデジタル署名を使えば、否認防止が可能になります。

9章はデジタル署名です。
メッセージ認証コードで解決できなかった問題が二つありました（第三者へ証明できない、否認防止ができない）。
それらの問題は、アリスとボブの間で鍵を共有する必要があったためです。片方が送ったデータをもう片方でも正しいMAC値が計算できてしまうため、どちらが送ったを第三者に証明することができません。
同じ鍵を使っていることが問題であるなら、別の鍵を使うことにするのはどうでしょうか？アリスはメッセージ送信時に自分だけが知っているプライベートな鍵を使って「署名」を作成します。受信者のボブは別の鍵（公開鍵？）を使ってその「署名」を検証する。ボブの鍵では「署名」を作成できないが、鍵を使って検証することはできる。
こうすることで、改竄の検出、なりすましの検出、否認防止が可能になります。これがデジタル署名です。

10章は証明書です。公開鍵認証が相手を特定する上で、また鍵を共有する上で有効であることはわかりました。しかし、自分が持っている公開鍵が正しいものであるかどうかがわからないと、man-in-the-middle攻撃にやられてしまいます。公開鍵が正しいものかどうかを証明するものがこの章で説明する証明書になります。
証明書といえばやはりSSL証明書ですね。CSR作成して認証局に送って証明書を発行してもらうみたいな作業を訳もわからずやっていたのですが、なぜその手順を行うのかしっかり理解したいです。

証明書とは何か

証明書（公開鍵証明書）は公開鍵に対して、認証局（CA: certification authority）によるデジタル署名が行われているものです。

認証局とは何か

認証局とは「確かにこの公開鍵はこの人のものである」と認め、デジタル署名を作成できる人や組織のことです。つまり認証局はその公開鍵（証明書）の持ち主を保証する機関であると言えます。

証明書を使うシナリオ

証明書を利用するシナリオ（SSL証明書など）で証明書の役割を理解する

登場人物

ボブ（メッセージ受信者）
アリス（メッセージ送信者）
トレント（認証局）

シナリオ

ボブがキーペアを作成する
ボブが認証局トレントに自分の公開鍵を登録する
認証局トレントがボブの公開鍵に自局（トレント）の秘密鍵でデジタル署名をして証明書を作成する
アリスは認証局トレントのデジタル署名がついたボブの公開鍵（証明書）を入手する
アリスは認証局トレントの公開鍵を使ってデジタル署名を検証、ボブの公開鍵が正しいことを確認する
アリスはボブの公開鍵でメッセージを暗号化しボブへ送信
ボブは暗号化されたメッセージを自分の秘密鍵で複合化しアリスのメッセージを読む

基本的には公開鍵認証であるが、信頼できる第三者（認証局）のデジタル署名（秘密鍵での暗号化）によって公開鍵の信頼性を保証している。
このシナリオの2番がSSL証明書作成時のCSRに相当する。

証明書関連の規格

SSL証明書を作成したことがある人なら聞いたことがあるX.509や公開鍵基盤（PKI）などの解説も丁寧にされており、しっかり理解しておきたい。

証明書に対する攻撃

問題のなさそうな証明書の仕組みにもまだ攻撃できる余地があり、どういった攻撃が可能かの紹介がされています。

公開鍵の登録前を攻撃

認証局にデジタル署名されてしまうと攻撃しづらくなるので、デジタル署名される前の公開鍵を攻撃します。公開鍵をすり替えるなどの方法があります。

デジタル署名を依頼する時の本人情報を攻撃対象者と似せる

コンピュータには別人と認識できるような情報でも人間には別人に見えないような情報でデジタル署名を依頼し、証明書の情報を誤認させます。正しくはBobだがBOB、BObなど、パッと見あっているような情報で登録するということです。

認証局の秘密鍵を盗み出す攻撃

認証局の秘密鍵を盗むのは困難でしょう。盗まれないように認証局もセキュリティを万全にしているはずです。万が一、認証局の秘密鍵が盗まれた場合は、CRLを使って利用者に通知する必要があります。

証明書Q&A

Q&Aで紹介されている内容は証明書の必要性を説明してくれていて、モヤモヤを解決してくれる。いくつか紹介しよう。

Q. 証明書がなぜ必要なのか？
A. 信頼できない経路で公開鍵を入手した場合、man-in-the-middle攻撃が可能になります。その公開鍵が本当にその人が作成した公開鍵と保証できないからです。
認証局から証明書を入手すると、man-in-the-middle攻撃の可能性を減らすことができます。なぜなら証明書に含まれている公開鍵には認証局のデジタル署名が付いているため、すりかえることが事実上できないからです。
直接手渡しするなど信頼できる経路で公開鍵を受け取る場合は認証局は不要です。

信頼できる公開会議を入手できるなら認証局は不要
信頼できる認証局の公開鍵を持っていて、認証局の本人確認を信頼するなら、その認証局の発行した証明書によって入手した公開鍵は信用できる。

Q. 認証局はどうやって信頼するのか？
A. 「信頼」がどのように生まれるかという本質的な問題であって、答えとしては信頼できそうだからというもの。信頼できそうな認証局であれば信頼できるということだ。

証明書まとめ

証明書のパートだけ長くなってしまった。もともとSSL/TLSをしっかりと理解したいという欲求から本書を読み始めてしまったせいもある。
証明書は信頼できる第三者のデジタル署名がついている公開鍵であり、標準規格はX.509である。
認証局の役割、公開鍵基盤（PKI）などを学びました。

3部鍵乱数応用技術

3部ではまず鍵について再考する。次に乱数について深掘りする。
その後は暗号技術の組み合わせのPGP、もともとの目的であったSSL/TLSについて記されている。
最後にまとめの章がある。

11章鍵

鍵とは何か？

あらゆる暗号技術には必ず鍵と呼ばれる大きな数が必要になる。
重要なのは鍵そのものの大きさよりも鍵空間の大きさ、すなわちどれくらいの数の鍵が生成可能かということ。
その大きさはビット長で決まる。

鍵の価値
対称暗号（共有鍵暗号）を利用して、平文を暗号化したとする。鍵を盗まれてしまった場合、その鍵を利用して暗号化された平文の内容がわかってしまう。
鍵が他人に渡ってしまう＝平文が他人に渡ってしまうということ、すなわち鍵は平文と同じ価値があるということである。
暗号アルゴリズムと鍵
暗号アルゴリズムを秘密にすることで情報の機密性を守ろうとするのは危険。暗号アルゴリズムではなく鍵を秘密にすることで情報の機密性を守るのがよい。

さまざまな鍵

鍵の用途
対称暗号（共通鍵暗号）の鍵や、公開鍵暗号の鍵はデータの気密性を保つための鍵である。メッセージ認証コードやデジタル署名で使われる鍵は、認証を行うための鍵である。

鍵を管理する

鍵を作る
- 乱数から鍵を作る
- パスワード（パスフレーズ）から鍵を作る
鍵を配送する
- 鍵配送問題
  - 解決方法
    - 鍵の事前共有（pre-shared key）
    - 鍵配布センターを利用する
    - 公開鍵暗号
    - Diffie-Hellman鍵交換
鍵を保存する
- 安全な場所に保存する
- 暗号化して保存する
  - 鍵を暗号化するための鍵が必要（KEK）

Diffie-Hellman鍵交換

Diffie-Hellman鍵交換とは
鍵配送問題を解決する方法の一つ。
他人に知られても良い情報を交換するだけで共通の秘密の数を作り出すという方法。
Diffie-Hellman鍵交換の手順
アリスとボブが対称暗号の鍵を共有する場合

アリスはボブに対して2つの素数P, Gを送信する
Pは非常に大きな素数でなければならない。Gは生成元と呼ばれる数でPに依存する。
アリスは乱数Aを用意する
Aは1からP-2の間にある整数。Aはアリスだけの秘密の数。
ボブは乱数Bを用意する
Bも1からP-2の間にある整数。Bはボブだけの秘密の数。
アリスはボブに対してG^A mod Pという数を送信する
これは他人に知られても構いません
ボブはアリスに対してG^B mod Pという数を送信する
これは他人に知られても構いません
アリスはボブから送られてきた数をA乗して、mod Pを取る
これが鍵になる。
アリスの計算
(G^B mod P)^A mod P
= G^BxA mod P
= G^AxB mod P
ボブはアリスから送られてきた数をB乗して、mod Pを取る
アリスから送られてきた数
G^A mod P
をB乗してmod P
(G^A mod P)^B mod P
= G^AxB mod P

6で得た数と７で得た数は同じ、なので共通の鍵を得たことになる。

イブ（盗聴者）は鍵を計算できないのか？
イブが知り得る数はP, G, G^A mod P, G^B mod Pの4つ。
この4つの数からG^AxB mod Pを計算することは極めて困難だと考えられている。
もしAかBどちらかでもわかればG^AxB mod Pを計算することは可能。
しかしG^A mod Pから数Aを簡単に計算するアルゴリズムはまだ発見されていない。
有限体の上の離散対数問題と呼ばれている。