（加餐）情報セキュリティ | インターネット時代、どのように信頼を築くか？

—— 加餐開始 ——

SSL/TLS#

HTTP の平文での情報伝送のセキュリティ問題を解決するために、HTTPS は HTTP の基礎の上に SSL/TLS（Secure Sockets Layer / Transport Layer Security）セキュリティプロトコルを導入し、情報を暗号化して伝送できるようにしました。

まず、SSL/TLS の発展の歴史を見てみましょう：

実際、SSL は TLS の前身です。

SSL はネットスケープ社が設計したもので、SSL 3.0 以降、ネットスケープ社は SSL を IETF（インターネット技術標準化団体）に引き渡し、IETF は SSL を標準化し、TLS 1.0（= SSL 3.1）を発表し、RFC（インターネットの規範、プロトコル、手続きなどを記録する標準文書）に登録しました。更新と進化を経て、

現在（2022 年 5 月）使用されている TLS バージョンは 1.2 と 1.3 のみです。

PS：図に SSL 1.0 が見当たらないのは、大きなセキュリティの脆弱性があったため、公開されなかったからです。

参考：

SSL/TLS の歴史と最前線ガイド——Blog
SSL/TLS プロトコル各バージョン間の違い—— 安信証明書

TLS ハンドシェイクのプロセスについて、以下の図を簡単に見てみましょう（左側は一方向認証プロセス、右側は双方向認証プロセスです）：

見ることができるのは：

TLS ハンドシェイクは TCP 接続が確立された後に行われます；
双方向認証プロセスでは、クライアントも自分の証明書をサーバーに送信します；
ChangeCipherSpec の後、情報は暗号化されて伝送されます；

全体の TLS ハンドシェイクプロセスは主に証明書の伝達、鍵交換などのステップを含み、具体的な原理については、いくつかの良い資料をお勧めします～

以下の資料を読む際に2 つの質問を持っていくと良いでしょう：1）ClientHello は単に「Hello」と言っているだけですか？2）暗号化伝送情報に使用される鍵はどのように生成されるのですか？（後の「実践部分 > WireShark」で答えが公開されますので、ネットワークパケット分析ツール WireShark を通じて TLS ハンドシェイクプロセスの理解を深めることを強くお勧めします。）

動画：SSL/TLS ハンドシェイクプロセス——bilibili
記事
- SSL/TLS プロトコルの動作メカニズムの概要—— 阮一峰
- HTTPS - TLS 1.2 プロトコルの完全なハンドシェイクプロセスの解明——51CTO
- HTTPS RSA ハンドシェイク解析—— 小林 Coding
- HTTPS ECDHE ハンドシェイク解析—— 小林 Coding

ヒント：小林 Coding の記事から、上図のプロセスは絶対的ではないことがわかります。異なる鍵交換アルゴリズム（RSA、ECDHE など）に応じて、プロセスに違いがあるため、例えばRSA に基づく鍵交換アルゴリズムのプロセスには ServerKeyExchange メッセージが含まれません。

SSH#

SSH（Secure Shell）もまた、ネットワークセキュリティプロトコルの一種で、IETF によって策定されました。しかし、これは TLS の上に構築されたアプリケーション層プロトコル（TLS は輸送層とアプリケーション層の間で機能します）であり、暗号化と認証メカニズムを通じて安全なアクセスやファイル転送などの業務を実現します。クラウドホストや Github を頻繁に使用する場合、あなたはそれに馴染みがあるでしょう～

SSH 接続の確立プロセスは 3 つのステップに分かれます：

1）クライアントがサーバーを認証する

あなたが初めて SSH でクラウドホストに接続する際、以下の図を見たことがあるでしょう：

クライアントはクラウドホストからいくつかの情報を受け取り、ここでの「フィンガープリント」（ECDSA 署名アルゴリズムにおける公開鍵の SHA-256 値）が重要です。ssh-keyscan -t ECDSA -p 22 [host] > key.pubを使用してサーバーの実際の公開鍵を取得し、ssh-keygen -E sha256 -lf key.pubを使用してその SHA256 値を計算し、図の「フィンガープリント」と比較します。一致すれば接続を決定します。

このように、ここでの認証プロセスはクライアントが制御しており、クライアントは何の比較もせずに接続を信頼することもできますが、そうするとリスクが伴います。

2）情報を暗号化して伝送するための鍵を生成する（鍵交換アルゴリズムを通じて）、その後の通信はすべて暗号化されます

3）サーバーがクライアントを認証する（2 つの方法）

a. クライアントが公開鍵をアップロードしていない場合：サーバーはクライアントに公開鍵を提供し、クライアントはその公開鍵を使用してユーザー情報（パスワードなど）を暗号化し、サーバーに送信します。サーバーが検証を通過した後、接続が確立されます。

a. クライアントが公開鍵をアップロードしていない場合

b. クライアントが事前に公開鍵をサーバーにアップロードした場合：サーバーはその公開鍵を使用してランダムな数をクライアントに送信し、クライアントは対応する秘密鍵で復号し、再びサーバーに送信します。サーバーが検証を通過した後、接続が確立されます。

b. クライアントが公開鍵をアップロードした場合

参考：SSH 無パスワードログインの原理と実装—— 掘金

iOS 署名#

図からわかるように、iOS 署名は実際には非常に複雑なプロセスであり、一段落では詳細に説明することはできません。

ここで知っておくべき iOS 署名における 2 つの必須の重要ファイルは次のとおりです：

1）.mobileprovision ファイル：PP ファイルとも呼ばれ（図中は Provisioning Profile）、これは証明書のアップグレード版と考えることができ、1 つ以上の iOS 開発者証明書やその他の情報が含まれています。

2）.p12 ファイル：開発者証明書と対応する秘密鍵で構成され、図中の重要なステップ 2 と 4 に関連しています。Xcode がパッケージを作成する際、PP ファイルに含まれる証明書の集合に属する証明書を Keychain から検索し、その中の秘密鍵を使用してアプリに署名します。

詳細な説明は私の以前の記事を参照してください：iOS | iOS 署名の背後にある原理の図解、これがこの記事の出所です。

覚えておいてください、iOS 署名パッケージに関連する問題に直面した場合、まずは上記の 2 つのファイルから取り組んでみてください～

いくつかの実践#

最後に、今日の内容を強化するために、2 つの優れた実践ツールを紹介します。

OpenSSL#

OpenSSL はオープンソースの暗号学ツールキットで、以下のスクリプトを使用して、今日学んだアルゴリズムを復習することができます。

# プライベートキーを生成する（RSA）
openssl genrsa -out private.pem
# プライベートキーから公開鍵を生成する
openssl rsa -in private.pem -pubout -out pubkey.pem

echo "hello, world" > test.txt
# 暗号化
openssl rsautl -encrypt -pubin -inkey pubkey.pem -in test.txt -out test.enc
# 復号
openssl rsautl -decrypt -inkey private.pem -in test.enc -out test.dec

# 署名（ハッシュ：SHA-256）
## 生成
openssl dgst -sign private.pem -sha256 -out test.sig test.txt
## 検証
openssl dgst -verify pubkey.pem -sha256 -signature test.sig test.txt

# テキストとして鍵を表示
## プライベートキー
openssl rsa -in private.pem -noout -text
## 公開鍵
openssl rsa -pubin -in pubkey.pem -noout -text

# 自己署名証明書を生成する
# {OpenSSLで自己署名証明書を作成する——Baeldung}
...

参考：

openssl——Linux コマンド大全
OpenSSL で自己署名証明書を作成する——Baeldung

WireShark#

WireShark はオープンソースのネットワークパケット分析ツールで、さまざまなネットワークプロトコルを深く理解するために使用するのに最適です～

次に、「関連技術 > SSL/TLS」セクションで提起された質問を振り返りましょう：

1）ClientHello は単に「Hello」と言っているだけですか？

2）暗号化伝送情報に使用される鍵はどのように生成されるのですか？

次に、WireShark を開き、取得したネットワークパケットを簡単にフィルタリングします。例えばip.addr == 115.236.119.85 && tls。

見ることができるのは、ClientHello で伝達される情報はかなり多く、重要な情報には TLS バージョン、ランダム数（鍵交換アルゴリズム用）、サポートされている 21 種類の暗号スイート（サーバーが選択できる鍵交換アルゴリズム）などが含まれています。これにより、上記の 1 つ目の質問が解決されます。

次に、後の各情報を分析し続けると、ServerHello でサーバーが選択した鍵交換アルゴリズムがあり、最終的にそのアルゴリズムを通じて暗号化伝送情報に使用される鍵が生成されることがわかります。これにより、上記の 2 つ目の質問が解決されます。

さらなる詳細は、あなたが WireShark をインストールして探索するのを待っています～

—— 加餐終了 ——

Bo2SS