製品作る気無いなら標準化するなよ。
<2016年10月1日追記>
コメントにも書きましたが、現在は、対象のページがリダイレクトされるようになっていて、製品情報とかが表示されるようになっています。ほかのURIでも試しましたが、普通に全体としてlabs.jpから-research.jpに転送されるようになっております。もし、一時的な不具合によって転送が働かないようになっていたのでしたら、元の日記における「てんでやる気無い」という九州大学とKDDI研究所に対する意見は失投であり不適切なものです。深く謝罪申し上げます。
しかし、KDDI研究所の製品実績にある、SmartMIMASは2010年11月16日にリリース、VistaFinderMXは2012年に販売開始されています。CRYPTREC暗号リストに掲載されるには利用実績が必要なのですが、これらは掲載されるための実績として強引に利用実績を作ったのでしょうか。ほかの記事で最近発売開始されたVistaFinderMX CloudにもK-Cipher2が搭載されているのであれば、なぜJCMVPでアルゴリズム確認くらいしようとしないのでしょうか。
CRYPTREC暗号リストに掲載されるということは、JCMVPの承認されたセキュリティ機能になることは当たり前ですし、承認されたセキュリティ機能になれば、それの確認手続きをJCMVPは用意するためのコストが発生します。ですので、CRYPTREC暗号リストに掲載されたからには、JCMVPにおいてアルゴリズム確認くらいするのは当たり前（そもそも自分たちが標準化を働きかけなければJCMVPのコストは発生しない）と思いますが、CRYPTREC暗号リストには価値があるけど、JCMVPには価値がないのでしょうかね（そうなんだろうけど）。<元記事。2016年9月30日、10時頃に掲載。>
今って平成28年ですよね。28年。で、CRYPTREC暗号リストなるものの最終更新日は、この日記を書いている時点で平成25年3月1日なのです。3年有りますね。で、皆様KCipher-2って知っていますか？Wikipediaによると、2007年に開発されたらしいですよ。九州大学とKDDI研究所によって。でもてんでやる気ないですよね。
ちょっとした好奇心でk-cipher2とGoogleで検索してみました。
で、一番上のサイトをクリックしてみました。
素敵な404だね！やったね！
で、そういえばこれってCRYPTREC暗号リストにあるから、JCMVPでも使用できるのかなー、って調べようと思ったら、承認されたセキュリティ機能にちゃんと挙げられています。いつからかは知らないけど。へー、じゃあJCMVPでモジュール自体の認証はお金がかかるし、誰も見向きしないから良いけど、アルゴリズム確認くらいやっているよね、と思って暗号アルゴリズム確認登録簿を見てみたけど無いのですよね。
これ、何のために標準化したの？どこで利用されているの？利用されていなかったらCRYPTREC暗号リストから落とされるんだよね？早く落とそうよ、標準化した会社でさえまともに使うつもりないのだから。
えぇと、回答例を用意してみました。
- そもそも標準化されたのが間違え -> 早くCRYPTREC暗号リストから落として貰えるように働きかけましょう
- 標準化したけど、JCMVPなんてどうでもいい -> CRYPTRECの委員の方々にはJCMVPに携わる方たちがたくさんいるので、JCMVPの無意味さを啓蒙しましょう。もう今後はCMVPだけでいいじゃないですか！
- その他
その他を選んだ方は、是非理由を教えてください。.go.jpでも、.co.jpでも.gmail.comでも言い分を聞きたいです。メールでこそっと言いたい場合は、プロフィールにメアドがありますし、そうでないのならコメント欄にどうぞ。あ、でもコメント欄に書いても通知されないし、あまり確認もしないので、メールでコメントしたと教えてくださいね。
こんな機能していない形だけの自己満足大会ならCYRPTRECもJCMVPもやめようよ。大学の教授様と企業の研究者様の自己満足の場だから見向きもされないんだよ。
暗号モジュール試験及び認証制度に関する説明会（0630）
JCMVPの最新情報を見ていると、セミナーをやりました、としかないのですが一向に認証された製品が増えない制度のセミナーをやって何か効果があるのでしょうか？理解できません。今のやり方でうまくいかないのならば方法を変えないとずっと変わらないかと思うのですが。
さて、そんな説明会の資料を見ていると気になることがありました。スライド10によると
GCHQ intervened to change the originaldesigns and save the £11bn nationwide system of smart energy meters against hackers on discovery of a fault, which meant all of the meters were given the same encryption key.
、とあってそれで見出しが
暗号モジュール試験及び認証制度の概要
第三者による評価の有効性(1)
、とあるのですが、同じ暗号鍵を使う暗号モジュールであってもISO 19790には適合できますよ。ISO 19790で暗号鍵自体に求められているのは適切なSEEDを用いて生成すること、くらいで鍵交換もしないのであれば別に同じ鍵を使い回しても準拠できますよ。なので、GHCQの例は暗号の実装の失敗ではありますが、JCMVPによって担保されうる実装の「成功」をもってしても解決することはできません。例としては不適切ですし、誤った印象を与えますね。
ICMCについての報告もあるけど、行ったなら発表すればいいのに。そこで知恵を募れば良いのに。我々はこの制度を立ち上げてペケペケ年たつのですが、全然需要が高まりません、何故ですか、って。
FIPS 140-3ってどうなってるの？
いっこうに話が聞こえないFIPS 140-3ですが、様々な思惑があるかと思います。試験機関のなかでの主権争い、どこまでを要件化するのか、そしてメジャーなベンダー間での争いです。
一時期あった140-3のドラフトでは、DPA/SPAへの耐性も必須になる、ということで、特許を持っている企業の鼻息荒くなったりしていましたが、スマートカードみたいなsingle chipのモジュールはまだしも、multi chipのモジュールはどのようにこれを確認するの？と大きな議論になりました。その後、FIPS 140-3はめでたく暗誦に乗り上げ、そしてそのまま…。
一部の話では、19790を更新して、それを140-3に落とし込むという話もあり、それを裏付けるようなPDFが僅かな期間だけ掲載されていましたが、それもすぐに取り下げられたのが現実です。えーと、FIPS 140-3はきっと日の目を見ず、東京オリンピックくらいまではFIPS 140-2は現役なのでしょうね。
Level2のSoftware Moduleは無駄以外の何でもない
FIPS 140-2では、Security Levelが1から4まで定義されていて、4がもっとも高いです。このうち、ソフトウェアだけで構成されている暗号モジュールはレベル2までしか取得できません。そうすると、Level 1よりLevel 2の方が良いよねー、と思ってしまいがちですが、これは嘘っぱちです。Security Level 2のソフトウェアモジュールは買うべきではないですし、企業もマーケティング目的でしか売っていません。
ソフトウェアだけで構成されている暗号モジュールにおいては、動作環境（Operational Environment）がくせ者です。Level 1ではGPC：General Pupose Computerで良いのですが、Level 2ではCC：Common Criteriaで評価を受けたOSが必須になります。世の中には、多くのCCを受けたOSはあります。Windowsを初めとして、Red Hat、SolarisもいくつかのバージョンではCCを取得しています。
ただし、CCを受けたバージョンのOSは評価をされた環境に限定されます。ですので、パッチ1つ当ててしまうと対象外になりますし、HWもCCを取得したものと同等でなければ対象外です。Level 2を謳うソフトウェアモジュールはその限定された環境を使用した場合のみ、Level 2としての価値があります。もし、まったく同じ構成でLevel 1も取得しているのであれば、環境を更新した場合にLevel 2ではなく、Level 1としての認証の効力を持ちますが、そうするとLevel 2の価値って何なの？となります。セキュリティパッチを適用できない、ということはOS自体に深刻な脆弱性があったとしても変更することはできません。HWを更新できない、ということは機能拡張のためにメモリを増やしたり、CPUを変えたり、ということもできません。
ですので、ソフトウェアモジュールが必要ならばLevel 1のモジュールで十分ですし、マーケティング目的のためにベンダーが用意するLevel 2のモジュールは相手にしてはいけません。
ソフトウェアライブラリにおける鍵生成のあれとこれと/dev/random
ソフトウェアライブラリで毎回頭を悩まされるのが、鍵生成のためのSEEDの確保です。HSMを初めとする、物理的な暗号モジュールの場合はTRNGのチップを用意することや、工場出荷時の段階でSEEDを書き込んでおいてそれを使用する、という逃げ道があるのですがソフトウェアライブラリではそうはいきません。
一方、FIPS 140-2においては、鍵生成を行う際には生成する鍵と同等レベルの強度を要するSEEDを用意する、という要件があります。ですので、256ビットのAES鍵を生成する場合は、SEEDも256ビットの強度を用意していなければなりません*1。実際には、SP 800-57で求められる強度を保有していれば良いのですが、それでも112ビットの強度をどうやって用意するの？という問題は永遠につきまといます。そこで逃げ道がいくつかあります。
1. SEEDの用意は暗号境界の外です、と利用者に責任をなすりつける
これが一番簡単な方法です。ライブラリとしては入力されたSEEDをそのまま信じるので、利用者が適切な強度を保有するSEEDを用意してね、となります。時間とか、時間とか、時間とか、時間とかを誤って利用者がSEEDとして使っても知らんぷりです。ソフトウェアライブラリが取得可能なFIPS 140-2の最高レベルは2であり、そのなかではモジュールがFIPS modeで動いているかどうかを確認できるようにする、という要件はないので、うっかり利用者が時間とか、時間とか、時間とか、時間とかをSEEDとして使用していて、non FIPS modeでモジュールが動いていても分かりようがありません。親切ですね。
2. 自前のTRNGもどきのDRNG*2を用意する
いくつかのライブラリではあるのですが、決定的な関数を使ってなぜか非決定的な値を作れるDRNGを開発します。この時に試験機関はそのDRNGがちゃんとしたセキュリティかどうかを試験しないといけないないのですが、そこは緩い試験機関を使えば大丈夫です。今は知りませんが、昔、とある試験機関*3ではSEEDは80ビット以上の長さであれば何でもいいんだよ、と言われて計りきれない衝撃を受けました。
3. OSが用意してくれているDRNGを利用する
Windowsの場合はCryptGenRandom、*NIXの場合は/dev/randomを使います。OSがアクセス可能な処理できっと乱数性があるであろうものをエントロピープールにいれておいて、そこである程度乱数っぽくなったら加工して吐き出してくれます。2点目のDRNGよりも深い領域でOSはアクセスできますし、アクセスする情報は通常のAPIではコールできないものも含まれます*4ので、信頼性はこちらの方が増すのかな、と思います。ただ、/dev/randomってどうなのよ感が定期的に沸き上がります。
/dev/randomですと、エントロピープールに情報をため込んでおいて、SHA-1で最後にハッシュして値を吐き出します。
The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy poo. From this entropy pool random numbers are created.
という記述がManページにはあります。この記述を利用者は信じて多くの利用者は256ビットの値を/dev/randomから吐き出したら256ビットの強度だよ！やったね！、という理論を作ります。その気持ちは分かるのですが、果たしてソフトウェアだけのDRNGでエントロピーが担保されている高品質の乱数を生成できるのでしょうか…*5。さらに、/dev/randomは吐き出す際にSHA-1でハッシュした値を出力します。そうすると、SHA-1の強度って？うんうん？と思わずにはいられません。いくつかのSecurity PolicyにはSHA-1で加工した値になるから160ビットの強度に限定されるよ、と書いてありますし、2030年までは128ビットの強度で問題ないとNISTが認めているので、160ビットの強度で十分なのかとも思いますが。
いずれにしろ、ソフトウェアライブラリにおいて、鍵生成は困難なのは変わりませんし、おなじFIPS 140-2を取得している、といっても程度の差は顕著です。個人的には、ソフトウェアライブラリ単体で高品質の乱数を生成するのは困難ですのでOSに任せてしまうのがベストかとも思います。その点ではMSはCSPも基本的にはFIPS 140-2認証を取得しているので未だ信用できる感があるのですが/dev/random自体の第三者評価ってどこもやっていないですよね…*6。
*1:この要件にはさんざん泣かされました…。
*2:Deterministic Random Number Generator。SP 800-90ではDRBG：Deterministic Random Bit Generatorと定義していますが、好き好きの問題と思い込んでいます
*3:いまはどこかに買収されています
*4:むかーーーーし、MSの方にその様に回答頂きました。*NIXは知りません
*5:むかし、MSのCryptGenRandomの乱数を調べた際には、ある程度の品質は認められたものの、フルエントロピーの乱数とは認められない、と第三者に評価されました
*6:いや、組み込み機器でLinuxベースの場合はそこに含まれるとは思いますがLinuxが用意している暗号周りの機能に関するFIPS 140-2認証は知りません。あるのなら教えてください…。
R.I.P, JCMVP
むかし、むかし、あるところ*1にCMVPというものがありました。政府調達*2のための必須要件だったことも手伝い、その制度は大変に流行しました。ベンダーは競って自社の製品で認証を取得しました。そして、日出づる国もその制度を倣いました。
JCMVPの誕生です。
しかし、JCMVPはCMVPとは違い、流行しませんでした。認証製品リストも公開されてからおよそ8年経ちますが、20しか製品がありません。そのうち、JCMVPでしか承認モード*3として動作できない暗号アルゴリズム*4を実装しているモジュールは4つしかありません*5。CAVPに該当するリストのCamelliaの認証数を見ても4件しかないのも、需要の無さをしみじみと感じさせます。自社で開発した暗号でさえ、興味 が ないのなら標準化なんかされても迷惑だと思うのは間違えでしょうか。電子政府推奨暗号に自社の暗号アルゴリズムを登場させることに熱心だった方々は、それがゴールだったのでしょうか。暗号アルゴリズム確認登録簿に名前すら登場しないアルゴリズムを開発した企業名も委員名簿にはチラホラ見えるのは気のせいなのでしょうか。
先日、Real World Crypto 報告会＆ディスカッションに参加した際には、日米の違いとして、日本の場合は調達の仕様書をベンダーが書く、という話がありました。私は常々、官側から強制することが必要と考えていましたが、政府統一基準において、JCMVPで取得された暗号モジュールの利用を強制する遵守事項はありません*6。一方で、その認証の取得を強制する仕様書も見たことがありません。せっかく自社の暗号を標準化したベンダーも、それを仕様書において強制させることを怠っていたのではないでしょうか*7。
JCMVPの失敗はそれぞれのステークホルダーが招いたのだと、今は思います。強制させられなかった国、暗号アルゴリズムを標準化させることで満足してしまった企業、関心がなかった利用者。そこに、CMVPとJCMVPの片務的相互認証が始まったことから、この制度はさらに形骸化していったと思います。CMVPで使用できる暗号アルゴリズムはすべてJCMVPにおいても承認モードで使えるのに対して、JCMVPで使用が可能なCamelliaはCMVPではnon-FIPS modeでしか動作できないからです。こうなってしまうと、CMVPで認証を取得して、「ついで」にJCMVPの認証も取ってしまえば良いというロジックが成り立ってしまいます。JCMVPの必要性がいっそう薄れてしまったのです。
2014年、JCMVPでは1件も新しい暗号モジュールが認証されませんでした。CMVPの「ついで」にJCMVPの認証が取れるにも関わらずです。一方のCMVPは235件の暗号モジュールが新たに認証を取得しました。JCMVPはそのあり方を広く議論すべき時を迎えているのではないでしょうか。CRYPTRECシンポジウム2015では議論される気配すらありませんが、官、民、そして利用者を交えて国としてJCMVPをどうするか議論しないと、せっかくの暗号アルゴリズムを開発できる技術力も使われることなく、パーツだけは作れるけど全体の絵を描けない構造からいつまでも脱することができません。ステークホルダー間で広く議論が行われ、そしてJCMVPがその役割を果たす日がいつかくることを願っております。
Até breve, obrigado.
2013 年度 暗号技術活用委員会活動計画（案）について
http://www.cryptrec.go.jp/report/c13_kentou_giji01_4.pdf
を読んでいるとガッカリする。
2012 年度の暗号技術の利用状況に係る調査結 果からは、旧電子政府推奨暗号リスト策定から 10 年経過していたにもかかわらず、同リストに掲載さ
れていた国産の暗号アルゴリズムの普及がほとんど進んでいない実態も明らかとなった。
まるで他人事。10年間何やってたの？なんで普及しなかったか考えなかったのかな。
そのため、本委員会では、「暗号政策上の課題の構造」や「暗号と産業競争力の関連性」などの課題 に対する分析について約 2 年間の集中審議期間を設けることにより、暗号アルゴリズムの普及促進や セキュリティ産業の競争力強化に向けた障壁が何かを明らかにするとともに、その解決策を取りまと める。
うぅんと、凄い単純だと思うのですが。国策の暗号アルゴリズムを使うメリットが無いのが一番の問題でしょ。JCMVPの認証モジュールリストを見てみれば直ぐ分かると思うのですが。どこかのストリーム暗号を作ったベンダーの暗号モジュールの共通暗号にAESしか使われていない理由を考えたことはないのでしょうか。
もう少しビジネスを考えられる人がCRYPTRECなり、IPAなりに必要だと強く思います。
