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.
