List of cryptrec - Baldanders.info
tag:Baldanders.info,2014-09-18:/tags
2014-09-18T09:00:00+00:00
バルトアンデルスは連続的な怪物,時間の怪物である。(ホルヘ・ルイス・ボルヘス 『幻獣辞典』より)
https://baldanders.info/images/avatar.jpg
https://baldanders.info/images/avatar.jpg
CRYPTREC Report 2013
tag:Baldanders.info,2014-09-18:/blog/000740/
2014-09-18T09:00:00+00:00
2014-09-18T09:00:00+00:00
8月に CRYPTREC Report 2013 が出てたのに気付かず。ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。
Spiegel
/profile/
<p> 8月に CRYPTREC Report 2013 が出てたのに気付かず。 </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20140811_c13report.html">CRYPTREC Report 2013の公開</a> <ul> <li><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_prom_web_final.pdf">CRYPTREC Report 2013 暗号技術活用委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf">CRYPTREC 暗号技術ガイドライン (SSL/TLS における近年の攻撃への対応)<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_SHA-1_web.pdf">CRYPTREC 暗号技術ガイドライン (SHA-1)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul></li> </ul><p> あと CRYPTREC Report じゃないけど,昨年大騒ぎになった </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></li> </ul><p> も併せてどうぞ。 </p><p> セキュリティ管理に関わっている人は最低でも「暗号技術評価委員会報告書」は読んでおくとよい。 ちなみに SSL/TLS と SHA-1 の暗号技術ガイドラインは「暗号技術評価委員会報告書」にも含まれている。 </p><p> ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。 </p> <ol> <li><a href="#pubkey">公開鍵暗号に関する安全性評価</a></li> <li><a href="#sha3">ハッシュ関数について</a></li> <li><a href="#dsa">FIPS PUB 186-4</a></li> <li><a href="#tls12">SP800-52 revision 1 と TLS 1.2</a></li> <li><a href="#pfs">perfect forward secrecy と forward secrecy</a></li> <li><a href="#key-exch">SSL/TLS における DHE, DH, RSA の安全性評価</a></li> <li><a href="#rnd">擬似乱数生成アルゴリズム Dual_EC_DRBG</a></li> <li><a href="#light-cipher">軽量暗号</a></li> </ol> <section id="pubkey"> <h3>公開鍵暗号に関する安全性評価</h3> <figure> <blockquote> <q>昨年の Crypto 2012 で A.K. Lenstra らは、実社会に公開されている RSA 公開鍵証明書(X.509)に、異なる署名に同じ modulus が使われていたり、modulus が素因数分解できたりといった問題を指摘した。これに続き、 Asiacrypt 2013 において N. Heninger らは、台湾市民向けのスマートカードで利用される公開鍵証明書約300万件について、同じ問題点があることと、Coppersmith 攻撃によって新たな素因数分解が可能となったことを示した。 <br/>楕円曲線暗号に関しては、Asiacrypt 013 のランプセッションにおいて J.W. Bos らが、実際に暗号通信(TLS/SSH)で利用されている証明書を調べ、TLS 公開鍵の 4%(20 万個)、SSH公開鍵の 30%(40 万個)に同じものが使用されている問題点を確認した。また、Bitcoin において、同じ nonce の存在が利用されており、59 BTC が盗難されたとしている。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> ということで,実装上の脆弱性が浮き彫りになった。 スマートカードのようにハードウェアに組み込むタイプのものは,いったん脆弱性や危殆化が発覚すると対処が難しい。 なので,やはり「事後」の対処がとても重要になってくる。(下手に隠蔽したり判断をミスったりすれば被害を拡大させてしまう) </p><p> ちなみに<a href="http://www.converterhub.com/index.php?sum=59&from=BTC&to=JPY">59BTCは290万円くらい</a>らしい。 </p> </section> <section id="sha3"> <h3>ハッシュ関数について</h3> <p> <a href="https://baldanders.info/blog/000702/">以前も述べた</a>が FIPS PUB 202 (SHA-3 Standard) のドラフトが登場している(パブリックコメントは既に終了している)。 </p><ul> <li><a href="http://csrc.nist.gov/publications/drafts/fips-202/fips_202_draft.pdf">DRAFT FIPS PUB 202: SHA-3 Standard<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul><p> 正式リリースは来年以降かな? </p> </section> <section id="dsa"> <h3>FIPS PUB 186-4</h3> <p> FIPS PUB 186-4 が登場している。 </p><ul> <li><a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">FIPS PUB 186-4: Digital Signature Standard (DSS)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul> <figure> <blockquote> <q>補助関数(ハッシュ関数、KDF、及び、擬似乱数生先の変更を認 成系、素数生成や楕円曲線生成等の基本的なアルゴリズム)を除いた、当該アルゴリズムを実装するための必要最小限の範囲において、パラメータ修正等の簡易な修正である。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> とのこと。 </p> </section> <section id="tls12"> <h3>SP800-52 revision 1 と TLS 1.2</h3> <p> 近年の SSL/TLS への攻撃(BEAST, CRIME, TIME. BREACH, Lucky Thirteen, Renegotiation)や <a href="https://baldanders.info/blog/000626/">RC4 の危殆化</a>を鑑み, TLS 1.2 へのアップデートが推奨されている。 </p> <figure> <blockquote> <q>推奨される設定として、TLS 1.0 より古いバージョンについては、新しいバージョンへアップデートすることが推奨される。TLS 1.0 については、CBC モードを用いた場合の脆弱性に対してパッチが提供されているため、Java 等のソフトウェアを最新版に更新した上で、CBC モードを選択することが推奨される。TLS 1.1 については、CBC モードを用いた場合の脆弱性が解消されていることから、CBC モードを選択することが推奨される。 TLS1.2 については、CBC モード、CCM モード、GCM モードが選択できるため、それらを使うことが推奨される。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> NIST では SP800-52 revision 1 を発行し TLS 1.2 への対応を行うことを進めている。 </p><ul> <li><a href="http://www.nist.gov/itl/csd/tls-043014.cfm">NIST Revises Guide to Use of Transport Layer Security (TLS) in Networks</a></li> <li><a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">Publication Citation: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations</a></li> <li><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015 | Threatpost | The first stop for security news</a></li> </ul> <figure> <blockquote> <q lang="en">“Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2,” the document says. “These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0.”</q> </blockquote> <figcaption>via <q lang="en"><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015</a></q></figcaption> </figure> <section> <h4>ところでクライアント側はどうなっているだろう</h4> <p> 主要ブラウザは TLS 1.2 のサポートを完了しているようだ。 </p><ul> <li>Google Chrome は 30 から全プラットフォームで正式対応</li> <li>Mozilla Firefox は 27 から全プラットフォームで正式対応</li> <li>Internet Explorer は 11 から既定で有効になっている(Windows Vista および 2008(無印)は非対応)</li> <li>Safari は 7 以降は全プラットフォームで対応</li> <li>その他 <ul> <li><a href="http://www.atmarkit.co.jp/ait/articles/1401/31/news141.html">JDK 8、TLS 1.2がデフォルトに - @IT</a></li> </ul></li> </ul><p> いやぁ, WinXP(および IE6)がなくなってホンマによかったよ。 (<span class="offrec">でもうちのサイトに来るブラウザの UA 見てると IE6 っぽいのがいまだにワンサカ来るんだけど。 IE6 & WinXP ってどのくらい残ってるのかねぇ。ちなみにうちのサイトはもう IE8 以前は見捨ててますので。 IE9 もダメかな,多分。 Safari は確認する手段を持ってないので知らない振りをする</span>) </p><p> ちなみに Firefox で Google のサイトを見ると </p> <pre class="brush:text" title="google.com 接続情報">TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</pre>
<p>
と表示される。
つまり TLS 1.2 下で Perfect Forward Secrecy を満たす ECDHE 鍵交換方式を使い AES 128bit アルゴリズムで GCM モードにより暗号化している(HMAC には SHA256 を使用),ということになる。
</p><p>
あとは古い AOSP(Android Open Source Project)版ブラウザだよね。
AOSP 版ブラウザはもともと WebKit から fork したものだが, Google 自身は2012年以降サポートを打ち切っている(Chromium があるからね)。
ユーザ側としては Chrome 等を導入して AOSP 版ブラウザを使わないようにするしかない。
他にも AOSP 版ブラウザには「同一生成元ポリシー回避の脆弱性」が指摘されている。
</p><ul>
<li><a href="https://community.rapid7.com/community/metasploit/blog/2014/09/15/major-android-bug-is-a-privacy-disaster-cve-2014-6041">Metasploit: Major Android Bug is a Privacy Disa... | SecurityStreet</a></li>
<li><a href="http://www.itmedia.co.jp/enterprise/articles/1409/16/news044.html">AndroidのAOSPブラウザに脆弱性、情報盗聴の恐れ - ITmedia エンタープライズ</a></li>
</ul>
</section>
</section>
<section id="pfs">
<h3>perfect forward secrecy と forward secrecy</h3>
<p>
どうもドキュメントによって表記に揺れがあるらしい。
</p><p>
<a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では
</p>
<figure>
<blockquote>
<q lang="en">Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the second mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. While support of these cipher suites is not required by these guidelines, it is strongly recommended.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
とあり, <q lang="en">perfect forward secrecy</q> の表記になっている。
一方 RFC3268 では
</p>
<figure>
<blockquote>
<q lang="en">At the same time the DHE ciphersuites are the only ones to offer forward secrecy.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc3268">RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)</a></q></figcaption>
</figure>
<p>
とあり,こちらは <q lang="en">forward secrecy</q> の表記になっている。
</p><p>
さらに RFC4949 では
</p>
<figure>
<blockquote>
<q lang="en">Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are compromised.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc4949">RFC4949: Internet Security Glossary, Version 2</a></q></figcaption>
</figure>
<p>
と書かれていて,両者の違いに一致した見解はないそうだ。
ちなみに <a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では <q lang="en">perfect forward secrecy</q> について
</p>
<figure>
<blockquote>
<q lang="en">Perfect forward secrecy is the condition in which the compromise of a long-term private key used in deriving a session key subsequent to the derivation does not cause the compromise of the session key.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
と定義している。
大雑把に言えば「長期的に使われる秘密鍵が漏洩しても、漏洩前のセッションで交換された鍵の秘密が漏れない」という解釈でいいようだ。
</p>
</section>
<section id="key-exch">
<h3>SSL/TLS における DHE, DH, RSA の安全性評価</h3>
<p>
TLS で使われる鍵交換方式である DH(Diffie-Hellman), DHE(ephemeral DH), RSA(RSAES-PKCS1-v1_5)を比較すると
</p><p>
DHE > DH > RSA
</p><p>
となるらしい。
これは
</p><ul>
<li><strong>DHE</strong>: 安全な認証機能付き鍵交換であり,かつ Perfect Forward Secrecy を満たす</li>
<li><strong>DH</strong>: 安全な認証機能付き鍵交換である</li>
<li><strong>RSA</strong>: 安全な認証機能付き鍵交換ではない(ただし RSA-OAEP を使う場合は安全な認証機能付き鍵交換である)</li>
</ul><p>
ということらしい。
ちなみに CRYPTREC では RSAES-PKCS1-v1_5 は「運用監視暗号」としてリストされ,「利用実績があることから当面の利用を認める」という条件で利用可能である。
</p><p>
参考:
</p><ul>
<li><a href="http://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf">政府機関の情報システムにおいて使用されている暗号アルゴリズム SHA-1 及び RSA1024 に係る移行指針<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p class="offrec">
(CRYPTREC の「電子政府推奨暗号リスト」では,「鍵共有」用途としては DH および ECDH(Elliptic Curve Diffie–Hellman)しかリストアップされていない(推奨候補にも挙がってない)。
CRYPTREC において DHE や ECDHE(ephemeral ECDH)がどのような位置づけになるか,今後の動向が注目される)
</p>
</section>
<section id="rnd">
<h3>擬似乱数生成アルゴリズム Dual_EC_DRBG</h3>
<p>
Dual_EC_DRBG については<q><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></q>を参照していただきたいが,最新動向として SP800-90 A Rev. 1 (2nd Draft) が登場している。
</p><ul>
<li><a href="http://csrc.nist.gov/publications/drafts/800-90/sp800_90a_r1_draft.pdf">DRAFT NIST Special Publication 800-90A, Rev. 1<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p>
このドラフトのパブリックコメントは2014年5月に締め切られている。
</p><p>
もともとこの脆弱性は2013年に Dual_EC_DRBG に NSA によるバックドアが仕込まれているという指摘からはじまったものだ。
NIST はこの脆弱性の修正に懸命になっているが,あまり芳しくないようである。
</p>
</section>
<section id="light-cipher">
<h3>軽量暗号</h3>
<p>
軽量暗号についてはまだまだこれからのようだが,いわゆる IoT(Internet of Things)を考える際には外せない要素技術であるといえる。
</p><p>
軽量暗号の特徴は以下のとおり。
</p><ul>
<li>ハードウェア規模が小さい,低消費電力で動作,消費電力が少ない,低コスト</li>
<li>コードサイズが小さい,RAM が少ない</li>
<li>低レイテンシ性,リアルタイム性</li>
</ul><p>
そして「軽量暗号の活用が期待されるアプリケーション」としては
</p><ul>
<li>RFID タグ,センサー,ワイヤレスセンサー</li>
<li>IC カード</li>
<li>医療機器(体内埋め込みや携帯型など),ヘルスケア製品</li>
<li>スマートメータ</li>
<li>モバイル製品</li>
<li>バッテリ</li>
<li>車, ITS システム</li>
</ul><p>
が挙がっている。
バッテリーかぁ。
</p><p>
車への応用は急務だろうね。
いまどきの車は ECU だらけだけどセキュリティに関してはこれからって感じだもんなぁ。
</p>
</section>
<section>
<h3>参考図書</h3>
<div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p>
<p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p>
<p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p>
</div>
</section>
CRYPTREC Report 2008
tag:Baldanders.info,2009-06-05:/blog/000453/
2009-06-05T09:00:00+00:00
2009-06-05T09:00:00+00:00
CRYPTREC より「CRYPTREC Report 2008」が公開されていた。
Spiegel
/profile/
<p>
<a href="http://www.cryptrec.go.jp/index.html">CRYPTREC</a> より<a href="http://www.cryptrec.go.jp/topics/cryptrec_20090530_c08report.html">「CRYPTREC Report 2008」が公開</a>されていた。
統一サイトがあるのはいいのだが,
トピックスのフィードくらい提供してくれ。
今時なんでこんなアナクロなサイト構成なんだろう。
</p><p>
とりあえず
<a href="http://www.cryptrec.go.jp/report/c08_wat_web_color.pdf">「CRYPTREC Report 2008 暗号技術監視委員会報告書」</a>(PDF)
くらいは目を通しておいたほうがいいだろう。
目につく内容としては,
電子政府推奨暗号リストの改訂とかある。
結構大掛かりな改訂になるらしい。
他には,
NIST で行われている次世代ハッシュ関数 SHA-3 のコンテストについて,
状況などが報告されている。
</p><p>
面白いところでは
<a href="http://www.cryptrec.go.jp/topics/cryptrec_20090530_c08report.html">「IDベース暗号に関する調査報告書」</a>(PDF)
なるものがある。
ID ベース暗号(Identity-Based Encryption; IBE)というのは,
電子メールアドレスなどの ID に基く暗号(署名や認証も含む)を指したものだ。
公開鍵暗号と違って煩雑な鍵の取りまわしを行う PKI が不要であるというのが売りである。
何年か前に結構話題になったような。
既に製品もいくつかあるよね。
売れてるのかどうかは知らないけど。
</p><p>
当時はよく分かっていなかったのだが,
今回の報告書を斜め読みしてなんとなく分かった。
IBE では PKI の代わりに PKG (Private Key Generator)というものがあって,
PKG によって(ID に基いて)復号が可能な仕組みになっているらしい
(「PKG がマスター鍵と共通パラメータの作成を行い,
このうち共通パラメータを周知させ,
PKG 自身がマスター鍵と利用者固有のID を用いて各利用者の復号鍵の鍵生成を行う」とある)。
PKG では ID さえ分かれば任意の暗号文を復号できてしまうので,
PKG は相当に信頼できる機関でなければならない。
どうやらここがポイントのようだ。
</p><p>
報告書では IBE の問題点を以下のように挙げている。
(長い引用でゴメン)
</p><blockquote>
「上記の通り,
IBE を利用することで,
公開鍵インフラにおける鍵証明書を排除できるものと大きく期待されているが,
その直接的な適用では必ずしも問題は解決されない.
つまり,
実利用においては,
鍵の更新や無効化の問題を考える必要があり,
これらを考慮すると,
結局はなんらかの方法で無効化された利用者情報などを利用者たちに掲示板などを用いて通知せねばならず,
また,
そのような通信路の存在を認める場合,
それを用いて従来の公開鍵暗号の公開鍵や鍵証明書もすべての利用者に配信可能であるため,
従来の公開鍵暗号に対する IBE の優位性はほとんど失われてしまう.
これは,
IBE を実利用する上での最大の検討事項と考えることができ,
IBE の利点を損なうことなく鍵更新と無効化を行う手法が明らかとならない限り,
現行の PKI から直ちに IBE に移行することには慎重になるべきである.
(中略)<br/>
また,
IBE では PKG がすべての利用者の復号鍵を作成するため,
PKG 自身も任意の受信者宛ての暗号文を復号することができてしまう.
そのため,
問題となりうる.
また,
ひとつの PKG ですべての利用者の鍵生成を行う場合,
PKG の負担が非常に大きいので,
PKI 同様,複数の PKG を階層的に用いて鍵生成を行う必要が生じる.
その際は,
通常の IBE ではなく,
階層的 IBE (HIBE) を利用しなくてはならないことにも注意したい.」
</blockquote><p>
たしかに PKG 側の運用の問題はあるが,
ユーザ側の利便性が上がるのは間違いないようだ。
IBE のベースとなっているペアリング技術についても悪い評価ではなさそう。
報告書によると,
色々と応用も考えられているし,
IETF,ISO/IEC,IEEE でも標準化の動きがあるようだ。
標準化のあたりはもう少し注目していってもいいかもしれないなぁ。
</p>