プロフェッショナルTLS＆PKI (Bulletproot TLS and PKI) 改題第2版を読む ①第1章

自身、SSL時代からTLSについてはただただユーザー・管理者として設定しているだけでした。が、さすがに昨今の事情を鑑みるに勉強しないといかんのではないか、と思い某所で発見した良書を読んでみたいと思います。

プロフェッショナルTLS＆PKI 改題第2版
https://www.amazon.co.jp/dp/490868619X?ref=ppx_yo2ov_dt_b_fed_asin_title

全く記憶力は自信が無いので(^^;　ここに学習メモを残します。
私自身はIBM i がコアスキルの技術者なのでIBMi タグもいれています。いずれIBM i でのTLS、、という記事も並行してまとめてみたいと思います。

TLS : Transport Layer Security

私がSEになってから長い事、SSL（Secure Sockets Layer）と呼ばれていましたが、近年では TLS（Transport Layer Security）の名称が普及しています。
ものすごくアバウトにはSSLの最新名称がTLS、でいいように理解しています。

TLSの4つの目標

TLSの目標は優先度順に以下の４つ

1.暗号学的なセキュリティ（cryptographic security）
TCP/IP通信する二者間での安全な通信を実現する。

2.相互運用性（interoperability）
それぞれのコンピューターでは異なるプログラマーが独自にプログラムやライブラリーを開発できること。
これら別々に開発されたプログラム間で同じパラメーターを使って暗号通信ができること。

3.拡張性（extensibility）
TLSが利用する要素技術（暗号、ハッシュ関数、etc.）をプロトコルから独立させ、新しい要素技術を都度利用可能とすること

4.効率性（efficiency）
コンピューター上で計算コストのかかる暗号処理を最小限にし、後続のセッションでの再計算を避けるキャッシュ方式を用意して、上記3点をすべて妥当なパフォーマンスで実現すること

暗号技術の目的3つ

また、（原書ではページが飛びますが、）TLSはじめ暗号化の目的は以下の3つと記載されています。

機密性 confidentiality：秘密が守られること
真正性 authenticity：本人であることの検証ができること
完全性 integrity：オリジナルのデータが改ざんされることなく転送されること

TLSの動作レイヤーはプレゼンテーション層（OSA7層モデル）

引用：OSI model

上記出典より引用

TLSはアプリケーション層（HTTP, SMTP, IMAP等）の下位レイヤーなので、アプリケーション単位でTLSの有効化・無効化が出来ます。

※原書にはSSL,TLSの歴史も興味深く書かれており、Netscapeなど懐かしい名前も登場します。最初のSSL2が1994年、RFC2246としてTLS1.0がリリース（標準化）されたのは1999年だそうです。TLS 1.1は2006年、TLS 1.2は2008年、そしてTLS1.3が2018年にRFC発行に至りました。TLS1.3はほぼ完全なプロトコルの書き換えとなっているようです。

暗号化に関わる要素技術

暗号化の１つ１つの機能？を実装するための技術は沢山あります。一例として鍵交換、署名、など
TLSで使われる代表的な要素技術の解説が以下です。

共通鍵暗号化方式（対象暗号方式）

送信者アリストと受信者ボブで同じ秘密鍵を共有しておき、文書（データ）の送受信の際、秘密が儀を使って暗号化・復号化を行う。

暗号システムは鍵以外の全てが攻撃者に掌握されたとしても安全でなければならない
（Auguste Kerchoffs）の主張
暗号化の強さのメジャーとしては鍵の長さが用いられる。

原書では続けて、暗号化方式２つの解説があります。

ストリーム暗号化方式 と ブロック暗号化方式

ストリーム暗号化方式

ストリーム暗号化方式は鍵ストリームというランダムなデータを作ります。そして鍵ストリームの1バイトと平文のデータの1バイトの排他的論理和を取り暗号化を行います。

暗号化鍵を持っていれば、排他的論理和を取る操作は可逆的に実行できるので平文の生成が可能です。

ストリーム暗号化の方式には古くは RC4 暗号化方式が使われていましたが、近年では安全ではない、という事で基本利用しません。近年のストリーム暗号化方式としては ChaCha20 Salsa20 などがあります。

ストリーム暗号化の例 RC4

RC4のしくみ＝排他的論理和による暗号化

排他的論理和、を久しぶりに見ました(^^　あまりに懐かしくて図も同じものを起こしてしまいました。

RC4は平文のデータと鍵ストリームの排他的論理和を求めて暗号文を作ります。
RC4は,
・鍵ストリームの各バイトがどの位置にあるかを攻撃者に予測されなければ安全だとみなせます。
・それでも、平文の特定部分を攻撃者が知っていたり予測可能だったりすると脆弱になる。たとえばHTTPリクエストを暗号化してもリクエストメソッドやプロトコルバージョン、ヘッダー名などは別な通信リクエストでも同様なので予測可能かもしれない。
・上記の脆弱性を補うために鍵ストリームは同じ鍵を使い回さないことが重要になる
・以上からストリーム暗号化方式では通信する2者間で共有して使う秘密鍵から通信の度に一回限りの鍵を導出してその鍵を使用する。

RC4の弱点は別章で解説があるようです。

ブロック暗号化方式

ブロック暗号化方式では、データをブロック単位で暗号化します。現在のブロック暗号化方式の多くは、ブロック長はを128ビット＝16バイトとしています。

原書にはブロック暗号化方式の図は無かったので作成してみました。（間違いあるかもしれません）

ブロック暗号化方式は
・変換変数、と言える。入力する平文をランダムに見える暗号文に変換できる。
・ほんの少し（例 1ビットだけ違う）ちがうデータでも大きく変わる暗号文に変換できる。
・ただし、ブロック長に足りないデータはそのままでは暗号化できない
・同じ平文に対しては毎回同じ結果が生成される（決定論的な暗号化方式）このため様々な攻撃方法が考えられる
・以上から、実際には暗号化利用モードと呼ばれる方式を利用して上記の弱点を補完している。

暗号化利用モードの副次的なメリットとしては認証機構の追加ができる事です。
ブロック暗号化方式は以下のような暗号化技術の基礎として使用されている。
・ハッシュ
・メッセージ認証コード（MAC）
・疑似乱数生成器
・ストリーム暗号化方式にも応用

現在最も利用されているブロック暗号化方式は AES(Advanced Encryption Standard)です。AESで利用できるブロック長は128ビット、192ビット、256ビットです。

パディングとは

ブロック暗号化の課題としてブロック長より短いデータをどう暗号化するか？という事があり、１つの方式として上図の様に送信・受信両社で取り決めた方法で余分なデータ（パディング） を追加する方法です。

上記の取り決めには
・受け取り側がパディングであることを識別できる
・何バイトがパディングであるか識別できる
を正しく特定できる必要があります。
TLSでは暗号化ブロックの末尾のバイトにパディング長を格納します。また、パディングの各バイトはパディングの長さを示すバイトと同じ値にします。

データの受信側は
①末尾のバイトの値を調べる
②①の値と同じ個数のバイトの値が①のバイト値を同じか１バイトずつ調べる
③すべて等しければOK、としてはパティングのデータブロックを削除

を行います。