![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>暗号化]] * 目次 [#de7a60fe] #contents *概要 [#xce2432b] -ハッシュ化 -暗号化 --秘密鍵・暗号化 --公開鍵・暗号化 -ハイブリッド・暗号化 -デジタル署名 上記の暗号化アルゴリズムの -メリット・デメリット -安全性 などのポイント解説と、 .NETのライブラリとして提供されている「暗号化アルゴリズム」を纏める。 *ハッシュ化 [#y6cc34ab] ハッシュ化とは、「[[暗号学的ハッシュ関数>#gb8f765f]]」を用いて指定のメッセージのハッシュ値を求める行為である。~ また、「暗号学的ハッシュ関数」には、次のようなことが求められているため、~ 既成の「暗号学的ハッシュ関数」を使用した場合、これらは満たされているものとして利用できる。 -不可逆性~ ハッシュ値から元のメッセージを得ることが事実上不可能であること。 -衝突困難性~ --ハッシュ値を変えずにメッセージを改竄することが事実上不可能であること。 --同じハッシュ値を持つ2つのメッセージを求めることが事実上不可能であること。 #ref(CryptographicHashFunction.png,left,nowrap,暗号学的ハッシュ関数) **[[暗号学的ハッシュ関数>http://ja.wikipedia.org/wiki/%E6%9A%97%E5%8F%B7%E5%AD%A6%E7%9A%84%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E9%96%A2%E6%95%B0]] [#gb8f765f] 情報セキュリティ分野で - メッセージ認証符号（MAC） - デジタル署名 - 各種、認証技術 など、様々に利用されている。 また、通常のハッシュ関数としても利用でき、 - ハッシュテーブル（テーブルのキー） - ダイジェスト、フィンガープリント（認証） - データ、ファイルの一意識別、重複検出 - チェックサム（データの誤りを検出） などの用途にも利用されている 。 **暗号学的ハッシュ関数の安全性 [#ff7fd94e] ***キーなし方式・あり方式 [#uc14e156] 「暗号学的ハッシュ関数」には、 -ハッシュ計算用のキーを取れないもの（キーなし方式）と、 -キーを取れるもの（キーあり方式）が存在する。 「暗号学的ハッシュ関数」自体は不可逆であるものの、~ 「キーなし方式」の場合、辞書攻撃 により、容易にメッセージが割れる可能性がある。~ このため、辞書攻撃を防ぐ場合、「キーあり方式」を採用する。 ***衝突耐性 [#n3f7704b] 「暗号学的ハッシュ関数」を使用する際は、~ 最新の「ハッシュの衝突耐性」の情報を入手する事が推奨される。~ これは、例えば、2010/5現在、MD5、SHA-0、SHA-1について~ 「強衝突耐性」が突破される脆弱性が発見されているためである。 -＠IT > 第１回 すべてはここから始まった ～ SHA-1 の脆弱化~ http://www.atmarkit.co.jp/fsecurity/rensai/crypt01/crypt01.html -ITpro > 記者の眼 > APOPのぜい弱性で見えてきたMD5の「ご臨終」~ http://itpro.nikkeibp.co.jp/article/OPINION/20070521/271639/ ただし、「強衝突耐性」が突破されても、直ちに、これらの「暗号学的ハッシュ関数」を用いている~ 暗号化通信が盗聴・改竄されたり、電子署名の有効性が無くなったりすると言うわけではない。~ これは、将来的な「弱衝突耐性」の突破を示唆し、「弱衝突耐性」が突破された場合は、~ 暗号化通信や電子署名の無改竄性を証明できなくなる。 -[IT 管理者向け] SHA-1 からの移行を推奨しています~ http://blogs.technet.com/b/jpsecurity/archive/2014/10/15/sha1-migration.aspx -FAQ: SHA-1 廃止/SHA-2 移行に関するマイクロソフトのポリシー~ http://blogs.technet.com/b/jpsecurity/archive/2015/11/02/faq-microsoft-policy-on-sha1-deprecation.aspx **.NETにて提供されている「暗号学的ハッシュ関数」のプロバイダ [#uc4db25e] 「[[.NETの署名・暗号化アルゴリズム>#uef3e17d]]」も参考になります。 ***キーなし方式 [#g774ad06] -MD --[[MD5>http://ja.wikipedia.org/wiki/MD5]] --[[RIPEMD160>https://ja.wikipedia.org/wiki/RIPEMD]] -[[SHA>http://ja.wikipedia.org/wiki/SHA]] --[[SHA1>https://ja.wikipedia.org/wiki/SHA-1]] --[[SHA256>https://ja.wikipedia.org/wiki/SHA-2]] --SHA384 --SHA512 -参考~ [[.NETの暗号学的ハッシュ関数（キーなし方式）>.NETの署名・暗号化アルゴリズム#l1894cde]] ***キーあり方式 [#kdb48f23] -[[HMAC>https://ja.wikipedia.org/wiki/HMAC]] --HMAC-MD5 --HMAC-Ripemd-160 --HMAC-SHA1 --HMAC-SHA256 --HMAC-SHA384 --HMAC-SHA512 -[[TDES-MAC>https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%97%E3%83%ABDES]] --MACTripleDES -[[.NETの暗号学的ハッシュ関数（キーあり方式）>.NETの署名・暗号化アルゴリズム#x4fe1902]] **参考 [#j99919e6] ***ハッシュ値 [#ja806d9a] 「メッセージ ダイジェスト」、あるいは単に「ダイジェスト」と呼ぶことがある。~ 認証アルゴリズムの「ダイジェスト認証」や、「チャレンジ＆レスポンス認証」で使用されている。 目的によってはハッシュ値のことを「フィンガープリント」、「チェックサム」とも呼ぶ。 ***辞書攻撃 [#qe71d1f9] あらかじめメッセージ（例えば、ここでは、メッセージ ＝ パスワードとする）として~ 利用され易いキーワードを、暗号化プロバイダ毎にハッシュ化し、ハッシュ値をDBに格納しておく。~ 次に入手したパスワードのハッシュを、このDB上で検索すると、元のパスワードを引く事が出来る。 *暗号化 [#xa6356ee] 暗号化の方式には、大きく分けて、 -[[秘密鍵・暗号化方式>#u680ecb7]]~ 暗号化と復号が同じ処理であるところから、「対称アルゴリズム」とも呼ばれる。 -[[公開鍵・暗号化方式>#tfda0d72]]~ 暗号化と復号が違う処理であるところから、「非対称アルゴリズム」とも呼ばれる。 の２つの方式がある。 以下の表に「[[秘密鍵・暗号化方式>#u680ecb7]]」と、「[[公開鍵・暗号化方式>#tfda0d72]]」との比較を示す。 なお、両者のメリット・デメリットを考慮し、両者を組み合わせたハイブリッドの方式もある。~ これについては、「[[ハイブリッド・暗号化方式>#z7306cb4]]」の項にて説明する。 #ref(ComparisonOfEncryptionScheme.png,left,nowrap,暗号化方式の比較) -※1 : 「秘密鍵・暗号化方式」は、暗号化と復号化に使用する鍵が、同一の秘密鍵であることから、「共通鍵・暗号化方式」とも呼ばれる。 -※2 : 「秘密鍵・暗号化方式」の鍵はパスワードのようなもので、基本的に相手毎に、この秘密鍵（パスワード）を変えることが望ましい。~ 従って、相手が増えるほど管理する秘密鍵（パスワード）が増える。ただし、自分のために暗号化し、自分だけが復号化する場合は、秘密鍵（パスワード）は１つでも良い。 -※3 : アルゴリズムが非対称であると、数学的に難しい処理が多く、高速での処理が難しくなるため。 **秘密鍵・暗号化 [#u680ecb7] -「秘密鍵・暗号化方式」は、秘密鍵を使用して暗号化・復号化を行う。 -この方式は、秘密鍵の受け渡しと、管理が困難となるため、~ 不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムには使用されない。 -「秘密鍵・暗号化方式」では、秘密鍵として、任意のキー（パスワード）を使用できる。 ***.NETにて提供されている「秘密鍵・暗号化方式」のプロバイダ [#l163d171] -[[DES>http://ja.wikipedia.org/wiki/DES_%28%E6%9A%97%E5%8F%B7%29]] -[[RC2>http://ja.wikipedia.org/wiki/RC2]] -[[Rijndael>http://ja.wikipedia.org/wiki/AES%E6%9A%97%E5%8F%B7]] -[[TripleDES>http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%97%E3%83%ABDES]] -[[.NETの秘密鍵・暗号化方式のプロバイダ>.NETの署名・暗号化アルゴリズム#r45cd534]] **公開鍵・暗号化 [#tfda0d72] -「公開鍵・暗号化方式」は、秘密鍵・公開鍵のキー・ペアを生成する。 -公開鍵で暗号化したものは、秘密鍵でしか復号できないと言う性質を利用して、~ 不特定多数のユーザとネットワーク越しの情報受け渡しを行うC/Sシステムには使用される。 以下の図に、その処理方式の概要図を示す。 #ref(PublicKeyEncryptionSchemes.png,left,nowrap,公開鍵・暗号化方式) 処理シーケンスは次のようになる。 +送信側は、「受信側の公開鍵」を取得する。 +送信側は、平文を「受信側の公開鍵」で暗号化する。 +上記、暗号化された平文を送付する。 +受信側は、平文を、「受信側の秘密鍵」で復号化する。 ***.NETにて提供されている「公開鍵・暗号化方式」のプロバイダ [#ud11fac2] -[[RSA>http://e-words.jp/w/RSA.html]] -[[ECDH>https://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9A%E3%83%87%E3%82%A3%E3%83%95%E3%82%A3%E3%83%BC%E3%83%BB%E3%83%98%E3%83%AB%E3%83%9E%E3%83%B3%E9%8D%B5%E5%85%B1%E6%9C%89]] -[[.NETの公開鍵・暗号化方式のプロバイダ>.NETの署名・暗号化アルゴリズム#q04bc939]]~ >.NETにて提供されるRSACryptoServiceProviderを使用した場合、 -同じ公開鍵を使用しても暗号化情報は可変になるが、~ 同じ秘密鍵で復号化可能であるので、リプレイ攻撃の対象になる。 -このため、公開鍵・秘密鍵のキー・ペアを可変にするか、~ チャレンジを加えるなどの実装を追加する必要がある。 >>なお、リプレイ攻撃とは、ユーザがログインするときにネットワークを流れる電文を盗聴し、~ これを自分の送信する電文として利用することでシステムへ不正にログインしようとする行為を指す。 **ハイブリッド・暗号化 [#z7306cb4] 両者のメリットとデメリットを考慮し、~ 組み合わせた「ハイブリッド・暗号化方式」もある。~ 以下の図に、その処理方式の概要図を示す。 #ref(HybridEncryptionScheme.png,left,nowrap,ハイブリッド・暗号化方式) 処理シーケンスは次のようになる。 +送信側は、「受信側の公開鍵」を取得する。 +送信側は、「送信側の秘密（共通）鍵」を、「受信側の公開鍵」で暗号化する。 +上記、暗号化された「送信側の秘密（共通）鍵」を送付する。 +受信側は、「送信側の秘密（共通）鍵」を、「受信側の秘密鍵」で復号化する。 +送信側は、平文を「送信側の秘密（共通）鍵」で暗号化する。 +上記、暗号化された平文を送付する。 +受信側は、平文を、「送信側の秘密（共通）鍵」で復号化する。 ※「秘密鍵・暗号化方式」と「公開鍵・暗号化方式」の鍵を区別しやすくするように、~ ここでは、「秘密鍵・暗号化方式」の秘密鍵を、秘密（共通）鍵と記述した。 「公開鍵・暗号化方式」で「送信側の秘密（共通）鍵」を共有し、~ 平文自体は速度の速い「秘密鍵・暗号化方式」で暗号化・復号化するため、~ 「安全性」を落とさずに、処理速度を稼ぐことができる。 また、「送信側の秘密（共通）鍵」（セッション鍵）をセッション毎に変更すれば、~ 万一共通鍵での暗号部分が解読されても短い時間しかクラッキングできなくなる。 なお、SSL暗号化なども、この「ハイブリッド・暗号化方式」を採用している。 -ThinkIT > サーバ構築・運用 >~ いまさら聞けないApache ～ Webサーバ構築のキソ > 第6回 : SSLの基本を押さえる~ http://thinkit.co.jp/free/article/0706/3/6/ *デジタル署名 [#leddd7f0] **概要 [#udf15110] 「デジタル署名」は、元となるメッセージのハッシュを秘密鍵で暗号化したものである。 送信元が、この「デジタル署名」を、元となるメッセージと同梱して送付することにより、~ 送信先は、元となるメッセージの正当性を（＝ 改ざんされていない事を）検証できる。 以下の図に「デジタル署名」の処理方式の概要図を示す。 #ref(DigitalSignature.png,left,nowrap,デジタル署名) 処理シーケンスは次のようになる。 +送信側は、「メッセージ」から「メッセージのハッシュ」を求め、~ これを「送信側の秘密鍵」で暗号化することで、「デジタル署名」を生成する。 +送信側は、「メッセージ」、「デジタル署名」を送付する。 +受信側は、「デジタル署名」を、「送信側の公開鍵」を使用して、~ 復号化することで、「メッセージのハッシュ」を求め、メッセージを検証する。 このことから、「デジタル署名」は、~ 「公開鍵・暗号化方式」とは逆の「非対称アルゴリズム」を~ 使用していることが分かる（秘密鍵で暗号化し、公開鍵で復号化）。 **.NETにて提供されている「デジタル署名」のプロバイダ [#za613abc] 「デジタル署名」では、秘密鍵・公開鍵のキー・ペアを、~ 下記のプロバイダを使用して生成する必要がある。 -[[RSA>http://e-words.jp/w/RSA.html]] -[[DSA>http://e-words.jp/w/DSA.html]] -[[ECDSA>https://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9ADSA]] -[[.NETのデジタル署名のプロバイダ>.NETの署名・暗号化アルゴリズム#lf5eb161]]~ *参考 [#obc20caf] 暗号についての概要や体系や、各種の「暗号化アルゴリズム」の詳細については、~ 説明しないので、これについては、下記のサイトや、他の情報源を参照のこと。 - SBINS > 暗号技術 TOP > ライブラリ > 暗号入門~ http://dev.sbins.co.jp/cryptography/04_menu.html#crypt - SBINS > 暗号技術 TOP > 技術詳細 > 暗号技術~ http://dev.sbins.co.jp/cipher/ なお、各種の「暗号化アルゴリズム」の「安全性」の問題については、~ 日々、調査・研究が進められていため、NIST やCRYPTREC などから~ 公にアナウンスされる情報源を確認のこと。 -2010年問題 - Wikipedia~ https://ja.wikipedia.org/wiki/2010%E5%B9%B4%E5%95%8F%E9%A1%8C -＠IT > Security＆Trust > もう避けられない？ 暗号の2010年問題~ http://www.atmarkit.co.jp/news/200811/20/rsa.html -Networkキーワード - 暗号の2010年問題：ITpro~ http://itpro.nikkeibp.co.jp/article/Keyword/20090119/323069/ -ASCII.jp：電子証明書に近づく 「暗号アルゴリズム 2010年問題」~ http://ascii.jp/elem/000/000/550/550217/ **[[デジタル証明書>証明書]] [#l634154e] 「[[デジタル証明書>証明書]]」の検証は、「送信側の公開鍵」を拠り所にしていると言えるが、提供される「送信側の公開鍵」の出所が、正規の出所か、検証できない（場合がある）という問題がある。~ このため、この問題を解決するための、「認証局」と呼ばれる、信頼のおける第三者が発行した「[[デジタル証明書>証明書]]」を使用して「送信側の公開鍵」が信頼できるものであるかを検証する機構がある。 **[[.NETの署名・暗号化アルゴリズム]] [#uef3e17d] **Open棟梁の暗号化クラスを使用したサンプル・コード [#ye082291] -暗号化クラスは、.NETの暗号化プロバイダのラッパークラスです。 -[[暗号化ツール>https://github.com/OpenTouryoProject/OpenTouryo/tree/develop/root/programs/C%23/Frameworks/Tools/Encryption]]のコードをサンプル コードとして利用できます。 ---- Tags: [[:セキュリティ]], [[:暗号化]]
