暗号技術検討会
２００４年度報告書

暗号技術検討会
２００５年３月

目次
１．はじめに····································································· 1
２．暗号技術検討会開催の背景、構成員及び開催状況 ································· 3
２．１．暗号技術検討会開催の背景··············································· 3
２．２．CRYPTREC の体制 ························································ 3
２．２．１．暗号技術検討会··················································· 3
２．２．２．暗号技術監視委員会··············································· 4
２．２．３．暗号モジュール委員会············································· 4
２．３．暗号技術検討会メンバー················································· 6
２．４．暗号技術検討会開催状況················································· 7
３．暗号技術監視委員会活動報告··················································· 8
３．１．監視活動······························································· 8
３．１．１．活動の指針······················································· 8
３．１．２．監視状況························································· 8
３．１．３．暗号技術監視委員会開催状況······································ 10
３．１．４．国際学会等における発表の動向···································· 11
３．２．暗号技術調査ワーキンググループ········································ 15
３．２．１．擬似乱数生成系の調査············································ 15
３．２．２．ハッシュ関数の安全性調査········································ 17
４．暗号モジュール委員会活動報告················································ 20
４．１．暗号モジュール委員会活動の背景と目的·································· 20
４．１．１．暗号モジュール評価の標準化に関する国際動向 ······················ 20
４．１．２．暗号モジュールに対する攻撃に関する研究動向 ······················ 21
４．１．３．暗号モジュール委員会の活動目的·································· 22
４．２．暗号モジュール委員会開催状況·········································· 24
４．３．暗号モジュール評価基準及び試験基準の策定 ······························ 25
４．３．１．基準類の概要···················································· 25
４．３．２．国際標準への対応検討············································ 26
４．３．３．運用ガイダンス第 0 版の検討······································ 27
４．３．４．評価基準/試験基準第 0.1 版の作成 ································· 28
４．４．非破壊攻撃及び破壊攻撃に対する調査・研究 ······························ 29
４．４．１．評価用標準プラットフォームの検討方針 ···························· 29
４．４．２．評価用標準プラットフォームの作成································ 29

５．今後の CRYPTREC 活動について················································· 31
５．１．今後の CRYPTREC の活動目的及び活動内容 ································· 31
５．１．１．活動目的························································ 31
５．１．２．活動内容························································ 31
５．２．今後の CRYPTREC 体制··················································· 32
５．２．１．暗号技術検討会·················································· 32
５．２．２．暗号技術監視委員会·············································· 32
５．２．３．暗号モジュール委員会············································ 32
５．３．電子政府推奨暗号の監視················································ 33
５．３．１．電子政府推奨暗号の監視の基本的考え方 ···························· 33
５．３．２．電子政府推奨暗号の監視の具体的内容 ······························ 33
５．３．３．電子政府推奨暗号の監視の手順···································· 35
５．４．電子政府推奨暗号リストの改訂·········································· 36
５．４．１．基本的認識······················································ 36
５．４．２．基本的考え方···················································· 37
５．５．暗号モジュールに関する検討············································ 37【参考資料】
・「各府省の情報システム調達における暗号の利用方針」（平成 15 年 2 月）
・「暗号調達のためのガイドブック」（平成 15 年 3 月）

１．はじめに
最近のインターネットの急速な拡大に代表されるように、社会における IT 化の進展はめ
ざましいものがあり、インターネット人口普及率も 60%を超えている状況である。我が国政府においても、IT の活用による国民の利便性の向上や行政の効率化を実現するため、申請・届出手続のオンライン化等を推進しており、2003 年度末までに国の行政機関が扱う申請・届出等手続きの 96%がオンライン化されている。
他方、IT 化による利便性の増大とともに、新種ウィルスやサイバー攻撃、フィシング詐
欺など、これまでになかった新次元のリスクに直面しており、IT に対する脅威が増加しており、その姿も多様化している。このような環境の中、いかに IT の安全性・信頼性を確保するかという問題は、我々の社会が直面している喫緊の課題と言える。
政府としても、安全性及び信頼性の高い電子政府を実現するために、情報セキュリティの確保が不可欠であり、情報セキュリティ技術の基盤をなす暗号技術が重要であるとの認識を深めている。この認識は、2001 年 3 月に IT 戦略本部において決定された「e-Japan 重点計画」においても示され、さらに、同年 10 月に情報セキュリティ対策推進会議において「総務省及び経済産業省は、両省で実施している研究会の成果等も踏まえ、2002 年度中に「電子政府」における調達のための推奨すべき暗号のリストを作成し、これを踏まえ、各省庁における暗号の利用方針について合意を目指す」ことが決定された。
これに先立ち、2000 年度、経済産業省（旧通商産業省）からの委託を受けて、独立行政法人情報処理推進機構（IPA、旧情報処理振興事業協会）は電子政府で利用可能な暗号技術
を安全性および実装性など技術的な面から評価することを目的とした暗号技術評価委員会を設置するとともに同委員会の事務局を務めた。2001 年度からは独立行政法人情報通信研究機構（NICT、旧通信・放送機構）が同委員会の共同事務局として参加した。また、2001 年
度には、暗号技術評価委員会に加えて、総務省大臣官房技術総括審議官及び経済産業省商務情報政策局長が、暗号技術の利用に関し政策的な観点から検討を行うことを目的として、暗号技術検討会（以下、「本検討会」）を設置した。
本検討会は、電子政府で利用される暗号技術、国際標準化に関する暗号技術及び電子署名法等に基づいて利用される暗号技術の評価・調査研究、並びにその他暗号技術の利用等に関連する技術課題を検討対象としており、2002 年度には、それまでの検討及び評価を踏まえ、
電子政府推奨暗号リスト案を作成した。これを受けて、総務省及び経済産業省は 2003 年 2
月に「電子政府」における調達のための推奨すべき暗号のリストとして公表した。2004 年
度は、昨年度に引き続き電子政府推奨暗号の監視、電子政府推奨暗号の安全性及び信頼性確保のための調査・検討、暗号モジュール評価基準及び試験基準の作成のための調査・検討を行った。これらの結果をまとめた本報告書は、総務省及び経済産業省に対して報告するとと

1

もに、電子政府を構築する各府省関係者、及び一般の暗号ユーザの方々にも広く読んで頂くことを想定している。
なお、2004 年度の CRYPTREC 活動のうち、詳細な技術的事項については、暗号技術監視委
員会及び暗号モジュール委員会における議論を踏まえて、情報処理推進機構（IPA）及び情報通信研究機構（NICT）によってまとめられている「CRYPTREC Report 2004」を御参照頂きたい。
本検討会は、今後も引き続き、国民が安心して利用できる電子政府を構築し、運用していくために、暗号技術を監視し、評価するとともに、暗号モジュールに関する評価基準及び試
験基準を作成する等の活動を実施していく必要がある。このためには、CRYPTREC に関係する諸団体が一致団結して前進することが必要であり、今後とも関係者の方々の御協力を頂きながら、暗号技術検討会をはじめとする CRYPTREC 活動を積極的に推進していきたい。
末筆であるが、本検討会にご協力いただいた構成員の方々及びオブザーバとしてご参加頂
いた方々をはじめ、関係者の皆様に心から謝意を表する次第である。

2005 年 3 月
暗号技術検討会
座長 今井

2

秀樹

２． 暗号技術検討会開催の背景、構成員及び開催状況
２．１．暗号技術検討会開催の背景
高度情報通信ネットワークの安全性及び信頼性の確保は、我が国が目指す世界最先端のIT 国家構築の基盤となるものであり、国民一人一人が安心してネットワークを利用するための前提となるものである。高度情報通信ネットワーク社会形成基本法に基づく eJapan 重点計画-2004（2004 年 6 月 15 日

IT 戦略本部決定）では、特に、電子政府や電子自治体、重要インフラ等の公共的分野のサービスについては、国民の社会経済活動に大きな影響を及ぼすことのないよう、情報セキュリティ対策の一層の充実を図ることを目標としており、政府は情報セキュリティに関する諸施策を実施している。
暗号技術は情報セキュリティの基盤技術であり、その安全性を暗号技術の専門家により技術的、専門的な見地から客観的に評価することが重要である。電子政府のセキュリティ確保のためには、安全性に優れた暗号技術を利用することが不可欠である。
このため、総務省及び経済産業省は、客観的な評価により安全性及び実装性に優れると判断される暗号技術をリスト化し、各府省に対してその利用を推奨することにより、高度な安全性と信頼性に支えられ、国民が安心して利用できる電子政府の構築に貢献することを目指し、2001 年度から本検討会を開催した。両省は、本検討会での検討及び評価の結果を踏まえ 2003 年 2 月 20 日に「電子政府」における調達のための推奨すべき暗号のリスト（電子政府推奨暗号リスト）を公表し、2003 年 2 月 28 日には、行政情報システム関係
課長連絡会議において、各府省が情報システムの構築にあたり暗号を利用する場合には、可能な限り、電子政府推奨暗号リストに掲載された暗号の利用を推進する旨の「各府省の情報システム調達における暗号の利用方針」が了承された。
総務省及び経済産業省は、国民が安心して電子政府を利用できるように、電子政府の安全性及び信頼性を確保するための活動を引き続き実施していくこととした。
２．２．CRYPTREC の体制
CRYPTREC とは Cryptography Research and Evaluation Committees の略であり、総務
省及び経済産業省が共同で開催する暗号技術検討会（座長：今井秀樹東京大学教授）と、
独立行政法人情報通信研究機構（NICT）及び独立行政法人情報処理推進機構（IPA）が共同で開催する暗号技術監視委員会（委員長：今井秀樹東京大学教授）及び暗号モジュール
委員会（委員長：松本勉横浜国立大学教授）による暗号技術評価プロジェクトを指す（CRYPTREC の体制図は図 1 参照）。暗号技術検討会、暗号技術監視委員会及び暗号モ
ジュール委員会は以下のように検討等を進めた。
２．２．１．暗号技術検討会
暗号技術検討会（以下、「検討会」）は、電子政府推奨暗号の監視、電子政府推奨暗号の安全性及び信頼性確保のための調査・検討及び暗号モジュールの評価基準及び試験基準の作成等について、総合的な観点から検討を行った。

3

検討会は総務省大臣官房技術総括審議官及び経済産業省商務情報政策局長の研究会として開催し、内閣官房、警察庁、防衛庁、法務省、外務省、財務省等がオブザーバとして参加した。
２．２．２．暗号技術監視委員会
暗号技術監視委員会（以下、「監視委員会」）は、検討会の下に設置され、電子政府推奨暗号の監視、電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする調査・検討を行った。なお、監視委員会の日常業務を行う監視要員を NICT 及び IPA に配置した。
また、具体的な調査・検討に際して監視委員会を支援することを目的に、同委員会の下に暗号技術調査 WG として暗号利用モード調査 WG（主査：古原和邦東京大学助手）及び擬似乱数生成系調査 WG（主査：金子敏信東京理科大学教授）を設置し、検討を行った。
暗号技術監視委員会は NICT 及び IPA の委員会として開催し、総務省、経済産業省、
警察庁、防衛庁、外務省等がオブザーバとして参加した。
２．２．３．暗号モジュール委員会
暗号モジュール委員会は検討会の下に設置され、ISO/IEC 等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用されることをも視野に入れながら、電子政
府推奨暗号に準拠した暗号モジュール製品に対する暗号モジュール評価基準及び試験基準の策定に向けた検討を行った。また、上記評価基準及び試験基準の検討に資するため、暗号実装関連技術に関して、サイドチャネル攻撃及びタンパーに関する調査・検討を行った。
暗号モジュール委員会は NICT 及び IPA の委員会として開催し、総務省、経済産業省、
警察庁、防衛庁等がオブザーバとして参加した。

4

暗号技術検討会（座長：今井秀樹東京大学教授）
事務局：総務省／経済産業省

暗号技術監視委員会

暗号モジュール委員会（委員長：今井秀樹東京大学教授）（委員長：松本勉横浜国立大学教授）

事務局： NICT／IPA(1)

電子政府推奨暗号の監視(2)

暗号アルゴリズム等を主な対象と事務局： NICT／IPA(1) 暗号モジュール評価基準及び試験基準の作成する調査・検討(3)(2) 暗号実装関連技術を主な対象とする
調査・検討

電子政府推奨暗号リストの改訂に関する調査・検討

暗号技術調査 WG

図 1 2004 年度の CRYPTREC の体制図

5

２．３．暗号技術検討会メンバー（構成員）※肩書は 2005 年 3 月末現在。敬称略。
座 長 今井 秀樹

東京大学生産技術研究所教授

顧 問 辻井 重男

情報セキュリティ大学院大学学長

会田雄一

社団法人情報サービス産業協会セキュリティ委員会委員

岩下直行

日本銀行金融研究所参事役

太田和夫

電気通信大学電気通信学部情報通信工学科教授

岡崎宏

情報通信ネットワーク産業協会常務理事

岡本栄司

筑波大学大学院システム情報工学研究科教授

岡本龍明

日本電信電話株式会社情報流通プラットフォーム研究所
主席研究員（社団法人電気通信事業者協会代表兼務）

加藤義文

社団法人テレコムサービス協会技術委員会委員長

金子

敏信

東京理科大学理工学部電気電子情報工学科教授

国分明男

財団法人ニューメディア開発協会常務理事・開発グループ長

櫻井幸一

九州大学大学院システム情報科学研究院教授

佐々木

良一

東京電機大学工学部情報メディア学科教授

宝木和夫

社団法人電子情報技術産業協会情報セキュリティ委員会委員

苗村憲司

慶応義塾大学環境情報学部教授

松井充

三菱電機株式会社情報技術総合研究所
情報セキュリティ技術部部長

松本勉

横浜国立大学大学院環境情報研究院教授（オブザーバ）※肩書は原則として参加当時のもの。敬称略。
大矢浩

内閣官房情報セキュリティ対策推進室内閣参事官

手塚新樹

警察庁情報通信局情報技術解析課長

河村延樹

防衛庁長官官房情報通信課長

中井川
牧

禎彦

慎太郎

総務省行政管理局行政情報システム企画課情報システム企画官
総務省自治行政局自治政策課情報政策企画官

安田

錦治郎

法務省民事局商事課補佐官

星山隆

外務省大臣官房情報通信課長

野島透

財務省大臣官房文書課業務企画室長

瀬戸和吉

経済産業省産業技術環境局情報電気標準化推進室長

松島裕一

独立行政法人情報通信研究機構情報通信部門長

大蒔和仁

独立行政法人産業技術総合研究所
研究エディネータ（情報通信担当）

大久保
早貸

明

淳子

独立行政法人情報通信研究機構研究開発推進部門長
独立行政法人情報処理推進機構セキュリティセンター所長

6

米倉

昭利

財団法人情報処理開発協会電子署名・認証センター長

郡山信

財団法人金融情報システムセンター監査安全部長

２．４．暗号技術検討会開催状況
2004 年度、検討会は計 3 回開催された。各回会合の開催日及び主な議題は以下のとおり。
【第 1 回】2004 年 8 月 10 日（火）（主な議題）
・暗号技術検討会の運営方針
・暗号技術検討会 2004 年度活動計画【第 2 回】2004 年 1 月 20 日（木）（主な議題）
・暗号技術監視委員会活動報告
・暗号モジュール委員会活動報告【第 3 回】2005 年 3 月 24 日（木）（主な議題）
・暗号技術監視委員会活動報告
・暗号モジュール委員会活動報告
・今後の CRYPTREC 活動
・暗号技術検討会 2004 年度報告書

7３．暗号技術監視委員会活動報告
３．１．監視活動
電子政府推奨暗号リストに掲載された暗号に対する攻撃の予兆や被害に関する情報収集・分析が重要であることから、暗号技術監視委員会が 2003 年度に組織され、活動を行っている。以下に監視委員会の活動内容について説明を行う。
３．１．１．活動の指針
監視委員会は電子政府推奨暗号リスト掲載の暗号に関する研究動向を把握して、暗号技術の安全性について監視を行い、必要に応じて電子政府システムにおける暗号技
術の情報収集と電子政府推奨暗号リストの改訂について検討会に対して助言を行う。
また、暗号理論全体の技術動向を把握して、最新技術との比較を行い、電子政府シス
テムにおける暗号技術の陳腐化を避けるため、将来の電子政府推奨暗号リストの改訂を考慮して、電子政府推奨暗号に関する調査・検討を行う。監視活動は、「情報収集」、「情報分析」、「審議及び決定」の 3 つのフェーズからなる。
検討会における電子政府推奨暗号の監視に関する基本的考え方は以下の通りである。
（１）実運用環境において安全性に問題が認められた電子政府推奨暗号は原則としてリストから削除する。
（２）電子政府推奨暗号の仕様変更は認めない。
（３）電子政府推奨暗号の仕様変更に到らないパラメータの修正等の簡易な修正を行う
ことにより当該暗号の安全性が維持される場合には、修正情報を周知して当該暗号をリストに残す。
以上の指針に基づき、監視委員会では NICT 及び IPA に監視要員を配置した。監視要
員は研究集会、国際会議、研究論文誌、インターネット上の情報等を監視し、電子政府
推奨暗号の安全性に関して情報を分析するとともに、それを監視委員会に報告する。監
視委員会のもと暗号技術調査ワーキンググループ（以下、「調査 WG」）を構成し、電子
政府推奨暗号の安全性に問題を有する疑いがある場合には早急に検討できる体制を作った。また電子政府推奨暗号の応募者からの自発的な情報提供を呼びかけている。監視要員は情報を参考にして情報分析を行い、電子政府推奨暗号の削除等を検討すべき事態が発生しているか否か判断する。

３．１．２．監視状況（１）全般
監視活動の結果、2004 年度の現時点では収集した全ての情報が「情報収集」、「情報分析」フェーズに留まり、「審議及び決定」には至らず、電子政府推奨暗号の安全

8

性に懸念を持たせるような事態は生じていない。
但し、ハッシュ関数の衝突に関する研究発表があり、それが電子政府推奨暗号の安全性に影響を与えないことの確認作業が実施されたので、次項に示す。
（２）ハッシュ関数問題
2004 年度は新たにハッシュ関数の安全性に関して重要な研究成果が学会等で報告されたため、CRYPTREC 事務局での協議、および暗号技術監視委員会のメーリングリ
スト審議を実施した。その結果、2004 年 9 月 8 日時点では電子政府推奨暗号に含まれるハッシュ関数の安全性が損なわれる事態には至っていないとの判断から、Web サ
イトにその旨を CRYPTREC 見解として掲載した。
【検討の経過】（イ）2004 年 8 月 9 日

SAC 2004 の招待講演 1 でBihamがハッシュ関数（SHA0）の近衝突を発見したと報告した（New Results on

SHA-0 and SHA-1）。なおSHA-1 に関しては、80 段のフル
スペック版に対する衝突ではなく、36 段に処理段数を減らした縮小版に対する衝突の発見が報告された1。
2004 年 8 月 17 日

CRYPTO 2004 のランプセッションで、Joux がハッシュ関
数（SHA-0）の衝突を発見したと報告し、Wang が複数のハッシュ関数（MD4,MD5,HAVAL-128,RIPEMD）の衝突を発見したと報告した。

（ロ）2004 年 8 月 27 日

事務局会議開催（総務省、経済産業省、NICT 及び IPA）

・電子政府推奨暗号に安全性の問題が発生していない事が確認された。
・暗号技術検討会、暗号技術監視委員会の招集は見送ることとした。
・専門外の人々に誤った情報を与えることを防ぐために、CRYPTREC としての見解を Web で示す事にした。
（ハ）2004 年 8 月 31 日

CRYPTREC 見解（案）の作成（ニ）2004 年 9 月 6 日

暗号技術監視委員会メーリングリスト審議（ホ）2004 年 9 月 8 日

Web サイトに CRYPTREC 見解を掲載

1 SHA-1 については後述するように、2005 年 2 月になってWangらにより、従来より少ない計算量（269）で衝突が発見できるとの速報が発表されている。

9

【CRYPTREC 見解】
ハッシュ関数 SHA-1 及び RIPEMD-160 の安全性について
平成 16 年 9 月 8 日
CRYPTREC 暗号技術監視委員会
ハッシュ関数 SHA-0、RIPEMD、MD4、MD5 及び HAVAL-128 の衝突が発見されたことが学会（CRYPTO 2004）で報告され、一部報道等で大きく取り上げられました。電子政
府推奨暗号リストにはハッシュ関数 SHA-1 および RIPEMD-160 が掲載されていますが、今回衝突が発見されたハッシュ関数とは構造が異なっており、現時点までに公表されている解析技術を適用して衝突を発見するには極めて大きな技術的ギャップが存在すると考えられます。従って、冒頭に述べた学会での報告によって、電子政府推奨暗号リストに掲載されているハッシュ関数の安全性に特段の変化は生じていないと考えています。
また、電子政府推奨暗号リストの注釈にあるように、CRYPTREC としてはハッシュ
値が 256 ビット以上とより長い方式の利用を薦めており、この方針を維持・強化することが望ましいと考えています。
いずれにせよ、研究の進展は予断を許さないため、引き続き注意深く監視活動を続
けていきます。
ご意見・コメントなどの問い合わせがございましたら、下記までお願いいたします。
CRYPTREC 暗号技術監視委員会事務局

３．１．３．暗号技術監視委員会開催状況（１）暗号技術監視委員会
2004 年度、監視委員会は計 2 回開催された。各回会合の開催日及び主な議題は以下のとおりである。
【第 1 回】2004 年 6 月 24 日（木）（主な議題）
・活動方針案の説明・審議・監視状況報告【第 2 回】2005 年 2 月 15 日（火）（主な議題）
・監視状況報告・暗号技術調査 WG 活動報告
・国際学会等の参加報告（２）暗号技術調査ワーキンググループ
2004 年度、調査 WG は計 6 回開催された。各回会合の開催日及び主な議題は以下のとおりである。
10

【第 1 回】2004 年 8 月 2 日（月）（主な議題）
・擬似乱数生成系調査【第 2 回】2004 年 8 月 5 日（木）（主な議題）
・暗号利用モード調査【第 3 回】2004 年 10 月 7 日（木）（主な議題）
・ハッシュ関数の安全性調査【第 4 回】2004 年 12 月 24 日（金）（主な議題）
・擬似乱数生成系調査【第 5 回】2005 年 1 月 13 日（木）（主な議題）
・ハッシュ関数の安全性調査【第 6 回】2005 年 2 月 8 日（火）（主な議題）
・ハッシュ関数の安全性調査
３．１．４． 国際学会等における発表の動向（１）国際会議への参加状況
2004 年度は、現在までの間に表 1 に示すような国際会議に監視要員等を派遣し、暗号解読技術に関する情報収集を実施した。情報収集の結果、電子政府推奨暗号の安全性に影響を与える発表等は見られなかった。

表 1 国際会議への参加状況
学会名・会議名

開催国・都市ISO/IEC

ISO/IEC JTC 1/SC 27/WG 2

Singapore

EUROCRYPT 2004

Eurocrypt

AES 4*1

Advanced Encryption Standard(AES ‒ State of the Crypto Analysis)
Yet
Another
Conferenceon
Cryptography
Selected Areas in Cryptography

Interlaken,
Switzerland
Bonn, Germany

YACC 2004*2
SAC 2004
CHES 2004
CRYPTO 2004

Workshop on Cryptographic
and Embedded Systems
Crypto

SASC*3The State of Art Stream Ciphers

ISO/IEC

ISO/IEC JTC 1/SC 27/WG 2

ASIACRYPT 2004

Asiacrypt

11

HardwarePorquerolles
Island, France
Waterloo, Ontario
CanadaBostonUSA
Santa Barbara
United States
BruggeBelgium
Fortaleza
BrazilJeju Island
Korea

期間
2004/4/19 〜
2004/4/27
2004/5/2 〜
2004/5/6
2004/5/9 〜
2004/5/12
2004/6/1 〜
2004/6/5
2004/8/9 〜
2004/8/10
2004/8/11 〜
2004/8/13
2004/8/16 〜
2004/8/19
2004/10/14〜
2004/10/15
2004/10/18〜
2004/10/22
2004/12/5 〜
2004/12/9

PKC 2005
TCC 2005

International Workshop on Theory andPractice in Public Key Cryptography
Theory of Cryptography Conference

FSE 2005

Fast Software Encryption

SHARCS*4

Special-purpose
HardwareAttacking Cryptographic Systems

for

Les Diablerets
Switzerland
Cambridge, MA
USA
Paris
FranceParis
France2005/1/23 〜
2005/1/26
2005/2/10 〜
2005/2/12
2005/2/21 〜
2005/2/23
2005/2/24 〜
2005/2/25*1 AES 4: 共通鍵暗号の安全性評価に関連する国際会議である。1998 年から 2000 年にかけて AES1、AES2、AES3が開催されたが、2001 年に AES が FIPS197 として選定された後はしばらく開催されていなかった。今回は 4 年ぶりの開催になる。
*2 YACC 2004: フランスの研究者中心の国際会議である。Meier の EUROCRYPT 2004 での代数的攻撃法の改良法についての詳細な発表や、Courtois による AES を対象にした代数的攻撃法に関する報告があった。
*3 SASC: The State of the Art of Stream Ciphers は、EU のセキュリティについてのプロジェクトである ECYRYPT が主催するストリーム暗号の安全性評価と設計法に関する会議である。
*4 SHARCS: EU のセキュリティについてのプロジェクトである ECYRYPT が主催する暗号解読専用ハードウェアに関する会議である。

（２）解読技術の動向（イ）ハッシュ関数
ハッシュ関数の安全性に関しては、2004 年度は注目すべき動きが見られた。
ハッシュ関数は衝突を発見できないことが重要な安全性の条件であるが、電子政府
推奨暗号リストに含まれる SHA-1 の衝突発見を試みる研究が、Biham、Joux、Wangにより報告された。
2004 年 8 月に開催されたSAC 2004 およびCRYPTO 2004 において、BihamがSHA-1の 80 段の関数を 36 段に減らした版についての近衝突を発見したと報告した。さらに、CRYPTO 2004 においては、Jouxがハッシュ関数SHA-0 の衝突を発見したほか、Wangがハッシュ関数MD4,MD5, HAVAL-128, RIPEMDの衝突をそれぞれ発見したと報告した（JouxはBihamの結果を応用してSHA-0 の衝突を発見している）。さらに、2005
年 2 月にはWangが、論文(Collision search attacks on SHA12)において 269回程度のSHA-1 の計算で衝突が見つかるという見積もりを報告している。MD5 の衝突について、Wangのアルゴリズムの高速化がFinding MD5 Collisions ‒a Toy For a3

Notebook Vlastimil Klima, Cryptology ePrint Archive 2005/075 によりなされている。さらに、Wang等のMD5 の衝突発見法を利用して、発行者署名が共通の２つの 異 な る X.509 証 明 書 を 作 成 す る 攻 撃 が Colliding X.509 Certificates Arjen
Lenstra and Xiaoyun Wang and Benne de Weger, Cryptology ePrint Archive
2005/067 において発表されている。これはWang等によるMD5 の衝突が現実的な問題

2 http://theory.csail.mit.edu/~yiqun/shanote.pdfから入手可能
3 http://eprint.iacr.org/から入手可能12

に発展することを示唆している。その他、今年度報告されたハッシュ関数に関する解読技術としては、ASIACRYPT 2004 において、Mullerが、ハッシュ関数MD2 の一方向性を否定する理論的結果を報告した。これは 2104の複雑度でMD2 の逆像を求められることを示すものである。MD2 はRSA社が提案する民間標準PKCS#1 v2.1 において
旧システムとの整合性が求められる場合に使用が認められているが、電子政府推奨
暗号リストやISO/IEC標準等には含まれていない。
ハッシュ関数は衝突を発見できないことが重要な安全性の条件であり、ハッシュ関数 SHA-0, MD4, MD5, HAVAL-128, RIPEMD はこの条件を満たしていない。また、Wang らは SHA-1 の衝突困難性について述べた論文を発表しているが、速報であり、詳細な情報が入手できていないため、監視委員会としての判断を得るには至っていない。今後の SHA-1 の解読技術の進展には特に注意する必要がある。また、NIST
は SHA-1 の利用を 2010 年までに止め、より安全なハッシュ関数（SHA-224, SHA256, SHA-384, SHA-512）への移行を推奨する旨のコメントを発表している。
（ロ）ストリーム暗号
ストリーム暗号に対する代数的攻撃（Algebraic attack）は Courtois らにより提案され、解読に必要な計算量の見積もりが与えられていたが CRYPTO 2004 において Hawks と Rose は、Courtois らの見積もりは代入計算の部分の計算量を過小評価しており、正しい評価でははるか大きい演算量が必要であることを示した。さらに、
離散フーリエ変換を利用することによりこの演算量を大幅に減らすことが可能であり、依然として強力な解読法であるとも主張している。他方、ASIACRYPT 2004 において、Diem が、Shamir らが提案する代数的攻撃の一種（XL 攻撃）の漸近的な挙動を理論的に解析したほか、今井、杉田、Faugère らは、XL 攻撃が実はグレブナー
基底アルゴリズムに他ならないことを示し、さらに Faugère 氏によって提案されていた従来最速のグレブナーアルゴリズム F4、F5 よりも速度が大幅に劣ることを示
すなど、代数的攻撃の限界についての報告があった。
ストリーム暗号に対するその他の結果として、Vaudenay らのグループが CRYPTO
2004 及び ASIACRYPT 2004 において、Bluetooth で使用されているストリーム暗号
E0 に対して Fast Correlation Attack を適用し、Courtois らの評価よりも高速な解読が可能であることを示している。
また、電子政府推奨暗号リストに掲載されているストリーム暗号MUGIについて、いくつかの研究報告があった。BiryukovとShamirはFSE 2005 において、非線形部分を変形したMUGIの変形版についての解析結果を示した。彼らの解析では、オリジナルのMUGIの安全性上の問題は見つかっていない。関根・金子ら 4 は、Truncate線形確率評価で最大線形特性確率の上界が 2-138以下となり、Coppersmithの乱数識別攻撃に対しMUGIが安全であることを示した。

4 H.Sekine,T.Nosaka,Y.Hatano,M.Takeda and T.Kaneko:” A Strength Evaluation of a Pseudorandom Number

generator MUGI against Linear Cryptanalysis”, IEICE Trans. Vol.E88-A, No.1, pp.16-24 Jan.2005

13

（ハ）ブロック暗号
ブロック暗号に対する攻撃法に関して、Biryukov らが線形解読法の拡張として複数の線形近似をセットとして考えるマルティブルリニアー解読法を、Courtois
が Bilinear 解読法を CRYPTO 2004 においてそれぞれ提案した。マルチプルリニ
アー解読法は従来から提案されていたが、Biryukov らはこの解読法を DES に適用
し、線形解読法に比べて解読効率が有意の差で向上した主張している。また、
Courtois の提案する Bilinear 解読法は、従来の線形解読法では 1 次式で近似していたものを、Bilinear 関数と呼ばれる特殊な形をした 2 次式による近似に拡張して解読するというもので、特殊な例では解読効率が飛躍的に向上すると主張している。
（ニ）公開鍵暗号
守秘目的の公開鍵暗号アルゴリズムに対する解読技術については、今回の範囲では電子政府推奨暗号の安全性に影響を与える報告はない。特に国際会議 SHARCS に
おいても素因数分解を解く専用ハードウェアがいくつか報告されたが、1024bit のRSA 鍵を解読するために必要なコストの見積もりは 2003 年度報告書で述べた内容と変化していない。新しく SHARK と呼ばれる素因数分解に特化したハードウェアが提案されたが、SHARK は現実的な ASIC 技術を前提にし、1024bit の RSA 鍵の解読に必要なコストは多く見ても$200M との見積もりを報告している。WSI 技術を前提とする TWIRL の$1.1M よりは大きいが、現実的な見積もりとして注目する必要がある。
その他の公開鍵暗号の解読技術として、今年度報告されたものには以下がある。
RSA 暗号の秘密鍵 d を、 d > N 1 / 4 と定めた時の安全性を肯定する結果が報告されている。 d < N 1 / 4 であれば、効率的に d を求めることができるという Wiener 攻撃が知られており、CRYPTREC Report 2002 で指摘した通り、今回の結果を加味しても、計算の高速化を理由に秘密鍵 d を小さな値に制限することはすべきでない。
また、実装に対する解読技術について、GNU Privacy Guard（GPG）と呼ばれる
オープンソースプログラムの実装レベルでの脆弱性の存在を指摘する報告や楕円曲線に基づく署名方式において、楕円曲線上の点の表現方法によっては秘密鍵に関する情報が漏れることがあるという報告があった。
署名目的の公開鍵暗号アルゴリズムの解読技術についても、今回の範囲では電子政府推奨暗号の安全性に影響を与える報告はない。
電子政府推奨暗号の一つであるDSAの変形版であるRDSA5に関し、少ない計算量で、署名鍵を導けることを示す強力な解読法提案された。ただし、この解読法はRDSAに固有の特殊な性質を利用しており、DSAの安全性への影響はない。
また、DSA 署名のスマートカード実装に対して、電気的刺激を加えることにより、
5 RDSAはBiehlらが 2002 年に論文誌Designs, Codes and Cryptographyで発表した署名アルゴリズムである。その名称は、位数が未知の群におけるRoot problem(n乗根を求める問題)に基づいており、かつDSAと式の形が似ていることに由来しているが、離散対数問題に基づくDSAとは別物である。

14

署名鍵を実際に求める(公開されているものとしては最初の)実験の報告があった。
３．２．暗号技術調査ワーキンググループ
３．２．１．擬似乱数生成系の調査
３．２．１．１．ワーキンググループの活動目標
乱数の検定法は一般的な乱数を対象としているが、CRYPTREC が対象としているのは暗号利用用途の擬似乱数生成系であり、このような観点から CRYPTREC が推奨する乱数検定法をまとめた乱数検定ツール(以下、「CRYPTREC 乱数検定ミニマムセット」)
を作成することを最終的な目標とした。
この CRYPTREC 乱数検定ミニマムセットの導出にあたり各乱数検定法の理論的根拠を確認し、どのような観点からの検定が CRYPTREC の方針に適切かを整理する。また、必要であれば閾値等のパラメータを適切な値に修正する。
３．２．１．２．今年度の活動内容
2003 年度暗号技術評価報告書において、2004 年度以降の活動として以下の課題が残されていた。
（１）FIPS 140-2、SP 800-22、DIEHARD で採用されている各検定法の調査範囲の絞り込みと理論的根拠の確認及び計算機実験による検証（２）以上の結果を踏まえての CRYPTREC 乱数検定ミニマムセットへの導入の判断
特に，（１）の検定方法に関しては、調査課題Ⅰ）離散フーリエ変換検定について
離散フーリエ変換検定するための数学理論を構築するための予備調査と、調査課題
Ⅱ）擬似乱数生成系に対する各種検定方式の理論的根拠の確認及び計算機実験による検証を実施した。
３．２．１．３．これまでの成果
調査課題Ⅰ：｢離散フーリエ変換検定について｣
2003 年度の調査より、離散フーリエ変換検定については以下の問題点が抽出されている。
問題点（１）：DFT 振幅スペクトルを 2 値化する際に SP 800-22 で用いている閾
値 T は概算値である。
問題点（２）：2 値化系列の分散σの設定に問題がある。

15

この問題点を解決する目的で、以下の調査を行った。
（１）擬似乱数列を離散フーリエ変換検定するための数学理論を構築するための予
備調査（２）予備調査の結果に基づき、DFT 検定における、分散σに関する理論的な検討
これまでに、以下の点が明らかとなった。
・閾値 T に関し、理論的な真値を用いることにより DFT 検定に対し指摘されている問題点の一部は解決する事
・2 値化系列の相関により、分散σが SP 800-22 で期待している値にならない事、及びその相関の影響を定性的に回避する手法
しかしながら、分散σの理論値を解析するには至っていない。理論で明確に示された乱数検定法のみが適切と判断するならば、NIST の離散フ−リエ変換(DFT)検定は不適切であると判断する。
調査課題Ⅱ：「擬似乱数生成系の各検定方式の理論的根拠の確認及び計算機実験による検証について」
SP 800-22 の 16 種類の検定法に対し、その背景の理論的分布と、実際の試験値の分布を実験的に比較し、検定法の理論的根拠の妥当性を調査した。ここでは、理想的乱数源として Generator-Using SHA-1 を仮定し、理論的に想定される統計量の分布と、実験結果の分布を比較し、その検定法の妥当性を調査した。パラメータの設定範囲は、SP 800-22 で推奨されている値である。実験値が理論分布に合致しているかの判断は、分布曲線を比較し定性的におこなった。理由は以下である。
・仮想的な理想乱数源として Generator-Using SHA-1 を仮定していることの理想性に関する疑問・実験分布と理論分布の一致性を合否検定すると、合格閾値の設定により細部の不一致が見過ごされる危険があること
実験結果として、DFT 検定、Lempel-Ziv 圧縮検定では、理論分布と試験値の分布に大きな違いがあること、近次エントロピー検定では、推奨パラメータの一部において、理論分布からの乖離がみられることがわかった。なお、それ以外の検定項目に関して、実験値は、SP 800-22 で、期待している理論分布に沿った振る舞いをしている事が確認された。

16

３．２．２．ハッシュ関数の安全性調査
３．２．２．１．調査背景
昨年度、本ワーキンググループでは、米国を中心とする暗号利用モード標準の見直しの流れのもと、ブロック暗号を用いた暗号利用モードの調査研究に注力した。
本年度は、暗号利用モード標準化の動きが一段落したこと、ハッシュ関数の衝突解
析に進展があり、現在利用されているハッシュ関数に対して脅威が生じる可能性が出てきたことから、電子政府推奨暗号の監視という観点より、ハッシュ関数の安全性に関する調査を行うこととした。
３．２．２．２．今年度の活動内容
暗号利用モード及びハッシュ関数全般について評価方法と安全性についてまとめ、評価内容について技術的・理論的に示し、電子政府におけるシステム調達者が暗号利用モード及びハッシュ関数の選定における判断材料となる資料を提供することを最終的な目標とした。
特に今年度は、ハッシュ関数の衝突解析に進展があり、電子政府システム及び世の中で広く利用されているハッシュ関数に対して脅威が生じる可能性が出てきたことから、緊急にハッシュ関数の安全性に関する調査を行い、暗号技術監視委員会に報告す
ることを目標とした。
電子政府システム及び世の中で広く利用されている代表的なハッシュ関数について、その技術的特徴と最新の採用・標準化状況を整理し、最新の解析結果を踏まえた安全性評価を調査してまとめる。学会等で発表された学術論文をもとに調査を行った。
３．２．２．３．2005 年 2 月までの成果【ハッシュ関数の安全性について】
電子政府推奨暗号及び IETF, ISO/IEC, FIPS 標準として広く利用されている MD4,
MD5, RIPEMD-160, SHA-1, SHA-256, SHA-512 等の代表的な専用ハッシュ関数を対象とし、技術的特徴と採用・標準化動向をまとめ、最新の解析結果を踏まえた安全性評
価を行った。
表 2 に示すものを中心に調査を行い、本ワーキンググループの報告書としてまとめる。
表 2 調査したハッシュ関数
ハッシュ関数名
MD4
MD5
RIPEMDRIPEMD-128

メッセージ長
(bit)
上限なし
上限なし
上限なし
＜ 264

ハッシュ長
(bit)
128
128
128
128

17

採用されている標準規格等
RFC 1320
RFC 1321
ISO/IEC 10118-3

RIPEMD-160

64

＜ 2

160

SHA(SHA-0)

＜ 264

160

SHA-1

＜ 264

160

SHA-224

＜ 264

224

SHA-256

＜ 264

256

SHA-384＜ 2128384

SHA-512＜ 2128

512

Whirlpool＜ 2256512

電子政府推奨暗号注)
ISO/IEC 10118-3

電子政府推奨暗号注)
FIPS 180-2
ISO/IEC 10118-3
FIPS 180-2 (Change Notice 1)
電子政府推奨暗号
NESSIE Portfolio
FIPS 180-2
ISO/IEC 10118-3
電子政府推奨暗号
NESSIE Portfolio
FIPS 180-2
ISO/IEC 10118-3
電子政府推奨暗号
NESSIE Portfolio
FIPS 180-2
ISO/IEC 10118-3
NESSIE Portfolio
ISO/IEC 10118-3

注）電子政府推奨暗号リストにおいて、RIPEMD-160, SHA-1 については「新たな電子政府用システムを構築する場
合、より長いハッシュ値のものが使用できるのであれば、256 ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべきハッシュ関数が指定されている場合には、この限りではない。」という注釈がついている。

（１）MD4, MD5, RIPEMD, SHA-0
従来から Birthday Paradox による衝突発見よりも効率の良い攻撃が知られているものもあり、積極的な利用は推奨されていなかったが、2004 年に Wang らにより、さらに少ない計算量で衝突が見つけられることが発表された。これらの安全性は十分でなく、衝突困難性が求められる電子署名などのアプリケーションでの利用は避けるべきと思われる。
（２）RIPEMD-128, RIPEMD-160
2005 年 2 月現在、問題点は見つかっていない。但し、RIPEMD-128 はハッシュ長が 128 ビットであるため、衝突攻撃による攻撃計算量は高々264であり、長い将来に渡って利用されるアプリケーションには適さない。また、RIPEMD-160 もハッシュ長が 160 ビットであるため、衝突攻撃による攻撃計算量は高々280であり、将18

来に渡って安全であるとは保証できない。
（３）SHA-1
2004 年にBihamらにより、36 段に短縮したSHA-1 の衝突が発見された他、Rijmen
により、53 段に短縮したSHA-1 の衝突が発見された。また、2005 年 2 月中旬になって、Wangらによって 269の計算量によって衝突が発見できるという報告があった。詳細なアルゴリズムがまだ公開されておらず計算量の見積もりが適切か不明であるため、2005 年 3 月現在では判断できない状況である。本攻撃結果のみによってSHA-1 を利用したシステム全てが直ちに危険にさらされるとは考えにくいが、今後の動向に厳重に注意する必要がある。2005 年度は引き続き調査を継続する予定である。
（４）SHA-224/256/384/512
Gilbertらによる評価で、最も確率の高い”differential collision pattern”の攻撃計算量がSHA-224に対しては266であり、SHA-256に対しては2132となることから、SHA-256は衝突攻撃に対して耐性をもつという結論が導かれている。2005年2月
現在では致命的な問題点は見つかっていないが、今後の動向に注意していく必要がある。SHA-384/512に関してはSHA-224/256と同様の解析がGilbertら及びHawkesらによって報告されているが、現時点では安全性を脅かす問題は見つかっていない。
今後の動向に注意していく必要がある。
（５）Whirlpool
2005 年 2 月現在、問題点は見つかっていないが、2000 年に提案されて以来、提案者以外からの安全性評価がされていないため、今後の解析に注意していく必要がある。

19

４．暗号モジュール委員会活動報告
４．１．暗号モジュール委員会活動の背景と目的
４．１．１．暗号モジュール評価の標準化に関する国際動向
暗号モジュール評価の国際的な標準化活動としては、(1)米国/カナダが共同運用しているCMVP6、(2)ISO/IEC JTC1/SC27/WG3 で審議中の暗号モジュール評価基準の国際標準化、の 2 つが重要である。
CMVPは米国のNIST7 とカナダのCSE8 が共同運用している暗号モジュールの評価プログラムである。米国連邦政府が調達する、機微であるが機密でない情報の秘匿･完全性･認証を実現する暗号モジュールの評価・認証は、評価基準FIPS9 140-2 に基づいて行われる。
CMVPでは、現行の評価基準FIPS 140-2 を改訂し、新基準FIPS 140-3 に移行する方針
であり、その説明のためにCMVPシンポジウム 200410を 2004 年 9 月にワシントンDC郊外のRockvilleで開催した。会合でのトピックスは、(1)FIPS 140-3 の発行に向けた、
FIPS 140-2 の改訂作業の開始、(2)DESの廃止、(3)暗号モジュール評価に関する国際相互承認への言及、の３点である。FIPS 140-3 の発行に向けたFIPS 140-2 の改訂作業は2005 年 1 月に開始し、2006 年 11 月の完了を目指している。FIPS 140-3 の発効に伴い、FIPS 140-2 は 2007 年 5 月に失効する予定である。
FIPS 140-2 の主な改訂の予定箇所は、ソフトウエア暗号モジュールの取り扱い、動作モード、物理的セキュリティ、鍵管理など８項目である。日本で関心の高い電力解析
関係は言及されなかったものの、EMI/EMC11 関連基準の見直しと、スマートカードを評
価対象に含める方針は示された。
ISO/IEC JTC112は、ISO13とIEC14が共同で運営するIT技術標準化のための組織で、SC27
委員会で情報セキュリティを、その下のWG3 で情報セキュリティの評価基準を担当している。
ISO/IEC JTC1/SC27/WG3 は、2002 年 10 月から暗号モジュール評価基準の国際標準化
15(規格予定番号 19790)を審議している。2004 年の国際会合は、4 月(シンガポール)と10 月(ブラジル)の 2 回開催された。この間に暗号モジュール評価基準の国際標準化フェーズは、2nd WD16からFCD17へと進捗し、2006 年 4 月にはIS18化される見込みである。
6 Cryptographic Module Validation Program

7 National Institute of Standards and Technology
8 Communications Security Establishment

9 Federal Information Processing Standards

10 Cryptographic Module Validation Program Symposium 2004, http://csrc.nist.gov/cryptval/cmvp2004/
11 Electromagnetic Interference / Electromagnetic Compatibility
12 Joint Technical Committee 1

13 International Organization for Standardization
14 International Electrotechnical Commission

15 Security Requirements for Cryptographic Modules
16 Working Draft

17 Final Committee Draft
18 International Standard20

図 2 に FIPS 140 と IS 19790 の関係を示す。IS 19790 は、FIPS 140-2 をベースとした基準であるが、CC(Common Criteria)への連接性を意識しているため、詳細な評価項
目は異なる部分が存在する。また、FIPS 140-3 については、成立見込み時期が IS
19790 よりも遅いことから、IS 19790 の内容を反映する可能性がある。
さらに、暗号モジュール評価基準の国際標準化に付随して、実際の評価・運用に必要となる、運用ガイダンスと暗号モジュール試験基準の標準化も study period として検討されることとなった。
NIST
2001年5月

FIPS 140-2

2006年11月（見込み）

FIPS 140-3

ISO/IEC

2006年4月（見込み）

IS 19790

図 2 FIPS 140とIS 19790の関係

４．１．２．暗号モジュールに対する攻撃に関する研究動向
暗号モジュールの安全性評価には、使用される暗号方式の数学的安全性に加え、実装に伴った情報漏洩の可能性も考慮する必要がある。このような実装の特性に着目した攻撃法は近年盛んに研究されている。表 3 に今年度中に学会発表されたもの（予定を含む）を示す。
表 3 暗号モジュールに対する攻撃に関する学会別発表件数
学会名
ASIACRYPT 2004
CHES19 2004
EUROCRYPT 2004
PKC20 2005
情報セキュリティ研究会(ISEC 研究会)
SCIS21 2005
CSS22 2004
集積回路研究専門委員会（ICD23）
その他（e-Print 等）

発表件数
1
6
1
1
10
21
3
3
1

19 Workshop on Cryptographic Hardware and Embedded Systems
20 International Workshop on Practice and Theory in Public-Key Cryptography
21 Symposium on Cryptography and Information Security
22 Computer Security Symposium

23 Integrated Circuits and Devices21

実装の特性に着目した攻撃は、破壊攻撃と非破壊攻撃の 2 種類に大別できる。破壊攻
撃は、暗号モジュールのパッケージを剥がして配線を読み取るといった、不可逆的な改変を伴うものである。一方、非破壊攻撃は、動作時の実行時間や消費電力量等の観測だ
けで、暗号モジュール自体の改変を伴わないものである。現状では、非破壊攻撃の研究がより盛んである。
非破壊攻撃はサイドチャネル攻撃とも呼ばれ、今年度の重要な発表としては、(1)ス
マートカードに実装された DSA 署名の署名鍵を実際に求めてみせた Naccache らの研究
(PKC 2005)、(2)DES の実装に対する従来の電力解析への防御策のほとんどを無効にす
る Kunz-Jacques らの研究(ASIACRYPT 2004)、(3)電力解析用評価環境の開発とそれを利用した評価実験 (ISEC 7 月)、などがある。
破壊攻撃に関しては、電子情報通信学会の時限研究会・LSI 動作解析研究会において、LSI 研究者と暗号研究者が現状の LSI 解析技術で実際の LSI チップがどの程度解析可能かを検討した。研究成果は、集積回路研究専門委員会(ICD)の平成 16 年度 9 月研究会で発表された。
４．１．３．暗号モジュール委員会の活動目的
以上のような状況を踏まえ、昨年度、暗号モジュール委員会では、ISO/IEC等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用され得ることをも視野に入れながら、暗号モジュール評価基準及び試験基準の策定作業を開始し、北米の評価基
準及び試験基準の翻訳版として、暗号モジュール評価基準及び試験基準の第 0 版を発行した。また、暗号モジュールへの非破壊攻撃及び破壊攻撃に対する調査・研究として、その具体的テーマに、非破壊攻撃の１つである電力解析に関する調査・研究を選定し、電力解析のためのFPGA24による評価用標準プラットフォームの要求仕様を策定した。
今年度の活動として、暗号モジュール委員会では、昨年度に引き続き、次の 2 つを主な活動項目とした。
（１）暗号モジュール評価基準及び試験基準の策定（２）暗号モジュールへの非破壊攻撃及び破壊攻撃に対する調査・研究
各活動項目の詳細は以下の通りである。
（１）暗号モジュール評価基準及び試験基準の策定
現在審議中の国際標準案（ISO/IEC 19790）は、当初、北米の暗号モジュール評価基準である FIPS 140-2 ベースで IS 化されるものと予想していたが、審議状況から、内容的に FIPS 140-2 と大きな差が発生する可能性が出てきた。そのため、今年度予定していた評価基準及び試験基準第 1 版の策定作業を休止し、国際標準にも対応可能なように、準備として以下の作業を行うこととした。
24 Field Programmable Gate Array22

（イ）暗号モジュール評価基準の差分表の作成
FIPS 140-2 と国際標準案（1st CD25 19790）との差分表を作成し、作成した差分表の翻訳を行うことで、暗号モジュール評価基準第 0 版と国際標準案（1st CD
19790）との差分表の作成を行う。
（ロ）差分表に対応した暗号モジュール試験基準の検討表の作成
上記（イ）の作業の結果、暗号モジュール評価基準第 0 版の内容に追加等が発生した場合、その対応部分について、暗号モジュール試験基準第 0 版の内容も追加等が必要である。従って、上記（イ）にて作成した暗号モジュール評価基準の差分表に対応した暗号モジュール試験基準の検討表の作成を行う。
（ハ）ISO/IEC JTC1/SC27/WG3 への技術コメント作成協力
国際標準案(ISO/IEC 19790)に対する日本コメント案作成の協力を行う。
（ニ）運用ガイダンス第 0 版の作成
NIST 発 行 の “ Implementation Guidance for FIPS PUB 140-2 and the
Cryptographic Module Validation Program(Last Update: April 28, 2004)”の翻訳版の作成を行う。4 月 28 日以降に改版が発行された場合には、逐次、翻訳対応を行う。
（ホ）暗号モジュール評価基準及び試験基準第 0.1 版の作成
昨年度作成した暗号モジュール評価基準及び試験基準第 0 版に対して、NIST発行のFIPS 140-2 及びDTR26のCHANGE NOTICEへの対応等を行った修正版の作成を行う。
（２）暗号モジュールへの非破壊攻撃及び破壊攻撃に対する調査・研究
今年度は、評価用標準プラットフォームを用いた評価データの蓄積期間と位置付け、原則、委員会内での検討作業は行わないこととした。なお、昨年度、暗号モジュール委員会にて仕様策定を行った評価用標準プラットフォームの入手及び委員への評価用
標準プラットフォームの配布は次のように実施することとした。
（イ）評価用標準プラットフォームの入手
暗号モジュール委員会では、INSTAC27の耐タンパー性に関する標準化調査研究委
員会（委員長：横浜国立大学 松本教授）と協調して、暗号モジュールへの非破壊攻撃及び破壊攻撃に対する評価基準の検討を行っている。今年度、耐タンパー性に関する標準化調査研究委員会では、電力解析のための汎用 32 ビットCPUを用いた評25 Committee Draft
26 Derived Test Requirements for FIPS PUB 140-2, Security Requirements for Cryptographic Modules
27

日本規格協会 情報技術標準化研究センター

23価用標準プラットフォーム仕様に、暗号モジュール委員会にて昨年度策定したFPGAを用いた評価用標準プラットフォーム仕様を加えた評価用標準プラットフォーム仕様 の 策 定 を 行 う 。 INSTAC の 委 託 先 が 、 今 年 度 、 本 仕 様 に 基 づ く 評 価 ボ ー ド（INSTAC-32 準拠評価用標準プラットフォーム）を作成し、実証実験を行うため、その委託先からプラットフォームの入手を行う。
（ロ）委員への評価用標準プラットフォームの配布得られた成果について、学会等で発表する条件にて、希望する委員に対して無償配布を行う。
４．２．暗号モジュール委員会開催状況
2004 年度の暗号モジュール委員会は、計 5 回開催された。各回会合の開催日及び概要
は次のとおりである。
【第 1 回】平成 16 年 6 月 23 日（水）（主な議題）
・ISO/IEC JTC1/SC27/WG3 シンガポール会合報告
・平成 16 年度暗号モジュール委員会活動計画（案）について【第 2 回】平成 16 年 9 月 10 日（金）（主な議題）
・差分表の検討について
・運用ガイダンス第 0 版の検討について【第 3 回】平成 16 年 11 月 12 日（金）（主な議題）
・CMVP シンポジウム 2004 及び NIST 定期会議報告について
・ISO/IEC JTC1/SC27/WG3 ブラジル会合報告について・評価基準の差分に対応した試験基準の検討について・シングルチップモジュールの validation 後のアプリケーション追加について【第 4 回】平成 16 年 12 月 10 日（金）（主な議題）
・評価基準の差分に対応した試験基準の検討について
・運用ガイダンス第 0 版の検討について
・暗号モジュール委員会活動報告書の作成について・シングルチップモジュールの validation 後のアプリケーション追加について【第 5 回】平成 17 年 2 月 18 日（金）（主な議題）・FIPS 140-2 及び Final CD に対するコメント作成について
・暗号モジュール委員会活動報告書の作成について・来年度以降のスケジュールについて24

４．３．暗号モジュール評価基準及び試験基準の策定
４．３．１．基準類の概要（１）FIPS 140-2
FIPS 140 は、コンピュータシステム及び電気通信システム内の暗号モジュールに対するセキュリティ要求事項を規定した、NIST が発行する米国政府標準である。
FIPS 140 は、政府及び産業界で構成されたワーキンググループによって開発された。1994 年 1 月に FIPS 140-1 が制定され、2001 年 5 月には FIPS 140-2 として改訂された。FIPS 140-2 は、ベンダ、試験機関、及びユーザ団体から寄せられたコメントに基づいた変更だけでなく、FIPS 140-1 が開発された以降に利用可能となった標
準及び技術の変更も取り入れている。FIPS 140-2 は適宜改訂されており、2002 年 12
月の改訂版が 2005 年 3 月時点での最新版となっている。
FIPS 140-2 は、暗号モジュールのセキュアな設計及び実装のために、暗号モジュールが満たすべき 11 分野(暗号モジュールの仕様、暗号モジュールのポート及びインタフェース、役割・サービス・認証、有限状態モデル、物理的セキュリティ、動作環境、暗号鍵管理、電磁妨害/電磁両立性、自己テスト、設計保証、その他の攻撃への対処)のセキュリティ要求事項を規定しており、さらに、保護すべきデータの重要性と使用環境に応じて暗号モジュールを提供できるように、分野ごとに 4 段階のセ
キュリティレベル(セキュリティレベル 1〜4)を規定している。
（２）DTRDTR は、暗号モジュールが FIPS 140-2 で規定されたセキュリティ要求事項を満たしているかどうかを試験する際に、試験者が実施しなければならない試験手順及びベンダが提供しなければならない情報を規定したものである。
DTR も FIP 140-2 と同様に適宜改訂されており、2004 年 3 月の改訂ドラフト版が2005 年 3 月時点での最新版となっている。
DTR は、全 11 章から構成されており、各章は FIPS 140-2 で規定された 11 分野に対応している。各章では、FIPS 140-2 に対応するセキュリティ要求事項をアサーション(すなわち、設定されたセキュリティレベルで、設定された分野のセキュリ
ティ要求事項を暗号モジュールが満足するために適用しなければならない宣言)として記述している。全てのアサーションは FIPS 140-2 から直接引用している。各ア
サーションの次には、ベンダが提供しなければならない情報、試験者が実施しなければならない試験手順を順に記述している。
（３）Implementation Guidance
Implementation Guidance は、CMVP、特に DTR に関する、ベンダや試験機関等からの問合せに対して、NIST 及び CSE が回答したコメントを CMVP に関するガイダンスと25

してまとめたものである。
Implementation Guidance も FIPS 140-2 及び DTR と同様に適宜改訂されており、2005 年 1 月の改訂版が 2005 年 3 月時点での最新版となっている。
Implementation Guidance は、全 17 節(OVERVIEW, GENERAL ISSUES, SECTION 1 から SECTION 14, EXPIRED IMPLEMENTAITON GUIDANCE)から構成されている。
SECTION 1 から SECTION 14 は、FIPS 140-2 の 4.1 節から 4.11 節(SECTION 1 から
SECTION 11 に対応)、APPENDIX A(SECTION 12 に対応)、 APPENDIX B(SECTION 13 に対応)、APPENDIX C(SECTION 14 に対応)にそれぞれ対応しており、FIPS 140-2 で規定されるセキュリティ要求事項の分野ごとに整理され、記述されている。また、複数の分野に当てはまる内容については、最適な分野の SECTION に記述されている。
OVERVIEW に は Implementation Guidance の 概 要 が 記 述 さ れ て お り 、 GENERALISSUES には、SECTION 1 から SECTION 14 の分野に特定されない全般的な問題が整理され、記述されている。また、取消された運用ガイダンスを記述するために、
EXPIRED IMPLEMENTAITON GUIDANCE の節が用意されているが、現在、何も記述されていない。
４．３．２．国際標準への対応検討
今年度、暗号モジュール委員会では、４．１．１．で述べたような暗号モジュール評
価の標準化に関する国際動向に対応すべく、その準備として、以下の（１）、（２）の作業を行い、表に整理してまとめた。なお、本表については、ISO/IEC JTC1/SC27/WG3 での審議内容を多く含んでいるため、2005 年 3 月時点での公開を予定していない。
（１）暗号モジュール評価基準の差分表の作成
FIPS 140-2 と国際標準案（1st CD 19790）との差分表を作成し、暗号モジュール委員会内での検討を完了した。検討結果については、表に整理してまとめた。また、国際標準案が 1st CD から FCD へ進む際に修正部分が多数発生しており、今後も継続的な検討が必要である。
なお、差分表の翻訳については、国際標準案（ISO/IEC 19790）がほぼ確定した時点で改めて実施することとなった。
（２）差分表に対応した暗号モジュール試験基準の検討表の作成
上記（１）の差分表に対応した暗号モジュール試験基準案を作成し、暗号モジュール委員会内での検討を完了した。検討結果については、表に整理してまとめた。また、国際標準案が 1st CD から FCD へ進む際に上記（１）の差分表の修正部分が多数発生していることや試験基準の国際標準化の動きがある（study period）ことから、今後も継続的な検討が必要である。
また、国際標準案（1st CD 19790, FCD 19790）に対する日本コメント案を作成し、26

ISO/IEC JTC1/SC27/WG3 国内委員会に提出した。2004 年 10 月（ブラジル）の会合では、
1st CDに対する日本NB28コメントとして、44 件のコメントを提出し、42 件が受理され、2 件がRejectされた。なお、FCDに対する各国コメントの審議については、2005 年 4 月（ウィーン）にて実施される予定である。
４．３．３．運用ガイダンス第 0 版の検討
（１）第 0 版の作成
まず、暗号モジュール委員会事務局にて Implementation Guidance の 2004 年 4 月
改訂版の翻訳案を作成し、翻訳案に対して委員会内での審議を行い、英文解釈の統一化を図った。
次に、Implementation Guidance が 2004 年 9 月に改訂されたため、その差分について、暗号モジュール委員会事務局にて翻訳案を作成し、同様に委員会内での審議を行い、英文解釈の統一化を図った。
そして、委員会内での英文解釈を統一化した Implementation Guidance の 2004 年
9 月改訂版の翻訳を運用ガイダンス第 0 版としてまとめた。
また、2005 年 1 月にはさらに改訂されたため、その差分について翻訳検討中である。
今後、Implementation Guidance のさらなる改訂版にも追従していくとともに、国際動向も考慮しながら、わが国の運用ガイダンス第 1 版を作成していく予定である。
（２）第 0 版の構成
運用ガイダンス第 0 版は、“Implementation Guidance for FIPS PUB 140-2 andthe Cryptographic Module Validation Program, Last Update: September 22,
2004” を 翻 訳 し た も の で あ り 、 構 成 は 、 4.3.1 (3) で 述 べ た

Implementation

Guidance と同様である。
本文は全 17 節から構成されており、「概要」、「全般的な問題」、「第 1 章 暗号モ
ジュールの仕様」、「第 2 章 暗号モジュールのポート及びインタフェース」、「第 3 章役割、サービス、及び認証」、「第 4 章 有限状態モデル」、「第 5 章 物理的セキュリ
ティ」、「第 6 章

動作環境」、「第 7 章性(EMI/EMC)」、「第 9 章

暗号鍵管理」、「第 8 章 電磁妨害/電磁両立

自己テスト」、「第 10 章攻 撃 へ の対処 」、「 第 12 章

設計保証」、「第 11 章その他のAppendix A: 文書 要 求 事項の ま と め」、「第 13 章

Appendix B: 推奨ソフトウエア開発手順」、「第 14 章Appendix C: 暗号モジュールのセキュリティポリシ」、「取消された運用ガイダンス」が記述されている。
各節の冒頭には、NIST 及び CSE からの解答内容に関し、適用されるセキュリティ
レベル、有効期間、最終改訂日、DTR の関連するアサーションの番号(AS 番号)、DTRの関連する試験者に課せられる要求事項の番号(TE 番号)、DTR の関連するベンダに課
28 National Body27

せられる要求事項の番号(VE 番号)が記述されている。その後に、背景(節によっては記述されない)、NIST 及び CSE への質問内容、NIST 及び CSE からの解答、NIST 及び
CSE からの追加コメントが順に記述されている。
運用ガイダンス第 0 版については、下記 URL の「CRYPTREC Report 2004 の公開」
から参照できる。
http://www.ipa.go.jp/security/enc/CRYPTREC/index.html
http://www2.nict.go.jp/ns/s801/102/index.html
４．３．４．評価基準/試験基準第 0.1 版の作成
４．３．４．１．評価基準第 0.1 版の作成
昨年度の暗号モジュール委員会では、“FIPS PUB 140-2, SECURITY REQUIREMENTS
FOR CRYPTOGRAPHIC MODULES, CHANGE NOTICE(12-03-2002)”を翻訳したものを暗号モ
ジュール評価基準第 0 版として発行した。
今年度の暗号モジュール委員会では、運用ガイダンス第 0 版の訳語との統一を図る
ために、暗号モジュール評価基準第 0 版の訳語の見直しを行い、暗号モジュール評価
基準第 0.1 版として発行した。
暗号モジュール評価基準第 0.1 版については、下記 URL の「CRYPTREC Report 2004の公開」から参照できる。また、昨年度、問題点整理表としてまとめた、基準内容に関する不明点及び問題点に関し、その回答を表にまとめた。詳細については、下記
URL から「CRYPTREC Report 2004 暗号モジュール委員会報告書」を参照されたい。
http://www.ipa.go.jp/security/enc/CRYPTREC/index.html
http://www2.nict.go.jp/ns/s801/102/index.html
４．３．４．２．試験基準第 0.1 版の作成
昨年度の暗号モジュール委員会では、“Derived Test Requirements for FIPS PUB
140-2, Security Requirement for Cryptographic Modules (February 12, 2003
Draft)”を翻訳したものを暗号モジュール試験基準第 0 版として発行した。
上記 DTR は 2004 年 3 月 24 日に改訂ドラフト版が発行されたため、今年度の暗号モ
ジュール委員会では、暗号モジュール試験基準第 0 版に対して、主に DTR の改訂部分を反映させるとともに、運用ガイダンス第 0 版の訳語との統一を図るために、暗号モジュール試験基準第 0 版の訳語の見直しを行い、暗号モジュール試験基準第 0.1 版として発行した。
暗号モジュール試験基準第 0.1 版については、下記 URL の「CRYPTREC Report 2004の公開」から参照できる。また、昨年度、問題点整理表としてまとめた、基準内容に28

関する不明点及び問題点に関し、その回答を表にまとめた。詳細については、下記
URL から「CRYPTREC Report 2004 暗号モジュール委員会報告書」を参照されたい。
http://www.ipa.go.jp/security/enc/CRYPTREC/index.html
http://www2.nict.go.jp/ns/s801/102/index.html
４．４．非破壊攻撃及び破壊攻撃に対する調査・研究
４．４．１．評価用標準プラットフォームの検討方針
昨年度、暗号モジュール委員会では、暗号モジュールへの非破壊攻撃及び破壊攻撃に対する調査・研究において、その具体的テーマを検討するにあたり、INSTAC の耐タンパー性に関する標準化調査研究委員会(委員長：横浜国立大学 松本教授)と共同で文献調査を行い、暗号モジュールへの電力解析に関する調査・研究を具体的テーマとして決定した。
また、その研究の位置づけは、暗号モジュールへの電力解析への対策に関する評価基
準及び試験基準策定のための予備的な研究とし、理論だけでなく、攻撃及び対策の効果に対する追試実験等を行い、実データに基づいた研究を行うことを研究方針とした。本
研究を進めるにあたり、基準策定のための必要なデータを多くの研究機関から効率的に収集できるよう、評価用標準プラットフォームを構築し、このプラットフォーム上での評価手法の確立を目指すこととした。
また、評価用標準プラットフォームにおいて、早期に着手可能であり、評価対象を柔軟かつ広範囲に設定できることから、FPGA による評価用標準プラットフォームを作成することとし、その要求仕様を決定した。
詳細は、昨年度公開した「CRYPTREC Report 2003 の公開」の「CRYPTREC Report
2003 暗号モジュール委員会報告書」29を参照されたい。
今年度は、FPGA による評価用標準プラットフォームを作成し、委員への配布を行うこととし、評価用標準プラットフォームを用いた評価データの蓄積期間と位置付け、原則、暗号モジュール委員会内での検討作業は行わないこととした。
４．４．２．評価用標準プラットフォームの作成
暗号モジュール委員会では、INSTAC の耐タンパー性に関する標準化調査研究委員会と協調して、暗号モジュールへの非破壊攻撃及び破壊攻撃に対する評価基準の検討を行っている。
昨年度、INSTACの耐タンパー性に関する標準化調査研究委員会では、電力解析のための汎用 8 ビットCPUを用いた評価用標準プラットフォーム仕様を策定し、INSTACの委託先が本仕様にもとづいた評価ボード(INSTAC-8 準拠評価用標準プラットフォーム)を作成し、電力解析の実証実験を行った。なお、その報告書は、INSTACのホームページ上に

29 http://www.ipa.go.jp/security/enc/CRYPTREC/index.html

http://www2.nict.go.jp/ns/s801/102/index.html

29

公開されている30。
INSTAC-8 準拠評価用標準プラットフォームを用いた電力解析の実証実験は１社のみの実施であったため、暗号モジュール委員会では、評価基準の検討には複数の実証実験
データの収集が必要との判断から、今年度、本プラットフォームを INSTAC の委託先より入手し、委員への配布を行い、現在、実証実験データの収集をお願いしているところである。
今年度、INSTAC の耐タンパー性に関する標準化調査研究委員会では、電力解析のための汎用 32 ビット CPU を用いた評価用標準プラットフォーム仕様に、暗号モジュール委員会にて昨年度策定した FPGA を用いた評価用標準プラットフォーム仕様を加えた評
価用標準プラットフォーム仕様を策定した。また、INSTAC の委託先が本仕様にもとづく評価ボード(INSTAC-32 準拠評価用標準プラットフォーム)を作成し、電力解析の実証実験を行っている。
暗号モジュール委員会では、この INSTAC-32 準拠評価用標準プラットフォームを今年度中に入手し、委員への配布を行うべく、INSTAC の委託先との調整を実施してきたが、今年度中の入手が困難な状況となり、現在、2005 年 6 月以降に入手できるよう、再度調整を進めているところである。

30「耐タンパー性に関する標準化調査研究開発 第一部 」、「耐タンパー性に関する標準化調査研究開発部」, http://www.jsa.or.jp/domestic/instac/index.htm

30

第二５．今後の CRYPTREC 活動について
CRYPTREC は、電子政府の安全性及び信頼性を確保し国民が安心して電子政府を利用できる環境を整備するため、2005 年度以降以下の活動を実施していくこととする。
５．１．今後の CRYPTREC の活動目的及び活動内容
５．１．１．活動目的
CRYPTREC は、暗号技術及び暗号関連技術の評価等を通じて、電子政府等の安全性及び信頼性の確保に貢献することを目的として活動する。
５．１．２．活動内容
CRYPTRECは、2005年度以降も引き続き以下の活動を行う。なお、今後、新たに必要と考えられる事案が生じた場合には、その都度、暗号技術検討会において具体的な活動内容を検討していくものとする。
（１）電子政府推奨暗号の監視
電子政府推奨暗号に選定された各暗号の安全性等についての情報収集や評価を行い、必要に応じて修正情報の周知やリストからの削除等の電子政府推奨暗号リストの変更を行う。
（２）電子政府推奨暗号の安全性及び信頼性確保のための調査・検討（イ）暗号アルゴリズム等を主な対象とする調査・検討
暗号アルゴリズムや素因数分解問題等の数論的問題の困難性を主な対象とする調査及び検討を行う。
（ロ）暗号実装関連技術を主な対象とする調査・検討
実装攻撃等の暗号実装関連技術を主な対象とする調査及び検討を行う。
（３）電子政府推奨暗号リストの改訂に関する調査・検討
将来の電子政府推奨暗号リストの改訂（新たな電子政府推奨暗号リストの策定及び本件電子政府推奨暗号リストの廃棄）のために必要な調査及び検討（電子政府における暗号利用状況調査等）を行う。その際、総務省、経済産業省及び行政情報システム
関係課長連絡会議との連携を図ることとする。
（４）暗号モジュール評価基準の作成
暗号モジュール評価基準及び試験基準を作成する。

31

５．２．今後の CRYPTREC 体制
CRYPTREC は、2005 年度以降も引き続き、「暗号技術検討会」、暗号技術検討会の下に設置される「暗号技術監視委員会」及び「暗号モジュール委員会」並びに暗号技術監視委員会の下に設置される「暗号技術調査 WG」により構成されるものとする。
暗号技術検討会、暗号技術監視委員会、暗号モジュール委員会、暗号技術調査 WG の位
置づけ、構成及び機能は以下のとおり。
５．２．１．暗号技術検討会
暗号技術検討会（以下、「検討会」）は、電子政府推奨暗号リストに掲載された暗号技術の監視、関連する調査研究、及び、暗号技術の危殆化や暗号プロトコル等その他暗号技術の評価・利用等に関する事項について、総合的な観点から検討を行う。また、電子政府等のセキュリティの確保のため、政府のセキュリティ関係機関等との連携、調整を図る。
５．２．２．暗号技術監視委員会
暗号技術監視委員会（以下、「監視委員会」）は検討会の下に設置される。監視委員会
は、数名の有識者等により構成され、安全性及び信頼性確保の観点から、電子政府推奨
暗号の監視、電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする調査・検討を適宜行うとともに電子政府推奨暗号リストの改訂に関する調査・検討を行う。なお、監視委員会の日常業務を行う監視要員をNICT及びIPAに配置する。
（１）暗号技術調査ワーキンググループ（イ） 暗号技術調査WG（以下、「調査WG」）は、電子政府推奨暗号リストの変更案等の作成、及び電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする
具体的な調査・検討に際して監視委員会を支援することを目的として、監視委員会の下に設置される。
（ロ） 調査WGは、監視委員会からの要請により事案の性質に応じて開催されることとし、監視委員会に対して電子政府推奨暗号リストの変更案の作成等に関する専門的助言を行う。
（ハ）その他、調査WGは、電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする具体的な調査・検討（電子政府における暗号利用状況調査等）を行い、監視委員会に対して専門的な助言を行う。
５．２．３．暗号モジュール委員会
暗号モジュール委員会は検討会の下に設置される。暗号モジュール委員会は、

32

ISO/IEC等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用され得ることをも視野に入れながら、暗号モジュール評価基準及び試験基準を作成する。また、
電子政府推奨暗号の安全性及び信頼性確保のための、主として暗号実装関連技術等を対象とする調査・検討を行う。
５．３．電子政府推奨暗号の監視
５．３．１．電子政府推奨暗号の監視の基本的考え方
CRYPTRECは、電子政府推奨暗号の安全性及び信頼性を確保することを目的とし、継続的に暗号技術に関する情報を収集し、必要に応じて暗号の安全性を評価する電子政府推奨暗号の監視活動を行う。
監視は、以下のような考え方に基づいて実施することとする。
（１）実運用環境において安全性に問題が認められた電子政府推奨暗号は原則としてリストから削除する。
（２）電子政府推奨暗号の仕様変更は原則として認めない。
（３）電子政府推奨暗号の仕様変更に到らないパラメータの修正等の簡易な修正を行う
ことにより当該暗号の安全性が維持される場合には、修正情報を周知して当該暗号をリストに残す。
５．３．２．電子政府推奨暗号の監視の具体的内容
電子政府推奨暗号の監視は、調査研究、リストからの削除、修正情報の周知等からなる。それぞれの具体的内容は以下（１）〜（４）のとおりとする。
（１） 暗号技術調査・研究及びデータの蓄積
暗号技術に関する調査研究を実施し、国際標準化の動向等種々のデータを蓄積する。
（２）電子政府推奨暗号の削除（イ）電子政府推奨暗号が実運用環境上において攻撃により破られる可能性が高いと判断される場合であって、かつ当該暗号の仕様を変更すること無く攻撃を回避することが不可能であると判断される場合には、当該暗号をリストから削除する。
（ロ）電子政府推奨暗号が実運用環境上において攻撃により破られる可能性が高いと判断される場合であって、かつ当該暗号の仕様を変更すること無く、パラメー
タの修正等の簡易な修正を行うことによって攻撃を回避することが可能であると判断される場合であっても、その方法等を記述した修正情報が当該暗号の仕33

様書の管理者より提案されない場合には、当該暗号をリストから削除する。
（３）電子政府推奨暗号に関する修正情報の周知（イ）電子政府推奨暗号が実運用環境上において攻撃により破られる可能性が高いと判断される場合であって、電子政府推奨暗号の仕様変更ではなくパラメータの修正等の簡易な修正を実施することにより当該攻撃を回避することができると判断される場合には、当該修正方法を修正情報として周知する。
（ロ）（イ）の場合において、修正情報は仕様書の管理者から提案させることとし、監視委員会は、提案された修正情報を加味して当該電子政府推奨暗号の安全性評価を実施する。仕様書の管理者より修正情報の提案がなされない場合には、当該暗号をリストから削除する。
（ハ）監視委員会は応募暗号31以外の電子政府推奨暗号が実運用環境上において攻撃
により破られる可能性が高いとは判断していないにも関わらず、当該暗号に関する修正情報が仕様書の管理者により発行された場合であって（パラメータ修
正等の簡易な修正に限る）、監視委員会が当該修正情報を加味した上で安全性評価を実施し、安全性が確保されていると判断する場合には当該修正情報を周知する。
（４）電子政府推奨暗号の追加（イ）電子政府推奨暗号リストの改訂（新たな電子政府推奨暗号リストの策定及び本
件電子政府推奨暗号リストの廃棄）が行われるまでは、電子政府推奨暗号の追加は例外的な扱いとする。
（ロ）電子政府推奨暗号リストに掲載されていない暗号が国際的に高い評価を得ている場合であって、検討会が当該暗号を新たに評価することが必要と判断し、かつ、評価の結果、検討会が当該暗号を電子政府推奨暗号リストへ掲載することが適切と判断する場合には、当該暗号を電子政府推奨暗号リストへ追加する。
（ハ）電子政府推奨暗号リストへの追加を検討する場合には、「10年間は安心して利用できる」という観点から評価を行う。

31

応募暗号：電子政府推奨暗号のうち、以下のものを指す。
（公開鍵暗号）ECDSA, RSA-PSS, RSA-OAEP, ECDH, PSEC-KEM（共通鍵暗号）CIPHERUNICORN-E, Hierocrypt-L1, MISTY1, Camellia, CIPHERUNICORN-A,
Hierocrypt-3, SC2000, MUGI, MULTI-S01

34

（ニ）電子政府調達者より、電子政府推奨暗号リストに無い新たな用途及び当該用途に適した暗号の追加に関する要望がよせられた場合であって、かつ、検討会としても当該用途の追加が適切と判断した上で、それに適した暗号の評価を実施
し、その結果、適切な暗号を選定した場合には、当該用途及び当該暗号を電子
政府推奨暗号リストへ追加することとする。
５．３．３．電子政府推奨暗号の監視の手順
電子政府推奨暗号の監視の手順は、（１）監視委員会における情報収集、（２）監視委
員会における情報分析、（３）監視委員会及び検討会における審議及び決定の３段階からなる。具体的には以下のとおりとする。ただし、監視委員会が、電子政府推奨暗号リストの変更を直ちに行うべき事態が発生していると判断する場合は、以下に示す手順に関わらず、その緊急性に応じた対応を実施する。
（１）監視委員会における情報収集監視委員会は以下のように情報収集を行うこととする。
（イ）国内外の学会等への参加等を通じて暗号技術に関する情報（学術論文、発表原稿等）を収集する。
（ロ）調査WGメンバー等との連絡体制を整備し、同メンバーから恒常的に情報提供を受ける。
（ハ）応募暗号については、原則として応募元から情報提供を受ける。
（ニ）その他、一般からの情報提供も受ける。
（２）監視委員会における情報分析
監視委員会は、（１）により収集された情報を分析し、電子政府推奨暗号の削除等を検討すべき事態が発生しているか否か判断する。その結果、監視委員会が電子政府
推奨暗号の削除等を検討すべき事態が発生していると判断する場合には、事案の性質に応じて、調査WGを開催する。
（３）監視委員会及び検討会における審議及び決定（イ） 調査WGは、技術的観点から、監視委員会に対して助言を行う。なお、調査WG
は、応募元等より修正情報の提供を受け、同修正情報を加味した暗号の安全性評価も行う。
（ロ）監視委員会は、調査WGの助言を踏まえて、電子政府推奨暗号の削除等を実施するか否かについて素案を作成し、検討会に報告する。

35

（ハ）検討会は、総合的な観点から当該素案を審議し電子政府推奨暗号の削除等に関する案を作成する。同案が電子政府推奨暗号リストに変更を加えるものである
場合、総務省及び経済産業省はパブリックコメントに付し、その結果を検討会に報告する。検討会は、パブリックコメントの結果を踏まえて、電子政府推奨
暗号の削除等に関する案を決定する。
（ニ）検討会の決定に基づいて電子政府推奨暗号リストの変更を行った場合、総務省
及び経済産業省は、電子政府推奨暗号リストの変更について行政情報システム
関係課長連絡会議等に連絡する。

電子政府推奨暗号の削除等の手順

総務省及び
経済産業省

暗号技術検討会⑦暗号技術検討会の決定を踏まえて電子政府推奨暗号リストの変更
について行政情報システム関係課
長連絡会議に連絡⑤監視委員会が必要と判断する
場合には、その緊急性に応じた対応を行うとともに、素案について暗号技術検討会に報告する①電子政府推奨暗号の削除等の検討の必要があると判断する場合、事案の性質に応じて、暗号技術調査ＷＧ
を開催

暗号技術
調査ＷＧ
②対象となる暗号について
技術的な観点から評価を実施③評価結果を踏まえて監視委員会に助言を行う

図3⑥電子政府推奨暗号の削除等に関する案を作成し、必要に応じてパブリックコメ
ントに付した後、最終的に案を決定⑤電子政府推奨暗号の削除等に関する素案を
暗号技術検討会に報告

暗号技術
監視委員会
④技術的観点から電子政府
推奨暗号の削除等について素案を作成

電子政府推奨暗号削除等の手順

５．４．電子政府推奨暗号リストの改訂
５．４．１．基本的認識
電子政府推奨暗号リストには、策定時点において、今後 10 年間は安心して利用できるという観点から選定された暗号が掲載されている。しかし、暗号に対する解析や攻撃

36

の技術や手法はますます高度化しており、電子政府推奨暗号は常に危殆化の危険にさらされている。一方、新たな暗号の開発も進んでおり、今後、安全性や実装性に優れた新しい暗号の出現が期待されるところである。そこで、危殆化した暗号の削除や新しい暗号の選定等により、電子政府推奨暗号リストを一定期間毎に改訂することが望ましい。
改訂を実施する際に、仮に公募を実施する場合は、公募のアナウンス（公募開始時期、
公募期間、評価期間、新リスト発表時期等の公表）から新リストの策定まで、5 年程度の期間をかけることが望ましい。
５．４．２．基本的考え方
リストの改訂作業の具体的な実施内容については、電子政府の導入状況及び電子政府
推奨暗号の監視状況を考慮しつつ、然るべきタイミングで検討を行うこととする。なお、
リスト改訂作業の実施方法としては、現在のところ、以下のような検討事項が想定されるところである。
（想定される検討事項）（イ）公募の要否（ロ）リスト項目（技術分類等）の見直し（ハ）項目別の掲載暗号数（ニ）評価基準、評価方法
また、改訂作業の具体的な開始時期については、検討会において検討の上決定するが、改訂作業の完了及び新リストの決定は、遅くともリスト策定から10年を経た2013年までに行うこととする。なお、仮に公募を実施するとした場合は、5年程度の期間をかけることが望ましいと考えられることから、遅くとも2008年3月頃には公募のアナウンスを行うことが望ましい。
５．５．暗号モジュールに関する検討
電子政府の安全性及び信頼性を確保するためには、暗号技術レベルの安全性だけでなく暗号技術の実装の安全性を確保する必要があり、この観点から暗号モジュールの安全性評
価基準を作成することが急務である。他方、暗号モジュールの安全性評価基準に関しては、米国が自国の政府調達基準であるFIPS140-2のISO/IEC化を提案しており、暗号モジュールの安全性評価基準を我が国において作成するにあたっては、ISO/IEC等における議論を注視していく必要がある。
このような状況を踏まえて、暗号モジュール委員会は、ISO等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用され得ることをも視野に入れながら、暗号モ
ジュール評価基準及び試験基準を作成する。
なお、暗号モジュール委員会は、監視委員会と連絡をとりつつ、電子政府推奨暗号の安全性及び信頼性確保のための暗号実装関連技術を主な対象とする調査・検討を併せて行う

37

こととする。

38

参考資料「各府省の情報システム調達における暗号の利用方針」

各府省の情報システム調達における暗号の利用方針
平成１５年２月２８日
行政情報システム関係課長連絡会議了承

電子政府における情報セキュリティ確保のために、各府省の情報システムにおいて暗号を利用する場合には、一定水準以上の安全性及び信頼性を有する暗号の利用が不可欠であり、また、その安全性・信頼性は客観的な評価を得たものであることが必要である。
かかる観点から、「電子政府の情報セキュリティ確保のためのアクションプ
ラン」（平成１３年１０月１０日、情報セキュリティ対策推進会議）に基づき、総務省及び経済産業省において、電子政府における調達のための推奨すべき暗号のリスト（「電子政府推奨暗号リスト」：別添参照）を策定したところである。
これを踏まえ、各府省は、情報システムの構築に当たり暗号を利用する場合には、調達仕様書において上記暗号リストに掲載された暗号を利用することを入札要件とする等の方法により、必要とされる安全性・信頼性などに応じ、可能な限り、「電子政府推奨暗号リスト」に掲載された暗号の利用を推進するものとする。
なお、総務省及び経済産業省は、「電子政府推奨暗号リスト」に掲載された暗号の安全性及び信頼性について、今後の情報通信技術の進展を踏まえ必要に応じ評価を行うとともに、「電子政府推奨暗号リスト」の内容の変更を行う場
合には本会議に報告することとする。

別添

電子政府推奨暗号リスト
平成１５年２月２０日
総
経
技術分類

務
済

産

省
業

省

名称
署名

公開鍵暗号

守秘
鍵共有

64 ビットブロック暗号(注 3)

共通鍵暗号

128 ビットブロック暗号

ストリーム暗号

ハッシュ関数その他
擬似乱数生成系(注 7)

DSA
ECDSA
RSASSA-PKCS1-v1̲5
RSA-PSSRSA-OAEP
RSAES-PKCS1-v1̲5(注 1)
DH
ECDH
PSEC-KEM(注 2)
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1
3-key Triple DES(注 4)
AES
Camellia
CIPHERUNICORN-A
Hierocrypt-3
SC2000MUGI
MULTI-S01
128-bit RC4(注 5)
RIPEMD-160(注 6)
SHA-1(注 6)
SHA-256
SHA-384
SHA-512PRNG based on SHA-1 in ANSI X9.42-2001 Annex C.1
PRNG based on SHA-1 for general purpose in FIPS
186-2 (+ change notice 1) Appendix 3.1
PRNG based on SHA-1 for general purpose in FIPS
186-2 (+ change notice 1) revised Appendix 3.1

注釈：
(注 1)

SSL3.0/TLS1.0 で使用実績があることから当面の使用を認める。

(注 2)

KEM（Key Encapsulation Mechanism）-DEM(Data Encapsulation Mechanism)構成における利用を前提とする。

(注 3)

新たな電子政府用システムを構築する場合、より長いブロック長の暗号が使用できるのであれば、128 ビットブロック暗号を選択することが望ましい。

(注 4)

3-key Triple DES は、以下の条件を考慮し、当面の使用を認める。
1) FIPS46-3 として規定されていること
2) デファクトスタンダードとしての位置を保っていること(注 5)128-bit RC4 は、SSL3.0/TLS1.0 以上に限定して利用することを想定している。なお、リストに掲載されている別の暗号が利用できるのであれば、そちらを使用することが望ま
しい。

(注6)

新たな電子政府用システムを構築する場合、より長いハッシュ値のものが使用できるのであれば、256ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべきハッシュ関数が指定されている場合には、この限りではない。

(注7)

擬似乱数生成系は、その利用特性上、インタオペラビリティを確保する必要性がないた
め、暗号学的に安全な擬似乱数生成アルゴリズムであれば、どれを利用しても基本的に問題が生じない。したがって、ここに掲載する擬似乱数生成アルゴリズムは「例示」である。

参考資料「暗号調達のためのガイドブック」

暗号調達のためのガイドブック

平成１５年３月
暗号技術検討会
暗号調達ガイドブック作成ワーキンググループ

目次
１．

背景.......................................................................1

２．

本ガイドブックの利用にあたって .............................................2

２．１ 本ガイドブックについて ...................................................2
２．２ 本ガイドブックの位置付け .................................................3
３．

暗号調達、及び関連する暗号技術の概要 .......................................5

３．１ システム全体の検討作業と暗号調達の作業の関わり ...........................7
３．２ 暗号調達に必要な暗号関連の技術的概念 ....................................14４．

調達の手順................................................................16

４．１ 概要....................................................................24
４．２ 調達仕様書の作成 ........................................................26
４．２．１

調達者指定モデルの場合..............................................26

４．２．２ 提案審査モデルの場合 ................................................40
４．２．３ 調達仕様書作成上の留意点 ............................................42
４．３ 調達先決定..............................................................45
４．３．１ 調達者指定モデルの場合 ..............................................45
４．３．２ 提案審査モデルの場合 ................................................46
４．４ 契約....................................................................47
４．５ 納品....................................................................47
５．

連絡先....................................................................49

６．

参考資料..................................................................50

７．

用語集....................................................................51【参考資料】
参考１

各府省の情報システム調達における暗号の利用方針（別添：電子政府推奨暗号リスト）

参考２

評価・特徴一覧（公開鍵暗号）
評価・特徴一覧（共通鍵暗号）評価・特徴一覧の利用にあたって

１．

背景

高度情報通信ネットワーク社会形成基本法に基づく e‑Japan 重点計画及び e‑Japan 重点
計画‑2002 においては、我が国の高度情報通信ネットワークの安全性及び信頼性を世界最先端のＩＴ国家にふさわしいものにするため、高度情報通信ネットワークにおける脅威に起因するサービス提供機能の停止が最小限となるように、政府は各種の施策を実施することとしている。特に、電子署名等の電子認証の普及、電子政府の構築等に向けて、高度情報
通信ネットワークの安全性及び信頼性を確保するためには、基盤技術である暗号技術について、客観的な評価や標準化が重要である。
このため、総務省及び経済産業省は、平成１３年５月から「暗号技術検討会（座長：
今井秀樹東京大学教授）」を開催し、電子政府利用等に資する暗号技術の評価等を実施してきた。なお、従来は「暗号技術評価委員会（委員長：今井秀樹東京大学教授）」をＣＲＹＰＴＲＥＣと称したが、平成１４年度からは「暗号技術検討会」及び、「暗号技術評価委員会」の両者を含めて、ＣＲＹＰＴＲＥＣ（Cryptography Research and Evaluation Committees）
プロジェクトとして暗号技術の評価等の活動を継続している。その活動の成果として、安
全性が客観的に評価され、実装性に優れた暗号技術が、電子政府における調達のための推奨すべき暗号（電子政府推奨暗号）としてリスト化（電子政府推奨暗号リスト）された。
各府省は、「各府省の情報システム調達における暗号の利用方針（平成１５年２月２８日、
行政情報システム関係課長連絡会議了承）」（以下、「連絡会議了承」）により、各府省における暗号技術の利用方針について合意したところである。
各府省が電子政府システムを構築する際、電子政府推奨暗号リストを活用し、適切な暗号を調達することが重要であることから、総務省及び経済産業省は、適切な電子政府推奨
暗号を調達するための手引書として「暗号調達のためのガイドブック」を作成した。

− 1 −

２．

本ガイドブックの利用にあたって

電子政府システムにおける重要な課題である情報セキュリティを確保するための方策として、暗号技術の利用が考えられる。「連絡会議了承」では、各府省が電子政府システムで利用する暗号を調達する際には、電子政府推奨暗号リストに掲載された暗号アルゴリズム
を可能な限り利用する旨、合意されている。
本ガイドブックの目的は、各府省の調達担当者が、適切な暗号アルゴリズムを円滑に調達することができるよう、一つの道筋を示すことである。なお、本ガイドブックに引用されている掲載例はあくまでも一つの参考であり、各府省の調達担当者が実際に調達を実施するにあたっては、掲載例自体を引用するのではなく、掲載例を参照しつつ個別の具体的な状況に応じた適切な調達を実施する必要がある。

２．１

本ガイドブックについて（１）「暗号調達のためのガイドブック」とは「暗号調達のためのガイドブック」は、電子政府システムの調達に際し、暗号技術を利用したセキュリティ確保が必要な場合に、調達者が効率的に電子政府推奨暗号の調達を進められるよう、調達における電子政府推奨暗号リストの利用手順や考え方について説明するものである。
（図２．１−１参照）
ガイドブック

電子政府システムの要件

各種手順
調達仕様書作成

電子政府推奨暗号
の調達
調達者

調達先決定

調達作業
検収、運用等調達仕様書

図２．１−１

本ガイドブックの位置付け− 2 −電子政府推奨暗号リスト

（２）本ガイドブック利用のメリット
本ガイドブックは、電子政府システムの構築の際、電子政府推奨暗号リストを活用して効率的に電子政府推奨暗号を調達することを目的として作成された。本ガイドブックを利用することにより、以下のようなメリットが得られる。
調達に必要な暗号関連の技術や用語の概要が把握できる。
ガイダンスに沿って電子政府推奨暗号の調達を進められる。

２．２

本ガイドブックの位置付け

ここでは、本ガイドブックと関係の深い電子政府推奨暗号リスト、及び、情報機器等の情報セキュリティ関連国際規格である ISO/IEC15408 と本ガイドブックの関係について説明する。
（１）電子政府推奨暗号リストについて
本ガイドブックにおいて利用を推奨する電子政府推奨暗号リストは、以下の想定のもとに、電子政府推奨暗号を技術的観点から分類し、リスト化したものである。
● 想定システム：電子申請システムや電子入札システム等、政府と国民との間で書類の申請等についてやりとりを行う必要があるシステムを想定する。（国防関係の特別なシステムや、政府内限りのやりとりを行うシステムについて
は、この対象としない。
）●

耐用期間：１０年間は安心して利用できる暗号アルゴリズムを想定する。

● リストの見直し：

今後の電子政府推奨暗号の電子政府における利用状況等も踏まえ、
平成１５年度以降、CRYPTREC において具体的に検討する。

− 3 −（２）ISO/IEC15408 を活用した調達と暗号調達の関連について
セキュリティ関連のシステム調達に関するガイドブックとして、本ガイドブックの他に、「ISO/IEC15408 を活用した調達のガイドブック（経済産業省情報セキュリティ政策室発行、
http://www.meti.go.jp/policy/netsecurity/downloadfiles/CCguide̲ver1̲06.pdf）」がある。このガイドブックは、国際標準である ISO/IEC15408 に基づいて評価又は認証された製品等の調達を効率的に行えるように、調達の仕方等について説明をしたものである。
ISO/IEC15408 では、セキュリティ確保の具体的な方法の一つである暗号技術の選択については触れていないため、ISO/IEC15408 の認証を取得している製品やシステムであっても、
電子政府推奨暗号リストに掲載されていない暗号アルゴリズムが使われている場合もある。
このため、「ISO/IEC15408 を活用した調達のガイドブック」に従って暗号機能を含む製品・システムを調達しても、安全な暗号技術が調達できるとは限らないことから、本ガイドブッ
クにおいて、暗号技術の選定を中心に説明するものである。
したがって、図２．２−１に示すとおり、セキュリティ確保に関する諸要件と暗号要件をそれぞれに指定して調達を進める場合は、それぞれのガイドブックを参照し、セキュリ
ティ確保に関する諸要件の一部として暗号要件を指定する場合には、セキュリティ確保全体については「ISO/IEC15408 を活用した調達のガイドブック」を参照したうえで、暗号要件の選定に関してのみ、本ガイドブックを参照することを意図している。
●セキュリティ要件と暗号要件が並立する場合
ガイドブック

調達仕様書

ISO/IEC15408
活用ガイドブック

セキュリティ要件記述

暗号調達のためのガイドブック

暗号要件記述●セキュリティ要件に暗号要件が含まれる場合
ガイドブック

調達仕様書
セキュリティ要件記述

ISO/IEC15408
活用ガイドブック・セキュリティ要件１・ 暗号要件記述

・セキュリティ要件２

暗号調達のためのガイドブック

図２．２−１ ISO/IEC15408 を活用した調達と暗号調達の関連

− 4 −

３．

暗号調達、及び関連する暗号技術の概要

電子政府システムの調達における暗号の調達手順については第４章で詳細に説明するが、この章では第４章で説明する調達手順を理解し、実行するために必要な事項、すなわちシステム全体の検討作業と暗号調達の作業の関わり、及び暗号調達に必要な暗号関連の技術的概念について説明する。
暗号はセキュリティ対策の一部として利用されるので、暗号を調達するにあたっては、その前段として、システム全体を見たときに、どのような目的で暗号を利用すべきかの整理をしておく必要がある。この作業がリスク分析である。図３−１にシステム全体で行う作業に占める暗号調達（調達仕様書作成作業）の位置付けを示す。

システム構築作業
システム基本検討

システム設計システム開発／試験

リスク分析
システム調達仕様書の作成暗号調達
仕様書の作成図３−１ システム全体の作業に占める暗号調達（調達仕様書作成作業）の位置付け− 5 −以下では、３．１節において、（１）でシステム全体として行う作業のうち暗号調達に深い関連を持つリスク分析について概説し、（２）で実際の電子政府システムにおいて暗号が利用されるイメージの例示を行う。
また、３．２節において、暗号調達の主要な手順である暗号アルゴリズムを選定するまでの道筋（図３−２参照）を意識しながら、この手順を進めるうえで必要となる技術的概念、
すなわち、暗号利用形態、暗号技術分類、暗号アルゴリズムの３つについて説明する。

具体的

４．２．１節（４）暗号アルゴリズムの選定

暗号の具体性４．２．１節（３）
暗号技術分類の選定

４．２．１節（２）
暗号利用形態の選定

３．１節（１）
リスク分析
調達する
システムの
イメージ

暗号に
関する
要件

３．２節（１）暗号
利用形態

３．１節（２）
暗号利用
イメージ

３．２節（３）暗号
アルゴリズム３．２節（２）
暗号
技術分類

調達成作業
号
暗 書作

達仕
（調

）

様

凡例
システム全体で行うべき作業・ステップの一部
暗号を具体化・絞り込むためのステップ

曖昧

調達者が行うべき作業

図３−２

暗号を具体化・絞り込みを行うためのステップ

− 6 −

３．１

システム全体の検討作業と暗号調達の作業の関わり（１） リスク分析と暗号調達の関わり
電子政府システムのような社会的影響の大きなシステムにおいては、セキュリティが重要な要件であるため、システムの基本検討の段階においてセキュリティ関連の要件を整理する必要がある。このためにリスク分析の作業が行われる。リスク分析の手順については、様々な方法が考えられるが、最も標準的なものとしては、ISO/IEC15408 に準拠した手順が考えられる。
リスク分析等の作業の中で、暗号調達を進めるにあたって必要な事項は、該当システムに必要な暗号利用の目的の決定、及びその他の暗号技術への要件（暗号化の処理速度など）の決定である。
暗号利用の目的については、作業を標準化するため、電子政府システムにおける暗号利用の目的を４つに類型化して暗号利用形態を定義している。この整理した暗号利用形態については、３．２節（１）にて解説する。

− 7 −（２）電子政府システムにおける暗号利用イメージ
本節では、システムにおける暗号利用を理解するために重要な以下の要素、・調達するシステムが実現する機能・調達するシステムの構成要素（装置、人物、組織）・各要素間で授受される情報（電子情報、鍵情報など）を抽出、整理したうえで、電子政府システムにおける暗号の利用に関するイメージをまとめたものである。
すべての電子政府システムについて個別に説明することはできないので、電子政府システ
ムのうち暗号の利用が想定される主な 5 つのシステムにおける暗号利用イメージを例示、
解 説 し て い る 。 な お 、 例 示 し た シ ス テ ム モ デ ル は 、「 e‑Japan 重 点 計 画 − 2002
（http://www.kantei.go.jp/jp/singi/it2/index.html）」にも挙がっている 4 つのシステ
ムモデルと、それらの共通基盤となるシステムモデルのあわせて 5 つである。
電子申請システムモデル
e‑Japan 重点計画‑2002 では「申請・届出等手続の電子化」と表現している。
電子調達システムモデル
e‑Japan 重点計画‑2002 では「調達手続の電子化」と表現している。
電子納付システムモデル
e‑Japan 重点計画‑2002 では「歳入・歳出の電子化」と表現している。
電子情報提供システムモデル
e‑Japan 重点計画‑2002 では「行政情報の電子的提供」と表現している。
政府認証基盤
上記４システムモデルの共通基盤。
以下に、この 5 つの暗号利用システムモデルについて説明する。
なお、これら暗号利用システムモデルについては、参考資料「暗号技術検討会 2001 年度報告書」（http://www.soumu.go.jp/s‑news/2002/020416̲2.html

又は

http://www.meti.go.jp/policy/netsecurity/crypt.htm）に記載されているので、詳細についてはそちらを参照されたい。

− 8 −

a)

電子申請システムモデル

電子申請システムとは、利用者（個人ならびに法人）が政府（中央官庁）に対して行っている現行の申請・届出手続きを、インターネットのようなオープンなネットワークを介して電子的に行うことができるようにするものである。
電子申請システムにおける要素と、要素間で授受される主な情報を図にしたもの（モデル図と呼ぶ）を図３．１−１に示す。
個別業務システムのサーバ

中央官庁

申請

電子証明書

結果通知

汎用受付等
システムの
サーバ

審査官の端末民間認証局

府省認証サーバ

申請の審査官

申請・
問い合わせ

電子証明書
結果通知

申請者

申請者端末

図３．１−１

電子申請システムのモデル図

図３．１−１は、図中左下の申請者が、図中右上の政府（中央官庁）に対して、インターネットを介して電子的に申請を行い、政府の審査官がその内容を審査し、審査結果を返信している状況を表している。
当該システムにおいては、利用者と審査官の間の通信において、相手認証、署名、守秘が、また、それらの通信に必要な暗号化の鍵情報について、鍵共有の暗号利用形態が想定
される。

− 9 −

b)

電子調達システムモデル

電子調達システムとは、政府（中央官庁）が行っている調達業務のうち、入札参加申請、入開札、落札者通知を、インターネットのようなオープンなネットワークを介して電子的に行うことができるようにしたシステムである。
電子調達システムにおけるモデル図を図３．１−２に示す。
汎用受付等
システムの
サーバ
民間認証局

中央官庁

入札参加
資格申請

電子入札システム

入札参加

電子証明書
資格認定
通知

落札結果通知入札者

図３．１−２

電子調達システムのモデル図

図３．１−２は、図中左下の入札者が、図中右上の政府（中央官庁）に対して、インターネットを介して電子的に入札参加申請を行った上で、入札を行い、落札結果を受け取っている状況を表している。
当該システムにおいては、入札者と中央官庁の間の通信において、相手認証、署名、守秘が、また、それらの通信に必要な暗号化の鍵情報について、鍵共有の暗号利用形態が想定される。

− 10 −

c)

電子納付システムモデル

電子納付システムとは、個人ならびに法人が政府（中央官庁）に対して行っている税金
や行政手数料等の納付業務を、インターネットのようなオープンなネットワークを介して電子的に行うことができるようにするものである。
電子納付システムにおけるモデル図を図３．１−３に示す。
歳入金電子納付システム

財務省会計センター
日本銀行
納付
納付情報

納付番号・
申請者情報通知民間金融機関

汎用受付等
システムの
サーバ

中央官庁
申請・届出

納付済
の通知
納付番号・
納付依頼

納付番号・
金額通知

申請者・
納付者

図３．１−３

電子納付システムのモデル図

図３．１−３は、図中左下の申請者・納付者が、図中右の政府（中央官庁）に対して納付の申請手続きを行った上で、図中左の民間金融機関を経由して日本銀行の政府口座に入金し、図中上の財務省会計センターで申請と入金の突き合わせ確認を行っている状況を表している。
図３．１−３のうち、申請者・納付者と中央官庁間は電子申請システムの対象であり、また納付者と民間金融機関間は民間のシステムが実現すべき部分である。
当該システムにおいては、民間金融機関と財務省会計センター間の通信において、相手認
証、署名、守秘が、また、それらの通信に必要な暗号化の鍵情報について、鍵共有の暗号利用形態が想定される。

− 11 −

d)

電子情報提供システムモデル

電子情報提供システムとは、個人ならびに法人が政府（中央官庁）により提供されている情報に、インターネットのようなオープンなネットワークを介して電子的にアクセスできるようにするものである。
電子情報提供システムにおけるモデル図を図３．１−４に示す。

利用者情報
管理サーバ

ＤＢサーバ

フロントエンド
サーバ
中央官庁
民間認証局
電子証明書

利用者
図３．１−４

電子情報提供システムのモデル図

図３．１−４は、図中左下の利用者が、図中右上の政府（中央官庁）サーバにアクセス
し、情報の提供を受けている状況を表している。
当該システムにおいては、政府からの情報提供にあたり申請・登録等による利用者の認証を想定しており、利用者と中央官庁との間の通信において、相手認証（利用者は必要に応じて認証局(ＣＡ)に登録する）、署名、守秘の暗号利用形態が、また、それらの通信に必要な暗号化の鍵情報について、鍵共有の暗号利用形態が想定される。

− 12 −

e)

政府認証基盤

政府認証基盤は、官職の認証や申請、届出等の情報の真正性を確保する等のために用いられる、公開鍵暗号方式をベースにした電子認証システムであり、現在ＧＰＫＩとして実用化されている。
政府認証基盤におけるモデル図を図３．１−５に示す。
中央官庁
相互認証

ブリッジ認証局
行政機関認証局
証明書検査

電子証明書

相互認証
承認等

電子政府
システム

電子証明書

民間認証局
電子申請・
入札等
電子証明書

電子証明書

官職

利用者

図３．１−５

政府認証基盤のモデル図

図３．１−５は、図中右上の政府（中央官庁）の官職、または図中左下の利用者が電子
政府システムを利用するにあたり、図中右上の行政機関認証局、または図中左の民間認証局から電子証明書の発行を受けている状況、ならびにそれら証明書の有効性を検証するための手段を提供するブリッジ認証局（図３．１−５の中央上）を表している。
当該システムは電子政府システムにおける相手認証及び署名の暗号利用形態を支援して、認証のために必要な情報を管理するシステムである。

− 13 −

３．２

暗号調達に必要な暗号関連の技術的概念（１）暗号利用形態の解説
暗号利用形態とは、電子政府システムにおける暗号利用の目的を整理、分類したものである。
表３．２−１では、電子政府システムにおける暗号利用の目的を整理、分類した 4 つの暗号利用形態について説明している。
表３．２−１
暗号利用形態
相手認証
鍵共有
守秘

署名

暗号利用形態一覧

概要
やりとりの相手の正当性を保証すること
インターネット等のオープンなネットワークを用いて共通鍵暗号技術を利用する際に、通信の当事者間で鍵情報を共有すること
インターネット等のオープンなネットワークや、記録媒体を使って電子情報をやりとりするときに、知られて良い利用者以外には内容を知られないようにすること
電子情報が正当であることを確認できるようにすること
このことは、電子情報自体が改竄されていないかを確認できることと、署名を作った者を第三者が確認できることの二つの目的を同時に満たすことを意味する− 14 −

（２）暗号技術分類の解説
暗号技術分類とは、暗号アルゴリズムを、機能的、技術的に類似するグループに整理及び分類したものである。
表３．２−２では、現存する暗号アルゴリズムを機能的、技術的に整理及び分類した 4 つの暗号技術分類について説明している。
なお、これらの暗号技術分類のうち、中核となるものが公開鍵暗号と共通鍵暗号であり、ハッシュ関数と擬似乱数生成は、公開鍵暗号または共通鍵暗号に付随して用いられることが多い。
表３．２−２
暗号技術分類
公開鍵暗号

共通鍵暗号

ハッシュ関数

擬似乱数生成暗号技術分類一覧概要
公開鍵と秘密鍵という対をなす２種類の鍵を用いる暗号（または暗号技
術）を総称して公開鍵暗号（または公開鍵暗号技術）という。公開鍵から秘密鍵を求めることは計算の手間が膨大となり事実上困難であるという特性を持っている。守秘のための方式と署名のための方式とに大別でき、前者を（狭い意味で）公開鍵暗号方式、後者を公開鍵署名方式と呼んで区別することがある。前者の意味での公開鍵暗号方式においては、平文を暗号化する時に用いる鍵（暗号化鍵）が公開鍵であり、暗号文を復号する時に用いる鍵（復号鍵）が秘密鍵である。公開鍵署名方式においては、平文に対して署名文を生成する時に用いる鍵（署名生成鍵）が秘密鍵であり、署名文を検査し平文を取り出す時に用いる鍵（署名検査・復号鍵）が公開鍵である。
平文を暗号化する時に使用する鍵と、暗号文を復号する時に使用する鍵が共通の暗号方式。
高速性に優れているが、共通鍵の配送を安全に行うことが求められる。
共通鍵暗号は、データを一定の長さ（ブロック）に分割し、ブロック単位で処理を行う方式（ブロック暗号）と、データを 1 ビットないし 1 バイト
程度の短い単位で処理する方式（ストリーム暗号）に分けることができる。
入力データの長さに関わらず、固定長のハッシュ値を出力する関数。ハッシュ関数には、出力から入力を簡単に計算できない一方向性と、異なる 2つの入力に対し同じハッシュ値を出力しない無衝突性が求められる。
暗号学的に安全な乱数 *1 にできるだけ近づけた数の系列を人為的に生成する仕組み。

*1) 「暗号学的に安全な乱数」とは、過去の履歴から次の値が予測できないような数字列を意味する。

− 15 −

（３）電子政府推奨暗号の概要
ここでは、電子政府推奨暗号の概要を説明する。なお、詳細については、以下の資料等を参照のこと。
・JIS‐TR X0050（暗号技術評価報告書

CRYPTREC Report 2000）（http://www.meti.go.jp/policy/netsecurity/crypt.htm 又は
http://www.ipa.go.jp/security/enc/CRYPTREC/fy12/cryptrec20010418.html）
・暗号技術検討会 2001 年度報告書（http://www.soumu.go.jp/s‑news/2002/pdf/020416̲2̲a.pdf 又は
http://www.meti.go.jp/policy/netsecurity/downloadfiles/cryptrec2001report.pdf）
・JIS‑TR X0087（暗号技術評価報告書(2001 年度版) CRYPTREC Report 2001）（http://www.meti.go.jp/policy/netsecurity/crypt.htmの「CRYPTREC Report 2001」、

http://www.ipa.go.jp/security/enc/CRYPTREC/fy14/cryptrec20020418̲report01.html
http://www.shiba.tao.go.jp/kenkyu/CRYPTREC/fy14/cryptrec20020418̲report01.html）
・暗号技術検討会 2002 年度報告書（http://www.soumu.go.jp/

又は

http://www.meti.go.jp/
・暗号技術評価報告書 2002 年度版）
CRYPTREC Report 2002

（http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/cryptrec20030401̲report01.html
http://www.shiba.tao.go.jp/kenkyu/CRYPTREC/fy15/cryptrec200304̲report02.html）

a)

公開鍵暗号

（署名）
●

DSA(Digital Signature Algorithm)
米国規格協会(ANSI: American National Standards Institute)が ANSI X9.30:1‑1997
として 1997 年に標準化した離散対数問題の困難性に基づく署名方式。
我が国の「電子署名及び認証業務に関する法律に基づく特定認証業務の認定に係る指針（以下、電子署名法の指針）」にも記載されている。
また、市販のブラウザソフト等に多く用いられている暗号プロトコル SSL(Secure
Socket Layer)3.0/TLS（Transport Layer Security）1.0 に採用されている。

− 16 −●

ECDSA（Elliptic Curve Digital Signature Algorithm）
楕円曲線暗号の標準仕様策定のためのコンソーシアムである SECG（Standards for
Efficient Cryptography Group）が策定している SEC 1: Elliptic Curve
Cryptography(Version 1.0)（以下、SEC 1）で 2000 年に規格化された楕円曲線上の離散対数問題の困難性に基づく署名方式。CRYPTREC へは富士通株式会社から応募されている。
我が国の電子署名法の指針にも一部のパラメータを除いて適合している。
欧州の暗号評価事業である NESSIE（New European Schemes for Signatures, Integrity,
Encryption）プロジェクトにおいて、推奨アルゴリズムに選定されている。

●

RSASSA‑PKCS1‑v1̲5(RSA Signature Scheme with Appendix based on PKCS#1 v1.5)
米 RSA 研究所が策定している暗号規格 PKCS（Public Key Cryptography Standards）
シリーズの１つである PKCS #1 Version 2.1 で 2002 年に RSASSA‑PKCS1‑v1̲5 として規格化された素因数分解問題の困難性に基づく署名方式で、PKCS #1 Version 1.5 で 1993
年に規格化された署名方式とはハッシュ関数の選択に関して、MD4 が除かれ、SHA‑1、SHA‑256、SHA‑384、SHA‑512 が追加されたことを除いて同じである｡
我が国の電子署名法の指針にも記載されている。また、PKCS #1 Version 1.5 で規格化された署名方式が SSL3.0/TLS1.0 に採用されている。

●

RSA‑PSS(RSA Public‑Key Cryptosystem with Probabilistic Signature Scheme)
米 RSA 研究所が策定している暗号規格 PKCS シリーズの１つである PKCS #1 Version
2.1 で RSASSA‑PSS として 2002 年に規格化された素因数分解問題の困難性に基づく証明
可能安全性を有する署名方式。CRYPTREC へは RSA セキュリティ株式会社から応募されている。
我が国の電子署名法の指針にも記載されている。
NESSIE プロジェクトにおいて、推奨アルゴリズムに選定されている。

（守秘）●

RSA‑OAEP(RSA Public‑Key Cryptosystem with Optimal Asymmetric Encryption Padding)
米 RSA 研究所が策定している暗号規格 PKCS シリーズの１つである PKCS #1 Version
2.1 で 2002 年に RSAES‑OAEP として規格化された素因数分解問題の困難性に基づく証明
可能安全性を有する守秘方式で、PKCS #1 Version 2.0 で 1998 年に RSAES‑OAEP として規定された守秘方式と同じである。CRYPTREC へは RSA セキュリティ株式会社から応募されている。

− 17 −●

RSAES‑PKCS1‑v1̲5(RSA Encryption Scheme based on PKCS#1 v1.5)
米 RSA 研究所が策定している暗号規格 PKCS シリーズの１つである PKCS #1 Version
2.1 で 2002 年に RSAES‑PKCS1‑v1̲5 として規格化された素因数分解問題の困難性に基づく守秘方式で、PKCS #1 Version 1.5 で 1993 年に規定された守秘方式と同じである。
PKCS #1 Version 1.5 で規格化された守秘方式が SSL3.0/TLS1.0 に採用されている。
【CRYPTREC からのコメント】《注意》SSL3.0/TLS1.0 で使用実績があることから、当面の使用を認める。

（鍵共有）
●

DH（Diffie‑Hellman）
米国規格協会が ANSI X9.42‑2001 として 2001 年に標準化した離散対数問題の困難性に基づく鍵共有方式で、1976 年に W. Diffie と M. E.. Hellman が論文（"New Directions
in Cryptography," IEEE Transactions on Information Theory, vol. IT‑22, pp. 644‑
654, Nov. 1976）で発表した鍵共有方式に基づくものである。
W. Diffie と M. E.. Hellman が論文で発表した鍵共有方式が SSL3.0/TLS1.0 に採用されている。

●

ECDH(Elliptic Curve Diffie‑Hellman Scheme)
SECG が策定している SEC 1 で 2000 年に規格化された楕円曲線上の離散対数問題の困難性に基づく鍵共有方式で、DH における離散対数計算を楕円曲線上の離散対数計算に置き換えたものである。CRYPTREC へは富士通株式会社から応募されている。

●

PSEC‑KEM
日本電信電話株式会社が 2001 年に提案した、楕円曲線上の離散対数問題の困難性に基づく鍵カプセル化メカニズム。CRYPTREC へは日本電信電話株式会社から応募されている。
NESSIE プロジェクトにおいて推奨アルゴリズムに選定されている。
【CRYPTREC からのコメント】《注意》KEM(Key Encapsulation Mechanism)‑DEM(Data Encapsulation Mechanism)
構成における利用を前提とする。

− 18 −

b)

共通鍵暗号（64 ビットブロック暗号）【CRYPTREC からのコメント】《注意》共通鍵ブロック暗号を使用して新たな電子政府用システムを構築する場合、より長いブロック長の暗号が利用できるのであれば、128 ビットブロック暗号を選択することが望ましい。
CIPHERUNICORN‑E
1998 年に日本電気が発表した、鍵長 128 ビットの 64 ビットブロック暗号である。

Hierocrypt‑L1
2000 年に東芝が発表した、鍵長 128 ビットの 64 ビットブロック暗号である。

MISTY1
1996 年に三菱電機が発表した、鍵長 128 ビットの 64 ビットブロック暗号である。
NESSIE プロジェクトにおいて、推奨アルゴリズムに選定されている。

3‑key Triple DES（Data Encryption Standard）
鍵長 168 ビットの 64 ビッ
1979 年に FIPS 認定された DES *1 の組み合わせ暗号である、
トブロック暗号。1998 年に NIST により FIPS46‑3 として標準化され、ANSI X9.52 としても規格化されている。SSL3.0/TLS1.0 に採用されている。
*1）DES： 1977 年に FIPS46 として標準化された、鍵長 56 ビットの 64 ビットブロッ
ク暗号【CRYPTREC からのコメント】《注意１》3‑key Triple DES は、以下の条件を考慮し、当面の使用を認める。
1) FIPS46‑3 として規定されていること
2) デファクトスタンダードとしての地位を保っていること《注意２》Triple DES には鍵長 112 ビットの 2‑key Triple DES もあるが、CRYPTRECとして 2‑key Triple DES の使用は推奨しない。

− 19 −

（128 ビットブロック暗号）

AES
2001 年に、Rijndael *2 をもとに、NIST が FIPS 197 として標準化した、鍵長 128 ビット、192 ビット、256 ビットの 128 ビットブロック暗号である。
NESSIE プロジェクトにおいて、推奨アルゴリズムに選定されている。
*2）Rijndael： 1998 年にベルギーの J.Daemen と V.Rijmen により AES プロジェク
トに提案され、2000 年に AES Winner に選定されたブロック暗号

Camellia
2000 年に発表された、NTT と三菱電機の共同開発による、鍵長 128 ビット、192 ビッ
ト、256 ビットの 128 ビットブロック暗号。
NESSIE プロジェクトにおいて、推奨アルゴリズムに選定されている。

CIPHERUNICORN‑A
2000 年に日本電気が発表した、鍵長 128 ビット、192 ビット、256 ビットの 128 ビットブロック暗号である。

Hierocrypt‑3
2000 年に東芝が発表した、鍵長 128 ビット、192 ビット、256 ビットの 128 ビットブロック暗号である。

SC20002000 年に発表された、富士通と東京理科大学の共同研究による、鍵長 128 ビット、
192 ビット、256 ビットの 128 ビットブロック暗号である。

− 20 −

（ストリーム暗号）

MUGI
2001 年に日立製作所が発表した、鍵長 128 ビットのストリーム暗号である。

MULTI‑S01
2000 年に日立製作所が発表した、鍵長 256 ビットのストリーム暗号である。

128‑bit RC41987 年に RSA セキュリティ社（当時 RSA データセキュリティ社）が発表した、鍵長128 ビットのストリーム暗号である。SSL3.0/TLS1.0 に採用されている。
【CRYPTREC からのコメント】《注意》 128‑bit RC4 は、SSL3.0/TLS1.0 に限定して利用することを想定している。なお、リストに掲載されている別の暗号が利用できるのであれば、可能な限りそちらを使用することが望ましい。
《警告》 RC4 は、SSL3.0/TLS1.0 では鍵長 40 ビットと鍵長 128 ビットを選択して利用することが可能であるが、RC4 を使うとしても、安全性確保の観点から、
CRYPTREC としては、鍵長 128 ビットで利用すべきであり、鍵長 40 ビットでの利用は避けるべきであると警告する。

c)

ハッシュ関数【CRYPTREC からのコメント】《注意》新たな電子政府用システムを構築する場合、より長いハッシュ値のものがが利用できるのであれば、256 ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべきハッシュ関数が指定されている場合は、この限りではない。
RIPEMD‑160
1997 年に、RIPEMD *3 の安全性強化版として、H. Dobbertin、A. Bosselaers、B. Preneelにより提案された、出力ハッシュ値 160 ビット長のハッシュ関数である。ISO/IEC
10118‑3 に採用されている。
*3）RIPEMD： ヨーロッパの RIPE（RACE Integrity Primitive Evaluation）プロジェ
クトで策定されたハッシュ関数− 21 −

SHA‑1
1994 年に NIST が FIPS 180 として標準化した、出力ハッシュ値 160 ビット長のハッシュ関数である。我が国の電子署名法の指針に記載されている。ISO/IEC 10118‑3、SSL3.0/TLS1.0 に採用されている。

SHA‑256
2002 年に NIST が FIPS 180‑2 として標準化した、出力ハッシュ値 256 ビット長のハッシュ関数である。
NESSIE プロジェクトにおいて推奨アルゴリズムに選定されている。

SHA‑384
2002 年に NIST が FIPS 180‑2 として標準化した、出力ハッシュ値 384 ビット長のハッシュ関数である。
NESSIE プロジェクトにおいて推奨アルゴリズムに選定されている。

SHA‑5122002 年に NIST が FIPS 180‑2 として標準化した、出力ハッシュ値 512 ビット長のハッシュ関数である。
NESSIE プロジェクトにおいて推奨アルゴリズムに選定されている。
d)

擬似乱数生成【CRYPTREC からのコメント】《注意１》擬似乱数生成系は、その利用特性上、インタオペラビリティを確保する
必要性がないため、暗号学的に安全な擬似乱数生成アルゴリズムであれば、どれを利用しても基本的に問題が生じない。したがって、以下に挙げる擬似乱数
は例示であり、これら以外の「暗号学的に安全な擬似乱数生成アルゴリズム」の採用を妨げるものではない。
《注意２》以下の３つのアルゴリズムについては、パラメータの選び方によっては、仕様書中に定義されている使い方の中に安全とは言い切れないものが存在する。
利用にあたっては、CRYPTREC Report 2002 の該当章を確認の上、適切な使い方を選択する必要がある。
PRNG based on SHA‑1 in ANSI X9.42‑2001 Annex C.1
2001 年に ANSI が規格化した ANSI X9.42‑2001 Public Key Cryptography for the
Financial Services Industry : Agreement of Symmetric Keys Using Discrete
Logalithm Cryptography で利用する擬似乱数生成方式。ハッシュ関数 SHA‑1 をもとにした構成になっている。

− 22 −

PRNG based on SHA‑1 for general purpose in FIPS 186‑2 (+ change notice 1) Appendix
3.1（*）
2000 年に NIST が標準化した規格 FIPS 186‑2 をベースに、変更情報（change notice1）が 2001 年に付け加えられた FIPS 186‑2 (+ change notice 1) Digital SignatureStandard (DSS)に掲載されている擬似乱数生成方式。本規格中では、複数の擬似乱数生成方式が規定されているが、そのうち本アルゴリズム及び下記(**)のアルゴリズム
を CRYPTREC としては例示する。ハッシュ関数 SHA‑1 をもとにした構成になっている。

PRNG based on SHA‑1 for general purpose in FIPS 186‑2 (+ change notice 1) revised
Appendix 3.1（**）
2000 年に NIST が標準化した規格 FIPS 186‑2 をベースに、変更情報（change notice1）が 2001 年に付け加えられた FIPS 186‑2 (+ change notice 1) Digital SignatureStandard (DSS)に掲載されている擬似乱数生成方式。本規格中では、複数の擬似乱数生成方式が規定されているが、そのうち本アルゴリズムと上記(*)のアルゴリズムを
CRYPTREC としては例示する。ハッシュ関数 SHA‑1 をもとにした構成になっている。

− 23 −

４．

調達の手順

４．１

概要

（１）暗号調達の流れ
電子政府システムの調達に係る作業の流れはおおよそ図４．１−１及び表４．１−１のとおりである。本節では、この流れを意識しながら、暗号調達に関わる事項のみを抜粋して
説明する。
調達対象

調達仕様

公示・

調達先の

契約書の

納品受領

システム

の検討、

公募等の

決定

作成、

〜検収

の基本検

仕様書の

事務作業

討

作成

契約締結

図４．１−１

システム調達の流れ

表４．１−１

各作業の概要

調達の流れ

作

業

概

要

調達対象システムの基本検 システムの背景、目的、対象範囲、構築条件、概算費
討用等、調達を進める基本的事項の整理、その他、暗号に関連した作業として、リスク分析等が行なわれる調達仕様の検討、仕様書の作 システムへの要件となる事項の具体化検討と仕様書
成の作成（必要に応じて、パブリックコメントを募集する場合がある）
公示・公募等の事務作業
公示・公募、提案の受付などの事務作業
調達先の決定調達システムに適合する提案をした業者を選定
契約書作成、契約締結
納品受領〜検収調達システムの特記事項等を盛り込んで、契約書を作成、契約を締結
調達したシステムを受領、仕様と相違ないことを確認
検収− 24 −

（２）暗号調達の進め方について調達作業の流れの中で、調達者はシステムに必要な暗号の要件を明確化し、業者に示す必要がある。このために、調達者は電子政府推奨暗号リストの提示する情報をもとにして、暗号技術を絞り込む作業を実施する。
絞り込む作業の進め方には、以下に挙げる２種類の方法が考えられる。
調達仕様書の作成時に、調達システムについて詳細に説明し、その中で暗号アルゴリ
ズムを指定する。（以下では調達者指定モデルと記載）
調達仕様書では暗号について概略を説明し、業者に電子政府推奨暗号リストに準じて
暗号アルゴリズムを選定させ、提案資料を見て審査する。
（以下では提案審査モデルと記載）
前記した２種類の方法のうち、前者（調達者指定モデル）の場合は仕様書作成段階で暗号への要件を詳細化することが必要であるが、後者（提案審査モデル）においては提案書受領時の審査時に同様の作業が必要となるため、システム調達全体を通じての調達者の作業については同等になるものと考えられる。

調達対象

調達仕様

公示・

調達先の

契約書の

納品受領

システム

の検討、

公募等の

決定

作成、

〜検収

の基本検

仕様書の

討

作成

契約締結

事務作業

調達者指定モデルでは、

提案審査モデルでは、業者に調達仕様書に暗号アルゴ

より提案された暗号アルゴ

リズム等詳細な指定をしリズム等の情報を審査してて調達を進める

調達先を決定する

図４．１−２

暗号要件絞り込みのポイント− 25 −

４．２

調達仕様書の作成

調達仕様書の作成においては、４．１節の（２）で説明した調達者指定モデルと、提案審査モデルにおいて、作業手順が異なるため、以下では各々のモデルに対して個別に手順の説明を行う。
４．２．１

調達者指定モデルの場合（１）概要
この節では、調達する暗号アルゴリズムを選定するために、調達者が検討すべき内容と、実際の記載内容について説明する。
調達者は、リスク分析結果等の調達するシステムの基本検討の結果を把握した上で、次の順番で、調達する暗号アルゴリズムに関する検討を行い、調達仕様書を作成する。

（２）
暗号利用形態の選定（３）
暗号技術分類の選定

図４．２．１−１（４）
暗号アルゴリズムの選定（５）
調達仕様書への記載

調達者指定モデルにおける調達仕様書作成の流れ− 26 −

（２）暗号利用形態の選定
本ガイドブックでは、システムの基本検討におけるリスク分析等の様々な作業の一環として暗号利用形態の選定が行われた後に、本ガイドブックにしたがって、暗号技術分類、暗号アルゴリズムを選定することを想定している。
ここでは、確認の意味で、一般的なセキュリティ上の脅威に対して暗号利用形態を選定する場合の基本的な考え方の例を示す。
●

暗号による保護が必要である情報が漏洩する可能性があり、その情報が漏洩しては困るもの（利用者または政府に金銭的又はその他の被害を与えることが想定される場合。
以下同様）については、暗号利用形態のうち「守秘」による保護が必要となる。

●

暗号による保護が必要である情報が改竄されるか、または否認（後になって異議を申し立てられる）の可能性があり、その情報が改竄または否認されては困るものについては、暗号利用形態のうち「署名」による保護が必要となる。

●

暗号による保護が必要である情報を交換する相手に他人による成りすましの可能性があり、その情報が成りすました他人と授受を行われては困るものについては、暗号利用形態のうち「相手認証」による保護が必要となる。

●「守秘」、「署名」、「相手認証」のいずれかの暗号利用形態において共通鍵暗号を利用する場合には、暗号鍵を安全に共有するために、「鍵共有」による鍵情報の保護が必要な場合がある。
共通鍵暗号の利用が未だ明確でない場合、この段階では「鍵共有」は必要なものとして作業を進めることも可能であるが、暗号技術分類の選定が進んだ段階で、再度必要性を検討することが必要となる。

− 27 −

＜参考：

作業の進め方の例＞

たとえば、電子申請システムの場合を例にとって説明する。
「申請・届出等手続きのオンライン化に関わる汎用受付等システムの基本的な仕様 （ 平 成 13 年 8 月 6 日

行 政 情 報 化 推 進 各 省 庁 連 絡 会 議 幹 事 会 了 承 ）」（http://www.soumu.go.jp/gyoukan/kanri/010806̲1.htm）に基づくシステムモデ
ル図が図４．２．１−２である。
個別業務システムのサーバ

中央官庁

申請

電子証明書

結果通知

汎用受付等
システムの
サーバ

審査官の端末民間認証局

府省認証サーバ

申請の審査官

申請・
問い合わせ

電子証明書
結果通知

申請者

申請者端末

図４．２．１−２

電子申請システムのシステムモデル図

システム全体におけるリスク分析で、このシステムに登場する暗号による保護を必要とする情報を洗い出し、それらの情報に対応する暗号利用の目的、すなわち暗号利用形態を検討する。さらに、暗号アルゴリズム選定の過程において考慮すべき
暗号技術への要件をまとめた表のサンプルが表４．２．１−１である。
表４．２．１−１暗号による保護を必要とする情報
・申請データ・申請内容確認で授受されるデータ
・到達確認通知・状況確認で授受されるデータ・審査終了通知・許認可等公文書の取得要求データ
・許認可等公文書（・鍵情報）

暗号利用形態選定表のサンプル※
暗号利用形態
・相手認証
・署名
・守秘

（鍵共有）

※

暗号技術への要件
・通信速度は、利用者の負担とならない程度の速度であること。
・多くの利用者にとって利用が負担とならないように、暗号アルゴリズムは標準的なものであることが望ましい。
（必要になった時のための欄）

実際の調達においては、サンプル自体を引用するのではなく、個別具体的な状況に応じた適切な調達を行うこと。

− 28 −

（３）暗号技術分類の選定
ここでは、暗号利用形態毎に、電子政府システムにおいて多く使用される暗号技術分類を例示する。
調達者は、調達するシステムの目的、特性を考慮して、暗号利用形態に対して適切と思われる暗号技術分類を選定すること。
なお、暗号技術分類の選定にあたっての留意点は以下の通り。
・ハッシュ関数と擬似乱数生成は、他の２つの暗号技術分類、共通鍵暗号と公開鍵暗号に付随して使用されることが多いため、ここでは共通鍵暗号と公開鍵暗号のどちらを選択するかについて説明している。ハッシュ関数と擬似乱数生成については、共通鍵暗号、
公開鍵暗号のいずれを選択した場合でも使用されるものとして次項（４）に進んで構わない。
・説明にあたり、暗号利用形態によって、共通鍵暗号と公開鍵暗号の出現する順番が変わっているが、電子政府システム又は世間一般において、より多く使用されている暗号技術
分類について先に説明している。
・暗号利用形態「守秘」「署名」「相手認証」において共通鍵暗号を使用した場合は、通信当事者間で暗号鍵を安全に共有するために「鍵共有」に対応する暗号技術分類も選定しておくこと。

a) 暗号利用形態が「守秘」の場合
・ 共通鍵暗号を用いる場合
多くの場合、守秘では共通鍵暗号が使用される。
特に、「送受信するデータ量が多い場合」、「高速処理が要求される場合」には、共通鍵暗号が使用される。
・ 公開鍵暗号を用いる場合
他の暗号利用形態で公開鍵暗号を使用しており、共通的に使用する場合など、場合によっては守秘に公開鍵暗号が使用されることがある。
公開鍵暗号は共通鍵暗号に比べて処理速度はかなり遅いが、送受信されるデータ量が少ない場合には、処理速度の影響が小さくなるので、公開鍵暗号を使用しても問題にはならないことがある。

− 29 −

b) 暗号利用形態が「鍵共有」の場合
・ 公開鍵暗号を用いる場合
多くの場合、鍵共有では公開鍵暗号が使用される。
特に近年では、安全に鍵情報を共有するために公開鍵暗号が多く使用される。
・ 共通鍵暗号を用いる場合
一部の方式（Kerberos 等）では鍵共有に共通鍵暗号を使用することがある。ただし、鍵共有のために使用する共通鍵暗号の暗号鍵を、事前に何らかの方法で安全に配布できる場合に限られる。
なお、頻繁に鍵情報を交換する必要がある場合には、処理速度を上げるために共通
鍵暗号を用いることがある。

c) 暗号利用形態が「署名」の場合
・ 公開鍵暗号を用いる場合
多くの場合、署名では公開鍵暗号が使用される。
公開鍵暗号を用いた署名では、信頼できる公開鍵を入手する必要があり、そのためのインフラとしてＰＫＩを用いることが一般的である。
また、多くの場合、改竄を防ぐために添付されるデータの作成にはハッシュ関数が使用される。
・ 共通鍵暗号を用いる場合
署名には共通鍵暗号を用いることもできるが、署名を使用する目的のうち、「署名を作った者を第三者が確認できること」の実現は困難である。
共通鍵暗号を用いて署名に類似する目的を実現する方式として、ＭＡＣ（Message
Authentication Code：メッセージ認証子）を用いる方法がある。

− 30 −

d) 暗号利用形態が「相手認証」の場合
・ 公開鍵暗号を用いる場合
多くの場合、相手認証では公開鍵暗号が使用される。実際、被認証者が特定の情報に署名を施し、検証者がそれを署名検証することで被認証者の同一性が判断できるので、特定の手続きと共に用いれば、リストに記載されたすべての署名方式は相手認 証 へ の 応 用 が 基 本 的 に 可 能 で あ る 。 た と え ば 、 JIS X5056‑3:2002(ISO/IEC
9798‑3:1998)に詳しい手続きの記述がある。
・ 共通鍵暗号を用いる場合
一部の方式（チャレンジ＆レスポンス等）では相手認証に共通鍵暗号を使用することがある。ただし、相手認証のために使用する共通鍵暗号の暗号鍵を、事前に何らかの方法で安全に配布できる場合に限られる。
なお、相手認証を高速に実行する必要がある場合には、処理速度を上げるために共通鍵暗号を用いることがある。
＜参考：

作業の進め方の例＞

前項（２）と同じく、電子申請システムを例にとって説明する。
表４．２．１−１で選定した暗号利用形態から、暗号技術への要件を考慮して、選定した暗号技術分類をまとめた表のサンプルが表４．２．１−２である。
暗号利用形態「守秘」においては、暗号技術への要件でもある通信速度を考慮して共通鍵暗号を選定している。暗号利用形態「相手認証」、「署名」においては、特に考慮すべき要件が無いので、多く使用される公開鍵暗号を選定している。暗号利用形態「守秘」において共通鍵暗号を選定したため、暗号利用形態「鍵共有」が必要となり、特に考慮すべき要件が無いので、多く使用されている公開鍵暗号を選定している。
表４．２．１−２暗号による保護を必要とする情報
・申請データ・申請内容確認で授受されるデータ
・到達確認通知・状況確認で授受されるデータ・審査終了通知・許認可等公文書の取得要求データ
・許認可等公文書
・鍵情報※

暗号技術分類選定表のサンプル※
暗号利用
形態
守秘

暗号技術
暗号技術への要件
分類
共通鍵暗号 ・ 通信速度は、利用者の

相手認証

公開鍵暗号

署名

公開鍵暗号

鍵共有

公開鍵暗号

負担とならない程度の速度であること。
・多 く の 利 用 者 に と って利用が負担とならないように、暗号アル
ゴリズムは標準的なものであることが望ましい。

実際の調達においては、サンプル自体を引用するのではなく、個別具体的な状況に応じた適切な調達を行うこと。

− 31 −

（４）暗号アルゴリズムの選定
本来、電子政府推奨暗号リストに掲載されている暗号アルゴリズムは、安全な実装が行われている限り、すべて安全な暗号であり、電子政府システムにおいてどの暗号アルゴリズ
ムを使用しても問題はない。ここで挙げている観点は、そのような安全な暗号アルゴリズ
ムの中から 1 つ又は必要な数の暗号アルゴリズムを選定する場合に、どのような点に着目すべきかを説明するものである。
なお、最も適切な暗号アルゴリズムの選定が困難な場合は、調達仕様書では複数の暗号ア
ルゴリズムを列挙し、その中から調達参加業者に選択させても構わない。
<< 注意 >>
実装方法によっては、このリストに掲載されている暗号アルゴリズムを使用したとしても、様々な実装攻撃にさらされる危険性を排除できない。したがって、実装攻撃の脅
威に対する十分な配慮、検討を行い、適切な対策を施して実装するよう注意すること。
詳しくは、CRYPTREC Report 2002 の第６章「暗号技術の実装に関わる攻撃」を参照
すること。
暗号アルゴリズム比較の観点として、次の４点が挙げられる。
これらの観点は、参考２「評価・特徴一覧」からの抜粋である。参考２において記載がな
い観点は以下に示す比較のための表から省いている。
① 暗号利用形態
機能的に、利用が適している暗号利用形態を掲載している。
共通鍵暗号、ハッシュ関数は、どの暗号利用形態にも適用可能であるので、この欄は省略している。
② 処理速度Pentium Ⅲチップを用いた暗号化処理速度における比較。
共通鍵暗号、ハッシュ関数、擬似乱数生成では 3‑key Triple DES を基準とした比較を示している。
表中の表示は、
Ａ：処理速度が、3‑key Triple DES よりもかなり速い
Ｂ：処理速度が、3‑key Triple DES よりも速い
Ｃ：処理速度が、3‑key Triple DES と同程度
Ｄ：処理速度が、3‑key Triple DES よりも遅いを意味している。

− 32 −

なお、一般的には、公開鍵暗号による暗号化処理速度は、共通鍵暗号による処理速度の1/100 以下である。
③ メモリ制限環境での実装性（ＩＣカード等）
低機能型ＩＣカード（8 ビットＣＰＵ、ＲＯＭは数 k〜10kbyte 程度、ＲＡＭ 128byte
程度）における使用ＲＯＭサイズ、使用ＲＡＭサイズ、処理速度の総合性能による比較。
表中の表示は、
Ａ：メモリ制限環境での実装性が、3‑key Triple DES よりもかなり良い
Ｂ：メモリ制限環境での実装性が、3‑key Triple DES よりも良い
Ｃ：メモリ制限環境での実装性が、3‑key Triple DES と同程度
Ｄ：メモリ制限環境での実装性が、3‑key Triple DES よりも劣る−：未評価を意味している。
④ プロトコル標準（SSL 3.0、TLS 1.0）
暗号アルゴリズムのうち、標準的暗号プロトコルに採用されているもの、すなわち国民が使用するパソコンの多くにプレインストールされていると思われるものを、SSL 3.0、TLS 1.0 を例にとって掲載している。ただし、これらの標準的暗号プロトコルに規格上は採用されていても、市販の製品には実装されていないものもあるため、注意が必要である。たとえば、共通鍵暗号の AES は、比較的最近 TLS 1.0 に採用されたため、既存の多くの実装には含まれていない。

− 33 −

a)

公開鍵暗号表４．２．１−３は、電子政府推奨暗号リストに掲載されている公開鍵暗号アルゴリズムの比較表である。
なお、公開鍵暗号に使用される鍵長(より詳しくいえば、例えば RSA 暗号の場合、2 つの素数の積となる合成数のビット長を指す)と処理速度の関係について、一般的には鍵長が 2倍になると処理速度は数分の 1 になるため、調達するシステムにおいて公開鍵暗号を利用する場合には、許容出来る処理速度の範囲で鍵を長くする（例えば RSA の場合は 1024 ビッ
ト以上にする）などの検討が必要である。

①暗号利用形態④プロトコル標準
SSL3.0TLS

表４．２．１−３

公開鍵暗号における暗号アルゴリズム比較表

DSA

RSASSA‑ RSA‑
PKCS1‑ PSS
v1̲5
署名
署名

ECDSA

署名

署名

○

−

○

TLS1.0(ProposedStandard)

Internet‑DraftTLS1.0(ProposedStandard)

RSA‑
OAEP
守秘

RSAES‑
PKCS1‑
v1̲5 *1)
守秘

DH

ECDH

PSEC‑
KEM

鍵共有

鍵共有

鍵共有

−

−

○

○

−

−

−

−

TLS1.0(ProposedStandard)

TLS1.0(ProposedStandard)

Internet‑Draft−*1）SSL3.0/TLS1.0 で使用実績があることから当面の使用を認める。なお、リストに掲載している別の暗号が利用できるのであれば、可能な限りそちらを使用することが望ましい。

なお、公開鍵暗号については、各アルゴリズムの数論的困難性を担保するため、パラメー
タの選択に十分留意する必要がある。そのため、選択した暗号の仕様書、及び、「CRYPTREC
Report 2002」の、選択した暗号に関する記述部分を参考にして記載する。
又は、選択した暗号の仕様書、あるいは「CRYPTREC Report 2002」を業者に提示し、調達するアルゴリズムがパラメータ要件を満たすよう業者に指示しても構わない。

− 34 −

b）共通鍵暗号表４．２．１−４〜表４．２．１−６は、電子政府推奨暗号リストに掲載されている
共通鍵暗号アルゴリズムの比較表である。観点の①「暗号利用形態」については、表４．
２．１−４、表４．２．１−５では、ブロック暗号はどの暗号アルゴリズムでも相手認証、署名、守秘、鍵共有の全ての暗号利用形態に適用可能なため省略している。また表
４．２．１−６では、ストリーム暗号は主に守秘に用いられるため、記載していない。
共通鍵暗号における暗号アルゴリズムの選定は、下記の点に留意して行うこと。
・ ブロック暗号は、現在はブロック長が 64 ビットの暗号が多く使われているが安全性の面から、今後は可能な限りブロック長が 128 ビットの暗号を使用すること。
・ ストリーム暗号は、高速の通信路で、主に守秘を目的として使用されることが多い。
表４．２．１−４②処理速度③メモリ制限環境での実装性④プロトコル
標準表４．２．１−５②処理速度③メモリ制限環境での実装性④プロトコル標準表４．２．１−６

共通鍵暗号（128 ビットブロック暗号）アルゴリズム比較表
128 ビットブロック暗号
Camellia CIPHERUNICORN‑A Hierocrypt‑3
Ａ
Ｃ
Ｂ+
Ｂ+
Ｄ以下
Ｂ

AES
Ａ
Ｂ+
RFC3268: AES
Ciphersuits
for TLS(ProposedStandard)

TLS1.0(Internet
Draft)−

SC2000Ａ
Ｃ+−−

共通鍵暗号（64 ビットブロック暗号）アルゴリズム比較表
CIPHERUNICORN‑E
Ｃ‑
Ｄ以下
−

64 ビットブロック暗号
Hierocrypt‑L1
MISTY1
Ａ
Ｂ+
Ｂ
Ｂ+
−

−

3‑key Triple DES（比較基準：Ｃ）（比較基準：Ｃ）
SSL3.0/TLS1.0(Proposed Standard)

共通鍵暗号（ストリーム暗号）アルゴリズム比較表②処理速度③メモリ制限環境での実装性④プロトコル標準

MULTI‑S01
Ａ+−−

ストリーム暗号
MUGI
128‑bit RC4 *1
Ａ+
Ａ+
−
−
SSL
3.0/TLS
1.0−(Proposed Standard)*1）128‑bit RC4 は、SSL3.0/TLS1.0 以上に限定して利用することを想定している。なお、リストに掲載している別の暗号が利用できるのであれば、可能な限りそちらを使用することが望ましい。

− 35 −なお、ブロック暗号を利用した暗号化処理に関連して、安全性の向上を図ったり、伝送中のビット誤りの影響が拡散して復号できなくなる事態を回避したりすることを目的とした、暗号利用モード（Modes of Operation）と呼ばれる技法が、いくつか規定されている。
暗号利用モードごとに実現している目的や特性が異なるので、ブロック暗号の利用にあたっては、実装環境や利用用途に応じて、適切な暗号利用モードを選択する必要がある。なお、代表的な暗号利用モードが JIS X5052 や JIS X5053 に示されているので、これを参考にされたい。
あるいは、上記規格又は「CRYPTREC Report 2002」を業者に提示し、適切な暗号利用モードを選択するよう、業者に指示しても構わない。

c) ハッシュ関数
観点の①「暗号利用形態」については、どのハッシュ関数であっても、適切な公開鍵暗号との組み合わせなどによって、相手認証、署名、守秘、鍵共有のどの暗号利用形態にも適用可能であるため、掲載していない。また、観点③「メモリ制限環境での実装性」
は未評価であるため、やはり掲載していない。
ハッシュ関数は公開鍵暗号または共通鍵暗号に付随して使用されることが多い暗号技術であるため、次の３点を考慮して選定する。
1) 電子政府推奨暗号リストに掲載されているハッシュ関数のうち、適切ないずれかを選定する。
2) その場合、可能であれば 256 ビット以上の長さのハッシュ値を出力するハッシュ関数を選択することが望ましい。
3) ただし、すでに選定している公開鍵暗号または共通鍵暗号の暗号アルゴリズム仕様
書で指定されている場合は、その限りではない。
表４．２．１−７

ハッシュ関数における暗号アルゴリズムの比較表②処理速度④プロトコル標準

RIPEMD‑160
Ａ+
−

＜参考＞
ハッシュ値の長さ

160 ビット

SHA‑1
Ａ+
SSL 3.0/TLS 1.0(ProposedStandard)

160 ビット− 36 −

SHA‑256
Ａ−

SHA‑384
Ｃ+−

SHA‑512
Ｃ+−

256 ビット 384 ビット 512 ビットd) 擬似乱数生成
擬似乱数生成アルゴリズムは、その利用特性上、インタオペラビリティ（相互接続性）を確保する必要性がないため、「暗号学的に安全な擬似乱数アルゴリズム」であれば、どれを利用しても基本的に問題は生じない。したがって、リストに掲載されている擬似乱数生成アルゴリズムのほか、「暗号学的に安全な擬似乱数アルゴリズム」を利用することができる。
なお、リストに掲載されている暗号アルゴリズムの仕様自体に、特定の擬似乱数生成
アルゴリズムを使用するよう規定されている場合は、その使用を妨げるものではない。
<< 注意 >>
擬似乱数生成アルゴリズムを実装する場合には、例えば以下の点を考慮すべきである。
・Ｃ言語の rand 関数のような擬似乱数生成関数は暗号学的には安全ではないので、暗号アルゴリズムで利用する擬似乱数生成アルゴリズムとして利用してはならない。
・擬似乱数生成アルゴリズムで利用する種（seed）として、ユーザ ID やプロセス
ID、マシン ID、time 関数の出力値など、推測が比較的容易な情報のみを使用することは避ける。
・種（seed）のビット長として、128 ビット以上にすることが望ましい。
・NIST が発行する NIST Special Publication 800‑22, A Statistical Test Suit for
Random and Pseudorandom Number Generators に 記 載 さ れ て い る 検 定 テ ス ト（http://csrc.nist.gov/encryption/tkring を参照のこと）や、フロリダ州立大学 George Marsaglia 教 授 が 開 発 し た DIEHARD に よ る 検 定 テ ス ト（http://stat.fsu.edu/pub/diehard を参照のこと）などの擬似乱数検定法を実施する。この擬似乱数検定法により不合格になった擬似乱数生成アルゴリズムの利用は避けるべきである。なお、擬似乱数生成アルゴリズムの検定方法の詳細については、CRYPTREC Report 2002 の 5.4「擬似乱数生成系の検定方法」を参照されたい。
上記のような考慮が必要な理由は、出力データのランダム性及び予測不可能性（過去の出力ビット列を利用しても次に出力されるビットが推測できないという性質）、種（Seed）の安全性を満たしていない擬似乱数生成アルゴリズムを利用した場合、たとえリストに掲載されている暗号アルゴリズムを利用していても、予期せぬ安全性上の問題を生じさせる可能性がある。このため、暗号アルゴリズムで利用する擬似乱数生
成においては、上記の特性を満たすような「暗号学的に安全な擬似乱数生成アルゴリ
ズム」を利用しなければならない。

− 37 −

＜参考：

作業の進め方の例＞

前項（３）と同じく、電子申請システムを例にとって説明する。
表４．２．１−２で選定した暗号技術分類から、暗号技術への要件を考慮して、選定した暗号アルゴリズムをまとめたものが表４．２．１−８である。
選定にあたっては、標準的な暗号アルゴリズムという要件を考慮し、暗号利用形
態「守秘」においては、プロトコル標準 SSL 3.0 に採用されている暗号アルゴリズ
ムのうちもっとも処理速度の速いものを選定している。暗号利用形態「署名」、「鍵共有」も同じくプロトコル標準 SSL 3.0 に採用されている暗号アルゴリズムを選定している。
ハッシュ関数、擬似乱数生成は、暗号アルゴリズム仕様で指定されているものがあればそれを使用するが、特に指定が無い場合のための候補を選定している。
表４．２．１−８

暗号アルゴリズム選定表のサンプル※

暗号による保護を必要とする情報

暗号利用形態

暗号技術分類

暗号アルゴリズム・ 申請データ・ 申請内容確認で授受されるデータ
・ 到達確認通知
・ 状況確認で授受されるデータ
・ 審査終了通知・ 許認可等公文書の取得要求データ・ 許認可等公文書

守秘
相手認証

共通鍵暗号
公開鍵暗号

共通鍵暗号その１
公開鍵暗号その１
または

署名

公開鍵暗号

または

公開鍵暗号その３

・鍵情報
鍵共有
公開鍵暗号
上記暗号アルゴリズムにて ハッシュ関数
特に指定の無い場合は 擬似乱数生成
右記アルゴリズムを使用すること※

公開鍵暗号その３
公開鍵暗号その１

公開鍵暗号その２
ハッシュ関数その１
擬似乱数生成その１

暗号技術への要件
・ 通信速度は、利用者の負担とならない
程度の速度であること・多 く の 利 用 者 にとって利用が負担とならないように、
暗号アルゴリズムは標準的なものであることが望ましい

実際の調達においては、サンプル自体を引用するのではなく、個別具体的な状況に応じた適切な調達を行うこと。

− 38 −

（５）調達仕様書記載項目
以上のような手順により、調達者は下記記載例のような「暗号アルゴリズム指定表」
を調達仕様書に記載する。

＜参考：

アルゴリズム指定表の記載例＞

電子申請システムにおける、アルゴリズム指定表の記載例を表４．２．１−９に示す。
表４．２．１−９

暗号アルゴリズム選定表の記載例※

暗号による保護を必要とする情報
暗号利用形態・ 申請データ
守秘・ 申請内容確認で授受されるデータ
相手認証
・ 到達確認通知
・ 状況確認で授受されるデータ
・ 審査終了通知
署名・ 許認可等公文書の取得要求データ
・ 許認可等公文書
・鍵情報
鍵共有
上記暗号アルゴリズムにて ハッシュ関数として
特に指定の無い場合は 擬似乱数生成として
右記アルゴリズムを使用すること※

暗号アルゴリズム

共通鍵暗号その１
公開鍵暗号その１
または

公開鍵暗号その３
公開鍵暗号その１
または

公開鍵暗号その３
公開鍵暗号その２
ハッシュ関数その１
擬似乱数生成その１

実際の調達においては、サンプル自体を引用するのではなく、個別具体的な状況に応じた適切な調達を行うこと。

− 39 −

４．２．２

提案審査モデルの場合（１）概要
提案審査モデルの場合、調達者は調達仕様書には最低限の要件だけを指定し、提案を行う業者に、最新の技術や方式、又は斬新なシステムの提案を行わせ、もって電子政府システ
ムとして先端的な、又は最適なシステムを構築することを目的とする。

（２）調達仕様書記載項目
調達者は、下記項目を調達仕様書に記載すること。
a) 電子政府推奨暗号リスト掲載の暗号アルゴリズムの使用に関する指示
調達するシステムでは、可能な限り電子政府推奨暗号リストに記載されている暗号ア
ルゴリズムを使用するよう、提案を行う業者に指示すること。
調達仕様書に記載する内容としては、たとえば、次のような文章が考えられる。
「本システムで使用する暗号アルゴリズムは、本システムのセキュリティ要件を満たし、かつ可能な限り電子政府推奨暗号リストに掲載されている暗号アルゴリズムから、適切なものを選定すること」
b) 暗号アルゴリズム選定理由の明記に関する指示
提案書の審査にあたっては、暗号アルゴリズムの選定（公開鍵暗号のパラメータ選択、
及び、共通鍵ブロック暗号の利用モードの選択を含む）が妥当であることを審査する必要があるため、提案を行う業者に、調達するシステムのイメージから暗号アルゴリズム
選定（同上）までの過程を理由を付けてわかり易く説明した文書を提案書に添付させること。
調達仕様書に記載する内容としては、たとえば、次のような文章が考えられる。
「提案書には『暗号選定理由書』を添付すること。『暗号選定理由書』では、本システ
ムの仕様から暗号アルゴリズム選定（公開鍵暗号のパラメータ選択、及び、共通鍵ブロッ
ク暗号の利用モードの選択を含む）までの過程を、理由を付けてわかりやすく説明すること。なお、使用する用語は可能な限り電子政府推奨暗号リストで使用されている用語にあわせること」− 40 −

＜参考：

暗号選定理由の記載例＞

暗号選定理由書の参考例を表４．２．２−１に示す。暗号選定理由書は調達参加業者が作成、提出するものであるが、最低限、次の 3 項目が記載されていることが望ましい。
a) リスク分析の概要と暗号利用形態の選定理由
リスク分析作業のアウトプットとして、暗号による保護を必要とする情報、暗号利用形態、暗号技術への要件について、の選定理由b) 暗号技術分類の選定理由
個々の暗号利用形態に対して、なぜその暗号技術分類を選定したのか。
c) 暗号アルゴリズムの選定理由
個々の暗号技術分類に対して、なぜその暗号アルゴリズムを選定したのか。
表４．２．２−１

暗号選定理由のサンプル（「守秘」に関する部分）※

項目選定したもの選定理由
暗号による保護を ・ 申請データ
このシステムで使用する電子情報のうち、暗号によ・ 審 査 終 了 通 る保護を必要とする情報は、必要とする情報「申請データ」、「審査
知 ．．．
終了通知」、＜中略＞である。
＜以下略＞．．．

暗号利用形態

暗号に関する要件

守秘これらの情報は、政府と利用者間でやり取りされるが、そのやり取りはインターネット上で行われるため、盗聴、改竄等のリスクが存在する。その一方で、これらの情報には、利用者のプライバシーに関する情報や事業の展開上秘匿すべき情報が含まれるため、「守秘」による保護が必要である。
・ 処理速度は、．． 暗号技術への要件としては、利用者に負担をかけな＜以下略＞
いという観点から、「利用者が負担に感じない程度
・ 利 用 者 の 負 担 の処理速度」と「可能な限り標準的に実装されていとならない．．
る暗号アルゴリズムの使用」が挙げられる。
＜以下略＞

暗号技術分類

暗号アルゴリズム

共通鍵暗号

処理速度が高速であること、より一般的に使用されている（鍵情報を公開鍵暗号にて共有し、情報のやり取りは共通鍵暗号にて行う方式が多く使用されている）こと、この 2 点から共通鍵暗号を選定する。
共 通 鍵 暗 号 そ 電子政府推奨暗号リストに掲載されている共通鍵暗の１号のうち、処理速度がより高速であるもの、標準プロトコルで採用されているもの、この 2 点から「共通鍵暗号その 1」を選定する。なお、共通鍵暗号その 1 の利用用途は＜略＞であるから、利用モードは
は「（モード名称）」とした。

※

実際の調達においては、サンプル自体を引用するのではなく、個別具体的な状況に応じた適切な調達を行うこと。

− 41 −

４．２．３

調達仕様書作成上の留意点

調達者が調達仕様書を作成する際に、留意すべきである点について、以下に示す。
（１） 複数暗号アルゴリズムの実装について
電子政府システムにおけるサーバや、パソコン等に複数の暗号アルゴリズムを同時に実装する事に関する考え方について記載する。
セキュリティ面だけ考えると以下のようにいえる。
a) 複数暗号実装のメリット
電子政府推奨暗号リストに掲載される暗号アルゴリズムにおいては暗号解読問題
発生の可能性が低いとはいえ、１つの暗号アルゴリズムが解読された場合に備えて、複数の暗号を実装し切り替えられるようにすることは、セキュリティを向上する上で有効である。
b) 複数暗号実装のデメリット
複数の暗号アルゴリズムを同じシステムに実装し、これを切り替えて利用できるよ
うに作り込んだ場合、切り替え部分等にセキュリティホールが混入してしまう恐れがある。そのため、脆弱性が上昇し、セキュリティが減少する可能性がある。
c) 対応策したがって、セキュリティ脆弱性の上昇により懸念されるリスクが、暗号アルゴ
リズムが解読されるリスクに比べて小さいと判断された場合にのみ、複数暗号アル
ゴリズムを実装すべきである。
なお、インターネットなどを通じて広く一般国民が利用するシステムにおいて、利用者の利用する暗号アルゴリズムが全体として１つに特定できない場合などには、政府側のサーバ装置で、複数の暗号アルゴリズムをどちらでも扱えるようにしておかなければならない
場合がある。このような場合には、セキュリティホールを作りこまないよう十分な配慮をしつつ複数暗号を実装しておくことが利用者の利便性を向上させる上でも望ましい。

− 42 −

（２）暗号プログラムの配布と、外国為替及び外国貿易法による暗号輸出規制について
不特定多数の利用者に暗号機能を含むプログラムを配布することには、ワッセナー・アレ
ンジメントに基づき、外国為替及び外国貿易法による規制がある。
ここでは、電子政府システムにおいて、不特定多数の利用者に暗号機能を含むプログラムを配布する場合の法制度上の留意点について説明する。
電子政府システムにおいて、政府、国民間でやり取りされる電子情報の保護のために使用される暗号アルゴリズムとして、先進性などの理由から十分に国民に普及していない暗号
アルゴリズムを利用する場合、政府が管理するサーバ装置上のホームページ等にてその暗号アルゴリズムを内包する通信プログラムを公開し、不特定多数の利用者が自由にその通信プログラムをダウンロードし、使用できるようにすることが考えられる。
このような、日本国内に居住していない者を含む不特定多数の利用者に暗号機能を含むプ
ログラムを配布することは、外国為替及び外国貿易法（第 25 条第 1 項第 1 号）により、経済産業大臣の許可を必要とする行為である。
そのため、調達者は調達するシステムの形態の検討にあたって、そもそも不特定多数の利用者に通信プログラムを配布しないですむよう配慮するか、又は暗号アルゴリズムの選定
または通信プログラムの配布にあたり、配布する通信プログラムが次の３点を全て満たしていることに留意すること。後者の留意については、具体的には、調達仕様上で調達者が確認するか、調達仕様書で「ワッセナー・アレンジメントに関し、外国為替及び外国貿易法による規制に注意して暗号機能を設計すること」等の指示を行うこと。
・ 市販製品（購入に関して何ら制限されず販売されるもの）をそのまま組み込むか、プロ
グラムが無償で提供されること。
・ 暗号機能が利用者によって変更できないこと。
・ プログラム使用に際して技術支援が不要であるように設計されていること。
なお、認証 *1 またはデジタル署名 *2 のための暗号機能はこの規制の対象外である。

詳しくは、「外国為替及び外国貿易法」（第 25 条第 1 項第 1 号）、「輸出貿易管理令」（第 1
条第 1 項）、「外国為替令」（第 17 条第 1 項）、「輸出貿易管理令別表第一及び外国為替令別表の規定に基づき貨物または技術を定める省令」（第 8 条第 1 項第 9 号）、「外国為替及び外国貿易法第 25 条第 1 項第 1 号の規定に基づき許可を要する技術を提供する取り引きについて（役務通達）」を参照のこと。

− 43 −

また、これら法令の解釈、個別の状況判断に関する問い合わせは経済産業省 貿易経済協
力局 貿易管理部 安全保障貿易管理課（Web ページは、
http://www.meti.go.jp/policy/boekikanri/anpo̲hourei/index.html）まで。

*1：ここで言う「認証」にはユーザ認証とデータ認証の 2 つの概念が含まれており、前者は暗号利用形態の「相手認証」にほぼ該当する。後者は「署名」がほぼ該当するが、「鍵共有」が該当する場合もある。実際のシステムにおける利用の形態がここで言う「認証」に該当するかどうかは、個別に経済産業省 貿易経済協力局 貿易管理部 安全保障貿易審査課に確認のこと。
*2：ここで言う「デジタル署名」は暗号利用形態の「署名」にほぼ該当する。実際のシス
テムにおける利用の形態がここで言う「デジタル署名」に該当するかどうかは、個別に経済産業省 貿易経済協力局 貿易管理部 安全保障貿易審査課に確認のこと。

− 44 −

４．３

調達先決定

調達先決定においては、４．１節の（２）で説明した調達者指定モデルと、提案審査モデ
ルにおいて、作業手順が異なるため、以下では各々のモデルに対して個別に手順の説明を
行う。
４．３．１

調達者指定モデルの場合（１）提案書の審査
この項では、業者から、システム提案書の提出を受けた場合の審査の観点を説明する。
調達者指定モデルの場合では、調達するシステムにおける暗号に関する必要な要件は、既に調達仕様書で指定しているので、ここでは業者の提案が、調達仕様書で指定した要件を満たしているかどうかを確認する。
最も注目すべき点は、指定した暗号利用形態に対して、指定した暗号アルゴリズムを指定通りに使用しているか、という点である。
（２）業者の選定システムを納入する業者としては、システム全体に対して適切な提案を行った業者を選定するので、暗号に関する要件の満足度だけで業者選定を左右することはない。
一方、暗号に関する要件の満足度は、業者を選定する理由の重要な点でもあるので、ここ
では、暗号に関してどのような点に留意すべきかについて述べる。
業者選定における評価項目として、暗号に関するものには次のようなものがある。
・ 調達仕様書への準拠
業者からの提案において、調達仕様書に指示した暗号アルゴリズムが、同じく指示したパラメータを満たして使用されている場合には、調達仕様書の指示を守ったものとして、評価を是とするか、又は加点する。

− 45 −

４．３．２

提案審査モデルの場合（１）提案書の審査
提案審査モデルの場合では、業者の提案が、調達するシステムにおける暗号の使用について適切であることを確認する。
審査にあたっては、本ガイドブック「４．２．１

調達者指定モデルの場合」における暗号利用形態選定から暗号アルゴリズム選定までの過程を参照しながら、提案書に添付されている「暗号選定理由書」に記載されている暗号アルゴリズム選定の過程ならびに選定の理由が、論理的に整合性が取れているか、また納得できる内容であるかを、必要に応じて専門家や第三者の助言を仰ぎながら審査する。また、選定された暗号アルゴリズムが電子
政府推奨暗号リストに記載されているかどうかも確認する。
（２）業者の選定システムを納入する業者としては、システム全体に対して適切な提案を行った業者を選定するので、暗号に関する要件の満足度だけで業者選定を左右することはない。
一方、暗号に関する要件の満足度は、業者を選定する理由の重要な点でもあるので、ここ
では、暗号に関してどのような点に留意すべきかについて述べる。
業者選定における評価項目として、暗号に関するものには次のようなものがある。
・電子政府推奨暗号リストへの準拠
業者からの提案において使用されている暗号アルゴリズムが、電子政府推奨暗号リストに掲載されており、かつそのパラメータが各暗号アルゴリズムの仕様書やCRYPTREC Report 2002 で指定された要件を満たしている場合には、評価を是とする。
一方、業者からの提案において使用されている暗号アルゴリズムが、電子政府推奨暗号リストに掲載されていないか、又は電子政府推奨暗号リストに掲載されていても、そのパラメータが各暗号アルゴリズムの仕様書や CRYPTREC Report 2002 で指定された要件を満たしていない場合には、その提案の採用は薦められない。
・実装方法の適切さ
電子政府推奨暗号リストに掲載されている暗号アルゴリズムを使用したとしても、実装方法によっては、様々な実装攻撃にさらされる危険性を排除できない。
したがって、業者からの提案において、実装攻撃に対する十分な配慮、検討が行われ、適切な対策が施されている場合には、評価を是とする。一方、実装攻撃に対する適切な対策が行われていない場合、その提案の採用は薦められない。

− 46 −

・暗号利用形態と暗号アルゴリズムの対応の適切さ
業者からの提案において、暗号利用形態から暗号アルゴリズム選定までの過程と理由が、論理的に整合性が取れており、納得できる内容である場合には基準を満たしているものとして、評価を是とするか、又は加点する。

４．４

契約

契約は、調達するシステム全体について業者と取り交わすため、暗号だけについて別途契約を取り交わす必要はない。
ただし、暗号製品・システムにかかるセキュリティ上の支障が発見された場合の保守・保証の方法及び範囲について、必要に応じて追加すること。

４．５

納品

ここでは、調達した暗号が正しく実装されていることを確認する方法について説明する。
通常、電子政府システムでは、暗号はシステムの一部として機能するよう設計・構築されており、暗号製品・システムが正しく納品されていることをシステムと切り離して個別に評価することは困難である。したがって、一般に行えるのは、疎通テスト程度となる。
ただし、技術的に踏み込んで、調達した暗号の実装が正しいことをより厳密に確認する方法として、次のような方法が挙げられる。
（１）テストベクトルの利用
テストベクトルを利用したテストでは、まず、正しく実装された暗号において確認された、暗号鍵と暗号化される前のデータ（「データ１」とする）、並びに暗号化された後のデータ（「データ２」とする）の３点を用意する。評価する暗号の実装において、データ１を与えられた暗号鍵で暗号化し、得られたデータとデータ２が同一であることをもって、評価する暗号の実装が正しいとする方式である。
（２）別の暗号製品・システムとの対向通信評価する暗号と同等の機能を有する、正しく実装された暗号を用意し、それと評価する暗号とを通信させ、様々なパターンのデータについて、一方で暗号化されたデー
タをもう一方で復号できること、およびその逆方向の処理ができることをもって、評価する暗号の実装が正しいとする方法である。

− 47 −

（３）第三者機関による評価
第三者機関に各種のテストを行わせ、暗号の実装が正しいことを確認させる方法である。米国ではＮＩＳＴが FIPS 140‑2 に基づいて、暗号製品の安全性の認定を行っているが、国内においては公的に承認されている評価機関はまだ存在しないので、暗号の専門家に評価を依頼する等の方策が必要である。

− 48 −

５．

連絡先●本ガイドブックに関する問い合わせ
・総務省

情報通信政策局

通信規格課

ｅ−ｍａｉｌ： cryptrec‑inq@soumu.go.jp
ＵＲＬ： http://www.soumu.go.jp/joho̲tsusin/security/security.html
・経済産業省

商務情報政策局

情報政策ユニット

情報セキュリティ政策室

ｅ−ｍａｉｌ： it‑security@meti.go.jp
ＵＲＬ： http://www.meti.go.jp/policy/netsecurity/●暗号に関する技術的な問い合わせ・情報処理振興事業協会（ＩＰＡ）
ｅ−ｍａｉｌ：セキュリティセンター

暗号技術グループ

cryptrec@ipa.go.jp

ＵＲＬ： http://www.ipa.go.jp/security/
・通信・放送機構（ＴＡＯ）

研究企画管理部

研究企画課

ｅ−ｍａｉｌ： cryptrec@shiba.tao.go.jp
ＵＲＬ： http://www.shiba.tao.go.jp/kenkyu/CRYPTREC/index.html− 49 −

６．
●

参考資料
各府省の情報システム調達における暗号の利用方針：参考１（別添：電子政府推奨暗号リスト）●

評価・特徴一覧（公開鍵暗号／共通鍵暗号）・ JIS‐TR X0050（暗号技術評価報告書：参考２

CRYPTREC Report 2000）

下記 Web ページよりダウンロード可能− http://www.meti.go.jp/policy/netsecurity/crypt.htm− http://www.ipa.go.jp/security/enc/CRYPTREC/fy12/cryptrec20010418.html
・ 暗号技術検討会 2001 年度報告書
下記 Web ページよりダウンロード可能− http://www.soumu.go.jp/s‑news/2002/020416̲2.html− http://www.meti.go.jp/policy/netsecurity/crypt.htm
・ JIS‐TR X0087（暗号技術評価報告書(2001 年度版) CRYPTREC Report 2001）

下記 Web ページよりダウンロード可能− http://www.meti.go.jp/policy/netsecurity/crypt.htm（この Web ページでは、「CRYPTREC Report 2001」と表記している）− http://www.shiba.tao.go.jp/kenkyu/CRYPTREC/fy14/cryptrec20020418̲report01.html− http://www.ipa.go.jp/security/enc/CRYPTREC/fy14/cryptrec20020418̲report01.html
・暗号技術検討会 2002 年度報告書

下記 Web ページよりダウンロード可能− http://www.soumu.go.jp/− http://www.meti.go.jp/
暗号技術評価報告書 2002 年度版 CRYPTREC Report 2002
下記 Web ページよりダウンロード可能− http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/cryptrec20030401̲report01.html− http://www.shiba.tao.go.jp/kenkyu/CRYPTREC/fy15/cryptrec200304̲report02.html− 50 −７．

用語集

ANSI（American National Standard Institute：米国規格協会）
米国における国内標準を定める民間組織。
FIPS（Federal Information Processing Standard：連邦情報処理規格）
NIST が策定する米国連邦政府の情報処理の標準仕様
Kerberos
暗号による認証方式の一つ。通信経路上の安全が保障されないインターネットなどのネットワークにおいて、サーバとクライアントの間で身元の確認を行なうのに使う。
マサチューセッツ工科大学(MIT)の「Athena」プロジェクトによる、認証サービスや関連するプロトコル、プログラムなどの総称。共通鍵暗号を用いることにより、クライアント/サーバアプリケーションに強固な認証システムを提供できるように設計されている。
MAC（Message Authentication Code：メッセージ認証子）
通信当事者間で共有する秘密情報と、送信する情報を組み合わせたうえで、ハッシュ関数などによって処理を行った結果であるデータのこと。MAC を元の情報と一緒に送信し、受信側で受信した情報と秘密情報を組み合わせて処理を行った結果と、受信した MAC が一致すれば、受信した情報が改竄されていないと考えて良い。
NIST（National Institute of Standards and Technology：国立標準技術研究所）
米国政府機関で利用される情報セキュリティ技術等の標準化を行う、商務省傘下の機関
PKI（Public Key Infrastructure：公開鍵基盤）
公開鍵を配布する仕組み、電子証明書を作成・発行・配布する仕組み、電子証明書の有効性を確認する仕組みなどの公開鍵暗号の運用に関わる基盤技術の総称
SECG（Standards for Efficient Cryptography Group）
楕円暗号の業界標準を策定するための国際的コンソーシアム
ストリーム暗号
共通鍵暗号の一種で、データを１ビットないし１バイト程度の短い単位で処理する方式− 51 −

チャレンジ＆レスポンス
相手認証を行う側（認証側）がランダムに生成したデータ（このデータを「チャレンジ」と呼ぶ）を、相手認証を行われる側（被認証側）に送信し、被認証側で双方が共有している秘密情報を用いて暗号化したデータを認証側に送信する（この行為が「レスポンス」である）。認証側では、認証側で秘密情報を用いて暗号化したデータと、受信したデータを比較して、両者が一致したら被認証側が正当である、とする方式。
ハッシュ値
ハッシュ関数が出力する固定長のデータのこと
ブロック暗号共通鍵暗号の一種で、データを一定の長さ（ブロック）に分割し、ブロック単位で処
理する方式
ブロック長
共通鍵暗号の一種であるブロック暗号における、暗号処理を行う情報の長さの単位
ワッセナー・アレンジメント（the Wassenaar Arrangement）
通常兵器及び関連汎用品・技術の責任ある輸出管理を実施することにより、地域の安定を損なう虞れのある通常兵器の過度の移転と蓄積を防止することを目的として、
1996 年 7 月に成立した新しい国際的申し合わせに基づく国際輸出管理体制
より詳しくは、http://www.meti.go.jp/topic/data/ewasenaj.html

を参照のこと相手認証
暗号利用形態の 1 つで、やりとりの相手の正当性を保証すること
暗号アルゴリズム
暗号機能を実現するための仕様
暗号技術分類
暗号アルゴリズムを、機能的・技術的に類似するグループに整理、分類するためのものであるで、公開鍵暗号、共通鍵暗号の２つの主要な分類と、この２つの主要な分類に付随する２つの分類、ハッシュ関数、擬似乱数生成からなる
暗号利用形態電子政府システムにおける暗号利用の目的を整理し、４つの形態にまとめたもの− 52 −

改竄
第三者によって、情報の内容の一部または全部を別のデータで置き換えられてしまう
こと
鍵共有
暗号利用形態の 1 つで、インターネット等のオープンなネットワークを用いて共通鍵暗号技術を利用する際に、通信の当事者間で鍵情報を共有すること
鍵長
暗号鍵の長さ。電子政府推奨暗号リストでは、共通鍵暗号の場合で 128〜256 ビット、
公開鍵暗号の場合で 1024 ビット以上（素因数分解の困難性に基づく方式の場合）の暗号アルゴリズムが選定されている
擬似乱数生成暗号技術分類の 1 つで、暗号学的に安全な乱数（過去の履歴から次のビットが予測できないような数字列）にできるだけ近づけた数の系列を人為的に生成する仕組み
共通鍵暗号
暗号技術分類の 1 つで、平文を暗号化する時に使用する鍵と、暗号文を復号する時に使用する鍵が共通の暗号方式。この鍵のことを共通鍵と呼ぶ。
高速性に優れているが、共通鍵の配送を安全に行うことが求められる。
共通鍵暗号はさらに、データを一定の長さ（ブロック）に分割し、ブロック単位で処理を行う方式（ブロック暗号）と、データを 1 ビットないし 1 バイト程度の短い単位で乱数などによって生成される鍵系列を用いて処理する方式（ストリーム暗号、または逐次暗号）に分けることができる。
公開鍵暗号
公開鍵と秘密鍵という対をなす２種類の鍵を用いる暗号（または暗号技術）を総称して公開鍵暗号（または公開鍵暗号技術）という。公開鍵から秘密鍵を求めることは計算の手間が膨大となり事実上困難であるという特性を持っている。守秘のための方式と署名のための方式とに大別でき、前者を（狭い意味で）公開鍵暗号方式、後者を公
開鍵署名方式と呼んで区別することがある。前者の意味での公開鍵暗号方式においては、平文を暗号化する時に用いる鍵（暗号化鍵）が公開鍵であり、暗号文を復号する時に用いる鍵（復号鍵）が秘密鍵である。公開鍵署名方式においては、平文に対して
署名文を生成する時に用いる鍵（署名生成鍵）が秘密鍵であり、署名文を検査し平文を取り出す時に用いる鍵（署名検査・復号鍵）が公開鍵である。

− 53 −

守秘
暗号利用形態の 1 つで、インターネット等のオープンなネットワークや、記録媒体を使って電子情報をやりとりするときに、知られて良い利用者以外には内容を知られないようにすること
署名
暗号利用形態の 1 つで、電子情報が正当であることを確認できるようにすること
この中には署名を作った者を確認すること（否認防止）と、電子情報自体が改竄されていないかを確認すること（完全性保証）の二つの目的がある
電子政府「行政の情報化により、事務・事業及び組織の改革を推進するとともに、セキュリティの確保等に留意しつつ、「紙」による情報の管理からネットワークを駆使した電子化された情報の管理へ移行し、高度に情報化された行政」のこと
詳細は「e‑Japan 重点計画‑2002（http://www.kantei.go.jp/jp/singi/it2/index.html
よりダウンロード可能）」を参照のこと
電子政府システム
電子政府を実現するための情報システム
本ガイドブックでは、主に、政府と国民の間で、書類の申請等の電子情報をやり取りするためのシステムを想定して記述している
成りすまし
第三者が、資格のある利用者のふりをして情報を利用すること
否認
情報を送信または受信したにもかかわらず、その事実を認めないこと
漏洩
情報の内容を第三者に知られてしまうこと− 54 −

参考１「各府省の情報システム調達における暗号の利用方針」

参考１
各府省の情報システム調達における暗号の利用方針
平成１５年２月２８日
行政情報システム関係課長連絡会議了承

電子政府における情報セキュリティ確保のために、各府省の情報システムにおいて暗号を利用する場合には、一定水準以上の安全性及び信頼性を有する暗号の利用が不可欠であり、また、その安全性・信頼性は客観的な評価を得たものであることが必要である。
かかる観点から、「電子政府の情報セキュリティ確保のためのアクションプ
ラン」（平成１３年１０月１０日、情報セキュリティ対策推進会議）に基づき、総務省及び経済産業省において、電子政府における調達のための推奨すべき暗号のリスト（「電子政府推奨暗号リスト」：別添参照）を策定したところである。
これを踏まえ、各府省は、情報システムの構築に当たり暗号を利用する場合には、調達仕様書において上記暗号リストに掲載された暗号を利用することを入札要件とする等の方法により、必要とされる安全性・信頼性などに応じ、可能な限り、「電子政府推奨暗号リスト」に掲載された暗号の利用を推進するものとする。
なお、総務省及び経済産業省は、「電子政府推奨暗号リスト」に掲載された暗号の安全性及び信頼性について、今後の情報通信技術の進展を踏まえ必要に応じ評価を行うとともに、「電子政府推奨暗号リスト」の内容の変更を行う場
合には本会議に報告することとする。

i

別

添

電子政府推奨暗号リスト
平成１５年２月２０日
総
経
技術分類

務
済

産

省
業

省

名称
署名

公開鍵暗号

守秘
鍵共有

64 ビットブロック暗号(注 3)

共通鍵暗号

128 ビットブロック暗号

ストリーム暗号

ハッシュ関数その他
擬似乱数生成系(注 7)

DSA
ECDSA
RSASSA-PKCS1-v1̲5
RSA-PSSRSA-OAEP
RSAES-PKCS1-v1̲5(注 1)
DH
ECDH
PSEC-KEM(注 2)
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1
3-key Triple DES(注 4)
AES
Camellia
CIPHERUNICORN-A
Hierocrypt-3
SC2000MUGI
MULTI-S01
128-bit RC4(注 5)
RIPEMD-160(注 6)
SHA-1(注 6)
SHA-256
SHA-384
SHA-512PRNG based on SHA-1 in ANSI X9.42-2001 Annex C.1
PRNG based on SHA-1 for general purpose in FIPS
186-2 (+ change notice 1) Appendix 3.1
PRNG based on SHA-1 for general purpose in FIPS
186-2 (+ change notice 1) revised Appendix 3.1

注釈：
(注 1)

SSL3.0/TLS1.0 で使用実績があることから当面の使用を認める。

(注 2)

KEM（Key Encapsulation Mechanism）-DEM(Data Encapsulation Mechanism)構成における利用を前提とする。

ii

(注 3)

新たな電子政府用システムを構築する場合、より長いブロック長の暗号が使用できるのであれば、128 ビットブロック暗号を選択することが望ましい。

(注 4)

3-key Triple DES は、以下の条件を考慮し、当面の使用を認める。
1) FIPS46-3 として規定されていること
2) デファクトスタンダードとしての位置を保っていること(注 5)128-bit RC4 は、SSL3.0/TLS1.0 以上に限定して利用することを想定している。なお、リストに掲載されている別の暗号が利用できるのであれば、そちらを使用することが望ま
しい。

(注6)

新たな電子政府用システムを構築する場合、より長いハッシュ値のものが使用できるのであれば、256ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべきハッシュ関数が指定されている場合には、この限りではない。

(注7)

擬似乱数生成系は、その利用特性上、インタオペラビリティを確保する必要性がないた
め、暗号学的に安全な擬似乱数生成アルゴリズムであれば、どれを利用しても基本的に問題が生じない。したがって、ここに掲載する擬似乱数生成アルゴリズムは「例示」で
ある。

iii

参考２
「評価・特徴一覧（公開鍵暗号）」「評価・特徴一覧（共通鍵暗号）」「評価・特徴一覧の利用にあたって」

評価・特徴一覧（公開鍵暗号）
利用形態

署名

暗号アルゴリズム名

参照すべき仕様書

守秘RSA-PSSRSA-OAEP

鍵共有

DSA

ECDSA

RSASSA-PKCS1-v1̲5

ANSI X9.30:1-1997(http://www.x9.org/)

SEC1 (Version 1.0)
(http://www.secg.org/)

PKCS#1v2.1
PKCS#1v2.1
PKCS#1v2.1
PKCS#1v2.1
ANSI X9.42-2001(http://www.rsasecurity.com/rs (http://www.rsasecurity.com/rs (http://www.rsasecurity.com/rs (http://www.rsasecurity.com/rs (http://www.x9.org/)alabs/pkcs/)
alabs/pkcs/)
alabs/pkcs/)
alabs/pkcs/)

RSAES-PKCS1-v1̲5

DH

ECDH

PSEC-KEM

SEC1 (Version 1.0)
(http://www.secg.org/)

PSEC-KEM仕様書(2002 年5 月14日)(http://info.isl.ntt.co.jp/psec/CRY
PTREC/index-j.html)

経験的安全性

○

○

○

○

○

○

○

○

-

証明可能安全性の有
無

-

-

-

○

○

-

-

-

○

-

-

-

ランダムオラクルモデル

ランダムオラクルモデル

-

-

-

ランダムオラクルモデル

-

-

-

RSA問題の困難性

RSA問題の困難性---

楕円曲線上のDH計算問題

-

-

-

適応的選択文書攻撃に対して存在的偽造不可適応的選択暗号文攻撃に対し
て強秘匿

-

-

-

鍵カプセル化メカニズムとして適応的選択暗号文攻撃に対して強
秘匿有限体上の離散対数問題

楕円曲線上の離散対数問題

素因数分解問題

素因数分解問題

素因数分解問題

素因数分解問題

有限体上の離散対数問題

楕円曲線上の離散対数問題

楕円曲線上の離散対数問題

仮定するモデル
帰着される問題

リストに載せた根拠

安全性の到達度
プリミティブの安全性の根拠
主なパラメータ・
補助関数に関する要件

参考２

パラメータの範囲

・｢参照すべき仕様書｣に記載の各暗号技術の仕様書で指定されたパラメータのうち、CRYPTREC Report 2002で指定された条件を満たすものを使用することハッシュ関数・電子政府推奨暗号リストに記載されたものを使用すること

擬似乱数生成器
電子署名法に○係る指針(注1)
・X9.30:1-1997
ANSI
・P1363-2000
IEEE(注2)
仕様策定

ISO/IEC(注3) ・14888-3
NESSIE(注4)

NIST(注5)
国際標準等への採用状況(2003年1-3月期)
(注6)

IETF
利用
実績

SET(注7)(注8)
SSL3.0(注9)
WAP/WTLS
W3C

(注10)

提案元

・電子政府推奨暗号リストの注釈7を参照のこと○
・X9.62-1998
・P1363-2000
・14888-3・15946-2

○

○

-

-

-

-

-

・11770-3

-

○

-

-

-

-

○ (Public-key Encryptionとして)

-

-

-

-

-

-

-

・RFC2246(Proposed Standard)
・RFC3275(Draft Standard)
・RFC3279(Proposed Standard)
・RFC3370(Proposed Standard)

・RFC2246(Proposed Standard)
・RFC3278(Informational)
・RFC3447(Informational)
・RFC3275(Draft Standard)
・RFC3279(Proposed Standard)
・RFC3279(Proposed Standard) ・pkix(Internet-Draft)・ipsec(Internet-Draft)
・RFC3370(Proposed Standard) ・smime(Internet-Draft)・tls(Internet-Draft)
・RFC3447(Informational)

・Standards for Efficient
Cryptography Group (SECG)

・ANSI

○
○
○
・XML-Signature Syntax andProcessing(12 February 2002)
・RSA Laboratories

・RFC3447(Informational)
・pkix(Internet-Draft)・smime(Internet-Draft)-

・X9.63-2001
・P1363-2000
・11770-3・15946-3○○○○
・XML Encryption Syntax and・XML Encryption Syntax and・XML Encryption Syntax andProcessing(10 December 2002) Processing(10 December 2002) Processing(10 December 2002)

・RSA Laboratories

・RSA Laboratories

・RSA Laboratories(b) 上記(a)の知的財産権の扱い(注11)

特記事項−

・より大きなサイズのパラメータ ・電子署名法の指針にも（一部を選択可能とするために仕様の のパラメータを除いて）適合して変更が検討されていることに注 いる。
・Koblitz曲線と呼ばれる曲線
意を払う必要がある。
は、そのクラス特有の攻撃法が出現する可能性に注意を払う必
要がある。

−

−

−

−

−

−

・18033-2(Committee Draft)

−

−

-

○

-

-

-

・Standards for Efficient
Cryptography Group (SECG)

・ANSI

−
富士通株式会社
RSAセキュリティ株式会社
RSAセキュリティ株式会社
RSAセキュリティ株式会社
RSAセキュリティ株式会社−
・SECG member patent letters RSAセキュリティ株式会社は、 RSAセキュリティ株式会社は、 RSAセキュリティ株式会社は、 RSAセキュリティ株式会社は、 (参考情報)(参考情報)
・ISO/IEC 14888-3 Annex Gで (http://www.secg.org/collateral 上記アルゴリズムについての知 上記アルゴリズムについての知 上記アルゴリズムについての知 上記アルゴリズムについての知 ・U.S. Patent 4,200,770, April/certicom̲secg̲patent.pdf)を参 的財産権を持たない。ただし、 的財産権を持たない。ただし、 的財産権を持たない。ただし、 的財産権を持たない。ただし、 1980(1997年に失効している)は、Contact Address欄に[no(a) 該当する license required]と記載されてい 照のこと。
上記アルゴリズムを具現化した 上記アルゴリズムを具現化した 上記アルゴリズムを具現化した 上記アルゴリズムを具現化した知的財産権 る・富士通株式会社の所有する特 ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリーズ）についての著作権は、同社 ズ）についての著作権は、同社 ズ）についての著作権は、同社 ズ）についての著作権は、同社
許は、特になし。
・U.S. Patent 5,231,668, Julyに帰属する。
に帰属する。
に帰属する。
に帰属する。
1993

電子政府利用にあたっての知的財産権の実施の権利に関する考え方-

・RFC2246(Proposed Standard)
・RFC3278(Informational)
・RFC2246(Proposed Standard) ・RFC2409(Proposed Standard)
・RFC3279(Proposed Standard)
・RFC3370(Proposed Standard) ・RFC2631(Proposed Standard)
・ipsec(Internet-Draft)
・RFC3370(Proposed Standard)
・RFC3447(Informational)・tls(Internet-Draft)
・RFC3279(Proposed Standard)

問い合わせ先（2）※当該知的財産権の内容、条件の詳細は、特許所有者、及びSECGのウェブサイトを参照のこと。
(http://www.secg.org/patent̲policy.htm ,http://www.secg.org/collateral/certicom̲secg̲patent.pdf ,http://www.secg.org/index.htm)
富士通は、本アルゴリズムに関する特許を所有していない。特許技術の使用許諾が必要となる場合には、上記URLを参照の
上、特許所有者と交渉するこ
と。

-

-

・P1363-2000○
・FIPS PUB 186-2(+Change
Notice1)---・P1363a(Draft)

・X9.44(Draft)--

・P1363a(Draft)○

・X9.42-2001
・P1363-2000

・FIPS PUB 186-2(+Change
Notice1)○・XML-Signature Syntax andProcessing(12 February 2002)

・電子政府推奨暗号リストに記載されたものを使用すること-・日本電信電話株式会社

富士通株式会社
日本電信電話株式会社
・SECG member patent letters ・特開2000-148011(http://www.secg.org/collateral 「ランダム関数利用公開鍵暗号/certicom̲secg̲patent.pdf)を参 の暗号装置」
・特開2001-222218
照のこと。
・富士通株式会社の所有する特 「暗号化装置、方法、複合装置、方法、暗号システム及びプログラ
許は、特になし。
ムを記憶した記憶媒体」（１）（2）※当該知的財産権の内容、条件の詳細は、特許所有者、及びSECGのウェブサイトを参照のこと。
(http://www.secg.org/patent̲policy.htm ,http://www.secg.org/collateral/certicom̲secg̲patent.pdf ,http://www.secg.org/index.htm)
富士通は、本アルゴリズムに関する特許を所有していない。特許技術の使用許諾が必要となる場合には、上記URLを参照の
上、特許所有者と交渉すること。

・SSL3.0/TLS1.0で使用実績が ・鍵とエンティティとの結び付き ・鍵とエンティティとの結び付き ・KEM(Key Encapsulation
Mechanism)-DEM(Dataを保証する手段を備え、またあり当面の使用を認める。
を保証する手段を備え、またセッション鍵として使用する場 セッション鍵として使用する場 Encapsulation Mechanism)構成に合、交換する公開鍵は一時的な 合、交換する公開鍵は一時的な おける利用を前提とする。
・Koblitz曲線と呼ばれる曲線は、ものとするべきである。
ものとするべきである。
そのクラス特有の攻撃法が出現
・Koblitz曲線と呼ばれる曲線
は、そのクラス特有の攻撃法が する可能性に注意を払う必要があ
出現する可能性に注意を払う必 る。
要がある。

注1: 米国規格協会(http://www.ansi.org) 注2: IEEE（電気電子学会）(http://homepage1.nifty.com/ieeetokyo/faq.htmによる) 注3: 国際標準化機構（International Organization for Standardization）/国際電気標準会議（International Electrotechnical Commission）(http://www.jisc.go.jp/international/isoiec.htmlによる) 注4: 欧州における暗号技術評価プロジェクトで、New European Schemes for Signatures, Integrity, and Encryptionの略称(http://www.cryptonessie.org) 注5: 米国の国立標準技術局(http://www.nist.gov) 注6: インターネットに係わる技術の標準化を制定する業界団体(Internet Engineering Task Force)(http://www.ietf.org/) 注7: Secure Electronic Transactionの略称(http://www.setco.org/) 注8: Secure Sockets Layer protocol(http://wp.netscape.com/eng/ssl3/) 注9: Wireless Application Protocol(http://www.wapforum.org/) 注10: World Wide Web Consortium(http://www.w3.org/) 注11: 括弧内の数字の意味については、別添２｢評価・特徴一覧の利用にあたって｣の｢○公開鍵暗号／共通鍵暗号 共通」「知的財産権情報について｣を参照のこと。

ⅳ

評価・特徴一覧（共通鍵暗号）
1.

64 ビットブロック暗号
評価項目
アルゴリズム安全性評価コメント*

Pentium III 実装

CIPHERUNICORN-E

Hierocrypt-L1

MISTY1[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[C-] 総合的な処理性能は Triple DES 同程度以下[A] 総合的な処理性能は Triple DES よりもかなり高い[B+] 総合的な処理性能は Triple DES よりも高い•

暗号化処理速度[C-]： Triple DES の 0.6 倍程度の性能•

暗号化処理速度[A]： Triple DES の 4.25 倍前後の性能•

暗号化処理速度[B+]： Triple DES の 4 倍超の性能•

鍵生成込暗号化処理[C-]： Triple DES の 0.8 倍程度の性能•

鍵生成込暗号化処理[A/B+]： 暗号化では Triple DES の 5.25•

鍵生成込暗号化処理[A]： Triple DES の 5.5 倍超の性能

倍程度、復号では同 3.2 倍程度の性能[C-] 総合的な処理性能は Triple DES 同程度以下

ソ

•

フ
ト
ウ

他プラットフォーム実装

UltraSPARC IIi での暗号化処理速度[C-]、鍵生成込暗号化•

Alpha 21264 での暗号化処理速度[C-]、鍵生成込暗号化処

性•理[C/C-]

実[C] 鍵交換ペナルティは中程度

装•

鍵生成時間は Triple DES と同程度である[B+] 総合的な処理性能は Triple DES よりも高い[B] FIPS 等で保証されている間は問題ないと考える[C] 実用的には問題ないことも多いが、一般には処理速度が遅いといわれる（基準性能）•

暗号化処理速度は遅いといわれる[C]•

鍵生成込暗号化処理は遅いといわれる[C][C] 実用的には問題ないことも多いが、一般にはUltraSPARC IIi での暗号化処理速度[B]、鍵生成込暗号化処•

UltraSPARC IIi での評価なし

理[B/C]•

Alpha 21264 での暗号化処理速度[A]、鍵生成込暗号化処理•

暗号化処理速度は遅いといわれる[C][A]•

鍵生成込暗号化処理は遅いといわれる[C]Alpha 21264 での暗号化処理速度[A]、鍵生成込暗号化処理

処理速度が遅いといわれる[A/B+]
•

ア

装

•

処理[D]

ェ

実

[B+] 総合的な処理性能は Triple DES よりも高い

3-key Triple DES

鍵生成込暗号化処理は暗号化よりも復号の方がより重い[B]鍵交換ペナルティは少ない•[B] 鍵交換ペナルティは少ない

鍵生成時間は、暗号化では Triple DES の 1/5 程度、復号では•鍵生成時間は Triple DES の 1/7 程度である[C] 鍵交換ペナルティは中程度•

鍵生成時間は暗号化処理と同程度の時間が必要である

2/5 程度である

鍵即応性**•

復号の場合には、暗号化の場合と比較して、少なくとも鍵生成
または復号のどちらかにより重い処理を実行させることが必要となるため、全体として性能が低下する[D 以下] 評価未実施であり、最終的な結論ではない [B] やや使用 ROM サイズが大きいことを除けば、総合 [B+] 総合的な処理性能および実装性は Triple DES [C] 総合的な処理性能および実装性はおおむねが、少なくとも Triple DES の処理性能と同程度以上に 的な処理性能および実装性は Triple DES よりもやや優 よりも優れている
メモリ制限環境での実装性能はならないと推定（低機能型 IC カード評価***）

れている

良好である

•

使用 ROM サイズは中程度[C-]•使用 ROM サイズは少ない[C]•使用 ROM サイズはやや大きい[D]•使用 RAM サイズは中程度[C-]•使用 RAM サイズは少ない[C]•使用 RAM サイズは少ない[C]•

処理速度は Triple DES よりも高速である[B+]•

処理速度は中程度といわれる[C]•

処理速度は Triple DES よりも高速であるが、復号性能は暗号化性能の約 85%程度[B+]ハードウェア実装

第三者実装が可能であることを確認

第三者実装が可能であることを確認

第三者実装が可能であることを確認

第三者実装が可能であることを確認* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。
** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。
*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数 k〜10kbyte 程度、RAM128byte 程度）を想定した評価を基にしている。

v

評価・特徴一覧（共通鍵暗号）（続） 64 ビットブロック暗号
評価項目

CIPHERUNICORN-E

ISO/IEC 9979 （アルゴリズム公開登録）
国際標準
などへの
採用状況

Hierocrypt-L1

MISTY1なし

仕様が定められた規格

仕様が

なし

なし

3-key Triple DES

IETF RFC 2994 (Informational)

ANSI X9.52-1998

ISO/IEC 9979 （アルゴリズム公開登録）

ANSI X9.65 (Working Draft)

ISO/IEC 18033-3 (Committee Draft)

FIPS PUB 46-3

NESSIE

ISO/IEC 18033-3 (Committee Draft)

なし

RFC 2246: SSL3.0/TLS1.0 (Proposed Standard)

引用された規格

そ
の
他

電子政府
利用にあ
たっての
提案元が
保有する
知的財産
権の実施
の権利に
関する考
え方

出願番号 PCT/JP96/02154
特許
特許出願番号（公開番号） 特願 2000-210484「データ変換装置及びデータ変換方法」
出願番号：出願平 9-213274「暗号化装置及び暗号化方法、復号装置及び復号（参考）
名称： 暗号装置及び暗号装置を実現するプログラ
方法並びに演算装置」
日本特許： 特許第 3035358 号
ムを記録したコンピューターが読み取り可能な 特許出願番号（公開番号） 特願 2000-211686
記録媒体「暗号化装置、復号装置及び拡大鍵生成装置、拡
著作物
大鍵生成方法並びに記憶媒体」(a)該当する知CIPHERUNICORN-E のプログラム
特許出願番号（公開番号） 特願 2000-212175
商標
的財産権「パラメータ決定装置、パラメータ決定方法、暗号化
登録番号 第 4221077 号
装置、および復号装置」
特許出願番号（公開番号） 特願 2001-68742「暗号化装置及び暗号化方法、復号装置及び復号
方法並びに記憶媒体」

FIPS PUB 46-3 において、Patents に関する記述は以下のとおり。
「Patents. Cryptographic devices implementing thisstandard may be covered by U.S. and foreign patents,
including patents issued to the International Business
Machines Corporation. However, IBM has granted
nonexclucive, royality-free licenses under thepatents to make, use and sell apparatus which
complies with this standard. The terms, conditions
and scope of the licenses are set out in notices
published in the May 13, 1975 and August 31, 1976
issues of the Official Gazette of the United States
Patent and Trademark Office (934 O.G. 452 and 949
O.G. 1717).」(b) 上記(a)の知的財産権の扱い

（２）

（２）

（１）

下記問い合わせ先 URL 等を参照のこと。

提案元

日本電気株式会社

株式会社東芝

三菱電機株式会社

NIST

問い合わせ先日本電気株式会社

株式会社東芝

三菱電機株式会社

http://csrc.nist.gov/encryption/tkencryption.html•

FIPS46-3 に登録されており、かつデファクトスタ
ンダードの地位にあることを考慮し、当面の使用

特記事項

を認める。
•

vi

2-key Triple DES での使用は推奨しない。

評価・特徴一覧（共通鍵暗号）
2.

128 ビットブロック暗号
評価項目
アルゴリズム安全性評価コメント*

AES

Camellia

CIPHERUNICORN-A

Hierocrypt-3

SC2000[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 総合的な処理性能は Triple DES よりも[A] 総合的な処理性能は Triple DES より [C] 総合的な処理性能は Triple DES 同 [B+] 総合的な処理性能は Triple DES より [A] 総合的な処理性能は Triple DES よりもかなり高い

もかなり高い•暗号化処理速度[A+/A]： 暗号化では Triple•

DES の 7 倍超、復号では同 4.75 倍程度の性能

Pentium III 実装•(128 ビット鍵)

鍵 生 成 込 暗 号 化 処 理 [A+/B] ： 暗 号 化 で は

•

ソ
フ
実
装
性

ト
ウ
ェ
ア

•

鍵生成込暗号化処理[A+]： Triple DES の 8.3

暗号化処理速度[C]： Triple DES 同程度の性

鍵長により処理速度が 25%程度低下•

鍵生成込暗号化処理[C]： Triple DES の 0.8•

暗号化処理速度[A/B+]： Triple DES の 4 倍超

•

の性能
•

鍵 生 成 込 暗 号 化 処 理 [A/B+] ： 暗 号 化 で は倍程度の性能Triple DES の 5.5 倍弱、復号では同 3 倍弱の性

鍵長による処理速度低下はほとんどない能•鍵長により処理速度が 15-30%程度低下

かなり高い
後の性能
•

鍵生成込暗号化処理[A]： Triple DES の 5 倍弱の性能•

鍵長によって、処理速度が 15%程度低下

鍵長により処理速度が 15-25%程度低下[B+] 総合的な処理性能は Triple DES より [A] 総合的な処理性能は Triple DES よりもかなり高い

もかなり高いも高い•

UltraSPARC IIi での評価未実施•

Alpha 21264 での暗号化処理速度[A+/-]、鍵生成込暗号化処理は[B+/-]•

UltraSPARC IIi での暗号化処理速度[A]、鍵程度以下•

UltraSPARC IIi での暗号化処理速度[C-]、鍵生成込暗号化処理[A]•

鍵生成込暗号化処理は、暗号化よりも復号のAlpha 21264 での暗号化処理速度[A+]、鍵生•

生成込暗号化処理[D-]•Alpha 21264 での暗号化処理速度[C/C+]、鍵成込暗号化処理[A+]UltraSPARC IIi での暗号化処理速度[B+/B]、

かなり高い
•

鍵生成込暗号化処理[B+/C]•

生成込暗号化処理[C/C-]

Alpha 21264 での暗号化処理速度[A]、鍵生成

鍵生成込暗号化処理は、暗号化よりも復号の•[B] 鍵交換ペナルティは小さい[D] 鍵交換ペナルティは大きい[B/C] 鍵交換ペナルティは小〜中程度• 鍵生成時間は、暗号化では Triple DES の 1/5••• 鍵生成時間は、暗号化では Triple DES の 1/3

鍵生成時間は Triple DES の 1/7 程度である

鍵生成時間は Triple DES の 3 倍程度である

程度、復号では Triple DES と同程度である

程度、復号では Triple DES と同程度である• 復号の場合には、暗号化の場合と比較して、少• 復号の場合には、暗号化の場合と比較して、なくとも鍵生成または復号のどちらかにより重い

少なくとも鍵生成または復号のどちらかにより処理を実行させることが必要となるため、全体と重い処理を実行させることが必要となるため、して性能が低下する全体として性能が低下する

Alpha 21264 での暗号化処理速度[A+]、鍵生成
込暗号化処理[A+]•方がより重い[B/C] 鍵交換ペナルティは小〜中程度

UltraSPARC IIi での暗号化処理速度[A]、鍵生
成込暗号化処理[B+]込暗号化処理[A/B+]•

方がより重いとされる

鍵即応性**

暗号化処理速度[A]： Triple DES の 4.25 倍前[A] 総合的な処理性能は Triple DES より [C-] 総合的な処理性能は Triple DES 同

•

装

•

能

倍超の性能
•

も高い

[A] 総合的な処理性能は Triple DES よりも他プラットフォーム実装

実

•

度の性能

Triple DES の 7 倍弱、復号では同 2.3 倍程度の性能

暗号化処理速度[A]： Triple DES の 5.25 倍程

程度

キャッシュサイズが大きい CPU では実装性能が向上[B] 鍵交換ペナルティは小さい•

鍵生成時間は Triple DES の 1/3 程度である* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。
** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

vii

評価・特徴一覧（共通鍵暗号）（続） 128 ビットブロック暗号
評価項目

AES

Camellia

CIPHERUNICORN-A

Hierocrypt-3

SC2000[B+] 総合的な処理性能および実装性は [B+] 総合的な処理性能および実装性は [D 以下] 評価未実施であり、最終的な結 [B] やや使用メモリ量が大きいことを除け [C+] 総合的な処理性能および実装性はTriple DES よりも優れている
実

メモリ制限環境での実装性能

装（低機能型 IC カード評価***）性

ハードウェア実装
仕様が定められた規格

Triple DES よりも優れている•

使用 ROM サイズは少ない[C]•使用 ROM サイズは少ない[C]•使用 RAM サイズは中程度[C-]•使用 RAM サイズは中程度[C-]••

処理速度は Triple DES よりも高速である[B+]•

処理速度は Triple DES よりも高速である[B+]•

復号処理速度は暗号化処理速度の約 70%程度

使用 ROM サイズは中程度[C-]使用 ROM サイズはやや大きい[D]•使用 RAM サイズは中程度[C-]•使用 RAM サイズはやや大きい[D]•

処理速度は Triple DES 同程度以上[C+]•

処理速度は Triple DES よりも高速である[B+/B]•

復号処理速度は暗号化処理速度の約 70%程度

第三者実装が可能であることを確認

第三者実装が可能であることを確認

第三者実装が可能であることを確認

FIPS PUB 197

IETF RFC: (Internet Draft)

なし

なし

なし

ISO/IEC 18033-3 (Committee Draft)

ISO/IEC 18033-3 (Committee Draft)

NESSIENESSIE
なし

なし

なし

特許出願番号（公開番号）
特願 2000-210484「暗号化装置及び暗号化方法、復号装置
及び復号方法並びに演算装置」
特許出願番号（公開番号）
特願 2000-211686「暗号化装置、復号装置及び拡大鍵生成装置、拡大鍵生成方法並びに記憶媒体」
特許出願番号（公開番号）
特願 2000-212175「パラメータ決定装置、パラメータ決定方
法、暗号化装置、および復号装置」
特許出願番号（公開番号）
特願 2001-68742「暗号化装置及び暗号化方法、復号装置
及び復号方法並びに記憶媒体」

特願 2001-108016 （特開 2001-282102）「暗号設計装置、暗号設計プログラム
及び記憶媒体」
特願 2000-212813 （特開 2000-91297）「F 関数内部に SPN 構造を用いた演算装置及び演算方法」
特願 2000-212814 （特開 2002-91295）「Feistel 構造と SPN 構造とを組み合わせた演算装置及び演算」
特願 2000-212482 （特開 2002-91296）「拡大鍵生成装置及び記憶媒体」(Proposed Standard)などへのIETF RFC 3394: AES Key Wrap Algorithm TV-Anytime Forum Specification S-7
引用された規格•

Triple DES よりやや優れている

第三者実装が可能であることを確認

国際標準

仕様が

理性能と同程度以上にはならないと推定

第三者実装が可能であることを確認

IETF RFC 3268: AES Ciphersuites for TLS IETF TLS1.0 (Internet Draft)

採用状況論ではないが、少なくとも Triple DES の処 ば 、 総 合 的 な 処 理 性 能 お よ び 実 装 性 は Triple DES と同程度以上

IETF S/MIME (Internet Draft)(Informational)
IETF S/MIME (Internet Draft)
IETF IPsec (Internet Draft)
TV-Anytime Forum Specification S-7

その他

WAP/WTLS1.0
特許
FIPS PUB 197 において、Patents に関 特願 2001-565161
出願番号：出願平 9-213274「データ変換装置及びデータ変換方法
する記述は以下のとおり。
名称： 暗号装置及び暗号装置を実現
をコンピュータに実行させるプログラム
するプログラムを記録したコンを記録したコンピュータ読み取り可能な「Patents. Implementation of the algorithm
電子政
ピ
記録媒体」
specified in this standard may be covered
府利用ューターが読み取り可能な記録
PCT/JP01/01796
by U.S. and foreign patents.」にあたっ
媒体「データ変換装置及びデータ変換方法ての提案(a) 該 当 す るをコンピュータに実行させるプログラム 著作物
元が保有
知的財産権
CIPHERUNICORN-A のプログラムを記録したコンピュータ読み取り可能な
する 知的
商標
記録媒体」
財産権
登録番号 第 4221077 号
中華民国出願 90105464の実施「データ変換装置及びデータ変換方法の権利をコンピュータに実行させるプログラムに関するを記録したコンピュータ読み取り可能な
考え方
記録媒体」
(b) 上記(a)の知的財産権の扱い
提案元

問い合わせ先下記問い合わせ先 URL 等を参照のこと。
NIST

（１）

（２）

（２）

（２）

日本電信電話株式会社

日本電気株式会社

株式会社東芝富士通株式会社

日本電気株式会社

株式会社東芝富士通株式会社

三菱電機株式会社

http://csrc.nist.gov/encryption/tkencrypti

日本電信電話株式会社

on. html

三菱電機株式会社

特記事項*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数〜10KB 程度、RAM128byte 程度）を想定した評価を基にしている。

viii

評価・特徴一覧（共通鍵暗号）
3.

ストリーム暗号
評価項目

MUGI

アルゴリズム安全性評価コメント*

ソフトウェア実

実装[A+] 処理性能は Triple DES よりもかなり高い[A+] 処理性能は Triple DES よりもかなり高い[A+] 処理性能は Triple DES よりもかなり高い

•

•

•

暗号化処理速度[A+]： Triple DES の 10.75 倍前後の性能である

鍵生成時間は Triple DES の 20 倍程度である

メモリ制限環境での実装性能

どへの採用
状況

仕様が

の
他

ない
暗号化処理速度[A+]： Triple DES の 8.3 倍の性能である[D] 鍵交換ペナルティは大きい•―――

鍵生成時間は Triple DES の 5 倍前後である

―――

―――

第三者実装が可能であることを確認

第三者実装が可能であることを確認

なし

ISO/IEC 18033-4 (Committee Draft)

ISO/IEC 9979 （アルゴリズム非公開登録）

―――

なし

なし

RFC 2246: SSL3.0/TLS1.0 (Proposed Standard)

特願 2001-145783 （公開番号なし）

特願 2000-108334 （特開 2001-007800）「暗号化装置および方法」

RSA セキュリティ株式会社によると、RC4 に関する権利は以下のとおり。

特願 2001-274433 （公開番号なし）

特願 2000-210690 （特開 2001-324925）"The mark RC4 is a registered trademark of RSA Security Inc. and may not be「疑似乱数生成装置またはそれを用いた暗号復号処理装置」「共通鍵暗号方法及び装置」

定められた規格仕様が引用された規格「疑似乱数生成装置またはそれを用いた暗号復号処理装置」

そ

暗号化処理速度[A+]： Triple DES の 7.5 倍前後の性能である―――（低機能型 IC カード***）

国際標準な[B] SSL/TLS としての利用に関しては、今のところ問題は見つかってい[A] 今のところ問題は見つかっていない•

ハードウェア実装

128-bit RC4[A] 今のところ問題は見つかっていない[E] 鍵交換ペナルティは非常に大きい

鍵即応性**

装性Pentium III 実装

MULTI-S01

電子政府
利用にあた
っ て の 提 案 (a) 該当する
元が保有す
知的財産権
る 知的財産
権の実施
の権利に
関する考え
方

used by third parties creating implementations of the algorithm. RSA Security
does not hold any patents nor does it have any pending applications on the RC4algorithm. However, RSA Security does not represent or warrant that
implementations of the algorithm will not infringe the intellectual property rights
of any third party. Proprietary implementations of the RC4 encryption algorithm
are available under license from RSA Security Inc. For licensing information,
contact: RSA Security Inc. 2955 Campus Drive, Suite 400, San Mateo, CA
94403-2507, USA, or http://www.rsasecurity.com."(b) 上記(a)の知的財産権の扱い（２）（２）

下記問い合わせ先等に照会のこと。

提案元

株式会社日立製作所

株式会社日立製作所

RSA セキュリティ株式会社

問い合わせ先株式会社日立製作所

株式会社日立製作所

RSA セキュリティ株式会社
128 ビット鍵長を選択のうえ、SSL3.0/TLS1.0 に限定して利用することを想定している。その他の暗号を利用できるのであれば、そちらを選択することが望まし

特記事項

い。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。
** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。
*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数 k〜10kbyte 程度、RAM128byte 程度）を想定した評価を基にしている。

ix

評価・特徴一覧（共通鍵暗号）
4.

ハッシュ関数評価項目

RIPEMD-160

SHA-1

SHA-256

SHA-384

SHA-512[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない[A] 今のところ問題は見つかっていない

アルゴリズム安全性評価コメント*
ソフトウェア実装[A+] 処理速度は Triple DES よりも極めて [A+] 処理速度は Triple DES よりも極めて[A] 処理速度は Triple DES よりもかなり速 [C+] 処理速度は SHA-512 相当であり、

実（Pentium III 実装）

速い

い

装

メモリ制限環境での実装性能性（低機能型 IC カード***）ハードウェア実装
仕様が
国際標準な

速い
―――

―――

―――

―――

―――

―――

―――

―――

―――

ISO/IEC 10118-3

仕様がANSI X9.30 (Part2)

FIPS PUB 180-2

FIPS PUB 180-2

FIPS PUB 180-2

FIPS PUB 180-2

NESSIENESSIENESSIEなし

なし

なし

IETF RFC 3174 (Informational)

格状況[C+] 処理速度は Triple DES 同程度以上―――定められた規どへの採用

Triple DES 同程度以上

ISO/IEC 10118-3
なし

RFC 2246: SSL3.0/TLS1.0 (Proposed Standard)

下記 URL において、Patents に関する記述は以下のとおり。
「 The authors of RIPEMD-160 and
RIPEMD-128 do not hold any patents on
the algorithms (nor on the optional
extensions), and are also not aware of any
patents on these algorithms.」

FIPS PUB 180-2 において、Patents に関す FIPS PUB 180-2 において、Patents に関す FIPS PUB 180-2 において、Patents に関す FIPS PUB 180-2 において、Patents に関する記述は以下のとおり。
る記述は以下のとおり。
る記述は以下のとおり。
る記述は以下のとおり。
「Patents. Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」「Patents. Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」「Patents. Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」「Patents. Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」

下記問い合わせ先 URL 等を参照のこと。

下記問い合わせ先 URL 等を参照のこと。

下記問い合わせ先 URL 等を参照のこと。

下記問い合わせ先 URL 等を参照のこと。

下記問い合わせ先 URL 等を参照のこと。

NIST

NIST

NIST

NIST

http://cscr.nist.gov/encryption/tkhash.html

http://cscr.nist.gov/encryption/tkhash.html

http://cscr.nist.gov/encryption/tkhash.html

http://cscr.nist.gov/encryption/tkhash.html

引用された規
格

そ
の
他

電子政府
利用にあた
っての提案 (a) 該当する
元 が 保 有 知的財産権
する知的財
産権の実
施の権利
に関する考 (b) 上記(a)のえ方
知的財産権の扱い
提案元

問い合わせ先Hans Dobbertin, Antoon Bosselaers, andBart Preneel
http://www.esat.kuleuven.ac.be/˜bosselae/ ripemd160.html

より長いハッシュ値のものを採用すること より長いハッシュ値のものを採用することができるのであれば、256 ビット以上のハッ ができるのであれば、256 ビット以上のハッ
特記事項

シュ関数を選択することが望ましい。ただ シュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべき し、公開鍵暗号での仕様上、利用すべき
ハッシュ関数が指定されている場合には、 ハッシュ関数が指定されている場合には、
この限りではない。

この限りではない。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。
** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。
*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数 k〜10kbyte 程度、RAM128byte 程度）を想定した評価を基にしている。

x評価・特徴一覧（共通鍵暗号）
5.

擬似乱数生成系（例示）PRNG based on SHA-1 in ANSI X9.42-2001 Annex C.1

評価項目

アルゴリズム安全性評価コメント*
ソフトウェア実装
実（Pentium II/III 実装）

装メモリ制限環境での実装性能性（低機能型 IC カード***）

仕様が

などへの採
用状況

そ
の
他

PRNG based on SHA-1 for general purpose in FIPS 186-2 (+ change notice 1)

Appendix 3.1

revised Appendix 3.1[A] 今のところ、パラメータなどを適切に設定すれば、実用上の重大な [A] 今のところ、パラメータなどを適切に設定すれば、実用上の重大な[A] 今のところ、パラメータなどを適切に設定すれば、実用上の重大な問題点は見つかっていない

問題点は見つかっていない

問題点は見つかっていない[A+] ほぼ SHA-1 の処理速度に等しい。SHA-1 の実装性能を参照。

[A+] ほぼ SHA-1 の処理速度に等しい。SHA-1 の実装性能を参照。

[A+] ほぼ SHA-1 の処理速度に等しい。SHA-1 の実装性能を参照。

ハードウェア実装
国際標準

PRNG based on SHA-1 for general purpose in FIPS 186-2 (+ change notice 1)

―――

―――

―――

―――

―――

―――

ANSI X9.42-2001 Annex C.1

FIPS PUB 186-2 (+ change notice 1) Appendix 3.1

FIPS PUB 186-2 (+ change notice 1) Revised Appendix 3.1

なし

なし

なし

FIPS PUB 186-2 において、Patents に関する記述は以下のとおり。
「Patents. The algorithms in this standard may be covered by U.S. andforeign patents.」

FIPS PUB 186-2 において、Patents に関する記述は以下のとおり。
「Patents. The algorithms in this standard may be covered by U.S. andforeign patents.」

下記問い合わせ先 URL 等を参照のこと。

下記問い合わせ先 URL 等を参照のこと。

NIST

NIST

http://cscr.nist.gov/encryption/tkrng.html

http://cscr.nist.gov/encryption/tkrng.html

定められた規格仕様が引用された規格電子政府
利 用 に あ (a) 該 当 す る
下記問い合わせ先等に照会のこと。
た っ て の 知的財産権
提案元が
保有する
知的財産
権 の 実 施 (b) 上記(a)の知の 権 利 に 的財産権の扱い 下記問い合わせ先等に照会のこと。
関する考
え方
提案元
ANSI
問い合わせ先特記事項

日本規格協会仕様書中で定義されている使い方の中には安全とは言い切れない方法 仕様書中で定義されている使い方の中には安全とは言い切れない方法

仕様書中で定義されている使い方の中には安全とは言い切れない方法がある。利用の際には、CRYPTREC Report 2002 の該当節を確認のう がある。利用の際には、CRYPTREC Report 2002 の該当節を確認のうがある。利用の際には、CRYPTREC Report 2002 の該当節を確認のう

え、適切な使い方を選択する必要がある。

え、適切な使い方を選択する必要がある。

え、適切な使い方を選択する必要がある。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。
** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。
*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数 k〜10kbyte 程度、RAM128byte 程度）を想定した評価を基にしている。

xi

評価・特徴一覧の利用にあたって○公開鍵暗号/共通鍵暗号 共通
知的財産権情報について
各応募暗号の、電子政府システムでの利用における提案元が保有する知的財産権の実施の権利の取扱いについて、提案元に確認を行った。「（b） 上記（a）の知的財産権の取扱い」の「（1）」「（2）」は、それぞれ以下のような取扱いを示す。
※提案元以外の第三者が保有する知的財産権については、その有無も含めて確認されていないので、注意すること。

（１） 当社は、上記「暗号アルゴリズム名」に記載された暗号アルゴリズムの使用にあたって、上記（a）に記載されている当社保有知的財産権に関し、いかなる者に対しても、非差別的かつ無償で通常実施権（又は著作権の利用）を許諾する。ただし、当該暗号アルゴリズムに関連する他の知的財産権所有者であって、（１）の条件で自らの知的財産権の実施を許諾しない者に対しては、この
限りではない。

（２） 当社は、上記「暗号アルゴリズム名」に記載された暗号アルゴリズムの使用にあたって、上記（a）に記載されている当社保有知的財産権に関し、いかなる者に対しても、当該知的財産権の権利の内容、条件を明らかにした上で、非差別的かつ妥当な条件（無償の場合を除く。）で通常実施
権（又は著作物の利用）を許諾する。ただし、当該暗号アルゴリズムに関連する他の知的財産権所有者であって、（１）又は（２）の条件で自らの知的財産権の実施を許諾しない者に対しては、この限りではない。

○共通鍵暗号
各評価項目における記号表記は以下のように設定されている。なお、評価基準が各評価
項目により異なるので、評価項目間の単純な記号比較は意味がないことに注意されたい。
1.

アルゴリズムの安全性評価について
安全な実装が行われているとの前提のもとに、アルゴリズムそのものの安全性強度を評価したものであり、その結果を表 1 の基準に従って示す。CRYPTREC としては B 以上を実用上安全であると判断する。
すなわち、電子政府推奨暗号リストに掲載されている暗号は全て B 以上の評価を受けたものである。

xii

なお、実装方法によっては、安全とされるアルゴリズムを使用したとしても、さまざまな実装攻撃にさらされる危険性を排除できない。したがって、実装攻撃の脅威に対する十分な配慮・検討を行い、適切な対策を施して実装するよう注意されたい。実装攻撃に対する詳細については、CRYPTREC Report 2002
第 3 章『共通鍵暗号技術の評価』中の個別暗号技術の結果（第 3.3 節）、ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

表 1：アルゴリズム安全性評価における記号表記基準
A

今のところ問題は見つかっていない

B

学術的には解読可能とされるが、今後 10 年間の使用について実用上の問題はないと考えるC

今後 10 年間に現実時間内で解読に成功する可能性がある

D

現実時間内で解読に成功する

2.

ソフトウェア実装評価について•

ソフトウェアによる処理性能では表 2 の基準にしたがって表すものとし、基準表価値として Triple
DES の性能を評価「C」の中位に設定する。
なお、各評価段階は 1.5 倍の処理性能差により区分されるものとする。

性能比較のイメージ図
1.5 倍性能差

1.225 倍性能差

2.25(=1.5x1.5)倍性能差

高性能
A+

低性能
A

B+

B

C+

C

C-

D

D-

E

Triple DES の性能

表 2：ソフトウェアによる処理性能における記号表記基準
Triple DES との相対性能比

評価コメントA+

6.20 倍以上

Triple DES の処理性能と比較して極めて高いA

6.20 – 4.13 倍

Triple DES の処理性能と比較してかなり高い

B+

4.13 – 2.76 倍

Triple DES の処理性能と比較して高いB

2.76 – 1.84 倍

Triple DES の処理性能と比較してやや高いC+

1.84 – 1.23 倍

Triple DES 同程度以上の性能

C1.23 – 0.82 倍

Triple DES 同程度の性能

C-

0.82 – 0.54 倍

Triple DES 同程度以下の性能

D0.54 – 0.36 倍

Triple DES の処理性能と比較してやや低いD-

0.36 – 0.24 倍

Triple DES の処理性能と比較して低いE

0.24 – 0.16 倍

Triple DES の処理性能と比較してかなり低い

E-

0.16 倍以下

Triple DES の処理性能と比較して極めて低い

xiii

E-

注意事項
i.

最速値と平均値が測定されている暗号技術については最速値を採用する。

ii.

規定計測プログラムと修正計測プログラムとの両方が測定されている暗号技術については、速い方の値を採用する。

iii.

記号に付随する数値は、Triple DES との相対性能比を表す。

iv.

X/Y と表記されている暗号技術は、暗号化性能評価が X、復号性能評価が Y であることを示す。
特に区別がない場合は、暗号化性能と復号性能が同程度であることを示す。

v.

X〜Y と表記されている暗号技術は、プラットフォーム（Pentium II/III, UltraSPARC IIi, Alpha21264）等の実装条件によって性能評価が X から Y まで変わりうることを示す。

•

ソフトウェアによる鍵即応性では、表 3 に示す基準にしたがって表すものとする。なお、Triple DESの性能を評価「C」の中位に設定する。

表 3：鍵即応性における記号表記基準
Triple DES 鍵セットアップ

評価コメントとの相対クロック比
A

0.10 倍以下

鍵交換ペナルティはほとんどないB

0.10 – 0.47 倍

鍵交換ペナルティは少ないC

0.47 – 2.15 倍

鍵交換ペナルティは中程度

D

2.15 – 9.9 倍

鍵交換ペナルティは大きいE

9.9 倍以上

鍵交換ペナルティが非常に大きい

性能比較のイメージ図
4.62 (=2.15x2.15)倍性能差

2.15 倍性能差

高性能

低性能
A

B

C

D

E

Triple DES の性能

注意事項
i.

本評価の便宜上、暗号化処理速度と鍵込処理速度の差を鍵セットアップ時間とみなす。

ii.

最速値と平均値が測定されている暗号技術については、最速値を採用する。

iii.

規定計測プログラムと修正計測プログラムとの両方が測定されている暗号技術については、速い方の値を採用する。

iv.

X/Y と表記されている暗号技術は、暗号化性能評価が X、復号性能評価が Y であることを示
す。

xiv

•

メモリ制限環境における使用メモリ量および逐次副鍵生成の評価項目では、表 4 の基準にしたがって表すものとする。なお、Triple DES の性能を評価「C」の中位に設定するため、評価「A+, A, B+,
B」に該当する評価値はないことに注意されたい。

表 4：使用メモリ量および逐次副鍵生成における記号表記基準
使用メモリ量
ROM

RAM

C+

0.5 KB 以下

16 byte 以下C

0.5 – 1.5 KB

16 – 32 byte

逐次副鍵生成 (on-the-fly subkey generation)--処理性能低下および使用 RAM サイズ増加がほとんどなしに実行可能
処理性能低下および使用 RAM サイズ増加がほとんどC-

1.5 – 2.5 KB

32 – 64 byte

なしに実行可能。ただし、復号性能は暗号化性能に比
べて劣る。

D

2.5 – 5 KB

64 – 80 byte

若干の処理性能低下または使用 RAM サイズ増加を必要とするが、実行可能
若干の処理性能低下または使用 RAM サイズ増加を必D-

5 – 10 KB

80 – 128 byte

要とするが、実行可能。ただし、復号性能は暗号化性能に比べて劣る。

E

10 – 20 KB

128 – 256 byte

E-

20 KB 以上

256 byte 以上

著しい処理性能低下または大幅な使用 RAM サイズ増
加がなければ実行困難。
---

以

xv

上