担当：横山

目次

• 暗号学者の道具箱
• 暗号技術のフレームワーク化
• 暗号技術は圧縮技術
• ビットコインの例
• 完全な暗号技術を夢見て

暗号学者の道具箱

いくつもの暗号技術が今現在のインターネットの安全性を支えている。
このうち特に重要なのが６つの技術

• メッセージ認証コード
• 一方向ハッシュ関数
• 対象暗号
• デジタル署名
• 公開鍵暗号
• 疑似乱数生成器

各技術の相関図

メッセージ認証コード

Message Authentication Code (略称 MAC)

• メッセージが改ざんされていないことを保証
• メッセージが期待された通信先から来たことを保証

送信者と受信者が共有鍵からMAC値を作成することで、オリジナルメッセージが、鍵を共有している送信者から受信したものであることを確認する。

一方向ハッシュ関数

データの正真性を確保する。

• オリジナルデータを一方向ハッシュ関数にかけると固定長のハッシュ値が生成される。（高速化）
• オリジナルデータが違えばそこから生成されるハッシュ値も異なる
• ハッシュ値からオリジナルデータは算出不可 => 暗号化ではなく、あくまで正真性の確保
• 衝突耐性
  • 弱衝突耐性:あるハッシュ値を持つ別のデータを探すのが困難
  • 強衝突耐性：ハッシュ値が一致するような異なる２つのデータを探すのが困難

対称暗号

別称：共有鍵暗号、秘密鍵暗号

最初に鍵ペアを作成。（認証局登録・で正当性を証明）

公開鍵暗号方式の通信の流れ

1. 送信者は受信者が公開している公開鍵でデータを暗号化して送信
2. 受信者は受け取ったデータを秘密鍵で復号化(秘密鍵は受信者が所持）

デジタル署名 (digital signature)

• 送信者はオリジナルデータを秘密鍵で暗号化したものとオリジナルデータをまとめて送信
• 受信者は受信した署名を送信者の公開鍵で復号化し、受信したメッセージと比較
  →比較して一致すれば、そのデータが想定する送信者からもらったデータだと判断できる。
  ※メッセージに一方向ハッシュ関数をかませたものを暗号化するケースもある。

公開鍵暗号

暗号化の鍵と復号化の鍵を別々に管理する。
1. 受信者は公開鍵・秘密鍵を用意しておく
1. 送信者は受信者から公開鍵をもらう
1. 送信者は公開鍵でデータを暗号化して送信
1. 受信者は受信したデータを秘密鍵で復号化
(3)で送信するデータが盗聴されても第三者は復号化用の秘密鍵を持っていないので解読されずに済む。

乱数

鍵・鍵ペア作成等の際に乱数を活用する。

乱数：無作為性・予測不可能性・再現不可能性が必要 → 乱数を生成するソフト「疑似乱数生成器」

※マシンが生成するものは真の意味では乱数ではないので「疑似」が付く。

種を疑似乱数生成器に渡して疑似乱数列を出力する

暗号技術のフレームワーク化

ここまでに紹介したいくつかの技術は役割ごとにブロックになっており、差し替えができる

→ある部分のアルゴリズムがハッカーに突破された場合その１か所のアルゴリズムさえ改めれば、その他の仕組みは変えずに運用継続できる。

暗号技術は圧縮技術

暗号化技術は見方を変えると「圧縮技術」と言える。

=> 長い平文の機密性を保つ・検証するのはコストが高い

技術	目的
鍵	機密性
ハッシュ値	正真性
認証子（MAC値やデジタル署名）	認証
乱数	予測不可能性

ビットコイン

ビットコイン(Bitcoin)という仮想通貨・決済システムを例に暗号化技術が具体的にどのように活用されているかを紹介

中本哲史（なかもとさとし）という人物が投稿した論文をもとに２００９年から運用開始。（日本は禁止）

おおまかな仕組み

• ユーザーはウォレットというアプリを介してビットコインに対して通信を行う。
• ビットコイン本体は取引が誰と誰の間で行われているのかを保存する
• ユーザーにはトランザクションごとにアドレスが割り振られる（アドレスはプライバシー確保のために毎回変わる）

単一トランザクションのフロー

ブロックチェーン

ビットコイン上で行われた全トランザクションを記録しておく公開取引簿

ヘッダ

値H?は前回のブロックのヘッダから生成したハッシュ値
T?は自分のブロックのトランザクション群のデータから生成したハッシュ値
ナンス(使い捨てのランダムな値)やタイムスタンプ等も含まれる

ブロックチェーンの分岐

全世界のユーザーがビットコインを使うならばブロックの追加リクエストは
24時間常に同時多発的に存在する。→ P2Pネットワークによる承認
全ての分岐は一時的に保存されるが、一番長く伸びた分岐を正として承認する

採掘 (mining)

前頁までの説明にある「ブロック」の追加は世界中の miner （採掘者）達の手によって行われている。

→ ブロック追加が成功すると報酬(block reward / 2015年時点で75万円)と、含まれるトランザクションの手数料をもらえる。

ブロックチェーンは改ざんされない？

厳密に言えば改ざんされるが、改ざんされたであろう分岐は承認されない仕組み

前頁の例で、たとえばブロック１のトランザクション１－１の金額を書き換える

→ ブロック2のヘッダの内容が変わる

→ ブロック３も変わる・・・

という具合で後ろのブロックを接続していくことが困難になる

→正しい値を積んで伸ばしているノードよりも長い分岐を作れない

→承認されない（承認システムはノードの長さにで正否を判断するため）

単一トランザクションのフロー

完全な暗号技術を夢見て

量子暗号　( Quantum cryptography)

1980年代にベネットとブラサールによって考案された量子鍵配送を示す。
「暗号」という名称だが、厳密には暗号を直接構成するのではなく、盗聴が不可能な通信を構成する技術。

量子の以下の２つの特性を利用する
1. 光子の変更方向を正確に測定することが原理t系に不可能
1. 測定することで光子の状態が変化する

補足　そもそも量子って何？

原子より大きい世界では、「物質」と「状態」をはっきりと区別できます。
（　「海水」という物質に対する「波」）
しかし原子より小さな世界「電子」には事情が異なる。
電子はエネルギーを持った波動だが、対応する物質がない。
→波動性と粒子性を併せ持っているものを量子と呼ぶ。（電子・光子など

左の図の電子が陽子の中心点から等距離を超高速でグルグル回ると右の図のように見える

→左図のように電子を粒ととらえて位置を決めてしまうと、電子がどのように動いているのかを特定できない

右図のように電子がどのように動いているのかの軌跡を基準に考えると、電子がどこに居るのかを特定できない

ハイゼンベルグの不確定性原理「粒子の位置と運動量を同時に確定することはできない」

量子論を通信技術に応用する

不確定性原理（位置と運動量は同時に確定できない）と、「量子は観測することにより発生する相互作用で状態を変える」という観測不能性を応用して、実際には偏光・スピン・位相等の状態を信号として送り込む。

量子コンピュータ

量子が同時に複数の状態を持つことができる特性を利用した超高速のマシン

2011年5月11日、D-Wave Systemsは「世界初の商用量子コンピュータ」を謳ったD-Wave Oneを発表

→ ブルートフォースアタックに要する時間を大幅に短縮できる！
　　既存の暗号技術が突破される？

→ 前ページまでで紹介していた量子暗号は、特性上、盗聴自体を検知できるので量子コンピュータを使った不正行為にも耐えられる。

→ 耐量子暗号・ポスト量子暗号と呼ばれる

暗号技術が完全になっても人間は不完全

理論が完全でも現実は不完全

たとえば一般的な公開鍵の認証

認証局の公開鍵に対して「これを信用する」というユーザーの判断が発生する。

防御は完全ではければならないが攻撃は一点を破ればよい

まとめ

暗号化技術が日進月歩で更新されているのと同じように暗号を破る技術も更新されている。

実装者として自分が開発に関わる暗号化・認証のフロー・仕組みに対して興味を持ちセキュリティに対する意識を高く持とう。

参考書籍

結城浩(2015)『暗号技術入門 第3版 秘密の国のアリス』SB Creative 446pp.
ISBN978-4-7973-8222-8
第15章 暗号技術と現実社会(p390-p411)

担当：大辻

目次

• 歴史
• 概要
• プロトコル
• 暗号スイートの構成要素

SSL/TLSの歴史

SSL 1.0

1994年 Netscape Communications社が開発

設計レビューの段階で脆弱性が発見される

SSL 2.0

1995年 Netscape Communications社が発表

2011年 いくつかの脆弱性が発見され、使用禁止に

SSLには後方互換性があり、SSL 3.0発表後も2.0を利用することはできた

SSL 3.0

1996年 Netscape Communications社が発表

2014年10月 仕様上の脆弱性が見つかる

2015年6月 使用禁止に

TLS 1.0

1999年 RFC 2246としてインターネット標準化された

SSL 3.0をベースに細かい仕様が変更されている

ネゴシエーション時のバージョン番号は3.1

TLS 1.1

2006年 RFC 4346として制定

AES対応や新しい攻撃手法に対する強化

ネゴシエーション時のバージョン番号は3.2

TLS 1.2

2008年 RFC 5246として制定

いくつかのアルゴリズム追加

ネゴシエーション時のバージョン番号は3.3

TLS 1.3

2017年2月 そろそろドラフト最終段階

ネゴシエーション時のバージョン番号は3.4(予定)

プロトコル概要

三つの脅威

1. 盗聴
2. 改ざん
3. なりすまし

から守る

通信経路を暗号化するのでHTTP以外でも利用できる

二つのプロトコル

• ハンドシェイクプロトコル
• レコードプロトコル

五つの要素技術

• 鍵交換
• 公開鍵暗号
• 共通鍵暗号
• ブロック暗号モード
• メッセージ認証コード

ハンドシェイクプロトコル

ClientHello →

対応しているアルゴリズムの一覧を送信する

← ServerHello

最も安全性の高いアルゴリズムを選択して応答する

← (Certificate)

サーバ証明書(ルート認証局含む)をクライアントに渡す
Note: 証明書の検証、相手にしか読めない暗号文の作成が可能に

← (ServerKeyExchange)

鍵生成に必要なパラメータを送る

← (CertificateRequest)

クライアント証明書もよこしなさい

← ServerHelloDone

サーバのターン終了

(Certificate) →

クライアント証明書をサーバに渡す

ClientKeyExchange →

鍵生成に必要なパラメータを送る

(CertificateVerify) →

私は間違いなく証明書の持ち主です

ChangeCipherSpec →

アルゴリズムの確定

Finished →

クライアントからは以上です
Note: このメッセージ自体は暗号化されている

← Finished

サーバからも以上です
Note: このメッセージ自体は暗号化されている

レコードプロトコル

HTTP等のデータを共通鍵で暗号化して送受信するだけ

だけじゃないよ！

Note: 単純な暗号化だけでは盗聴しか防げない

認証アルゴリズム

相手は本当に証明書の持ち主か？

1. ランダムなデータを送信する
2. 署名されて返ってくる
3. サーバ証明書の公開鍵で検証する

そもそもサーバ証明書は本物か？

サーバ証明書自体は認証局によって署名されている

OSやブラウザにインストールされている認証局の証明書で検証可能

鍵交換アルゴリズム

プレマスターシークレットを受け渡す

• 鍵配送型
  送信者がランダムに鍵を生成し、相手の公開鍵で暗号化して送信する
• DH型(Diffie-Hellman key exchange)
  お互いに自分の秘密鍵と相手の公開鍵を利用して共通の鍵を生成する

マスターシークレットを作る

プレマスターシークレット ＋ ソルト
→
一方向ハッシュ関数
→
マスターシークレット(ClientHello/ServerHello時に生成されたランダム値をソルトとして使う)

マスターシークレットで鍵などを作る

• 対称暗号の共通鍵
• メッセージ認証コードの鍵
• CBCモードの初期化ベクトル

共通鍵暗号

レコードプロトコルで使う暗号

• ブロック暗号
  AES、 DES、3DESなど
• ストリーム暗号
  RC4

ブロック暗号モード

ブロック暗号にひと手間加える

同じ平文からは同じ暗号文が出力されるため、そのままだと鍵や平文の一部が予測されやすい

直前のブロックをXORするなどして安全性を高めるCBC、GCM、CCMなどがある

メッセージ認証コード

ハッシュ値による改ざん検出

• シーケンス番号
• 鍵
• 元データ

暗号スイート

五つのアルゴリズムの組み合わせ

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

まとめ

SSLの良いところ

• 色んなプロトコルへの水平展開
• 色んな環境での相互運用性
• 色んな暗号技術に対応

参考書籍

結城浩(2015)『暗号技術入門 第3版 秘密の国のアリス』SB Creative 446pp.
ISBN978-4-7973-8222-8
第14章 SSL/TLS(p364-p388)

担当：斎藤

目次

• ＰＧＰとは
• 他の秘密通信方式との違い
• 鍵の管理
• まとめ

ＰＧＰとは

PGP (Pretty Good Privacy, 「たいへんよいプライバシー」)は，Philip Zimmermann が開発した暗号ソフトウェア．

主な用途は，ファイルやメールの暗号化です．

また，署名やその検証も行えます．

一方，SSL/TLSやSSHと異なり，通信の暗号化はしません．

公開鍵暗号を使用しますが，その鍵の管理のために，認証局を設置せず，各利用者の責任で鍵を管理し，取得した公開鍵をチェックします．

そして，ハイブリッド暗号で暗号化されます．

メッセージまたはファイルは，セッション鍵と呼ばれる乱数の値を鍵として，対称暗号により暗号化され，そのセッション鍵は，受信者の公開鍵で暗号化されます．

PGPの別実装として，GnuPG (GNU Privacy Guard)があります．

こちらはGPL (GNU General Public License)に基づき無料で利用できます．

ターミナル(シェル)では，gpgというコマンドに，オプションをつけて実行．

他の秘密通信方式との違い

SSLなどとの違い: 

SSL/TLS (Secure Sockets Layer / Transport Layer Security) や，SSH (Secure Shell) のポート転送を用いて，メールサーバとの通信を暗号化することができます．

しかしそれでは，送信後のメールの配送や，サーバで保管されるメールについては，暗号化されません．

Bcc (Blind Carbon Copy)は，メールのヘッダに宛先が表示されませんが，これも配送は暗号化されませんし，サーバで保管された状態のメールは，暗号化されていません．

これらに対して，PGPは，必ずしも安全でない通信経路やサーバを介しても，メッセージの秘密を守るための仕組みを提供しています．

暗号化ZIPとの違い: 

パスワードつきのZIPファイル(暗号化ZIP)は，そのファイルごとにパスワードが設定されます．

しかし，何らかの理由でパスワードを変更したいと思っても，送付したあとには，できませんし，いくつも作るとなると，そのパスワードの管理が面倒です．

PGPの暗号化では，鍵(セッション鍵)が，受信者の公開鍵で暗号化されています．

したがってその安全性は，受信者の鍵の管理に依存します．

受信者の持つ秘密鍵は，パスフレーズを入力しないと使用できませんが，そのパスフレーズはあとで変更できます．

なお，暗号化ZIPでは，一つのファイルに対して，パスワードを知っている複数の人が復号できますが，PGPにおいても，複数の利用者が(それぞれの秘密鍵で)ファイルを復号できるような，単一のファイルを作ることは可能です．

S/MIMEとの違い: 

S/MIME (Secure/Multipurpose Internet Mail Extensions) は，メールの暗号化や署名についての規格ですが，そのデータフォーマットは，PGPと異なります.

S/MIME では，鍵や証明書を発行したりその正当性を保証したりするため，認証局を必要する．

秘密通信方式	暗号化
SSL/TLS	ポート転送
暗号化ZIP	fileごとにpwを設定
S/MIME

送信側はあらかじめ、受信側の公開鍵を受け取っておきます.

その上で、本文の暗号化にかかるわけですが、通常の文章のままで暗号化をすると効果が薄いので、メールを圧縮します.

圧縮は、gzipやcompressなど可逆のものならなんでも構いません.

ついで、セッション鍵とよばれる、一時的に利用する鍵を生成します.

この生成したセッション鍵で、圧縮後のメールを暗号化すると同時に、セッション鍵自体を受信側の公開鍵を使って暗号化します.

この結果、暗号化した本文と暗号化したセッション鍵が作成され、これを両方とも受信側に送ります.

受信側はこれを受け取った後、まず自分の秘密鍵を使ってセッション鍵を復号化します.

そして、復号化したセッション鍵を使用して、本文の復号化も行ないます.

最後に圧縮を展開すれば、本文が元通りに読めるというわけです.

鍵の管理

PGPの鍵は，公開鍵暗号系や，PKI (Public-Key Infrastructure, 公開鍵基盤) での考え方と，同じところもあれば，異なっているところもあります．

PGPを使うにあたっての原則は，次の5つです．

1. 暗号化には，受信者の公開鍵を使用．
2. 復号には，受信者の秘密鍵を使用．
3. 署名には，送信者の秘密鍵を使用．
4. 検証には，送信者の公開鍵を使用．
5. 秘密鍵を使用するとき，パスフレーズを入力．

鍵情報は，16進8桁(32ビット)であらわされる，「鍵ID」を指定するのが一般的です．

私の鍵IDは，0x3BDCC722です．

これが，“【ユーザー】”という「ユーザーID」に結びつけられています．

しかし，PGPでは，私以外の人が，私と同じユーザーIDの鍵ペア(公開鍵と秘密鍵のペア)を作ることができてしまいます．

ソフトウェアに手を加えれば，鍵IDも同じにすることができます．

そのようにして作られる可能性のある，偽造鍵と，正しい鍵とを区別するため，公開鍵の利用者はあらかじめ，公開鍵の正当性を確認しておきます．

通常は，fingerprint (「フィンガープリント」「指紋」「ハッシュ値」とも呼ばれます)を使います．

受け取った公開鍵からfingerprintを求め，それが，鍵の所有者が提示するfingerprintと一致していれば，正当な鍵とみなします．(fingerprintまで一致するような，鍵の偽造は，現実的にできません．もし万一そのようなことがあれば，むしろ，秘密鍵の漏洩を疑うべきです．)

公開鍵を正当なものと確認したら，その鍵に，自分の秘密鍵で署名をすることで，以後，安全に利用できるようになります．

またその公開鍵に信頼度を設定することもできます．このように鍵の正当性を確認するとともに，信頼度を設定し，その情報をやりとりするしくみは，web of trust (「信頼の輪」または「信頼の網」)と呼ばれます．

なお，生成した鍵ペアを含め，所有し管理する鍵の集合をkeyring (「鍵束」または「鍵輪」)といいます．

Linuxなどでは，~/.gnupgに保存されます．複数の計算機に，共通の(もちろん同じ鍵IDの)鍵ペアを持たせることも可能です．

運用のためのアドバイスを，以下に記します．

• 自分の秘密鍵のパスフレーズを，忘れないようにしましょう．
• 自分の秘密鍵のパスフレーズを，漏らさないようにしましょう．
• 暗号化して送りたいとき，公開鍵の正当性確認をきちんとしましょう．

まとめ

• 鍵を利用し暗号化することでデータのセキュリティを担保する
• 証明書を利用しなりすましや改ざんを排除する

参考書籍

結城浩(2015)『暗号技術入門 第3版 秘密の国のアリス』SB Creative 446pp.
ISBN978-4-7973-8222-8
第13章 PGP(p334-p360)