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

—— 加餐開始 ——

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