🌐
「食べる!SSL!」を読んでSSLについて深掘りしたメモ
「食べる!SSL!」を読んで自分なりにSSLについて深掘りしてみました。
この本の「食べる!」というタイトルは「咀嚼しよう」という意味が込められているらしく、
インパクトと込められた意味が個人的にめちゃ好みのタイトルでした
Amazonの評価4.2(93)も高く、このテーマを深掘りする上で参考になりました。
2014年(+2017年加筆)の本なので最新情報は載っていないです。
SSLは名前を変え、2025年現在はTLS1.2, 1.3が使われています。
セキュリティは大事
- OpenSSLの脆弱性(Heartbleed等)、Log4jの脆弱性(Log4Shell - CVE-2021-44228)などなど、1つの脆弱性の影響大きい、セキュリティ大事
- OpenSSLの脆弱性(Heartbleed等)
- インターネット全体で使用されている暗号化ライブラリの脆弱性
- Log4jの脆弱性(Log4Shell - CVE-2021-44228)
- Javaアプリケーションで広く使用されているログライブラリの脆弱性
- リモートコード実行が可能な極めて危険な脆弱性(修正対応に膨大なコストと時間が必要だった)
- OpenSSLの脆弱性(Heartbleed等)
- 情報セキュリティ3要素 CIA
- 応用情報試験で出て書けなかったやつだ
- Confidentiality(機密性), Integrity(完全性), Availability(可用性)
- 情報漏れてないかな?, 改竄されてないかな?, 使いたい時にシステム使えるかな?(DoSとか)
- 脅威モデル STRIDE
| 脅威の種類 | 説明 |
|---|---|
|
Spoofing (なりすまし) |
攻撃者が正当なユーザーやシステムになりすます |
|
Tampering (改ざん) |
データや通信内容が不正に変更される |
|
Repudiation (否認) |
実行した行為を否定される |
|
Information Disclosure (情報漏洩) |
機密情報が権限のない者に開示される |
|
Denial of Service (サービス拒否) |
正当なユーザーがサービスを利用できなくなる |
|
Elevation of Privilege (権限昇格) |
攻撃者が本来持たない高い権限を取得する |
SSL通信で何から守れる?
- データ通信のセキュリティではSTRI(なりすまし、改竄、否認、情報漏洩)の脅威に気をつける
- 改竄には「MAC メッセージ認証符号」
- なりすまし、否認防止には「デジタル署名」
- 情報漏洩しないために「暗号化」
- 共通鍵暗号方式(2人だけの秘密の鍵(3人だと読まれちゃうため)で使いまわせない、インターネットは人が多すぎて一人当たりn-1個の鍵が必要なので、現実的じゃない)
- 暗号化・複合化の処理めちゃ速い
- 鍵多すぎ問題
- 配送時に盗聴される可能性がある(これのせいで単体で使えない)
- O(n) nはデータ量(AESの場合)
- 公開鍵暗号方式(公開鍵・秘密鍵)
- 暗号化・複合化の処理遅すぎ
- 鍵2個を使いまわせる
- 配送時も安全
- O(k^3) kは鍵長、一回に暗号・複合化できるデータ長に制限があり、鍵長に比較して無視
できるため(RSAの場合、実装によって異なる場合あり) - 署名とか小さいデータ長なら使われている
- ハイブリッド暗号方式(いいとこ取り)
- 鍵交換だけ公開鍵暗号方式で、そのあとの通信は共通鍵暗号方式(時間問題解決)
- 鍵は通信終わったら破棄しちゃうので持っておく必要ない
- これが使われている
- 共通鍵暗号方式(2人だけの秘密の鍵(3人だと読まれちゃうため)で使いまわせない、インターネットは人が多すぎて一人当たりn-1個の鍵が必要なので、現実的じゃない)
- 二人が共通鍵持ってればお互いに相手がわかるよね?著名ってなんの意味があるの?
- 送った、送ってない論争が起きた時に証明になる(否認防止)
- Open SSLはSSL/TLSの仕組みを使ってSTRIの4つのセキュリティ脅威に対応する機能を提供している
- オープンソースのソフトウェア。最も広く利用されているSSL通信を行うソフトウェア。
- (heart bleedという脆弱性って本当に危なかったんだな・・・)
| STRIDE脅威 | MAC | デジタル署名 | 暗号化 |
|---|---|---|---|
| Spoofing(なりすまし) | ❌ | ✅ | ❌ |
| Tampering(改ざん) | ✅ | ✅ | ❌ |
| Repudiation(否認) | ❌ | ✅ | ❌ |
| Information Disclosure(情報漏洩) | ❌ | ❌ | ✅ |
| Denial of Service(サービス拒否) | ❌ | ❌ | ❌ |
| Elevation of Privilege(権限昇格) | ❌ | ❌ | ❌ |
SSL通信の仕組み
- ハンドシェイクからのデータ転送
- ハンドシェイクで、クライアントに合わせてアルゴリズムが選択される
- 2点間の通信に限った仕組み
-
SSLはトランスポート層とアプリケーション層の間にある、厳密には層に収まらない。アプリケーション層のプロトコルと色々組み合わせることができる
- HTTPS, FTPS, SMTPS, SSL-VPN
方式別暗号化アルゴリズム
共通鍵暗号方式
| アルゴリズム | 特徴 |
|---|---|
| AES(Advanced Encryption Standard) | 現在の標準。高速&安全。TLSやVPNなど広く使われる。鍵長128/192/256bit。 |
| ChaCha20 | モバイルや低スペック向け。AESより高速なケースあり。TLSにも対応。 |
| 3DES(Triple DES) | 古い規格。今は非推奨(遅くて脆弱)。 |
| Blowfish / Twofish | 一時期人気だったが、今はAESが主流。 |
公開鍵暗号方式
| アルゴリズム | 特徴 |
|---|---|
| RSA | 古典的な公開鍵暗号。処理は重いが広く使われてる。鍵長2048bit以上が主流。暗号化・署名両方に使える。 |
| ECC(楕円曲線暗号) | RSAより短い鍵長で同等の安全性。処理も高速。TLSやスマホ、ブロックチェーン系で多用。 |
| ElGamal | 楕円曲線のベースになる古典暗号。ランダム性を使った暗号。今はあまり主流じゃない。 |
| DSA(Digital Signature Algorithm) | 署名専用。FIPS標準。暗号化には使わない。TLSでは非推奨。 |
Discussion