暗号アルゴリズムの実装方式とリスク分析に関する調査 ·...

電子政府情報セキュリティ技術開発事業

暗号アルゴリズムの実装方式とリスク分析に関する調査

調査報告書

平成 15 年 2 月 28 日

情報処理振興事業協会

セキュリティセンター

1

Microsoft、Outlook Express などは、米国 Microsoft Corporation の米国および、その他の国にお

ける登録商標または商標です。Chrysalis-ITS, Luna などは、米国 Chrysalis-ITS Inc. の米国およ

び、その他の国における登録商標または商標です。

その他、本書に掲載されている会社名、商品名、製品名などは、一般に各社の商標または登録商

標です。

2

目次 1. 調査の概要.....................................................................................................................................5

1.1 背景 ...........................................................................................................................5 1.2 目的 ...........................................................................................................................5 1.3 調査項目 ....................................................................................................................5 1.4 調査内容および調査方法 ............................................................................................6

2. 暗号技術に関する CC と CMVP の統合運用環境実例調査 ...................................................10 2.1 CC 運用の実例.........................................................................................................10

2.1.1 実例調査............................................................................................................10 2.1.2 調査結果............................................................................................................12

2.2 CMVP 運用の実例 ...................................................................................................18 2.2.1 実例調査............................................................................................................18 2.2.2 調査結果............................................................................................................19

2.3 CC と CMVP の併用 ................................................................................................28 2.3.1 メリット ................................................................................................................28 2.3.2 課題点・制約 ......................................................................................................29 2.3.3 対策 ...................................................................................................................30

3. 複数の暗号アルゴリズム実装方式に関するリスク分析と脆弱性評価 .....................................35 3.1 複数の暗号アルゴリズムを実装したシステムの事例 ...................................................35

3.1.1 事例 1: USPS (United States Postal Service) , IBIP.......................................35 3.1.2 事例 2: 米国政府系銀行 FB (仮称) ...................................................................39 3.1.3 事例 3: 株式会社オレンジソフト、S/Goma .........................................................43 3.1.4 事例 4: 三菱電機株式会社他、Crypto-API........................................................46

3.2 暗号アルゴリズムの単一実装と複数実装の差異分析 .................................................50 3.2.1 システム設計......................................................................................................50 3.2.2 システム構築......................................................................................................51 3.2.3 システム運用......................................................................................................52

3.3 複数暗号アルゴリズム実装の脅威低減の方策 ...........................................................54 3.3.1 メリット ................................................................................................................54 3.3.2 脅威 ...................................................................................................................54 3.3.3 対策 ...................................................................................................................55

4. その他実装方式に関する重要事項 ............................................................................................56 4.1 米国における暗号実装技術の最新動向.....................................................................56

4.1.1 サイドチャネル攻撃の状況 ..................................................................................56

3

4.1.2 サイドチャネル攻撃対策の研究・開発動向...........................................................59 4.1.3 テンペスト攻撃の状況 .........................................................................................62 4.1.4 テンペスト攻撃対策の研究・開発動向..................................................................63 4.1.5 耐タンパー技術の研究・開発動向........................................................................63 4.1.6 耐タンパー性評価の状況 ....................................................................................66

4.2 CMVP における対応状況と今後の対応.....................................................................68 4.2.1 現在 CMVP で行われている対応 .......................................................................68 4.2.2 CMVP の今後の対応.........................................................................................70

5. まとめ.............................................................................................................................................74 添付資料 ............................................................................................................................................75

添付資料 A-1. 調査項目 1 の NIST および Lab 向けインタビュー質問票 ........................76 添付資料 A-2. 調査項目 1 の開発ベンダー向けのインタビュー質問票...........................78 添付資料 A-3. 調査項目 2 用 (システム開発者向け) インタビュー質問票 .....................80 添付資料 A-4. 調査項目 3 用のインタビュー質問票 ......................................................82 添付資料 B-1. ActivCard インタビューメモ .................................................................83 添付資料 B-2. Chrysalis-ITS インタビューメモ...........................................................85 添付資料 B-3. Spyrus, Inc. インタビューメモ..............................................................88 添付資料 B-4. Hasler, Inc. インタビューメモ...............................................................92 添付資料 C-1. USPS インタビューメモ ........................................................................95 添付資料 C-2. USPS 事例調査..................................................................................99 添付資料 C-3. Federal Bank 事例調査................................................................... 111 添付資料 C-4. 株式会社オレンジソフトインタビューメモ ............................................ 119 添付資料 C-5. セコムトラストネット株式会社インタビューメモ ..................................... 120 添付資料 C-6. 株式会社富士通研究所インタビューメモ .......................................... 121 添付資料 D-1. Cryptography Research, Inc. インタビューメモ ............................... 122 添付資料 D-2. InfoGard Laboratories インタビューメモ......................................... 124 添付資料 D-3. RSA Laboratories インタビューメモ .................................................. 126 添付資料 E. 調査項目 1 分析結果 (原文) ................................................................ 128 添付資料 F. 調査項目 2 分析結果 (原文)................................................................. 153 添付資料 G. 調査項目 3 分析結果 (原文)................................................................ 180 添付資料 H-1. CC 評価機関の一覧........................................................................... 185 添付資料 H-2. CMVP 評価機関の一覧..................................................................... 188 添付資料 I. 用語 .......................................................................................................190 添付資料 J. 参考文献、参考資料 ............................................................................... 194

4

1. 調査の概要

1.1 背景

2001 年 3 月に政府 IT 戦略本部において決定された e-Japan 重点計画ではインターネットを利用し

た行政情報の電子的提供、申請・届出等手続きの電子化等を主な具体的施策とする「電子政府」

を 2003 年度までに実現することを目指している。また、高度情報通信ネットワークの安全性及び信

頼性確保のため、「暗号技術の標準化の推進」を具体的施策の一つに挙げている。これに伴い、

わが国では電子政府システムにおける重要な課題である情報セキュリティを確保するための暗号

の評価・認証制度の整備に向けた検討を、国際標準化の流れを汲み取りながら行う必要がある。

1.2 目的

わが国の暗号技術を含んだ情報セキュリティ評価認証制度の整備に際して考慮すべき点を整理

する上で、国際的な情報セキュリティ評価基準となっている ISO/IEC15408 （Common Criteria:

CC）と、新たに ISO/IEC 化が進められている FIPS 140-2 に基づいて米国・カナダで運用されてい

る暗号モジュール評価制度 CMVP (Cryptographic Module Validation Program) の運用の実例を

分析検証することが役立つと考えられる。さらに、電子政府システムの実現において、複数の暗号

アルゴリズムを実装する場合が今後考えられるが、その場合の脆弱性についての調査分析も必要

となる。

本プロジェクトでは、これら暗号技術に関する CC と CMVP の評価制度の調査を行い、両制度を併

用して運用する際の課題や可能性、および環境条件等を分析する。また、複数の暗号アルゴリズ

ム実装方式に関するリスク分析を行い、電子政府システムにおいて複数の暗号アルゴリズムを実装

する場合のセキュリティ上の影響について調査する。さらに、実装攻撃対策などの暗号実装技術

に関するその他重要事項についても調査する。

1.3 調査項目

本報告書では、前項の調査の目的を達成するため、主として米国及びカナダの具体例を基に以

下の三つの調査を実施した。

暗号技術に関する CC と CMVP の統合運用環境実例調査 •

•

•

（暗号モジュール評価結果の CC での活用策等）

複数の暗号アルゴリズム実装方式に関するリスク分析と脆弱性評価

その他実装技術に関する重要事項（暗号実装攻撃に関する対策等）の調査

5

1.4 調査内容および調査方法

前述の 3 つの調査項目のそれぞれに対して行なった調査内容と、その調査方法を本項で説明す

る。

(1) 暗号技術に関する CC と CMVP の統合運用環境実例調査

情報セキュリティ製品・システムの評価・認証制度である CC と暗号モジュールの評価・認証制度で

ある CMVP を今後日本で統合運用する場合の可能性、制約、問題点等を洗い出すために、実際

にこの二つの制度が併用されている米国・カナダでの実情を調査分析した。

＜文献調査対象・機関＞

FIPS (Federal Information Processing Standards)

Common Criteria Project

CMVP Conference

NIST (National Institute of Standards and Technology)

CSE (Communications Security Establishment)

＜ヒアリング対象者＞

NIST/CSE の CC および CMVP 関係者

CC および CMVP の民間評価機関

CC または CMVP の評価認証を受けたベンダー

暗号製品を使うシステムベンダーまたはインテグレーター

＜調査項目＞

(1-1) CC 運用の実例

a. 評価・認証の実施フロー

b. 期間

c. 費用

d. 評価要員数・スキルレベル

e. 提出物・フォーマット

f. CMVP との使い分け

g. CMVP の結果の利用や参照の有無

(1-2) CMVP 運用の実例


b. 期間

c. 費用


6


f. CC との使い分け

g. CC の結果の利用や参照の有無

(1-3) CC と CMVP の併用

a. メリット

b. 課題点・制約

c. 対策

(2) 複数の暗号アルゴリズム実装方式に関するリスク分析と脆弱性評価

電子政府システムにおいて、複数の暗号アルゴリズムを実装する場合の脆弱性を明らかにし、その

脅威を低減する方策を検討するために、主な電子政府システム･アプリケーションの事例を調査分

析した。

＜文献調査情報源＞

複数暗号アルゴリズムを実装した CMVP 認証暗号製品

電子政府システムのインテグレーター（Veridian 等）

電子政府システムのアプリケーション（電子申請システム等）

IPA セキュリティセンター

国内電子政府関連

米国電子政府関連






米国および日本の電子政府システム開発関係者

＜調査項目＞

（2‐1）複数の暗号アルゴリズムを実装したシステム

米国および日本の電子政府システムにおいて、複数の暗号アルゴリズムを実装した事例について

調査する。たとえば、次のような形で複数の暗号アルゴリズムを実装した事例を想定する。

1 つの暗号アルゴリズムがブレイクされた場合、バックアップの暗号アルゴリズムを使うシ

ステム

単一アルゴリズム実装のサブシステムを切り替えて、複数アルゴリズムを実装したシステ

ム

7

(2‐2) 暗号アルゴリズムの単一実装と複数実装の差異分析

電子政府システムにおいて単一実装と複数実装の再分析を次のような項目に対して行なった。

1. システム設計

a. 設計および設計コスト

b. 暗号製品選定

c. データフロー上の各ポイントにおける脆弱性

2. システム構築

a. 構築コスト

b. テスト

c. システム構築における脆弱性

3. システム運用

a. 運用コスト

b. システム利用者（政府、運用管理者、エンドユーザ）への影響

c. 鍵管理

d. インシデント対応

e. システム運用における脆弱性

（2‐3）複数暗号アルゴリズム実装の脅威低減の方策

複数暗号リズム実装における問題点とその対策を洗い出すために、次のような項目に対して分析

を行なった。

1. メリット

2. 脅威

3. 対策

（3）その他暗号実装技術に関する重要事項の調査

暗号実装技術に関する米国での最新動向を調査し、暗号実装技術の脅威に対して、CMVP での

現在の対応状況と、日本で CMVP 相当の暗号モジュール評価認証製制度を運営するにあたって

の今後の対応について分析するため、文献、URL 等の調査およびヒアリング調査を実施した。

＜文献調査情報源＞

学会及びワークショップ


8

上記学会及びワークショップ関係者





＜調査項目＞

(3-1) 暗号実装技術に関する最新動向調査

1. サイドチャネル攻撃の状況

2. サイドチャネル攻撃対策の研究・開発動向

3. テンペスト攻撃の状況

4. テンペスト攻撃対策の研究・開発動向

5. 耐タンパー技術の研究・開発動向

6. 耐タンパー性評価の状況

(3-2) CMVP における対応状況と今後の対応

1. 現在 CMVP で行なわれている対応

2. CMVP の今後の対応

9

2. 暗号技術に関する CC と CMVP の統合運用環境実例調査

2.1 CC 運用の実例

CC (Common Criteria) とは、情報システムやそれを構成するハードウェアおよびソフトウェアにつ

いて、目標とするセキュリティ保証レベルにより規定される評価基準に基づいた評価・認証を実施し、

その結果を公開する国際規格の名称である。米・英・仏など欧米先進諸国において、これまで国防

上の観点から実施されてきたものを、1998 年 10 月に国際共通化を図るため CC として策定した。

1999 年 12 月、「ISO/IEC15408 情報技術セキュリティ評価基準」として国際規格化され、Common

Criteria 立案国 (カナダ、フランス、ドイツ、英国および米国) にオーストラリア、ニュージーランド、

オーストリア、フィンランド、ギリシャ、イスラエル、イタリア、オランダ、ノルウェイ、スペイン、スウェー

デンの 16 ヶ国が加盟調印国として参加した。日本は加盟申請中で、2003 年 4 月の加盟を予定し

ている。ISO/IEC15408 は国際規格のため、ある国で CC に基づいて評価・認証された IT 関連製品

は、協定に合意している国同士で相互に適用が認められる。

2.1.1 実例調査

米国で CC 評価認証を受けた (あるいは作業中の) 企業にインタビューを行なった。以下にインタ

ビューを行なった企業とそのインタビュー内容を示す。

a. ActivCard 1

ActivCard 社は、さまざまなアプリケーションで使われるスマートカード用のアプレット･スイートを開

発しており、自社製品を用いた最大の実装は、

･ Common Access Card Solutions for the U.S. Government

という製品で、これは米国国防総省 (Department of Defense) において 470 万人がスマートカード

によるセキュアなシステムおよびネットワークへのアクセスのために使用されている。

ActivCard 社は、ハードウェア製品において、物理的セキュリティのレベル 3、ソフトウェア･セキュリ

ティのレベル 3 の 2 つに対する FIPS 140-1 の評価認証を受けている。この評価認証には 2 ヶ月

間の作業がかかり、2002 年 9 月に InfoGard Laboratories から FIPS 140-1 評価認証を受けている。

ActivCard 社が CMVP 評価認証を受けた目的は、米国政府へ自社製品を納入するためであるが、

一般の顧客の多くも FIPS 140 認証製品を要求し、これを購入するケースが多い。

また、同じ製品に対して、CC 評価認証を受ける作業を開始しており、インタビュー当時もその作業

を継続している最中であった。CC 評価認証を開始した動機は、EU 市場をターゲットにするには

CC 評価認証が不可欠であると判断したためである。

これ以前に CC 評価認証を受けた経験はなく、また今回の CC 評価認証も完了していないが、途中

段階においても FIPS 140-1 の作業に比べ 1 桁大きい作業が CC 評価認証のためにかかっており、

10

10 倍以上のコストが既にかかっていると報告している。

このコスト増の原因は、CC 評価認証が要求する文書化作業にかなりの作業がかかっているためで

ある。FIPS では開発者が開発時に通常作成する仕様書レベルのドキュメントを要求するのに対し、

CC 評価認証では CC が規定するドキュメントを新たに作成する必要があり、FIPS が要求する技術

文書およびセキュリティ･ポリシーをはるかに超えた量の文書化が要求されているためである。

なお、ActivCard 社のインタビュー内容は、添付資料 B-1. ActivCard インタビューメモを参

照。

b. Chrysalis-ITS 2

Chrysalis-ITS 社は、CA (Certification Authority) 用のハードウェア･セキュリティ･モジュール

(HSM) の製造元であり、その製品は FIPS 140 と CC の両方の評価認証を受けている。

Chrysalis-ITS 社の CMVP 認証製品を挙げると、次の表になる3。

取得した評価認証製品

FIPS 140-2 レベル 3 Luna SA (HSM サーバ)

FIPS 140-1 レベル 3 Luna CA3 (ルート鍵管理)、Luna XPplus (デジタル署名エンジ

ン)、Luna XL/XLR Premium (プレミアム SSL アクセラレータ)

FIPS 140-1 レベル 2 Luna 2 (暗号ハードウェア･トークン) 、Luna RA (セキュア鍵発行

ハードウェア･セキュリティ･モジュール)、 Luna XL/XL-R (SSL アク

セラレータ)

また、Luna CA3 は 2002 年 11 月に CC 評価認証を受けているが、HSM で EAL (Evaluation

Assurance Level) 4+ を受けた製品は世界中で Luna CA3 だけであった4。

CMVP 評価認証および CC 評価認証を比較すると、FIPS がテスト基準に適合するかどうか (チェッ

ク･リスト) をベースにしているのに対し、CC 評価認証はより詳細で、設計文書、(ISO9000 認証のよ

うに) プロセス、変更管理を評価対象としている。

評価認証にかかった期間については、CMVP 評価認証に数ヶ月かかる一方、CC 評価認証には最

初の CC 評価認証に数年、評価認証を経験した現在は 1 年ほどで終了するようになったと回答して

いる。また、同じ製品に対する CC の再認証であれば (前回からの変更量にも依るが) 3 ヶ月から 6

ヶ月で終了するようになったとのことである。また、2 つの評価認証のコストを比較すると、CC 評価

認証の場合、契約社員の助けを借りる必要もあり、CMVP 評価認証の約 30 倍のコストがかかって

いるとの回答であった。

なお、Chrysalis-ITS 社のインタビュー内容は、添付資料 B-2. Chrysalis-ITS インタビューメモを

参照。

11

c. Spyrus, Inc. 5

Spyrus, Inc. 社は、Rosetta Smart Card、Common Access Card (CAC)、 FORTEZZA Crypto Card

などの暗号製品を製造するメーカである。Spyrus, Inc. 社は Rosetta Smart Card で暗号モジュー

ルおよび製品全体の両方に対する FIPS 140 評価認証を受け、さらにインタビュー当時には CC の

認証作業を行なっている最中であった。

FIPS 140-2 ではβ段階のハードウェアに対し耐タンパー検査を要求しており、これにより評価対象

の製品が耐タンパーであることが示される。また、ファームウェア固有のテストもあり、ファームウェア

に変更が生じた場合は、CC および FIPS で再認証を受ける必要が生じる。

最初の CMVP 評価認証では約 1 年の期間を要したが、15 から 20 の製品に対する認証を済ませ

た現在、2 から 4 ヶ月の期間で済むようになったと報告している。また、既に認証を受けた製品に認

証を追加する場合は約 6 週間で済むとのことであった。スケジュールが延びる主な原因は文書化

作業のためで、CMVP 評価認証に 1 製品あたり$75,000 から$150,000 かかった、と回答している。

CC 評価認証の取得中であるが、一般的に言って、CC 評価認証は CMVP 評価認証より長い期間

がかかると回答している。その理由は CC 評価認証の方が文書化すべきものが多いためであるが、

暗号技術の視点から比較すると CC と FIPS に本質的な違いはない、と回答している。

CMVP評価認証からCC 評価認証に移る場合のほうが逆の場合よりも容易であるとの指摘があった。

これは、CMVP 評価認証が CC 評価認証を取得するのに役立つ情報を要求しているためである。

なお、Spyrus, Inc. 社のインタビュー内容は、添付資料 B-3. Spyrus, Inc. インタビューメモを参

照。

2.1.2 調査結果

上記 2.1.1 項のインタビュー結果および文献調査の結果を元に、項目ごとにまとめたものを以下に

示す。


CC 評価認証は次の図 1 のようなステップで行なわれる。

12

図 1. CC 評価・認証のフロー

後述の CMVP 評価認証のステップと類似するが、実際には CMVP 評価認証よりも CC 評価認証の

方が開発時に作成する以外の文書を CC 評価認証が規定するフォーマットで作成する必要がある

など複雑である。特にステップ 5 は、そのレビュー対象の文書の種類や評価項目が多くレビューが

複雑で、現地調査などを含め評価認証作業に長期間を必要とするため、このステップのために CC

評価認証に必要な大半の作業が費やさていれる。

b. 期間

一般的なケースとして、CC 評価認証に必要な期間は CMVP 評価認証の場合の約 3 倍で、ベンダ

ーが CC 評価認証プロセスを終了するまでには 12 ヶ月から 18 ヶ月を必要とする。過去に CC 評価

認証の経験がない初めてである場合には、特にトラブルが多く、作業が長期化する傾向がある。し

かし、2 回目以降の CC 評価認証では期間は短くなり、CMVP 評価認証の約 2 倍の期間にまで短

縮される。これは、ベンダーの企業内に認証の手順とプロセスが適切に習得されたためである。認

証期間の大半を占める作業は、現地調査と、手順、プロセス、文書の 3 つに対する適合度の監査

から構成されている。

c. 費用

ベンダーが CC 評価認証に必要とする費用は、下の要因によってかなり差があり、一概に提示する

ことが難しい。

･認証対象の製品の種類 (これは調査の範囲や製品の実際のテストに影響を与える)

･認証する EAL (Evaluation Assurance Level) 評価保証レベルの高さ (EAL が高くなるほど、テス

13

トや調査を要するためコストが高くなる)

･評価が物理的テストを必要とするか (物理的テストはコストを増加させる)

･ベンダーの準備状況 (開発から納品までの全プロセスをコントロールできるか、これらのプロセス

を実証できるか。FIPS 140-2 で評価されるプロセスは CC 評価認証においても評価対象となるが、

CCの方がより範囲が広い。たとえば、CCではソフトウェア･コーディング規則を要求するが、FIPS

では単に推奨するだけである。)

･ベンダーが開発作業で作成する技術文書の品質レベル (CC では開発における標準プロセスを

想定した要求を行なっている。ソフトウェア開発の標準プロセスでは変更管理やコーディング規

則を要求しているが、これに従って開発している企業は多くないだろう。)

･製品が準拠する対象のプロテクション･プロファイル PP の有無 (既存の PP である場合は若干作

業が少ないといえるが、新しい PP の場合はまずその PP が国の CC 機関により認められる必要が

ある。)

･セキュリティ･ターゲット ST (新規の ST の場合、まず CC 評価機関である CCTL (Common

Criteria Testing Laboratory) がアプローチを開発する必要がある。)

･以前、CCTL が評価した製品であるか、製品に関連する技術を全て知っているか (評価機関は

異なったタイプの製品を評価し、それぞれが異なる経験を積んでいるため。)

また、米国企業で 2 回以上 CC 評価認証を受けた企業がほとんど存在しないため、今回の調査で

は標準的なコストについての情報はほとんど収集できなかった。さらに、国立標準技術研究所

(NIST) と国家安全保障局 (NSA) の共同事業である国家情報保証パートナーシップ (NIAP、

National Information Assurance Partnership) が米国で CC 評価認証の管理を行なうようになったの

がつい最近であるため、評価認証期間が不慣れなために長期化し、必要とするコストが高くなる傾

向がある。

今回の調査を基にし 2 つの評価認証に必要な費用を比較すると、同一製品に対して典型的な CC

評価認証のために評価機関に払う費用は CMVP 評価認証にかかる費用の少なくとも 3 倍、と見積

もることができる。ただし、この見積もりはベンダーがそれぞれの認証の準備が十分で、提出物を全

て用意してある、との仮定の下での値である (もし対象製品が既に CMVP 評価認証を受けており、

かつそのテスト結果を CC 評価認証で利用することができるのであれば、そのコストは若干少なくて

済むであろう)。NIST の見積もりでは、複雑な製品に対する CC 評価認証は百万ドルを超える、と報

告している。現在、NIST および NSA は共同で認定機関に参加しており、提出物のレビューに対し

て費用請求をしていない。

評価機関やベンダーによると、多くのベンダーは CC 評価認証の文書化作業の支援のためにコン

サルタント･スタッフを追加で雇っており、これにかかる費用は CC 評価認証に必要な費用全体の

1/3 に達している。いくつかの評価機関はベンダーの文書化作業を支援しているが、他の評価機

関はベンダーのサポートをほとんど行なっていない。

14

一般的には、評価機関のスタッフがベンダーの製品に熟知するにつれ、認証および検査プロセス

がより効率的になっており、評価機関とベンダーは評価作業を通じて継続的な関係を築いている。


CC 評価機関が必要とする要員は、プロセスで実施される監査タイプのレビューのため、CMVP 評

価認証の場合よりも多くのスタッフを必要とする。CC 評価機関のスタッフは、このレビューのために

システム監査 (EDP 監査の経験と計算機科学、および一般的なコンピュータ･システム･セキュリテ

ィ) のスキルを必要とする。また、同一製品に対して CMVP 評価認証を行なうのに要求されるのと

同じ技術的な知識や経歴、同じ人数の技術スタッフが必要となる。

CMVP 評価認証が対象製品の暗号モジュールのみを認証するのに対し、CC プロセスでは製品全

体に対するレビューを行なうが、暗号モジュールにおける暗号アルゴリズムはテストしない。後述の

3.1.1 事例 1: USPS (United States Postal Service) , IBIP では、暗号モジュールに対し FIPS

140-1 評価認証を要求している一方で、暗号モジュール以外の部分に対しては追加の設計レビュ

ー (たとえば、郵便料金の価値データを保持するレジスターに対する保護など) を要求している。

USPS では、CC および CMVP 評価機関の一つを使って、評価対象のベンダーの製品をレビューさ

せている。

NVLAP (National Voluntary Laboratory Accrediation Program) は CC 評価認証を行なう評価機関

の認定に必要なスキルを定義しており、NISTのDraft Handbook 150-20 6 にスタッフが満たすべき

要件が書かれている。それをまとめると、次のようになる。

･ IT 評価活動に携わる評価機関のスタッフは、計算機科学、コンピュータ工学、またはこれに関連

する技術領域の専門知識ないし同等の経験を有すること。

･スタッフは、OS、データ構造、アルゴリズムの設計/分析、DB システム、プログラム言語、コンピュ

ータ･システム･アーキテクチャ、ネットワークに関する知識または経験を有すること。

･評価機関のスタッフは、検査方法、計算機科学概念、セキュリティ概念、CC および CEM

(Common Evaluation Methdology) の実務に必要な知識、に関する一般的な要求を満たす教育

を継続すること。


CC が社内プロセスで作成すべき文書は ISO9000 の場合の文書化に匹敵する作業量となっている。

CMVP 評価認証で必要とされる文書は全て CC 評価認証でも必要となるが、それぞれの認証が規

定するフォーマットが異なっており、認証ごとに独自のフォーマットを使っている。

ベンダー (CC では「IT 評価のスポンサー」と呼ぶ) は PP (Protection Profile) または ST (Security

Target)、これに関連する TOE (Target of Evaluation) となる IT 製品/システムを提出する必要がある。

提出する TOE は次の条件を満たすものとなる。

(1) 暗号モジュールを含む製品の場合、製品のハードウェア、ソフトウェアのコンパイル済

みコードと文書化されたソース･コード、およびマイクロ･コードである。これらは通常、開発期

15

間中に作成される。

(2) さらに ST の保証で必要になるセキュリティ関連文書が作成され、公開されなければなら

ない。

(3) TOE が以前に評価された製品を含んでいる場合、ベンダーは評価機関と契約上の協

定を結び、以前の評価結果の提供を評価機関に依頼する必要がある。提出された評価結

果のいくつかは、以前評価された製品の認証取得後に、アクセス可能な公開文書とされ

る。

認定機関が製品ないしシステムの評価に同意しスケジュール作成に入る前に、ベンダーおよび

CCTL (CC 評価機関) は次の文書を作成し提出しなければならない。

･評価作業計画

･評価スケジュール

･ ST と TOE の記述、または、PP 評価の場合には PP

認定機関は、要求する評価プロセスおよび評価活動の技術的な監督を行なう必要があるため、ベ

ンダーは認定機関が正式に評価を許可する前に一部の評価作業が発生することを許可しなけれ

ばならない。

CCTL は次を含む作業資料を認定機関に提出する。

･評価プロジェクト中に提出される所見報告書すべて (技術評価およびスキーム･プロセスに対す

る解決策に関する報告およびガイダンスを含む)

･ CEM (Common Evaluation Method) に従った評価分析

･評価技術レポート (Evaluation Technical Report)

CCTL は評価技術レポートを作成し、認定機関はこれを基に認定レポート (Validation Report) を

作成する。評価技術レポートには、意見とその理由、評価中に発見した調査結果、発見したエラー、

評価中に発見した潜在的な脆弱性 (exploitable vulnerabilities discovered) を含める必要がある

(この点が CC と CMVP の一番の違いである)。また、評価技術レポートは次の 2 種類のフォーマット

で提出されなければならない。

･ベンダーの機密情報を含むもの

･機密情報を除いた簡略形式のもの

上記のうち、簡略形式のレポートがユーザに公開される。

f. CMVP との使い分け

CMVP が暗号モジュールおよびこれを組み込んだ製品を対象とするのに対し、CC では暗号モジ

ュールを組み込んでいない IT 製品および (暗号製品を組み合わせた) システムをその評価対象

としている。また、CMVP が暗号モジュールの実装が FIPS 標準に適合しているかどうかを評価する

のに対し、CC は製品およびシステムの設計、実装、運用を含めた全体がセキュリティの要求仕様

に一致しているかどうかを評価する、という違いがある 4。このように、CMVP と CC ではその対象が

別であり、むしろ CMVP は CC の補完的役割とみなすべき標準である7。

16

今回のインタビューでも、ベンダーがどの認証を受けるか選択する際に次の 2 つの要因により決定

している、と回答している。

･製品のタイプ (暗号アルゴリズムのみで CMVP 評価認証が必要か。製品が暗号アルゴリズムを

実装しており、CMVP 評価認証が必要か。暗号アルゴリズムをシステムとして実装している製品

で、CC の認証が必要か。)

･ターゲットとする市場 (ターゲットとする市場が特定の認証を要求しているか。)

なおベンダーが認証取得を決定する場合、認証にかかる費用が市場規模に見合うものであるかを

判断している、とインタビューで報告されている。

また、CC 評価認証は米国内で認知度が低く、今回のインタビューを行なった多くのベンダーが CC

評価認証に対し次の認識を持っていると回答している。

･ヨーロッパの市場をターゲットにしない限り、必要はない

･コストが非常に高い

しかし、CC プログラムは米国の防衛システムのセキュリティ分野で注目を浴びており、つい最近、

そのいくつかが連邦政府の要求として定められ、今後は CC 評価認証が必須になると思われる。防

衛システム以外の連邦政府システムでは CC 評価認証は必須とはならないであろうが、(連邦政府

向けに CC 評価認証された製品を含み) 今後、CC プログラムの下で認証製品が増加することが期

待されている。

g. CMVP の結果の利用や参照の有無

現在の米国では政府調達に CMVP 評価認証が必須となっているが、CC 評価認証は必須となって

いないため、NIST などが政府調達において CC 評価認証を促進する (あるいは義務付ける) 活動

を行なっている。具体的には、NIST は CMVP 認証製品の利用を要求する PP の開発を行なって

おり、現時点ではスマートカードと CA 製品8の 2 種類のみ公開されている。現在は義務付けられて

いないが、このような CMVP 認証製品を要求する PP を電子政府調達で義務付けすることにより、

CMVP の結果が CC で利用され、CMVP 評価認証製品を含んだ形でシステムが CC で評価認証さ

れることを意味している。

また、NIST と評価機関は現在、CMVP 評価認証結果を CC 評価認証に利用するための作業を継

続しているが、今のところ CMVP 評価認証結果のほとんどは CC 評価認証で利用することはできて

いない。この問題に取り組んだカナダ CSE (Communications Security Establishment) による調査

結果では、「CC 評価認証において CMVP 評価認証結果はある条件を満たす場合のみ利用可能

である」と結論付けているが、これは文書フォーマットにおける利用を言っており、検査内容が異な

るため CMVP の検査結果をそのまま CC 評価認証に利用することはできない。

17

2.2 CMVP 運用の実例

CMVP (Cryptographic Module Validation Program) とは、FIPS 140-2 およびその他の暗号標準に

基づき、米国 NIST とカナダ CSE が共同で運用する暗号モジュール認証プログラムのことである。

FIPS 140-2 (FIPS 140-1) への適合が評価認証された製品は、両国の連邦政府によって機密情報

(米国) または指定情報 (カナダ) の保護に適した製品であると認められている。CMVP の目標は、

認証済み暗号モジュールの利用を促進し、さらに暗号モジュールを含む機器の調達に対するセキ

ュリティ評価基準を連邦政府に提供することである。CMVP において、市販の暗号モジュール開発

ベンダーは認定を受けた CMT (Cryptographic Module Testing) ラボで暗号モジュールの認証を受

ける。CMT ラボは NVLAP (National Voluntary Laboratory Accrediation Program) から認定を受け、

暗号モジュールの適合性および準拠のテストを実施する。

FIPS 140-2 が定めるセキュリティ要件は、暗号モジュールの安全な設計と実装に関する、下の 11

のエリアを網羅するものである9。

1. 暗号モジュール仕様

2. 暗号モジュールのポートおよびインターフェース

3. 役割、サービス、認証

4. 限定状態モデル

5. 物理的セキュリティ

6. 運用環境

7. 暗号鍵管理

8. 電磁波妨害雑音 (EMI)/ 電磁環境両立性 (EMC)

9. セルフ･テスト

10. 設計保証

11. その他､攻撃軽減策

2.2.1 実例調査

米国で CMVP 評価認証を受けた企業にインタビューを行なった。以下にインタビューを行なった企

業とそのインタビュー内容を示す。

a. ActivCard

b. Chrysalis-ITS

c. Spyrus, Inc.

これら 3 社については、CMVP 評価認証と CC 評価認証の両方の評価認証を取得 (もしくは取得

作業中) であるため、前述の 2.1.1 実例調査に記述した。インタビュー内容については 2.1.1 実

例調査を参照。

18

d. Hasler, Inc. 10

Hasler, Inc. 社は、郵送･輸送システムや郵便物仕分けなどの郵便関連機器を開発している企業で

ある。Hasler, Inc. 社が開発する Safe CV という製品はハードウェアおよびソフトウェアでCMVP評

価認証を受けている。なお、CMVP 評価認証は暗号モジュールに対してであり、Safe CV ユニット

全体としては CMVP 評価認証を受けておらず、その代わりにユニット全体に対しては 3.1.1 事例

1: USPS (United States Postal Service) で述べる USPS 標準の認証を受けている。なお、Hasler,

Inc. 社が USPS 標準の認証を受けているのは、USPS に PSD (Postal Security Device) ユニットを

提供しているためである。

この製品に対してHasler, Inc. 社はCC評価認証を受けていない。これはコストがかかること、国ごと

に異なる部分があること、の 2 つの理由のためである。さらにインタビューでは、Hasler, Inc. 社が所

属する業界は CC 評価認証をボイコットしている、とのコメントも加えている。

CMVP 評価認証においては、Hasler, Inc. 社が評価機関にセキュリティ装置と検査設備の両方を

提供している。Hasler, Inc. 社が提供した検査設備は Hasler, Inc. 社製品に特化しておりかつ評

価機関がこれを購入する予定がないため、Hasler, Inc. 社自身がこの検査設備を提供している。

評価認証時にはβ版ではなく、製品レベルのハードウェアを提出しており、競合である Pitney

Bowes もこれと同様である。評価機関ではハードウェアの検査として、ドリル、化学、電子技術、振

動、急激な温度変化などのさまざまな物理的攻撃の検査を行なっている。

評価機関が評価に要する期間は往々にして伸びる傾向にあり、その理由は評価機関に評価スキ

ルを持った人材が十分にいなかったため、と回答している。さらに、評価担当者は FIPSに対する検

査方法を十分理解していなかったため、IBM や Intel などの製品に関しベンダーと密接な連携を

取る必要があった、と回答していた。

また、CMVP 評価認証に必要なコストは、最初の評価認証の場合に約$50,000 かかるだろう、と回

答している。

なお、Hasler, Inc. 社のインタビュー内容は、添付資料 B-4. Hasler, Inc. インタビューメモを参

照。

2.2.2 調査結果

上記 2.2.1 項のインタビュー結果および文献調査の結果を元に、項目ごとにまとめたものを記す。


暗号モジュール評価認証手順のベンダーからユーザまでの大まかなフローは、下の図 2 の通り

である。11

19

図 2. CMVP 手順概略

まず、ベンダーから暗号モジュールとアルゴリズム、それらに関する文書が CMT ラボに持ち込まれ、

認証の前段階として IUT (Implementation Under Test) と称するプレテストが行なわれる。IUT 時に

は、暗号モジュールと関連する文書を CMT ラボ内に常時置いておく必要があり、その後でベンダ

ーが CMT ラボとその後に行なわれる認証テストの契約を行なうことになる。

ここでの適合性テストには DTR (Derived Test Requirement) が用いられる。DTR とは FIPS 140 を

基にしたテスト要件書であり、FIPS 140-2 の全ての要件が宣言形式で DTR の中に組み込まれ、

FIPS と DTR が一対一に対応付けられることにより追跡可能性が保証されている12。この関係を図で

説明したものが図 3 である。

図 3. FIPS 140-1&2 と DTR の関係

認証の検閲段階に入ると、文書は NIST 及び CSE の検閲を受ける。検閲では NIST および CSE

によるコメントが加えられ、改めて CMT ラボへと送られる。そこからは認証調整段階となる。改版さ

20

れた文書のレビュー、また必要であれば追加の文書レビューとテストが実施され、再び NIST 及び

CSE の検閲作業が繰り返される。そして最終認証段階に入ると認証検閲コメントの最終結果が出さ

れ、暗号モジュールが正式に認証されたものとなると、番号が割り当てられ、署名された証明書の

発行が行なわれる。これらのプロセスを図示したものが図 4 である。

図 4. CMVP フロー概観図

2.1.2 調査結果のフローと比較するために、図 1. CC 評価・認証のフローと同じ形式にまとめ

たものが次の図 5 である。

21

図 5. CMVP 評価認証のフロー

図 1. CC 評価・認証のフローと上の図を比較すると同じようなステップに見えるが、CC 評価認

証ではそのレビュー対象の文書の種類や評価項目が多くレビューが複雑で、現地調査などを含め

評価認証作業に長期間を必要としている。これに対し、CMVP 評価認証の方は CC 評価認証に比

べて単純である。

b. 期間

CMVP 評価認証は CC 評価認証に比べて短期間で評価認証を行なうことができる。ベンダーに評

価認証の経験がない場合には、評価認証に必要な期間の差は一層大きくなる。ベンダーが行なう

文書化の量と準備状況によって状況が異なるが、一般的なケースで言って CMVP 評価認証でベ

ンダーおよび評価機関が行なうテストのプロセスには 3 ヶ月から 6 ヶ月の期間が必要である。この期

間の間に評価機関が 8 週間から 12 週間かけてモジュール検査、ソースコード検査、物理的検査を

行なう。ここで作業期間に 8 週間から 12 週間と差が生じるのは、対象製品の種類と製品に求めら

れる認証レベルに依存して作業が変化するためである。また評価認証期間中、NIST はおおよそ 4

週間かけて文書の検査およびレビューを行なうが、実際には依頼してから通常 2 ヶ月ほど経たない

と評価認証作業が終了しない。これは、NIST が常に以前に依頼された評価作業が終了していな

いため、新規に依頼された作業にすぐに取り掛かることができないためである。

c. 費用

製品の目的とする認証レベル、得られる文書の完全性、製品の性質（ハードウェア、ソフトウェア、

22

シングル機能、マルチ機能）、前段階分析や製品のバージョンの評価、そして認証期間などにより、

認証に必要となる費用は異なっている。

しかし、一般的には、CMVP評価認証に必要な費用はCC評価認証の費用よりはかなり低くて済む

と言える。今回インタビューを行なったほとんどの企業が CC 評価認証と CMVP 評価認証の費用を

同時に報告していないため正確な比較は困難であるが、インタビュー結果から推測すると、CC 評

価認証に CMVP 評価認証の 4 倍から 30 倍の費用がかかると言える。この内、30 倍かかると回答し

たベンダーでは、CC 評価認証の作業途中であり、プロセスの文書化に対する要求の変更や追加

のプロセス、内部監査や企業の管理策に対する検査のために同じ作業が繰り返されていると報告

しており、最終的には 30 倍を超える可能性が高い。

下の表 1 に、CMVP の評価機関に支払う典型的な費用を示す。

セキュリティ･レベル下限上限

レベル 1 $25,000 $30,000

レベル 2 $30,000 $35,000

レベル 3 $35,000 $45,000

レベル 4 $40,000 $60,000

表 1. 典型的な評価機関に支払う CMVP 評価認証費用

上記の費用には評価機関がベンダー側で実施する 2 日間のワークショップの費用が含まれている。

このワークショップでは担当者に対する文書化要求、手順、スケジュールなどの教育が行なわれる。

また、上記費用には文書化作業に対するサポート費用も含まれている。あるベンダーは CMVP 評

価認証に必要な文書化作業をコンサルタント会社に依頼しており、1 製品に対してコンサルタント

会社に支払った費用は約$30,000 と報告している。

ほとんどの製品は NIST の要求に従って検査または文書化のやり直しを必要としており、追加の文

書化や検査を必要としないケースはこれまでに数えるほどしかないため、コストが増加する傾向に

あると言える。

また、2002 年 7 月以降、NIST の検査に対して下の表 2 に示すような費用が必要となり、コストが追

加された。

23

セキュリティ･レベル料金

レベル 1 $2,750

レベル 2 $3,750

レベル 3 $5,250

レベル 4 $7,250

表 2. NIST に支払う CMVP 評価認証費用


NIST で FIPS 140-2 の評価認証を行なう CMVP のスタッフは総勢 4 名で、このスタッフがアプリケ

ーションのレビューを行なっており、これらのスタッフは計算機科学、暗号 (数学)、電子工学の経

歴を有する。また評価機関のスタッフも同様の経歴を有しており、評価機関で物理的検査を行なう

スタッフはさらに材料科学を専攻科目とする経歴を有している。これら評価機関のスタッフは最低で

も大学理工学部卒であり、その多くは修士卒であるが、情報セキュリティにおける特定の経歴は有

していないため、評価機関がその代わりに教育を行なっている。CMVP 評価認証チームはかなり

小規模で、レビュー対象の製品の規模により 1 名から 3 名のスタッフがプロジェクトに割り当てられ

ている。

NIST は評価機関の認定にあたり、FIPS の検査を実行するのに必要なスキルを定義しており、セキ

ュリティ製品開発・検査を行なうスタッフに対し、適切な大学の学位、またはこれと同等の 2 年以上

の経験を要件にあげている。また、評価機関のスタッフには、次のような専門分野のトレーニングが

行なわれている。

･検査方法および検査報告書作成に関する一般的知識･スキル

･ソフトウェア暗号アルゴリズムの検査を行なうハードウェアおよび OS に対する知識

･セキュリティ･レベル 4 の検査に要求される環境検査の電圧･温度測定

･コンピュータ･セキュリティ概念

･限定状態モデルの分析

･製品のグレード、タンパーの証拠、タンパー検知の技術

･高級言語および形式モデルを含むソフトウェア設計仕様

･鍵管理の技法と概念

･暗号セルフ･テスト技法

･電磁波妨害雑音 (EMI)/ 電磁環境両立性 (EMC) の検査技法

･ CMVP評価認証の全てのタイプの暗号アルゴリズム、暗号用語と暗号アルゴリズム群に関する知

識

24

･（NIST による） Cryptik Testing Support Tool の操作および保守13

･品質プログラムおよび品質管理プロセス

また補足として、評価機関のスタッフに必要とされるスキルは Cambridge Tamper Labs に勤めるス

タッフのスキルが参考になるが、彼らは計算機科学におけるセキュリティ、システム、暗号、数学、

半導体技術、材料科学、化学工学の専門家であり、また、電磁気、工学、音響信号における信号

検出･信号処理の専門家である。


CMVP 評価認証においてベンダーは、評価機関に以下の規定に従った提出物を提出しなければ

ならない。

･ベンダーは、次の項目を記述したセキュリティ･ポリシーを提出し公開しなければならない。

モジュールに対して認可された運用モード

認可された運用モードを起動する方法

暗号モジュールが認可された運用モードにあるかを示す方法

認可された運用モードを示す指標を取り出す操作方法

･主要なサービスのためにプロセッサが実行するソフトウェアまたはファームウェア、また実行可能

コードおよびデータを格納するメモリ装置、の 2 種類を規定する文書を提出しなければならない。ま

た、ベンダーは、プロセッサとインターフェースを取るようなハードウェアが次の項目を全て満たすよ

うにしなければならない。

暗号モジュール仕様

暗号モジュールのポートおよびインターフェース

役割、サービス、認証

限定状態モデル

物理的セキュリティの仕様および保守方法 (適切な場合)、通常の運用範囲

OS およびハードウェアを含む運用環境

暗号鍵管理

電磁波妨害雑音 (EMI)/ 電磁環境両立性 (EMC)

セルフ･テスト

モジュールの安全なインストールと起動、分散セキュリティ、ハードウェア、ソフト

ウェア、ファームウェア部品の対応とモジュールのセキュリティ･ポリシー、ファー

ムウェア部品の (コメント付き) ソースコード、仕様、手順を含む設計保証

ベンダーは、製品として出荷するハードウェア、コンパイル済みソフトウェア、ソースコード、上記に

挙げた文書を評価機関に提出する必要がある。テストはベンダー側サイトで実施される場合があり、

ベンダー側自身の機密情報を保護するために、ベンダーが評価機関に対して物理的セキュリティ

を提供することが要求されている。

また、テストを実施した評価機関は NIST に、申請書、準拠のレベル、文書、テスト結果などの書類

25

を提出する。

f. CC との使い分け

2.1 CC 運用の実例でも述べたが、CMVP 評価認証は米国政府の調達で必要とされ、また州政

府においても要求されているケースがあるため、政府関係機関へ暗号製品を納めるために CMVP

評価認証を受ける。また、民間のセキュリティ市場においても FIPS の認知度は高く、政府以外にお

いても確固たる地位を占めているため、米国のベンダーの多くが CMVP 評価認証を取得するよう

になっている。

また、暗号モジュールまたはこれを組み込んだ製品の場合は、暗号モジュールのセキュリティ評価

を行なうために CMVP 評価認証を取得する 4。これに対し、CC 評価認証は製品および製品から構

成されたシステムが評価対象である。

g. CC の結果の利用や参照の有無

CMVP 評価認証において、CC 評価認証の結果を利用したり参照したりすることはできない。

また、CC 評価認証で行なわれたテスト結果を CMVP 評価認証に提出することは現状では不可能

で、これを行なうためには両方の評価認証で行なわれるべきテストを一致させると同時に、対象製

品が求める CMVP のセキュリティ･レベルと CC の EAL (評価保証レベル) を対応付ける必要があ

る。

CMVP と NIAP では CMVP 評価認証を CC 評価認証に近づける活動を行なっている。たとえば、

FIPS 140-1 から FIPS 140-2 の改版により、CC が対象とする保証クラスに対する一致度が向上して

いる。これを示す表をカナダ CSE が行った調査結果から下に引用する14。

CC 保証クラス FIPS 140-1 FIPS 140-2

構成管理部分的に一致部分的に一致

配布および運用一致せず部分的に一致

開発解釈によっては一致解釈によっては一致

ガイダンス文書部分的に一致部分的に一致

ライフサイクル支援一致せず一致せず

テスト解釈によっては一致解釈によっては一致

脆弱性評価部分的に一致部分的に一致

また、最新版である FIPS 140-2 では CC 評価認証を統合するために、セキュリティ･レベルを次の

ように定義している。

セキュリティ･レベル 3 は暗号モジュールのソフトウェアおよびファームウェアが次の汎用のコ

ンピュータ･システムおよび OS で動作することを必要とする。

付録 B で挙げる PP が規定する機能要件と、高信頼パス (FTP_TRP.1) の追加機能要

件を満たすこと

•

26

かつ

CC 評価認証の EAL2 (以上) と、TOE セキュリティ･ポリシー･モデル (ADM-SPM.1) の

追加保証要件で評価認証されていること

•

27

2.3 CC と CMVP の併用

2.1 項および 2.2 項では米国における CC および CMVP の統合運用に関する実態を報告した。

現在の日本においては、電子政府の調達および暗号に関し、以下のような状況にある。

･ CC に基づく製品およびシステムの評価認証制度が「IT セキュリティ評価及び認証制度」として実

施されている。

･ CC 評価認証では、暗号に対する要求およびこれを実装した暗号モジュールに対する評価を対

象としておらず、暗号に関しては各国政府に任されており、各国スキームで独自に評価されてい

る。たとえば、米国においては、政府が使用すべき暗号アルゴリズムを FIPS 標準により規定し、

FIPS 140-2 標準に基づく CMVP 評価認証制度により暗号モジュールおよびこれを含む製品の

評価認証を行ない、政府調達に CMVP 認証を義務付けている。

この状況の下、日本における電子政府調達に対して、次のような課題が存在している。

･日本においては CC 評価認証制度はあるが、CMVP に相当する評価認証制度はなく、政府調達

において暗号に対する評価が行なわれていない。

上記課題に対して、CMVP 評価認証結果を CC 評価認証の中の暗号部分に適用するための対策

を以下に挙げる。

･暗号モジュールおよびこれを含む暗号製品の評価認証を行なう CMVP に相当する評価認証制

度を導入し、暗号製品および暗号製品を含むシステムについては CMVP 評価認証取得後に

CC 評価認証を取得するものとする。

･日本の電子政府システム向けに CMVP 評価認証を要求する Protection Profile (PP) を開発す

る。

以降では、上記提案をさらに詳しく説明するために、CC および CMVP の統合環境におけるメリット、

課題、その対策について述べる。

2.3.1 メリット

ここでは、CC 評価認証に CMVP 評価認証結果を利用し、CC と CMVP の統合運用した場合のメリ

ットについて述べる。

a. セキュリティ向上

CMVP 評価認証が暗号モジュールに対し FIPS 標準への適合性を評価認証するのに対し、CC 評

価認証ではシステムまたは製品におけるセキュリティ機能が PP の要件を満たしているかの評価認

証を行なう、というように双方は相補的な関係にある。CMVP 評価認証の後に CC 評価認証を受け

ることにより、暗号モジュールを含む製品全体のセキュリティを保証することができる。

28

b. 評価認証の作業量軽減

CC と CMVP の 2 つの評価認証では、下の図 6 のように、暗号モジュールを含む暗号製品にお

ける機能チェックの評価認証部分の作業が重複している。このため、CMVP 評価認証の取得後に

CC 評価認証を受ける手順を取ることにより、つまり CMVP 評価認証で行なった機能チェック部分

の評価結果を CC 評価認証で利用することにより、重複している機能チェック部分の作業量を軽減

することができる。これは 2.2.1 実例調査で述べた c. Spyrus, Inc.のインタビューでの回答で裏

付けられている。

図 6. CC 評価認証における CMVP 評価認証結果の利用

2.3.2 課題点・制約

ここでは、日本の電子政府システムの調達に CC と CMVP を統合運用する場合の課題点および制

約について述べる。

a. CMVP 評価認証を要求する Protection Profile (PP)

現在、日本が政府調達において実施している「IT セキュリティ評価及び認証制度」は、CC に基づく

製品およびシステムの評価認証制度であるが、CC 評価認証では暗号に対する要求およびこれを

実装した暗号モジュールに対する評価を対象としておらず、暗号に関しては各国政府に任されて

おり、各国スキームで独自に評価を実施している。米国においては、政府が使用すべき暗号アル

ゴリズムを FIPS 標準により規定し、FIPS 140-2 標準に基づく CMVP 評価認証制度により暗号モジ

ュールおよびこれを含む製品の評価認証を行ない、政府調達に CMVP 認証を義務付けている。し

かし、日本においてはこの CMVP に相当する評価認証制度はなく、政府調達において暗号に対

29

する評価認証が行なわれていない、という問題点がある。

この問題を解決するためには、CC 評価認証に暗号アルゴリズムとその実装性に対する評価認証を

含めなければならない。このためには、CMVP 相当の評価認証制度を導入し、CC 評価認証制度

にこれを統合することが課題となる。

具体的には、日本の電子政府システムが対象とする製品およびシステムに対して CMVP 評価認証

を要求する PP を開発し、これを調達の要件とすべきである。しかし、PP の開発はセキュリティに対

する専門性が要求されかつ時間のかかる作業であり、かつ電子政府システムが対象とする製品お

よびシステムの全てに対して PP を開発する必要がある、という問題が存在している。

b. CMVP と CC の 2 つの評価認証で重複する作業

CC と CMVP の 2 つの評価認証では、暗号モジュールを含む暗号製品における機能チェックの評

価認証部分の作業が重複している。このため、CC および CMVP の 2 つの評価認証が必要なベン

ダーにとっては、重複した作業を行なう必要があり、余計なコストの負担を強いるとともに、評価作

業の長期化による市場競争力の低下を招く恐れがある、という問題が存在している。

2.3.3 対策

2.3.2 課題点・制約で述べた課題を解決するためには、具体的に以下のことを行なう必要があ

る。

a. CMVP 評価認証を要求する Protection Profile (PP) の開発

暗号モジュールおよびこれを含む暗号製品の評価認証を行なう CMVP に相当する評価認証制度

を導入し、暗号製品および暗号製品を含む電子政府システムの評価認証において CMVP 評価認

証結果を CC 評価認証の中の暗号部分に適用することが必要である。

そして、電子政府システム調達の要件として CC 評価認証に CMVP 相当の暗号モジュール評価認

証を統合するためには、CC 評価認証で要求仕様となる PP が CMVP 相当の暗号モジュール評価

認証を要求するように開発される必要がある。

米国において政府調達に CC 評価認証を導入するために、米国 NIST は CMVP 認証を要求する

PP の開発を行なっているが、現在のところ、スマートカードおよび CA 製品の 2 種類の PP のみの

公開で、その他製品に対する PP の開発を継続している最中である。

日本においては、これら NIST が開発した CMVP 評価認証を要求する PP 開発方法を参考に、調

達の対象とする製品およびシステムに対して CMVP 相当の暗号モジュール評価認証を要求する

PP を開発し、これを調達の要件とすべきである。

PP の開発にはセキュリティに対する高度な専門性と電子政府システムが対象とする製品およびシ

ステムに対する知識が必要とされる。また、電子政府システムに必要な製品およびシステムの全て

に対して、迅速に PP の開発を行なう必要もある。これを達成するためには、民間の協力を仰ぎなが

30

ら PP 開発を進める体制を整備すべきである。

b. CMVP 評価認証取得後に CC 評価認証を取得

暗号製品および暗号製品を含むシステムについては、暗号モジュールにおける暗号アルゴリズム

およびその実装性を CMVP 評価認証で保証し、製品やシステムにおけるセキュリティ機能を CC 評

価認証で保証することになる。CMVP 評価認証で行なった機能チェックの部分の評価結果を CC

評価認証で利用することにより、CC および CMVP 評価認証で重複している作業を軽減することが

できる。つまり、CMVP 評価認証の取得後に CC 評価認証を受けるよう、CC 評価認証制度に

CMVP 相当の評価認証制度を統合すべきである。

c. CMVP 評価認証を要求する PP の例

ここでは、上記 a.で述べた PP 開発の参考として、NIST が CA 製品に対して作成した PP がどのよう

に CMVP (FIPS 140-2) 評価認証を要求しているか、について説明する 8。

i) セキュリティ･レベルの定義

PP に対する 4 つのセキュリティ･レベルを定義し、それぞれのセキュリティ･レベルに対して FIPS 140

認証におけるセキュリティ･レベルの対応付けを行なっている。この対応付けは 4 つのセキュリティ･

レベルを定義し、それぞれのセキュリティ･レベルに対する PP を開発し、これら 4 つの PP を CA 製

品に対する PP のファミリーとして 1 つの資料にまとめている。それぞれのセキュリティ･レベルは、一

つ上のレベルの PP がそれより下にある PP のセキュリティ要求を含む形で、階層構造として定義さ

れている。たとえば、セキュリティ･レベル 3 の PP は、それより下のセキュリティ･レベル 1 およびセキ

ュリティ･レベル 2 の 2 つの PP が要求する機能および保証のセキュリティ要求を全て含んでいる。

詳細なセキュリティ･レベルは PP の「2.1 項 CIMC (Certificate Issuing and Management

Components) セキュリティ･レベル」に定義され、また、FIPS 140 のセキュリティ･レベルとの対応付

けは、「7.2.2 項私有鍵または秘密鍵を含む暗号機能に対する暗号モジュール･レベル」に表とし

て書かれている。

ii) TOE (Target of Evaluation)

CA 製品の機能は次の 3 種類に分類される。

(1) TOE によって実行される機能

(2) FIPS 140 認証の暗号モジュール内で実行される機能

(3) TOE または環境のどちらかが実行する暗号以外の機能

上記の (1) に分類される機能のセキュリティ要求は「6 項 TOE セキュリティ機能要求」に規定され、

(2)および(3)に分類される機能のセキュリティ要件は「5 項 IT 環境に対するセキュリティ要求」に規

定される。

31

iii) セキュリティ･ポリシー

「3.3 項組織のセキュリティ･ポリシー」では次のように規定されている。

P.暗号

暗号操作を実行するためには必ず、FIPS 認可または NIST 推奨の暗号機能が使われなければ

ならない。

iv) セキュリティ対策方針

「4.2 項環境に対するセキュリティ対策方針」では、環境に対する IT セキュリティ対策方針に次のよ

うに規定されている。

O.暗号機能

TOE は暗号/復号、認証、証明生成/検証に対して認可された暗号アルゴリズムを実装し、また、

認可された鍵生成技法を実装し、さらに (FIPS 140 で) 認証された暗号モジュールを使用しな

ければならない。

v) IT 環境に対するセキュリティ要求

「5.4 項識別および認証」では次の規定がある。

FIA_AFL.1.1 全体でレベル 2 以上、役割およびサービスでレベル 3 以上、の FIPS 140 で評

価認証された暗号モジュールで認証が実行されない場合、対象のユーザ識別に対する認証が

成功した後、管理者構成可能な最大認証の施行において失敗した認証を検知しなければなら

ない。

また、FIA_AFL.1.2 の注釈には、次の記述がある。

ST は (a) 全体でレベル 2 以上、役割およびサービスでレベル 3 以上、の FIPS 140 で評価認証

された暗号モジュールで認証が実行されるか、(b) しきい値に達するかまたはこれを超える場合

にとられるアクションを規定しなければならない。

「5.6 項鍵管理」では次の規定がある。

FCS_CKM.1.1 FIPS 140 で評価認証された暗号モジュールは、次の [ST 指定: FIPS のリスト]

を満たす [ST 指定: FIPS 認可または推奨の暗号鍵アルゴリズム] に従って暗号鍵を生成しなけ

ればならない。

「5.8 項暗号モジュール」では次の規定がある。

FCS_COP.1.1 FIPS 140 で評価認証された暗号モジュールは、[ST 指定: IT 環境によって実行

されるそれぞれの暗号操作に対して、ST は実行される操作が従うべき標準を指定しなければな

らない (たとえば、電子署名は FIPS 186-2 で規定される DSA アルゴリズムに従って生成される)。

実行する操作のタイプが FIPS 認可あるいは推奨のアルゴリズムを持つ限り、FIPS 認可または推

32

奨アルゴリズムは用いられなければならない。FIPS 認可あるいは推奨アルゴリズムが使われない

場合、ST はその操作の実行になぜ FIPS 認可または推奨アルゴリズムを用いなかったかの根拠

を示さなければならない。] に従って [ST 指定: IT 環境によって実行される暗号操作のリスト。

ST 作成者はこの指定を完成するために、IT 環境によって実行される暗号操作の全ての方を含

めなければならない。] を実行しなければならない。

vi) TOE セキュリティ機能要求

「6.７項鍵管理」では次の規定がある。

FDP_ACF_CIMC.2.1 CIMS (Certificate Issuing and Management System) の個人的な私有

鍵は FIPS 140 で評価認証された暗号モジュールに格納されるか、または暗号化して格納されな

ければならない。CIMS の個人的な私有鍵が暗号化されて格納された場合、暗号化は FIPS 140

で評価認証された暗号モジュールによって暗号化されなければならない。

また、 FDP_ACF_CIMC.2.1 、 FDP_SDI_CIMC.3.1 、 FDP_ACF_CIMC.3.1 、

FDP_MTD_CIMC.5.1、FDP_CKM_CIMC.5.1 にも、FIPS 140 を参照する規定がされている。

vii) 機能の強度

「７.2 項暗号モジュール」では次の規定がある。

CIMC が実行する全ての暗号機能は、FIPS 140 で認証された暗号モジュールによって実行され

なければならない。また、暗号鍵の生成およびプレーンテキストの私有鍵および秘密鍵の保存

のために、FIPS 140 で認証された暗号モジュールが必要とされる。

また、「7.2.1.2 項 FIPS 140 で認証された暗号モジュール」に次の規定がある。

FCS_CKM.1、FDP_ACF_CIMC.2 (以降、略) に規定される暗号モジュールは、FIPS 140 で認

証されなければならない。

これと同様に「7.2.1.3 項スプリット･ナレッジ･プロシージャ」に次の規定がある。

FDP_ETC_CIMC.4、FDP_ETC_CIMC.5 (以降、略) に規定されるスプリット･ナレッジ･プロシー

ジャは、FIPS 140 に準拠した実装を行い、FIPS 140 で認証されなければならない。

「７.2.2 項私有鍵または秘密鍵を含む暗号機能に対する暗号モジュール･レベル」では次の規定

がされている。

TOE の要求により実行される全ての暗号操作 (鍵生成を含む) は、FIPS 140 で認証された暗号

モジュール内で FIPS 認可または推奨の運用モードで実行されなければならない。

また、7.2.2 項では前述のように、CIMC のセキュリティ･レベルと FIPS 140 のセキュリティ･レベルの

対応付けがされている。

「７.2.3 項私有鍵または秘密鍵を含まない暗号機能」では次の規定がある。

33

署名検証かつ/または鍵なしハッシュ生成関数を実行するだけの暗号モジュールに対しては、

CIMC のセキュリティ･レベル 1 から 3 に対しては FIPS140 のレベル 1、CIMC のセキュリティ･レ

ベル 4 に対しては FIPS 140 のレベル 2、が全体のセキュリティ･レベルとして満たされなければな

らない。

viii) 根拠

「9.4.1.1.1.1 項 FMT_MSA.2 に関するサポート対象外の依存性に対する理由」では次の規定があ

る。

コンポーネント、FCS_CKM.1 暗号鍵生成、FCS_CKM.4 暗号鍵破壊、FCS_COP.1 暗号操作

は、これらと一致しない FMT_MSA.2 に対して直接の依存性を持たなければならない。このセキ

ュリティ･レベルは FIPS 140 で認証された暗号モジュールの利用を必要とする。ここでリストした

依存性の全ては暗号モジュールの一部を構成する。ゆえに、FMT_MSA.2 への依存性は適用

できない。

34

3. 複数の暗号アルゴリズム実装方式に関するリスク分析と脆弱性評価

3.1 複数の暗号アルゴリズムを実装したシステムの事例

日本および米国において、複数暗号アルゴリズムを実装した事例ないしこれを想定した場合の情

報を入手するために、文献調査およびインタビュー調査を行なった。ここで報告する事例は主に電

子政府システムまたはこれを構築するためのシステムで、秘密鍵、公開鍵、署名鍵に複数の暗号

アルゴリズムが使われている事例である。

事例 1 と事例 2 は米国でインタビューにより情報収集した事例である。また、事例 3 および事例 4

は日本における事例であり、事例 3 はインタビューにより、また事例 4 は文献調査により、それぞれ

情報収集を行なった。

なお、地方公共団体行政サービスオンライン化促進協議会の報告書[15]によると、海外の電子政

府システムにおいて複数暗号方式に対応した事例は見つかっていない。各国で PKI (Public Key

Infrastructure) 相互運用実験が行なわれているが16、複数暗号アルゴリズムを対象としたものは BCA Technology Demonstration Phase2 17のみで、その技術仕様18 では複数の署名アルゴリズム

やハッシュ･アルゴリズムを規定しているが、その実証実験の報告書19 では複数暗号アルゴリズム

に関しては報告されていない。また、本項で紹介した事例以外に、電子政府システムを対象とし複数暗号アルゴリズムに対応して

いるものに、次があることを付け加えておく。･ NTT 情報流通プラットフォーム研究所20、Trust-CANP 21, 22, 23

･名古屋工業大学、EasyCert 24

3.1.1 事例 1: USPS (United States Postal Service) 25, IBIP a. システム概要

USPS (The United States Postal Service、米国郵政公社) が実施している IBIP (Information-Based

Indicia Program) では、Open IBI Postage Evidencing Systems の仕様を規定している26。

IBIP とは、従来の Indicia (料金別納郵便物の証印) を郵便物に貼る代わりに、郵便物に電子的

に Indicia を印刷して処理する新しい方法をサポートするプログラムのことである。Open IBI

Postage Evidencing Systems は IBIP プログラムで利用するシステムをベンダーが開発する場合

に要求されるシステム仕様を定めている。ここで Postage Evidencing Systems とは電子的に

Indicia を印刷し郵送料支払いの証拠を確認するシステム (郵便料金別納証印刷機) のことを指

す27。

ここで、家庭ないし事務所において電子的に Indicia を印刷する装置ないしシステムを Postage

Meters と呼び、これが郵便物ないし郵便物に貼られるラベルに直接、郵便料金を印刷する28。参

35

考として、下の図 7 に Indicia のサンプルを示す29。

図 7. Indicia (電子郵便マーク)

仕様書 [26]では、 Indicia のフォーマット、 Indicia を家庭や事務所で印刷する PSD (Postal

Security Device)、ホスト･システム、IBIP 鍵インフラ (Key Infurastructure) の仕様を規定しており、

デジタル署名として次の 3 つのアルゴリズムをサポートするように要求している。

･ Digital Signature Algorithm (DSA)

･ Rivest Shamir Adleman (RSA) Algorithm

･ Elliptic Curve Digital Signature Algorithm (ECDSA)

なお、前述 2.1.1 実例調査で説明した Hasler, Inc. は USPS から認可を受けて Postage Meters

を扱うサービスを提供している。

b. システム構成図

仕様書[26]から引用したシステムの全体構成図を図 8 に示す。

36

図 8. IBIP システム･アーキテクチャ

なお図中、「プロバイダ」とはサービス提供企業を、PSD は Postal Security Device を指す。

c. データフロー

仕様書[26]から引用した構成要素とデータフローの概略を図 9 に示す。

37

図 9. IBIP Indicia 生成における PSD の役割

なお図中、「プロバイダ」とはサービス提供企業を、PSD は Postal Security Device を指す。

d. 利用暗号技術

暗号の用途

USPS は複数の電子署名アルゴリズムの DSA、RSA、ECDSA をサポートしており、プロバイダが

Indicia にこれらのいずれかの署名アルゴリズムによって署名を行なう。

暗号製品名と鍵長

仕様書[26]が規定する暗号アルゴリズムと鍵長は以下。アルゴリズム鍵長 (ビット)

DSA 1,024

RSA 1,024

ECDSA 21

PSD の開発ベンダーには、Hasler, Inc. とその競合メーカである Pitney Bowes Inc. などがある。

CC/FIPS 140-2 認証情報

IBIP を構成するシステムは、FIPS 140-1 評価認証と USPS による評価認定を必要とする。

38

鍵管理方法

PSD の鍵発行、配布、保管については、FIPS で認可された方法と IBIP 鍵インフラへの準拠が規

定されている。

e. システム利用者

PSD の利用者には Indicia を出力する事務所および一般家庭のユーザを想定している。

f. 取り扱いデータの種類と価値

主なデータには以下の 2 種類がある。

･郵便料金を取り扱う、郵便料金メーター (Meter)、補給データ

･エンドユーザとサーバ間、PSD 装置、郵便料金の交換でやり取りされる認証と暗号化データ

なお、登録時にインフラからダウンロードされる郵便料金メーター (Meter) は$100 である。

g. 脆弱性要因

たとえば$.37 の封書と$13.00 の航空郵便ではリスクが異なる。USPS では、プロバイダの費用を見

積もるためにサンプリング法を用い、封書トラフィック量と購入パターンを比較することにより、(切手

のコピーやリプレイ攻撃など) 不正手段がないかのチェックを行なっている。

(9 桁のバーコードにより宛て先別にソートする) 住所確認のインフラにより同時に署名の検証も行

なっているため、処理速度とリスクが重要なトレードオフになっている。郵便小包の処理速度は遅い

が単価が高いため証明書を確認する必要性が高い。一方、単価の安い封書の場合には統計的手

法によりいくつかを確認するだけで済ませている。

ユーザ、アプリケーション、PSD などびエンティティの権利が失効してから実際の失効処理が反映

されるまでの遅延時間により、料金処理に関する損失が発生する場合が考えられる。この問題に対

して PSD では、郵便料金レジスターの残高のチェックとタイマー機構がリセットされていないかチェ

ックし、PSD の操作を無効化することによって対応している。

また、USPS では複数の暗号アルゴリズムを実装しており、ある固有の暗号アルゴリズムに脆弱性が

発見されたとしても、別の暗号アルゴリズムに切り替えることができ、これによりインシデントの発生

可能性を低減している。

3.1.2 事例 2: 米国政府系銀行 FB (仮称) a. システム概要

米国の FB の銀行業務で利用するシステムで、銀行間の資金振り替えなどさまざまな銀行業務の

処理を行なう。なお、機密保護のためにこの事例の詳細な情報は入手できなかった。

39


FB 銀行業務のサービスで利用されるアプリケーションの典型的なシステム構成図を次の図 10 に

示す。

暗号ライブラリは、銀行システムの大量のトランザクションおよび高価値のデータを処理するために、

アプリケーション固有の暗号 API を提供している。暗号ライブラリは汎用の PKI ツールキットを利用

して開発されており、PKI ツールキットはそれより低位のスマートカードやハードウェア･アクセラレー

タとインターフェースを取るために利用されている。

図 10. FB アプリケーションのシステム構成


クライアントとサーバ間の構成を次の図 11 に示す。

クライアント側 PC はスマートカードと繋がっており、エンドユーザはスマートカードとパスワードによ

る二要素ユーザ認証を行なう。

40

クライアント PC 上のアプリケーションは、ハードディスクや PCMCIA カードなどを用いて、アプリケー

ション間の認証および鍵交換を行なう。また、アプリケーション内部およびアプリケーション間のデ

ータは、電子署名および暗号化が行なわれる。

クライアント PC とサーバであるメインフレームとはネットワークで接続されており、その間の通信はア

プリケーション･レベルの鍵を用いて暗号化される。また、クライアント PC とメインフレーム間の接続

された状態では、スマートカードの再初期化などのシステム管理機能が提供される。

図 11. FB アプリケーションのシステム構成


システムが利用する暗号ライブラリでは、複数の対称鍵アルゴリズム (DES、トリプル DES など) を

サポートしている。

また、メインフレーム側システムは当初、トリプル DES 対応を完全にサポートしていなかったため、

現在、DES からトリプル DES への移行中であった。現在、トリプル DES への完全移行が重要課題

となっている。この移行期において両方の暗号アルゴリズムのサポートが必要となり、このために暗

号ライブラリを開発した。なお、暗号ライブラリの実装においては、DES およびトリプル DES の実装

に異なるパッディング方法を用いている。また、暗号ライブラリにより、PC のハードディスク、スマート

カード、ハードウェア･アクセラレータ･カードという複数の暗号記憶装置をサポートしている。

暗号の用途

共通鍵暗号および公開鍵暗号がデータの暗号化のために用いられている。また署名の生成

および検証に電子署名が使われている。コンポーネント別には次のように暗号が使われている。･メインフレーム: DES/トリプル DES による暗号/復号

･ハードウェア･アクセラレータ: RSA 暗号/復号、デジタル署名の生成/検証、DES/トリプル DES

41

による暗号/復号、鍵ロード

･デスクトップ PC: RSA 暗号/復号、デジタル署名の生成/検証、DES/トリプル DES による暗号/復

号、鍵ロード

･スマートカード: RSA 暗号/復号

暗号製品名と鍵長

暗号製品名および鍵長については、機密情報のため入手不可であった。 CC/FIPS 140-2 認証情報

ハードウェア･アクセラレータ･カードについてのみ FIPS 140-1 認証製品を利用。鍵管理方法

ユーザの私有鍵でアプリケーション･レベルの鍵にアクセスし、アプリケーション･レベルの鍵が追加

の鍵をアクセスし、といった形の鍵の動的な関係付けを処理するために、複雑な鍵管理スキームを

暗号ライブラリにより実装している。

また、中間的な鍵の保管場所として PC のハードディスクが使われている。鍵はハードディスクに書

き込まれる前に暗号化される。それぞれの銀行アプリケーションは固有のアプリケーション･レベル

の鍵を持ち、CPU で処理を行なっている。スマートカードにはユーザ認証のための私有鍵、トップ

レベル CA の公開鍵、暗号化された秘密鍵の保管を行なう。また、ハードウェア･アクセラレータ･カ

ードにより、アプリケーションのみで使用される秘密鍵の保管がされる。


銀行システムを利用するエンドユーザ。また、銀行間の資金のやり取りでは相手側銀行が利用者と

なる。


銀行サービスのトランザクションとしてやり取りされる金銭のデータ。また、スマートカードを用いたユ

ーザ認証、署名、証明書のデータがサーバ/クライアント間でやり取りされる。

取り扱う主なデータは金銭データであるため通常のデータよりも価値が高い。さらに、銀行間でやり

取りされるデータは一般ユーザと銀行間でやり取りされるデータよりもはるかに高額のデータがやり

取りされ、価値が非常に高い。

g. 脆弱性要因

複数鍵の同時利用をサポートするように、高レベルの鍵管理オブジェクトが実装されており、また暗

号ライブラリやツールキットにより鍵が残らない処理を行なっていて、ワーキング･メモリやディスクに

残った鍵などのデータ漏えいを防止する対策が取られている。

暗号ライブラリにはダイナミック･リンク･ライブラリ、周辺機器にはドライバを用いる場合があるが、こ

れらが不正なものに置き換えられて脆弱性が発生する場合が考えられる。この問題に対し FB で

は、ベンダーがダイナミック･リンク･ライブラリ (DLL) でなくスタティック･リンク･ライブラリを使用する

42

ように要求している。また、電子署名を保存するために使われるハードウェア･ドライバでは、アプリ

ケーション起動時に偽物でないことを検証するようにしている。

複数の暗号アルゴリズム実装には関係ないが、デバッグなどのためにエラーログに暗号アルゴリズ

ムや鍵などに関する機密情報が出力される場合があり、FB ではエラーログ作成をプログラミング

におけるマクロ関数の使用に制限することによって、この問題に対処している。

3.1.3 事例 3: 株式会社オレンジソフト、S/Goma 30 a. システム概要

株式会社オレンジソフトでは、次の 2 つのソフトウェアの開発を行なっている。

･ S/Goma V2 (S/MIME v2 に対応し Winbiff v2.X を S/MIME 対応にするためのアドインソフト)

･ S/Goma OE (政府認証基盤 (GPKI）拡張が可能とする Microsoft Outlook Express のプラグ

イン)

S/Goma OE は、IPA の委託により政府認証基盤 (GPKI）対応アプリケーションとして開発されたも

のであり、複数暗号アルゴリズムを実装した暗号ライブラリ AiCrypto 31を用いて、公開鍵証明書を

正当に扱うことを可能とする32。

なお、S/Goma OE とほぼ同じアーキテクチャで設計され、実証実験のために開発したアプリケーシ

ョンがあり、本調査ではこの実証実験で用いたものを対象とする。この実証実験で用いたアプリケ

ーションは、S/Goma OE と異なり、S/MIME 形式での電子メールの取り扱いを可能とする。また、現

時点では製品化の予定がなく製品名が付けられていないが、将来的には S/Goma のシリーズとな

るため、便宜的に S/Goma に含めている。


実証実験に用いた版のシステム構成図を資料[32]から引用し下の図 12 に示す。

43

図 12. S/Goma システム構成図

また、S/Goma OE もほぼ同じシステム構成であるが、Outook Express に対応するために

CryptoAPI を一部用いている 32。


S/Goma は PKI アプリケーションとして CA と証明書のやり取りを行なう。CA とのデータのやり取り

を示した図を、S/Goma を用いて実証実験を行なった報告書[33]から引用し下の図 13 に示す。

44

図 13. S/Goma データフロー

図中の EE-A および EE-B で S/Goma OE が用いられている。


暗号の用途

署名鍵: RSA (上限 4,096 ビット)、DSA (1,024 ビット固定)

秘密鍵: RC2 (40、128 ビット) 、DES (56 ビット)、トリプル DES (168 ビット)

公開鍵: RSA (上限 4,096 ビット)

RSA は証明書生成では 1,024 ビットおよび 2,048 ビットに対応し、また 4,096 ビットまでの証明書を

生成可能。DSA は署名および証明書のインポートで利用。暗号製品名と鍵長

暗号ライブラリ AiCrypto 31 •

• IC カードドライバ

それぞれの暗号に対する鍵長は、上述の「暗号の用途」を参照。

CC/FIPS 140-2 認証情報

CC および FIPS 140-2 認証は取得されておらず、現時点では取得の予定もない。ただし、政府の

採用基準となれば検討する予定。

鍵管理方法

鍵は、IC カードおよび証明書 DB で管理される。


PKI (特に GPKI) において、電子メールを利用する利用者。

45


メール (電子署名、暗号通信) •

• 証明書

署名および暗号化されたメールは、通常のメールよりも機密性や本人性を有する場合に用いられ、

通常のメールよりも価値が高いと言える。

g. 脆弱性要因

脆弱性要因として考えられるのは、RC2 (40 ビット) などセキュリティ強度の低い暗号アルゴリズムを

システム利用者が選択した場合である。この機能は、これら古い暗号アルゴリズムを用いているユ

ーザへの便宜のために残された機能である。

3.1.4 事例 4: 三菱電機株式会社他、Crypto-API a. システム概要

IPA の委託により、三菱電機(株)、(株)NTT データ、日本電気(株)、(株)日立製作所、富士通(株)

は平成 12 年度および 13 年度にかけて、PKI ライブラリの標準仕様34 とそれに基づくライブラリの

開発を行なった35。ここでは、複数暗号アルゴリズムを用いた電子政府システムが考察の対象であ

るため、API 仕様自身ではなく、Crypto-API 検証実験36 で用いたシステムを対象とする。


Crypto-API は PKI ライブラリの標準仕様であるため、仕様書[34]からそのシステム構成図を下の図 14 に引用する。

46

図 14. Crypto-API システム構成図

なお、図 14 中、CSP は Cryptographic Service Provider の略で暗号アルゴリズムを実装したモ

ジュールを指し、HSM は Hardware Security Module の略で耐タンパー性を有する秘密鍵管理装

置を指す。


資料[36]から実証実験の際に用いたシステムにおける簡単なデータフローの図を図 15 に引用す

る。

47

図 15. 認証基盤モデル


暗号の用途

共通鍵アルゴリズム: DES-EDE3、MISTY1、MISTY2

公開鍵アルゴリズム: RSA

署名アルゴリズム: sha1WithRSAEncryption、ECDSA 暗号製品名と鍵長

プロジェクト参加メンバが分担協力して自主先行開発したプロトタイプまたは製品 (三菱電機

CERTMANAGER、日立 Enterprise Certificate Manager など) 。

楕円曲線暗号 (ECDSA) の鍵長は192ビット。なお、これ以外の鍵長は収集した資料[343536]に明

記されていない。

鍵管理方法

HD、IC カード、HSM のそれぞれに対応した鍵管理 CSP および証明書管理 CSP を選択/切り替え

可能。


Crypto-API は PKI 製品開発ベンダーが利用者となるが、Crypto-API を用いて開発された PKI シ

ステムは政府および一般ユーザが利用者となる。

48


鍵および証明書。複数署名アルゴリズムで署名を行なう場合は、複数の鍵および証明書を扱うこと

となる。また、政府認証基盤 (GPKI）の利用場面で電子署名法特定業務認定を取得している場

合、手書き署名や押印と同等の法的効力を有するため、通常の場合よりも価値が高いと言える。

g. 脆弱性要因

検証実験報告書[36]では、設計、実装、運用において複数暗号アルゴリズムによる大きな脆弱性は

報告されていない。なお、報告書では次のような脆弱性が指摘されている。

･複数暗号アルゴリズムをエンドユーザが切り替えられるよう運用した場合、故意または過失などに

よって、ポリシーで規定した暗号アルゴリズムや証明書検証仕様が個々のユーザで利用されな

い可能性がある。このため、暗号アルゴリズム独立および証明書検証仕様独立の切り替え制御

には、運用管理者だけが切り替え制御可能とする運用方法を推奨している。

･各独立機構を実現するために CSP を切り替えられるようにしているが、これによりプログラム･コー

ドに対する変造等の脅威に対して相対的に弱くなる。

49

3.2 暗号アルゴリズムの単一実装と複数実装の差異分析

前述の 3.1 項で述べた事例を元に、電子政府システムにおいて暗号アルゴリズムの単一実装の場

合と複数実装の場合の差異分析を行なった。4 つの事例を複数暗号アルゴリズムの実装方法で分

類すると次のようになる。

a. 複数の共通鍵アルゴリズムを実装したアプリケーション

3.1.2 事例 2: 米国政府系銀行 FB (仮称)、3.1.4 事例 4: 三菱電機株式会社他、Crypto-API

では、複数の共通鍵アルゴリズムを実装している。なお、複数の共通鍵暗号アルゴリズムの実装は、

SSL 対応のブラウザなどでは一般的に行なわれている。

b. 複数の署名アルゴリズムを実装したアプリケーション

3.1.1 事例 1: USPS (United States Postal Service) , IBIP 、3.1.3 事例 3: 株式会社オレンジソフ

ト、S/Goma 、3.1.4 事例 4: 三菱電機株式会社他、Crypto-API では複数の署名アルゴリズム

に対応している。

なお、S/MIME v337では複数の暗号アルゴリズムへの対応が考慮されており、NIST では政府向け

に S/MIME v3 クライアントで使うべき暗号アルゴリズムの組みを暗号アルゴリズム･スイートとして定

め、複数の暗号アルゴリズム･スイートを使うように規定している38、ことを付け加えておく。

差異分析では設計、構築、運用の 3 種類のフェーズに分け、さらにフェーズごとに次のような事項

を考慮し、詳細な項目に分けて記述を行なった。

フェーズ考慮した項目

設計ライブラリの組み合わせ、製品選定、暗号アルゴリズム(鍵長)の選定

構築製品のインストール(環境設定)、テスト

運用鍵管理、暗号アルゴリズム切り替え(移行)、ユーザサポート(ヘルプデスクなど)

3.2.1 システム設計 a. 設計および設計コスト

複数実装の場合には次のような考慮を行なう必要がある。

･ブロック長の違いをどう吸収するか (共通鍵・公開鍵ともに)。

･公開鍵暗号でのパラメータの（種類の）違いをどうするか（例えば、RSA では鍵長だけが決ま

れば鍵生成が可能だが、楕円曲線暗号では、曲線パラメータも入力しなければならない）。

50

しかし、今回調査したいずれの事例においても、当初から複数暗号アルゴリズムへの対応を想定し

た設計および開発作業を行なっているため、単一実装と比べて設計および設計コストの差はわず

かである。

b. 暗号製品選定

事例 2 FB では、設計時に製品選定が行なわれたが、メインフレームにおける DES およびトリプル

DES の実装 (パッディングなど) に独自の方法を取ったため、同じアルゴリズムを実装した別のベ

ンダー製品の間で相互運用性の問題が生じた。

事例4 Crypto-APIでは、開発した Crypto-API を適用するように既存製品の改造を行なっており、

同じ Crypto-API を利用した製品を選定の前提にしている。

単一実装の場合、指定した単一の暗号アルゴリズムを実装した暗号製品から選定することになり、

製品選定は単純である。一方、複数実装の場合、指定した 1 部または全ての暗号アルゴリズムに

対応する製品を選定する必要があり、さらに暗号アルゴリズムの切り替えを考慮する必要があるた

め、単一実装よりも複雑で多くの選定作業を必要とする。

c. データフロー上の各ポイントにおける脆弱性

今回調査を行なった事例では暗号ライブラリまたは API の利用により複数暗号アルゴリズムへの対

応を行なっており、いずれの事例においてもシステム設計における脆弱性は報告されていない。こ

のように、システム設計における脆弱性においては、単一実装と複数実装で大きな差はないと考え

られる。

3.2.2 システム構築 a. 構築コスト

事例 3 S/Goma および事例 4 Crypto-API では、設計当初から複数暗号アルゴリズムへの対応を想

定し、暗号ライブラリおよび API を用いているため、実装時に単一実装と複数実装で大きな差は考

えられないが、複数実装によりユーザがインストール後に暗号アルゴリズムを指定するという作業が

新たに発生し、単一実装に比べてわずかな差が生じている。

しかし、システム構築では設計やプロジェクト管理などの要因が重要な位置を占めているため、上

記の差は大きな影響を与えず、単一実装および複数実装による大きな差は考えられない。

b. テスト

事例 2 FB では、独自の暗号ライブラリ開発と複数の用途に複数暗号アルゴリズムが使われている

ためテストケースが増加し、さらに一部のテストを手動で行なう必要があるため、単一実装に比べて

テスト作業が大きく増加している。

事例 4 Crypto-API では、複数の暗号アルゴリズムおよび暗号アルゴリズムの切り替えのテストを行

51

なっており、単一実装よりもテストケースが増えている。

システム構築におけるテストにおいては、複数実装は単一実装に比べ、複数の暗号アルゴリズムに

対するテストと、暗号アルゴリズムの切り替えのテストを行なう必要があり、テスト量が増えている。手

作業によるテストが必要な場合には作業量ははるかに大きくなり、また暗号アルゴリズムの種類が

増えると組み合わせが増えるため、複数実装のテストにかかる作業量は一層増えることになる。

c. システム構築における脆弱性

暗号製品における脆弱性のほとんどは、暗号アルゴリズム自身ではなく、その暗号アルゴリズムを

正しく実装していないことが原因で発生している。特に、ワーキング･メモリに残った鍵などのデータ

がクリアされず、これを盗むことにより脆弱性が発生した事例がある。

暗号ライブラリまたは API の実装においては、個々の暗号アルゴリズムを正しく実装するだけでなく、

暗号アルゴリズムの切り替え部分の実装が複雑なため、ここに脆弱性が発生する可能性がある。

3.2.3 システム運用 a. 運用コスト

事例4 Crypto-APIでは、単一実装の場合にはアプリケーション全体の置換および再設定に手間が

かかり (およそ 1 時間)、複数実装の場合には外部指定ファイルの変更だけで済む (およそ 10 分

以内)、と報告している。また複数実装により、配布作業の減少だけでなく、トラブルシューティング/

ヘルプデスク作業の効率化が期待できる、とも報告している。

基本的な運用コストは、単一実装の場合も複数実装の場合も差はないと考えられるが、問題は暗

号アルゴリズムの切り替えまたは移行が必要になる場合である。単一実装では運用停止して別の

暗号アルゴリズムを実装したシステムへの移行作業が必要となるのに対し、複数実装では別の暗

号アルゴリズムへの切り替えで済むため、複数実装の場合の方がコストが少なくて済む。

b. システム利用者（政府、運用管理者、エンドユーザ）への影響

事例 3 S/Goma では、エンドユーザが証明書作成時に暗号アルゴリズムを選択することができ、簡

単な操作で暗号アルゴリズムを切り替えることが可能である。一方、単一実装の場合にはアプリケ

ーションの置き換え作業が発生するため、複数実装の方が影響が少ない。

事例4 Crypto-APIでは、単一実装の場合にはアプリケーション全体の置換および再設定に手間が

かかり (およそ 1 時間)、複数実装の場合には外部指定ファイルの変更だけで済む (およそ 10 分

以内)、としている。

通常の運用において単一実装と複数実装に大きな差はないが、暗号アルゴリズムの切り替えまた

は移行において、単一実装では運用停止や構築などの作業を行なう必要があるため、単一実装

の方が運用管理者やエンドユーザに負担がかかる。一方、複数実装では設定ファイルの変更など

52

の簡単な作業で切り替えを行なうことができ、単一実装に比べて影響は非常に小さい。複数実装

の場合、エンドユーザが自由に暗号アルゴリズムの切り替えを行なうと問題が発生する可能性があ

るため、運用管理者のみが切り替えを行なえるようにすべきである。

なお、複数暗号アルゴリズムのサポートにより、ユーザサポートの手間が増えることが考えられるが、

全体のサポート量から比べると大きな差とは考えられない。

c. 鍵管理

鍵管理では、暗号アルゴリズムまたは API (Application Program Interface) が差を吸収しているた

め、単一実装と複数実装で大きな差は生じていない。なお、スマートカードに鍵の保管を行なうの

が理想的であるが、スマートカードのメモリおよび性能などの制約があるため、複数暗号アルゴリズ

ムの場合、保管するデータや実装方式に制限が追加される場合が考えられる。

d. インシデント対応

事例 4 Crypto-API では、単一実装の場合にはアプリケーション全体の置換・再設定で手間がかか

る (およそ 1 週間以内) とし、複数実装の場合にはアプリケーションの置換･再設定に伴うサービス

停止は短くなる (およそ 1 日以内) と報告している。

単一実装の暗号アルゴリズムに脆弱性が見つかった場合、サービス停止などの措置を取り、別の

暗号アルゴリズムを実装したシステムへの移行が必要となるため、作業量が大きい。一方、複数実

装では、別の暗号アルゴリズムに切り替えることができ、比較的短期間にサービスを復旧することが

できるが、新しいアルゴリズムの追加や切り替え作業不良により新たな問題が発生する可能性があ

る。

e. システム運用における脆弱性

事例 3 S/Goma では、過去からの互換性のためセキュリティ強度の低い暗号アルゴリズムのサポー

トを行なっており、このセキュリティ強度の低い暗号アルゴリズムを選択した場合の脆弱性が考えら

れる。

事例 4 では暗号アルゴリズムの切り替え制御に関し、利用者が切り替えられるようにした場合に、故

意または過失により、エラーが発生する恐れがあると指摘し、運用管理者だけが暗号アルゴリズム

の切り替え制御可能とする方法を推奨している。同時に、PKI ライブラリのプログラム･コードに対す

る変造等の脅威に対しても相対的に弱くなることを指摘し、運用管理者が OS アクセス制御機能を

用いて保護するようなセキュリティ対策の必要性を述べている。

システム運用における脆弱性では、複数実装の場合に暗号アルゴリズム切り替えにおける作業手

順不良によるセキュリティホールが発生する可能性が考えられる。しかし、単一実装の場合には、

実装した暗号アルゴリズムの脆弱性が発見された場合に、システムの置き換えが発生し、ある程度

長期に渡って運用を継続できない期間が発生するという大きなリスクが存在している。

53

3.3 複数暗号アルゴリズム実装の脅威低減の方策

3.2 項で述べた単一実装と複数実装の差異分析の結果を基にすると、複数実装におけるリスクと脆

弱性に次のような問題を指摘することができる。

･暗号アルゴリズムの切り替え部分の実装が複雑であるため、ここに脆弱性が発生する可能性が

ある。

･暗号アルゴリズムの切り替え作業において、作業手順不良によるセキュリティホールが発生する、

など、運用面で問題が生じる場合が考えられる。

上記の問題に対し、次のようなリスク低減策を提案する。

･複数の暗号アルゴリズムに対応し、かつ安全な API (Application Program Interface) の研究開

発を行い、さらに開発した API を標準化する。

･暗号アルゴリズムの切り替え作業手順など運用規定を作成し、これを CC や ISMS (Information

Security Management System) 等で評価する。

以降では、上記の問題および対策を詳細に述べるために、複数実装のメリット、複数実装による脅

威、脅威低減の対策、のそれぞれについて説明する。

3.3.1 メリット

単一実装では実装した暗号アルゴリズムに脆弱性が発見された場合、別の暗号アルゴリズムを実

装したシステムへの置き換えが必要となり、システム運用停止など大きなリスクが存在する。これに

対し、複数暗号アルゴリズムを実装した場合には別の暗号アルゴリズムに容易にかつ短期間に切

り替えを行なうことができるため、これによって単一実装の脅威の大きさを低減できるというメリットが

ある。

3.3.2 脅威

3.2 項で述べた単一実装と複数実装の差異分析の結果を基にすると、単一実装に比べて複数実

装に次のような脅威が存在する。

a. 実装面における脅威

複数実装では暗号アルゴリズムの切り替え部分の実装が複雑であるため、この実装部分に脅威が

発生する可能性がある。

b. 運用面における脅威

複数実装において暗号アルゴリズムに脆弱性が発見された場合、別の暗号アルゴリズムに切り替

えることによって問題に対処することができる。しかし、この暗号アルゴリズムの切り替え作業におい

ては、作業手順の不良によりセキュリティホールが発生するなど、運用上の脆弱性が考えられる。

54

また、この切り替え作業の際には、個々のエンドユーザが行なうとミスが発生する場合が高くなる。

さらに、複数実装では運用停止しなくても切り替えを行なうことができるため、弱い暗号アルゴリズム

が使われ続けた場合に脆弱性が発生する。

3.3.3 対策

3.3.2 脅威で挙げた脅威を低減するためには、具体的に以下の対策を行なう必要がある。

a. 実装面における対策

複数実装において、暗号アルゴリズム切り替えの実装部分に発生する脅威を低減するためには、

この切り替え部分の実装に脆弱性が発生しない、安全なAPIの研究開発を行なう必要がある。また

開発した API を標準化し、複数暗号アルゴリズムを実装したシステムで利用できるよう様々な普及

策を講じる必要がある。

b. 運用面における対策

複数実装において、暗号アルゴリズム切り替えの運用作業で発生する脅威を低減するためには、

暗号アルゴリズム切り替え作業手順などの運用規定を作成し、これを CC 評価認証制度や ISMS

適合性評価制度などにより評価を行なって安全性を保証すべきである。

また、この切り替え作業の際のミスを防ぐために、運用管理者だけに切り替え作業を許可する規定

を設け、さらに指定の暗号アルゴリズムに切り替えるためのツールを開発してエンドユーザ全員の

切り替えを運用管理者が短時間に行なえるようにする対策も必要である。

さらに、暗号アルゴリズム切り替えまでの弱い暗号アルゴリズムが使われ続けることから発生する脅

威に対応するために、暗号アルゴリズム切り替えの指示を周知徹底させる連絡体制の整備や切り

替えツールの開発をあらかじめ行なっておく必要がある。

55

4. その他実装方式に関する重要事項

4.1 米国における暗号実装技術の最新動向スマートカードでは暗号鍵のような秘密情報がメモリに記録され、それを CPU がアクセス制御するこ

とによって、容易なデータの読み出しを不可能にする耐タンパー性が実現されている。そのため従

来よりも安全性の高いクレジットカードや電子マネーの提供が可能になり、情報セキュリティのキー

デバイスの一つとして期待が寄せられている。

日本でも、ｅ-Ｊａｐａｎ重点計画に基づく電子政府・電子自治体の構築（申請・届出のオンライン化）

の基盤となる、住民基本台帳ネットワークシステムにおいて、今年 8 月からスマートカードが導入さ

れ希望者に発行される予定である。

これに代表されるように、暗号実装技術の普及、そしてそれらを利用した電子政府のシステム導入

は急速に進んでいくと思われる。しかし、近年、それら暗号実装技術に対する攻撃もまた多数報告

されている。4.1 項では、学会を中心に発表されている暗号実装技術への最近の代表的な攻撃の

研究動向を整理する。

調査のために、以下の 3 名の暗号専門家にインタビューを行なった。

･ Paul Kocher, Cryptography Research, Inc.39

･ Tom Caddy, InfoGard Laboratories40

･ Bill Kaliski, RSA Laboratories41

また、文献調査として CHES （Cryptographic Hardware and Embedded Systems）ワークショップ42

で発表された論文を中心に文献を調査した。

4.1.1 サイドチャネル攻撃の状況

耐タンパー･デバイスを用いたセキュリティ･システムの設計者は、多くの場合、信頼できる計算環境

の中に秘密情報が保存され、それらの情報が外部からはアクセスできないことを想定している。し

かし、実際のコンピュータやマイクロチップは秘密情報を用いて演算を行う際、設計者の予想しな

かった情報 (side-channel information) を外にもらしてしまう43。このような不注意な実装による、設

計者の予期しない情報を利用して、秘密情報の解析を行なう方法がサイドチャネル攻撃である。

サイドチャネル攻撃はもともと Paul C. Kocher らにより提案された、実際に暗号が実装された装置

に対する攻撃法である。これは、実行時の漏洩情報、すなわち、暗号処理装置外部から計測可能

な情報（例えば、計算時間や電力消費量など）と、秘密鍵等の秘密情報との間の相関関係を利

用して、秘密情報を推定しようとする攻撃手法であり、特にスマートカードに対しては、大きな脅威

となりうることが報告されている44。

なお、FIPS 140-2 が制定された時点ではこの攻撃を完全に防ぎ得る対処法は分かっていなかった

が、ある程度回避し得る方法として、電力消費を平均化するコンデンサの使用、内部電源の使用、

暗号処理中の電力消費を平均化するアルゴリズムやプロセスの採用が挙げられている。サイドチャ

56

ネル攻撃の例としては、SPA (Simple Power Analysis) 攻撃、DPA (Differential Power Analysis) 攻

撃、タイミング攻撃などが知られている 51。

a. SPA （Simple Power Analysis）攻撃

SPA 攻撃は単純電力解析と呼ばれ、統計的手法を用いずに、電力消費量の波形を直接観測する

ことで秘密情報を推定する手法である 44。スマートカードなどの耐タンパー・デバイスのほとんどはト

ランジスタで構成された論理回路からなり、ゲートに電圧が加えられると電流が流れ、電力が消費

される。一般に回路の消費電力は、実行している演算と用いられているデータの値に関係している

ため、処理されるデータの種類により実行パスが異なる暗号実装の場合、消費電力から実行命令

系列が明らかになり攻撃されやすい 43。以下はその例である。

DES 鍵スケジュール：

DES の鍵生成部では各段においてビットシフトを行う。このときシフトされる鍵のビット値でそれぞれ

分岐される。もし実行パスが分岐により異なるならば、消費電力の違いから単純電力解析が有効と

なる。

DES 置換：

DES のアルゴリズムでは多くの置換が行われる。置換されるデータによって置換アルゴリズムが異

なる場合、置換時の消費電力の違いから情報を得ることができる。

比較：

系列や数値の比較を行ってミスマッチが生じた場合、通常条件分岐が起きる。このような条件分岐

は消費電力の大きな違いとなって外部から観察可能である。

べき乗剰余演算：

RSA 暗号系では、法ｎ (＝pq) によるべき剰余演算Ｙ≡ xd mod n が計算される。乗算が演算中

のどの時点で行われるかは、べき指数 d （署名生成及び復号における秘密鍵）に依存して決まる。

Binary 法と呼ばれる基本的なべき乗剰余演算は d を上位桁から順にスキャンしていき、ビット値が

"1"のときのみ乗算を行いながら平方演算を繰り返す。もし平方演算と乗法演算がそれぞれ異なる

電力消費や計算時間を見せたり、異なる計算回路を用いる場合は、秘密鍵 d についての全情報を

得ることができる。また Binary 法以外にも Windows 法など様々なアルゴリズムが研究されているが、

これらのべき剰余演算アルゴリズムに対する SPA、DPA も研究されている。

楕円曲線上の乗算：

楕円曲線暗号系では、曲線状の点のスカラー倍演算Ｑ＝dＰが行なわれる。スカラー倍演算は、

べき剰余演算と同様のアルゴリズムにより行なわれ、点の加算と 2 倍算が繰り返し行なわれる。した

がって、電力波形を解析することにより、点加算と点 2 倍算の波形の特徴の違いを識別できればス

カラー値 d のビットを特定できる。

57

b. DPA （Differential Power Analysis）攻撃

DPA 攻撃はサイドチャネル攻撃の一種であり、大量の測定値の平均をとって測定誤差やノイズな

どの影響を小さくし、全データの平均値との差分を取ることで、用いられる秘密情報による消費電

力の変化のみを取り出し秘密情報を推定する。この攻撃は、サイドチャネル攻撃の中でも最も強力

な攻撃方法の一つである 44。

DES や RSA に対する攻撃は一般的に知られているため、ここでは、主に楕円曲線暗号に対する

攻撃について記述する。J. S. Coron の DPA 攻撃を考慮に入れると、DPA 攻撃が成立するための

条件は以下の 3 つが前提条件となる。

(1) 楕円曲線状のある点が、計算途中で（タイミングも含めて）出現するか否かにより、スカラー値

の情報を攻撃者が引き出すことが出来る。また、そのような点が存在する。

(2) 判別点の座標の値が、攻撃者にとって計算可能である、もしくは有意な確率により、推定可

能である。

(3) サイドチャネル情報を用いて、判別点が出現したかどうかを、攻撃者が判定できる。

この 3 つ全てが満たされれば、攻撃者は DPA 攻撃を成功させることが出来る。

Ⅰ) 攻撃者は、入力する点の集合を判別点（入力する点に依存して決まる）の座標の値により、2

つのクラスに分類する（(1)よりそのような点が存在し、(2)より攻撃者が実行可能）。

Ⅱ) 攻撃者は、サイドチャネル情報を収集し、判別点が出現したか否かを判定する（(3)より攻撃

者が実行可能）。

Ⅲ) 攻撃者は判別点が出現したか否かが分かるので、スカラー値の部分情報を特定できる（(1)よ

り攻撃者が実行可能）。

従って、DPA 攻撃を防ぐには(1)～(3)のいずれかの条件の成立を阻止する必要がある45。

c. タイミング攻撃

サイドチャネル攻撃の一種であり、漏洩情報として計算時間を用いて秘密情報を推定する攻撃法

である。暗号アルゴリズムを実装する場合、処理時間の短縮やプログラムサイズの縮小を狙って、

処理の最適化を行うことが多い。最適化とは、例えばデータのあるビットが 1 であるか 0 であるかに

よって、行う必要のない処理をスキップしたり、分岐して異なる処理を行ったりすることである。この

ような方法で実装すると処理時間がデータに依存して異なってくるため、処理時間を見ることで秘

密情報を推定することができる。これがタイミング解析の原理である。秘密情報推定の際に、統計

的処理を行って推定する方法もあるし、一度の計算時間から秘密情報を割り出す方法もある 44。タ

イミング解析を行う上で，次の前提条件をおく。

(1) 秘密情報は攻撃中には不変である。

(2) 攻撃者は実装されているアルゴリズムを知っている。

(3) 攻撃者は暗号化 1 回の処理時間を正確に計測可能である。

これらの条件が揃ったとき、攻撃は次のように行われる。

Ⅰ) 実装アルゴリズム中で，処理時間差を生じる部分のうち 1 ヶ所に注目する。

58

Ⅱ) 計測できるのは暗号化全体の時間だけなので、注目した部分以外の時間差が (統計的に)

無視できるまでの量のメッセージ (平文) を入力し、暗号化の処理時間を計測する。

Ⅲ) その計測データから秘密鍵情報を推定する。

また、最近では、キャッシュメモリをサイドチャネル攻撃の情報漏洩の手段として用いる｢キャッシュ

攻撃｣に関する理論的な脆弱性の報告がされている46。

d. 電磁解析攻撃

その他、電磁解析攻撃という方法もあり、その攻撃では暗号チップの周辺にコイルを近づけ、電磁

放射を測定して暗号チップの各部分の動作を推測する。得られた電磁放射量は電力波形量と同

様の処理が行われる。ただし、実際の測定にあたっては、チップのパッケージと保護層をはがす必

要がある。

サイドチャネル攻撃は、比較的検出の可能性が低く耐タンパー･デバイスに証拠が残りにくい。被

害者は攻撃された事が気付きにくいことから、特に攻撃後の処置や対処が施しにくい面倒なものと

されている。しかし、サイドチャネル攻撃が実行されるには 100 から 1000 もの莫大なサンプルの収

集が必要となり、その攻撃対象のデバイスは通常の、また場合によっては特殊な計算の実行が可

能であるものでなければならない。また攻撃対象のデバイスと攻撃者の装置が比較的近接してい

なければならないという物理的条件も必要である。

4.1.2 サイドチャネル攻撃対策の研究・開発動向

FIPS 140-2 では、"Mitigation of Other Attacks" （その他､攻撃軽減策）として、いくつかの攻撃法

に対する処置について触れている。詳しくは 4.2.1 項で説明するが、ここではその処置も踏まえて

対策を述べていく。

a. SPA 攻撃対策

FIPS 140-2 が制定された時点では、攻撃を完全に防ぐことができる対処法は分かっていなかった

が、ある程度回避できる方法として、電力消費を平均化するコンデンサの使用、内部電源の使用、

暗号処理中の電力消費を平均化するアルゴリズムやプロセスの採用が SPA と DPA の共通対策と

して挙げられている 51。現在、SPA 攻撃に対する防御法は、ダミー演算を挿入するものや、モンゴメ

リ型楕円曲線を用いるもの、加算と２倍算の演算公式を同一にするものが知られている 44。DES に

おいては、SPA 攻撃を防ぐ方法は比較的簡単に実装することができる。条件分岐演算についても

秘密の中間プロセスや鍵を用いることで多くの単純電力解析の特徴を隠すことができる。しかし条

件分岐を本質的に仮定しているアルゴリズムでは、新たな符号化が必要となり重大なパフォーマン

スの低下を招いてしまう。さらに、オペランド値に大きく依存した電力消費をするシステムでは、実

行パスを同一にしても単純電力により解析が可能である。ただ、現在の共通鍵暗号を実装したデ

59

バイスのほとんどは電力消費量が小さく、単純電力解析により鍵情報を得ることが困難である。また、

AES に関してはコードの実行パスの鍵やデータからの独立化、可能な限りのノイズの生成によって、

SPA での攻撃を困難にさせることが可能である 43。

b. DPA 攻撃対策

1998 年に Paul Kocker により DPA 攻撃が提案されて以来、DES や RSA などの従来からあるアル

ゴリズムに対し、仲介データのマスキング手法による対策が挙げられてきた。しかし今後使用が見

込まれる IDEA や MARS、EC6、Twofish などの論理演算と算術演算関数を一体化したアルゴリズ

ムには、二つの異なるマスキングを行わねばならず、DPA 攻撃を防ぐには不十分であった。T.

Messerges はそれらのアルゴリズムを対象とした、"⊕mask" と "+ mask" を併せた手法を提案した

が、後ほど Jean-Sebastien Coron と Louis Gubin によって DPA を防ぐには不十分であることが指摘

されたため、新しい手法を提案することが必要となった。

DPA に対するより確実な手段としては、Louis Goubin らによって、論理演算と算術演算を搭載する

アルゴリズムに適するマスキング手法が新しく提案されている。

これは、二つの演算を利用した公開鍵 (非対称) アルゴリズムに適用する手法で、論理演算から

算術演算への変換は、比較的簡単な定数 7 を使用し、他方の算術演算から論理演算への変換は

5K+5 を利用しプロセッサー・レジスタのサイズ K（ビット）に比例してマスキングする。このマスキング

手法に使われる二つのアルゴリズムは"XOR"、"AND"、という基礎的なものそして"logical shift

left"という非常に簡単な演算のみを用いている。

これにより、「論理演算マスキングから算術演算マスキング、またその逆への変換において、データ

からでる全ての介在変数がマスキングされる、DPA に対し安全且つ効果的なアルゴリズムの発見」

という課題を解決することとなった47。

また、D. May、H. L. Muller、N. P. Smart らは既存のプロセッサに拡張機能としてランダム・レジスタ

をつけることで、DPA 防御に効果を上げる手法を提案している。

4.1.1 項で紹介したように、DPA 攻撃が成立するための条件は以下の 3 つである。

(1) 楕円曲線状のある点が、計算途中で（タイミングも含めて）出現するか否かにより、スカラー

値の情報を攻撃者が引き出すことが出来る。また、そのような点が存在する。

(2) 判別点の座標の値が、攻撃者にとって計算可能である、もしくは有意な確率により、推定可

能である。

(3) サイドチャネル情報を用いて、判別点が出現したかどうかを、攻撃者が判定できる。

従って、DPA 攻撃を防ぐにはこれら 3 つのいずれかの条件の成立を阻止する必要がある。 (1) を

回避するには、秘密情報（スカラー値）に全く依存しないアルゴリズムが必要になるため、そのよ

うなアルゴリズムの構成は困難と考えられる。 (3) は暗号アルゴリズムの実装環境に依存すると考

えられているが、実際に電力消費量が、格納されているデータのハミングウェイトに依存するとの報

告例もあり、成立すると考えられる。従って、今後 (2) を回避する方法が注力されていくと思われる

が、ランダム化射影座標はその方法の一つである。

60

c. タイミング攻撃対策

タイミング攻撃に対する防御法は、秘密鍵に依存した計算時間差を無くすことと、攻撃者が計算方

法をシミュレートできないように計算の中間状態を隠蔽すること、の 2 つの基本方針に分類される。

具体的には、モンゴメリ型楕円曲線を用い際にダミー演算を常に行うことで計算時間差を無くす方

法と、標数 2 の楕円曲線におけるものが知られている 44。また、FIPS 140-2 においては、タイミング

攻撃法に対するリスク軽減処置として、暗号処理中のタイミングの変動を抑えるアルゴリズムやプロ

セスの採用をあげている 51。

d. サイドチャネル攻撃対策

上記で紹介した攻撃全てを含んだサイドチャネル攻撃に対して、デバイスのベンダーは近年、攻

撃のリスク軽減のために様々な対策法を実装している。主な項目は以下のものである。

・データに依存するタイミングの拡散

回路内での遅延、ダミーメモリアクセスのような余分な動作を挿入したり、また回路や処理の最適

化を控えること（価値はないが、常に付加作業を実行しているような、コストパフォ－マンスの悪い

動作をわざと入れること）を通じて、実行プロセスに無作為性を持たせることが可能となる。

・データに依存する電力消費変動の除去

自動的な回路設計のための代替符号化データの用意、ワイヤー・ロードを減らすための回路バ

ス・レイアウト内で用いられる線の変化量の最小化、複雑な論理における変化量の最小化、ランダ

ム作業の組み入れ、操作の最適化の除去といった対策を複数施す。

・積極的故障検出

状況が把握できない範囲においては、要求操作の実行を先んじて検出し、デバイスの保護対策

をとる。

しかし、これらは長く継続するうちに観測データが蓄積され、平均値などの算出から対策法を見破

られる可能性もあるため、攻撃から保護するには完全とは言えない。また対策を施していても、攻

撃や何らかの影響で対処法が施されていない初期状態に戻ることも有り得るので、プログラムなど

により対策の再設定が可能となるようにすべきである。

知識レベルの向上および攻撃の多様性の増加に伴い、効果的な対策法への必要性も高まってい

る。後手の対策では根本的な脆弱性を不当に利用する攻撃者の侵入を困難にはできても、結局

は攻撃に必要な時間とコストを吊り上げるだけで完全に攻撃を防ぐことは出来ない、という対策法

の限界についても認識されるべきである。

サイドチャネル攻撃に対する対策として、桶屋勝幸、宮崎邦彦、櫻井幸一らはモンゴメリ型楕円曲

線上の高速なスカラー倍計算方法を挙げている。彼らはモンゴメリ型楕円曲線におけるスカラー倍

計算において、計算量が増大しないランダム化射影座標を提案している。

61

ランダム化射影座標は、楕円曲線暗号に対するサイドチャネル攻撃を防ぐための有効な一手法で

ある。これは、座標表現をランダム化することにより、特定の数値の出現を攻撃者に対して予測不

能とする防御方法である。しかしながら従来法では、座標表現のランダム化により射影座標の 1 つ

である Z 座標の値を 1 とすることしか出来ず、そのため Z 座標との乗算が発生し計算量が増大して

いた。また、モンゴメリ型楕円曲線における元々のスカラー倍計算法では、Z 座標が 1 であるため高

速計算可能であるが、ランダム化をしていないためサイドチャネル攻撃に対しては脆弱である。

提案の対策では、楕円曲線上の 1 つの点に対し、座標表現をランダム化した点とランダム化してい

ない点という 2 つの表し方を用いることにより、サイドチャネル攻撃への耐性と計算の高速性を達成

している。また、この対策法に対する厳密な耐性解析を行い、耐性を有することも証明されている。

この手法はワイエルシュトラス型楕円曲線といった他の方の楕円曲線や、Jacobian 座標といった他

の座標系に対しても適応できるが、残念ながらその場合は速度面での効果は無いとしている48。

4.1.3 テンペスト攻撃の状況

テンペスト攻撃は、処理を行う暗号モジュールおよび周辺機器からの電磁気的シグナルを、遠隔も

しくは外部からの測定により収集することで、キー入力情報、スクリーン上の情報、暗号鍵などの重

要セキュリティ情報を得る攻撃法である 51。もともとコンピュータや周辺機器が発する微弱な電磁波

が他の機器から検出できることは 1960 年代から知られていた。本格的に研究がされ始めたのは

1970 年代からで、NSA （米国家安全保障局）が漏洩電波について調査したプロジェクトがテンペ

ストと呼ばれていた。以後、テンペストは、漏洩電波をキャッチして情報を再現する技術の総称とな

っており、最近では Total Electronic and Mechanical Protection against Emission of Spurious

Transmissions （セキュリティに対して悪影響を与える、意図せざる電波の放射やそれが傍受されな

いための管理及びそのための電気的、機械的な総合対策を施した機器）や、 Transient

Electromagnetic Pulse Surveillance Technology （瞬間的電磁パルス監視技術）と定義する場合も

ある。

その後、NSA はテンペスト研究の結果、コンピュータ機器からの漏洩電波の量を規定するテンペス

ト規格を規定した。しかし、研究結果とテンペスト規格の内容を公開することは、国家安全保障に深

刻なダメージを与える可能性が大きいとして、未だ機密扱いにされており、規格を満たした機器も

輸出禁止対象品目になっている。

しかし、1999 年に John Young が情報公開法に基づいて NSA に対してテンペスト関連文書の公開

を迫った結果、2000 年に文書の部分公開が行われた。ただし、重要な部分（信号強度、最大デー

タ帯域幅、周波数など）は伏せられている。

こういったコンピュータシステムや周辺機器に対するテンペスト攻撃の公開文書が出てきた一方で、

暗号デバイスに対する特別な攻撃のシナリオは、ほとんど明らかにされていない。

しかし、"Soft Tempest: Hidden Data Transmission Using Electromagnetic Emanations" において、

Kuhu と Anderson は「このような攻撃は十分な時間と労力、そして資金が与えられて始めて実行す

62

ることが可能になるあろう」と示唆している。以下はテンペストを行う際に攻撃者が実行すると推測さ

れるものである。

・ターゲットデバイスが放出するシグナルを傍受し分離する

・そのシグナルが周期的なものなのか、暗号コードような予測可能なものかを識別する

・操作上の行為を割り出すためにシグナルにフィルターをかける

・操作上の行為からターゲットの機密事項をリバースエンジニアで知る

IBM ワトソン研究所の Agrawal、Archambeault、Rao、Rohatgi らは、IC カードや SSL Accelarator 上

の DES や RSA といったブロック暗号の実装に対して、効果的なテンペスト型の攻撃に進展があっ

たことを報告しているi。これらの攻撃の大部分は、実験環境における計算処理プロセスの制御能

力（例えば、1 ビット毎に異なる 2 つのデータ要素を DES によって暗号化することが可能）に依存す

る成功であった。しかし、資金があり確固たる決意を持った攻撃者によれば、このようなテンペストを

ベースとした攻撃が発展・高度化されて、実際に深刻な脅威を引き起こしえることが証明された。

4.1.4 テンペスト攻撃対策の研究・開発動向

テンペスト攻撃の対策としては、ネットワークケーブルを含む全ての構成物のシールドが必要とされ

ており、それにより電磁シグナルの放出を減少させ、防ぐことが出来るとされている 51。ルート認証

局など非常に重要な暗号操作が使われるシステムにおいては、以下のような従来のテンペストに

対する対策法が強く推薦されている。

・シグナルの強さの低減

攻撃のための材料となるようなシグナルの強度を落とすために、回路の再設計をしたり、シールド

を使う。

・シグナルから得られる情報の低減

統計分析による被害を減らすために、様々なランダム化手法や頻繁な鍵の更新といった方法をと

る。

4.1.5 耐タンパー技術の研究・開発動向

耐タンパー性とは、ソフトウェアまたはハードウェアのモジュール内部に存在する秘密情報の観測

や、モジュールが実現する機能の改変が困難な性質のことである。実装攻撃は破壊型攻撃法と非

破壊型攻撃法に分類されるが、上記に挙げてきた攻撃法は、いずれも非破壊型攻撃法にあたる。

破壊型攻撃法としては、故障利用解析やプローブ攻撃などがあり、これらはパッケージを破壊して

秘密データにアクセスするものであり、より物理的セキュリティの強固な耐タンパー性を持つ技術が

i “EM Side-Channel(s): Attacks and Assessment Methodologies”

63

求められている。ここでは、物理的耐タンパー技術の研究・開発動向として故障利用解析及びプロ

ーブ攻撃についてまとめ、米国の状況に触れる。

a. 故障利用解析とその技術対策

故障利用解析は、攻撃者が加熱や放射線照射などにより人為的に起こした故障を利用して解析を

行う手法で、これもまた FIPS 140-2 で触れられている攻撃の一つである。しかし、物理的セキュリテ

ィが十分でない場合に故障利用解析に対するリスクが大きくなるため、適切な物理的セキュリティ

の処置が必要、との記述に留まっており、具体的措置については触れられていない 51。一方、故障

利用解析を行う上での技術的課題と考えられるものには以下のようなものがある。

1) 故障発生の手段

放射線やレーザ照射といった故障発生手段には専用の設備が必要となる。

2) 不可逆障害の影響

Biham らの故障非差分攻撃では、暗号アルゴリズムの利用するメモリに不可逆的な障害を与えて

いるが、暗号アルゴリズムのコードが中間データの保持にワークメモリを利用している場合、他のア

プリケーションにも影響が及ぶ。

3) 故障の発生のタイミング

一過性の故障を適切なタイミングで、適切な時間(数秒)だけ発生させなければならない。耐タン

パー･デバイスへのクロックが内部で供給されている場合、困難が伴うと予想される。

4) 攻撃位置の特定

配線の多層化やアドレス・スクランブルなどが行われている耐タンパー･デバイスに対して、攻撃

すべき RAM や ROM の位置を的確に把握する技術が必要である。

5) 故障の発生方法

たとえばチップが多層である場合、破壊的な解析では上層を除去することで対応できるが、故障

利用解析では上層に障害を与えることなく目的の箇所を操作できる必要がある。

6) メモリの特性

ECC (Error Correcting Code) メモリが使われることは稀であるが、RAM や PROM や EEPROM

など書き込み可能なメモリについてはパリティ・チェック機能がある。

7) クロック/電圧/温度変動

現在の IC カードには、クロックや電圧や温度等の動作環境検知回路を搭載し、異常を検出した

際にカードを停止あるいは使用不能にする機能をもったものもある。

故障利用解析への対策としては、これらの技術的課題を活用することが考えられる。また、プロー

ブ解析への対策と同様のものが有効であるとされているが、永久故障の場合には対策にならない

場合もある 43。

64

b. プローブ攻撃とその技術対策

プローブ攻撃は、IC の内部バスに直接探針（プローブ）を当て、暗号処理の内部周期毎に目的

のレジスターのビット値を観測することで秘密情報を得る方法である。そのため攻撃者がチップへ

のプローブが可能な状況さえ一旦作り出してしまえば、解読は暗号方式を問わずほとんどのものに

対して可能となる 43。

このため、プローブ解析に対する耐タンパー技術としては、周波数検知回路、電圧検知回路、温

度検知回路など、外部から動作を観測することを妨げるような保護層の装備が進んでいる。さらに

は IC チップに低・高電圧センサー、低周波数センサー、コンタクト異常検出機能など、回路を取り

込むように金属層を設け、それに流れる電流や電圧をモニターし、異常を検出した時には機密デ

ータを破壊するような保護メカニズムを備えた各種セキュリティ回路の搭載をしているベンダーもあ

る。

また耐タンパーの新技術として、IC チップに Si コーティングを施すことでプローブ解析のような IC

チップへの物理的攻撃を防ぐ技術 (例えば物理的に無理なアクセスをするとチップ自体が破壊さ

れる) も開発されている。これは従来の製造工程を用いてコスト効率良く実現でき、リバースエンジ

ニアリングや、プロービング、化学的処理、電子顕微鏡、フォーカス・イオン・ビーム (FIB) などの

解析から IC チップを保護するものである 43。

c. 耐タンパー･ソフトウェア技術

耐タンパー･ソフトウェア技術としては、オブフスケーション変換（Obfuscation Transformation）が

ある（難読化技術は、概念的にも技術的にもオブフスケーション変換と非常に似ていることから、

オブフスケーション変換に含むものとする）。オブフスケーション変換は、解析者の不正な解析行為

が困難に成るように、プログラムの等価変換を行う。例えば、ループ構造のようにプログラムの記述

の中で頻繁に現れるような構造や、置き換え可能な命令群に着目して、プログラムを等価変換する。

これにより、プログラムが実現する機能の理解を困難にする。オブフスケーション変換は、一般的な

プログラム言語で記述されたプログラムに耐タンパー性を付加することができ、安価で利便性が高

い。またこれまでの耐タンパーソフトウェア技術では最も盛んに研究されてきているものである 45。

d. 米国の状況

現在のところ、耐タンパー性を要求する FIPS 140-1 Level4 Physical Protection requirements を満

たす認可製品の数は数えるほどしかなく、研究に関しての公開（unclassified) 情報は非常に限ら

れている。これは、この分野の研究の多くが民間企業の研究所で行われており、その内容が企業

秘密または知的所有権として扱われていることによる。

最近の製品開発には様々なスキームが用いられているが、以下のようなものが含まれる。

･シリコン製の薄幕フィルム物質から構成される耐タンパー性。これらの物質は半導体デバイスの

ハードおよびソフト論理領域に格納されている機密情報へのアクセスを防いだり抑止したりする。

65

主な目的は、暗号化、情報蓄積（メモリ）、マイクロ制御、高度な回路設計などに使われる集積回

路のセキュリティを向上することである。あるベンダーは次のような特性をもつ物質を製造したとして

いる。

通常の回路設計の検査時には不透明

半導体チップ表面コーティングの機械的磨耗や除去動作が、チップの損傷、機能停止と

揮発性メモリの損失を引き起こす

耐熱衝撃

頑強な粘着性と厚みでコーティングをはがすことは不可能

コーティングの硬さが他の活性区域への探査を防ぐ

耐温度

コーティングを除去しようとするとデバイスへの電力供給が止まる

家庭用化学品に対して不浸透性

チップをプラスティックパッケージから外す専門技術もコーティングを通さない

耐鉱酸、耐塩基

耐過湿度

半導体チップ表面コーティングの化学的磨耗や除去動作が、チップの損傷、機能停止と

揮発性メモリの損失を引き起こす

通常の拡大視では不透明

紫外線から可視電磁波の範囲内の既知の周波数に対して不浸透性

赤外線の範囲内の既知の周波数に対して不浸透性

X 線の範囲内の既知の周波数に対して不浸透性

･回路設計をリバース･エンジニアするのにより多くの努力が必要になるような特別の回路設計手

法。以下が含まれる。

顕微鏡を使って接続したり切断したりする隠されたトランジスタの使用

全ての CMOS トランジスタの対を機能的に同一に見えるようにして、機能の境界をなくす

それぞれのトランジスタを全ての可能な接続先へ接続し、何百何千という見せかけの接

続を作り出す

･境界のはっきりしたトップレベルの金属パターンでチップの暗号機能の物理的境界への侵入を

検知。

･タンパーへの反応として、SRAM への速い書き出し技術によって機密情報を迅速にゼロ化する。

･タンパーへの反応を起こす異常な環境条件を検知するオン・チップ・センサー。

4.1.6 耐タンパー性評価の状況

ここでは、上記で触れてこなかったソフトウェア技術の評価方法について述べる。耐タンパーソフト

ウェア技術の評価として、まず始めに上げられるのは、人間の評価者を用いた評価である。しかし、

66

プログラム言語を理解している評価者が多数必要であったり、評価者のレベルを的確に設定するこ

とが困難であったりするなどの問題があり、客観的な結果を得るためには多大なコストを払わなけ

ればならない。そこで、耐タンパー性の評価を行うためには、コストをかけずに十分にその耐タンパ

ー性を評価しうる計算機で行えるような手法が求められる。そのような評価の指標として、命令コー

ドの分布に着目したものや、コンパイラの解析木に着目したものが報告されている。しかし、これら

の評価指標と耐タンパー性との関係は必ずしも明確ではない。また、耐タンパーソフトウェアの評

価をより客観的にするためには、解析手法が的確にモデル化されて、その効果を定量的に見積も

れるような評価法を多く作り出すことで、評価結果を客観的にしていくことが必要とされる。しかし、

そのような評価法自体はまだ少ない状態である。

赤井健一郎、三澤学、松本勉らはこれに対し、ランタイムデータ探索型耐タンパー性評価法を提

案している。提案の評価法は、耐タンパー化プログラムの実行過程でメモリ上に現れたデータの中

から秘密データを見つけ出すことで、秘密データ守秘性の点からの評価を行うものである。具体的

には、耐タンパー化の対象となるプログラムとして暗号の復号方式を実装し、内部に秘密の復号鍵

を内蔵するものを想定する。そして秘密情報である復号鍵を隠蔽するように耐タンパー化したもの

を評価対象プログラムとする。このプログラムの実行過程を監視し、メモリ上に現れたデータの中か

ら復号鍵を探索する上で、もし鍵を短時間で見つけることが出来たならば、評価対象プログラムは

秘密データ守秘性の点で脆弱であると判断できる。また、これはすべての処理過程で人間の介在

がなく、計算機上で実現可能であるため、その評価結果は客観的なものになると考えられている。

実際にこの評価法を実現する実験システムを用いて、耐タンパー性を付与された評価対象プログ

ラムから秘密データを抽出する実験を行った結果では、評価対象プログラムから秘密データを極

短時間で見つけ出すことが証明されており、有効性も確認されている 45。

67

4.2 CMVP における対応状況と今後の対応

4.1 項では、サイドチャネル攻撃、テンペスト攻撃に代表される実装攻撃の研究動向について説明

してきた。本稿では、それら実装攻撃に対して現在 CMVP で行なわれている対応、および今後の

日本で CMVP のような暗号モジュール評価・運用制度を運営するにあたっての提言をまとめる。

○ 現在の CMVP の対応状況

FIPS140-2 に”Mitigation of Other Attacks”の項を新たに追加し、ベンダーに対し Power

Analysis (電力解析)、Timing Analysis (タイミング解析)、Fault Induction (故障利用)、

TEMPEST (テンペスト)といった特定の攻撃を緩和するセキュリティ機構を文書化するよう要

求している。

•

•

•

•

•

•

FIPS140 を技術的及び経済的な変化に対応させるべく、5 年ごとに見直し、要求の追加及び

見直しを行う。

○ 今後の日本での対応についての提言

新しい攻撃方法の監視や、標準に与える影響を評価する専門のグループを結成し、アンダ

ーグラウンドからの情報収集及び分析も検討すべきである。

NIST の動きに注目し、新しい攻撃に対するセキュリティ要件とテスト手順を開発するといった

迅速な対応をすべきである。

標準規格において特殊なセキュリティ要件を組み込むことは、テストにかかるコストの不必要

な増加と、そこを差別化領域とする民間企業活動のモチベーションの喪失につながるため、

むやみに行うべきでない。

ベンダーに対し、機密保持契約終結などの条件の下でテスト・プロトコルを開示するなどの

検討がなされるべきである。

以下で、それぞれの項目についての詳細を述べていく。

4.2.1 現在 CMVP で行われている対応

現在の CMVP は FIPS 140-2 への準拠を認定するプログラムであり、暗号モジュールに対する要件

は FIPS 140-2 に規定されている。FIPS 140-2 は FIPS 140-149の改版であり、2002 年 5 月 25 日以

降の製品に適応されることとなった。

前述の 4.1 項で論じた暗号実装技術および新たな攻撃に対する対策として、FIPS の改訂とそれに

関連して NIST が行なっている対応について説明する。

a. "Mitigation of Other Attacks"項の追加

FIPS 140-1 から FIPS 140-2 への変更点が NIST 発行の資料[50]で説明されているが、FIPS 140-2

では ”Mitigation of Other Attacks” (その他､攻撃軽減策) の項が新たに追加され、ベンダーに対

し特定の攻撃を緩和するセキュリティ機構を文書化するよう要求している。

FIPS 140-2 策定時、当時は検査不能なセキュリティ要求 (たとえば、Power Analysis、Timing

Analysis、Fault Induction) や、FIPS 140-2 標準の対象範囲外の攻撃 (たとえば、TEMPEST) を

68

将来的に受けるであろうと予想していた。FIPS 140-2 のこの項ではこれらに対してベンダーに次の

ような要求を行なっている51。

「(レベル 1、2、3、4 に対し) 暗号モジュールが一つ以上の特定の攻撃を緩和するように設計

されている場合、対象モジュールのセキュリティ･ポリシーはモジュールが攻撃を緩和するセキ

ュリティ機構を規定しなければならない。要求および関連する検査が開発された場合に、該当

のセキュリティ機構の存在とこれが適切に機能するかが検査されるであろう。」

また、その記述では策定当時に知られている新しい攻撃として以下の 4 つを紹介している。

Power Analysis (電力解析)

Timing Analysis (タイミング解析)

Fault Induction (故障利用)

TEMPEST (テンペスト)

しかし、FIPS 140-2 のこの項では FIPS 140-2 評価認証時の検査に含まれる項目として、これらの攻

撃を含めておらず、ベンダーに対してはこれらの攻撃に対するセキュリティ機構の文書化を要求す

るのみである。その理由は以下にある。

1） FIPS 140-2 が公布されたときに、これらの攻撃法に対して活用できる試験可能なセキュリティ

要件が無かった

2）テンペスト攻撃は、標準化の適用範囲外だと思われていた（テンペスト攻撃は 1960 年代から

コンピュータシステムに対する攻撃方法として知られていた）

b. 5 年毎の見直し

上記 a で説明したように FIPS 140-1 から FIPS 140-2 への改版により、その間に発見された新しい

攻撃とその対策に関する対応が盛り込まれた。また、1998 年の秋、FIPS 140 は技術的および経済

的な変化に対応すべく、5 年ごとにレビューし、要求の追加および見直しを行なうことが決まった

50。

上で説明した ” Mitigation of Other Attacks” は、FIPS 140-2 策定当時に検査方法の確立されて

いないセキュリティ攻撃および今後発見される新しい攻撃に対する規定を定めたものであるが、

FIPS 140-2 評価認証時の検査には含まれていない。セキュリティ業界で広く認められた保護策お

よび検査方法が開発された場合、NIST および CSE はこれらを FIPS 140 に統合する、つまり、FIPS

140 標準の将来の版か、あるいは、FIPS 140-2 実装ガイダンスの改版に反映する、と思われる52。

さらに、NIST では、FIPS 140 標準およびテスト仕様である DTR (Derived Test Requirements)53 を

定期的に見直すと同時に、Validation Report を再評価し認証機関が経験を積んでいく、というよう

に、CMVP を常に改善していくダイナミックなプログラムと捉えている54。

また、FIPS 標準策定以降に発見された脆弱性に対応するためにガイドラインを作成しており、評価

機関が評価を行なう際はこのガイドラインを利用する。次の FIPS 140 の改訂の際にはこのガイドラ

インも統合され、脆弱性に対するガイドラインとして認証時に利用されることになる。

69

4.2.2 CMVP の今後の対応

ここでは、4.2.1 項で述べた米国での現状を踏まえ、日本で CMVP 相当の暗号モジュール評価認

証制度を運用する上での提言について述べる。

a. 「その他､攻撃軽減策」のセキュリティ要件とテストについて

今後日本で CMVP に準ずる暗号モジュール評価認証制度の導入を検討する上で、NIST の動き

に注目し、新しい攻撃に対するセキュリティ要件とテスト手順の開発といった迅速な対応を考慮す

べきである。もし暗号モジュールが前述の攻撃の一つまたは複数への対策を備えるように設計され

ていれば、セキュリティ･ポリシーはその暗号モジュールが使用する、攻撃を軽減するためのセキュ

リティ機構の仕様を明記すべきである。これらの適切なセキュリティ機能が正しく機能しているかどう

かは、セキュリティ要求とテスト手順が開発された後に実証されるであろう。NIST は NSA (National

Security Agency) と協力して、これらの攻撃に対するテスト手順を開発中であり、それが終了すれ

ば、そのセキュリティ要件と Derived Test Requirement を開発すると思われる。NIST は出来るだけ

早くセキュリティ要件とテスト手順を開発することが望まれており、日本はその動向に注意を払うべ

きである。

しかし、今後も「その他､攻撃軽減策」に関するセキュリティ要件を必須項目とはしないことが望まし

い。標準規格に特殊なセキュリティ要件を組み込むことは、全体としてテストにかかるコストの不必

要な増加につながる。たとえば、暗号モジュールの脆弱性が不正に利用されることが懸念されてい

るスマートカードと他の製品を例にとる。スマートカードは、盗まれやすく、また一般に広く普及して

いるため、悪意を持てば誰もがセキュリティ機構やデバイスコントロールを破ろうと試みることが可能

な環境下にある。これは、許可された人のみにアクセスが与えられ、物理的な攻撃から保護された

環境にある他の多くのセキュリティ･デバイスには見受けられないことである。

これに対し、スマートカードの国際的なセキュリティ標準策定の一環として、Smart Card Security

User's Group が 2001 年後半にスマートカード向けの Protection Profile (PP) を定義している。この

PP の開発には、American Express、Europay、JCB、MasterCard、Mondex、VISA、そして NIST と

NSAが携わっていた。この PPには、スマートカードに対して想定される特殊な脅威や、それに対応

するセキュリティ要件が記述されているが、FIPS140-2 の「その他､攻撃軽減策」に関連すると思わ

れるものも含まれている。例えば、ＩＣチップを物理的に探査、変更したり、電気的に操作を行うなど

して変更されたスマートカードが攻撃者に再利用される脅威が想定されており、それに対してタン

パーされたことが検証できることを対策と定義している。

だが、これらのスマートカードのセキュリティ要件は、スマートカード以外の暗号製品、例えば中央

の認証局のような通常物理的に安全な環境に置かれるタイプの製品に対しては、必ずしも必要とさ

70

れない。一方で、FIPS 140-2 の標準規格は、規格を取得した暗号モジュールが如何なる製品に組

み込まれても均一な安全性を保証するために、セキュリティ要件にはその暗号モジュールが適用さ

れる全ての製品に影響する制御とパラメータを含むことを要求している。FIPS の「その他､攻撃軽減

策」にスマートカードの特殊なセキュリティ要件を追加して FIPS の必須事項にするとすれば、その

他の製品にとっては満たさなければならない要件が増える結果、不必要にコストを増加することに

なるであろう。

NIST はこれまでのところこの点で妥協案を採用している。つまり、自社の製品がその他の脅威に対

して対策をもつ必要があると信じるベンダーはセキュリティ要求を追加することができるし、そのよう

な脅威が全くない市場を意図した製品はそうしないことができる。前述のように、今後は出来るだけ

早く、Power Analysis、Timing Analysis、Fault induction、テンペスト攻撃に対するテスト可能なセ

キュリティ要件を定義することが望まれる。しかし、それらのセキュリティ要件及び規格適合テストは

オプションとすべきである。日本でも、この点は考慮する必要がある。

b. 新しい攻撃方法の情報収集について

CMVP のような暗号モジュール認証評価制度を導入・運営するにあたっては、新しい攻撃方法の

監視や、標準に与える影響を評価する専門のグループを結成し、アンダーグラウンドからの情報収

集及び分析も検討すべきである。NIST には新しい攻撃方法を監視したり、攻撃がどれほど FIPS

140 標準に影響を与えるかを評価するような組織だったグループはない。もしテスト方法やセキュリ

ティ要件における深刻な脆弱性を明らかにするような危機的イベントが起これば、NIST はガイドラ

インを発行するが、標準をアップデートすることはしていない。標準をアップデートする場合は、パ

ブリックコメントからのインプットを検討している。一方、本調査のためにインタビューを受けたセキュ

リティ専門家たちは、新しい攻撃方法が様々な形で発見されることに言及しており、特に以下が主

な情報源になるとしている。

1）オープンな学術研究による発見。California Berkeley 大学の Doug Tygar、Carnegie Mellon 大

学、Stanford 大学の Dan Boneh、そして Cambridge 大学の Ross Anderson と Marcus Kuhn ら

による "Systematic Attack Analysis" としての学術的分析が進んでおり、これらのサイトではア

ルゴリズム、故障利用解析、耐タンパー・ハードウェアの具体的研究が行われている。

2）民間研究所による商業的発見。Paul Kocher 率いる Cryptography Research （DPA 攻撃を特

定し、DPA の耐性試験システムを開発している企業）のような民間研究所は、認証機関とごく

限られた商用セキュリティ製品ベンダー、そして政府（NSA と NIST）にのみ研究結果を販売

している。

3） NIST、NSA、Department of Defense も含めた政府機関による発見。

71

4）犯罪活動による発見。Cambridge 大学の Ross Anderson は "ハッカー" と攻撃方法について

議論したものをまとめており、彼らの中には顧客であるロシアのマフィアから攻撃に役立つ 10

万ドルもの電子顕微鏡の提供を受け、引き換えに様々な攻撃情報をマフィアに渡している者

もいることが記されている。また、"犠牲者" は攻撃の事実の後に使用された方法を推論しな

ければならないが、時として、その方法はハッカーによってインターネット上に提示されることも

あるため、インターネットを継続的に監視することも必要だとしている。

NIST は、当然これらのうち 1)、2)、3) を活用しているものと考えられるが、それらはもちろんのこと、

新しい攻撃方法を監視したり、攻撃がどれほど規定された標準に影響を与えるかを評価するような

専門のグループを結成し、攻撃監視手段として 4) のようなアンダーグラウンドからの情報収集およ

び分析を行うことも検討すべきである。日本においても同様で、他国政府やアンダーグラウンドも含

めた幅広い情報源から新しい攻撃方法についての情報収集を組織的に行なう体制を検討すべき

である。

c. 情報公開とベンダーの動機付けについて

標準規格に特殊なセキュリティ要件を組み込むことは、それを製品の差別化にしている民間企業

活動のモチベーションの喪失にもつながるため、むやみに行うべきではない。CMVP 評価認証機

関の一つである InfoGard Laboratories のディレクター Tom Caddy は、近年、ベンダーが評価機

関に DPA やテンペスト、その他のサイドチャネル攻撃に対する耐性テストを依頼しなくなってきてお

り、その原因にはベンダーの競争的差別化に関わる問題があると指摘している。「その他、攻撃方

法」に対するセキュリティ対策はベンダーにとって同業他社の製品と自分たちの製品とを差別化す

ることの出来る領域である。このため、その情報公開は製品購入予定のシステムベンダーに対して

のみ機密保持契約の下で直接情報を提供するものとなっている。このように、暗号製品ベンダーは

このような情報を FIPS 140 の要件として公的なセキュリティ･ポリシーとともに提供し公開する事を望

んでおらず、現在の FIPS 140-2 でもこの情報の開示を要求していない。暗号製品ベンダーは今後

もノウハウにあたる情報を独自に管理し一般には公開しない道を選んでいくと思われる。CMVP の

ような評価認証制度を日本で運用していくにあたっても、健全な市場原理を維持・推進する立場と

して、このように民間企業活動のモチベーションを失わないようにするという配慮から、むやみに情

報公開するべきではない。

また暗号製品ベンダーに対し、機密保持契約終結などの条件下で、テスト・プロトコルを開示する

などの検討がなされるべきである。深刻なセキュリティ･インシデントが起こった場合に、NIST はそ

の問題への対処として FIPS のための特別なテスト方法を修正しているとされるが、テスト手順は公

開されたり開発者に提供されることはなく、そのテスト･プロトコルは認証機関でのみ使用できるよう

になっている。このため、前もってテスト･プロトコルを知らないベンダーの設計者は、特殊なテスト・

72

プロトコルに対応した設計を行なうことができず、テスト後にテスト･プロトコルに合わせた設計をやり

直す場合が発生している。このような理由によって、ベンダーからはテスト･プロトコルなどの情報公

開が求められているが、その一方、全ての情報を公開した場合にハッカーなどに攻撃の手がかりを

与えるなどセキュリティ上の問題も考えられる。このため、日本における評価認証制度の運営にお

いても、条件を整えた上でテスト・プロトコルを開示するするなど、検討を行なうべきである。

73

5. まとめ

本報告書では大きく 3 つの調査項目について調査分析を行なった結果を報告している。2 項では

CC と CMVP の運用について、3 項では政府システムにおける複数暗号アルゴリズム実装方式につ

いて、4 項では米国における暗号実装技術の最新動向と CMVP における対応について、それぞれ

報告している。

2 項および 4 項の調査結果は、日本における暗号モジュールの評価に対する参考情報が提供でき、

また 3 項においては日本の電子政府実現に向けたガイドラインに有用な情報が提供できたと思わ

れる。

74

添付資料添付資料 A. インタビュー質問票添付資料 B. 調査項目 1 のインタビューメモ添付資料 C. 調査項目 2 のインタビューメモ添付資料 D. 調査項目 3 のインタビューメモ添付資料 E. 調査項目 1 分析結果 (原文) 添付資料 F. 調査項目 2 の分析結果 (原文) 添付資料 G. 調査項目 3 の分析結果 (原文) 添付資料 H. 米国 CC および CMVP 評価機関一覧添付資料 I. 用語添付資料 J. 参考文献、参考資料

75

添付資料 A-1. 調査項目 1 の NIST および Lab 向けインタビュー質問票

Questions for NIST and Laboratories

Relative Merits of Certification Programs and approaches

Parallel operation environment of CC and CMVP for cryptography technologies

Current operation information

Procedure flow of evaluation and certification

Schedule and length of time

Cost

Number of required personnel and skill level for evaluation

Required materials (documents, sample, etc.) and format

Choice of the evaluation program {CMVP, CC} to suit requirement

Reuse of or reference to the results of {CMVP, CC}

Comments on the parallel operation of CC and CMVP

Advantages

Issues and constraints

Solutions for problem

Relevance to CMVP

Current status of CMVP for the cryptographic implementation technologies

Future requirement for CMVP

1. What is the process that a vendor must go through to get a crypto module certified? (What

are the key steps in the process?) What are some key differences in the process between a

FIPS 140 certification and CC certification? Does you lab do both?

2. How does the vendor supply the module? Hardware, software, compiled code, source?

What are key differences between the certification of a hardware product with a crypto

module and a software product? What are key differences between CC and CMVP in terms

of what they test and what must be supplied?

3. What does the client provide in terms of resources and materials, samples, and what format

are these provided in? Differences between CC and CVMP?

76

4. What in the typical length of time for the certification process? What factors influence the

time of the certification process? How does this differ between CC and CVMP time for

certification?

5. What factors influence the cost of the certification? What is an example of a typical cost

of a module? Is there a significant difference in the cost of certification between CC and

CVMP? How does cost differ between CC and CVMP certification?

6. The IPA is considering setting up or certifying labs to do this in Japan. What are the skills

required? Types of personnel? Numbers of personnel? How does the affect what you can

do? How does this differ if you do both types of certification?

7. What are the relative differences you see in the certification of crypt products/modules

under CC and CVMP to FIPS 140.2? What are some key differences? What do you

think is better for a supplier of a crypto product?

8. Can you reuse test data from FIPS 140 in a CC certification?

What does the manufacturer gain from dual certification?

What impact does implementation have on testing?

What impact will different types of threats and the methods used to counter threats (such

as threats against hardware) have on the testing and certification process?

For NIST and CSE and CC organizations

77

添付資料 A-2. 調査項目 1 の開発ベンダー向けのインタビュー質問票

Questions for Vendors with Certified Products

1. What product did you have certified? Did you certify the entire product or just the

cryptographic module?

2. Was the product certified to CC , FIPS 140 or both?

3. What was the process you had to go through to get the product certified?

a. Application?

b. Call to laboratory?

c. Preparation for testing and certification?

4. What did you have to supply to the certifying agent (lab or government?)? What documents,

what format for the modules/ products?

5. How did you supply it? (software as compiled code? Or source code?, hardware as

prototype or beta version of the product?) If hardware, what sorts of testing did they do for

resistance to tampering?

6. Do you know what sorts of attack scenarios they used?

7. How long did the process take? What were some of the causes of delay?

8. How much did the process cost? Do you think there is a difference between the

laboratories in cost of time effectiveness?

9. If you had a product certified in both standards, what were the differences in the process?

a. What was tested? Extent of testing?

b. What was certified? How was that different from the other standard?

c. Module versus product in system? Standalone or in combination with other

products/software?

d. How was the time different? Did one take longer than the other? Do you know

why?

e. How much different was the cost? Did certifying to one standard cost more than

78

the other standard?.

f. Were any of the test results from one certification process usable in the other

certification process?

10. Why did you choose one standard over the other for certifying this product? Or why did

you choose FIPS 140 versus CC certification? Cost, time, target market?

11. What is your opinion of the certification process? Do you think it improves the product?

How would you compare the CC versus CMVP process and the goals of each certification?

12. Do you think there are vulnerabilities in the CMVP approach or CC approach to

certification? For example, do you know about any trends in attack methods that would

affect the process and testing procedures for the CC or CMVP? Are there future

requirement for CMVP? Additional approaches to testing and certification that should be

explored?

13. Do you have any other issues with these certification processes that you feel are important

for the IPA to know?

79

添付資料 A-3. 調査項目 2 用 (システム開発者向け) インタビュー質問票

Interview guide for System developers

1. Does your system use multiple encryption algorithms in its design? For example: does it

have two instances of a symmetric key or asymmetric key algorithm, or does it have

multiple crypto methods from which the user/client can select? Other selection examples

are below:

a. A back up cryptographic algorithm in case for the main cryptographic

algorithm being broken

b. A system having sub applications, each of which has a different single

crypto algorithm, switching the algorithms

c. Uses an encryption accelerator card and a smart card

d. Uses the same algorithm supplied by two different vendors in the same

system

e. Do they have any examples of systems or incidents in which a

multi-cryptographic-algorithm-implemented system was broken?

2. If so, what was the risk management approach used during the system development

process?

o What was the purpose of using multiple algorithms and how does that

affect the risk to the system?

o Does it increase or reduce the scale of the threat? How?

o Does it increase or reduce the probability of a compromise? How?

o How does using multiple-algorithms affect the operational response to a

threat when it occurs?

o

3. If you participated in designing such systems, how did you go about selecting the products?

What were the decision criteria for the products?

4. How did using multiple algorithms affect the system cost? Software costs?

Programming costs? Implementation costs? Testing costs?

5. Can you describe in broad terms the system that you may have participated in designing?

(We need to describe the following)

i. System overview of its function

ii. System block diagram: major storage and IO

iii. Data processing flow

80

iv. Cryptography function

1. Application of cryptography

2. Cryptographic product name and key length

3. CC/FIPS 140-2 certification information

4. Key management procedure

v. System users

vi. Types and values of data

vii. Vulnerability factors

a. Can you broadly describe the processing flow of this a system highlighting where

the encryption was used? What was the purpose of this system (information

exchange, secure access, monetary transactions)? What type of data was

involved? Numeric, alpha numeric, text? What was the value of the data?

Who were the users (other governments, businesses, the public)

b. Where were the main points of vulnerability you were addressing with the crypto

techniques chosen? What were the specific threats? What products were used?

What key length was used? Were these products certified? Was the level of

certification a factor in choosing the product? Was certification required?

c. Were there vulnerabilities that remained?

6. During system implementation, were there vulnerabilities to using multiple algorithms?

How was this managed?

7. How does using multiple algorithms affect the operation of such a system?

a. On the costs?

b. On the users of the system? Do they have higher costs or increased complexity?

Do you have a higher cost of technical support for users?

c. What is the impact on key management of the added complexity of such a system?

d. How does it affect incident response? What additional costs or problems occur

when there is an incident in such a system?

e. What effects on vulnerability of system operation can using multiple algorithms

have? Increased complexity? Increased cost? More technical support? More

81

添付資料 A-4. 調査項目 3 用のインタビュー質問票

Trend of Cryptogeraphic Implementation Technology

Trend of cryptographic implementation technology

Side-channel attacks/Tempest attacks

Current status

Trend of research and development for counter measures

Tamper resistant technology

Trend of research and development

Current status of evaluation tamper resistant

Other important technological direction

Relevance to CMVP

Current status of CMVP for the cryptographic implementation technologies

Future requirement for CMVP

82

添付資料 B-1. ActivCard インタビューメモ

Interview Notes – ActivCard

Eric Le Saint, product manager

ActivCard develops applet suites for smart cards used in a variety of applications. The largest

implementation using the company’s products is the Common Access Card solution for the

Department of Defense. Over 4.7 million members of the U.S> military have these cards for access

to secure computing systems and networks. EDS implemented the system using the product from

ActivCard.

ActivCard has one hardware product certified to Level 3 for Physical Security and Level 3 for

software security to the FIPS-140-1 standard. They received this certification in September 2002.

The physical card that ActivCard uses is provided by Schlumberger; it is the SchlumbergerSema

Cyberflex Access.

The FIPS certification was performed by InfoGard Laboratories in San Luis Obispo, California.

The process required about two months to complete.

The certified for FIPS 140-1 because it was required to sell this product to any unit of the U.S.

government. They also see many commercial customers in the U.S> beginning to rely and require

FIPS 140 certified products.

They are starting the process of getting CC certification for the same product. They have little

experience with this standard that would allow them to compare the processes. FIPS is relatively

straightforward and all the documents and testing is fully described in the standard document

available from the NIST. They are proceeding with CC certification because they have markets in

the EU that they would like to sell in and they can’t sell if they don’t have the CC certification.

They believe that some larger customers in the U.S. will also require or prefer CC certified products.

Their decision to apply for CC certification was a business decision driven by the market and

nothing else.

The cost of the CC certification is one order of magnitude more than FIPS certification; so at least 10

times the cost for FIPS (at this point they do not have a final cost for CC certification, nor do they

have any sense of the length of time it will take). The documentation effort required for FIPS is

83

really no more than the standard documentation that an engineer would have for any commercial

product designed with best practices in documenting engineering procedures and processes. The

CC documentation effort is huge. They are just starting. It requires documentation that goes far

beyond the engineering documentation and security policy that are required for FIPS. Thus, it is

also more expensive.

Mr. Le Saint referred us to InfoGard for more details on the process.

84

添付資料 B-2. Chrysalis-ITS インタビューメモ

Chrysalis-ITS

Bill Cullen,

Product Line Manager

January 15, 2003

1. What product did you have certified? Did you certify the entire product or just individual

cryptographic module(s)?

2. Was the product certified to CC, FIPS 140 or both?

Both—

CC

• much more detailed,

• design documentation, process oriented (ala ISO 9000 certification), change control

• source provided

• 30xcost – needed to bring in contractors to help

• not sure who did certification

• more stringent (e.g. PEDii)

• looks at non-standard algorithms (e.g. Japanese proprietary) that are included

FIPS 140-1

• Oriented towards meeting test criteria – checklist

• No source


a. Application?




ii PED は Pin Entry Device のこと。

85


See #2


prototype or beta version of the product?) If hardware, what sorts of testing did they do

for resistance to tampering?

Lab came onsite


Yes for FIPS. Only at a high-level for CC—lower levels are not so well defined


FIPS—a couple of months (without queue delays)

CC—a couple of years (1st for Chrysalis/1st CC)—a good year now (ANOTHER COMPANY or

product)—recert 3 to 6 months (depending on deltas)




d. What was tested? Extent of testing?

e. What was certified? How was that different from the other standard?

f. Module versus product in system? Standalone or in combination with other

products/software?

g. How was the time different? Did one take longer than the other? Do you know

why?

h. How much different was the cost? Did certifying to one standard cost more than


i. Were any of the test results from one certification process usable in the other




86







explored?



FIPS or CC is a foundation not pinnacle of decision—should include best practices (e.g. n of m

authentication, disconnect able PED, etc.)

87

添付資料 B-3. Spyrus, Inc. インタビューメモ

Spyrus, Inc.

Tom Dickens



Rosetta Smart Card

Had both the cryptographic module and the whole product tested. Depends on what’s being

required for what level of certification and the product

15. Was the product certified to CC , FIPS 140 or both?

Certified to FIPS 140

Now going through CC process


a. Application?



Get clarification from Ruth on what this means.

Can probably get this info from the FIPS-140 security policy



He said they provided whatever was specified in the FIPS 140-1 security policy.


prototype or beta version of the product?) If hardware, what sorts of testing did they do for

resistance to tampering?

88

Hardware at beta stage; tamper resistant testing is required in FIPS 140-2; have to show that

your product is tamper resistant

Also had firmware-specific testing: if firmware is changed you have to have it re-certified. This

is the case under CC or FIPS


No. It should be in the FIPS 140 security policy


2-4 months

In the beginning it takes a year

For add on certifications to already certified products it takes about 6 weeks

Documentation is the biggest cause for delay

Also important is the availability of trained personnel at the labs: there is generally a back log



FIPS cost was $75,000-$150,000

CC - ?


Have not gone through the CC process yet on the Rosetta family of products. In generatl, CC

takes longer because more documentation is required but otherwise he thought there were no

major differences between CC and FIPS from a cryptographic content point of view.

a. What was tested? Extent of testing?

b. What was certified? How was that different from the other standard?

89

c. Module versus product in system? Standalone or in combination with other

products/software?

d. How was the time different? Did one take longer than the other? Do you know

why?

e. How much different was the cost? Did certifying to one standard cost more than

the other standard?

f. Were any of the test results from one certification process usable in the other


Have not certified in both yet.

In the past it was easier to go from FIPS to CC than the reverse. This may mean that FIPS was

harder and required more which helped get through CC faster.



Possibly because they do US government work and this is required (KY speculation, not his

answer)



Ask this.





explored?

Ask this

90



Ask this

Other comments:

They feel they have a domain expertise in certification, so at a certain point he didn’t want to

answer any more questions “for free”.

If you are doing anything in the government sphere, it has to be certified to FIPS-140

Believes that FIPS 140 will be integrated into CC in 2-3 years. Most organizations outside US

are very ethno-centric and they are not likely to want to certified to a “US standard”.

Spyrus has the only smart token certified at FIPS level 3

They have done about 15-20 FIPS certifications

I think they also did IT Sec certifications, which was the procedure prior to CC

91

添付資料 B-4. Hasler, Inc. インタビューメモ

HASLER, INC. Shelton, CT

Mr. George Brookner (don’t know title; was referred to us by Richard Rosen, contact listed on

the sheet)



Product called Safe CV, both hardware and software. Only certified the cryptographic module

to FIPS; whole unit is certified to a USPS standard

2. Was the product certified to CC, FIPS 140 or both?

FIPS only, not CC. CC requires they certify to CC standard and to a second set of criteria that

varies by country. His company said that was too expensive (US government has not actively

taken up the issue, but the rest of his industry is also boycotting CC certification)


a. Application?



Follow FIPS 140 procedures

Send to the lab and to USPS for review

Correct the problems identified by the certifying lab

There is an audit company which also reviews their manufacturing procedures



They supplied the security device and testing equipment. The testing equipment is quite

unique to their product so it is not likely that the lab would have it.


92

prototype or beta version of the product?) If hardware, what sorts of testing did they do

for resistance to tampering?

Hardware is supplied as a full fledged product (not beta version). Their competitor, Pitney

Bowes, also does this.

Software – ask


Hardware has to be put through numerous physical attack tests including drilling, chemicals,

electronics, vibration, and rapid temperature change


Used to take a lot longer because labs did not have enough sufficiently trained people to do the

evaluation. They also didn’t know how to test to FIPS. They still have to work very closely

with vendors on sophisticated products that come from Intel and IBM.



Approximately $50,000, if you get through the first time.


d. What was tested? Extent of testing?

e. What was certified? How was that different from the other standard?

f. Module versus product in system? Standalone or in combination with other

products/software?

g. How was the time different? Did one take longer than the other? Do you know

why?

h. How much different was the cost? Did certifying to one standard cost more than


i. Were any of the test results from one certification process usable in the other


93





Devices are absolutely more secure

Vendors are becoming more security conscious

Not sure how the customer (other than a government customer) benefits





explored?



94

添付資料 C-1. USPS インタビューメモ

USPS Interview Notes

Roy Gordon, Security Technology

USPS Information-Based Indicia Program

USPS has a variety of methods/channels for delivering “postage”. Postal Security Devices (meters

manufactured by companies like Pitney Bowes and Hasler); and “virtual PSD’s” which are

server-based systems that created registered value delivered via PC clients (licensed vendors are

Stamps.com, Pitney-Bowes ClickStamp and possibly a few others). The latter permit the user to

print stamps that can be affixed to envelopes, pay for and print airbills for express mail services,

postage and shipping labels for packages, receive electronic delivery confirmation, etc.

All certificate holders must be approved by the USPS. They apply for a license to create postage

value (i.e. use a postage meter). The vendors of the PSDs provide the information, USPS approves

the user. Certificates used to be centralized, but are now issued by the vendors as Infrastructure

Providers. Application process also sets up the payment method (credit card, bank account sweep)

Individuals and companies with PSDs from vendors connect to a vendor infrastructure for adding

postage value to the PSD devices. PSD’s sign each mailpiece with a digital signature.

When USPS was developing the business case for Internet delivery of stamps and on-line

infrastructure for the PSDs, they looked at security issues. Realized that NIST was developing

CMVP and FIPS 140 standard, so they decided to use FIPS 140 as the standard they would use for

encryption and digital signatures.

There are three algorithms mentioned. What is implemented?

Vendors implement what they wish that fits their requirements for the type of product they have

developed. RSA is implemented by Hasler and PB. Also will allow other methods that are

proprietary, but they must pass a rigorous testing much like FIPS and pay for the USPS costs to

implement on their systems that verify the digital signatures.

Why did USPS allow such flexibility in the signature algorithms?

Footprint becomes an issue on an envelope, more critical than airbill, more critical than package.

Size of the encoding method (bar code, data matrix, see examples from on-line) will determine the

95

availability of space for the signature. Type of product also determines the information that is

encoded in the barcode (for sheets of stamps, there will be sender information (or the purchaser), but

no recipient information. For most letter metered mail, there is also no recipient information. For

airbills and packages, there is recipient information encoded.

Realize that they have many different products and different schemes for the mail and issuing value

to customers.

Risk is different on envelope .37 vs airbill for $13.00. USPS uses sampling methods against

envelope traffic to estimate the volume of expenditure for providers and compares this with the

purchase patterns to ensure that they are not getting hit with fraud. (such as copies of stamps)

Individual may choose to have signature on mail, if signature on piece and production standpoint, if

automated scanning, networked automation platform for verification and is it networked centrally

with address information,

Infrastructure exists for address verification (they look up the address and print the 9 digit barcode

onto mail pieces the first time they go through a sorting system, then they can be sorted into delivery

order at the destination post office), Same infrastructure at USPS could be used for centralized

verification of signature, however, but speed and risk is factor.

Packages are processes at a slower speed. Certificates are pushed out when read locally. Packages

are higher value, so they are more likely to try to verify the certificate. On .37 mail pieces they use

a statistical approach and verify a few.

Applications in this environment:

Metering, refill data, for $ value, This data is exchanged and protected by crypto. Authentication

and encrypting data.

Can be between end user (thin client and crypto on server

Crypto functions on device attached to computer, monetary amounts downloaded to

device, Hasler PSD device. Other postage data on it. Application specific

sensitive parameters.

Process of exchanging data for registers (postage value)

The meter to infrastructure, are (replay attacks) $100,--- to register

96

Information from vendor infrastructure:

For PSDs they get summary information dumped from the vendor to the USPS. They can

verify the account information for each PSD holder and compare with the usage they

see in scanning the thruput of mail.

Transaction records are available and are dumped where they have thin client/server model.

Stamps.com, PSI these transaction records. This crypto occurs on the server.

Detailed transaction records of mail stream vs created.

On PSD, have methods to look at frequency of device velocity check. VS amount on

meter.

Other communication paths in this architecture (from vendor to USPS central systems, from

banks to USPS, from vendor to banks) General handshaking, peer to peer authentication.

Cookie cutter stuff. Types of information that are exchanged, registration & licensing

early in the business process and register with USPS (this database of authorized users ),

DB of money set to account or devices (collected from vendors); used to have own CA

now using different models (vendor); vendor collects data on USPS behalf

(actually payment is going directly to USPS) Credit card payment to USPS via download.

Pitney –Bowes also offers line of credit. If ACH debit, lockbox account, appears to be

PB but actual money transacted on PC postage is with USPS.

Security, besides using the FIPS standard for the crypto and the hardware security. USPS

had to Define other sensitive values such as value balances, and other information in

registers and determine the risk and then define how each needed to be handled,

zeroization, etc. if the device was tampered with. FIPS of course only deals with the

keys.

FEP

Path that vendor chooses in terms of its choice of algorithms or approach to selling postage

value can be linked to other vendor IP. Whatever can be done with postage, a patent

has been applied for. Method they choose to sign something may be driven by other

things that vendor has in IP.

97

PDF 417

MetStamps print adhesive stamps with data matrix bar code (see Stamps.com and

ClickStamps)

Why did USPS produce this requirements document. Open source gives opportunity for

people to review.

Have periodic symposiums, crypto and other topics in the postal world for vendors and

other interested parties

$21 billion moved this way by USPS. They have total revenues >$60 billion

Incident response plan with each vendor. Joint plan for USPS and vendor should

something happen that compromises the system (data failure, security breach, etc.)

98

添付資料 C-2. USPS 事例調査

USPS System Description

The United States Postal Service (USPS) has a variety of methods/channels for delivering “postage”.

Postal Security Devices (PSDs) (closed system meters manufactured by companies like Pitney

Bowes and Hasler); and “virtual PSD’s” which are server-based systems that create registered

postage value delivered via PC clients (licensed vendors are Stamps.com, Pitney-Bowes

ClickStamp and possibly a few others). The latter, or Open Systems, permit the end-user client

of the provider to purchase postage value and print electronically readable “stamps” that can be

affixed to envelopes, pay for and print airbills for express mail services, postage and shipping labels

for packages, receive electronic delivery confirmation, and similar services.

Figure 1: Examples of Digitally Signed Indicia for Packages and Envelopes

The overall architecture of the system supports different implementations by providers and customer

of the functions of the Information Based Indicia System. The functions and interactions are shown

in Figure 2. The customer authorization process is performed by the USPS. The customer

initialization process is actually performed by the providers after receiving authorization from the

USPS for each individual PSD device licensee. Postage payments are sent from the customer to the

USPS via the USPS cash management processors. Only information flows between the provider

and the customers and between the providers and the USPS. The postage payment processes and

the PSD postage value download process is performed by authenticated methods between the

99

customer, provider and the USPS.

Digitally signed objects (large and small envelopes and packages) enter the mail stream and the

digital stamps are verified by the USPS mail handling and sorting equipment. Some objects are

verified in real time, other indicia are examined and verified on a sampling basis after sorting. The

mail handling equipment links to servers that verify address information as well as verify the digital

signatures. The mail handling system must be able to verify digital signatures using different

algorithms-RSA, DSA, and ECDSA.

All certificate holders-individual companies with closed system meters and open-system vendors

like Stamps.com-must be approved and licensed by the USPS. A payment method is established for

both closed system users and open system providers by either credit cards or ACH processes with the

payer’s bank. Once the USPS approves a user, the vendors of the PSDs initialize a PSD and

provide the device to the user. Individuals and companies with PSDs from vendors communicate

across the vendor infrastructure to add postage value to the PSD devices. PSD’s generates a

digitally signed indicia or (bar code) for each mail piece.

100

In the original architecture, the certificate authority was maintained by the USPS, now each vendor

maintains a certificate authority that supports its Provider Infrastructure. Initially the keys were

also maintained centrally, but to facilitate rapid signature verification, the keys are distributed across

the postal system networks.

The PSD holds the cryptographic elements of the system that create the indicium for each mail piece

and digitally sign it. When USPS was developing the business case for Internet delivery of stamps

and on-line infrastructure for the PSDs, they investigated multiple methods of assuring security.

The designers recognized that NIST was developing the CMVP and FIPS 140 standard, so they

decided to use FIPS 140 as the standard they would require for encryption and digital signatures and

have CMVP verify all implementations in vendor devices.

The core security functions of the PSD are initialization, cryptographic digital signature generation

and verification, and the management of registers that maintain the total value remaining for

indicium creation and total postage value of created. The PSD is a physically secure device that

incorporates a random number generator, storage registers, a date/time clock and other circuits.

Figure 2 below shows the elements inside the crypto boundary of the Ascom Hasler SAFE CV411

from the FIPS 140-1 Security Policy.

Source: Ascom Hasler Mailing Systems, Inc.

101

The PSD digital signature function uses the signing key generated by the Providers Certificate

Authority (upon approval by USPS). The certificates all use public key cryptographic algorithms

for the digital signature function. The USPS has approved RSA, DSA, and ECDSA as algorithms

from which Providers may choose depending upon their preferences. Key length for each is

defined. Providers may also propose their own proprietary cryptographic algorithms, but only after

they are validated by an outside testing laboratory, approved by the USPS and the Provider pays for

the implementation in the USPS systems. As a result, the system has used only RSA and DSA.

At present, the currently operating providers are all using DSA because of the signing speed that this

algorithm offers. However, as recently as one year ago, another Provider was using RSA. Thus,

the USPS was verifying at least two methods in parallel.

USPS has defined the signature generation and verification process for each of the approved FIPS

algorithm. Because DSA is the current choice of Providers, we shall restrict the discussion to that

method.

The general steps in signature generation are the following:

In The PSD generates the DSA signature in accordance with FIPS PUB 186. The Secure Hash

Algorithm (SHA-1) is used to create a 160 bit message digest that contains data elements from Table

A2, such as Indicia version numbers, an algorithm ID, the certificate serial number PSD

manufacturer, model number and ID number, postage, ascending register amount, postage, dates, zip

codes, destination zip code, software ID, etc. The PSD uses the secure hash in the creation of the

DSA signature.

Figure X: DSA Signature Generation and Verification Process in USPS IBIP System

102

Source: USPS

Signature verification is performed on the mail handling systems of the USPS. Signatures are

stored in a database and retrieved for comparison. Note that the Message Digest is in the clear and

provides the algorithm and certificate number for key retrieval. Similar flow diagrams are described

for RSA and ECDSA algorithms.

103

Examples of Indicium Data Elements in USPS IBIP System, used for Secure Hash

Source; USPS

Using DSA default parameters specified in FIPS PUB 186, the PSD obtains or generates the

appropriate parameters according to the following table, which describes the signature generation for

the server-based PSD devices. In closed systems, there is no host system, all signature steps are

conducts onboard the PSD.

DSA Parameters: Sources and Storage in USPS IBIP System Requirements

104

The following diagram illustrates these various components:

For both open and closed system PSDs, the cryptographic functions are wholly contained in the PSD

device. The Provider initializes the PSD at the factory by receiving

105

Source USPS

106

Source: USPS

Use of Multi-Crypto within the USPS IBIP System

Multiple cryptography algorithms are used for generating digital signatures. Other secure hashing

is used for creating the message that is signed and printed in the bar code or data matrix.

Providers must also use secure communications with the PSDs for auditing functions and financial

transactions (Postage Value Download Transactions, audit messages, and register setting) and

resetting all registers such as the ascending and descending register values and the watchdog timer

values. Most of the Provider devices licensed to operate in the IBIP system use TDES for

communications purposes and Diffie Hellman for the keys to start the TDES sessions. One

Provider uses RSA for authentication with the Provider infrastructure.

107

Determining Decision Factors – Use of Multiple Digital Signature Algorithms

USPS decided to permit multiple digital signature algorithms with its indicia evidencing system in

order to provide flexibility for new products, vendor requirements, vendor proprietary needs for new

products. This approach enables more lines of revenue for the postal service. Different postage items

and data matrices have different space requirements and USPS decided that they would allow

flexibility to accommodate these needs.

Determining Decision Factors – Use of Multiple Devices and Vendor Implementations

The decision to permit multiple algorithms was based on the availability of proven, validated

algorithms and defined standards documents provided by NIST. The existence of the CMVP

program itself was a determining factor. This program gave the UPPS an effective means to ensure

that only valid products could be implemented on the system.

For the vendors, this permits them flexibility in the choice of algorithms for efficiency of signature

generation. DSA is considerably faster at generating signatures than RSA. This permits the

vendor to use lower cost processors and permits more rapid operation of the entire evidencing

system.

Determining Decision Factors – Ability to Rapidly Include Alternate or Future Algorithms

In addition to the ability to implement new algorithms rapidly into the design, the use of multiple

cryptography algorithms protects the IBIP system from catastrophic disruption should one algorithm

be compromised (or one Provider’s PSD implementation). The system can still function using

alternative algorithms. While Providers cannot easily change their PSD equipment, USPS

operations will not cease.

Key Management

Keys are generated in the PSD and the PSD public key is sent to the Provider’s certificate authority

and included with the certificate, which is forwarded to the USPS for use in verification. Because the

key management is a function of the Provider, the USPS cannot disclose details of this operation.

108

Design Cost

The design cost was affected to the extent that the design included more than one approach and key

management is more complicated. The USPS did not believe that there was a significant impact on

the design cost.

Implementation and Testing Cost

Using multiple algorithms to verify the indicia should not have significant impact on costs. Testing

the read capability must be performed for all different data matrices and bar codes in this system.

Each new Provider equipment must be tested for readability; testing for verification is a small

additional step once readability is proved.

Operational Cost

Operational costs are not significantly impacted in this approach. Once installed, the cryptographic

modules do not need to change..

The certificate indicates the type of algorithm used, thus there is less problem with key

confusion.

A key management issue for USPS is ensuring that the configuration of the drivers for the

crypto modules (if they use hardware) is properly maintained on host systems for validation.

Strong physical and logical access control and configuration controls on the hosts must be

used to protect host validation systems.

Risk Mitigation

In addition to the ability to implement new algorithms rapidly into the design, the use of multiple

cryptography algorithms protects the IBIP system from catastrophic disruption should one algorithm

be compromised (or one Provider’s PSD implementation). The system can still function using

alternative algorithms. While Providers cannot easily change their PSD equipment, USPS

operations will not cease.

109

Product Selection

USPS is using FIPS 140-1 certified cryptographic modules for verification. This is the key product

selection criteria.

110

添付資料 C-3. Federal Bank 事例調査

Federal Bank

System Description

The systems described herein is an application for transaction information between the government

and banks in the U.S. A more detailed description is not available, in order to protect the secrecy of

the security of this system.

This crypto-library provided an application-specific cryptographic functionality, via a high-level

application-programming interface (API), for a high-volume (transactions) and high-value

(monetary) banking system. As an intermediate library, its position in the call-chain hierarchy was

immediately below the banking system application and above the generic PKI toolkit and its

subordinate sub-systems. The following diagram illustrates the hierarchy of a typical application:

111

Although this banking system provided a variety of banking functions, the underlying criteria used

to define its security requirements (in terms of confidentiality and integrity) were based on:

• The system’s bank-to-bank fund-transfer capability.

• Potentially severe damage to the provider’s image that would be incurred in the case of a

compromise.

Due to the proprietary nature and sensitivity of the system, a complete description of the will not be

provided. However, only those areas involving the use of multiple-cryptographic functions will be

presented. Furthermore, all descriptions will be limited to the crypto-library and will not include

details of the banking system or its usage.

The architectural environment supported by the crypto-library included:

• A desktop PC, running an OTC operating system

• A smart card reader and smart cards attached to the desktop PC

• An optional hardware-accelerator card (PCMCIA) attached to the desktop PC

• A large centrally-located mainframe

The following diagram illustrates these various components:

The crypto-library incorporated a multi-level key-chaining process for controlling access to all

private and shared secret keys. The following table categorizes the major key levels and their use:

112

Key Category Hardware Device Primary Use Access Control

User-level Storage: Smartcard

Processing: Smartcard

• Two-factor user

authentication.

• Access to

Application-level

authentication

information.

Individual user

passwords—unique

to each user.

Application-level

(Some applications

were assigned

multiple keys in

order to enforce

role-based

entitlement)

Storage: Hardware

Accelerator Card (if

present), Disk (otherwise)

Processing: Hardware


present), PC’s CPU

(otherwise)

• Inter-application

authentication and

key exchange.

• Intra/inter-application

data encryption and

digital signing.

• En/decryption of

external access

keys.

Individual

application

passwords—unique,

randomly generated,

and frequently

changed byte-strings

required prior to

access or use.

External Access Storage: Hardware


present), Disk (otherwise)

Processing: Hardware


present), PC’s CPU

(otherwise)

• Communication with

external systems

(e.g., mainframes)

• Administrative

management

functions (e.g.,

re-initialization of

smartcards)

Encrypted using

application-level

keys

In general, all data was either digitally signed/verified or en/decrypted whenever it exited or entered

the applications’ immediate control (e.g., written to or read from disk, written to or read from

registry, transmitted over the network, etc.).

Use of Multi-Crypto within the Crypto-Library

The crypto-system provided multi-crypto in the following areas:

• Support for multiple symmetric algorithms (e.g., DES and Triple-DES).

• Support for multiple crypto-processing devices and the corresponding vendor’s

implementations (API libraries) of common cryptographic algorithms.

• Support for rapid inclusion of alternative or future algorithms (e.g., AES).

113

Determining Decision Factors – Use of Multiple Symmetric Algorithms

For the case where multiple symmetric algorithms were supported, the choice to support multiple

algorithms was due to timing issues. During the development and early deployment of the banking

system, the mainframe’s support for triple-DES capability was not fully implemented. However, a

conversion from single-DES to triple-DES was in progress and full-support for triple-DES was

imminent. Therefore, the crypto-library needed to support single-DES during the conversion period

as well as provide triple-DES support for imminent use.

It may also be of interest to note that the implementations of both the single-DES and triple-DES

algorithms varied slightly between implementations. Specifically, the mainframe’s implementation

used a different padding method (method to fill in incomplete data blocks) than did all of the other

implementations used in the banking system. This required additional but minor coding effort to

reconcile the different padding methods.

Determining Decision Factors – Use of Multiple Devices and Vendor Implementations

The crypto-library utilized multiple physical devices to perform the cryptographic functions,

including: (1) the desktop PC’s traditional (CPU and disk drives), (2) a smart card and reader

attached to the desktop PC, and (3) a hardware accelerator card. The mainframe system also

performed cryptographic operations but was outside the scope of the crypto-library and therefore

will not be discussed.

The PC’s CPU was used for the majority of cryptographic operations, including symmetric and

asymmetric encryption, as well as, digital signature creation and verification. The PC’s disk drives

were used for intermediate key storage (all keys were encrypted prior to being written to disk). It

should be noted that all CPU-based operations utilized only application-level keys (unique to each

banking system application) whose access was controlled using smartcard-based two-factor

user-level authentication. The decision to use common PC hardware to perform cryptographic

operations included several factors, including:

• Cost—PCs were fundamentally required—independent of the cryptography, for the

thick-client’s operation. Therefore performing cryptographic operations using the PC’s

resources did not incur additional costs. While requiring a hardware accelerator card in each

system was considered, the additional costs were considered to be excessive.

• Mitigating Controls—it was agued that the additional controls such as (1) substantial

114

hardening of the PC’s operating system; (2) physical access control; and (3) system integrity

checking; provided adequate protection of the system.

• Efficiency—While all systems utilized smartcards and readers, the cryptographic

throughput of these devices could not meet performance requirements.

The smartcard was used for two-factor authentication, key storage, asymmetric decryption, and

process control. The method used to provide two-factor authentication utilized: (1) a user-selected

password associated to the smartcard and (2) a smartcard-based decryption operation that utilize a

unique private key (also stored on smartcard). Additional private key decryption was limited (beyond

authentication) to the decryption of additional application-level authentication information that was

stored on the PC’s disk drive. In addition to the user’s private key, the smartcard was also used to

store the public key of the top-level certificate authority (required for secure verification of

certificate chains) and encrypted symmetric keys. The smartcard reader was also used to provide

screen-lock functionality—when the smartcard was removed from the reader the application would

continue to run, in a limited manner, but user reauthentication was required in order to access to the

application’s user interface. The decision to use smartcards included several factors, including:

• Cost—the smartcards and readers cost were sufficiently small when compared to the

additional security provided through two-factor authentication.

• Functionality—enabled the use of unique user-level passwords and access tokens (as

contrasted with a PIN-pad used with many hardware accelerator cards).

• Product maturity—considered to be relatively mature in terms of portable access tokens.

• Multiple suppliers—allowed for competitive bidding and contingency planning.

The use of the hardware accelerator card was limited to use by only the applications (i.e., user’s did

not authenticate directly to the card itself). In addition to providing secure key storage, this card was

also used to perform symmetric en/decryption and the digital signature operations performed by the

banking applications. A removable PCMCIA configuration was chosen to provide secure storage of

the card during periods of non-operation. As in the case of the application-level key access, the

access to this device also required smartcard-based two-factor user-level authentication. It may be of

interest to note that although the use of the hardware accelerator card has been optional and limited,

the crypto-library was designed to incorporate this device for use in any client within the banking

system. The decision to use a hardware accelerator card included several factors, including:

• Cost—the device’s cost were sufficiently small when compared to the operational costs

associated with the re-issuance and redistribution of certificates.

• Additional security—the remove-ability and secure storage of the device provided

additional methods to control use of the card and the keys that it contained.

115

• Product certification—the selected device was certified under FIPS 140.

.

Determining Decision Factors – Ability to Rapidly Include Alternate or Future Algorithms

The crypto-library was designed in a manner that enabled the rapid inclusion (through the use of

preprocessor directives) of alternate algorithms (Diffie-Hellman) and emerging standards (e.g., AES)

primarily to provide extensibility and increase product longevity. A secondary motivation for

including the ability to utilize alternate algorithms was to minimize the impact in the event that the

triple-DES algorithm was compromised.

Key Management

The design of the crypto-library uses a complex key management schema. However, the complexity

is due primarily to the dynamic linking of keys (i.e., user’s private key used to access

application-level key, then application-level key used to access additional keys, etc.). The additional

complexity of managing keys solely due to the multiplicity was negligible.

Design Cost

The design cost was primarily driven by the necessity to meet other aspects of the design

requirements (e.g., two-factor authentication, unique user access passwords, fine-grained

authorization/access controls, ease-of-use, etc.). Although some additional design costs were

incurred due to the multiple cryptographic aspects, these costs are estimated to be less than 5% of the

total.

Implementation and Testing Cost

The implementation and testing costs were primarily driven by the necessity to meet other aspects of

the design requirements (e.g., two-factor authentication, unique user access passwords, fine-grained

authorization/access controls, ease-of-use, etc.). This is primarily due to the abstract and high-level

manner in which the underlying toolkit supports the various algorithms and cryptographic devices.

Three multi-crypto related areas emerged during implementation that required significant levels of

effort—these were: (1) instability of the smartcard driver modules, (2) differences in the DES

padding implementations, and (3) the manual operations required during testing of smartcard-related

functionality. However, it should be noted that these problem areas would have been experienced in

116

simple/single-crypto implementations. With the exception of these three problem areas, the

additional costs are estimated to have been less than 5% of the total.

Operational Cost

The operational costs were primarily driven by two factors: (1) the operation of a centralized/root

certificate authority, and (2) level of difficulty associated with resolving user problems (i.e.,

helpdesk) when data is encrypted. Neither of these problems can be attributed to or are unique to the

multi-crypto aspects of the banking system.

However, it is important to recognize that, by design, nearly all of the user

management/administration (including issuance/revocation of smartcards, creation and publication

of user certificates) was delegated to the end-user staff. Had this not been done, these associated

costs would have been substantial.

Risk Mitigation

The use of multi-crypto provided risk mitigation by providing a means to provide:

• Two-factor authentication using smartcards

• Role-based user entitlement (e.g., user’s access to system functionality was

cryptographically enforced)

• Strong authentication of applications and control of its operational access.

• Immediate and local user management and administration.

• Extended longevity of product through incorporation of future and alternative algorithms.

The use of multi-crypto compounded many of the issues that must be addressed during the

implementation of any cryptographic utility, including:

• Run-time libraries and drivers—many vendors provide dynamically linked libraries that are

used to provide critical functionality. The implementation should provide a means to

validate the authenticity of these components prior to use in order to eliminate introduction

of subversive replacements.

• One-to-one association of passwords to keys and cryptographic hardware—this limitation,

even if done in a n-of-m manner, may require password sharing in order to meet the

practical operational needs of a system that supports numerous users. Alternative methods

should be employed in order to securely implement a many-to-one access control process.

• Immediate revocation of system access—this needs to be addressed in a manner that

117

minimizes (1) the elapsed time between the time that revocation is requested and time

revocation is effective, (2) the level of effort required, and (3) dependence of external

resources (e.g., revocation in cases where the user’s smartcard is not available)

• Independent review—an independent review and/or testing of system designs and

implementation is essential in order to validate the correctness and completeness of the

system. (This follows the principle that most cryptography implementations are not broken

through compromise of the cryptographic algorithms, but through its use/implementation)

• Isolation and insulation from cryptography—the resulting system should severely minimize

any cryptographically critical components (e.g., access to keys), decisions (e.g., acceptance

of certificates), and processes (e.g., importing keys).

Product Selection

The products were selected in various ways. In the case of the underlying toolkit, a comparative

analysis was performed (comparing functionality, security of implementation, ease of use, etc.) prior

to being purchased in a sole-source manner. In the case of the smartcards and readers, a traditional

RFP process was followed. In the case of the hardware accelerator card, a FIPS 140-1 certified

device that was supported by the toolkit was sole sourced.

118

添付資料 C-4. 株式会社オレンジソフトインタビューメモ

インタビュー実施: 2003 年 2 月 14 日

a. 複数暗号アルゴリズム

GPKI を想定した複数暗号アルゴリズム対応の S/MIME アプリケーションの開発を行った時、その

検証のために認証局のソフトウェアとして IPlanet、OpenSSL、EasyCert を用いた。EasyCert は名

古屋工業大学が開発しており、複数の共通鍵暗号、共通鍵暗号、署名暗号アルゴリズムをサポー

トしている 24。

実証実験等で用いたシステムでは複数の暗号アルゴリズムを実装しているが、想定される問題とし

ては、過去からの互換性のために、RC2 などセキュリティ強度の弱い暗号アルゴリズムをサポートし

ており、ユーザがこれを用いた場合に破られる可能性がある、ということである。RC2 など弱いアル

ゴリズムを使わせないようにするためには、インストーラや初期設定ファイルで特定の暗号アルゴリ

ズムの使用可/不可のオプション設定ができるため、この機能を用いてユーザに弱いアルゴリズムを

使わせないように強制する方法が考えられる。

119

添付資料 C-5. セコムトラストネット株式会社インタビューメモ


回答者: TS 事業部ソリューション技術部部長松本泰

a. 日本の政府認証基盤 (GPKI）

GPKI の現在の仕様では、署名アルゴリズムとして RSA のみの実装で作業が進んでいる。共通暗

号である DES、3DES、AES については、PtoP なので複数暗号アルゴリズムの対応は可能であるが、

公開鍵暗号に関しては、RSA 以外のアプリケーションの実装やテストは、困難であり、また複数ベ

ンダーによる GPKI 相互運用を考えた場合、複数暗号アルゴリズムに対応できている日本ベンダー

がほとんどないのが現状である。

CA 証明書と EE 証明書の 2 種類あるが、EE 証明書では DSA の可能性があるが、CA 証明書に関

して DSA の対応は現状では考えられない。また、DSA を正しくサポートしているベンダーが少なく、

また DSA は 1024 ビットの署名のみの暗号アルゴリズムである。

署名暗号アルゴリズムについて、md5WithRSAEncryption は問題なく動作すると思われるが、

MD5 は電子政府推奨暗号リスト案から現状外れている。dsaWithSha1 については、実際に DSA の

証明書を発行しているケースがなく、本当に動作するかどうかは分からないと思われる。

EE 証明書の有効期限が 3 年、CA 証明書の有効期限が 10 年であり、複数暗号アルゴリズムへの

対応あるいは新しい暗号アルゴリズムを追加することを想定した場合、2 年や 5 年といった短期での

対応は困難で、10 年、20 年のような長期での対応が必要となるであろう。CA 証明書では、RSA 以

外の 2048bit 相当の強度を持った推奨アルゴリズムがないので、現状は選択肢がなく、複数暗号ア

ルゴリズムを検討する必要性が考えられない。

複数の公開鍵暗号をサポートした認証局であっても、運用開始後は、ひとつの CA ではひとつの鍵

で運用するのであって、そのためひとつの署名アルゴリズムしか使えない。この鍵を切り替えるのは

通常は、困難である。「CA の鍵更新」は新しいスキームであり、ブリッジ CA としてはその対応が仕

様に含まれている。

アプリケーション側では RSA、DSA の両方のサポートがあるが、日本 GPKI として方針を出すとす

れば「5 年以内にサポート」のような形になると思われる。

日本 GPKI として、テストのスキームが存在しないため、機能などを確認する手段は現状なく、「署

名検証」のテストに対するクライテリアが必要であると思われる。

また、CMVP 評価認証の製品は日本ではまだほとんどないと思われる。理由は、CMVP 評価認証

にコストがかかるため。ただし、これに関連し、特定認証業務や GPKI 調達では HSM などに「FIPS

140 レベル 3 相当」の要件を出しているが、これを誰がどう認めるかが非常に曖昧、という問題点が

存在する。

120

添付資料 C-6. 株式会社富士通研究所インタビューメモ


回答者: IT コア研究所鳥居直哉

a. 複数暗号アルゴリズム

複数暗号アルゴリズムを使用できる通信プロトコルとして有名なものの１つは、SSL/TLS で、公開鍵

暗号 (RSA, DSS, DH)、共通鍵暗号 (RC2, RC4, IDEA, DES, 3DES) ともに暗号アルゴリズムを切

り替えて用いることができる。

複数暗号アルゴリズムを用いたシステムの実装を想定した場合、問題点は、暗号アルゴリズムに関

するものと暗号アルゴリズムのシステムへの適用に関するものが考えられる。

まず、暗号アルゴリズムに関しては、その選択や鍵長が重要であり、例えば 40 ビット鍵の RC2 など

セキュリティ強度の比較的弱いと考えられる暗号アルゴリズムを実装している場合、そのアルゴリズ

ムをユーザが用いることによりセキュリティが低下する可能性が考えられる。また、暗号アルゴリズム

実装時の問題点としては、数式で示される暗号アルゴリズム自体を正しく動作する暗号ライブラリに

実装できたかどうかという検証は一般的に困難なことがあげられる。これは全ての場合が検証でき

ることは、暗号が解けてしまうことを意味する場合が多いからである。複数アルゴリズムの場合、あま

りに多くのアルゴリズムへの対応した場合に、開発コストが増え脆弱性が増す可能性があるという問

題点が存在する。

また、暗号アルゴリズムをシステムに実装した場合の問題点として、暗号アルゴリズムの切り替え時

に脆弱性が発生する可能性があると考えられる。たとえば、暗号アルゴリズム切り替え時に、前の

暗号アルゴリズムで用いていたデータ領域がクリアされず、このデータが漏れて暗号化したデータ

の内容が盗まれるケースなどが考えられる。暗号の鍵管理においても、注意深い実装が必要であ

る。過去に公開されている事例でも、Web サーバに保管されている暗号鍵の保管に関して注意が

必要だと指摘されている。複数アルゴリズムという観点からは、複数暗号アルゴリズムに対応し鍵の

種類が増加すると、それだけ守るべきデータが増えるため、システム上で鍵をどのように守っていく

かという方針とそれに沿った実装が必要になる。

121

添付資料 D-1. Cryptography Research, Inc. インタビューメモ

Notes from conversation with Paul Kocher, Cryptography Research, Inc. Founder and CEO, discoverer of differential power analysis attack method.

Trends in crypto. See DPA, they are now selling a system to analyze and test for DPA

vulnerabilities.

It is difficult to pinpoint trends in attacks. There are new forms of attacks nearly daily, but few

pose major security risks. There is no way to understand every possible avenue of failure for every

product, thus there is no way to determine trends in new attacks. They can see the frequency of

certain types occurring, but not what will be new.

In implementation: Implementation security is a hard problem They are seeing most failures in

protocols, not in the hardware of technique itself. Knowing whether you

”got it right” is very difficult; and there are many ways to attack, nothing is unusual.

He believes that most of the effort should be spent on the process of risk analysis and risk

management. If you are not confident in your process, you will likely have weaknesses.

CR takes a different type of risk management approach and reviews the high level architecture,

architectural details, and even the code for implementations of new software and new hardware.

They look at it from the security viewpoint (what do you know, what do you have, for

authentication) etc and then they analyze each element. For example, if you have high value keys

that can’t be changed, you have a problem if they are compromised.

Smart cards as an application are easy to analyze for risk management. Smart cards have been

compromised, but now they are relatively tamper resistant for most applications, but you wouldn’t

want to use one for nuclear bomb launch codes, but they are good enough for managed risk

implementations. Most are used for cell phone value, credit and debit cards, Pay TV systems, and

Identity cards. The first two applications can limit the risk, the third application has slightly more

stringent requirements, and the last has the most stringent requirements.

The trend that he sees in the past year is a push away from standardized certification and evaluation

of products and systems. In fact, he sees them going sharply in a different direction. The problem

with certification programs is you will only find the problems that you are testing for, that are

defined in the test protocol. You won’t find other problems unless you look for them. He thinks

this is true of both CC and CMVP.

122

He sees clients wanting them to take a creative approach to trying to analyze and break their systems

during development and implementation. “Can we break it?” He says this isn’t as expensive as

you might think given that his team has a great deal of experience. They can do this for $100K for

an average system (financial clients are especially interested in doing this).

In terms of choosing products and using the certifications, he believes that people know what the

certifications do, but they really need to get a third party evaluation of the product. The purchaser

whats to know what the vendor is willing to do to have things tested. They also need to review the

CC PP and ST’s to make sure that the components they are selecting match (EAL levels, capabilities,

and the like)

He knows from inside experience that the NIST Laboratory accreditation process notwithstanding,

the labs are of varying quality. The low cost labs do not do any testing beyond the FIPS

requirements, so the vendors do not know what other attacks can compromise the product

(sometimes they know, but don’t want it confirmed.) Problem of building products to the

certification standard.

More skilled and more meticulous labs catch more problems with new products. The differences

are well known in the industry. These labs are not the cheap labs and they report more of the flaws

to the product vendor.

123

添付資料 D-2. InfoGard Laboratories インタビューメモ

Notes on interview with Tom Caddy, InfoGard Laboratories

Lab Director

Companies are no longer having their products tested for DPA and TEMPEST and other remote

means of attacking them (Power analysis, timing analysis, Fault induction and TEMPEST). Under

FIPS 140-1, before any of these methods were even mentioned in the Standard, companies were

having the laboratory look for these flaws. These decisions were driven by the widespread news

about attack methods and the vendor wanted the information for their own knowledge, not to be part

of the security policy of the product. He doesn’t see people making claims under section 4.11

Mitigation of other attacks under FIPS 140-2, but it is still early.

This problem is largely fixed. The ability to do DPA and TEMPEST attacks is true mostly of single

chip devices. If you have a multichip device, the magnitude of the problem is vastly reduced. A

multichip module will have power conditioning, grounding, voltage regulation on board, capacitors

etc) these all help reduce the power fluctuations that are being detected. These techniques reduce

the signal by 40 to 100 db.

The vulnerability of the single chip module was such that it could be cracked with about 10,000

samples (without the countermeasures they have now using software to randomize the timing and

power); for a similar multichip module you would need over 1 million samples to crack the crypto.

Smart cards are less susceptible today to DPA and SPA than they were. Most smart card vendors

have implemented random timing and noise which have done a lot to mitigate the risk from DPA and

SPA attacks. This is still important for the following situations: if you lose control of the card, it

can’t be used or if the card is in “enemy hands” such as the cards used for cell phone value and Pay

TV. Users have incentive to attempt to compromise cards in these applications so they require a

higher level of security. The card in postage meters fell into the latter category. In these settings

the user can tap the power line, so minor variations in power could be read directly while the card

generated the key. TEMPEST, such as that that is the concern of NASA and the DOD is not an

issue…

The USPS was very interested in having secure smart cards for postal applications (postage meters a

few years ago). These were single chip devices and they needed to have better security from side

124

channel attacks (DPA) and other attack methods. The need for security in single chip devices

varies with the application.

Most smart card companies have FIPS 140 certified products, such as Schlumberger, even if they are

not used by the government. In general, commercial organizations are using the FIPS

certification as a beginning point, then looking at the other capabilities of the cards. By law, the

financial service companies have to be very careful, so they use FIPS certified products (may help

protect them legally), other postal services (Germany, Canadian, Netherlands) are using FIPS

certified products (not CC as it happens).

Size of certification teams.

For most FIPS teams, this lab attempts to keep the team to one person. This gives a single point of

contact and most of their employees are trained in the assessment so they can handle the software

and electrical analysis of the products. If they have one that has physical security requirements

(such as smart cards) they add a physical security specialist to do those portions of the analysis.

They have had up to three on these teams, but only in rare cases.

The CC teams are bigger because there are more and different types of analysis. The process

inspections are performed by EDP audit types of people for the assurance portions of the

certification, the testers are the same staff that would do the FIPS testing. They use MS, and BS

degreed personnel in Computer science, Electrical engineering, materials science, and math.

125

添付資料 D-3. RSA Laboratories インタビューメモ

Notes from interview with Bill Kaliski RSA Laboratory, CT

Lab director for RSA Labs

IPS ahs Cryptorak (sp) algorithm evaluation program that is currently ongoing. He knows them

well.

RSA decided to submit the Keon CA product for CC certification due to customer interest in it.

They make such decisions based on the market need for certification of products.

He doesn’t really feel there are identifiable “trends” in attack methods. As far as implementation of

countermeasures, he suggests that we review the CHES materials for the past couple of years.

He feels there is a need for a more global standard. He believes that protocols are of key

importance. There need to be some standards for protocol implementation, there currently are not.

Security needs to be added to protocols. In protocol desing, there is much to be learned from

history (see 802.11 fiasco; they forgot the lessons learned from 802.10)

The most recent problem he can think of is the one identified by Nokia, IBM and others that has to

do with legacy authentication problem. When you layer two different authentication technologies

together, you are liable to get less than you started with. Nokia identified this as a tunneling

problem (Use the first authentication layer with another common security method and you get bad

outcomes). This is often found where you don’t have trust relationships and you use a shared key

plus a public key for scalability. Can introduce weaknesses because they are conflicting and can

enable an attack.

There is much to be learned in the correct structure to use for combining security technologies

correctly. It can be done, but it has to be done with a purpose and with careful design. For

example, authentication plus a key to establish a session can occur if one knows or has something,

like a biometric, but how do you start this process if the system holds the keys? During the design

phase, you have to look at how these interact (both the “rules” and the technologies). A few years

back Mitre discovered a problem with PKI switching between A and B when the system or the user

didn’t know what parameter they were using.

126

Industry has been weak on protocol design and usage. For example, SSL and wireless protocols

have grown in usage so they are being asked to do more than they were really intended to do.

Thinks that “remote monitoring” attacks still require some work in implantation. They aren’t fully

solved. Talk with Paul Kotcher.

127

添付資料 E. 調査項目 1 分析結果 (原文)

Comparison of Cryptographic Module Verification Program and Common Criteria Certification

Introduction

The goals of certification under Common Criteria (CC) and the goals and intent of the Cryptographic

Module Verification Program (CMVP) have similarities and significant differences. In fact, these

programs are not really comparable from a technical perspective.

The CMVP encompasses validation testing for cryptographic modules and algorithms. CMVP

is a program within the Computer Security Division of the National Institute of Standards and

Technology (NIST). The Computer Security Divison maintains standards for cryptographic

algorithms and modules. CMVP oversees validation and certification of products against

those standards, the NIST operated National Validtion Laboratory Assurance Program CMVP

is a logical extension of the standards activities of the National Institute of Standards and

Technology (NIST), its parent agency. NIST has an extensive program Information

Technology and in Computer Security (Computer Security Resource Center, CSRC). The

CMVP is one of the programs run by the CSRC. The entire focus of the CMVP is validation

and accreditation of cryptographic algorithms and their implementation in products.

The goal of the Common Criteria is much broader. The CC is intended to be used as the basis

for evaluation of security properties of IT products and systems. While it is intended to

provide comparability between the results of independent security evaluations, there is some

debate as to how effective it is at this goal. There are a number of topics that are outside the

scope of the CC. These include the following:

Administrative security measures not related to the IT security measures.

Evaluation of technical physical aspects of IT security such as

electromagnetic emanation control, are not specifically covered although

many of the concepts addressed in the CC are applicable to that area. Some

physical security aspects are covered.

“The subject of criteria for the assessment of the inherent qualities of

cryptographic algorithms is not covered in the CC. Should independent

128

assessment of mathematical properties of cryptography embedded in a Target

of Evaluation (TOE) be required, the evaluation scheme under which the CC is

applied must make provision for such assessments.iii

From a market perspective, that is when a product manager must make the decision to get one

evaluation or the other, they are somewhat comparable. The product manager makes the decisions

based on the security requirements, features, and functions appropriate for each market. If a

particular market requires the certification, such as government markets in the U.S., the product

manager must weigh the cost versus the size of the target market. For the purchasing manager,

the certification would seem to be a check off item in evaluating like products, however, they are not.

The FIPS 140 certification program assures that the product conforms to a highly specific set of

security requirements and that hardware and software testing demonstrates this conformance. In

contrast, CC certification only certifies that the product meets the security targets set by the product

vendor that meet the requirements of a protection profile, which may be defined by a client, or the

vendor itself. CC is highly process focused and looks at a broader set of issues than FIPS 140 and

other FIPS published standards, for encryption algorithms.

To the extent that FIPS is externally defined and highly specific, comparing different products that

are certified at the same assurance level under FIPS 140-2 gives the user some assurance that these

products will have similar security capabilities. This is not true in the CC scheme. EAL levels

provide a clue to the assurance level, but the user must compare products that meet the same

protection profile and have the same security targets. Otherwise, there is little basis for comparison.

This makes the procurement task much more difficult.

I. How the Current Systems Operate

There is a significant difference in the operation of CC versus CMVP with respect to the product

vendor. The CMVP certification process is relatively simple for vendors; CC, in contrast requires

considerable more work for the vendor, and vendors report that their first experience with a CC

certification process is lengthy, sometimes confusing, and very expensive. As a result, US vendors,

in particular, regard the FIPS certification process more favorably. Their decisions on which

certification to apply for are determined by the market, but, because CC can use FIPS 140

certification as a ST or requirement within a Protection Profile,

iii Common Criteria for Information Security Evaluation Part 1: Introduction and general model, Version 2.1, August 1999, Page 2.

129

A. Procedural Flow of Evaluation and Certification

1) CVMP/FIPS-140 and Algorithm Standards

The CVMP procedure is relatively simple. The company submits an application for

certification identifying the Standard, the level of compliance, documentation, test results, and

letter from the laboratory that performed the testing. The Laboratories must be from an

approved list of laboratories certified by the National Institute of Standards and Technology

under the National Voluntary Laboratory Accreditation Program.

Figure 1 following shows the steps in the process.

In some cases, a vendor may hire a third party laboratory or consultant to assist in the

preparation of the documentation required for submission to NIST. The documents required

are listed in the FIPS 140-2 Security Requirements for Crytographic Modules and include the

following:

Newly added to the FIPS 140 Security Requirements is an entire section on Design Assurance.

To the extent that design assurance is covered by CC, this addition, brings process assurance

investigation into the certification process. The NVLAP laboratories are also staffed to

examine the vendors’ internal design, engineering, and manufacturing processes to ensure that

they comply with the standard requirements.

130

Design assurance requires that the vendor follows best practices during the design, deployment,

and operation of cryptographic modules, which provides assurance that the module is properly

tested, configured, delivered, installed, and developed and that the proper operations guidance

documents are provided to the user. Security requirements are specified for configuration

management, delivery and operation, development, and guidance documents.

Design Assurances includes configuration management for the module, its components, the

operating system, and documentation for user guidance and the security policy.

The FIPS 140-2 Security Requirement also includes “recommended software development

practices” that vendors should follow to facilitate the analysis of the components for

conformance to the requirements of the standard and to reduce design errors. These Software

Development Practices include such items as

Comments for variables that provide the range of allowable values

One entry point for each procedure; at most two exit points for each procedure: one

for errors and one for normal exits.

Control flow should be defined

Software should be hierarchically structured

The full list of recommended software practices is included in Appendix B to FIPS PUB 140-1.

The NIST examiners evaluate the source code for all modules against these practices.

131

2) Common Criteria Certification

Although the steps in the CC certification process are very similar to the steps for CMVP, a

direct comparison is deceiving. Step 5 is an extremely lengthy, complex, and complicated

process; it comprises the bulk of the effort and cost of the CC certification process.

B. Schedule and length of time

The length of time for CMVP certification is shorter than for a CC certification. This is

particularly true for a vendor’s first attempt at either certification process. A typical FIPS 140

certification process will take from 3 to six months for the vendor and laboratory testing

process depending on the extent of readiness of the vendor’s documentation. The laboratory

testing of the module, examination of the source code, and physical testing takes from 8 weeks

to 12 weeks depending on the type of product and the level of certification sought by the client.

The actual time for examination of the documents at NIST is approximately 4 weeks, however

due to backlog, the NIST examination is taking about 2 months.

The schedule and length of time for a CC certification process is about 3 times as long. Thus,

it can take from 12 to 18 months for a vendor to complete the certification process for CC on a

product. According to vendors the first time through the CC process is very expensive,

lengthy, and troublesome. Subsequent certifications are shorter, perhaps only twice the time

for the first because the company has the proper procedures and processes in place and they

only need to be verified. Most of the time is spent on the vendor site investigating and auditing

132

the procedures, practices, and processes used and comparing them to the CC requirements for

that process and documenting the conformance.

C. Cost

The cost of CMVP certification is considerably less than the cost of a certification to the

Common Criteria. Most vendors could not cite direct costs for both experiences, however,

estimates for the difference in cost for CC versus CMVP certification varied from 4 times

CMVP certification to 30 times CMVP. The vendor citing this last estimate of the costs had

been certified in 2002 during which time the CC approach was still being developed and

additional costs resulted from changes in the requirements for documentation of processes,

additional processes, and the like occurred and caused considerable iteration during the internal

auditing and examination of the company’s controls.

Typical costs for FIPS 140 certification are shown in Table 1 following.

Table 1: Typical Laboratory Charges for FIPS 140 Certification

Assurance Level Low range High range

Level 1 $25K $30K

Level 2 $30K $35K

Level 3 $35K $45K

Level 4 $40K $60K

The above pricing includes a two day workshop at the client’s engineering offices to educate

the staff regarding the documentation requirements, procedures, schedule, and the like. This

price also includes some assistance with document preparation. One vendor routinely hired a

second consulting firm to assist in the preparation of documents for the application. This

increased the costs by about $30K.

Most products require some rework in testing or documentation (according to NIST), few

applications have ever completed the certification process without being sent back to the vendor

and laboratory for additional documentation and testing.

133

NIST started charging for its examination time in July, 2002. The following fee is charged

for each application:

Table 2: NIST Charges for FIPS 140 Certification

Assurance Level Fee

Level 1 $2,750

Level 2 $3,750

Level 3 $5,250

Level 4 $7,250

Costs for the CC certification are not neatly determined and vary considerably. CC Costs are

a function of:

Type of product to be certified (this affects the extent of the investigation and the actual

testing of the product)

Evaluation Level that the vendor wants to have the product certified against; the higher

the EAL, the more costly the evaluation because more testing and more investigations

are conducted

Whether the evaluation requires physical testing, this also increases the cost

Readiness of the vendor (does the vendor have controls on all the processes in

development and manufacturing or delivery, can the vendor demonstrate these

processes). Some of the processes that are examined under FIPS 140-2 are included in

the CC process, but CC is much broader. For example CC requires software coding

practices that FIPS simply recommends.

Documentation that is available in the vendors standard engineering processes; CC is

intended to require no more than engineering “Best Practices” but in some cases,

particularly in software development, companies do not adhere to best practices for

version control and coding practices

Protection Profile to which the product is intended to conform; if it is an existing profile,

there is somewhat less work, a new PP must be accepted first by the country CC

authority

134

Security Target; if new, the CCTL will need to develop an approach

Is the product one that the CCTL has worked with on prior occasions; do they know all

the technology involved in the product. Different laboratories have different

experience with products of different types. is it new or one that exists and is

accepted.

Few vendors have gone through this process more than twice, so there is little experience of CC

costs among North American vendors. Furthermore, NIST and NSA NIAP program has only

recently taken on the management of CC in the U.S. However, the costs are higher.

We estimate that typical CC certification costs for the laboratory work are at minimum three

times the same cost for a CMVP certification to FIPS 140-2 for the same product. This

assumes that the vendor is prepared for the certification and has all the “assurance” items in

place. The cost would be somewhat less if the product is already FIPS-140 certified and the test

results are usable for the CC submission. NIST estimates that complex products will cost in

excess of $1 million to certify to the CC. At present, NIST and NSA, which jointly participate

in the validation body, do not charge for their review of the submission package.

According to labs and vendors, many vendors hire additional consulting staff to assist with the

preparation of the documentation for the CC process. This will add another 1/3 to ½ to the

total cost of the certification. Some laboratories assist with documentation development,

others do less.

Typically a laboratory and vendor will establish an ongoing relationship over time because, as

laboratory staff become familiar with the vendor’s products, the certification and testing

process will be more cost effective.

D. Number of required personnel and skill level for evaluation

The CMVP staff at NIST who review the applications for FIPS 140-2 consists of 4 people reviewing applications. They have backgrounds in computer science, cryptography

(mathematics), and electrical engineering. The laboratories report similar backgrounds for their

staff, but those that perform physical testing also have materials science majors on staff. Staff

members generally has at minimum Bachelor of Science degrees, many have Master of Science

degrees. If they do not have specific backgrounds in information security, the laboratories

provide training. The FIPS certification teams are relatively small; the laboratory may assign

from one to three staff to a project depending on the product being reviewed.

135

CC teams must be larger because of the audit type review that is conducted on the processes;

these additional staff members often have backgrounds in IT auditing (computer science with

EDP auditing experience and general computer systems security). A CC team would have the

same technology backgrounds and similar numbers of technical staff that would conduct a FIPS

140-2 certification of the same product. The CC process, however, expands the review to the

entire product but would not test the algorithms in the cryptographic module, while the CMVP

process certifies only the cryptographic module within the product.

For example, the Postal Security Devices described in the multi-crypto case examined in the

following section, have cryptographic modules that are FIPS 140-1 certified. However, the

USPS had to have additional areas of the designs reviewed to ensure that other features and

elements of the product were also secure. More specifically, the product contains registers

containing values that someone wishing to use the device without paying for additional postage

value. The USPS had one of the NVLAP labs review the products vendor’s were proposing

for the system.

Skills required for FIPS testing

NIST has definded the skills required in laboratories that are accredited to perform FIPS testing.

The staff members must have appropriate college degrees or equivalent experience of 2 or more

years in security product development, testing. Or evaluation experience. Training for the

staff should be in the following areas:

General requirements of test methods and writing of test reports

Familiarity with classes of hardware platforms and operating systems for testing software

cryptographic algorithms

Voltage and temperature measurement for environmental testing required for testing to

Security Level 4

Computer security concepts

Finite state machine model analysis

Production grade, tamper evident and tamper detection techniques

Software design specifications including high-level languages and formal models

136

Key management techniques and concepts

Cryptographic self-test techniques

EMI/EMC testing techniques

Familiarity with FIPS-approved cryptographic algorithms of all types and with

cryptographic terminology and families of cryptographic algorithms

Familiarity with all FIPS publications and with the Common Criteria and ability to locate

and download information from NIST and CC sites on the Internet

Operation and maintenance of the Cryptik Testing Support Tool (from NIST)iv

Quality program and quality control processes

The academic backgrounds of the participants in the Cambridge Tamper Labs exhibit the

appropriate mix of skills and technical backgrounds that would be found at a validation

laboratory: Computer Science with specialties in Security and systems, cryptography,

mathematics, semiconductor engineering, materials science, chemical engineering. Signal

detection and processing for electromagnetic, optical, and acoustic signals.

Skills Required for CC Evaluation

NVLAP has defined the skills required for accrediting laboratories to perform CC evaluations.

These skills are outlined in the NVLAP Draft Handbook 150-20 Information Technology

Seucirty Testing – Common Criteria and include the following:

“Laboratory staff members who conduct IT security evaluation activies shall have a

Bachelor of Science in Comptuer Science, Computer Engineering, or related technical

discipline or equivalent experience.”

Collectively the staff shall have knowledge or experience in operating systems, data

structure, design/analysis of algorithms, database systems, programming languages,

computer systems architectures, and networking.

iv Horlick, Jeffery; Lee, Annabelle; Carnahan, Lisa; National Voluntary Laboratory Accreditation Program, NIST Handbook 150-17 InformationTechnology Security Testing – Cryptographic Module Testing,June 2000, page 7-9.

137

On going training of laboratory staff concentrates on general requirements of test methods,

computer science concepts, security concepts, working knowledge of the Common Criteria, and

working knowledge of the Common methodology

E. Required materials

The documentation requirements for both approaches are extensive, however, CC

documentation of internal company processes are comparable to an ISO 9000 documentation.

All the documents that are provided for FIPS certification are also required for the CC

certification, however the formats for the documents are different and fairly specific.

The materials that the vendor must submit to a CMVP Testing Laboratory include the following

documents and items:

Vendor must supply a nonproprietary Security Policy that describes

o the approved mode of operation for the module

o the method for invoking the approved mode or op34q5ion

o the method for indicationg that the cryptographic module is in an approved mode of

operation

o the instructions for obtaining the approved mode of operation indicator

Supply documentation that identifies, by major services, the software or firmware that are

executed by the processor, and the memory devices that contain the executable code and

data; the vendor shall identify any hardware with which the processor interfaces for all of

the following items:

o Cryptographic module specification

o Cryptographic module ports and interfaces

o Roles, Services, and authentication

o Finite state model

o Physical security specification and maintenance method, if appropriate, and normal

operating ranges

138

o Operational environment including operating system and hardware

o Cryptographic key management

o Electromagnetic Interference/Electromagnetic compatibility

o Self-tests performed by the module, error states, power-up tests and self tests

o Design assurance including procedures for secure installation and start-up of the

module; distribution security; correspondence between the design of hardware,

software, and firmware components and the module security policy; specification

of the source code or firmware components, annotated with comments.

Vendors must supply the validation laboratory with production-type hardware, compiled

software, source code, and documentation listed above. The testing may be conducted at the

vendor site, but laboratories are required to provide physical security to protect the proprietary

information of the vendor applicants.

Documents that need to be submitted for the CC evaluation by product vendors:

The vendor, or in CC language, the sponsor of an IT evaluation is responsible for providing the

Protection Profile or Security Target and the associated IT product/system that will become the

Target of Evaluation. (TOE).

The elements of the TOE that must be delivered include the following. In the case of a

product with a cryptographic module, this would include production hardware, software

compiled code and documented source code, microcode; all items normally generated during

the development. In addition, any security-relevant documentation must be developed and

delivered as required by the assurances in the ST. If the TOE consists of products that have

been evaluated previously, the sponsor of the evaluation must make the contractual

arrangements including the authority for the release of previous evaluation results for the

included product. Some of these documents will be the non-proprietary documents made

available after the certification of a previously evaluated product.

Before the Validation Body will schedule and agree to the evaluation of a product or system, the

following written information must be submitted by the sponsor and the CCTL

Evaluation work plan

139

Evaluation schedule

The Security Target and description of the Target of Evaluation or

The protection profile in the case of an evaluation of the PP.

Because the Validation Body is responsible for technical oversight of the evaluation process and

the validation activities required of the VB, the sponsors should not allow any evaluation tasks

to occur before the evaluation is formally accepted by the Validation Body.

The CCTL will submit a work package that includes:

All observation reports issued during the evaluation project (these request

guidance and report on proposed solutions to technical evaluation issues or scheme

process issues

Evaluation analyses (in accordance to the Common Evaluation Method

Evaluation Technical report

The Evaluation Technical Report is produced by the CCTL and is the principal basis for the

VB’s Validation Report. The ETR presents all verdicts, their justifications, and any findings

derived from the work performed during the evaluation, include errors found or any exploitable

vulnerabilities discovered during the evaluation. Note: This is a key difference between

CMVP and CC. The ETR must be submitted in two formats; one includes sponsor proprietary

information, the second is an abridged format that excludes the proprietary information. This

is the report that will be made available to users.

Both require that the Laboratory test

F. Choice of the evaluation program

The selection of evaluation program for the vendor depends on

The type of product (e.g. is it a cryptographic algorithm only (FIPS) or an implementation

of a cryptographic algorithm where the functioning of the algorithm must be tested (FIPS)

or another type of product that implements a cryptographic algorithm in a system (CC and

perhaps FIPS, but sometimes not).

The target market. Does the market require a specific type of certification.

Vendors cited market requirements as their guidance on choosing to certify a product and which

certification schema to use. In the U.S. the FIPS standard is required for U.S. Federal

government agencies and is often specified for state agencies as well. FIPS is also

140

well-recognized in commercial security markets. Thus, many products are FIPS certified in the

U.S. and it is commonly sought by vendors who wish to market to government organizations.

The CC is less well-known and is regarded by vendors as

“it’s European” so they do not seek it unless they are required to do so to meet a

market requirement

“It’s too expensive”

However, the CC program is growing as attention is focused on the security of national defense

systems (which have recently become subject to a new set of Federal Government

requirements) and are now going to be CC certified. Other Federal Systems will not be

required to be CC certified, but the number of products certified under the program (for

inclusion in these Federal systems) is expected to grow.

G. Reuse of results

NIST and the laboratories are making efforts to ensure that most, if not all of the FIPS test

results can be reused for a CC certification. An evaluation of this issue by the Canadian CSE

concluded that the results are “sometimes” usable. To some extent, the reusability is in the

format of the documentation, not the test itself.

Because a PP under the CC schema can refer to FIPS certified cryptographic modules, the

results of the FIPS certification can be submitted as evidence in the CC certification. If a

system being certified includes FIPS certified products, that certification is recognized in the

CC schema. To the extent possible, the results of the test performed during the CMVP

certification process for a cryptographic module can be submitted with the CC certification, if

the same testing is required. Both NIST and the laboratories that perform the certification

testing are attempting to ensure dual use of the test results where it is appropriate.

The results of any tests performed for a CC evaluation, if they were the same as the

conformance testing that must be performed for a FIPS certification, could be submitted to the

CMVP. The tests must be consistent with the evaluation level or certification level sought for

the product. The report format and the laboratory opinion would be different documents, but

testing results could be reused, as long as the tests were equivalent. CMVP and NIAP are

attempting to ensure that the costs are manageable for vendors.

141

It is important to note that in the U.S. cryptographic modules are more likely to undergo FIPS

certification before the vendor attempts a CC certification, in part because the CC process takes

so much longer and is so much more expensive. Furthermore, the market in the U.S. currently

emphasizes the FIPS certification, not CC.

II. Comments on the parallel operation of CC and CMVP

The CMVP program and FIPS Security Requirements are not substitutes for a CC evaluation.

Nor does a CC evaluation substitute for a FIPS certification. As NIST states

“The Common Criteria (CC) and FIPS 140-1&2 are different in the abstractness and

focus of tests. FIPS 140-1&2 testing is against a defined cryptographic module and

provides a suite of conformance tests to four security levels. FIPS 140-1 describes the

requirements for cryptographic modules and includes such areas as physical security,

key management, self tests, roles and services, etc. The standard was initially developed

in 1994 - prior to the development of the CC. CC is an evaluation against a created

protection profile (PP) or security target (ST). Typically, a PP covers a broad range of

products.

“A CC evaluation does not supersede or is a substitute for a FIPS 140-1&2 validation.

The four security levels in FIPS 140 are not intended to map directly to specific CC

EALs or to CC functional requirements. FIPS 140 is the current de facto standard for

cryptography and we are not aware of any other standard (developed in the US or

worldwide) that is comparable. Also, there is no document that correlates CC

functionality to FIPS 140-1&2 functionality. Therefore, a CC certificate cannot be a

substitute for a FIPS 140-1 certificate.”

Nonetheless, the latest release of the FIPS 140 standard, FIPS 140-2, incorporates references to

the CC: In defining Security Levels under FIPS 140-2 NIST states

“Security Level 3 allows the software and firmware components of a cryptographic module to

be executed on a general purpose computing system suing and operating system that

meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1) and (emphasis added)

142

is evaluated at the CC evaluation assurance level EAL2 (or higher) with the additional assurance requirement of an Information Target of Evaluation (TOE) Security Policy Model (ADM-SPM.1).”

To this extent, NIST has embedded the requirement for CC evaluation of the operating

environment for the modules certified under the CMVP.

Even if a country has a CC program, it still needs some means of evaluating cryptographic

algorithms.

A. Advantages

The advantage of the CMVP process is that it is a specific conformance certification. It

ensures that a certified cryptographic product meets specific requirements and is tested to

ensure that it works according to those requirements whether the product is tested to an

algorithm (AES, Skipjack, RSA, TDES, SHA-1, etc) for software and chips, or the

implementation of an algorithm in a product to FIPS 140-1/2. Customers have the confidence

that modules certified to the algorithm or to the same security level under FIPS 140-2 will work

as described.

The CC program, while not offering the user the ability to easily and directly compare certified

products, looks at a broader set of products than cryptographic module products and it examines

the implementation of the cryptographic module within a product without excluding the

security of the rest of the product-where FIPS 140-1/2 describe a boundary around the

cryptographic module, CC does not. CC does, however, reference algorithm standards within

Protection Profiles and Security Targets, and evidence of a certified algorithm used in the

product can be “inherited” to the system level.

The CC program has made accommodation for recertification of products when they are

updated with new versions. When a vendor makes minor changes to a product, the evaqlution

facility will perform a “delta” analysis between the new security taget and the original security

target (if it changes) to determine the impace of changes on the analysis and evidence from the

original evaluation. The evaluation facility should not have to repeat analysis perviousl

conducted where requirements have not changed or bveen impacted by changes in other

requirements.

143

B. Issues and constraints

The CVMP approach-conformance to a predefined security requirement-while useful for

comparison of one product to another, also can have perverse affects on product development.

There are two issues with this approach:

1) Design only to the standard. Product developers have been known to design

only to the standard as defined in order to make a product “pass the test” but have

ignored security vulnerabilities not covered by the standard. This means that the

end-user must understand which among a variety of FIPS products will be better for

his application. Furthermore, in FIPS 140-1 certain requirements could be

interpreted differently (even at the same security level) and result in widely different

implementations. Such differences have become the objects of marketing claims

against one’s competitors. The NIST solution for unclear interpretation of the

standard is to issue Implementation Guidelines, which essentially become a part of the

standard and are included in the standard in its regular update process after public

comment.

2) Designing to the retiring standard. During the phase-out period for FIPS 140-1,

which had less stringent requirements, NIST received a flood of applications for

certification under the expiring standard. During this time, the NIST review process

extended to about 2 months because of the backlog of applications. Today, NIST

certifies only to FIPS 140-2, but until the government declares that products must

meet FIPS 140-2, and only 140-2, to be used in government systems, the FIPS 140-1

products can be sold to government agencies. This problem will likely occur again

in 4 years as the FIPS 140-3 (or similar update) occurs.

The CC is not subject to such problems yet, but may have a similar problem with pre-defined

Protection Profiles and their interpretation and updating. The CC schema is too new to know if

preapproved PPs will have similar problems although the NIST representatives believe that

their security requirements are sufficiently general and not proscriptive, that they will not be

as difficult to update or as subject to adverse interpretation as FIPS was.

Other factors inhibiting the CC Schema from Adoption

1. The expense of the CC process inhibits its wide adoption. Vendors are reluctant to

undergo the expense of this process unless they believe that a sufficient market for the

144

product exists to recover the investment in the certification. Thus, if a government

requirement does not establish a sufficient marketplace for a CC product among either

government agencies or commercial companies (as a way to limit liability for security

breaches, as the Graham Leach Bliley Act and HIPPA, and some SEC rules may have

established in the U.S.), the vendor may focus solely on commercial applications.

2. The cost of CC certification inhibits smaller companies from applying for certification

for products. Small startup companies are unlikely to have the funds available for

expensive review processes. We know from history that smaller companies have not

applied for FIPS certification of products simply because of the expense and they knew

they would have to modify the product some to get certification. If either schema

becomes a defacto requirement in the broader commercial marketplace, this will inhibit

innovation and development of new innovative products.

3. As a result of the length of time it takes for a CC certification, companies believe that it

inhibits the “innovation” process and the rapid development of “new” products. This

issue also impacts FIPS certified products. Some vendors will not seek FIPS

certification for every new version of the product (expecially for new minor features),

but will maintain support for the FIPS certified version and sell that version to

government agencies, commercial organizations choose to order either the FIPS

certified versions or they can opt to assess the potential security impacts of the changes

and order the new version.

4. In addition to the slowness and expense of the process, the CC schema can be

confusing for customers. Much like FIPS, customers must also look at the evaluation

level of the product – EAL1 and EAL5 have very different security. Customers must

also select carefully and understand that they must compare the Security Targets of

different products. A product certified under one Security Target (ST) is not directly

comparable to a product certified under another ST. This requires that the purchaser

be sufficiently knowledgeable about security to perform this comparison.

Procurement staff must have assistance from technical specialists. This problem of

customer confusion can be alleviated somewhat if products are certified against

approved and adopted Protection Profiles and have the same or similar ST, but the

development of PPs is proceeding somewhat slowly, and vendors may still choose to

develop their own ST’s without referring to a PP.

145

C. Solutions

The solution for updating the FIPS 140-2 standard may be more frequent publication of

guidelines. NIST is currently working on its first set of guidelines for FIPS 140-2. These are

not available at the time of this report. NIST has pointed out that “a standard cannot be a

moving target.” Thus, changing the standard each time a vulnerability is discovered defeats the

purpose of having a standard.

Cost control is being addressed by NIST & CSE by attempting to reuse prior results of testing

under FIPS 140 and CC.

1. FIPS test results can be submitted with the work package for CC of the same product

assuming that the same laboratory is used.

2. CC products that are modified can undergo a modified evaluation process that looks

only at the changes in the ST of the product and verifies that they do not affect how the

product meets the original ST for the original product.

3. If CC certified products are used in systems that are being evaluated under the CC, the

system inherits the CC certifications of the individual components, making it important

to select components that are at or above the evaluation level the vendor is attempting to

achieve. These components are evaluated for the implementation in the system, but

not individually.

III. Merit and Problems on CC/CMVP Certified products

1) If the vendor has the products that both CC and CMVP certified, what dose the vendor benefit

from these products?

Vendors get products certified according to their view of the marketplace for those products and

what the market’s requirements are. For example, increasingly the financial industry is upgrading

the requirements of their security products. The industry is beginning to view using certified

products as a means to meet government requirements for the protection of customer information

and as a protection against lawsuits for intrusion and access to customer information. (This is a

peculiarly American problem that is unlikely to drive markets in Asia.) In Europe, the acceptance

146

of the CC schema is more widespread, so vendors aiming at European markets are having their

products evaluated.

In some minor ways, companies will find that undergoing the CC process will improve their internal

engineering habits and process controls. They may find that their engineering costs decline as they

develop better configuration management controls and practices. But this will be a costly way of

imbedding these practices into the company.

2) If the vendor wants to have their products both CC and CMVP certified, what are the problems

that the vendor will face (have)?

In the case that reusability (relationship) between the result of CC certified and that of CMVP

certified exists, it become easy for the vendor to get certified, I think.

This happens with many CC products now. I don’t see an issue here. To the extent that the

vendor can find a laboratory that can perform both evaluations, they are better off. The staff will

know both the company and the product and they will not have a long learning curve to repeat.

Laboratory testing is more easily reused if the same laboratory performs both services.

IV. Reuse of FIPS 140-1 and FIPS 140-2 results in CC

There are a couple of problems for CC and FIPS “integration”. The first is that the FIPS

requirements do not map directly to the Common Criteria schema. NIST’s CMVP attempted to

create a mapping and they ended the project because it was not successful. NIST states “However,

we are looking at FIPS 140-1&2 test data to be submitted as part of a CC evaluation. The hope is

that the tests will not need to be repeated.” They report that they are trying and they will do what

they can to make the test results acceptable, where relevant, to the CC certification. This statement

is posted on the NIST website on the FAQ page, and was again mentioned by NIST managers during

interviews.

To some extent, CC is driven from Europe and they are not “friendly” to suggestions from the U.S.

governing body even though the U.S. is far ahead in crypto standards.

The Communications security Establishment (CMVP Canada) has made the following

analysis of the comparison of FISP to CC.

147

CC Assurance Class FIPS 140-1 FIPS 140-2

Configuration management Partially met Partially met

Deliver and operation Not met Partially met

Development Met with interpretation Met with interpretation

Guidance documents Partially met Partially met

Life cycle support Not met Not met

Tests Met with interpretation Met with interpretation

Vulnerability assessment Partially met Partially met

The CSE concluded that the FIPS 140-1/FIPS 140-2 results can be reused in a CC

evaluation if the following conditions are met:

The Certificate is valid for the exact version of the TOE/TOE component

cryptographic module and

The operating system configuration is consistent with the evaluated configuration.

According to this analysis, it is possible to reuse some of the test results as long as they are

interpreted for CC reporting. Where FIPS is conformance testing, CC is evaluation, so the

final report needs rewriting.

Problems 1) In the current situation on CC/CMVP, the vendor who will have their products

certified to both CC&CMVP, should take much cost to both certification.

This is true. There is a significant cost, see my notes that using a single laboratory

accredited to perform both FIPS on cryptographic modules and CC on the system level will

save considerable money. If the same staff perform both evaluations, they will have

familiarity with the product, review the same item (that might occur in both evaluations)

one time rather than two times, and can gain as much efficiency in documentation as they

can.

It is advisable for a vendor of a cryptographic module to obtain FIPS certification before

attempting the CC evaluation. In many ways, the FIPS process will help somewhat to

prepare for the CC evaluation.

Countermeasure 1)

NIST is making some efforts to reduce the costs of parallel testing. Significant cost

reduction could be obtained in publishing clearer document formats for vendors to follow.

Much of what the laboratories and other consultants seem to do is recasting existing

148

documentation into the format acceptable to NIST and NIAP for both programs. This

could be improved according to the vendor personnel that we interviewed, by having NIST

provide more guidance on the documentation standards.

NIST has engaged in promotional and educational activities. NIST has produced many

documents introducing the CC schema; they ran training sessions for the first few years to

introduce the CC to vendors and consumers of security products. NIST also co-sponsors

conferences on CC.

NIST is also developing and adopting Protection Profiles for which vendors can develop

Security Targets and products.

Note: The NIST document “Certificate Issuing and Management Components Family of

Protection Profiles” is 119 pages long. This document deals only with the Protection

Profiles for Certificate Authorities and no other products. The entire FIPS 140-2 document

is only 61 pages including appendices and change notices. The actual text of the FIPS

140-2 standard is 44 pages.

Problem 2) In the current situation on CC/CMVP, the vendor has little experience

and less intention for CC certification to their products.

Countermeasure 2)

NIST is providing guidelines and other information. NIAP (National Information

Assurance Program is the CC organization in the U.S. It is a joint venture between NIST

and NSA. NIAP is currently published guidelines for government agencies, These are

available on their website. (See note above about training programs.

It is not NIST’s charter to decide what requirements the Federal government computing

environment shall adhere to. This is the task of Congress, or by default, each agency of the

government. The Congress has recently passed legislation requiring CC certification for

all National Security Agency computer systems and any that contain evidence used in

national security. (They gave me the name twice but I couldn’t understand what he was

saying and I have not been able to find this legislation in any news sites or the

Congressional Record. However, this was from the head of NIAP, Ron Ross, so it is

undoubtedly true. ) As a result, CC is being promoted by the government, but only for

government computers and, this an evaluation at the system level, which is different from

the FIPS level, but implies CC evaluated products. Note that CC refers to “appropriate

standards” for the certification of crypto algorithms and modules. So CC relies on FIPS to

149

a major extent for testing crypto modules.

See below for the definitions of Key management and key access under the CC.

The Cryptographic Operation in the CC is defined as follows:

FCS_COP.1 Cryptographic operation

FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic operations] in

accordance with a specified cryptographic algorithm [assignment: cryptographic

algorithm] and cryptographic key sizes [assignment: cryptographic key sized] that meet

the following: [assignment: list of standards which can include FIPS].

Cryptographic Key Access in the CC is defined as follows:

FCS_CKM.3 Cryptographic key access

FCS_CKM.3.1 The TSF shall perform [assignment: type of cryptographic key access] in

accordance with a specified cryptographic key access method [assignment: cryptographic

key access method] that meets the following: [assignment: list of standards].

The Protection Profile for Certificate Issuing and Mangement Components refers to and

requires cryptographic modules that are certified to the FIPS 140-2 standard.

V. Recommendations regarding the parallel operation of FIPS 140-2 certification and a CC

certification program s in CC

There are several key points that must be emphasized at the outset when considering how to combine

these programs.

1) FIPS 140-2 is a conformance testing approach. It specifically defines the testing

requirements for certification under the program and defines the security surrounding the

implementation of cryptographic algorithms (that are FIPS defined algorithms) to ensure

that the algorithms work properly and that the implementation is secured against common

problems and some common threats, and that the implementation provides a specific level

of operational security (user authentication, passwords, audit trails that are protected from

tampering, key management, etc.) The cryptographic module in a FIPS 140-2

implementation has specific boundaries and the process does not specify features or

functions or test the product outside of those boundaries.

FIPS 140-2 is required only for government consumers. It is not required for commercial

150

customers; but it is required for commercial enterprises working with the government.

2) Common Criteria is based on best practices and is an evaluation of claims that a product or

system makes in terms of the security functions of the system. In only some cases, does

not specifically address cryptographic algorithms or crypto modules as a separate entity

from the balance of a product. A single CC Protection Profile has been written for smart

cards, and another was written for Certificate Authorities and adopted by CC authorities in

the U.S. and Europe. In both cases, these Protection Profiles refer to specific FIPS approved

algorithms and in some cases specifically to FIPS 140-2 standards or to a “list of standards”

of which FIPS 140-2 may be one.

Please remember that NIST attempted to rewrite the FIPS 140 standard into CC language and

terminated the project after the document had grown to

Although specific Protection Profiles for specific types of products exist, they do not exist for all

products in the security space. This, were Japan to wish to combine the goals of these two

programs, CMVP and CC, it is possible to do so under one umbrella organization. While the goals

of the two might seem incongruent, there are several overlapping duties of the CMVP and the NIAP

(which controls CC in the US) that are illustrative.

1) Laboratory accreditation: NIAP works with the NVLAP to accredit laboratories and other

types of organizations to perform CC evaluations for submission to NIAP for approval and

certificate issuance. CMVP works with laboratories to accredit them for performing FIPS

140-2 certifications (and other FIPS standards for algorithms). This work could easily be

combined.

2) Defining testing requirements. One of the duties of CMVP is defining the Derived Testing

Requirements for FIPS 140-2 and keeping this document up to date. NIAP has a subgroup

that is also defining testing and evaluation requirements for CC certification. These

activities could overlap. In fact, at NIST many of the personnel who worked with CMVP

are now part of the NIAP program.

3) Combine the Certification Authority. While the CMVP personnel are narrowly defined in

skills, their knowledge would add considerably to an evaluation of a more generalized

system (knowing vulnerabilities and risks, key management, etc.).

4) Redefining a modern computing environment. One of the key criticisms of the FIPS 140-2

standard is that the defined computing environment for testing is very old and can no longer

be purchased. This needs to be updated.

5) Develop a method to examine the FIPS 140-2 certified product outside of the original

environment. The FIPS 140-23 certificate does not “carry forward” and the test results are

151

not valid for use in a CC evaluation if the product is not installed in EXACTLY the

environment it was tested on originally. If a series of “deltas” could be determined (how to

determine what different vulnerabilities a new environment imposes), this might shorten the

testing requirements and allow for the reuse of certain test results with the CC context.

6) Adopt the FIPS into the CC Protection Profiles where relevant, but meet the requirements

without a separate certification. Use the testing approach and the specification of the

standard, but only with respect to a CC certification. (The testing would mostly have to be

redone anyway.)

7) Examine the differences in coverage (See table for the comparison of FIPS 140 and CC

and reinsert it here) and add some missing elements to the FIPS process so the testing and

documentation are reusable.

8) Work with the CC to define more Protection Profiles to cover more types of security

products with families of Protection Profiles to map against the different levels of the FIPS

140 (this was done in the Smart Card Protection Profile). If PPs are well defined, vendors

will have more incentive to design to meet the requirements of a specific protection profile

rather than create a separate Security Target.

9) To promote this generalized CC (with a cryptographic conformance test); require products

sold to government meet specific protection profiles. Do not allow separately defined

security targets for these product areas. This will also make it easier for procurement

officers to compare products. It is very time consuming for a procurement officer to

compare different STs when there is no governing PP, or the vendor has chosen not to

conform to the who PP..

10) Create document templates for vendors. These will assist vendors in creating the

appropriate documentation in the appropriate format for submission to the certification

authority. Apparently, some considerable expense is incurred by vendors using consultants

to “clean up” their documentation. This is unnecessary if proper guidance is provided.

In a closing comment. FIPS is actually a rather inexpensive testing and certification process. CC

is much more expensive. Thus, attempting to perform crypto module verification within a CC

environment is going to place a heavy financial burden on vendors. There is no way around it

because the CC requirements are much more extensive than FIPS requirements (for such items as

configuration management, life cycle management, etc.). This will have two negative effects:

Slow down product development; confuse the customer. This were discussed in my earlier answer

to this same section.

152

添付資料 F. 調査項目 2 分析結果 (原文)

II. Gap Analysis between Single-crypto-algorithm implementation and Multi-crypto-algorithm in the e-government systems 1. System Design a. Design cost

Design cost is increased when using multiple encryption algorithms rather than a single algorithm.

However, if the multiple crypto decision is made at the beginning of the design or specification

phase, the cost factor is not double because the design team will understand from the outset that the

system will use multiple algorithms, thus the design approach taken will likely be modular and

provide the ability to change algorithms, implement new algorithms, and the like. If such a design

approach is not used, the cost of switching algorithms can be doubled.

At the design phase, the team abstracted the cryptographic operations to a high level and all of the

underlying algorithm specific operations were at a low level (final, if they had not done this, adding

a second algorithm would have been much more difficult. It would have required significant

changes in the code.

Banking System: The cost impact on this design was minimal. The design included the

development of a “crypto library” that was called by the banking system. If a new algorithm was

required, new library elements could be added. We estimate the additional cost, when multiple

cryptos are imple, adds about 10% to the design cost.

Postal System: The cost impact on the Postal System was minimal. The system is required to

identify the correct key from a database and use the verification module for that key. The algorithm

is identified in the clear in the Secure Hash in the indicia. The Postal System operations decided to

implement three FIPS approved signature algorithms (DSA, RSA and ECDSA) and allow a vendor

to implement its own algorithm if it could be shown to be secure. The risk of the cost of design and

implementation for any other algorithms is a risk for the vendor; the vendor must pay the postal

service for implementing a proprietary algorithm. This likely adds about the same cost, or 10% to

the cost.

b. Selection of Crypto-products with single or multi-crypto-algorithm

For any crypto product, there are multiple risks that must be addressed in the selection of vendor

products. These are:

1) Vendor will go out of business and the product will no longer be supported.

153

2) A Vendor specific product will be compromised, for example a smart card implementation

will be hacked.

3) If interfaces are not standard, you can become more dependent on a single vendor. If you

don’t use standardized interfaces, you will have to rewrite code. If you have different

interfaces for different vendors, will increase the probability of errors in coding to handle

different interfaces. Standardized interfaces are reviewed, so they wouldn’t have the

same vulnerabilities of proprietary interfaces. Standard interfaces are “tested” by use and

abuse; vulnerabilities are more likely discovered by widespread usage.

4) Interoperability problems may exist between products using the same algorithm in different

vendor implementations. In the case of the banking system the legacy mainframe

implementation of DES and TDES was different (padding was different) in the IBM

implementation.

In the banking system: see above 3) use of multiple crypto approaches solves, and choosing

products during the design phase, we specified the interfaces so they needed to provide a standard

interface to the devices. This makes it easier to

In the Postal System, the selection of the crypto system or products was determined by the PSD

vendors. Each vendor could select from among 3 FIPS approved algorithms.

c. Vulnerability Addressed In System Design

Banking System Risks Addressed by the System Design:

Risk: Unauthorized entities: Mutual Authentication

Description: In many instances, strong mutual authentication is required to assure that both of two

parties in an exchange are legitimate. For example, this frequently occurs during the exchange of a

shared secret key (e.g. communication session keys)—where the sharing is intended to occur strictly

between two specific entities.

Impact: Failure to enforce strong mutual authentication procedures, where it is required, can lead to

the unintentional and often undetectable compromise of shared-secret keys.

Risk: Replay Attacks

Description: In a typical replay attack, a valid interaction is intercepted by the attacker and

subsequently resubmitted.

Potential Impact: Successful resubmission of messages can lead to erroneous authentication or

154

redundant transaction processing

Risk: Recovery of Residual Keying Material

Description: Unless explicitly overwritten, keying material (e.g., keys, key parts, PINs/passwords,

etc.) may be left in released memory space.

Impact: If another process can gain access to the memory before it is overwritten, then it would have

direct access to these critical items.

Risk: Compromise of Crypto Algorithms-Cryptographic Strength

Description: Determining the cryptographic strength of the employed algorithms and their

corresponding key lengths is a fundamental requirement for establishing the resulting system

security models strength. Furthermore, the correctness of these algorithms implementations must

also be rigorously verified.

Impact: If weak algorithms or key lengths or faulty implementations are incorporated in the system,

the system’s security model is likewise diminished.

Risk: Single-Component Dependence

Description: During the system design and implementation phases, time/cost-to-market pressures

increase the risk of making a system too dependent on specific external resources (e.g., crypto

algorithms, key lengths, vendor products, etc.).

Impact: In general, system designs that do not incorporate common practices to isolate/insulate their

dependence on external resources are at substantial risk of high migration costs should the resource

fail or otherwise become obsolete.

Risk: Impersonation of Critical External Services

Description: Many of the current cryptographic providers (both software and hardware) utilize share

external resource such as dynamically linked libraries (DLLs) and hardware drivers. In many

instances, the authenticity of these resources is not adequately verified.

Impact: Replacement of these resources with subversive versions can result in result in complete

compromise of both confidentiality (e.g., capture of plain text data) and data integrity (e.g., digital

signature always verifies).

155

Risk: Revocation Latency

Description: In all systems, there is a potential for latency between the time when an entity’s (e.g.,

user, application, device, etc.) rights are revoked and the time when the enforcement of the

revocation becomes effective.

Impact: The risk of unauthorized access increases proportionally to the revocation latency time.

Risk: Key Confusion

Description: Given the variety of methods used to encrypt data and produce digital signatures there

is a risk of using the incorrect inversion key.

Impact: Using the incorrect inversion key may lead to the inability to decrypt and verify digital

signatures—leading to operational failures.

In the banking system, key confusion leads to operational failure (inability to connect and perform

transfers; inability to login). It does not lead to losses.

Risk: Inability to rapidly diagnose errors or incidents: Diagnostic Capability

Description: Within systems protected using cryptography, whether for confidentiality or integrity

purposes, the diagnostic functionality requires specific attention. In particular, the following two

areas are of concern:

• If confidential data is written to an error log, how is the audit record’s confidentiality

protected?

• How are cryptographic functions in the application debugged, since all the data looks like

garbage—even when it’s correct?

Impact: Failure to adequately address the preservation of confidentiality in the error logging process

may lead to inadvertent disclosures and potential system compromise (in the event that keys appear

in error logs).

Failure to address debugging requirements in the design, may lead to back doors (put in by

programmers) being inadvertently deployed in released versions

Unauthorized Users/Password sharing: User Authentication

Description: Although the need for individual user accounts and passwords has been a long-standing

and widely accepted best practice in general security arenas, most hardware devices (e.g.,

156

crypto-accelerator cards, smartcards, etc.) do not support multiple user or administrative (Security

Officer) accounts. Similar problems arise when shared resources (e.g., applications, services, etc.)

are assigned individual keys.

Furthermore, devices that are delivered in large quantities (e.g., smartcards) typically share a single

administrative password (or require no password at all).

Impact: Unless additional mechanisms are provided within the design, the resulting system

implementations (that use these devices) lead to sharing of authentication information (e.g., PINs,

passwords, etc) across users, as well as, devices.

Inability to track and investigate misuse--Audit functions


purposes, the audit functionality requires specific attention. In particular, the following areas need

special consideration:

• If confidential data is written to an audit log, how is the audit record’s confidentiality

protected?

• If the system’s requires high integrity, how is the audit records’ integrity maintained?

• If the audit functionality resides performs as an external service, how are auditable records

created (i.e., if all you can see is encrypted transactions, how do you create an audit log)?

• If cryptography is used for securing the audit functionality, which keys are used and how are

they controlled.

Impact: Failure to adequately address these issues may result in insufficient audit capability, loss of

confidentiality, or system compromise.

Postal System Risks:

Key risks that the design of the Postal System electronic franking was intended to address included

the following high level risks; these addressed the known risks of the then existing postal metering

system that was being replaced. . Note: As of 1988, meter fraud was costing the Postal System

about US $100 million per year and approximately 82,000 postage meters were reported stolen or

lost.

Risk: Fraudulently increasing the monetary value contained in the meter

Older metering devices were subject to tampering to fraudulently increase the value of the postage

balance in the registers in the meter; e.g. generate free postage value

157

Risk: Replay attacks

Existing postal indicia were easy to forge or copy. There was concern that the electronic indicia

could also be subject to copying.

Risk: Unauthorized use of postage meters

A legitimate postage meter may be used by an unauthorized person. User IDs can be implemented o

Under the design of this Postal System, individual IDs were optional for the equipment vendor. For

server based systems, . If all indicia were printed using a workstation type device that required a

unique user id and password, the ability of unauthorized users to print postage would be limited.

This system includes stand-alone PSDs that can be used by unauthorized persons. However, this

problem does not defraud the Postal System, it results in fraud against the company that leases the

PSD from a vendor. Thus, physical security methods can be used by the lessee to protect any

stand-alone PSDs from abuse.

Risk: Stolen postage meters.

The older postage metering systems could continue to print valid postage until the meter registers

were zeroed. While meter serial numbers were included in the indicia they printed, the postal

service was not equipped with the capability to inspect each indicium and reject mail pieces with

postage printed on stolen metering devices. The new system permits more rapid identification of

mail pieces from stolen PSDs.

Risk: Cryptographic Strength

Cryptographic strength is necessary to prevent fraudulent creation of indicia by removal of keys

from memory in the device. If fixed keys are used, and the key can be discovered, then fraudulent

transactions can occur..

Risk: Single component dependence.

By approving more than one algorithm, and by decentralizing the certificate authority (each vendor

infrastructure must have a centralized certificate authority) reliance on a single component was

avoided entirely in the postal system.

Risk: Key Confusion

As in the banking case above, key confusion can lead to operational failures.

In the postal system, key confusion leads to the inability to validate the authenticity of the indicium

on a mail piece. This can lead to monetary losses, but these can be reduced by holding the mail

158

piece and researching the authenticity using other data extracted from the indicium (such as the

sender’s identity).

Risk: Revocation Latency

Delay in revoking the certificate for a licensee using a PSD could result in the continued use of the

PSD by the licensee without proper authorization. The typical reasons for revoking a license would

be failure of payment method (when increasing the value in the PSD the credit card or other payment

method is refused after the trasaction is completed, or the license can be revoked for criminal

activity using the mail system (mail fraud) unrelated to monetary transactions with the postal

service.

Inability to diagnose fraud attempts: Audit trails in equipment


purposes, the audit functionality requires specific attention. In particular, the following areas need

special consideration:

• how is the audit record’s confidentiality protected?

• how is the audit records’ integrity maintained?

• how are auditable records created (i.e., if all you can see is encrypted transactions, how do

you create an audit log)?

Impact: Failure to adequately address these issues may result in insufficient audit capability, loss of

confidentiality, or system compromise.

2. System Integration or System Implementation a. Implementation or Integration cost

Discussion: The integration costs can be controlled by good design, good project management

(tasking order) and good design and engineering practices. Determining the number of builds of

the software and what functionality should be available and tested at each build is an important

means of controlling the complexity and cost of such systems implementations. It is critical in the

design of multi-cryptographic systems.

Clearly, design function cryptographic algorithms within a system will have an effect on the cost of

implementation. When multiple crypto systems are used, whether the implementation will have

significant impact will depend on what function they are being used for within the system. The

postal system example is a very simple example of multiple algorithms used within a system for

159

signing a message. The banking system example is a more complex case, and in this latter case, the

cost was considerably higher but the greatest cost different was seen in the testing and QA, which is

discussed below.

Banking System: In the writing of the code, there was little difference between the costs or risks

of coding for multiple or single crypto systems except that care had to be taken to ensure that the

design was properly implemented. The cost of creating the library elements for each different

crypto system is simply an additive cost factor (x number of lines of additional coding). In the

banking system, debugging/ QA had the major impact for implementation and integration.

Postal System: The implementation cost is likely very similar between a multiple crypto system or

single crypto system. The cost and risk of the implementation would impact the testing phase, but

here again, the difference is not significant. In the design phase, the database for verification of

signatures is defined, implementing the data structure and loading the database causes no significant

difference in the implementation. Testing had to occur for every vendor product, regardless of the

crypto system used by the vendor.

b. Test or Assessment

Discussion: Testing for multiple versus single crypto systems can cause a significant increase in

the testing and QA process for system development. In the single crypto system, only one

algorithm needs to be tested. In a multiple crypto environment all algorithms must be tested

separately and together. Depending upon the implementation, such as the banking system, the

testing may require considerable manual work (each test case tested with a manual activity rather

than with a simulation program, or transaction generator.)

Banking System: In the banking system, QA time scaled more than linearly, but not

exponentially, based on the number of algorithms. The time and effort was about squared by the

number of test cases. So, developing multiple test suites, testing each algorithm independently,

then for multiple implementations of the same algorithm, testing increases to n-factorial test cases.

For example, when testing TDES, data encrypted on a legacy mainframe had to be tested to see if it

could be decrypted on the desktop system, and when encrypted in hardware (2 separate

implementations) and in software. A large amount of time was spent on testing two-factor

authentication-smart cards plus user management—testing the physical insertion of the smart card

into a reader, a totally manual process, adds considerable time and cannot be automated easily. The

smart card/user management function had to be tested for all cases (add user, delete user, error

conditions, resetting passwords, and the like) required multiple manual insertions, time to read card,

160

etc. In addition, the smart card initialization is slow, and they wear out! Postal System: In the postal system, there was little difference in cost or risk to the postal authority for allowing multiple digital signatures. Each vendor uses a FIPS standard algorithm in a FIPS 140-1 certified implementation. Thus, the postal authority only needs to verify the signature for each vendor. They would need to test verification of each vendor’s implementation, regardless of whether they required only one algorithm, or permitted multiple signature algorithms as they have. c. Vulnerability in system Integration or Implementation

The integration of software and hardware components is of higher risk in multi crypto environments

due to the higher number of interfaces between software modules and hardware devices. This

impacts both the number of modules that must be coded and the testing of the integration. To some

extent, the inherent risks can be mitigated by good design and good management of the approach to

integration. For example, by defining the interfaces between devices and modules early in the

design phase (on any type of development project, not just those including cryptographic modules),

one can perform iterative testing of partially completed modules as the functionality is expanded.

Such approaches can ensure early identification of problems.

In the banking system, the project team defined a specific standard interface for the smart card, thus

ensuring some measure of interoperability between alternatives, and some measure of standard in the

testing. To ensure good project management and iterative testing (to surface problems early) the

project team executed approximately 10 builds with the client organization (for iterative testing) and

many more internal builds to test software interfaces.

The postal system integration risk was considerably lower. While the postal system had to integrate

all the allowable algorithms in its indicia decoding system, this process was relatively simple using

structured methods. Testing required testing each vendor’s equipment for readability of the indicia

and decoding of the indicia contents and verification of the signature. There were few problems

encountered.

3. System Operation a. Operational Cost

Discussion: Use of multiple cyrpto systems should not significantly affect the operational cost of a

system unless there are performance issues (speed of operation) that affect the efficiency of the

161

system (tho this should still not make a significant impact on costs.) Whether the system required

a single approach to cryptography, or would accommodate two algorithms does not really affect the

operational costs unless there is a significant licensing fee for the use of one of the algorithms.

(this has not proved to be enforced by the algorithm originators at this time.) Most of the cost

issues are addressed during the design phase.

Banking System: The operational costs of the banking system were minimal. Because the

multiple crypto approach was used in order to accommodate legacy systems while some were

upgraded and others were not, the use of the multiple crypto approach actually reduced the initial

startup costs in terms of the equipment required to implement the system. The dual authentication

would have been required in any event, and it did not use multiple algorithms to achieve its purpose.

Postal System: In the postal system, there is one result of allowing multiple crypto algorithms that

may eventually affect the cost of operating the system in a multiple crypto environment. Because

the vendors could select from among DSA, RSA and ECDSA, the vendors made their decisions

based on their cost and processing requirements and other proprietary technology or intellectual

property that they had.

In the current operation of the postal system, both the major vendors of the PSDs are using the DSA

algorithm. This algorithm is very quick to create a digital signature, but is relatively slow to verify

the signature. See table X below for comparison of speeds for signing and verifying signatures

with DSA and RSA.

Activity DSA RSA

Signature .03 sec 15 sec

Verification 16 sec 1.5 sec

As mentioned in the description of the postal system, the current vendors have selected DSA most

likely because of the speed of signing the indicia. This places the burden on the postal service

because of the slow speed of verifying the signature (the vendors would not expect their users to

wait 15 seconds for a meter to apply a signature; the old meters could handle dozens of mail pieces

per minute and users would not expect new electronic meters to operate more slowly. Thus, the

cost for the postal service to verify signatures in real time is limited by the processing power

available. It has not proven practical to implement either a distributed or centralized key system for

verification of the electronic indicia, therefore a sampling approach must be used on the high volume

mail pieces, e.g. letters. For the lower volume air express envelopes (with higher value) and

packages, a hand scanning system can be used. The speed is sufficient for verification of each of

these higher value pieces.

162

b. Impact on System Users (Government Agency, System Administrator, End User)

Discussion: Single and multiple crypto systems can be implemented in ways that can affect the

end user, the agency, or the operations or not depending upon their purpose and features. If

multiple crypto options are offered to the end user, then clearly configuring an system and selecting

and using the right crypto option may complicate the operation of the system; it might require a

higher level of user support; and it may introduce complications in key management for the agency.

However, the two examples shown here were deliberately designed to be transparent to the end user,

to simplify the administration fo the system administrator, and have minimal impact on the

government agency.

Banking System: For the end-user , the difference between the no crypto system that the new

system replaced, and the multiple crypto system as implemented, was only a matter of authentication

activity. Whether the system used multiple encryption or single encryption had no impact on the

end user. In the new system, the user had to insert a smart card and wait for a indicator light to

finish blinking. In both old and new systems, the user had a PIN. For the client system

administrator, there were some new operations added for managing smart cards, but there was no

difference for managing any of the cryptography. For the government banking system operations,

they had a custom CA to operate.

POSTAL SYSTEM: This postal system has significant impact on the end user. Because the PSD

can now update electronically, the user must learn certain system operations, but these are not a

function of whether the system uses a single algorithm or multiple algorithms. Configuration of the

devices-- which may employ multiple algorithms in the communication with the vendor

infrastructure, or not, a choice of the equipment manufacturer,- is performed at the factory. The

choice of algorithms may make a difference in the speed of operation of the unit, but other than the

time impact on the user, the choice is transparent. The users may or may not be required to enter

PINs into the PSD, or if a server based system, a password. If multiple users are using the same

device, the user may need to manage user IDs, but again, this is not a function of the cryptography.

The choice of multiple algorithms has a slight affect on the postal system; they must make sure they

test all new equipment and may need to perform a small amount of additional testing on the reading

of the indicia. Operationally the postal service will need to protect the database of public keys to

minimize interruption in verification processes.

c. Key Management

Discussion: Key management is complicated by using multiple algorithms. But again, this

163

depends upon the complexity of the functions that the multiple crypto or single crypto algorithms

serve. The example systems provide a wide variation in the complexity of key management.

Banking System: The design of the crypto-library uses a complex key management schema.

However, the complexity is due primarily to the dynamic linking of keys (i.e., user’s private key

used to access application-level key, then application-level key used to access additional keys, etc.).

The additional complexity of managing keys solely due to the multiplicity was negligible.

Assuredly, there is greater risk of key confusion, loss of keys, or improper key management in a

multi crypto environment. These can be overcome with careful design.

POSTAL SYSTEM: Issues in key management for the PSDs and postal system.

1) Key creation – is done on the FIPS device at the manufacturing plant when the PSD is to be sent

to a new user. Depending on the vendor implementation there may be multiple

2) Certificate generation & publishing—operation and management of the certificate authority is

by the vendors of the equipment, they could be using Verisgn certificates or could be operating

an Entrust or other CA . Some vendors use multiple certificates (factory, regional, root, that are

used during the setup of the device.

3) Key storage (in the PSD) is defined by FIPS 140-1; it must be secure and tamper resistant

4) Key agreement/exchange (session keys communication with Vendor) are used te ensure secure

communications with the vendor infrastructure for postal funds download transactions.

5) Key revocation; this activity would be by order of the postal service, not the equipment vendor.

Revokation would be affected at the postal service servers with notification to the lessor of the

PSD.

While all the types of keys used in the PSD seem complex, there are a static private key, a static

public key with a certificate, that are not changed until the license of the unit changes. Other keys

change with communications sessions and factory communications with the PSD for initialization

In ordinary operation, and from the postal service perspective, there is only one key for each PSD

the postal service must manage. This makes the multi crypto operations fairly straight forward for

the postal service. The risk is that the postal service would not receive the public key from the

vendor before the first mailpiece is received. But this is a procedural issue that is not affected by

the multiple crypto nature of the system.

CRL’s are handled in two way communications between the vendor infrastructures (CA)s and the

postal service. The postal service can order the revocation of a certificate as an administrative

matter (failure of funds transfer or criminal activity detected); vendors will revoke certificates based

on leasing arrangements with customers. Failure to keep the CRL up to date is one risk of the

operation

164

USPS receives the copy of the certificate for each PSD the vendor leases. From a key management

perspective for the postal service there is no difference between the use of multiple encryption

algorithms or single. An X.509 certificate carries with it all the necessary information, and the

message carries all the information to identify the correct key.

d. Incident Response

Discussion: Again, the incident repose varies with the purpose of the cryptographic

implementation and the type of incident. If the multiple crypto implementation is used in user

authentication, a quick response is required for the loss of keys, loss of a token to minimize the time

elapsed for an attack. If an algorithm is compromised, the system must be reconfigured to use a

stronger algorithm (if one is already implemented).

In the case of digital signatures, if a key is compromised, the certificate revocation process can be

invoked to stop the verification and validation of that specific certificate. If a signature algorithm is

compromised, a replacement for that algorithm must be impelemented.

In the case of multi crypto systems, if the incident involves a breach or compromise of the

cryptographic function, the system can still operate using the other algorithm. A single crypto

system would need to have a different algorithm implemented, which could take some time.

Banking System: The banking system had two features built in that were intended for incident

response.

1) Instantaneous revocation of all keys when a breach is detected (by user, or member bank level)

If a User looses a smart card, that specific card can be revoked instantly by member bank sysadmin

as soon as reported. If the security officer determines that the incident has resulted in a major

compromise, permission can also be revoked from central operations by revoking all keys for that

member bank and providing a new set of keys reinstalled from the central operations. Because

the user authentication involved smart cards, and would have notwithstanding the multiple crypto

algorithms used for communications with SNA, there is No difference between single or multiple

crypto implementation for this banking application..

2) The Design and implementation facilitated rapid replacement of algorithms and components.

For example, if TDES were broken, the application is capable of using AES faster than the

mainframes could be upgraded to provide AES. A Single crypto system can’t do this; it would

be non-operational for considerably longer

3) The banking system included an Integrity checker that operated on startup, much like FIPS 140

devices do. the integrity checker would check compliance of multiple parameters, resources,

software versions, digital signatures of dlls, signatures of registries, networking config

165

parameters, about 10 minute scan of system integrity, if not compliant, then access to all keys

was disabled, except for the security manager, who could make the determination if all keys

should be voided or not.

POSTAL SYSTEM: Fraud is detected in the postal system thru auditing of mail pieces history

and hand scanning of higher value mail pieces (express mail, packages, air express) real time.

If mail pieces do not validate properly, the postal service can investigate using the data that are

encoded into the indicia (sender information); however, if the certificate is not properly signed, the

PSD will not operate. If a certificate is expired, the PSD will not operate; it will only operate to

request a new certificate.

The monetary loss risk can be controlled by the postal service, thus the revocation latency is a less

serious issue for this system, and is not affected by the single or multiple crypto nature of the system.

e. Vulnerability of Operations

Discussion: The cited systems are subject to the same vulnerabilities as any e-government

operation. The vast majority of these “vulnerabilities” are not unique to a multiple or single crypto

system and have no unique response that would be taken for a multiple crypto system.

The key issue is the vulnerability of the cryptographic system. If a single crypto system is

compromised by the loss of keys or breaking the algorithm, then the system must stop operations

until new keys are installed, or a new algorithm is implemented.

In some incidences, the multicrypto system could continue to operate if ½ of the cryto were

compromised.

Banking System: Cryptosystems should be like pinball machines, tilt and they stop; if the

cryptographic system is compromised by loss or compromise of keys, they system should be stopped

until new keys are generated. During manual key loading, there is a risk that whoever enters keys

manually has access to it. In all instances, there were dual controls for manual key loading using

key splitting (they can see ½ of the key) and this was only during key loading for the CA system.

Most of keys were encrypted on floppy disks, then decrypted, then reincrypted. All keys were

encrypted or wrapped. These keys were used for the user and client authentication.

The session keys for the communications, which used three different algorithms depending on the

available method for the client, were session keys generated for one time use. This

Postal System: Operationally the postal system is vulnerable because not every piece can be

verified. It is designed this way. The postal system was not designed to be able to instantaneously

detect all attempts at fraud because the mail sorting equipment does not have the processing power

166

or speed to verify every electronic indica that is in the mail stream. The system was designed to

mitigate fraud using statistical sampling techniques to identify if fraud was occurring, at what rate,

identify specific “out of normal conditions of fraud” and identify fraudulent pieces for investigation.

In addition, the use of electronic indicia was intended to make fraud somewhat more difficult to

accomplish.

Operationally, key management poses some vulnerability if not accomplished correctly and if the

keys are not protected from disclosure. However, there is no operational difference in this

vulnerability posed by using more than one algorithm.

III. Measures to reduce risks in the e-government system with Multi-crypto-algorithm Risk mitigation is a combination of reducing both the scale (magnitude and duration of the

compromise) and probability of events. If we define scale of threat as the value of the compromise

(one participant) or of low value. Compromise of one key does not affect the other keys or other

users. The design can limit the duration that a compromise can exist. In this section we discuss

the risk mitigation factors used in the multi-crypto implementations for the systems under discussion.

We include the risks from part 1 above for the banking system and postal system.;

1. Unuathorized entities: mutual authentication

2. Replay attacks

3. Recovery of Residual Keying Maerial

4. Compromise of Crytpo Algorithms

5. Single-componenet Dependence

6. Impersonation of Critical External Services

7. Revocation Latency

8. Key Confusion

9. Inability to rapidly diagnose errors or incidents: diagnostic Capability

10. Unauthorized users/Password sharing: User authentication

11. Inability to track and investigate misuse: Audit functions

12. PS: Fraudulently increasing the monetary value in registers:

13. PS: Unauthorized use of meters; user authentication

14. PS: Stolen meters; revocation latency

Where a vulnerability applies to both systems , they will be discussed together. Where it applies to

only one system, it will be mentioned that it does not apply.

167

1. Reduction of Threat Scale Risk 5: Single Component Dependence

Reducing the dependence on a single component reduces the scale of the threat should a component

fail, be compromised or simple be outdated or no longer supported by the vendor (or the vendor

could go out of business and the component could not longer be available. This is a single point of

failure problem. With crypto algorithms, the algorithm can be compromised, but it won’t fail, per

se, but the implenmentation could be compromised

Single Crypto Systems:

In the case of vendor products, much of the dependence can be mitigated by selecting vendor’s that

support industry standard interfaces (e.g., PKCS#11)—if the vendor product fails, for whatever

reason, then another vendor that supports the standard interface can be substituted with minimal

impact.

In the case of cryptographic toolkits, call to the vendor’s direct interface (APIs) should be

encapsulated in as generic manner as possible—thereby reducing the amount of code changes

required to replace toolkits. A comparison the APIs that are available from various vendors is

recommended in order to determine an appropriate level of encapsulation.

In the case of cryptographic algorithms and key lengths, these should be parameterized to the largest

extent possible (i.e., compilation preprocessor variables)—thereby reducing the migration costs to a

simple parameter change and rebuild of the application.

Multi Crypto Systems:

Requiring vendors to support industry standards facilitates the inclusion of multiple products, since

the interfaces will remain (fairly) consistent.

Designs that are designed and implemented to support multiple crypto algorithms and key lengths

provide dynamic flexibility thus reducing dependency on a specific algorithm or key length.

However, the design and implementation of the logistical control for selecting and managing

multiple algorithms and key-lengths will increase the initial time/cost-to-market.

Banking System: The system used a standard interface for the smart card impelemtation. This did

not affect the part of the system that used multiple algorithms. In that case, the system was

designed to work with a single vendor network protocol, but one that was used by the legacy systems

168

in the banking application.

Postal System:

The postal system was designed to support multiple vendors of PSDs and multiple offerors of

electronic franks over a network, e.g. Stamps.com. In addition, the vendors of PSDs were required

to design their equipment to meet the FIPS 140-1 standard for the cryptographic module

implementation. This approach reduced the risk that any single vendor will have its

implementation compromised. Having multiple vendors reduces the risk that all vendors will be

compromised at the same time, even though the vendors might be using the same algorithm.

In addition, the postal system design flexibility provide the opportunity for the agency and

commercial organizations to develop “new products” or new delivery methods for postage value that

would be less likely to occur if the initial design did not provide this flexibility in algorithms and key

lengths.

Risk 7: Revocation Latency

Revocation latency issues are issues of threat scale and to some extent threat probability (the

shorter the window, the lower the probability that an attacker will successfully penetrate the

system or gain access to keys. If the latency period is short, the attacker’s damage is

minimized.


A classical example of long latency periods is in the propagation of certificate revocation lists. These

occur due to the need to balance certificate verification performance against acceptable risk. Any

system design should strive to minimize this latency to the fullest tolerable extent. Furthermore, this

design should be capable of perform this revocation of rights remotely (i.e., not need to access

potential captured systems or devices).

Multi Crypto Systems

Although the specific low-level methods of revocation enforcement may vary within multi-crypto

systems, the operational design model should be developed in a manner that is independent of the

particular algorithms or devices utilized.

Banking System:

In the Banking System case study, the revocation of user rights was performed directly on the

systems that the user had access and resulted in instantaneous revocation effectiveness. The

revocation of mainframe access rights was enforced by invalidation of a master shared-secret key

169

and again was instantaneously effective.

Postal System:

The USPS system is subject to revocation latency, but the PSD operation is disabled if postal value

registers are zero, or if a timer mechanism has not been reset by an audit. This manages the

potential monetary loss to the postal service when a user license is revoked. The postal service has

implemented a systematic CRL (Certificate revocation List) process.

In the postal system case, the statistical auditing function is designed to minimize the value of

the attack (high value transactions are verified with higher frequency to detect fraud faster).

Stolen meters can have certificates revoked as soon as they are reported to the vendor and the

vendo notifies the postal service.

Inability to rapidly diagnose errors or incidents: Diagnostic Capability

Single Crypto systems:

The following two options are the most prevalent methods used to maintain confidentiality of

logged:

• Encrypt all logged error messages using a key assigned to the diagnostic entity, or

• Not write sensitive information into the error logs.

In order to mitigate risk of releasing systems with “back doors”, careful attention should be given to

controlling the introduction of code intended for strictly debug use.


Using multi-crypto significantly compounds the necessity to programmatically enforce diagnostic

methods. However, once appropriately addressed, the complexity increases only slightly over

single-crypto implementations. (This of course presumes that the Key Confusion issue has been

sufficiently resolved.)

Banking System: In the Banking System case study no sensitive information was written to the

error logging facility. Restricting the creation of error logging through the use of precompiler macro

functions programmatically enforced this implementation goal. This option was chosen primarily

due to “right to privacy” reasons.

Furthermore, all access to keys required for debugging were similarly restricted using precompiler

170

macros. Access to these “back door” macro functions was also included in the quality assurance test

suite (failed if present).

Postal System:

Because the PSDs are FIPs 140 certified devices, they perform conformance routines on startup and

error conditions noted have specific responses. Other diagnostic capabilities are vendor specific

implementations and not necessarily required by the postal system.

Inability to track and investigate misuse: Audit functions

Single Crypto Systems

Assuming that the system is PKI-enabled and that a key-pair has been created for the audit entity, the

following procedures may be used:

• To preserve confidentiality, audit records can be encrypted using the audit entity’s public

key.

• To maintain high integrity of the audit records, each record can be signed by the user

(entity) being audited.

• For practical reasons, all audit functions should be migrated to reside within the

application’s “realm of clear-text”.

Similar methods can be used for non-PKI-enabled systems, but particular care is required in order to

prevent the unauthorized access of keys belong to the separate participants (i.e., prevent access to the

audit key by the user and visa versa).


In systems that utilize multiple algorithms or key-lengths, the key management scheme is increased

with respect to complexity. However, if auditing is considered during the design and implementation

of the scheme, the additional overhead can be minimized

Banking System: In the Banking System case study all transactional auditing was performed in

the pre-existing mainframe applications.

Postal System: the PSDs are designed to FIPS 140 and have the required auditing functions. The

Postal services has required additional auditing capabilities to contain information about updates to

the protected registers for account information, number of pieces franked, total value of postage

created, value remaining. Audit trails of changes to these register values are in protected areas of

memory and within the PSD crypto boundary so that they are protected by the tamper resistant

171

housing..

2. Reduction of Threat Probability Risk 1: Mutual Authentication

Single Crypto: Failures in the implementations of strong mutual authentication have been a

historical problem that has impacted numerous systems (e.g. early versions of Kerberos, 802.11 WEP,

SNA key exchange, etc.).

More recently, the use of encrypted tunnels as a means of providing protection for otherwise

insecure legacy protocols has led to similar failures. In Man-in-the-Middle in Tunneled

Authentication Protocols, Asokan provides specific examples of how failures can occur when legacy

protocols are secured using secure tunneling techniques.

Many of the potential problems can be avoided by using methods that have been evaluated and

published (e.g., FIPS 192—as illustrated FIPS 196 Mutual Authentication diagram that follows this

table)). In cases where these standard methods are unsuitable, the proposed method should be

thoroughly evaluated, by qualified crypto-analysts, in order to avoid faulty implementations.

Multi Crypto:

Using multiple cryptographic methods to implement mutual authentication may require using a

variety of schemes to perform this function.

The cost for design and implementation of multiple schemes typically scales in additive manner with

some additional costs incurred for determining which scheme should be used and key management.

Provided that the individual schemas used are by themselves secure, little additional security risk is

incurred—since mismatched schemas should fail to authenticate. However, operational failure risk

increases due to potential for mismatches

Banking System:

For example, in the Banking System case study, the FIPS 196 standard was implemented to provide

authentication between PKI-enabled applications, and the SNA key-exchange (corrected version)

was used when communicating with legacy mainframe systems.

172

Postal System:

This is an issue between the vendor and the customer and the vendors’ equipment uses other

encryption methods and shared secret keys to initiate communications for postage value

downloading and other operations. For example, the ASCOM Hasler system us

Risk 2: Replay Attacks:

Single Crypto:

Since the replay attack exploit’s success does not directly involve compromise of the

crypto-algorithms, it can be successfully used against any encryption or digital signature algorithm.

Typical countermeasures utilize the inclusion of additional and unique information in the protected

data, and then perform subsequent verification of this data during processing.

For example, in the Banking System case replay attacks are addressed in several areas, including:

• Posting of redundant financial transactions is defeated by the inclusion of unique

transaction numbers

• Erroneous authentication is defeated through the use of a challenge and response process

that includes a randomly generated number.

Communication sessions are protected using a unique session key that is established using a

randomly generated number

Multiple Crypto:

The use of multiple cryptographic algorithms may require additional and distinct implementations to

defend against replay attacks—potentially impacting design and implementation costs as well as

extend the time-to-market.

Banking System: Since the replay attack exploit’s success does not directly involve compromise

of the crypto-algorithms, it can be successfully used against any encryption or digital signature

algorithm.

Typical countermeasures utilize the inclusion of additional and unique information in the protected

data, and then perform subsequent verification of this data during processing.

For example, in the Banking System case replay attacks are addressed in several areas, including:

• Posting of redundant financial transactions is defeated by the inclusion of unique

transaction numbers

173

• Erroneous authentication is defeated through the use of a challenge and response process

that includes a randomly generated number.

Communication sessions are protected using a unique session key that is established using a

randomly generated number

Postal System:

In the postal system case, replay attacks are a known vulnerability. Statistical methods are used to

evaluate the mail stream to detect potential replay attacks and identify abusers. High value

transactions may be checked more frequently and identified in real time as validation occurs. Use

of multiple algorithms makes no difference in the approach to mitigating replay attacks.

Risk 3: Residual Keying Material:

Description: Unless explicitly overwritten, keying material (e.g., keys, key parts, PINs/passwords,

etc.) may be left in released memory space.

Impact: If another process can gain access to the memory before it is overwritten, then it would

have direct access to these critical items.


All keying material should be overwritten with random byte-strings upon termination of their use.

One method of providing this functionality is to include it in the destructor of the object—when the

object is released either explicitly or implicitly, the critical information is overwritten. Special

attention should be paid when pointers (or auto-pointers) are used to reference these critical

values—to ensure that the overwriting process is correctly invoked.

In the Banking System case study a high-level key manager object was implemented to manage the

numerous keys that were in simultaneous use (e.g., multi-threaded applications, communication

services, etc.). The overwriting of keying material was performed in the underlying toolkit and again

within the Crypto Library (in the event that the toolkit was replaced).

Multiple Crypto:

Provided that the overwriting of keying material is performed during the release (destructor) or the

low-level key object, no additional risks are introduced through dynamic switching of keys (this, of

course, assumes that the key is released during the switch).

Postal system: This problem does not apply because the keys remain in the FIPS 140-device in

hardware.

174

Risk 4: Cryptographic Strength:


Rigorous proofs of specific implementation strengths are difficult to obtain and are subject to debate.

However, when selecting an implementation there are several factors that should be considered:

• Has a community of experts subjected the implementation to scrutiny? This will ensure that

it is sound, in both the theoretic and practical sense.

• Does the algorithm have a published industry, government, or international standard?

Standardization alone does not provide strength—however, flaws and recommended

revisions are typically addressed more expeditiously.

Is there an independent certification program for the algorithm? This will ensure that the specific

implementation is correct.

Multiple Crypto systems:

In the case where the multi-crypto system utilizes only certified implementations, the resulting

confidence level will be reasonably high.

In the case where the system utilizes a mix of certified and “low confidence” algorithms, the ability

to dynamically switch to the certified algorithm (provide that this capability is included in the design

and implementation) may reduce the associated risk to an acceptable level.

Banking System: In the banking system, the system was designed to use low confidence algorithm

(DES) for a transition period while network equipment was being upgraded to TDES and AES.

Postal system:

In the postal system case, the use of multiple algorithms was viewed as a risk mitigating factor; if

one algorithm is broken, the entire system is not compromised. The strength of the cryptographic

algorithm is controlled by using FIPS standard algorithms with standard key lengths. Key lengths

could be increased to make cracking more difficult. If one of the algorithms is compromised, the

vendor can use another (some vendors implemented more than one algorithm in the hardware, but

use only one for operation of the system.)

Risk 6: Critical External Services


Where possible, all critical functions should be statically linked into the application (i.e., included as

part of the application rather than as a shared external resource).

175

In instances where this is not feasible, the resources authenticity should be verified prior to its use.

Multiple Crypto Systems

Where common APIs are provided for multiple interfaces (e.g., system includes two PKCS#11

devices) the naming APIs becomes problematic (due to the same API signature appearing in more

than one library).

The verification of multiple driver signatures also requires careful design consideration, since

multiple versions of each driver may be simultaneously deployed on various systems.

Banking System:

In the Banking System case study, the various vendors were required to provide static libraries

instead of dynamically link libraries. Furthermore, the hardware drivers were verified, during the

start-up of the application, using stored digital signatures.

Postal System:

The Postal system depends on external resources to the extent that updates and audit information

about individual licensees are updated to the postal service on a periodic basis as well as the version

of the algorithm used for the key. This information can be shared between postal sites and provides

key information to the postal service for fraud detection. Certain information about the sender’s

account is included in the indicia, thus verifying the signature and comparing dates, item counts, and

the like can detect fraudulent indicia.

By constraining signing algorithms to FIPS certified algorithms (and a FIPS certified

implementation of the algorithm) minimizes the chance that versions of the algorithm will be

compromised.

Risk 8: Key Confusion


One method to avoid key confusion is to provide all necessary inversion information along with the

data include sufficient information in the key exchange protocol (for session operations) or

supplemental data associated to the protected data (e.g., as prepended header information).

For example, the supplemental data provided for a signed and encrypted file might contain:

• Intended recipient identifier

• Signatory identifier

• Signatory’s Certificate (optional)

176

• Symmetric Encryption Mode (e.g., CBC, ECB, etc.)

• Initialization vector (preferable exchanged in an encrypted manner)

• Padding method

For shared secret key encryption, the associated information may include:

• Encryption Mode (e.g., CBC, ECB, etc.)


• Padding method

Multi-Crypto systems

For systems that utilize multiple encryption algorithms, the supplemental data provided for a signed

and encrypted file might be extended to contain:

• Intended recipient identifier

• Signatory identifier

• Signature Algorithm

• Signature Key Length

• Asymmetric Encryption Algorithm

• Asymmetric Encryption Key Length

• Signatory’s Certificate (optional)

• Symmetric Encryption Algorithm

• Symmetric Encryption Mode (e.g., CBC, ECB, etc.)


• Padding method

For shared secret key encryption, the associated information might be extended to include:

• Encryption Algorithm

• Encryption Mode (e.g., CBC, ECB, etc.)


• Padding method

Banking System

In the Banking System case study, all applicable information was associated with the encrypted

data—either during the key exchange, or as supplemental file data.

In the postal system case, the identification of the required algorithm and user identifiers are

included as supplemental information with the digital signature in the Secure Hash.

177

User Authentication

Single Crypto Systems:Shared authentication information (PINs and passwords) in general weaken

any security model due to:

• Lack of accountability

• Distribution and revocation issues

• Difficulty in detecting compromise


Authentication methods vary considerably between hardware models—both within a single vendor’s

product line and between vendors.

Many devices accept the PIN/password at the API level—leading to frequent use of keyboard as the

PIN entry device. This exposes the PIN to interception as it is transmitted from the application to the

device driver and to the physical hardware.

Other units use a Protected Access Path (PAP) that frequently utilizes a directly attached keypad.

While these PAP-enabled devices are generally considered to be more secure, the ability to include

support for multiple users is not universally supported and precludes the additions of methods

implemented in the Banking System case study.

Banking Systems: Within the Banking System case study, the following mechanisms were used to

provide strong user authentication:

• To eliminate sharing of passwords between users, the system’s design utilized a

key-hierarchy—where each user was issued their own key pair, which was used to access

the shared resources’ PIN.

• To eliminate shared administrative PIN/passwords across devices, when each device was

initialized:

1. The administrative PIN/password was reset to a randomly generated byte-string

2. The new PIN/password was encrypted using the public key of the local security

management (second level in the hierarchy).

3. The encrypted PIN/password was written to the publicly readable area of the card.

Postal System:

In the postal system server based implementations, users are individually authenticated, but the

digital signature can be common to groups of users as the signatures are specific to companies, not

178

individual users. PSDs can also be configured for multiple users and use unique PINs for each user,

but this is not required.

Fraudulently increasing the monetary value in registers:

Single crypto systems and multi crypto systems would have the same vulnerability.

This risk applies only to the postal system PSD devices. Because the postal system has required

FIPS 140 certification of the crypto modules in the PSDs to general level 2 and physical security

level 3, the crypto modules are tamper resistant, and for environmental threats (EMI and temperature

attacks) they are implanted and tested to security level 4. Single and multi chip cryptographic

implementations must include zeroization circuitry for the tamper response. thus, the postal service

has used a state of the art approach to securing against this threat.

3. Response that should be conducted in the case that vulnerability in the system detected. Discussion: There have been no significant security incidents reported for either system that are a

function of the multi-crypto nature of the system. All systems are subject to operational incidents

and vulnerabilities as enumerated above.

See section 2.3 above: Incident Response for the discussion of mitigating actions.

If one crypto algorithm is compromised, the opertions need to ensure that the compromise of one

algorithm does not affect the operation of the other algorithm. For example, if a system uses both

AES and TDES, if TDES is compromised and TDES is used in the KMS to manage all AES keys,

then the entire system is compromised and must be shut down until the key management is

converted to AES and new keys are loaded to the system. Multi-crypto systems must be designed

so that the crypto algorithms and keys are independent of the other algorithms. Such cascading

effects are a vulnerability.

179

添付資料 G. 調査項目 3 分析結果 (原文)

Trends in Cryptographic implementation technology in North America

I. Trends

Experts interviewed for this analysis note that new attack methods are discovered in several

ways:

1) Systematic attack analysis at academic sites such as those at University of California

Berkeley (Doug Tygar), Carnegie Mellon University, Stanford University (Dan

Boneh) and Cambridge University in the UK (Ross Anderson and Marcus Kuhn).

These sites are specifically studying algorithms, fault induction, and tamper resistant

hardware.

2) Private laboratories such as Cryptography Research (Paul Kocher), which identified

Differential Power Attacks and has developed testing systems for DPA which the

company will sell only to accredited laboratories, a limited number of commercial

security product vendors, and governments (NSA and NIST).

3) Government agencies specifically, NIST, the National Security Agency, and the

Department of Defense.

4) Criminal enterprises. Ross Anderson of Cambridge has reported discussing attack

methods with “hackers” and discovered one individual in possession of a $100,000

electron microscope. The hacker reported that this was provided by his “clients” the

Russian mafia. The “victims” must deduced the methods used after the fact. Sometimes

the methods are published on the Internet by the hackers, so constant monitoring of the

Internet is necessary.

NIST does not have a group systematically monitoring new attack methods and assessing how

these attacks impact the FIPS 140 standard. They rely on periods of public comment before

updating the standard. Should a critical event occur that points out a serious weakness in a test

method or a security requirement, NIST issues a guideline, but does not update the standard.

They may modify the test method to mitigate a problem in test methods. The specific test

methodology for FIPS is not provided to the public or developers, the test protocols are

available only to the laboratories. Thus, designers cannot design to pass specific testing

protocols.

180

NSA has a dual role. NSA is participating in NIAP and the CC in the U.S. NSA manages the

Validation Body, where NIST develops the Protection Profiles and testing methods. NSA

conducts its own testing and hacking activities to discover vulnerabilities in security products.

However, this work is very secret. All the researchers could discover is that NSA regarded

EAL 1-4 , currently the top level that products may be evaluated against in the CC, as those

levels appropriate to withstand the hacking and scanning tools, techniques, and scripts that

you can find on the Internet. When they start evaluating to Level 5 and 6, the testing is likely

to be performed within the NSA. These testing and hacking methods are very secret.

a. Non-invasive Attacks

Non-invasive attacks, also know as Side Channel attacks, have continued to mature in terms of

efficiency and sophistication. This group non-invasive attacks consists of a variety specific

techniques including:

• Differential Power Analysis (DPA) – where the circuitry and data information is

extracted by analyzing the differences in power emissions between data-dependent

computational test samples. This is due to the binary encoding of data, where one wire

is used to propagate one bit, results in power consumption proportional to the number

of state changes. Since data transmission along a bus consumes considerable power due

to wire capacitance, bus activity can be observed as the Hamming weight of the state

changes.

• Differential Timing Analysis (DTA) – where the circuitry and data information is

extracted by analyzing the differences in execution timing between. These attacks are

affected by the counting clock cycles asynchronous processing units require to complete

operations on known operand data.

• Fault Induction (FI) – where abnormal conditions in the devices operational

components (e.g., clock speed, voltage, etc.) are artificially induced in an effort to

extract information, bypass security controls, or perform abnormal execution.

• Electromagnetic Analysis (EMA) – a variation of DTA where focused (40µm) antennas

are used to determine power distribution and consumption during the execution of

data-dependent computational test samples.

These types of attacks are particularly troublesome since the lack of tampering evidence results

in a relatively low probability of detection. However, it should be noted that these attacks also

rely heavily on the collection of samples where:

• The number of samples in a set is large—often in the hundreds of thousands

181

• The device is enabled to perform normal/typical computational executions (i.e., either

the device perform authentication prior to operation, the authentication codes are known

to the attacker, or the authentication security measures have been circumvented.)

• The physical proximity between the device and the attacker’s equipment is relatively

close

b. Countermeasures for Non-invasive Attacks

Device vendors have recently implemented various countermeasures to mitigate the risk of

these non-invasive attacks. These include:

• Diffusing of data-dependent timing—this is typically achieved by introducing randomness

into the execution process through using both delays in the circuitry, superfluous operations

(e.g., dummy memory accesses), and removal of operation optimization (i.e., forcing the

operation to use the worst-case performance methods—for example, in an addition

operation, always performing a carry, even if the carried value is 0).

• Elimination of data-dependent power consumption—using a combination of alternative data

encoding (e.g., 1-of-2 or 1-of-4) to achieve self-timed circuit designs, minimization of

variations in wire lengths in the circuits bus layout to reduce wire loads, minimization of the

variations in logic complexity, insertion of random operations, and removal of operation

optimization.

• Proactive Fault Detection—where out of range conditions are detected prior to performing

the requested operation and then taking proactive measures to protect the device (e.g.,

zeroing keying material, administratively locking the device, etc.)

It is important to note that the introduction of non-deterministic behavior is, by itself, not an

adequate protection against non-intrusive attacks, since averaging the results from repeated

operations can filter out the corresponding variations.

Furthermore, care should be taken to enable any counter measure that is controllable through

programmatic means, since the default factory behavior may be set to the disabled state.

As the sophistication level and diversity of non-intrusive attacks increase, so will the

requirements for effective countermeasures. It is important to remember that these reactive

countermeasures can not prevent successful attacks—only increase the level of difficulty, time,

and money required to successfully exploit the underlying vulnerabilities.

182

c. TEMPEST

TEMPEST attacks are specialized non-intrusive attacks that are based on the interception and

analysis of emissions that result from the inadvertent telemetry systems formed naturally by

electronic devices and propagated via natural physical elements (antennas or wires). This signal

propagation makes TEMPEST attacks particularly threatening since the attack can be effectively

conducted over moderately long distances.

While there are numerous descriptions appearing in open (unclassified) literature of TEMPEST

attacks against computer systems and peripherals, few specifically addresses attack scenarios against

cryptographic devices.

However, in Soft Tempest: Hidden Data Transmission Using Electromagnetic Emanations, Kuhn and

Anderson suggest that such attacks may be possible, given sufficient time, effort, and funding. This

conjecture would require the attackers to:

• Intercept and isolate the target devices emission signal

• Identify either periodic or predictable (e.g., execution of known code) signals

• Filter the signal to determine operational behavior

• Reverse engineer the targeted sensitive from the operational behavior

In The EM Side–Channel(s):Attacks and Assessment Methodologies, Agrawal, Archambeault, Rao,

and Rohatgi (IBM Watson Research Center) describe their advancements of TEMPEST-style attacts

that allow them to successfully attack cryptographic implementations of block ciphers such as DES,

RSA on chipcards and SSL Accelarators and proprietary. While much of the success of these attacks

depended on the ability to control the processing (e.g., performing a DES encryption on two data

elements that differed only by one bit) in a laboratory environment, the evolution (in terms of

sophistication) of TEMPEST-base attacks by a well-funded and determined adversary poses a real

and serious threat.

For systems performing high value cryptographic operations (e.g., root certificate authorities),

traditional TEMPEST countermeasures, , are strongly advised. This countermeasures includes:

• Signal strength reduction—using circuit redesign to reduce unintentional emanations and

the use of shielding to reduce the strength of compromising signals.

• Signal information reduction—using various randomization techniques and frequent key

refreshing to reduce the effectiveness of statistical analysis.

183

II. Relevance to CMVP

a. Current status of CMVP evaluation for the cryptographic implementation technologies

This is part of the process for updating the standard. It is on a five year cycle. When

vulnerabilities are noted, there are guidelines for implementation issued to cover these

vulnerabilities and guidelines for the labs for testing. Once every five years they update the

standard, and these guidelines are incorporated. In the case of vulnerabilities, the guidelines can

be considered in certifying. They can divert from this process in a severe case. This was

discussed with Easter.

b. Future requirement for CMVP in regard to the cryptographic implementation technologies

184

添付資料 H-1. CC 評価機関の一覧

CC の基準下において、現在米国で 7 個所、カナダで 3 個所の研究所が CC の評価機関として認

定されている。以下はその概要である。55

＜アメリカ国内＞

Arca Systems, Inc. (NVLAP Lab Code 200429-0)

10220 Old Columbia Road

Suite G-H

Columbia, MD 21046

Tel: 410.309.1780 Sales: 571.434.5913 Fax: 410.309.1781

URL: http://www.arca.com

Point of Contact: Diann Carpenter or Lee Kestler

Booz Allen Hamilton Common Criteria Testing Laboratory (NVLAP Lab Code 200423-0)

900 Elkridge Landing Road

Suite 100

Linthicum, MD 21090

Tel: 410.684.6602 Fax: 410.309.6475

URL: http://www.bah.com

Point of Contact: Steven Rome

COACT Inc. (NVLAP Lab Code 200416)

9140 Guilford Road, Suite L, Columbia, MD 21046

Contact: Mr. Bill Hebler

Tel: 301-498-0150 FAX: 301-498-0855

E-mail: [email protected]

URL: http://www.coact.com/

Computer Sciences Corporation (NVLAP Lab Code 200426)

132 National Business Parkway

Annapolis Junction, MD 20701

Tel: 240-456-6001 Fax: 240-456-4522

URL: http://www.csc.com

Point of Contact: Lisa Kash and James Fink

185

http://www.arca.com/

mailto:[email protected]


http://www.bah.com/


http://www.csc.com/ttap



CEAL: a CygnaCom Solutions Laboratory (NVLAP Lab Code 200002)

7927 Jones Branch Drive, Suite 100 West McLean, VA 22102-3305

Contact: Mr. Miles Smid

Tel: 703-270-3542 FAX: 703-848-0985


URL: http://www.entrust.com/entrustcygnacom/labs/ceal.htm

InfoGard Laboratories (NVLAP Lab Code 100432-0)

641 Higuera St., 2nd Floor, San Luis Obispo, CA 93401

Contact: Mr. Tom Caddy

Tel: 805-783-0810 FAX: 805-783-0889


URL: http://www.infogard.com/

Science Application International Corporation (SAIC) (NVLAP Lab Code 200427)

7125 Columbia Gateway Drive

Suite 300

Columbia, MD 21046-2554

Tel: 410.953.6819 Fax: 410.953.6930

URL: http://www.saic.com/securebiz/cctl.html

Point of Contact: Robert L. Williamson Jr.

＜カナダ国内＞

CGI

1400-275 Slater Street, 14th Floor, Ottawa, Ontario, Canada K1P 5H9

Tel: 613-234-2155 Fax: 613-234-6934

Contact: Mr. Andrew Pridham


URL: http://www.cgi.ca

Domus IT Security Laboratory

Mailing Address: 2220 Walkley Rd Ottawa, Ontario, Canada, K1G 5L2

Contact: Mr. Laurie Mack

Tel: 613-247-5505 FAX: 613-739-4936


186

http://www.saic.com/securebiz/cctl.html


URL: http://www.domusitsl.com/

EWA-Canada LTD, IT Security Evaluation Facility

55 Metcalfe Street, Suite 1600, Ottawa, Ontario K1P 6L5

Contact: Mr. Paul Zatychec, Ms. Erin Connor

TEL: 613-230-6067 ext. 1227 FAX: 613-230-4933

E-mail: [email protected]; [email protected]

URL: http://www.ewa-canada.com/Default.php

187

添付資料 H-2. CMVP 評価機関の一覧

CMVP における NVLAP （National Voluntary Laboratory Accreditation Program）公認のテスト

CMT (Cryptographic Module Test) ラボは現在米国・カナダ内で 6 つ存在する。いずれも真に独立

したサードパーティ・テストラボであり、策定支援のためのテストを行うことは出来ない。以下は CMT

ラボの概要である。このうち Atlan Laboratories を除くほとんどの研究所が CC における評価機関を

兼ねている。56

Atlan Laboratories (NVLAP Lab Code 200492-0)

1340 Old Chain Bridge Road, Suite 401, McLean, VA 22101

Contact: Mr. Edward D. Morris

Tel: 703-748-4551 Fax: 703-748-4552

E-Mail: [email protected]

URL: http://www.atlanlabs.com

CEAL: a CygnaCom Solutions Laboratory (NVLAP Lab Code 200002-0)

7927 Jones Branch Drive, Suite 100 West McLean, VA 22102-3305

Contact: Mr. Miles Smid

Tel: 703-270-3542 FAX: 703-848-0985


URL: http://www.entrust.com/entrustcygnacom/labs/ceal.htm

COACT Inc. (NVLAP Lab Code 200416-0)

9140 Guilford Road, Suite L, Columbia, MD 21046

Contact: Mr. Bill Hebler

Tel: 301-498-0150 FAX: 301-498-0855


URL: http://www.coact.com/

Domus IT Security Laboratory (NVLAP Lab Code 200017-0)

Mailing Address: 2220 Walkley Rd Ottawa, Ontario, Canada, K1G 5L2

Contact: Mr. Laurie Mack

Tel: 613-247-5505 FAX: 613-739-4936


URL: http://www.domusitsl.com/

188

EWA-Canada LTD, IT Security Evaluation Facility (NVLAP Lab Code 200556-0)

55 Metcalfe Street, Suite 1600, Ottawa, Ontario K1P 6L5

Contact: Mr. Paul Zatychec, Ms. Erin Connor

Tel: 613-230-6067 ext. 1227 FAX: 613-230-4933

E-mail: [email protected]; [email protected]

URL: http://www.ewa-canada.com/Default.php

InfoGard Laboratories (NVLAP Lab Code 100432-0)

641 Higuera St., 2nd Floor, San Luis Obispo, CA 93401

Contact: Mr. Tom Caddy

Tel: 805-783-0810 FAX: 805-783-0889


URL: http://www.infogard.com/

189

添付資料 I. 用語

コモンクライテリア、CC (Common Criteria)

CC (Common Criteria)とは、情報システムやそれを構成するハードウェアやソフトウェアについ

て、目標とするセキュリティ保証レベルを評価基準に基づいて評価・認証し公開する国際規格

の名称である。米・英・仏等欧米先進諸国において、国防上の観点から実施されてきたもの

を、1998 年 10 月に国際共通化を図る為、CC を策定。1999 年 12 月「ISO/IEC15408 情報技術

セキュリティ評価基準」として国際規格化され、米・英・仏等欧米先進諸国を中心に 15 ヶ国

(2002 年 7 月現在)が加盟。日本は加盟申請中で、2003 年 4 月加盟予定。国際規格の為、あ

る国で CC に基づいて評価・認証された IT 関連製品は、協定に合意している国同士でも相互

に適用が認められている。

評価認証レベル、EAL (Evaluation Assessment Level)

評価保証レベルとは、製品やシステムが機能要件をどこまで保証しているかを表す尺度として、各

保証要件のサブセットという形で階層的にレベル分けしたものである。Common Criteria (CC) Part3

には７階層の評価保証レベル (EAL) が定義されている。

プロテクションプロファイル、PP (Protection Profile)

ユーザのセキュリティに関する要求仕様を記述した実装に依存しない文書。

セキュリティターゲット、ST (Security Target)

セキュリティ機能を実現する設計仕様を記述した文書。

評価対象、TOE (Target of Evaluation)

IT 製品/システムのセキュリティ機能、および管理者/ユーザガイダンス文書。

認証機関 (Certification Body)

企業に対して認証を行う機関を指し、認定機関 (accreditation body) によって認定された組織が

認証を行うことができる。

キーリカバリ (Key Recovery)

公開鍵 (非対称) 暗号における秘密鍵は復号化や署名生成に使用されることから、秘密鍵を紛失

してしまった場合、損害を被る恐れがある。そこで、秘密鍵をサーバなどに寄託 (Escrow) してお

き、鍵を紛失してしまった場合には、サーバに保管していた鍵を再度取り寄せる、といった方法が

考えられる。このように鍵を取り寄せることをキーリカバリ (Key Recovery) と呼ぶ。キーリカバリが行

われる場合、寄託サーバはパスワード認証などを行い、リカバリ要求者が正当なユーザである事を

190

確認する必要がある。2

FIPS 140-1, 2 (Federal Information Processing Standard)

暗号モジュール機器に関する米国政府標準評価制度。NIST(米国標準技術研究所)が策定した

米国・カナダにおいて機密情報を保護するセキュリティシステム内で利用される、暗号モジュール

が満たすべきセキュリティ要件を規定しているもの。情報の重要度を 4 つに分類し、これに応じて暗

号モジュールが満たすべきセキュリティ・レベルも最低レベル 1 から最高レベル 4 までに分類されて

いる。94 年に発表された FIPS140-1 では、セキュリティ要件としては暗号モジュールの設計と実装

に関わる 11 分野を網羅している。99 年 11 月に公開された FIPS140-2 ではセキュリティ要件に改定

が加えられ、新しい攻撃法に対処する対処に関する規定が追加された。

level 1：FIPS で定義している最低限のセキュリティ・レベル。一般的な PC に適用されてい

るような暗号モジュールに適用されているレベル。

level 2：暗号化モジュールに、不正アクセスされた場合に、侵入の痕跡を残せるような仕

組みを備えているレベル。

level 3：暗号化モジュールに、不正アクセスされた場合に、侵入の痕跡を残せるような仕

組みを備えている。レベル２に比べ、痕跡をより厳密に追跡できるような仕組みを備えて

いるレベル。特殊なハードウェア装置を使い、侵入があった場合にはデータを消去する

ような仕組みをもつ。

level 4：FIPS で定義している最高レベルのセキュリティ・レベル。温度の変化や電流の変

化等の環境の変動も検知できるような仕組みを導入しているレベル。一般的な市販製品

ではこのレベルの要求を満たしたものはない。

CMVP

CMVP (Cryptographic Module Validation Program) とは、FIPS 140-2 及びその他の暗号に基づ

く、米国 NIST とカナダ CSE が共同で運用する暗号モジュール認証プログラムのことであり、FIPS

140-1/-2 に適合と認証された製品は、両国の連邦政府によって機密情報または指定情報の保護

向けとして認証される。CMVP の目標は、認証済み製品の使用を促進すること、ならびに暗号モジ

ュールを装備した機器を調達する際に用いることができるセキュリティ測定基準を連邦政府に提供

することである。

CSE

CSE (Communications Security Establishment)とはカナダ国防省内に設置され、過去 50 年以上、

暗号技術、情報セキュリティ等の研究・開発を行っている通信安全保障機構である。CC Version2.1

の著作権をもつ 7 つの政府組織 ”the Common Criteria Project Sponsoring Organizations” の 1 つ

であり、NIST と共同運用する FIPS140 の評価・認定も行っている。

191

NIST

NIST (National Institute of Standards and Technology) とは、米国商務省(DOC)の一部門(Agency)

で、米国連邦政府機関の調達等に関連する国家的規格を制定する米国標準技術院である。CC

Version2.1 の著作権をもつ 7 つの政府組織 ”the Common Criteria Project Sponsoring

Organizations” の 1 つであり、CSE と共同運用する CMVP の評価・認定、また NVLAP (National

Voluntary Laboratory Accreditation Program)により、試験所の認定を行っている。

サイドチャネル攻撃

サイドチャネル攻撃(Side Channel Attack)とは、暗号演算中のデバイスから観測できる消費電力な

どの観測情報を元に、デバイス内の秘密情報（秘密鍵）を求める攻撃法である。観測情報と秘密情

報の間に強い結びつきがある場合に、攻撃は成功する。楕円曲線暗号は短い鍵長で高いセキュリ

ティを確保できることから、スマートカードのように性能の高くない計算環境にも適しているが、この

ようなデバイスに実装する場合、サイドチャネル攻撃に注意を払わなければならない。

耐タンパー技術

耐タンパー技術とは、広義の物理的セキュリティ技術の一つである。耐タンパー技術にはソフトウェ

アで構成されるものとハードウェアで構成されるものとがあるが、ハードウェアの場合は、半導体チ

ップなどの内部解析や改ざんを物理的及び論理的に防衛する技術で、チップ内部に強固で粘着

力の高いコーティングを施し、表面を剥がすと内部の回路が完全に破壊されるようにしたり、ダミー

の配線を施したり、電子的な攻撃に対しては公開鍵暗号法による認証を伴う暗号通信路（セキュア

コネクション）が形成された時のみデータの出し入れが出来るようにしている。課金を扱うＩＣカード

などで既に実用化されており実績もある。

テンペスト攻撃

テンペスト攻撃（TEMPEST Attack）とは、暗号モジュールからの電磁波的シグナルを解析するこ

とで、キー入力情報、スクリーン情報、暗号鍵などの重要セキュリティ情報を得る攻撃法である。ネ

ットワークケーブルを含む全ての構成物のシールドが必要とされる。

プローブ攻撃

プローブ攻撃（Probe Attack）とは、IC カードのパッケージを開封し、チップ表面のデータバスに

探針 (プローブ) を当て回路を動作させながらバス上のビットの変化を解析して秘密情報を得る攻

撃法である。

故障利用攻撃

192

故障利用攻撃（Fault Induction Attack）とは、暗号モジュールに故障を引き起こした状態で暗号

処理を行なわせ、その結果から秘密データを推定する攻撃方法である。

タイミング攻撃

タイミング攻撃（Timing Attack）とは、暗号デバイスの実行時間を測定することにより、暗号デバイ

スに格納されている秘密パラメータ (鍵) を求める攻撃である。

電力解析攻撃

電力解析攻撃（Power Analysis Attack）とは、暗号デバイスの実行時間に加えてその消費電力

から暗号処理内容に関する情報を得る攻撃方法である。

複数暗号アルゴリズム実装

複数暗号アルゴリズム実装には、基本的に以下の 2 つのケースを想定した。

システムに実装されている複数の暗号の中からユーザが使用する暗号を１つ選択

する場合

１つのシステム内に複数のアプリケーションが載っており、各々に別の暗号を実装し

ている場合

193

添付資料 J. 参考文献、参考資料 1 ActivCard http://www.activcard.com/ 2 Chrysalis-IT http://www.chrysalis-its.com/ 3 “Beyond FIPS 140-1: Essential Best Practices for Hardware Security Modules”, Chrisalis-ITS, Inc., March 22, 2002. http://www.chrysalis-its.com/news/library/white_papers/Beyond FIPS 140-1-best practices.pdf 4 “Evaluation, Validation and Certification: FIPS 140-2 and Common Criteria”, Chrysalis-ITS, Inc., December 12, 2002. http://www.chrysalis-its.com/news/library/white_papers/FIPS_CC_white_paper.pdf 5 Spyrus, Inc. http://www.spyrus.com/ 6 “NIST Handbook 150-20, Information Technology Security Testing—Common Criteria”, NIAP CCEVS Publications, April, 1999. http://niap.nist.gov/cc-scheme/HB150-20.pdf 7 Renaud Prestly, “FIPS140-2 & Common Criteria Security Evaluations”, June 4, 2002. http://www.expotrack.com/iccc/proceedings/pdf/proceed/english/track3/pr019_e.pdf 8 Certificate-Issuing and Management Components Family http://niap.nist.gov/cc-scheme/PPRegistry.html#cimc 9 Annabelle Lee (Director, CMVP), “FIPS 140-2 and the Cryptographic Module Validation Program (CMVP)”, March 26, 2002. http://csrc.nist.gov/cryptval/cmvp2002/proceed/CMVP2604.pdf 10 Hasler, Inc. http://www.ascomhasler.com/ 11 Annabelle Lee (Director, CMVP), “CMVP Status and FIPS 140-1 & 2”, March 26, 2002. http://csrc.nist.gov/cryptval/cmvp2002/proceed/CMVP2603.pdf 12 Randall J. Easter (NIST), “Testing to FIPS 140-2 Derived Test Requirements”, March 26, 2002. http://csrc.nist.gov/cryptval/cmvp2002/proceed/CMVP2606.pdf 13 Horlick, Jeffery; Lee, Annabelle; Carnahan, Lisa; National Voluntary Laboratory Accreditation Program, NIST Handbook 150-17 InformationTechnology Security Testing – Cryptographic Module Testing,June 2000, page 7-9. 14 Pamela Grannum (CSE), “The Re-use of CMVP Results use of CMVP Results within a CC

Evaluation within a CC Evaluation”, June 20, 2002. http://www.expotrack.com/iccc/proceedings/pdf/proceed/english/track3/pr025_e.pdf

194

http://www.activcard.com/

http://www.chrysalis-its.com/

http://www.chrysalis-its.com/news/library/white_papers/Beyond FIPS 140-1-best practices.pdf

http://www.chrysalis-its.com/news/library/white_papers/FIPS_CC_white_paper.pdf

http://www.spyrus.com/

http://niap.nist.gov/cc-scheme/HB150-20.pdf

http://www.expotrack.com/iccc/proceedings/pdf/proceed/english/track3/pr019_e.pdf

http://niap.nist.gov/cc-scheme/PPRegistry.html

http://csrc.nist.gov/cryptval/cmvp2002/proceed/CMVP2604.pdf

http://www.ascomhasler.com/




15「海外事例調査活動報告」、地方公共団体行政サービスオンライン化促進協議会調査部

会海外事例調査グループ、2001 年 9 月 21 日。 http://e-lg.jp/ga/C010_01_010921.pdf 16 松本泰 (NPO 日本ネットワークセキュリティ協会/セコムトラストネット株式会社)、「Identrus と e-Japan (電子政府) の PKI 技術」、Network Security Forum 2002、2002 年 11 月

15 日。 http://www.jnsa.org/active/fit2002/identrus.pdf 17 Dave Fillingham (NSA), “Bridge Certification Authority Technology Demonstration Phase 2”, Federal PKI Technical Working Group, August 2, 2001. http://csrc.nist.gov/pki/twg/y2001/presentations/twg-01-18.pdf 18 “Technology Interoperability Profile (TIP) for the BCA Interoperability Demonstration Phase II”, November 20, 2000. http://bcatest.atl.getronicsgov.com/docs/BCADemo2_TIPv1.2.doc 19 “Phase II Bridge Certification Authority Interoperability Demonstration Final Report”, November 2, 2001. http://bcatest.atl.getronicsgov.com/docs/BCA Phase II Final Report.doc 20 NTT 情報流通プラットフォーム研究所 http://www2.pflab.ecl.ntt.co.jp/ 21 Trust-CANP http://www2.pflab.ecl.ntt.co.jp/index/kenkyu/html/15.html 22 電子認証システム (CANP)、NTT 研究開発この一年 2000 年報。 http://www.ntt.co.jp/RD/OFIS/active/2000pdf/pf11.pdf 23 「情報流通プラットフォーム (2) －ネットワーク･セキュリティ－」、ビジネスコミュニ

ケーション 2001、Vol.38、No.8. 24 奥野琢人 (名古屋工業大学電気情報工学科)、「認証局パッケージ EasyCert の開発と評価」、

IC2000 プログラム、2000 年 11 月 2 日。 http://www.csl.sony.co.jp/ic2000/papers/S05_01.pdf 25 USPS (United States Postal Service) http://www.usps.com/ 26 "Information-based INDICIA Program, Performance Criteria for Information-based INDICIA and Security Architecture for Open IBI Postage Evidencing Systems (PCIBI-O)", USPS, February 23, 2000. http://www.usps.com/postagesolutions/_pdf/pcibo223.pdf 27 USPS, “Postage Meters (Postage Evidencing Systems)”, DMM Issue 57 plus Postal Bulletin changes through PB 22095, Febrary 6, 2003. http://pe.usps.gov/cpim/ftp/manuals/dmm/P030.pdf 28 USPS, Postage Meters

195

http://e-lg.jp/ga/C010_01_010921.pdf

http://www.jnsa.org/active/fit2002/identrus.pdf

http://csrc.nist.gov/pki/twg/y2001/presentations/twg-01-18.pdf

http://bcatest.atl.getronicsgov.com/docs/BCADemo2_TIPv1.2.doc

http://bcatest.atl.getronicsgov.com/docs/BCA Phase II Final Report.doc

http://www2.pflab.ecl.ntt.co.jp/

http://www2.pflab.ecl.ntt.co.jp/index/kenkyu/html/15.html

http://www.ntt.co.jp/RD/OFIS/active/2000pdf/pf11.pdf

http://www.csl.sony.co.jp/ic2000/papers/S05_01.pdf

http://www.usps.com/

http://www.usps.com/postagesolutions/_pdf/pcibo223.pdf

http://pe.usps.gov/cpim/ftp/manuals/dmm/P030.pdf

http://www.usps.com/postagesolutions/post_mtr.htm 29 USPS, Digital Postage Mark http://www.usps.com/postagesolutions/abotibip.htm 30 S/Goma http://www.sgoma.org/ 31 名古屋工業大学電気情報工学科岩田研、AiCrypto に関するページ http://mars.elcom.nitech.ac.jp/security/aicrypto.html 32 澤野弘幸 (株式会社オレンジソフト) 他、「GPKI 対応電子メールソフトのためのプラグ

イン開発」、平成 13 年度 IPA 報告書。 http://www.ipa.go.jp/security/products/fy13/report/H13-EG-Fin-4.pdf 33 １３情経第１１７５号、「複数 CA 製品を使用した相互運用性に関する調査実証実験報告書」、

IPA、平成 14 年。 http://www.ipa.go.jp/security/fy13/report/pki_interop/pki.pdf 34 13 情経第 770 号、「Crypto-API 仕様書」、IPA、平成 14 年 2 月。 http://www.ipa.go.jp/security/fy13/crypto/crypto_api/Crypto-API-Spec.pdf 35 佐伯正夫 (三菱電機株式会社) 他、「Crypto-API の開発」、IPA/ISEC、2001 年 6 月 12 日。 http://www.ipa.go.jp/security/products/fy12/report/H12-Mid-8-1.pdf 36「Crypto-API 検証実験報告書」、情報処理振興事業協会セキュリティセンター、平成 14年 2 月。 http://www.ipa.go.jp/security/fy13/crypto/crypto_api/Crypto-API-Report.pdf 37 IETF, S/MIME Mail Security http://www.ietf.org/html.charters/smime-charter.html 38 NIST Special Publication 800-XX, “Interim Draft Federal S/MIME V3 Client Profile”, NIST, December, 2001. http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf 39 Cryptography Research, Inc. http://www.cryptography.com/ 40 InfoGard Laboratories http://www.infogard.com/ 41 RSA Laboratories http://www.rsasecurity.com/rsalabs/index.html 42 Workshop on Cryptographic Hardware and Embedded Systems (CHES) http://islab.oregonstate.edu/ches/start.html 43 「平成 11 年度スマートカードの安全性に関する調査報告書」、IPA、平成 12 年 2 月 29 日。 http://www.ipa.go.jp/security/fy11/report/contents/crypto/crypto/report/SmartCard/sc.html

196

http://www.usps.com/postagesolutions/post_mtr.htm

http://www.usps.com/postagesolutions/abotibip.htm

http://www.sgoma.org/

http://mars.elcom.nitech.ac.jp/security/aicrypto.html

http://www.ipa.go.jp/security/products/fy13/report/H13-EG-Fin-4.pdf

http://www.ipa.go.jp/security/fy13/report/pki_interop/pki.pdf

http://www.ipa.go.jp/security/fy13/crypto/crypto_api/Crypto-API-Spec.pdf

http://www.ipa.go.jp/security/products/fy12/report/H12-Mid-8-1.pdf

http://www.ipa.go.jp/security/fy13/crypto/crypto_api/Crypto-API-Report.pdf

http://www.ietf.org/html.charters/smime-charter.html

http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf

http://www.cryptography.com/

http://www.infogard.com/

http://www.rsasecurity.com/rsalabs/index.html

http://islab.oregonstate.edu/ches/start.html

http://www.ipa.go.jp/security/fy11/report/contents/crypto/crypto/report/SmartCard/sc.html

44 「暗号技術仕様書 OK-ECDH」、日立製作所、Nov., 2001。 45 赤井健一郎、三澤学、松本勉「ランタイムデータ探索型耐タンパー性評価法」、情報処理学会

論文誌 Vol.43 No.8 p2447-2457、Aug., 2002。 46 D. Page, “Theoretical Use of Cache Memory as a Cryptanalytic Side-Channel”, Technical Report CSTR-02-003, Department of Computer Science, University of Bristol, June 2002. 47 “Cryptographic Hardware and Embedded Systems - CHES 2001” 48 桶屋勝幸、宮崎邦彦、櫻井幸一、「サイドチャネル攻撃を防ぐモンゴメリ型楕円曲線上の高速な

スカラー倍計算方法－理論的アプローチ」、情報処理学会論文誌 Vol.43 No.8 p2631-2643、

Aug., 2002。 49 FIPS PUB 140-1, “Security Requirements for Cryptographic Modules”, NIST, January 11, 1994. http://csrc.nist.gov/cryptval/140-1.htm 50 NIST Special Publication 800-29, Ray Snouffer, Annabelle Lee, Arch Oldehoeft, “A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2”, NIST, June, 2001. http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf 51 FIPS PUB 140-2, “Security Requirements for Cryptographic Modules”, NIST, May 25, 2001. http://csrc.nist.gov/cryptval/140-2.htm 52 Corsec, “Planning for FIPS 140-2: -- An Evolution of Security Requirements”, August, 2000. http://www.corsec.com/copy/pdf/140-2_whitepaper.pdf 53 “Derived Test Requirements for FIPS PUB 140-2, Security Requirements for Cryptographic Modules”, NIST, November 15, 2001. http://csrc.nist.gov/cryptval/140-1/fips1402DTR.pdf 54 Annabelle Lee (Director, CMVP), “FIPS 140-2, PKI, and PPs – Working Together ….”, May 13, 2002. http://www.expotrack.com/iccc/proceedings/pdf/proceed/english/track5/pr070_e.pdf 55 Common Criteria http://commoncriteria.org/ 56 NVLAP-accredited Cryptographic Module Testing (CMT) laboratories http://www.cse-cst.gc.ca/en/services/industrial_services/nvlap.html

197

http://csrc.nist.gov/cryptval/140-1.htm

http://csrc.nist.gov/publications/nistpubs/800-29/sp800-29.pdf

http://csrc.nist.gov/cryptval/140-2.htm

http://www.corsec.com/copy/pdf/140-2_whitepaper.pdf

http://csrc.nist.gov/cryptval/140-1/fips1402DTR.pdf


http://commoncriteria.org/

http://www.cse-cst.gc.ca/en/services/industrial_services/nvlap.html