Help Net Securityのこの動画で、マサリク大学の研究スペシャリストであるMariia Bakhtina氏が、Common CriteriaやFIPS-140の認証が何を保証し、何を保証しないのかを解説しています。同氏のチームによる分析では、スマートカードを除く認証取得製品に対応付けられた脆弱性のうち、約6割が認証日より後に公開されていました。さらに同氏は、研究室で開発している2つのオープンソースツール「sec-certs」と「SCRUTINY」、そして購入者がベンダーに投げかけるべき1つの質問についても語っています。
購入予定の製品について、300ページに及ぶ認証文書を渡された調達担当者を想像してください。最初の1時間で何をするでしょうか。また、その文書はどの時点で役に立たなくなるのでしょうか。
幸い、認証文書（CCのSecurity Target、FIPS-140のSecurity Policyなど）は通常100ページ前後までで、300ページに達することはまずありません。それでも、通常はセキュリティの専門家ではない調達担当者にとっては大変な分量です。最初の1時間で確認するのは、製品の正確な名称とバージョン、保証レベル（想定される脅威、資産、対象となるセキュリティ要件を含む）、評価された構成、そして対象外と明記されている範囲だと思います。セキュリティ上の主張の本当の境界線はそこにあります。ただ、担当者が認証スキームの詳細（文書の構成など）に不慣れな場合、これらをすべて確認するには1時間以上かかるでしょう。
そして、文書が役に立たなくなるのは、それが過去のある時点の製品を切り取ったスナップショットだからです。文書からわかるのは、ある時点で何が評価されたかだけです。その後に何が見つかったのか、何が変更されたのかはわかりません。2024年に行った私たちの分析では、スマートカードを除く認証取得製品に対応付けられた脆弱性のうち、約6割が認証日より後に公開されていました。また、1つの認証文書だけでは、その認証がいまも有効かどうか、調達候補の他の2製品と比べてどうかもわかりません。こうした疑問に答えるには、複数の文書を横断して調べる必要があります。
「認証済み」という言葉は、いわば合格判定のように聞こえます。Common CriteriaやFIPS 140の認証は何を約束するもので、購入者はそこに何を誤って読み込みがちでしょうか。
おっしゃるとおり、一般の人にとって「認証済み」は「検証を受け、この種の製品に必要な基準をすべて満たしている」という意味に聞こえます。しかし実際には、必ずしもそうではありません。
まず、私たちのデータの大半が対象としているCommon Criteriaから説明します。CC認証が示すのは、認定を受けた評価機関が、定義された製品を、定義された構成で、ベンダーがSecurity Targetという文書に記したセキュリティ上の主張に照らして評価した、ということです。このSecurity Targetは、スマートカードのような製品タイプ向けのProtection Profileに基づいていることが少なくありません。つまり「基準を満たしている」とは、実際には「定められた範囲内で、ベンダーが主張した基準を満たしている」という意味です。認証は、評価がEALと呼ばれる所定の保証レベルのプロセスに従って行われたことも示します。約束されているのは主張とプロセスであり、製品が全般的に安全であることではありません。
FIPS 140は性質が異なります。暗号処理を行うハードウェア、ソフトウェア、ファームウェアといった暗号モジュールを、4段階のセキュリティレベルのいずれかでFIPS 140の要件に照らして検証するものです。約束されるのは、定義された境界内にあるそのモジュールについてだけです。アプリケーションや周囲のシステムについては何も保証しません。
購入者が主にCCについて誤って読み込みがちな点は、次のとおりです。
- 「脆弱性がない」：認証はそのようなことを示していません。ROCA、Minerva、TPM-Failはいずれも認証取得製品で見つかっており、高い保証レベルの製品も含まれていました。
- 「製品全体が対象」：機能が対象範囲から除外されることもあります。私たちが見つけたCC認証取得のネットワークカメラでは、ネットワークインターフェースが信頼できるものと想定されており、おそらくその部分はテストされていませんでした。
- 「購入するバージョンがテスト済みのもので、いまも最新である」：CC認証は固定された構成に適用され、有効期間も限られています。通常は5年で、その後はアーカイブされます。
- 「レベルが高いほど安全」：レベルが高いからといって、製品が全般的に安全とは限りません。それが示すのは、製品がどれだけ徹底的に調べられたかです。私たちのデータでは、高いレベルで評価された製品は、深刻度の低い脆弱性が多い傾向にありましたが、脆弱性の数が目立って少ないわけではありませんでした。多少は参考になるものの、保証にはならないということです。
認証文書を検索できるようになると、これまでコンサルタントや数日がかりの読み込みが必要だった、どのような問いに購入者が数分で答えられるようになりますか。
認証文書はスナップショットです。認証がいまも有効なのか、同じ製品の新しい認証があるのか、製品が何をベースに作られているのかは、文書からはわかりません。文書が検索可能になれば、これらをすべて素早く確認できます。認証を見つけ、まだ有効なのかすでにアーカイブされたのかを確認し、新しいバージョンや再認証が存在するかどうかも調べられます。
文書が参照している対象もたどれます。たとえば、製品の土台となっている認証取得済みのハードウェアやライブラリ、基準として使われているProtection Profileなどです。これらは別個の認証であり、別個の文書です。以前は、それらの存在を知っていて、自分で探し出さなければなりませんでした。製品の土台にあたる部分も信頼の対象に含まれるため、これは重要です。検索すれば適切な文書に素早くたどり着けますが、そこに書かれている内容は自分で読む必要があります。
sec-certsを知らない読者に向けて、数文で説明するとどのようなツールでしょうか。また、どのような課題を解決するために作られたのですか。そして、最初に利用するのはベンダーによる自社エントリの確認、購入者によるサプライヤー審査、セキュリティラボのうちどれでしょうか。開発を始めた頃の予想どおりでしたか。
sec-certsは、公開されている認証文書を、検索可能でリンクされたデータセットに変えるオープンソースのツールおよびWebサイトです。対象はCommon Criteria、FIPS 140、EUCCです。毎週、公式ポータルから文書を収集し、主要なデータを抽出して、認証と既知の脆弱性を紐づけ、認証同士が相互に参照しているかどうかを検出します。Webサイトでも、Pythonライブラリとしても利用できます。
このツールを作ったのは、これらの証拠資料がすべて公開されているにもかかわらず、実質的には使い物にならないからです。資料は各国の多数のポータルに分散する何千もの長大なPDFの中にあり、共通の識別子もなく、脆弱性データとの関連づけもありません。きっかけは、ROCAやMinervaの公表時にまさにこうしたものを必要とした、私たちの研究室（Centre for Research on Cryptography and Security、CRoCS）の研究者たちです（同僚のPetr Švenda氏が主導しました）。
最初に利用するのが誰かについては、特定の1グループではありません。寄せられたフィードバックによると、全員が使っていますが、目的は異なります。ベンダーは自社のエントリを確認します。認証同士が相互に参照し合うため、自社製品に依存する他社製品も探します。競合他社が何を認証取得し、どのように取得しているかも調べます。購入者は、特定の技術を使った製品を探すときに訪れ、それらの製品の認証文書を比較します。一方、セキュリティラボは、自分たちが専門とするカテゴリでまもなく期限切れになる認証を確認し、再認証の一環としてテストを請け負う見込み顧客を探しています。
予想と合っていたかについては、おおむねそうだと思います。ただ現時点では、利用者が誰で、どのように使っているかを体系的に追跡しているわけではないため、把握できているのは私たちに連絡をくれたユーザーからの限られた情報にとどまります。それでも、CCATプロジェクトのおかげで、いまチームが最も力を入れているのは、sec-certsをさらに役立つものにするために利用者からより多くのフィードバックを集め、利用者のニーズに関する私たちのより細かな仮説を裏づける、あるいは否定するデータを増やすことです。
ベンダーが、自社の認証を公開の場で検索、比較、相互参照できると知ったとき、どのような反応がありましたか。その反応から、市場で認証がどのように使われているのかが見えてきますか。
反応はさまざまです。それは、このツールが認証エコシステムの透明性を高めるという目的を果たしていることの表れだと思います。
前向きに捉えるベンダーもいます。自社製品がsec-certsに「ページ」を持っていることを、見込み客に示せるからです。sec-certsは非営利の研究プロジェクトによる独立した情報源です。そのため顧客は、ベンダー自身の資料よりも製品の認証状況を把握しやすくなります。ベンダー資料の場合、その信頼性を確かめるには、やはりさまざまな認証ポータルをたどらなければなりません。
一方で、私たちは認証を検索可能にしているだけではありません。認証取得製品に影響する可能性のある脆弱性との対応づけも行っていますが、その一致の精度は約89%にすぎません。認証の対象範囲があいまいに定義されていることが多く、ソフトウェア、OS、ハードウェアプラットフォームを識別するための構造化された機械可読の命名規則であるCPEとの対応づけが難しいためです。検出された一致はあくまで目安であり、確認が必要であることは明示しています。それでも、自社製品に潜在的な脆弱性が表示されることを、ベンダーは歓迎しません。
ここから私が感じるのは、ベンダーは、認証が顧客への信頼の証として機能するかたちで見えることは歓迎する一方、同じページに潜在的な脆弱性が並んで表示されることは好まないということです。また、認証が顧客に頼られるステータスとしてどれほど扱われているかも浮き彫りになります。
SCRUTINYは、チームが開発しているもう1つのツールです。暗号の専門外の人に、何をテストするもので、なぜ暗号機能を組み込んだ製品を購入する企業にとって重要なのかを説明するとしたら、どうなりますか。たとえば乱数生成器で統計的な異常が検出されたとします。購入者は「壊れている」と受け取り、ラボは「ノイズ」と言うかもしれません。人々が慌てることも、聞き流すこともないように、こうした発見をどう伝えますか。
SCRUTINYは、実際の製品をテストするツールキットです。スマートカード、TPMチップ、暗号化ディスク、暗号ライブラリなど、暗号機能を組み込んだものを接続すると、一連のテストを実行します。データシートと比べて、実際にどの暗号機能に対応しているのか。不審な入力や悪意ある入力にどう反応するのか。計算にかかる時間から秘密情報が漏れないか。乱数は本当にランダムなのか。結果はプロファイルにまとめられ、リファレンスと比較したり、読みやすいレポートにしたりできます。
購入者にとって重要なのは、認証が示すのは書類上で何が評価されたかにすぎないからです。暗号の欠陥は深刻でありながら、外からは見えません。Minervaがその例です。認証取得済みのカードに影響し、弱点は署名処理の所要時間にありました。これは測定してはじめて見つかります。
統計的な異常が検出された場合、私は「壊れている」とも「ノイズ」とも言いません。わかっていることをそのまま伝えます。「収集したデータでは、このテストで偏りが見つかりました。証拠の強さはこの程度です」と。そのうえで、新しいデータでも再現するかどうか、そして製品の使い方にとって何を意味するのかを伝えます。また、「問題なし」「要フォローアップ」「強い証拠をもって再現可能」という単純なレベル分けも使います。
SCRUTINYは、購入しようとしている製品が、認証のためにテストされた製品と同等の性能を発揮するかどうかを検証するためのツールです。もちろん、認証取得製品と購入製品との間で主張に差がないかを独立して検証する社内の専門知識が購入者にない場合は、ベンダーがその証拠としてベースラインの測定結果を提供するのが、ベンダー自身にとっても最善でしょう。
認証取得製品の契約を結ぶ前に1つだけ読むとしたら、何を読むべきでしょうか。また、ベンダーにぶつけるべき1つの質問は何ですか。
読むべきなのは認証の対象範囲です。具体的には、何がどのバージョン・構成で認証され、どのような前提や除外事項があるのかです。これはSecurity Target（またはSecurity Policy）に記載されており、認証レポートがその要約を載せています。これを把握するまでは、「認証済み」という言葉から得られる情報はごくわずかです。
ベンダーへの質問は1つです。「私たちがこの用途で購入するセキュリティ機能が、あなたが納品する正確なバージョンについて、認証文書のどこでカバーされているのか示してください」。示せるなら問題ありません。示せない場合や、「それは対象範囲外です」という答えだった場合、契約前に最も重要なことがわかったことになります。そのときが、SCRUTINYのような独立したテストを検討する価値のあるタイミングでもあります。
