- Looker から Snowflake への OAuth 接続
- Looker (Google Cloud core) 30日間 フリートライアル設定
- AWS 落穂拾い (Security)
- AWS 落穂拾い (Storage)
- マイクロマウス
暗号方式の分類
暗号化に用いる鍵と復号化に用いる鍵が異なるかどうかで2種類に分類されます。
対称暗号
暗号化と復号化に同じ鍵を用います。共通鍵暗号、共有鍵暗号、秘密鍵暗号ともよばれます。
具体例
- DES (Data Encryption Standard): ブルートフォースアタックで現実的な時間内に解読されることが分かっています
- 3DES: トリプルデス。DESを三段重ねにしたもので処理スピードが遅い。安全面でもやや雲行きが怪しくなってきています
- AES (Advanced Encryption Standard): コンペ方式で世界中の英知を集結して標準化されました。今のところ破られていません。
欠点
送信者と受信者で同じ鍵を共有しておく必要があり、この鍵を配送する手段が問題になります (鍵配送問題)。例えば後述の公開鍵暗号によって解決できます。
公開鍵暗号
暗号化と復号化で異なる鍵を用います。非対称暗号ともよばれます。
具体例
- RSA (開発者三人の名前の頭文字)
欠点
- 処理速度が遅い: 後述のように対称暗号とのハイブリッド化によって解決できます
- man-in-the-middleアタックに弱い: こちらのページで紹介しました、公開鍵証明書によって解決されます
ハイブリッド暗号システム
対称暗号と公開鍵暗号を組み合わせることにより、それぞれの欠点を互いに補うことができます。
- 送信者は疑似乱数生成器でセッション鍵 (共有鍵) を生成
- 送信したいメッセージをセッション鍵で対称暗号化
- セッション鍵 (メッセージと比較して短いため、公開鍵暗号の処理速度が問題にならない) は公開鍵で暗号化
- 上記二つ (2,3) の結果を結合して送信
- 受信者は秘密鍵でセッション鍵部分を復号化し、取得したセッション鍵でメッセージ部分をを復号化
鍵の長さは「セッション鍵 <= 公開鍵」とします。
- 公開鍵暗号: 破られると過去のすべての通信内容が暴かれます
- セッション鍵による暗号: 破られても現在のセッションの通信内容が暴かれるだけですみます
メッセージの指紋
あるメッセージを一方向ハッシュ関数にかけることで、メッセージに依存した数値 (指紋) を取得できます。
これは、暗号技術の様々な場面で有用な数値です。
ハッシュ値
暗号化チェックサム、指紋、メッセージダイジェストともよばれます。
あるメッセージを一方向ハッシュ関数 (メッセージダイジェスト関数とも) にかけて計算した数値です。
ソフトウェアの改竄検出や、ワンタイムパスワードなどで利用されます。
一方向ハッシュ関数の具体例
- MD4: Message Digest 4
- MD5: Message Digest 5 (16進数 32桁で表現可能)
- SHA-1: シャーワン (16進数 40桁で表現可能)
- SHA-2: SHA-256,384,512の総称
欠点
MD4、MD5、SHA-1は同じハッシュ値を持つ二つのメッセージを現実的な時間内に意図的に生成可能であることが分かっており、用途によっては危険です。
SHA-2は、現在のところ同じハッシュ値を持つ二つのメッセージを意図的に生成できないため用途によってはこれを用いることが推奨されます。
メッセージ認証コード (Message Authentication Code; MAC)
MAC値ともよばれます。鍵に依存したハッシュ値です。
送信者と受信者で事前に鍵を共有しておき、送信者はMAC値とメッセージを送信します。
受信者はメッセージのMAC値を計算し、受信したMAC値と比較して検証します。
ハッシュ値と異なり、MAC値では内容の検証に加えて、受信者が確かにある送信者からの送信であったことを確認できます。
鍵に依存した一方向ハッシュ関数の具体例
一方向ハッシュ関数を利用したHMAC (エイチマック) シリーズがあります。
- HMAC-SHA1: SHA1を利用
- HMAC-MD5: MD5を利用
欠点
- 否認防止が不可能: 受信者は確かにある送信者からの通信であることを確認できるが、それを第三者に証明できません。こちらのページで紹介しました、公開鍵証明書によって解決されます
- 再生攻撃を受け得る: 盗聴したメッセージとMAC値の組み合わせを後でこっそり何度も送信され得ます。これはシーケンス番号やタイムスタンプで回避可能です
SSL/TLS
Secure Socket LayerとTransport Layer Securityの略称です。SSLの新しいバージョンがTLSですが、両者はほぼ同じであると考えてもあまり問題にはなりません。SSL/TLSの上には様々なアプリケーションプロトコルを乗せる (プロトコルスタック) ことができます:
- HTTPS: HTTPのリクエストとレスポンスを暗号化
- SMTP over SSL
- POP over SSL
なお、SSHはそれ自体アプリケーションプロトコルであり、SSL/TLSの上に乗せる必要なくSSL/TLS相当のセキュアな通信を実現できます。
サーバ証明書とクライアント証明書
SSL/TLSは、対称暗号、疑似乱数生成器、公開鍵暗号、デジタル署名、メッセージ認証コードなど (暗号スイート) を組み合わせてセキュアな通信を実現するための手続を定めています。一連の手続の中では、受信者であるサーバの公開鍵の信頼性を確保するために、こちらのページで紹介しました公開鍵証明書が用いられます。これを特にサーバ証明書とよびます。また、特殊な場合には送信者であるクライアントの信頼性を確保したいことがあり、そのような用途のためにSSL/TLSではサーバがクライアントに証明書を求めることもできます。その場合、認証局にデジタル署名してもらったクライアント証明書を、予めクライアントにインポートしておく必要があります。
