「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
上記の暗号化アルゴリズムの
などのポイント解説と、
.NETのライブラリとして提供されている「暗号化アルゴリズム」を纏める。
暗号化・復号化の流れ †
暗号化 †
- アルゴリズムに対応したブロック長に分割する。
- ブロック長に満たない部分をパディング方式で補完する。
- 暗号鍵を用いてアルゴリズムで暗号化する。
- 分割されたデータを結合する。
復号化 †
- アルゴリズムに対応したブロック長に分割する。
- 暗号鍵を用いてアルゴリズムで復号化する。
- 補完された部分をパディング方式で除去する。
- 分割されたデータを結合する。
基礎用語 †
ブロック暗号化 †
- 通常、暗号化は鍵のサイズと同じバイト長を１ブロックとして暗号化する。
1024ビットの鍵ならば = 1024 / 8 = 128バイトを１ブロックとして暗号化する。
- アルゴリズムによって、以下が、決まっていることがある。
暗号化モード（暗号利用モード） †
- 認証用の利用モード、秘匿用の利用モードとがある。
- 認証用の利用モード
| # | | |
| 1 | CCM | Counter with CBC-MAC |
| 2 | OCB | Offset CodeBook? |
| 3 | XCBC | eXtended Ciphertext Block Chaining |
| 4 | XCBC-MAC | |
- 秘匿用の利用モード
| # | 暗号化モード（暗号利用モード） | 特徴 |
| 1 | ECB: Electronic CodeBook?
暗号ブックモード | ・単純にブロックに分割しそのまま暗号化するため、初期値（IV：初期化ベクトル）を必要としない。
・鍵と暗号対象データが同じであれば、同じ暗号データになるため、暗号文一致攻撃、暗号文改ざん攻撃に弱いという問題がある。 |
| 2 | CBC: Cipher Block Chaining
暗号文ブロック連鎖モード | ・最初のブロックについては最後のブロック or 初期値（IV：初期化ベクトル）と暗号対象データをXOR計算した結果を暗号化する。
・次のブロックについては、前のブロックとそのブロックをXOR計算した結果を暗号化する。
・ブロック暗号をストリーム暗号のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。 |
| 3 | OFB: Output FeedBack?
出力フィードバックモード | ・初期値（IV：初期化ベクトル）を暗号化し、それをまた暗号化し、次々と乱数を生成する。
・その乱数列を XOR 演算によって平文に重ね合わせ暗号化処理を行う。
・ブロック暗号をストリーム暗号のように利用するため、元のデータが部分的に同じで、鍵が同一でも一意の暗号データになり難い。 |
| 4 | などなど他にも沢山ある | ・・・ |
パディングモード（パディング方式） †
- ブロック分割する時に割り切れない場合は、パディングで穴埋めする。
- ZeroBytePadding?
- NULLバイト(0x00)でパディング
- 元データにNULLバイトが含まれていない場合でないと使えない
- PKCS#5 Padding (RFC1423)
- ブロック長に満たないサイズの値を表すバイト値で足りない分を埋める
- ブロック長ぴったりな場合は1ブロック分丸ごとパディングされる
- Optimal Asymmetric Encryption Padding（OAEP）
- PKCS#1 に定義されているOAEPWith<digest>And<mgf>Padding
- OAEPはRSAと組み合わせることが多く、その場合はRSA-OAEPと呼ばれる。
- その他
- SSL3Padding
- ISO10126Padding
- ISO10126d2Padding
- ISO7816d4Padding
- TBCPadding
- X9.23Padding
初期値（IV：初期化ベクトル） †
- 暗号化モード（暗号利用モード）で前の平文ブロックの結果を次の平文に使用する。
- このときの最初のブロックに使用されるベクトル値が初期化ベクトル（IV: Initialization Vector）。
- 例えば、ECBでは単純にブロック長で分割するため、初期化ベクトルは不要。
ハッシュ化 †
ハッシュ化とは、「暗号学的ハッシュ関数」を用いて指定のメッセージのハッシュ値を求める行為である。
また、「暗号学的ハッシュ関数」には、次のようなことが求められているため、
既成の「暗号学的ハッシュ関数」を使用した場合、これらは満たされているものとして利用できる。
- 不可逆性
ハッシュ値から元のメッセージを得ることが事実上不可能であること。
- 衝突困難性
- ハッシュ値を変えずにメッセージを改竄することが事実上不可能であること。
- 同じハッシュ値を持つ2つのメッセージを求めることが事実上不可能であること。
情報セキュリティ分野で
など、様々に利用されている。
また、通常のハッシュ関数としても利用でき、
- ハッシュテーブル（テーブルのキー）
- ダイジェスト、フィンガープリント（認証）
- データ、ファイルの一意識別、重複検出
- チェックサム（データの誤りを検出）
などの用途にも利用されている 。
暗号学的ハッシュ関数の安全性 †
キーなし方式・あり方式 †
「暗号学的ハッシュ関数」には、
- ハッシュ計算用のキーを取れないもの（キーなし方式）と、
- キーを取れるもの（キーあり方式）が存在する。
「暗号学的ハッシュ関数」自体は不可逆であるものの、
「キーなし方式」の場合、辞書攻撃 により、容易にメッセージが割れる可能性がある。
このため、辞書攻撃を防ぐ場合、「キーあり方式」を採用する。
衝突耐性 †
「暗号学的ハッシュ関数」を使用する際は、
最新の「ハッシュの衝突耐性」の情報を入手する事が推奨される。
これは、例えば、2010/5現在、MD5、SHA-0、SHA-1について
「強衝突耐性」が突破される脆弱性が発見されているためである。
ただし、「強衝突耐性」が突破されても、直ちに、これらの「暗号学的ハッシュ関数」を用いている
暗号化通信が盗聴・改竄されたり、電子署名の有効性が無くなったりすると言うわけではない。
これは、将来的な「弱衝突耐性」の突破を示唆し、「弱衝突耐性」が突破された場合は、
暗号化通信や電子署名の無改竄性を証明できなくなる。
キーなし方式 †
キーあり方式 †
- HMAC
- HMAC-MD5
- HMAC-Ripemd-160
- HMAC-SHA1
- HMAC-SHA256
- HMAC-SHA384
- HMAC-SHA512
参考 †
ハッシュ値 †
「メッセージ ダイジェスト」、あるいは単に「ダイジェスト」と呼ぶことがある。
認証アルゴリズムの「ダイジェスト認証」や、「チャレンジ＆レスポンス認証」で使用されている。
目的によってはハッシュ値のことを「フィンガープリント」、「チェックサム」とも呼ぶ。
辞書攻撃 †
あらかじめメッセージ（例えば、ここでは、メッセージ ＝ パスワードとする）として
利用され易いキーワードを、暗号化プロバイダ毎にハッシュ化し、ハッシュ値をDBに格納しておく。
次に入手したパスワードのハッシュを、このDB上で検索すると、元のパスワードを引く事が出来る。
暗号化 †
暗号化の方式には、大きく分けて、
- 秘密鍵・暗号化方式
暗号化と復号が同じ処理であるところから、「対称アルゴリズム」とも呼ばれる。
- 公開鍵・暗号化方式
暗号化と復号が違う処理であるところから、「非対称アルゴリズム」とも呼ばれる。
の２つの方式がある。
以下の表に「秘密鍵・暗号化方式」と、「公開鍵・暗号化方式」との比較を示す。
なお、両者のメリット・デメリットを考慮し、両者を組み合わせたハイブリッドの方式もある。
これについては、「ハイブリッド・暗号化方式」の項にて説明する。
- ※1 : 「秘密鍵・暗号化方式」は、暗号化と復号化に使用する鍵が、同一の秘密鍵であることから、「共通鍵・暗号化方式」とも呼ばれる。
- ※2 : 「秘密鍵・暗号化方式」の鍵はパスワードのようなもので、基本的に相手毎に、この秘密鍵（パスワード）を変えることが望ましい。
従って、相手が増えるほど管理する秘密鍵（パスワード）が増える。ただし、自分のために暗号化し、自分だけが復号化する場合は、秘密鍵（パスワード）は１つでも良い。
- ※3 : アルゴリズムが非対称であると、数学的に難しい処理が多く、高速での処理が難しくなるため。
秘密鍵・暗号化 †
概要 †
- 「秘密鍵・暗号化方式」は、秘密鍵を使用して暗号化・復号化を行う。
- この方式は、秘密鍵の受け渡しと、管理が困難となるため、
不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムには使用されない。
- 「秘密鍵・暗号化方式」では、秘密鍵として、任意のキー（パスワード）を使用できる。
アルゴリズム †
公開鍵・暗号化 †
- 「公開鍵・暗号化方式」は、秘密鍵・公開鍵のキー・ペアを生成する。
- 公開鍵で暗号化したものは、秘密鍵でしか復号できないと言う性質を利用して、
不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムには使用される。
シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、平文を「受信側の公開鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「受信側の秘密鍵」で復号化する。
アルゴリズム †
.NETにて提供されるRSACryptoServiceProvider?を使用した場合、
- 同じ公開鍵を使用しても暗号化情報は可変になるが、
同じ秘密鍵で復号化が可能であるので、リプレイ攻撃の対象になる。
- このため、公開鍵・秘密鍵のキー・ペアを可変にするか、
チャレンジを加えるなどの実装を追加する必要がある。
なお、リプレイ攻撃とは、ユーザがログインするときにネットワークを流れる電文を盗聴し、
これを自分の送信する電文として利用することでシステムへ不正にログインしようとする行為を指す。
ハイブリッド・暗号化 †
秘密鍵・暗号化、公開鍵・暗号化の両者のメリットとデメリットを考慮し、
組み合わせた「ハイブリッド・暗号化方式」もある。
一般的には、アリスとボブ - Wikipediaで知られている。
シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「受信側の公開鍵」を取得する。
- 送信側は、「送信側の秘密（共通）鍵」を、「受信側の公開鍵」で暗号化する。
- 上記、暗号化された「送信側の秘密（共通）鍵」を送付する。
- 受信側は、「送信側の秘密（共通）鍵」を、「受信側の秘密鍵」で復号化する。
- 送信側は、平文を「送信側の秘密（共通）鍵」で暗号化する。
- 上記、暗号化された平文を送付する。
- 受信側は、平文を、「送信側の秘密（共通）鍵」で復号化する。
- 以下の図に、その処理方式の概要図を示す。
※「秘密鍵・暗号化方式」と「公開鍵・暗号化方式」の鍵を区別しやすくするように、
ここでは、「秘密鍵・暗号化方式」の秘密鍵を、秘密（共通）鍵と記述した。
- 「公開鍵・暗号化方式」で「送信側の秘密（共通）鍵」を共有し、
平文自体は速度の速い「秘密鍵・暗号化方式」で暗号化・復号化するため、
「安全性」を落とさずに、処理速度を稼ぐことができる。
- また、「送信側の秘密（共通）鍵」（セッション鍵）をセッション毎に変更すれば、
万一共通鍵での暗号部分が解読されても短い時間しかクラッキングできなくなる。
- なお、SSL暗号化なども、この「ハイブリッド・暗号化方式」を採用している。
アルゴリズム †
デジタル署名 †
概要 †
「デジタル署名」は、元となるメッセージのハッシュを秘密鍵で暗号化したものである。
送信元が、この「デジタル署名」を、元となるメッセージと同梱して送付することにより、
送信先は、元となるメッセージの正当性を（＝ 改ざんされていない事を）検証できる。
シーケンス †
- 処理シーケンスは次のようになる。
- 送信側は、「メッセージ」から「メッセージのハッシュ」を求め、
これを「送信側の秘密鍵」で暗号化することで、「デジタル署名」を生成する。
- 送信側は、「メッセージ」、「デジタル署名」を送付する。
- 受信側は、「デジタル署名」を、「送信側の公開鍵」を使用して、
復号化することで、「メッセージのハッシュ」を求め、メッセージを検証する。
- 以下の図に「デジタル署名」の処理方式の概要図を示す。
- このことから、「デジタル署名」は、
「公開鍵・暗号化方式」とは逆に「非対称アルゴリズム」を
使用していることが分かる（秘密鍵で暗号化し、公開鍵で復号化）。
アルゴリズム †
「デジタル署名」では、秘密鍵・公開鍵のキー・ペアを、プロバイダを使用して生成する必要がある。
認証 †
メッセージ認証符号（MAC） †
概要 †
メッセージ認証符号 - Wikipedia（MAC: Message Authentication Code）
メッセージ認証完全性コード（MAIC: Message Authentication and Integrity Code）とも呼ばれる。
- 暗号学的ハッシュ関数との違い
MAC関数は選択平文攻撃における存在的偽造に対して耐性がなければならない。
つまり、共通鍵を持ちMAC関数を計算できる"復号オラクル"にアクセスできる
攻撃者が、任意に選んだメッセージに対応するMACを取得できたとしても、
他の（"復号オラクル"に問い合わせていない）メッセージに対するMACを
"復号オラクル"に対して問い合わせずに計算で求めることが計算量的に困難でなければならない。
- デジタル署名との違い
- MAC値の生成と検証には同じ鍵（共通鍵暗号）が使われるので、
送信者と受信者は通信を行う前に鍵を共有しておく必要がある。
- また、共通鍵暗号であるために、MACによって認証されるメッセージは、
偽造ではなく送信者が作成し送信したという確証、つまり否認不可性をもたない。
なぜなら、MAC値を検証する利用者（メッセージの受信側）は、
通信の相手から受け取ったメッセージではなく、受信側で捏造したメッセージ
についても共通鍵を使ってMAC値を生成することができるからである。
シーケンス †
https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E8%AA%8D%E8%A8%BC%E7%AC%A6%E5%8F%B7#/media/File:MAC.svg
例：SSH2のトランスポート層のデータ一貫性を確保するためのMAC用の共通鍵を、
ハイブリッド・暗号化のECDHで生成された共通鍵からハッシュ関数によって生成される。
アルゴリズム †
MACアルゴリズムは他の暗号プリミティブから構築できる。
- ハッシュ関数（キーあり方式）を使う方式（HMAC）
- ブロック暗号アルゴリズムを使う方式（OMAC/CMAC、CBC-MAC、PMAC）
APIインターフェイス †
- 入力として共通鍵と認証すべき任意長のメッセージを受け取る。
- MAC（「タグ」とも呼ばれる）を出力する。
MAC値は（、共通鍵をもつ）、検証者がメッセージの内容の変化を
検出できるようにして、メッセージの完全性を保護し、認証する。
.NETのメッセージ認証符号（MAC）のプロバイダ †
認証付き暗号（AEAD） †
概要 †
認証付き暗号 - Wikipedia（AE: Authenticated Encryption あるいは AEAD: Authenticated Encryption with Associated Data）
- データの秘匿性、完全性、および認証性を同時に提供する暗号利用モードで、復号すると同時に完全性も検証される。
＝秘匿性と完全性の保護に加えて、認証付き暗号は平文既知性 (PA: plaintext awareness) を備えており、選択暗号文攻撃に対して安全である。
- この種の攻撃で敵は、よく考えられた暗号文を "復号オラクル" に渡して復号結果を分析することで、暗号システムの攻略ヒントを得ようとする。
- 認証付き暗号システムは不適切に細工された暗号文を識別して復号を拒否することができる。
- 適切に暗号化アルゴリズムを使って生成（≒平文を既に知っている）しない限り暗号文の復号要求を防ぐということである。
- 適切に実装されていれば、これにより攻撃者が既に知っている以上の有用な情報を復号オラクルで取り出せないようになる。
- 認証付き暗号対応のクラスライブラリを使用すれば、こうした特性がまとめて提供される。
- 秘匿用モードと認証用モードを安全に合成するのが困難であろうとの報告により、AE の必要性が明らかになった。
シーケンス †
- 共通鍵ブロック暗号で使うための認証付き暗号専用のモードも数多く開発されているが、
一般的に認証付き暗号は、以下要件を満たす暗号システムとメッセージ認証符号（MAC）を組み合わせて構成する。
- 暗号システム：選択平文攻撃のもとで強秘匿性を有する必要がある。
- MAC関数：選択メッセージ攻撃のもとで偽造不可でなければならない。
- 認証付き暗号の手法
Bellare and Namprempre (2000) はこうしたプリミティブの組み合わせを三通り考察し、
暗号と MAC 双方の関数が必要な性質を満たす場合は、メッセージを暗号化してから
暗号文に MAC を計算することで適応的選択暗号文攻撃に対し安全であることを実証した。
- Encrypt-then-MAC (EtM)
- Encrypt-and-MAC (E&M)
- MAC-then-Encrypt (MtE)
アルゴリズム †
6種類の異なるモードが、
ISO/IEC 19772:2009 によって標準化され、
さらにNISTによって開発がすすめられた。
- OCB 2.0
- Key Wrap
- EAX
- Encrypt-then-MAC (EtM)
APIインターフェイス †
AEADの典型的な APIインターフェイス は次のような関数を提供する:
- 暗号化
- 入力
- 鍵
- 平文
- 追加認証データ（AAD）
アルゴリズムによっては必要になる。
認証や完全性保護のためにあり、
暗号化はされないが認証保護の対象。
- 復号化
- 入力
- 鍵
- 暗号文
- 認証タグ（MAC）
- 追加認証データ（AAD）
- 出力
- 平文
- 平文が、認証タグ（MAC）、追加認証データ（AAD）に合致しない場合はエラー
.NETの認証付き暗号のプロバイダ †
- 昔、codeplexで提供されていたSecurity.Cryptography.AuthenticatedAes?辺りを使用可能。
- ただし、現在は、GitHubに移動されているが、メンテナンスされておらず、.NET Core対応がされていない。
参考 †
暗号についての概要や体系や、各種の「暗号化アルゴリズム」の詳細については、
説明しないので、これについては、下記サイトや、他の情報源を参照のこと。
RFC †
Wikipedia †
ハッシュ関数 †
共通鍵暗号 †
公開鍵暗号 †
その他 †
Qiita †
「デジタル証明書」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。
このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「デジタル証明書」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。
暗号の年問題 †
なお、各種の「暗号化アルゴリズム」の「安全性」の問題については、
日々、調査・研究が進められていため、NIST やCRYPTREC などから
公にアナウンスされる情報源を確認のこと。
.NET Framework、.NET Coreのライブラリで提供される署名・暗号化アルゴリズム
Tags: :セキュリティ, :暗号化
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
