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

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

目次

１．はじめに········································································································································· 1
２．暗号技術検討会開催の背景、構成員及び開催状況 ································································· 3
２．１．暗号技術検討会開催の背景 ····························································································· 3
２．２．CRYPTREC の体制············································································································ 3
２．２．１．暗号技術検討会 ····································································································· 3
２．２．２．暗号技術評価委員会 ····························································································· 4
２．３．メンバー ····························································································································· 5２．３．１．暗号技術検討会メンバー ····················································································· 5２．３．２． 暗号調達ガイドブック作成ＷＧメンバー······················································ 6
２．４．開催状況 ····························································································································· 7
３．電子政府推奨暗号リスト ············································································································· 8
３．１．e-Japan 重点計画及びセキュリティ・アクションプランにおける電子政府の実現及び暗号技術評価の位置付け ························································································· 8
３．２．暗号技術評価について ··································································································· 10
３．２．１．暗号技術評価の目的 ··························································································· 10
３．２．２．評価概要 ··············································································································· 10
３．２．３．各暗号技術の評価基準の概要 ··········································································· 11
３．２．４．暗号技術評価結果の概要 ··················································································· 12３．３．電子政府推奨暗号リスト ······························································································· 19
３．４．電子政府推奨暗号の仕様に関する情報提供 ······························································· 23
４．暗号調達のためのガイドブックについて ··············································································· 24
４．１．暗号調達ガイドブック作成 WG 設置の目的 ······························································ 24
４．２．ガイドブック作成の進め方 ··························································································· 24
４．２．１．対象とする読者 ··································································································· 24
４．２．２．盛り込む内容 ······································································································· 24
４．２．３．ISO/IEC15408 を活用した調達との関連 ·························································· 24
４．２．４．検討方法 ··············································································································· 25
４．２．５．WG 会合の開催状況 ··························································································· 25
４．３．ガイドブックの概要 ······································································································· 26
４．３．１．システム全体の検討作業と暗号調達作業との関わり ··································· 26
４．３．２．電子政府システムにおける暗号利用イメージ ··············································· 27
４．３．３．暗号利用形態及び暗号技術分類 ······································································· 27

４．３．４．電子政府推奨暗号の概要 ··················································································· 27
４．３．５．暗号調達の手順に関する説明 ··········································································· 27
４．３．６．調達仕様書作成上の留意点 ··············································································· 31
４．３．７．調達先の決定、契約及び納品 ··········································································· 31
４．３．８．参考資料 ··············································································································· 32
５．今後の CRYPTREC 活動について····························································································· 33
５．１．今後の CRYPTREC の活動目的及び活動内容····························································· 33
５．１．１．活動目的 ··············································································································· 33
５．１．２．活動内容 ··············································································································· 33
５．２．今後の CRYPTREC 体制································································································· 34
５．２．１．暗号技術検討会 ··································································································· 34
５．２．２．暗号技術監視委員会 ··························································································· 35
５．２．３．暗号モジュール委員会 ······················································································· 35
５．３．電子政府推奨暗号の監視 ······························································································· 36
５．３．１．電子政府推奨暗号の監視の基本的考え方 ······················································· 36
５．３．２．電子政府推奨暗号の監視の具体的内容 ··························································· 36
５．３．３．電子政府推奨暗号の監視の手順 ······································································· 38
５．４．電子政府推奨暗号リストの改訂 ··················································································· 40
５．４．１．基本的認識 ··········································································································· 40
５．４．２．基本的考え方 ······································································································· 40
５．５．暗号モジュールに関する検討 ······················································································· 40【資料】
・「暗号調達のためのガイドブック」【参考資料】
・「各府省の情報システム調達における暗号の利用方針」

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

び経済産業省に対して報告するとともに、電子政府を構築する各府省関係者、及び一般の暗号ユーザの方々にも広く読んで頂くことを想定している。
なお、2002 年度の CRYPTREC 活動のうち、詳細な技術的事項については、暗号技術評
価委員会並びに同委員会の下に設置された共通鍵暗号評価小委員会及び公開鍵暗号評価小委員会における議論を踏まえて、IPA 及び TAO によってまとめられている「CRYPTREC
Report 2002」を御参照頂きたい。
本検討会は、2002 年度、当面の目標であった電子政府推奨暗号リスト案及び暗号調達
ガイドブックを作成した。しかしながら、国民が安心して利用できる電子政府を構築し、運用していくためには、2003 年度以降も継続して暗号技術を監視し、評価するとともに、暗号モジュールに関する安全性評価基準を作成する等の活動を実施していく必要がある。
これらの活動を実施していくためには、CRYPTREC 関係者が一致団結することが不可欠であり、今後とも関係者の方々の御協力を頂きながら、暗号技術検討会をはじめとする
CRYPTREC 活動を積極的に推進していきたい。
末筆であるが、本検討会にご協力いただいた構成員の方々及びオブザーバとしてご参加頂いた方々、精力的に暗号調達ガイドブックを作成して頂いた暗号調達ガイドブック作成
WG の構成員の方々をはじめ関係者の皆様に心から謝意を表する次第である。

2003 年 3 月
暗号技術検討会
座長 今井 秀樹2

２．暗号技術検討会開催の背景、構成員及び開催状況
２．１．暗号技術検討会開催の背景
高度情報通信ネットワークの安全性及び信頼性の確保は、我が国が目指す世界最先端の IT 国家構築の基盤となるものであり、国民一人一人が安心してネットワークを利用するための前提となるものである。高度情報通信ネットワーク社会形成基本法に基づく
e-Japan 重点計画（2001 年 3 月 29 日高度情報通信ネットワーク社会推進戦略本部決定）
及び e-Japan 重点計画-2002（2002 年 6 月 18 日 同本部決定）では、特に電子政府、電子商取引、重要インフラについて、ネットワークにおける脅威に起因するサービス提供
機能の停止をゼロとすることを目標として、政府は情報セキュリティのための諸施策を実施することとされている。
暗号技術は情報セキュリティの基盤技術であり、その安全性を暗号技術の専門家により技術的、専門的な見地から客観的に評価することが重要である。また、2003 年度までに「電子政府」の実現が予定されており、そのセキュリティ確保のためには、安全性に優れた暗号技術を利用することが不可欠である。
このため、総務省及び経済産業省は、客観的な評価により安全性及び実装性に優れると判断される暗号技術をリスト化し、各府省に対してその利用を推奨することにより、高度な安全性と信頼性に支えられ、国民が安心して利用できる電子政府の構築に貢献することを目指すこととした。
２．２．CRYPTREC の体制
CRYPTREC とは Cryptography Research and Evaluation Committees の略であり、総務省
及び経済産業省が共同で開催する暗号技術検討会（座長：今井秀樹東京大学教授）と、
通信・放送機構（TAO）及び情報処理振興事業協会（IPA）が共同で開催する暗号技術評価委員会（委員長：今井秀樹東京大学教授）による暗号技術評価プロジェクトを指す（CRYPTREC の体制図は図１参照）。検討会及び評価委員会は以下のように検討及び評価を進めた。
２．２．１．暗号技術検討会
暗号技術検討会（以下、「検討会」）は、総務省及び経済産業省に対して暗号利用に関する助言を行うとともに、電子政府における暗号利用に関する政策的判断を行った。
また、検討会の下には、必要に応じてワーキンググループを設置し、詳細な検討を効率的に実施することとしており、2002 年度は、「暗号調達ガイドブック作成ワーキン
ググループ（リーダ：佐々木良一東京電機大学教授）」を設置し、電子政府推奨暗号
を円滑に調達するための手引書を作成した。
検討会は総務省大臣官房技術総括審議官及び経済産業省商務情報政策局長の研究会として開催し、内閣官房、警察庁、防衛庁、法務省、外務省、財務省等がオブザーバとして参加した。

3

２．２．２．暗号技術評価委員会
暗号技術評価委員会（以下、「評価委員会」）は、暗号アルゴリズム等に関する技術的評価を行い、評価結果を検討会に報告した。また、検討会に対して暗号に関する技術的助言を行った。評価委員会の下には、共通鍵暗号評価小委員会（委員長：金子敏
信東京理科大学教授）及び公開鍵暗号評価小委員会（委員長：松本勉横浜国立大学教授）を設置した。
TAO 及び IPA の委員会として開催し、総務省、経済産業省、警察庁、防衛庁、外務省等がオブザーバとして参加した。

・暗号アルゴリズム等に関する技術的評価の依頼
・その他、技術的事項に関する助言を求める

暗号技術検討会

暗号技術評価委員会（座長：今井秀樹東京大学教授）（委員長：今井秀樹東京大学教授）

事務局：総務省／経済産業省

事務局：通信・放送機構／
情報処理振興事業協会

・総務省及び経済産業省に対して暗号利用に関する助言を行う。

・暗号アルゴリズム等に関する評価結果の報告

・電子政府における暗号利用に関する政策的判断を行う。

・その他、技術的事項に関する助言を行う

・具体的な技術的評価を行う。
・電子政府における暗号利用に資する
各種ガイドラインを作成する。
・技術的事項に関する助言を行う。

・具体的な暗号の評価依頼を行う。

暗号調達ガイドブック作成 WG

共通鍵暗号評価小委員会（リーダ：佐々木良一東京電機大学教授）（委員長：金子敏信東京理科大学教授）

公開鍵暗号評価小委員会（委員長：松本 勉 横浜国立大学教授）

図１ 2002 年度の CRYPTREC の体制図

4

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

今井 秀樹

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

顧問

辻井 重男

中央大学理工学部教授

岩下 直行

日本銀行金融研究所調査第２課企画役

岡崎 宏

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

岡本 栄司

筑波大学電子・情報工学系教授

岡本 龍明

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

小田 雅一
小柳津

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

育郎 ＮＴＴエレクトロニクス株式会社セキュリティシステム
事業部技術部長

加藤 義文

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

金子 敏信

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

国分 明男

財団法人ニューメディア開発協会常務理事開発本部長

櫻井 幸一

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

佐々木良一 東京電機大学工学部情報メディア学科教授

宝木 和夫

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

苗村 憲司

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

松井 充

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

松本 勉

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

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

手塚 新樹

警察庁情報通信局技術対策課長

中村 範明

防衛庁運用局指揮通信課長（第１回）

青木 信義

防衛庁長官官房情報通信課長（第２回〜）

高森 國臣

総務省行政管理局管理官

猿渡 知之

総務省自治行政局自治政策課情報政策企画官

中垣 治夫

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

石川 正紀

外務省大臣官房情報通信課長（第１回）

楠田 かおる 外務省大臣官房情報通信課長（第２回〜）
中山 峰孝

財務省大臣官房審議官室長（第１回）

5

宇野 雅夫

財務省日野参事官室企画官（第２回〜）

木戸 達雄

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

福地 一

独立行政法人通信総合研究所情報通信部門長（第１回）

蓮池 和夫

独立行政法人通信総合研究所情報通信部門長（第２回〜）

大蒔 和仁

独立行政法人産業技術総合研究所 情報処理研究部門長

鈴木 薫

通信・放送機構研究企画管理部長（第１回）

喜安 拓

通信・放送機構研究企画管理部長（第２回〜）

内藤 理

情報処理振興事業協会セキュリティセンター所長

米倉 昭利

財団法人日本品質保証機構電子署名・認証調査センター
所長

小倉 久宜

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

２．３．２． 暗号調達ガイドブック作成ＷＧメンバー※肩書は 2003 年 3 月末現在。敬称略。

リーダ

佐々木 良一東京電機大学工学部情報メディア学科教授

岩下 直行

日本銀行金融研究所研究第２課企画役

宇賀村

直紀 社団法人電子情報技術産業協会ＩＴセキュリティ
センター部長岡本 栄司

筑波大学電子・情報工学系教授

川村 信一

株式会社東芝研究開発センター

コンピュータ・ネットワークラボラトリー主任研究員
洲崎 誠一

株式会社日立製作所システム開発研究所第７部
Ｈ０１研究ユニット研究員

館林 誠

松下電器産業株式会社マルチメディア開発センター
メディア情報グループチームリーダー

中村逸一

株式会社ＮＴＴデータ
ティ事業部

米倉 昭利

ビジネス開発事業本部セキュリ

営業グループ 部長

財団法人日本品質保証機構電子署名・認証調査センター
所長

渡辺 創

独立行政法人産業技術総合研究所情報処理部門研究員

6

２．４．開催状況
2002 年度、検討会は計 6 回開催された。各回会合の開催日及び主な議題は以下のとおり。なお、暗号調達ガイドブック作成ＷＧの会合開催状況は第４章を参照のこと。
【第 1 回】平成 14 年 5 月 16 日（木）（主な議題）暗号技術検討会 2002 年度活動計画
電子政府推奨暗号の数
暗号技術評価委員会への依頼事項
暗号調達ガイドブック作成ワーキンググループの設置【第 2 回】平成 14 年 7 月 16 日（火）（主な議題）暗号調達のためのガイドブック案
電子政府推奨暗号の数
電子政府推奨暗号リスト素案の検討状況
暗号モジュール評価の現状把握【第 3 回】平成 14 年 9 月 30 日（月）（主な議題）電子政府推奨暗号リスト案
暗号調達のためのガイドブック案【第 4 回】平成 14 年 11 月 27 日（水）（主な議題）電子政府推奨暗号リスト案
同リスト案に対するパブリックコメント
暗号調達のためのガイドブック案
暗号プロトコルの現状把握（１）
今後の CRYPTREC 活動【第 5 回】平成 15 年 2 月 12 日（水）（主な議題）電子政府推奨暗号リストの決定
パブリックコメントに対する回答
暗号調達のためのガイドブック案
暗号プロトコルの現状把握（２）
今後の CRYPTREC 活動【第 6 回】平成 15 年 3 月 24 日（月）（主な議題）2002 年度報告書
暗号調達のためのガイドブック
今後の CRYPTREC 活動

7３．電子政府推奨暗号リスト
３．１．e-Japan 重点計画及びセキュリティ・アクションプランにおける電子政府の実現及び暗号技術評価の位置付け
2001 年 3 月 29 日に、高度情報通信ネットワーク社会推進戦略本部で決定された eJapan 重点計画では、行政の情報化及び公共分野における情報通信技術の活用の推進における施策の意義として「電子政府」の実現が掲げられており、また、高度情報通信
ネットワークの安全性及び信頼性の確保のための具体的施策の一つとして、「暗号技術の標準化の推進」が掲げられている。
e-Japan

2002

ISO ITU

8

e-Japan 重点計画の決定を受け、2003 年度からの電子政府の実現に向けて政府の情報
セキュリティ確保に万全を尽くすことを目的として、「電子政府の情報セキュリティ確保のためのアクションプラン」が内閣官房が中心となって取りまとめられ、2001 年 10
月 10 日に情報セキュリティ対策推進会議において決定された。その中では、具体的な方策の一つとして、2002 年度中に「電子政府」における調達のための推奨すべき暗号のリストを作成することが掲げられている。

ISO/IEC15408

2002

2002 年 6 月 18 日に策定された「e-Japan 重点計画-2002」においても、高度情報通信
ネットワーク社会形成のために政府が迅速かつ重点的に実施すべき施策の中に、「電子政府の実現」及び「暗号技術の標準化の推進」が掲げられている。

9

３．２．暗号技術評価について
３．２．１．暗号技術評価の目的
申請届出や調達など行政手続の電子化を実現する電子政府の機能をより安心して利用できるようにするためには、電子政府で利用可能な暗号技術1 を評価することが重要であり、2000 年度から暗号技術評価委員会を設置して、暗号技術の公募や委員会による評価対象暗号技術の選定及び評価を進めてきた。
本暗号技術評価活動は我が国における暗号技術評価体制の確立に向けた一歩であり、米国政府標準暗号を定める AES (Advanced Encryption Standard)プログラムを参考にしつつ、欧州における暗号評価プロジェクト（NESSIE：New European Schemes for
Signatures, Integrity, and Encryption)や ISO/IEC における国際標準化活動への協力も行っている。
３．２．２．評価概要
電子政府で利用可能と想定される暗号技術の評価は暗号アルゴリズム2の評価を中心として実施した。公開鍵暗号、共通鍵暗号、ハッシュ関数、擬似乱数生成系の４つの分類について、評価対象暗号技術の募集・選定を行い、各暗号技術の評価を行った。
暗号技術評価は、原則スクリーニング評価を実施した後、詳細評価を実施する二段
階評価のプロセスで評価を行った。なお、今年度評価を実施した暗号技術は、昨年度でスクリーニング評価を終了しているため、詳細評価のみを行った。
（１）暗号分類（イ）公開鍵暗号
守秘，署名，認証、鍵共有（ロ）共通鍵暗号
64 ビットブロック暗号，128 ビットブロック暗号，ストリーム暗号（ハ）ハッシュ関数（二）擬似乱数生成系（２）スクリーニング評価※今年度は実施せず
詳細評価を実施するに値するかどうかを判断するためのスクリーニング評価を下記の観点から実施した。
（イ）安全性に明らかな問題がないかどうかを評価する。
（ロ）第三者実装上問題がないかどうかを評価する。

1：暗号技術とは、暗号（暗号アルゴリズム、暗号方式）、暗号プロトコル、暗号モジュール、
暗号鍵管理等を含む概念とする。
2：暗号アルゴリズムは、単に暗号、または、暗号方式とも呼ばれる。

10

（３）詳細評価
スクリーニング評価で問題がないと判断された暗号について、電子政府で利用可
能かどうかの観点から評価する詳細評価を下記の観点から実施した。
（イ）既知の攻撃法に対する統一的な強度評価（ロ）各詳細評価対象暗号特有の攻撃法に対する強度評価（ハ）パラメータ／鍵の設定基準の評価（二）ソフトウェア実装評価（ホ）ハードウェア実装評価
３．２．３．各暗号技術の評価基準の概要
各暗号技術の評価基準の概要は、以下の通りである。詳細は、暗号技術評価報告書（2002 年度版）(CRYPTREC Report 2002)を参照のこと。
（１）公開鍵暗号
比較的長い期間にわたる使用実績・評価実績があり、インターオペラビリティの観点から仕様の変更を簡単には求められない公開鍵暗号方式3については、多くの研究者から十分な評価研究を受けているが、実運用における安全性に関する問題点が指摘されていないこと、すなわち経験的に安全であることを求めた。
使用実績が少ない新しい公開鍵暗号方式については、既存暗号技術とは独立に仕様を定めることができることから、最低限の条件として証明可能安全性が示されていることを必須とした。
これらに加えて、プリミティブが依存する数論的な問題の困難性や、推奨パラメータの選択方法や補助関数のスキームの中での利用方法を含めて総合的に安全性を評価した。
（２）共通鍵暗号
以下の条件のいずれかを満たすことを求めた。
（イ）現時点の最良の解読技術を適用しても、秘密鍵の総当たりである 2128 以上の計算量が必要と判断されるもの。特に、差分攻撃や線形攻撃などの代表的な攻撃法について、安全性が確認されているもの。
（ロ）世界的に広く使用され、かつ多くの研究者から十分な評価研究を受けているが、実運用における安全性上の大きな問題点が指摘されておらず、現時点で安全と判断されるもの。この場合、2100 以上の解読計算量を目安とした。

3：公開鍵暗号方式（または公開鍵暗号スキーム）は、プリミティブ（基本関数）とその他の要素技術（ハッシュ関数、擬似乱数生成系等）を組み合わせて構成される公開鍵暗号全体の仕組みを指す専門用語。

11

（３）ハッシュ関数
以下の条件のいずれかを満たすことを求めた。
（イ）特定の出力に対する入力値を発見する手間への耐性が十分に高く（最良の解読技術を適用しても 2160 以上の計算量）、かつ出力値が一致するような異なる入力値を発見する計算量が最良の解読技術を適用しても 280 以上であること。
（ロ）世界的に広く使用され、かつ実運用における安全性上の問題点が指摘されていないこと。なお、全ハッシュ値の長さが少なくとも 160 ビット以上である
こと。
（４）擬似乱数生成系
以下の条件をすべて満たすことを求めた。
（イ）統計的性質が真性乱数に近く、かつ、既知の出力ビット履歴から未来又は過去の未知出力ビットが予測困難であること。
（ロ）擬似乱数生成系を使用するシステムの総当たり攻撃に対し、十分に耐性をもつ程に、実質的入力空間が大きいこと。
（ハ）統計的性質は、例えば NIST が公表している SP800-22 等の代表的な擬似乱数
検定テストに合格するものであること。
３．２．４．暗号技術評価結果の概要
今年度の暗号技術評価結果の概要を以下に示す。なお、詳細は、暗号技術評価報告書（2002 年度版）(CRYPTREC Report 2002)を参照のこと。
（１）公開鍵暗号方式の総評4（イ）DSA（署名）

米国 NIST(National Institute of Standards and Technology)によって提案、標準化された電子署名方式であり、電子署名法に係る指針5 に記載されている。オブジェ
クト識別子は、1 2 840 10040 4 3 である。
安全性は有限体上の離散対数問題の困難性に依存している。証明可能安全性は示されていないが経験的に安全である。
安全性の観点からパラメータ p のサイズは 1024 ビットを選択することを強く推奨する。2001 年 10 月に NIST が FIPS PUB 186-2 (+ change notice 1)に提示した
擬似乱数生成系の修正に従うべきである。

4：公開鍵暗号方式が証明可能安全性を有するとは、その方式を攻撃することの非現実性を、暗号理論分野で標準的な安全性評価モデルの枠組に沿って示せることをいう。ただし、それが現時点で示されていないからといって、その方式の安全性が否定されるわけではない。
5：電子署名及び認証業務に関する法律に基づく特定認証業務の認定に係る指針（平成 13 年総
務省 法務省 経済産業省告示第 2 号）のことを指す。以下、同指針を｢電子署名法に係る指針｣と略記する。

12

（ロ）ECDSA （署名）CRYPTREC では ECDSA (ANSI X9.62)と ECDSA (SEC 16)とを評価した。
ECDSA(ANSI X9.62)は電子署名法に係る指針に記載されている署名方式であり、オブジェクト識別子は、1 2 840 10045 4 1 である。
安全性は楕円曲線上の離散対数問題の困難性に依存している。証明可能安全性は示されていないが経験的に安全であり、2002 年時点では安全性について重大な問題点は指摘されていない。
ECDSA(SEC 1)における楕円曲線パラメータは SEC 1 に示されている。これらの楕円曲線については特段の問題点は指摘されていない。安全性の観点から群位数が 160 ビット以上の素因子をもつようなパラメータを選択することを強く推奨する。擬似乱数生成器に関して NIST が FIPS PUB 186-2 (+ change notice 1)に提示した擬似乱数生成器の動向に注意すべきである。
（ハ）ESIGN （署名）ESIGN 署名の仕様は複数存在する。ESIGN（応募暗号）の評価の参考にするために TSH-ESIGN も評価した。
プリミティブの安全性は n = p2q 型素因数分解問題の困難性に依存している。
ESIGN の署名生成速度は RSA 署名と比べて高速であるが、RSA プリミティブと同程度の安全性を ESIGN のプリミティブにおいて得るためには RSA の法パラ
メータのサイズよりも少し大きな法パラメータを利用しなければならない。
（ａ）ESIGN は証明可能安全性を有しない。実際に、一部のパラメータの利用に際して、無視できない確率で署名の偽造が可能である。
（ｂ）TSH-ESIGN には新提案技術に必須とされた証明可能安全性が示されていない。
（ニ）RSA （署名、守秘）
RSA プリミティブを利用した署名方式にはいくつか の仕様が存在する。
CRYPTREC では RSASSA-PKCS1-v1_5 と RSA-PSS を評価した。RSASSA-PKCS1v1_5 と RSA-PSS は両方とも電子署名法に係る指針に記載されている署名方式であり、それぞれのオブジェクト識別子は、1 2 840 113549 1 1 5 および 1 2 840
113549 1 1 10 である。
また RSA プリミティブを利用した守秘方式にはいくつかの仕様が存在する。
CRYPTREC では RSAES-PKCS1-v1_5 と RSA-OAEP を評価した。
これら 4 つの RSA 方式は長期間広く使われてきた実績と、広範な観点から評6：Standards for Efficient Cryptography Group (SECG)から提供されている技術文書の 1 つ。

13

価が行われてきたことから経験的に安全である。
（ａ）RSASSA-PKCS1-v1_5 は電子署名法に係る指針に記載されている署名方式の 1 つである。証明可能安全性は示されていない。
（ｂ）RSA-PSS は新提案技術に必須とされた証明可能安全性を有する。
（ｃ）RSAES-PKCS1-v1_5 は SSL3.0/TLS1.0 で使用実績があることから当面の使用を認める。経験的安全性は有するが、証明可能安全性は持たず、実際に能動的攻撃が成立する可能性も無視できないので､実運用環境上における攻撃に対する対策を十分に施し細心の注意を払う必要がある。
（ｄ）RSA-OAEP は新提案技術に必須とされた証明可能安全性を有する。
RSA プリミティブの安全性は、n = pq 型素因数分解問題の困難性に依存している。安全性の観点から法パラメータ n = pq のサイズは 1024 ビット以上のものを利用することを強く推奨する。
（ホ）ECIES （守秘）ECIES は、2000 年度には ECAES として CRYPTREC に応募されていたが、2001 年度では暗号技術名を ECIES に変更して応募されている。ECIES にはいく
つかの仕様が存在する。CRYPTREC では SEC 1 に記載された仕様を基に評価した。
SEC 1 に記載された仕様の ECIES におけるスキームには KDF 関数への入力及び MAC の取り扱い方法の不備が原因で、脆弱性が存在し、新提案技術に必須とされた証明可能安全性を有しない。
（ヘ）HIME(R) （守秘）2000 年度応募された HIME-1 と HIME-2 の改良版として 2001 年度に応募された技術である。
プリミティブの安全性は n = p2q 型素因数分解問題の困難性に依存している。
RSA プリミティブと同程度の安全性を HIME(R)のプリミティブにおいて得るた
めには RSA の法パラメータのサイズよりも少し大きな法パラメータを利用しなければならない。
HIME(R)にはその仕様書に不備・曖昧さがあり、2002 年 9 月時点で信頼に足るHIME(R)の仕様書が公に手に入る状況になっていないと判断された。このため、HIME(R)の第三者による実装性や相互接続性が担保されないと判断された。
HIME(R)の仕様の曖昧さを埋めてその仕様を合理的に定めたとしても、自己評価
14

書に記載されている証明可能安全性の証明中いくつかの箇所に問題があり、不完
全であり、2002 年 9 月時点で新提案技術に必須とされた証明可能安全性を有すると断定できないと評価された。
（ト）ECDH （鍵共有）
ECDH は、2000 年度には ECDHS として CRYPTREC に応募されていたが、2001 年度では暗号技術名を ECDH に変更して応募されている。
安全性は楕円曲線上の離散対数問題の困難性に依存している。能動的攻撃に対しては証明可能安全性は示されていないが経験的に安全である。使用にあたっては運用上の注意が必要である。
ECDH(SEC 1)における楕円曲線パラメータは SEC 1 に示されている。これらの楕円曲線については特段の問題点は指摘されていない。安全性の観点から群位数が 160 ビット以上の素因子をもつようなパラメータを選択することを強く推奨する。
（チ）DH （鍵共有）
DH にはいくつかの仕様が存在する。CRYPTREC では ANSI X9.42-2001 を対象とした。
安全性は有限体上の離散対数問題の困難性に依存している。能動的攻撃に対しては証明可能安全性は示されていないが経験的に安全である。使用にあたっては
運用上の注意が必要である。
安全性の観点からパラメータ p のサイズは 1024 ビット以上を選択することを強く推奨する。
（リ）PSEC-KEM （鍵共有）2000 年度に応募された PSEC を ISO/IEC 18033-2 において審議されている KEM
技術に適合するように変更を加えたもので、2001 年度に応募された。
安全性は楕円曲線上の離散対数問題の困難性に依存している。KEM技術に関する 証 明 可 能 安 全 性 を 有 す る の で 、 PSEC-KEM を KEM(Key Encapsulation
Mechanism)-DEM(Data Encapsulation Mechanism)構成に利用することは安全であるといえる。しかし、それ以外の目的の利用について安全性の研究は十分ではないので、今後の研究に注意すべきである。
CRYPTRECとしてはSEC 1で規定される曲線の利用を推奨する。これらの楕円曲線については特段の問題点は指摘されていない。安全性の観点から群位数が160ビット以上の素因子をもつようなパラメータを選択することを強く推奨する。

15

（２）共通鍵暗号の総評（イ）CIPHERUNICORN-E（６４ビットブロック暗号）7
安全性について、今のところ問題は見つかっていない。処理速度は遅いグルー
プである。
（ロ）Hierocrypt-L1（６４ビットブロック暗号）7
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（ハ）MISTY1（６４ビットブロック暗号）7
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（ニ）Triple DES（６４ビットブロック暗号）7
安全性について、FIPS等で保証されている間は、問題ないと考える。
（ホ）Advanced Encryption Standard（１２８ビットブロック暗号）
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（ヘ）Camellia（１２８ビットブロック暗号）
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（ト）CIPHERUNICORN-A（１２８ビットブロック暗号）
安全性について、今のところ問題は見つかっていない。処理速度は遅いグルー
プである。
（チ）Hierocrypt-3（１２８ビットブロック暗号）
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（リ）RC6 Block Cipher（１２８ビットブロック暗号）

7：電子政府用システムとして、新システムを構築する場合は、より長いブロック長が使用可能な状況にあれば、128ビットブロック暗号を選択するのが望ましい。

16

安全性について、今のところ問題は見つかっていない。Pentium III上での暗号化が最速であるが、ソフトウェア処理速度はプラットフォームに大きく依存する。
なお、CRYPTREC事務局では、2002年10月16日付文書で、RSAセキュリティ株
式会社から、「知的財産権上の問題により、今後RC6の普及活動は行わない」との連絡を受領している。
（ヌ）SC2000（１２８ビットブロック暗号）
安全性について、今のところ問題は見つかっていない。処理速度は速いグルー
プである。
（ル）MUGI（ストリーム暗号）
安全性について、今のところ問題は見つかっていない。ソフトウェアによる処
理速度は速いグループである。
（ヲ）MULTI-S01（ストリーム暗号）
安全性について、今のところ問題は見つかっていない。ソフトウェアによる処
理速度は速いグループである。
（ワ）RC4（ストリーム暗号）
標準仕様（ワード長n=8、状態数256)のRC4については、現在のところ、現実的な解読法は提案されていない。しかし、秘密鍵から生成される初期状態によっては、必ずしも安全ではないという報告がなされている。したがって、RC4の利用に関してその初期状態の決定には注意が必要である。
SSL3.0/TLS1.0での利用に関しては、現在のところその安全性に関して欠陥は報告されていない。ただし、SSL3.0/TLS1.0の仕様上は40ビット秘密鍵（40-bitRC4）と128ビット秘密鍵（128-bit RC4）が利用可能であるが、CRYPTRECとしては、40ビット秘密鍵によって初期状態を生成する40-bit RC4は鍵の推定が可能であることから安全ではないと判断する。

（３）ハッシュ関数8（イ）RIPEMD-160

8：電子政府用システムとして、新システムを構築する場合は、より長いハッシュ値のものを採用することができるのであれば、ハッシュ値が256ビット以上となるハッシュ関数を選択することが望ましい。ただし、例えば、公開鍵暗号の仕様上利用すべきハッシュ関数が指定されている場合やインターオペラビリティの必要性が生じる場合はこの限りではない。

17

安全性について、いまのところ問題は見つかっていない。
（ロ）SHA-1
安全性について、いまのところ問題は見つかっていない。
（ハ）SHA-256
安全性について、いまのところ問題は見つかっていない。
（ニ）SHA-384
安全性について、いまのところ問題は見つかっていない。
（ホ）SHA-512
安全性について、いまのところ問題は見つかっていない。

（４）擬似乱数生成系（イ）PRNG in ANSI X9.42-2001 Annex C.1/C.2
パラメータが適切に設定された Annex C.1 については、今のところ、実用上の重 大な 問題 点は見 つか って い ない 。適切 なパ ラメ ー タの 設定 法 につ いては
CRYPTREC Report 2002 の該当節を参照のこと。なお、Annex C.2 については強い攻撃法を仮定した場合の弱点が指摘されているので推奨できない。
（ロ）PRNG in ANSI X9.62-1998 Annex A.4
パラメータによっては擬似乱数出力分布について、PRNG for DSA in FIPS PUB
186-2 Appendix 3 を利用した DSA に対する攻撃に使われたと同様の大きな偏りが生じるので推奨できない。
（ハ）PRNG in ANSI X9.63-2001 Annex A.4
パラメータによっては擬似乱数出力分布について、PRNG for DSA in FIPS PUB
186-2 Appendix 3 を利用した DSA に対する攻撃に使われたと同様の大きな偏りが生じるので推奨できない。
（ニ）PRNG for DSA in FIPS PUB 186-2 Appendix 3{0, 1}の分布の偏りを利用した 264 の計算量と 222 の既知署名を必要とする攻撃法が発表されている。
この攻撃法は DSA での擬似乱数の使用時に特定の一つの鍵の使用回数を 200
万回以下に抑えることで防御できるものの、擬似乱数としては乱数出力に大きな偏りが生じているので推奨できない。

18

（ホ）PRNG for general purpose in FIPS PUB 186-2 (+ change notice 1) Appendix 3.1
いまのところ、パラメータを適切に設定すれば、実用上の重大な問題点は見つかっていない。但し、仕様書中で定義されている使い方の中には安全とは言い切れない方法が含まれているので、利用の際には適切なパラメータの設定法については CRYPTREC Report 2002 の該当節を参照の上、適切な使い方を選択する必要がある。
（へ）PRNG in FIPS PUB 186-2 (+ change notice 1) revised Appendix 3.1
いまのところ、パラメータを適切に設定すれば、実用上の重大な問題点は見つかっていない。但し、仕様書中で定義されている使い方の中には安全とは言い切れない方法が含まれているので、利用の際には適切なパラメータの設定法については CRYPTREC Report 2002 の該当節を参照の上、適切な使い方を選択する必要がある。

なお、今回の評価結果は、現時点で想定される攻撃等に対する安全性等を評価したものであり、将来にわたって安全性が保証されるものではなく、自ずと限界があるものであり、本報告書に記載されている評価結果等の情報を利用した結果として生じる損害等に対して責任を持つことはできない。

３．３．電子政府推奨暗号リスト
暗号技術評価委員会から報告された暗号技術評価結果に基づき、第 4 回検討会会合（平成 14 年 11 月 27 日）において、電子政府推奨暗号リスト案を作成した。リスト
案の作成にあたっては、2001 年度に暗号技術検討会の下に設置した「要件調査ワー
キンググループ」における検討結果に基づき、暗号強度が十分高く、10 年間電子政府システムで安心して使えること、一般に使われる商用ソフトにあらかじめ入っているか、入る可能性の高いものが選ばれること、等を考慮した。
リスト案については、平成 14 年 11 月 28 日から平成 14 年 12 月 25 日まで、総務省及び経済産業省においてパブリックコメントを行った。その結果寄せられた意見等を
第 5 回検討会会合（平成 15 年 2 月 12 日）において検討した結果、平成 15 年 2 月 20
日に、両省から電子政府推奨暗号リストとして公表された。
（21 頁及び 22 頁にリストを掲載）
電子政府推奨暗号リストには、公開鍵暗号 9 方式（内訳：署名 4 方式、守秘 2 方式、鍵共有 3 方式）、共通鍵暗号 12 方式（内訳：64 ビットブロック暗号 4 方式、128 ビッ
19

トブロック暗号 5 方式、ストリーム暗号 3 方式）、ハッシュ関数 5 方式、擬似乱数生
成系（例示）3 方式の計 29 方式が掲載された。また、利用の際に注意を要する暗号については、個別に注釈が付記された。
電子政府推奨暗号リストの決定を踏まえ、「電子政府の情報セキュリティ確保のためのアクションプラン（第 2 章第 1 項参照）」に基づき、平成 15 年 2 月 28 日に、行政情報システム関係課長連絡会議において、各府省が情報システムの構築に当たり暗号を利用する場合には、可能な限り、電子政府推奨暗号リストに掲載された暗号の利用を推進する旨の「各府省の情報システム調達における暗号の利用方針」（参考資料参照）が了承された。
「各府省の情報システム調達における暗号の利用方針」では、今後、総務省及び経済産業省が、電子政府推奨暗号リストに掲載された暗号の安全性及び信頼性について
今後の情報通信技術の進展を踏まえ必要に応じて評価する、とされており、両省はCRYPTREC において電子政府推奨暗号の監視を行っていくこととしている。詳細は第 5 章参照。

20

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

公開鍵暗号

共通鍵暗号

その他

務
済

産

省
業

省

名称
DSA
ECDSA
署名
RSASSA-PKCS1-v1_5
RSA-PSSRSA-OAEP
守秘
RSAES-PKCS1-v1_5(注 1)
DH
鍵共有
ECDH
PSEC-KEM(注 2)
CIPHERUNICORN-E
64 ビットブロック暗号 Hierocrypt-L1(注 3)
MISTY1
3-key Triple DES(注 4)
AES
Camellia
128 ビットブロック暗CIPHERUNICORN-A
号
Hierocrypt-3
SC2000
MUGI
ストリーム暗号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
擬似乱数生成系(注 7)
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 として規定されていること
21

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

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

(注7)

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

22

３．４．電子政府推奨暗号の仕様に関する情報提供
電子政府推奨暗号リストにおいては、CRYPTREC で評価・選定した暗号の暗号名のみを掲載しているところであるが、その暗号名に対応する暗号の仕様を一意に保つ必要ある。また、電子政府推奨暗号の調達を円滑に行うためには、調達担当者が電子政府推奨暗号の仕様を容易に入手できることが必要である。しかし、各電子政府推奨
暗号の仕様の管理者は CRYPTREC ではなく、応募暗号の提案元又は NIST 等である
ため、以下のような方策により、調達担当者に仕様に関する情報を提供することとした。
（イ）電子政府推奨暗号の仕様を可能な限りTAO及びIPAのホームページに掲載する。
（ロ）電子政府推奨暗号のうちその仕様をTAO及びIPAのホームページに掲載することができないものについては、当該暗号の仕様を参照することのできるホームページのＵＲＬ、あるいは、その仕様を参照する方法をTAO及びIPAのホームページに掲載する。
（ハ）（ロ）の場合であって、当該暗号の仕様を参照することができなくなった場
合には、その旨を TAO 及び IPA のホームページに掲載する。

23

４．暗号調達のためのガイドブックについて
４．１．暗号調達ガイドブック作成 WG 設置の目的
電子政府推奨暗号リストの決定により、電子政府において安全性及び信頼性に優れた暗号アルゴリズムを採用することが可能になった。しかし実際に、各府省の調達担当者
が、利用目的に合った暗号アルゴリズムを電子政府推奨暗号リストから適切に選択する
ためには、調達するシステムにおける暗号の利用目的の抽出から、暗号アルゴリズムの選定までの手順を分かりやすく示す手引書が望まれるところである。
そこで、暗号技術検討会の下に、暗号研究者、セキュリティの専門家及びシステム開発の専門家から構成される「暗号調達ガイドブック作成 WG（以下「ガイドブックＷ
Ｇ」という。リーダ：佐々木良一東京電機大学教授）」を平成 14 年 5 月に設置し、暗号技術評価委員会及び公開鍵暗号／共通鍵暗号評価小委員会の協力を得つつ、各府省の調達担当者が適切な電子政府推奨暗号を円滑に調達するための「暗号調達のためのガイド
ブック（以下、ガイドブック）」を作成した。
４．２．ガイドブック作成の進め方
４．２．１．対象とする読者
ガイドブックの作成にあたっては、各府省における電子政府システムの調達の担当者が読者となることを想定するとともに、暗号やセキュリティに関する知識があまり豊富でない読者でも理解できるような記述レベルを目指すことにした。
４．２．２．盛り込む内容
上記のような読者を対象とすることから、ガイドブックには以下のような内容を盛り込むことにした。
（１）暗号の利用目的の抽出から暗号アルゴリズムの選定までの手順の解説（２）電子政府推奨暗号及び電子政府推奨暗号リストの解説（３）調達仕様書作成にあたり、暗号に関連して留意すべき点
４．２．３．ISO/IEC15408 を活用した調達との関連
セキュリティに関する信頼度の高い情報システムの構築については、既に「可能な限り ISO/IEC15408 に基づいて評価又は認証された製品等の利用を推進する」旨の省庁間合意が成されている。ただし、ISO/IEC15408 では、暗号技術の選択に関する要件については触れられていない。
そこで、セキュリティに関する諸要件と暗号に関する要件をそれぞれ指定して調達を進める場合は、本ガイドブックと「ISO/IEC15408 を活用した調達のガイドブック（経済産業省情報セキュリティ政策室発行）」を並行して参照することを意図した。

24

４．２．４．検討方法
上記の内容について、以下の手順及び方法により検討を行った。また、暗号アルゴ
リズムの解説をはじめ、技術的な内容の記述に関しては、暗号技術評価委員会及び公開鍵暗号／共通鍵暗号評価小委員会の協力を得た。
（１）調達担当者及び情報システム担当者へのヒアリング
検討に先立ち、システム調達（特に暗号調達）についての現状、及び、ガイドブックに対する要望を把握するため、各府省の調達担当者及び情報システム担当者
へのヒアリングを行った。また、ガイドブックの原案を作成した時点で再びヒアリングを行い、記述内容に関するコメントを求めた。
（２）海外の電子政府の事例に関する調査
海外の電子政府システムにおける、暗号調達ガイドラインの事例を調査した。
（３）作業委員会による編集
ガイドブックＷＧの下に作業委員会を設置し、上記ヒアリング及び事例調査等に基づいてガイドブック原案の作成作業を集中的に行った。同委員会は平成 14 年 6月から 8 月まで計 7 回開催した。
４．２．５．WG 会合の開催状況【第 1 回】

5 月 22 日（水）（主な議題）会合開催スケジュール、検討事項、目次案及び作業事項の確認【第 2 回】

7 月 8 日（月）（主な議題）ガイドブック骨子案の検討、海外電子政府事例の確認【第 3 回】

7 月 19 日（金）（主な議題）ガイドブック一次案の検討【第 4 回】 9 月 3 日（火）（主な議題）ガイドブック最終案の検討【第 5 回】 9 月 24 日（火）（主な議題）ガイドブック最終案の検討【第 6 回】 11 月 19 日（火）（主な議題）ガイドブック案の決定

25

４．３．ガイドブックの概要
４．３．１．システム全体の検討作業と暗号調達作業との関わり
暗号は、情報システムの構築作業の中でセキュリティ対策の一部として利用されるので、暗号を調達するにあたっては、その前段としてリスク分析を行うことにより、
どんな目的で暗号を利用すべきか、整理をしておく必要がある。（図１）
システム
設計

システム基本検討
リスク分析

システム
開発／試験

調達仕様書
の作成
暗号調達
仕様書の作成図１

システム構築作業の流れ及び暗号調達の位置付け

このリスク分析に基づき、システムに必要となる暗号アルゴリズムを選定していくことになるが、その手順は図 2 に示すようなものになる。ガイドブックでは、この手順に沿って、暗号調達、及び、この手順を進める上で必要となる技術的概念である暗号利用形態及び暗号技術分類に関する解説、電子政府推奨暗号に選定された各暗号ア
ルゴリズムの概要について記述した。

具体的

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

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

暗
号
具
体
性

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

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

暗号に
関する
要件

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

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

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

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

曖昧

調達者が行うべき作業

図２ 暗号アルゴリズムを選定するまでのステップ（図中の数字はガイドブック本文の節番号に対応）

26

４．３．２．電子政府システムにおける暗号利用イメージ
e-Japan 重点計画-2002 に挙げられている電子政府の主な項目のうち、「電子申請」「電子調達」、「電子納付」、「電子情報提供」、の各システム及び「政府認証基盤」における暗号利用イメージ図及び説明を記載した。
４．３．３．暗号利用形態及び暗号技術分類
電子政府システムにおける暗号の利用目的を分類したものである「暗号利用形態」と、暗号アルゴリズムを機能的、技術的に整理したものである「暗号技術分類」についての解説を記載した。
４．３．４．電子政府推奨暗号の概要
電子政府推奨暗号に選定された暗号アルゴリズム 29 方式の概要説明、及び、利用にあたっての注意点等を記載した。
４．３．５．暗号調達の手順に関する説明
暗号アルゴリズムを選定するための作業について、調達担当者及び情報システム担
当者へのヒアリング等を基に、2 通りのモデル化を行い、それぞれについて解説した。
（１）暗号調達の流れ
電子政府システムの調達の流れ（図 3 及び図 4）の中で、調達者はシステムに必要な暗号の要件を明確化し、電子政府推奨暗号リストの中から暗号アルゴリズムを絞り込む必要がある。暗号アルゴリズムを絞り込む作業の進め方は、以下に挙げる
2 つのモデルが考えられる。
（イ）調達者指定モデル
調達仕様書の作成時に、調達するシステムについて詳細に説明し、その中で、
電子政府推奨暗号リストから暗号アルゴリズムを指定する方法（ロ）提案審査モデル
調達仕様書では、暗号については概略を説明するに止め、業者に電子政府推奨
暗号リストから暗号アルゴリズムを選択させ、提案資料を見て審査する方法
上記 2 モデルのうち、調達者指定モデルは仕様書作成段階で暗号への要件を詳細化することが必要となり、提案審査モデルでは提案書受領後の審査段階で同様の作業が必要となる。よって、暗号調達に関して必要となる、調達者の作業は、システ
ム調達全体を通して同等になると考えられる。

27

調達対象
システム
の基本検
討

調達仕様
の検討、
仕様書の
作成

調達先の
決定

公示・
公募等の
事務作業

納品受領
〜検収

提案審査モデルでは、業者により提案された暗号アル
ゴリズム等の情報を審査して調達先を決定する

調達者指定モデルでは、調達仕様書に暗号アルゴリズ
ム等詳細な指定をして調達
を進める

図３

契約書の
作成、
契約締結

システム調達の流れ及び両モデルの位置付け

調達の流れ

作 業 概 要調達対象システムの基本検討

システムの背景、目的、対象範囲、構築条件、概算費
用等、調達を進める基本的事項の整理、その他、暗号に関連した作業として、リスク分析等が行なわれるシステムへの要件となる事項の具体化検討と仕様書の作成（必要に応じて、パブリックコメントを募集する場合がある）
公示・公募、提案の受付などの事務作業
調達システムに適合する提案をした業者を選定

調達仕様の検討、仕様書の作成

公示・公募等の事務作業
調達先の決定契約書作成、契約締結

調達システムの特記事項等を盛り込んで、契約書を作成、契約を締結
調達したシステムを受領、仕様と相違ないことを確認
検収

納品受領〜検収図４

システム調達の流れにおける作業の概要（２）調達者指定モデルによる調達仕様書の作成
調達者指定モデルにおける暗号調達の流れを図５に示す。調達者は、リスク分析の結果等、調達対象システムの基本検討の結果を把握した上で、暗号利用形態の選定、暗号利用分類の選定、暗号アルゴリズムの選定、の順で作業を進め、暗号調達
仕様書を完成する。

暗号利用形態の選定

図５

暗 号技 術分類の選定

暗号アルゴリズムの選定

調達仕様書への記載

調達者指定モデルにおける暗号アルゴリズム選定までの流れ（イ）暗号利用形態の選定
ガイドブックでは、システムの基本検討におけるリスク分析等の様々な作業の一貫として暗号利用形態の選定が行われることを想定し、一般的なセキュリティ
28

上の脅威に対して、暗号利用形態を選定する場合の基本的な考え方を示した。
（ロ）暗号技術分類の選定
暗号利用形態の決定後、調達するシステムの目的や特性を考慮して暗号技術分類を選択する。ガイドブックでは、暗号利用形態別に、共通鍵暗号と公開鍵暗号のそれぞれがよく用いられる事例等について説明した。
（ハ）暗号アルゴリズムの選定
暗号技術分類の決定後、電子政府推奨暗号リストの中から、暗号技術分類別に１つ又は必要な数の暗号アルゴリズムを選択する。ガイドブックには参考資料として、アルゴリズム安全性評価結果（リストに載せた根拠）、主なパラメータ・
補助関数に関する要件、国際標準への対応等について一覧表にまとめた「評価・特徴一覧」を掲載した。なお、主な留意点又は着目すべき点は以下のとおり。
（ａ）実装方法によっては、電子政府推奨暗号を使用したとしても様々な実装攻撃に曝される危険性を排除できないので、実装攻撃の脅威に対する十分な配慮、検討を行い、適切な対策を施して実装するよう注意する必要がある。
（ｂ）公開鍵暗号は、暗号利用形態に応じて、プロトコル標準への採用の有無等を考慮して選択する。なお、許容される処理速度の範囲で、使用される鍵長（RSA 暗号の場合、2 つの素数の積となる合成数のビット数）を長くする（RSA 暗号の場合は 1024 ビット以上にする）などの検討が必要である。また、各アルゴリズムの数論的困難性を確保するため、パラメータの選択に十分留意する必要がある。
（ｃ） 共通鍵暗号は、処理速度、メモリ制限環境での実装性、プロトコル標準への採用の有無等を考慮して選択する。ブロック暗号を選択する場合、安全性の面から今後は可能な限りブロック長 128 ビットの暗号を使用する。なお、
ブロック暗号を利用した暗号化処理に関連して、暗号利用モード（Modes ofOperation）と呼ばれる技法がいくつか規定されており、各モードごとに実現している目的や機能が異なるので、実装環境や利用用途に応じて、適切な暗号利用モードを選択する必要がある。
（ｄ）ハッシュ関数は、可能であれば 256 ビット以上の長さのハッシュ値を出力するものを選択することが望ましい。ただし、既に選択した公開鍵暗号又は共通鍵暗号の仕様書でハッシュ関数が指定されている場合は、その中から選
択する。

29

（ｅ）擬似乱数生成については、リストに掲載されている以外の「暗号学的に安全な擬似乱数アルゴリズム」を利用することができる。また、リストに掲載されている暗号アルゴリズムの仕様自体に特定の擬似乱数生成アルゴリズムの使用が規定されている場合は、その使用を妨げるものではない。

（ニ）調達仕様書への記載
上記のような手順により選択した暗号アルゴリズムを、どのように調達仕様書に記載するかを例示した。
（図 6）
暗号による保護を必要とする情報
・ 申請データ・ 申請内容確認で授受されるデータ
到達確認通知・ 状況確認で授受されるデータ
・ 審査終了通知・ 許認可等公文書の取得要求データ
・ 許認可等公文書
・鍵情報
上記暗号アルゴリズムにて
特に指定の無い場合は右記アルゴリズムを使用すること
図6

暗号利用形態
守秘相手認証

暗号アルゴリズム

または
署名
または
鍵共有
ハッシュ関数として擬似乱数生成として電子申請システムにおける暗号アルゴリズム指定表の記載例 9（３）提案審査モデルによる調達仕様書の作成
提案審査モデルの場合、調達者は調達仕様書に下記項目を記載する。
（イ）電子政府推奨暗号の使用に関する指示
調達するシステムには、可能な限り電子政府推奨暗号を使用するよう、提案を行う業者に指示する。
（ロ）暗号アルゴリズム選定理由の明記に関する指示
提案書の審査において、調達者は、暗号アルゴリズムの選定が妥当であることを検証する必要があるため、調達するシステムのイメージから暗号アルゴリズム
選定までの過程を、理由を付けて分かりやすく説明した文書を提案書に添付する
よう、調達を行う業者に指示する。

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

30

４．３．６．調達仕様書作成上の留意点
調達者が調達仕様書を作成する際に留意すべき点を記載した。
（１）複数暗号アルゴリズムの実装について
電子政府システムにおけるサーバや、パソコン等に複数の暗号アルゴリズムを同時に実装する場合、セキュリティ面だけ考えると以下のようにいえる。
（イ）複数暗号実装のメリット
電子政府推奨暗号リストに掲載される暗号アルゴリズムにおいては暗号解読問
題発生の可能性が低いとはいえ、1 つの暗号アルゴリズムが解読された場合に備えて、複数の暗号を実装し切り替えられるようにすることは、セキュリティを向上する上で有効である。
（ロ）複数暗号実装のデメリット
複数の暗号アルゴリズムを同じシステムに実装し、これを切り替えて利用できるように作り込んだ場合、切り替え部分等にセキュリティホールが混入してしまう恐れがある。そのため脆弱性が上昇し、セキュリティが減少する可能性がある。
（ハ）対応策したがって、セキュリティ脆弱性の上昇により懸念されるリスクが、暗号アル
ゴリズムが解読されるリスクに比べて小さいと判断された場合にのみ、複数暗号
アルゴリズムを実装すべきである。
なお、インターネットなどを通じて広く一般国民が利用するシステムにおいて、利用者の利用する暗号アルゴリズムが全体として 1 つに特定できない場合などには、政府側のサーバ装置で、複数の暗号アルゴリズムをどちらでも扱えるようにしておかなければならない場合がある。このような場合には、セキュリティホールを作りこまないよう十分な配慮をしつつ複数暗号を実装しておくことが利用者の利便性を向上させる上でも望ましい。
（２）暗号プログラムの配布と外国為替及び外国貿易法による暗号輸出規制
不特定多数の利用者に、暗号機能を含むプログラムを配布することは、ワッセ
ナーアレンジメントに基づき、外国為替及び外国貿易法による規制がある。
ガイドブックでは、電子政府システムにおいて不特定多数の利用者に暗号機能を含むプログラムを配布する場合の、法制度上の留意点について解説した。
４．３．７．調達先の決定、契約及び納品
調達仕様書に基づき提出される提案書の審査、調達者の決定、契約、納品における、

31

暗号調達の観点からの留意点を記載した。
４．３．８．参考資料（１）各府省の情報システム調達における暗号の利用方針
電子政府推奨暗号の利用に関する府省間合意文書を掲載した。
（２）電子政府推奨暗号の評価・特徴一覧
電子政府推奨暗号の、アルゴリズム安全性（リストに載せた根拠）、主なパラ
メータ・補助関数に関する要件、国際標準等への採用状況等に関する情報を、一覧表にして掲載した。

32

５．今後の CRYPTREC 活動について
CRYPTREC では、発足以来の当面の目標であった、電子政府推奨暗号リストの策定及び暗号調達のためのガイドブックの作成を行った。しかし、国民が安心して電子政府を利用できるようにするためには、電子政府の安全性及び信頼性を確保するための活動を引き続き推進していく必要があり、CRYPTREC としても、それに貢献していくことが重要であるとの認識に立っている。そこで、2003 年度以降、以下のような活動を行っていくこととした。

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

ステム関係課長連絡会議との連携を図ることとする。
（４）暗号モジュール評価基準の作成
暗号モジュール評価基準及び試験基準を作成する。

５．２．今後の CRYPTREC 体制
2003 年度以降、当面の CRYPTREC の体制として、暗号技術検討会は存続し、暗号技術検討会の下に「暗号技術監視委員会」及び「暗号モジュール委員会」を設置する。また、暗号技術監視委員会の下に「暗号技術調査 WG」を設置する（図 7：今後のCRYPTREC の体制図）。
従来の暗号技術評価委員会は暗号技術監視委員会に発展的に再編することとする。また、公開鍵暗号評価小委員会及び共通鍵暗号評価小委員会は暗号技術調査ＷＧに再編す
ることとする。
各委員会及びＷＧの位置づけ、構成及び機能は以下のとおり。

今後のCRYPTREC体制図（事務局：総務省、経済省）（事務局：ＴＡＯ、ＩＰＡ）(１) 電子政府推奨暗号の監視(２) 暗号アルゴリズム等を主な対象とする
調査・検討(３) 電子政府推奨暗号リストの改訂に関する調査・検討(１) 暗号モジュール評価基準及び試験基準の作成(２) 暗号実装関連技術を主な対象とす
る調査・検討（図 7）
５．２．１．暗号技術検討会
暗号技術検討会（「検討会」）は、電子政府推奨暗号リストに掲載された暗号技術の34

監視、関連する調査研究、及び、暗号技術の危殆化や暗号プロトコル等その他暗号技術の評価・利用等に関する事項について、総合的な観点から検討を行う。また、電子政府等のセキュリティの確保のため、政府のセキュリティ関係機関等との連携、調整を図る。
５．２．２．暗号技術監視委員会
暗号技術監視委員会（以下、「監視委員会」）は検討会の下に設置される。監視委員
会は、数名の有識者等により構成され、安全性及び信頼性確保の観点から、電子政府
推奨暗号の監視、電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする調査・検討を適宜行うとともに電子政府推奨暗号リストの改訂に関する調査・検討を行う。なお、監視委員会の日常業務を行う監視要員をTAO／通信総合研究所（CRL）（両機関は2004年4月に統合予定）及びIPAに配置する。
（１）暗号技術調査WG（イ） 暗号技術調査WG（以下、「調査WG」）は、電子政府推奨暗号リストの変更
案等の作成、及び電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする具体的な調査・検討に際して監視委員会を支援することを目的として、監視委員会の下に設置される。
（ロ） 調査WGは、監視委員会委員、従来の暗号技術評価委員会委員、共通鍵暗号評価小委員会委員及び公開鍵暗号評価小委員会委員等を元に構成される。これらのWGメンバーは、共通鍵暗号評価グループ及び公開鍵暗号評価グルー
プに区分される。監視委員会は、事案の性質に応じて、共通鍵暗号評価グ
ループ及び／または公開鍵暗号評価グループを召集し、調査WGを開催する。
調査WGは、監視委員会に対して電子政府推奨暗号リストの変更案等の作成に関する専門的助言を行う。
（ハ）その他、調査WGは、監視委員会の要望により事案に応じて開催され、電子政府推奨暗号に関する暗号アルゴリズムを主な対象とする具体的な調査・検討（電子政府における暗号利用状況調査等）を行い、監視委員会に対して専門的な助言を行う。
５．２．３．暗号モジュール委員会
暗号モジュール委員会は検討会の下に設置される。暗号モジュール委員会は、
ISO/IEC等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用され得ることをも視野に入れながら、2005年3月を目処に暗号モジュール評価基準及び試
験基準を作成する。また、電子政府推奨暗号の安全性及び信頼性確保のための、主として暗号実装関連技術等を対象とする調査・検討を行う。

35

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

36

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

10：応募暗号：電子政府推奨暗号のうち、以下のものを指す。

（公開鍵暗号）ECDSA, RSA-PSS, RSA-OAEP, ECDH, PSEC-KEM（共通鍵暗号）CIPHERUNICORN-E, Hierocrypt-L1, MISTY1,
Camellia, CIPHERUNICORN-A, Hierocrypt-3, SC2000,
MUGI, MULTI-S01
37

（ニ）電子政府調達者より、電子政府推奨暗号リストに無い新たな用途及び当該用途に適した暗号の追加に関する要望がよせられた場合であって、かつ、暗号技術検討会としても当該用途の追加が適切と判断した上で、それに適した暗号の評価を実施し、その結果、適切な暗号を選定した場合には、当該用途及び当該暗号を電子政府推奨暗号リストへ追加することとする。

５．３．３．電子政府推奨暗号の監視の手順
電子政府推奨暗号の監視の手順は、（１）監視委員会における情報収集、（２）監視委員会における情報分析、（３）監視委員会及び検討会における審議及び決定の３段階からなる。具体的には以下のとおりとする。
（１）監視委員会における情報収集監視委員会において、電子政府推奨暗号の安全性に関する情報を迅速かつ円滑に入手するためには、監視委員会自らが情報収集を行うだけでなく、過去3年間のCRYPTREC活動によって形成された、暗号研究者とのネットワークを活用することが重要である。そこで、以下のように情報収集を行うこととする。
（イ）国内外の学会等への参加等を通じて暗号技術に関する情報（学術論文、発表原稿等）を収集する。
（ロ）暗号技術調査WGメンバー等との連絡体制を整備し、同メンバーから恒常的に情報提供を受ける。
（ハ）応募暗号については、原則として応募元から情報提供を受ける。
（ニ）その他一般からの情報提供も受ける。
（２）監視委員会における情報分析
監視委員会は、（１）により収集された情報を分析し、電子政府推奨暗号の削除等を検討すべき事態が発生しているか否か判断する。その結果、監視委員会が電子
政府推奨暗号の削除等を検討すべき事態が発生していると判断する場合には、事案に応じて、暗号技術調査ＷＧの共通鍵暗号評価グループおよび／または公開鍵暗号評価グループを召集し、暗号技術調査ＷＧを開催する。ただし、監視委員会が、電子政府推奨暗号の削除等を直ちに行うべき事態が発生していると判断する場合は、
その緊急性に応じた対応を実施する。
（３）監視委員会及び検討会における審議及び決定（イ） 暗号技術調査WGは、技術的観点から、監視委員会に対して助言を行う。なお、暗号技術調査WGは、応募元等より修正情報の提供を受け、同修正情報

38

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

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

総務省及び経済省

暗号技術検討会⑥電子政府推奨暗号の削除⑦暗号技術検討会の決定を踏まえ等に関する案を作成し、必て電子政府推奨暗号リストの変更
要に応じてパブリックコメ
について行政情報システム関係課⑤監視委員会が必要と判断する ントに付した後、最終的に長連絡会議に連絡
場合には、素案について暗号技 案を決定。
術検討会に報告するとともに、その緊急性に応じた対応を行う。

①リストへの削除等の必要があると判断する場合に暗号技術調査ＷＧを開催

暗号技術
調査ＷＧ
②対象となる暗号について
技術的な観点から評価を実施③評価結果を踏まえて監視委員会に助言を行う⑤電子政府推奨暗号の削除等に関する素案を
暗号技術検討会に報告

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

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

39

５．４．電子政府推奨暗号リストの改訂
５．４．１．基本的認識
電子政府推奨暗号は、現時点において、今後 10 年間は安心して利用できるという観点から選定された暗号である。しかし、暗号に対する解析や攻撃の技術や手法はますます高度化しており、電子政府推奨暗号は常に危殆化の危険にさらされている。一方、新たな暗号の開発も進んでおり、今後、安全性や実装性に優れた新しい暗号の出現が期待されるところである。そこで、危殆化した暗号の削除や新しい暗号の選定等により、電子政府推奨暗号リストを一定期間毎に改訂することが望ましい。改訂を実施する際に、仮に公募を実施する場合は、公募のアナウンス（公募開始時期、公募期
間、評価期間、新リスト発表時期等の公表）から新リストの策定まで、5 年程度の期間をかけることが望ましい。

５．４．２．基本的考え方
リストの改訂作業の具体的な実施内容については、電子政府の導入状況及び電子政
府推奨暗号の監視状況を考慮しつつ、然るべきタイミングで検討を行うこととする。
なお、リスト改訂作業の実施方法としては、現在のところ、以下のような検討事項が想定されるところである。
（想定される検討事項）（イ）公募の要否（ロ）リスト項目（技術分類等）の見直し（ハ）項目別の掲載暗号数（ニ）評価基準、評価方法
また、改訂作業の具体的な開始時期については、2003年度以降に暗号技術検討会において検討の上決定するが、改訂作業の完了及び新リストの決定は、遅くとも10年後の2013年までとする。なお、仮に公募を実施するとした場合は、5年程度の期間をかけることが望ましいと考えられることから、遅くとも2008年3月頃には公募のアナウンスを行うことが望ましい。

５．５．暗号モジュールに関する検討
電子政府の安全性及び信頼性を確保するためには、暗号技術レベルの安全性だけでなく暗号技術の実装の安全性を確保する必要があり、この観点から暗号モジュールの安全性評価基準を作成することが急務である。他方、暗号モジュールの安全性評価基準に関しては、米国が自国の政府調達基準であるFIPS140-2のISO/IEC化を提案しており、暗号モジュールの安全性評価基準を我が国において作成するにあたっては、ISO/IEC等にお40

ける議論を注視していく必要がある。
このような状況を踏まえて、検討会の下に暗号モジュール委員会を設置する。暗号モ
ジュール委員会は、ISO等の国際標準の動向を注視しつつ、将来的に政府調達基準等として利用され得ることをも視野に入れながら、2005年3月を目処に暗号モジュール評価
基準及び試験基準を作成する。
なお、暗号モジュール委員会は、暗号技術監視委員会と連絡をとりつつ、電子政府推奨暗号の安全性及び信頼性確保のための暗号実装関連技術を主な対象とする調査・検討
を併せて行うこととする。

41

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

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

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

１．

背景.......................................................................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) 「暗号学的に安全な乱数」とは、過去の履歴から次の値が予測できないような数字列を意味する。

− 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/s-news/2003/pdf/030331̲4̲1.pdf 又は
http://www.meti.go.jp/policy/netsecurity/index.html）
・暗号技術評価報告書

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. 644654, 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- RSAPKCS1- PSS
v1̲5
署名
署名

ECDSA

署名

署名

○

−

○

TLS1.0(ProposedStandard)

Internet-DraftTLS1.0(ProposedStandard)

RSAOAEPDHECDHPSECKEM

鍵共有

鍵共有

鍵共有

守秘

RSAESPKCS1v1̲5 *1)
守秘

−

−

○

○

−

−

−

−

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 点から「」を選定する。なお、の利用用途は＜略＞であるから、利用モードは
は「（モード名称）」とした。

※

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

− 41 −

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

− 42 −

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

またはデジタル署名のための暗号機能はこの規制の対象外である。

詳しくは、「外国為替及び外国貿易法」（第 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）まで。

：ここで言う「認証」にはユーザ認証とデータ認証の 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/s-news/2003/pdf/030331̲4̲1.pdf− http://www.meti.go.jp/policy/netsecurity/index.html
暗号技術評価報告書

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

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

-

-

-

安全性の到達度

ハッシュ関数

利用
実績

策定

・ANSI

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

・P1363a(Draft)

-

-

-

-

○

-

-

○

・P1363a(Draft)-○

・Standards for Efficient
Cryptography Group (SECG)-○

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

・RFC2246(Proposed Standard)
・RFC3278(Informational)
・RFC3275(Draft Standard)
・RFC3447(Informational)
・RFC3279(Proposed Standard)
・RFC3279(Proposed Standard) ・pkix(Internet-Draft)・ipsec(Internet-Draft)
・RFC3370(Proposed Standard) ・smime(Internet-Draft)・tls(Internet-Draft)
・RFC3447(Informational)○
・FIPS PUB 186-2(+Change
Notice1)○

素因数分解問題

適応的選択暗号文攻撃に対して強秘匿RSA問題の困難性

ランダムオラクルモデル○○

素因数分解問題

-

-

-

-

○

有限体上の離散対数問題

-

-

-

-

○

-

-

-

-

-

-

-

-

・11770-3

・X9.42-2001
・P1363-2000

-

-

-

・RSA Laboratories

・RSA Laboratories

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

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

−

（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を参照の
上、特許所有者と交渉するこ
と。

−

−

−

−

−

−

−

-

-

-

・日本電信電話株式会社

-

-

-

-

○ (Public-key Encryptionとして)・18033-2(Committee Draft)

-

（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を参照の
上、特許所有者と交渉すること。

富士通株式会社
日本電信電話株式会社
・SECG member patent letters ・特開2000-148011(http://www.secg.org/collateral 「ランダム関数利用公開鍵暗号/certicom̲secg̲patent.pdf)を参 の暗号装置」
照のこと。
・特開2001-222218
・富士通株式会社の所有する特 「暗号化装置、方法、複合装置、
許は、特になし。
方法、暗号システム及びプログラ
ムを記憶した記憶媒体」

・Standards for Efficient
Cryptography Group (SECG)-○

・RFC3278(Informational)
・RFC3279(Proposed Standard)
・ipsec(Internet-Draft)・tls(Internet-Draft)

・X9.63-2001
・P1363-2000
・11770-3・15946-3-

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

鍵カプセル化メカニズムとして適応的選択暗号文攻撃に対して強秘匿

楕円曲線上のDH計算問題

ランダムオラクルモデル○-

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

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

−

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

-

-

-

-

○

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

鍵共有

・電子政府推奨暗号リストに記載されたものを使用すること

・RFC2246(Proposed Standard)
・RFC2246(Proposed Standard) ・RFC2409(Proposed Standard)
・RFC3370(Proposed Standard) ・RFC2631(Proposed Standard)
・RFC3447(Informational)
・RFC3370(Proposed Standard)
・RFC3279(Proposed Standard)

・X9.44(Draft)

-

○
○
○
○
・XML Encryption Syntax and・XML Encryption Syntax and・XML Encryption Syntax andProcessing(10 December 2002) Processing(10 December 2002) Processing(10 December 2002)

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

・P1363-2000--

・電子政府推奨暗号リストの注釈7を参照のこと−
富士通株式会社
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
は、Contact Address欄に[no/certicom̲secg̲patent.pdf)を参 的財産権を持たない。ただし、 的財産権を持たない。ただし、 的財産権を持たない。ただし、 的財産権を持たない。ただし、 1980(1997年に失効している)(a) 該当する license required]と記載されてい 照のこと。
上記アルゴリズムを具現化した 上記アルゴリズムを具現化した 上記アルゴリズムを具現化した 上記アルゴリズムを具現化した知的財産権 る・富士通株式会社の所有する特 ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリー ソフトウェア（RSA BSAFEシリーズ）についての著作権は、同社 ズ）についての著作権は、同社 ズ）についての著作権は、同社 ズ）についての著作権は、同社
・U.S. Patent 5,231,668, July
許は、特になし。
1993に帰属する。
に帰属する。
に帰属する。
に帰属する。

問い合わせ先W3C(注10)(注7)

SET
SSL3.0(注8)
WAP/WTLS(注9)・RFC2246(Proposed Standard)
・RFC3275(Draft Standard)
・RFC3279(Proposed Standard)
・RFC3370(Proposed Standard)

・FIPS PUB 186-2(+Change
Notice1)

・X9.62-1998
・P1363-2000
・14888-3・15946-2

素因数分解問題

適応的選択文書攻撃に対して存在的偽造不可RSA問題の困難性

ランダムオラクルモデル○○

・｢参照すべき仕様書｣に記載の各暗号技術の仕様書で指定されたパラメータのうち、CRYPTREC Report 2002で指定された条件を満たすものを使用すること

素因数分解問題

-

-

-

-

○

・電子政府推奨暗号リストに記載されたものを使用すること

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

守秘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/)

署名ⅳ

注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: 括弧内の数字の意味については、別添２｢評価・特徴一覧の利用にあたって｣の｢○公開鍵暗号／共通鍵暗号 共通」「知的財産権情報について｣を参照のこと。

特記事項

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

IETF(注6)NISTNESSIE (注4)

ISO/IEC (注3) ・14888-3

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

提案元

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

主なパラメータ・
補助関数に関する要件

パラメータの範囲

有限体上の離散対数問題--

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

プリミティブの安全性の根拠リストに載せた根
拠

-

-

○

○

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

経験的安全性ANSI X9.30:1-1997(http://www.x9.org/)

証明可能安全性の有無参照すべき仕様書

利用形態

評価・特徴一覧（公開鍵暗号）

参考２

鍵即応性**

ハードウェア実装（低機能型 IC カード評価***）メモリ制限環境での実装性能

装

実

ア

ェ

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

化性能の約 85%程度[B+]

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

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

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

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

使用 RAM サイズは少ない[C]
処理速度は Triple DES よりも高速である[B+]

使用 RAM サイズは少ない[C]
処理速度は Triple DES よりも高速であるが、復号性能は暗号使用 ROM サイズは少ない[C]良好である[C] 総合的な処理性能および実装性はおおむね

鍵生成時間は暗号化処理と同程度の時間が必要である[C] 鍵交換ペナルティは中程度

鍵生成込暗号化処理は遅いといわれる[C]

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

処理速度が遅いといわれる[C] 実用的には問題ないことも多いが、一般には

鍵生成込暗号化処理は遅いといわれる[C]

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

処理速度が遅いといわれる（基準性能）

使用 RAM サイズは中程度[C-]れているはならないと推定

よりも優れている[B+] 総合的な処理性能および実装性は Triple DESる[C] 実用的には問題ないことも多いが、一般には使用 ROM サイズはやや大きい[D]的な処理性能および実装性は Triple DES よりもやや優が、少なくとも Triple DES の処理性能と同程度以上に鍵生成時間は Triple DES の 1/7 程度である[B] 鍵交換ペナルティは少ない[A]

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

UltraSPARC IIi での評価なし[B+] 総合的な処理性能は Triple DES よりも高い

3-key Triple DES[B] FIPS 等で保証されている間は問題ないと考え

使用 ROM サイズは中程度[C-][B] やや使用 ROM サイズが大きいことを除けば、総合となるため、全体として性能が低下する

または復号のどちらかにより重い処理を実行させることが必要

復号の場合には、暗号化の場合と比較して、少なくとも鍵生成

2/5 程度である

鍵生成時間は、暗号化では Triple DES の 1/5 程度、復号では[B]鍵交換ペナルティは少ない

鍵生成込暗号化処理は暗号化よりも復号の方がより重い[A/B+]

Alpha 21264 での暗号化処理速度[A]、鍵生成込暗号化処理[D 以下] 評価未実施であり、最終的な結論ではない

鍵生成時間は Triple DES と同程度である[C] 鍵交換ペナルティは中程度

理[C/C-]

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

UltraSPARC IIi での暗号化処理速度[B]、鍵生成込暗号化処[B+] 総合的な処理性能は Triple DES よりも高い

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

暗号化処理速度[B+]： Triple DES の 4 倍超の性能[B+] 総合的な処理性能は Triple DES よりも高い[A] 今のところ問題は見つかっていない

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

** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号

性

装

実

他プラットフォーム実装

処理[D]

ウ

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

ト[C-] 総合的な処理性能は Triple DES 同程度以下

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

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

鍵生成込暗号化処理[C-]： Triple DES の 0.8 倍程度の性能[A] 総合的な処理性能は Triple DES よりもかなり高い[C-] 総合的な処理性能は Triple DES 同程度以下

暗号化処理速度[C-]： Triple DES の 0.6 倍程度の性能[A] 今のところ問題は見つかっていない

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

CIPHERUNICORN-E

フ

ソ

Pentium III 実装

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

評価項目

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

そ

他

の

仕様が

三菱電機株式会社

特記事項

三菱電機株式会社

株式会社東芝（１）

出願番号 PCT/JP96/02154「データ変換装置及びデータ変換方法」（参考）日本特許： 特許第 3035358 号

株式会社東芝vi

ISO/IEC 18033-3 (Committee Draft)

NESSIE

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

を認める。

ンダードの地位にあることを考慮し、当面の使用

FIPS46-3 に登録されており、かつデファクトスタ

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

NIST

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

FIPS PUB 46-3 において、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).」

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

FIPS PUB 46-3

ISO/IEC 18033-3 (Committee Draft)
なし

ANSI X9.65 (Working Draft)

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

3-key Triple DES

ANSI X9.52-1998

MISTY1IETF RFC 2994 (Informational)

日本電気株式会社（２）

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

なし

Hierocrypt-L1

日本電気株式会社（２）

CIPHERUNICORN-E のプログラム
商標
登録番号 第 4221077 号

特許
出願番号：出願平 9-213274
名称： 暗号装置及び暗号装置を実現するプログラ
ムを記録したコンピューターが読み取り可能な
記録媒体
著作物

なし

なし

提案元

(b) 上記(a)の知的財産権の扱い(a) 該 当 す る 知
的財産権

引用された規格仕様が定められた規格CIPHERUNICORN-E

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

問い合わせ先

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

採用状況

などへの

国際標準

評価項目

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

装

実

ア

ェ

ウ

ト

鍵即応性**

他プラットフォーム実装

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

性能

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

処理を実行させることが必要となるため、全体として性能が低下する

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

鍵生成時間は、暗号化では Triple DES の 1/3

鍵生成時間は Triple DES の 1/3 程度である[B] 鍵交換ペナルティは小さいが向上[B/C] 鍵交換ペナルティは小〜中程度

キャッシュサイズが大きい CPU では実装性能方がより重い込暗号化処理[A+]Alpha 21264 での暗号化処理速度[A+]、鍵生成

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

かなり高い[A] 総合的な処理性能は Triple DES よりも鍵長によって、処理速度が 15%程度低下の性能

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

後の性能

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

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

SC2000

鍵生成込暗号化処理は、暗号化よりも復号の込暗号化処理[A/B+]

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

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

UltraSPARC IIi での暗号化処理速度[B+/B]、

も高い[B+] 総合的な処理性能は Triple DES より復号の場合には、暗号化の場合と比較して、

鍵生成時間は Triple DES の 3 倍程度である[D] 鍵交換ペナルティは大きい

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

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

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

能Triple DES の 5.5 倍弱、復号では同 3 倍弱の性

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

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

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

Hierocrypt-3

なくとも鍵生成または復号のどちらかにより重い

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

鍵長による処理速度低下はほとんどない

倍程度の性能

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

能暗号化処理速度[C]： Triple DES 同程度の性[C-] 総合的な処理性能は Triple DES 同

程度[C] 総合的な処理性能は Triple DES 同[A] 今のところ問題は見つかっていない

CIPHERUNICORN-A

復号の場合には、暗号化の場合と比較して、少程度、復号では Triple DES と同程度である

鍵生成時間は、暗号化では Triple DES の 1/5[B/C] 鍵交換ペナルティは小〜中程度[B] 鍵交換ペナルティは小さい

成込暗号化処理[A+]

鍵生成込暗号化処理は、暗号化よりも復号の方がより重いとされる

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

生成込暗号化処理[A]

成込暗号化処理は[B+/-]

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

UltraSPARC IIi での暗号化処理速度[A]、鍵もかなり高いかなり高い

UltraSPARC IIi での評価未実施[A] 総合的な処理性能は Triple DES より[A] 総合的な処理性能は Triple DES よりも鍵長により処理速度が 15-30%程度低下

倍超の性能

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

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

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

DES の 7 倍超、復号では同 4.75 倍程度の性能もかなり高いかなり高い
暗号化処理速度[A]： Triple DES の 5.25 倍程[A] 総合的な処理性能は Triple DES より[A] 総合的な処理性能は Triple DES よりも暗号化処理速度[A+/A]： 暗号化では Triple[A] 今のところ問題は見つかっていない

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

AES

vii

** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号

性

装

実

フ

ソ

(128 ビット鍵)

Pentium III 実装

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

評価項目

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

使用 RAM サイズは中程度[C-]
処理速度は Triple DES よりも高速である[B+]

使用 RAM サイズは中程度[C-]

処理速度は Triple DES よりも高速である[B+](b) 上記(a)の知的財産権の扱い(a) 該 当 す る
知的財産権

特記事項

問い合わせ先

提案元

財 産 権
の 実 施
の 権 利
に関する
考え方

元が保有
する 知的

電 子 政
府 利 用
にあたっ
ての 提案

引用された規格

日本電信電話株式会社
三菱電機株式会社

on. html

三菱電機株式会社

日本電信電話株式会社（１）

特願 2001-565161「データ変換装置及びデータ変換方法
をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体」
PCT/JP01/01796「データ変換装置及びデータ変換方法
をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体」
中華民国出願 90105464「データ変換装置及びデータ変換方法
をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体」

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

NIST

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

Implementation of the algorithm「
specified in this standard may be coveredby U.S. and foreign patents.」

WAP/WTLS1.0
FIPS PUB 197 において、Patents に関する記述は以下のとおり。

TV-Anytime Forum Specification S-7

IETF IPsec (Internet Draft)

IETF S/MIME (Internet Draft)

TV-Anytime Forum Specification S-7

IETF TLS1.0 (Internet Draft)

IETF RFC 3268: AES Ciphersuites for TLS(Informational)

NESSIENESSIEIETF RFC 3394: AES Key Wrap Algorithm

ISO/IEC 18033-3 (Committee Draft)

ISO/IEC 18033-3 (Committee Draft)などへのIETF RFC: (Internet Draft)

FIPS PUB 197

採用状況

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

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

CIPHERUNICORN-A

Hierocrypt-3

日本電気株式会社

日本電気株式会社（２）

CIPHERUNICORN-A のプログラム
商標
登録番号 第 4221077 号

特許
出願番号：出願平 9-213274
名称： 暗号装置及び暗号装置を実現するプログラムを記録したコンピューターが読み取り可能な記録
媒体
著作物

なし

なし

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

Triple DES よりやや優れている

viii

株式会社東芝株式会社東芝（２）

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

なし

なし

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

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

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

使用 RAM サイズはやや大きい[D]使用 ROM サイズはやや大きい[D]ば、総合的な処理性能および実装性は理性能と同程度以上にはならないと推定[B] や や使 用 メモリ 量が 大 きい ことを除 け論ではないが、少なくとも Triple DES の処[D 以下] 評価未実施であり、最終的な結*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数〜10KB 程度、RAM128byte 程度）を想定した評価を基にしている。

他

の

そ

使用 ROM サイズは少ない[C]使用 ROM サイズは少ない[C]IETF S/MIME (Internet Draft)

仕様がTriple DES よりも優れている

Triple DES よりも優れている

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

Camellia[B+] 総合的な処理性能および実装性は

AES[B+] 総合 的な処 理性 能および実 装 性は

(Proposed Standard)

国際標準

定められた規格仕様がハードウェア実装（低機能型 IC カード評価***）装性

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

実

評価項目

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

SC2000富士通株式会社

富士通株式会社（２）

特願 2001-108016 （特開 2001-282102）「暗号設計装置、暗号設計プログラム
及び記憶媒体」
特願 2000-212813 （特開 2000-91297）「F 関数内部に SPN 構造を用いた演算装置及び演算方法」
特願 2000-212814 （特開 2002-91295）「Feistel 構造と SPN 構造とを組み合わせた演算装置及び演算」
特願 2000-212482 （特開 2002-91296）「拡大鍵生成装置及び記憶媒体」

なし

なし

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

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

使用 RAM サイズは中程度[C-]使用 ROM サイズは中程度[C-]

Triple DES と同程度以上[C+] 総合的な処理性能および実装性は鍵即応性**

引用された規格仕様が定められた規格株式会社日立製作所

特記事項

株式会社日立製作所

株式会社日立製作所（２）い。

いる。その他の暗号を利用できるのであれば、そちらを選択することが望まし

128 ビット鍵長を選択のうえ、SSL3.0/TLS1.0 に限定して利用することを想定して

RSA セキュリティ株式会社

RSA セキュリティ株式会社

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

94403-2507, USA, or http://www.rsasecurity.com."contact: RSA Security Inc. 2955 Campus Drive, Suite 400, San Mateo, CA

are available under license from RSA Security Inc. For licensing information,of any third party. Proprietary implementations of the RC4 encryption algorithm

implementations of the algorithm will not infringe the intellectual property rights

algorithm. However, RSA Security does not represent or warrant that

does not hold any patents nor does it have any pending applications on the RC4

used by third parties creating implementations of the algorithm. RSA Security"The mark RC4 is a registered trademark of RSA Security Inc. and may not be「共通鍵暗号方法及び装置」

り。

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

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

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

―――

―――

―――

暗号化処理速度[A+]： Triple DES の 8.3 倍の性能である[A+] 処理性能は Triple DES よりもかなり高い

ない

特願 2000-210690 （特開 2001-324925）

株式会社日立製作所（２）

128-bit RC4[B] SSL/TLS としての利用に関しては、今のところ問題は見つかってい「暗号化装置および方法」

特願 2000-108334 （特開 2001-007800）

なし

提案元

(b) 上記(a)の知的財産権の扱い

知的財産権「疑似乱数生成装置またはそれを用いた暗号復号処理装置」

特願 2001-274433 （公開番号なし）「疑似乱数生成装置またはそれを用いた暗号復号処理装置」

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

なし

第三者実装が可能であることを確認
ISO/IEC 18033-4 (Committee Draft)

なし

―――

鍵生成時間は Triple DES の 5 倍前後である[D] 鍵交換ペナルティは大きい

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

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

鍵生成時間は Triple DES の 20 倍程度である[E] 鍵交換ペナルティは非常に大きい

暗号化処理速度[A+]： Triple DES の 10.75 倍前後の性能である[A+] 処理性能は Triple DES よりもかなり高い[A+] 処理性能は Triple DES よりもかなり高い

問い合わせ先

権の実施
の権利に
関する考え
方

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

状況

どへの採用

国際標準な

仕様が

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

実装

Pentium III 実装[A] 今のところ問題は見つかっていない

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

MUGI

ix

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

** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号

他

の

そ

性

装

実

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

評価項目

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

RIPEMD-160

SHA-1

そ

特記事項

問い合わせ先提案元扱い

ISO/IEC 10118-3より長いハッシュ値のものを採用することができるのであれば、256 ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべき
ハッシュ関数が指定されている場合には、
この限りではない。

ができるのであれば、256 ビット以上のハッシュ関数を選択することが望ましい。ただし、公開鍵暗号での仕様上、利用すべき

ハッシュ関数が指定されている場合には、

この限りではない。

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

NIST

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

NIST

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

「
Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」

Implementation of the secure「hash algorithms in this standard may becovered by U.S. and foreign patents.」

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

FIPS PUB 180-2 において、Patents に関する記述は以下のとおり。

なし

―――

―――

FIPS PUB 180-2 において、Patents に関する記述は以下のとおり。

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

より長いハッシュ値のものを採用すること/ ripemd160.html

http://www.esat.kuleuven.ac.be/~bosselae

Bart Preneel

Hans Dobbertin, Antoon Bosselaers, and下記問い合わせ先 URL 等を参照のこと。

下記 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.」

なし

NESSIEFIPS PUB 180-2
IETF RFC 3174 (Informational)

FIPS PUB 180-2―――

い[A] 処理速度は Triple DES よりもかなり速

ANSI X9.30 (Part2)―――

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

SHA-384―――

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

NIST

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

「
Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」

FIPS PUB 180-2 において、Patents に関する記述は以下のとおり。

なし

NESSIEFIPS PUB 180-2―――

Triple DES 同程度以上[C+] 処理速度は SHA-512 相当であり、[A] 今のところ問題は見つかっていない

SHA-512―――

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

NIST

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

「
Implementation of the securehash algorithms in this standard may becovered by U.S. and foreign patents.」

FIPS PUB 180-2 において、Patents に関する記述は以下のとおり。

なし

NESSIEFIPS PUB 180-2―――[C+] 処理速度は Triple DES 同程度以上[A] 今のところ問題は見つかっていないx*** メモリ制限環境での実装性能： 低機能型 IC カード（8 ビット CPU、ROM 数 k〜10kbyte 程度、RAM128byte 程度）を想定した評価を基にしている。

** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号

他

の

格

引用された規

仕様が

格

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

状況

どへの採用

国際標準な

仕様が

定められた規ISO/IEC 10118-3（低機能型 IC カード***）性

ハードウェア実装

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

装

―――

速い

速い

―――

[A+] 処理速度は Triple DES よりも極めて[A+] 処理速度は Triple DES よりも極めて

ソフトウェア実装[A] 今のところ問題は見つかっていない（Pentium III 実装）[A] 今のところ問題は見つかっていない実

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

評価項目

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

性

国際標準

引用された規格仕様が定められた規格

特記事項

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

用状況

などへの採

仕様が

―――

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

NIST
http://cscr.nist.gov/encryption/tkrng.html
仕様書中で定義されている使い方の中には安全とは言い切れない方法がある。利用の際には、CRYPTREC Report 2002 の該当節を確認のう
え、適切な使い方を選択する必要がある。

ANSI

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

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

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

がある。利用の際には、CRYPTREC Report 2002 の該当節を確認のう

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

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

NIST

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

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

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

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

なし

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

―――

―――

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

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

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

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

なし

ANSI X9.42-2001 Annex C.1―――[A+] ほぼ SHA-1 の処理速度に等しい。SHA-1 の実装性能を参照。

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

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

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

revised Appendix 3.1

Appendix 3.1[A] 今のところ、パラメータなどを適切に設定すれば、実用上の重大な

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

PRNG based on SHA-1 for general purpose in FIPS 186-2 (+ change notice 1)[A] 今のところ、パラメータなどを適切に設定すれば、実用上の重大な

PRNG based on SHA-1 in ANSI X9.42-2001 Annex C.1

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

** 鍵即応性： パケット通信のように、大量の短いデータ（数十 byte 程度）を異なる秘密鍵で暗号化（あるいは復号）するときの処理性能適性をあらわす。処理速度だけでなく、鍵生成（鍵セットアップ）に関する処理負荷も大きな特性要素となる。

技術の結果（第 3.3 節）ならびに第 6 章『暗号技術の実装に関わる攻撃』を参照すること。

* アルゴリズム安全性評価コメント： 暗号アルゴリズムそのものの安全性強度を評価したものであり、実装攻撃の脅威は対象としていない。実装攻撃に対する概要について、CRYPTREC Report 2002 第 3 章『共通鍵暗号技術の評価』中の個別暗号

他

の

そ

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

ハードウェア実装（Pentium II/III 実装）

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

実

ソフトウェア実装

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

評価項目

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

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

各応募暗号の、電子政府システムでの利用における提案元が保有する知的財産権の実施の権利の取扱いについて、提案元に確認を行った。「（b） 上記（a）の知的財産権の取扱い」の「（1）」「（2）」は、それぞれ以下のような取扱いを示す。
※提案元以外の第三者が保有する知的財産権については、その有無も含めて確認されていないので、注意すること。
（１） 当社は、上記「暗号アルゴリズム名」に記載された暗号アルゴリズムの使用にあたって、上記（a）に記載されている当社保有知的財産権に関し、いかなる者に対しても、非差別的かつ無償で通常実施権（又は著作権の利用）を許諾する。ただし、当該暗号アルゴリズムに関連する他の知的財産権所有者であって、（１）の条件で自らの知的財産権の実施を許諾しない者に対しては、この
限りではない。
（２） 当社は、上記「暗号アルゴリズム名」に記載された暗号アルゴリズムの使用にあたって、上記（a）に記載されている当社保有知的財産権に関し、いかなる者に対しても、当該知的財産権の権利の内容、条件を明らかにした上で、非差別的かつ妥当な条件（無償の場合を除く。）で通常実施
権（又は著作物の利用）を許諾する。ただし、当該暗号アルゴリズムに関連する他の知的財産権所有者であって、（１）又は（２）の条件で自らの知的財産権の実施を許諾しない者に対しては、この限りではない。

○共通鍵暗号

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

xii

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

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

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

B

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

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

D

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

ソフトウェアによる処理性能では表 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-

注意事項
最速値と平均値が測定されている暗号技術については最速値を採用する。
規定計測プログラムと修正計測プログラムとの両方が測定されている暗号技術については、速い方の値を採用する。
記号に付随する数値は、Triple DES との相対性能比を表す。
X/Y と表記されている暗号技術は、暗号化性能評価が X、復号性能評価が Y であることを示す。
特に区別がない場合は、暗号化性能と復号性能が同程度であることを示す。
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 の性能

注意事項
本評価の便宜上、暗号化処理速度と鍵込処理速度の差を鍵セットアップ時間とみなす。
最速値と平均値が測定されている暗号技術については、最速値を採用する。
規定計測プログラムと修正計測プログラムとの両方が測定されている暗号技術については、速い方の値を採用する。
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

上

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

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

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

別 添

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

務
済

産

省
業

省

名称
署名

公開鍵暗号

守秘
鍵共有

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)

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