EAL認証で保証されること・されないこと

ハードウェアウォレットを比較したことがあれば、EAL評価がセールスポイントとして使われているのを目にしたはずです。EAL6+セキュアエレメントは、実現可能な中で最も高いセキュリティ基準を示唆します。これらの評価は実在し、認証プロセスも非常に厳格で、ラベルを持つチップは本当に厳しい基準でテストされています。
 

しかし、EAL認証はハードウェアウォレットのマーケティングで最も誤解されやすい概念の一つでもあります。しばしば「絶対的なセキュリティ保証」として紹介・解釈されますが、実際はそうではありません。
 

本記事では、EALの枠組みを基礎から解説し、EAL5+・EAL6+で実際に行われる評価プロセス、ハードウェアウォレットで使われている具体的なチップとその認証レベル、そしてEAL認証がカバーしない3つの構造的な限界について順に説明します。

EAL認証は、チップがどれだけ深く・厳密にセキュリティ評価を受けたかを示しますが、「絶対に破られない」という意味ではありません。これらは全く異なる主張であり、混同すると誤った安心感につながります。

Common Criteria（コモンクライテリア）とは？

Common Criteria（正式名称：Common Criteria for Information Technology Security Evaluation、ISO/IEC 15408）は、IT製品のセキュリティを評価するための国際的な枠組みです。1999年に、国ごとに分断されていたセキュリティ評価制度を統一する目的で策定されました。
 

現在では30カ国以上がCommon Criteria Recognition Arrangement（CCRA）に参加しており、CC認証は独立機関による製品セキュリティ評価の世界標準となっています。
 

評価対象（Target of Evaluation）

この枠組みは「評価対象（Target of Evaluation、TOE）」という中心概念で運用されます。TOEとは、実際に評価される製品やコンポーネントのことです。セキュアエレメントの場合、通常はチップ自体（ハードウェア構造、組み込みOS、暗号ライブラリを含む）がTOEとなります。

TOEの製造元はSecurity Target（セキュリティターゲット）という文書を提出します。これは「何を守るための製品か」「どんな脅威に耐えるべきか」「どのようなセキュリティ機能を実装しているか」「どの前提条件下で有効か」などを正式に記述した仕様書です。
 

認証の発行

認定された独立評価機関が、その主張内容に対して製品をテストします。テストの深さや厳密さは申請されたEALレベルに応じて決まります。製品がそのレベルのSecurity Targetを満たせば、各国の認証機関が認証書を発行します。

この構造の重要なポイントは、「評価は製品自身が宣言したSecurity Targetに基づいて行われる」ということです。控えめな保護機能を主張してそれを達成した製品も、広範な保護機能を主張してそれを達成した製品も、同じEALを取得できます。

EALは「評価の厳密さ」を測るものであり、セキュリティ設計そのものの野心や完成度を測るものではありません。これは多様な製品にCCを適用できるよう意図された設計です。

EALスケールの概要

Common Criteriaでは、EAL1からEAL7まで7段階の評価保証レベル（Evaluation Assurance Level）が定義されています。各レベルは、設計の文書化・分析・テストの徹底度や、想定される攻撃者の高度さによって要求が厳しくなります。

より高いEALレベルは、より安全な製品を意味するのではなく、「より徹底的に評価された製品」であることを意味します。

例えば、狭い範囲でも正しく実装されたセキュリティ機能を持ちEAL6で評価された製品が、より広範な機能を持ちEAL4で評価された製品よりも「現実の運用で安全」とは限りません。何がSecurity Targetに含まれているかによって異なります。

ハードウェアウォレットやセキュアエレメントの場合、EAL5+・EAL6+が該当レベルです。EAL4はOSやファイアウォールなどエンタープライズソフトウェアの標準。EAL7（最上位）は、実際には軍事・機密用途など極めて限定的な範囲でのみ使われます。
 

「+」サフィックスは拡張評価を示します：ベースレベルを超えた追加要件が評価に含まれていることを意味します。セキュアエレメントでは、特にAVA_VAN.5の脆弱性分析が重要です。これは最も高度な脆弱性分析レベルであり、評価者が「非常に高い攻撃能力」を持つ想定で最新の攻撃手法を用いて評価を行うことを求めます。

EAL5+・EAL6+で求められること

EAL5とEAL6の違いは、設計検証の深さと想定攻撃者の高度さにあります。どちらのレベルも、独立評価者によるチップへのペネトレーションテスト（侵入テスト）が必須です。
 

EAL5+：半形式的設計・テスト済み

EAL5+では、メーカーは半形式的な設計文書（チップのセキュリティ構造を数学的に記述した文書）を提出する必要があります。これは下位レベルよりも厳格な文書化です。

独立評価者はこれらの設計を分析し、弱点を探してペネトレーションテストを実施します。ここでは、高度な技術力・資金・動機・十分な時間を持つ攻撃者を想定した評価が行われます。

Ledger Nano Xで使われているSTMicroelectronics社のST33J2M0セキュアエレメントはEAL5+認証を取得しています。これは銀行用途や決済端末、多くの非接触型スマートカードで利用される標準的なチップです。
 

EAL6+：半形式的設計・テスト済み（拡張）

EAL6+では、EAL5+よりさらに広範囲かつ詳細な設計検証が求められます。チップ内部のより多くのモジュールや相互作用まで評価対象が広がります。

脆弱性分析も、より幅広い攻撃シナリオを含みます。想定攻撃者は「非常に高い攻撃能力」を持ち、最先端の手法・長期間の分析・高度な機材（フォールトインジェクションや侵襲的チップ解析など）を駆使することが想定されます。

EAL6+は、政府パスポートや銀行HSM、セキュリティ重視のコンシューマーハードウェアなど、単一ターゲットに多大なリソースが投入されうる環境で使われる標準です。

EAL6+認証を取得したチップは、専門のセキュリティ研究者がプロ仕様の機材で攻撃を試み、その範囲内では突破できなかったことを意味します。

Ledger Nano S Plus、Stax、Flexで使われるST33K1M5、Samsung Semiconductors（特にTangem Walletで採用されているS3D350ファミリー）、NXP SE050/SE051ファミリー、NXP P60/SmartMX2シリーズ、Infineon SLE78/OPTIGAファミリーはいずれもEAL6+認証を取得しています。これらはハードウェアウォレットの中でも高セキュリティ帯に属するチップです。

ハードウェアウォレットで使われているセキュアエレメント

EAL認証の主な3つの限界

EAL認証は、チップが高度な攻撃手法で真剣にテストされたことを示す最強クラスの独立保証ですが、構造的に3つの限界があります。

限界1：評価範囲の問題

すべてのEAL評価は、その評価対象（TOE）に縛られます。多くの場合、チップ単体が対象であり、それ以外は明確に評価対象外となります。これには実用上の影響があります。
 

チップ内部でも、評価されるのは特定のセキュリティ機能のみです。たとえば、RSA鍵演算の電力解析攻撃耐性で評価された場合、その機能に対してのみ認証が付与されます。
 

後から追加されたECDSA署名処理など、Security Targetに明記されていない暗号処理実装は、同じ保証が適用されません。

限界2：スナップショット問題

EAL認証は、ある時点・特定バージョン・特定構成の製品に対して発行されます。新たな攻撃手法が発見されたり、認証済み製品に脆弱性が見つかっても、認証自体が自動で失効することはありません。
 

このため、認証日とデバイスの現時点のセキュリティ状況にギャップが生じる場合があります。ケンブリッジ大学コンピュータ研究所のSkorobogatov氏とAnderson氏による2002年の研究では、40ドル以下の機材でセキュアマイコンやスマートカードに光障害注入攻撃が可能であることが示され、業界に大きな衝撃を与え、既存認証チップの対策見直しを促しました。

限界3：脅威モデルのギャップ

EAL6+では、想定攻撃者は非常に高い攻撃能力を持つとされています。これは商用セキュリティ基準としては厳格ですが、現実にデバイスが直面する全ての攻撃者を網羅するものではなく、機密技術による攻撃は除外されています。
 

評価機関が使うのは公開された攻撃手法のみです。情報機関などが有する非公開の研究成果や攻撃技術は評価に含まれません。
 

EAL6+とは、「十分な能力と資源を持つ独立評価者が、Security Targetで定義されたセキュリティ機能に対し、公開されている最先端手法でチップの突破を試みたが、評価範囲内では破れなかった」ことを意味します。「絶対に破られない」という意味ではありません。

まとめ

EAL評価は有用な指標の一つですが、あくまで「複数ある限定的な指標の一つ」です。

ウォレットを比較する際は：

• CCポータルでチップのバージョンを必ず確認する
• チップだけでなく、デバイス全体が独立監査を受けているか確認する
• ファームウェアのアーキテクチャ（イミュータブルファームウェアなど）がアップデート経路の攻撃を防げるか理解する