Sunset Policy
こんにちは。
CMVPでは、2017年2月1日より有効になったSunset Policyなるものがあります。これによってモジュールの認証の有効期間は5年間に縛られ、試験機関の確認、評価機関の検証なしには認証は無効となります。
これを受けて、2012年2月1日より前に認証を取得したモジュール、FIPS 140-1において認証を取得したモジュールはすべて無効となりました*1足の長い製品を提供しているベンダーにとてはなかなか頭を悩ませるものです。また、一度取得したからといってずっとその認証番号を使ってきたベンダーにも決して歓迎される内容ではありませんでした。
さて、我らがJCMVPにはこの制度はありません。一方で、CMVPとJCMVPは共同認証なるものがあり、差異が無い範囲で片方の認証のみでもう片方も有効になるという素晴らしい制度です（これって未だ有効なのか、少しだけ知りたいです）。
あれ、そうするとこの共同認証を使って、5年が経つとCMVPでは無効だけどJCMVPでは有効、というチグハグな状況ができるのかな？と当然の疑問が沸きます。偶然、過去に協同認証を取得した素晴らしい製品があったので確認ができます！
CMVP側で確認したら、ありましたHistorical Listに。そして、JCMVPではもちろん有効なままですね。
JCMVPには目もくれずCMVPのみを頑張っていらっしゃるベンダー様たちにおかれては、有効期間が無期限のJCMVPをご一考される要素になれば幸いです。あ、調達において意味がないからどうでもいっか。
*1:有効になった当時。無効になっていく賞味期限切れのモジュールは日々増えています。
気づいたら2019年
気づいたら2019年で、前々記事で放置されっぱなしだと指摘した「承認されたセキュリティ機能」もだいぶ前に直されました。指摘有り難うございます、という謝辞は一切こなかったのだけが残念です。
そんな状況でも相変わらずK-Cipher2は一件もアルゴリズム確認をしていません。開発者自体が制度の普及のために努力しないアルゴリズムなんか国策で選ぶなよ。研究者様たちの自己満足でやっているから誰もこんな制度使わないんだよ。、と思うのでした。
どうでもいいか、こんな制度。早くCMVPへのリンクだけにしてしまえば良いのに。
あ、CMVPで取り入れられているSunset Policy（5年で認証が無効になる）は導入した方が良いと思うよ！そうしたら、少なくとも5年後には認証製品は1つもなくなってCMVPへのリダイレクトをしても誰も文句を言わなくなるよ！
その資料は公開して大丈夫？
その暗号モジュールは大丈夫？を今更ながら読んでみました。変わり映えしないだろうから、と放置していたけど、こんなに素晴らしい資料だったなんて！！
slide 2
・暗号モジュールとは、「承認されたセキュリティ機能」をソフトウエア/ファームウエア/ハードウエアで実装したものである。、と言い切っています。なので、承認されたセキュリティ機能を実装していない暗号モジュールの皆様、あなたたちは暗号モジュールではありません。せめてJCMVPにおいては、とか書けば良いのに。
・このHSMってこれですよね。IPA公認のHSMです！JCMVP Loveの皆様、是非こちらのHSMをご採用ください！！
slide 3
・安心して使用できる暗号モジュール？とあるなかで、アルゴリズムの強度が挙げられています。slide 2で承認されたセキュリティ機能に限定しているのに！承認されたセキュリティ機能の皆様、JCMVPに依ると強度に不安があるようです。
slide 13
・重要情報が保護されている、って言い方は斬新ですね。（暗号モジュールの健全性の担保、及び暗号処理における）重要情報が保護されている、と書かないことによってユーザーが重要だと思った情報（例えば暗号化されたファイルとか？）も保護されていると読み取れます。
slide 14
・2017年なのにSHA-1が残っているのは木の精…木の精。
slide 19
・実績をマッピングさせるとなお良いと思いますよ！J0021、と21件もあるのですから是非！ちなみに0000ってことは1000件は行くだろうなーと思って番号を振り始めたのですね。当時の気持ちを思いだして欲しいです。
slide 20
・サイドチャネル攻撃って評価の対象だったのですね。これは勉強不足でした。。。ISO/IEC 19790の新版を購入して読まなければと強く思いました。
実装可能な承認されたセキュリティ機能
どこぞのストリーム暗号の仕様が403になっていたので、ほかの承認されたセキュリティ機能についても調べなければ、と強く思いました。JCMVPのトップページは定期的に更新されているのにかかわらず、こちらのページは3年以上更新されていません。
署名
1. DSA - ARCHIVED PUBLICATION（最新は186-4）
2. ECDSA - そもそもリンクがない（あと、これ、ANSじゃなくてANSIじゃないの？）
3. ECDSA - ARCHIVED PUBLICATION（最新は186-4）
4. ECDSA - certicomのサイトに飛ばされる
5. RSASSA-PKCS1 v1.5 - ついに有効なリンク
6. RSASSA-PSS - 有効なリンク
守秘
7. RSA-OAEP - 有効なリンク
結論：唯一使用可能なRSA-OAEPを使用するのが吉
共通鍵
64ビットブロック暗号
1. TDES - Publication Moved
128ビットブロック暗号
2. AES - Publication Moved
3. Camellia - 有効なリンク
n-bitブロック暗号の利用モード
4. ECB, CBC, CFB, OFB, CTR - Publication Moved
128bitブロック暗号の利用モード
5. XTS - Publication Moved
ストリーム暗号
6. KCipher-2 - 403 Forbidden
結論：Camelliaを純粋に使いましょう。ECBで。
ハッシュ
1. SHS - ドラフトのリンクだと注意される
結論：諦めよう
メッセージ認証
1. HMAC - Publication Moved
2. CMAC - Publication Moved
3. CCM - Publication Moved
4. GCM/GMAC - Publication Moved
結論：諦めよう
決定論的乱数生成器
1. PRNG, ANSI X9.42 - 但し、2015年末を以て承認されたセキュリティ機能から取り消す。（2017年になってもサイトは更新せず放置している）
2. FIPS 186-2 PRNG - 但し、2015年末を以て承認されたセキュリティ機能から取り消す。（2017年になってもサイトは更新せず放置している）
3．FIPS 186-2 PRNG - 但し、2015年末を以て承認されたセキュリティ機能から取り消す。（2017年になってもサイトは更新せず放置している）
4. ANSI X9.31, TDES PRNG - 但し、2015年末を以て承認されたセキュリティ機能から取り消す。（2017年になってもサイトは更新せず放置している）
5. ANSI X9.31, AES PRNG - 但し、2015年末を以て承認されたセキュリティ機能から取り消す。（2017年になってもサイトは更新せず放置している）
6. Hash_DRBG, HMAC_DRBG, CTR_DBRG - Archived NIST Technical Series Publication
結論：諦めよう
鍵共有
1. DH - Archived Publication
2. MQV - Archived Publication
3. ECDH - Archived Publication
4. ECDH, SEC 1 - certicomのサイトに飛ばされる
5. ECMQV - Archived Publication
6. SP800-56B - 有効なリンク
7. KDF - Publication Moved
8. KDF - Publication Moved
9. KDF - Publication Moved
10. KDF - Publication Moved
結論：SP800-56Bを使おう。あと、KDF多すぎ
、ということで、CRYPTREC暗号リストで何を使えば分からない方は、JCMVPに従うとあっさりと実装するアルゴリズムを決められます！
共通鍵：Camellia（ECB only）
署名：RSASSA
守秘：RSA-OAEP
共有：SP800-56B
このページの更新履歴を見ると、2013年10月7日 PKCS#1 v2.2のリンク先URLを更新、とあるので、リンク先を更新することは可能だけど敢えて更新していない、ということを汲み取らないといけません。決してサボってる、とかリンク先が生きているかを確認することすらできないほどのぺけぺけ、なんて勘ぐるのはやめましょう。
CRYPTREC Report 2016; ChaCha20-Poly1305
まったく気づかないうちにCRYPTREC Report 2016が公開されていました。（あまりにも周知されていないと思うけどなんなんだかね…）。
2.4節に「ChaCha20-Poly1305のCRYPTREC暗号リストへの追加を視野に入れた評価について」というのがあって少し混乱しましたが読んでみました。1. 評価結果は他者の評価の概要。2. の暗号技術評価委員会の審議結果は別にいいんじゃないの、という内容。3. の暗号技術検討会は査読付きの国際会議でOKにしたのもあればそうでないけど、国際標準化等されてもOKっていったことあるしー、ChaCha20-Poly1305は前者には当たらないけど*1CRYPTREC暗号リストに向けて評価をするのなら自分たちで決めて、暗号技術評価委員会に評価させなきゃ、という内容で、何を審議したのかよく分かりませんでしたし、前項における暗号技術評価委員会の審議結果に異議があるんだかないんだかも読み取れない、とても難解な日本語です。
、と前置きはこの程度にして、ChaCha20-Poly1305をCRYPTREC暗号リストに追加すべきかどうか、って答えは明確にNOでしょう。CRYPTRECは国産の暗号の普及のためにやっていた認識ですが、米国の一企業が大きくプッシュしているからといって、NISTがFIPSに制定することもきっとないでしょう。昔の電子政府推奨暗号で国産ではなく、FIPSでも制定されていない*2暗号といえばRIPEMD-160とRC4しかなかった認識です。RIPEMD-160が何故電子政府推奨暗号になっていたのかは理解していませんが、RC4はSSLで広く使われていましたし、フィーチャーフォンではRC4が最上位の暗号スイートだったと記憶していますので、しかたない感は伝わってきます。
一方、ChaCha20-Poly1305がでてきたとしても今は他に選択肢はあるわけですし、CMVPで許可されることが永遠にないであろうアルゴリズムをJCMVPで国産でもないのに使用を許可するのは強い違和感を覚えます。、といっても暗号アルゴリズム確認登録簿が2年ぶり以上に更新されても相変わらず承認されたストリーム暗号が一件もないから気概を感じないですね。。。仕様も403エラーなので誰も実装できないのでしょう。残念です（下図は2017年7月29日、14:20時点。ちなみに一週間以上前からこの状態）。
Happy Holidays, JCMVP!!
この前、アメリカに行く機会があり、昔のなじみだったFIPS 140-2試験機関の方とお話しできてなかなか楽しかったです。
今年は一個もモジュールが認証されなかったしね、と思ってトピックスをさっき見たら12月1日 暗号モジュール認証製品リストを更新しました。、とあってまじで！まじで！ちゃんと確認してなくてごめん！と思って暗号モジュール認証製品リストを喜んで開いたのですが、一番上のモジュールはあれ、これ見覚えあるし、何も変わりないよね、と思いながら認証が更新されたモジュールがあったと気づく有様です。
アメリカのCMVPは相変わらず景気が良くて、前出の方もビジネスは絶好調だと言っていました。あ、今年はJapanでページ内検索するとそこそこ日本企業の暗号モジュールが目につくのが嬉しいです。この共同認証制度があまり活用されていないのは寂しいですけどね。
最後に、決定的乱数生成器コーナーで「但し、2015年末を以て承認されたセキュリティ機能から取り消す。」、って書かれているけど、暗号モジュール認証製品リストを見る限りでは何も更新されてないから変わらず使って良いのかな。暗号モジュール認証書も更新されていないし。NISTの場合はもう使えないモジュールの場合は、Historicalとあって分かりやすいですね。リストまであるのは流石だなーと思いました。
それではよいお年をお迎えください。
