CRYPTREC Report 2016

平成 29 年 3 月
独立行政法人情報処理推進機構
国立研究開発法人情報通信研究機構

CRYPTREC-RP-0003-2016「暗号技術活用委員会報告」

目次
はじめに ············································································································ 1
本報告書の利用にあたって···················································································· 2
委員会構成 ········································································································· 32016 年度の活動内容と成果概要 ············································································ 7
1.

活動内容 ··································································································· 7

2.

今年度の委員会の開催状況 ··········································································· 8

3.

成果概要 ··································································································· 83.1.

運用ガイドラインの対象について ······························································· 83.2.

運用ガイドラインのアップデート方法に関連する検討 ·································· 33

3.3.

外部連携について ·················································································· 34

4.

今後に向けて ··························································································· 36

i

ii

はじめに
本報告書は、総務省及び経済産業省が主催している暗号技術検討会の下に設置され、独立行政法人
情報処理推進機構及び国立研究開発法人情報通信研究機構によって共同で運営されている暗号技術活用委員会の 2016 年度活動報告である。
暗号技術活用委員会は、電子政府の安全性及び信頼性を確保し国民が安心して電子政府を利用できる環境を整備するため、暗号利用に関するセキュリティ対策の推進、暗号技術の利用促進に向けた環境整備を主に担当する委員会である。2015 年度に、暗号技術活用委員会の活動目的の軸足を、「暗号技術を主軸とした検討」から「情報システムのセキュリティ確保に寄与する暗号技術等に係る成果物の提供」に移すことに定義し直し、2016 年度から新たな目的に基づいて活動を開始した。
2016 年度の暗号技術活用委員会では、利用者に使いやすい運用面でのガイドライン（運用ガイド
ライン）を本格的に整備していくことを今後の活動の中心に据えることを視野に入れ、暗号プロトコルに関する部分については暗号プロトコル課題検討 WG にて検討し、それ以外の部分については暗号技術活用委員会にて、CRYPTREC として扱うべき運用ガイドラインの対象について検討を行った。
2017 年度以降の活動においては、運用ガイドラインの必要性や目的、書かれるべき内容や想定読者、作成時に考慮しなければならない課題、参考にすべき他組織が発行したガイドラインや連携すべき関連組織について 2016 年度に整理した検討結果を踏まえて、有益な運用ガイドラインを優先的かつ効率的に作成していく所存である。
さらに、運用ガイドラインは、ガイドライン作成時の標準化状況や製品状況、利用環境や利用実績等を踏まえて作成時における現実的かつ効果的な推奨設定や推奨基準を提示するものであることから、ある程度の時間が経過し、それらの状況が変化すれば、運用ガイドラインの中身も陳腐化し、ガイドラインとしてふさわしくないものとなる。そこで、運用ガイドラインの質を維持するためのアッ
プデートのあり方について検討を行い、例えば 2015 年に公開した「SSL/TLS 暗号設定ガイドライン」について、昨今 SSL/TLS に関する状況が大きく変化していることを反映して 2017 年度にアップデートする予定とするなど、今後運用ガイドラインの整備を進めるにあたっての方針を取りまとめた。
今年度の活動成果をもとに来年度以降、運用ガイドラインの拡充を図っていくことが、ひいては情報システムのセキュリティ確保の底上げ、暗号の普及促進・セキュリティ産業の競争力強化に繋がり、より安心・安全な情報化社会の実現に結び付くことを期待している。
末筆ではあるが、本活動に様々な形でご協力下さった委員の皆様、関係者の皆様に対して深く謝意を表する次第である。
暗号技術活用委員会 委員長

1

松本 勉

本報告書の利用にあたって
本報告書の想定読者は、一般的な情報セキュリティの基礎知識を有している方である。例えば、電子署名や GPKI1 システム等、暗号関連の電子政府関連システムに関係する業務に従事している方などを想定している。しかしながら、個別テーマの調査報告等については、ある程度の暗号技術の知識を備えていることが望まれる。
本報告書は、2016 年度の暗号技術活用委員会の活動内容と成果概要を記述した。
2015 年度以前の CRYPTREC Report は、CRYPTREC 事務局（総務省、経済産業省、国立研究開
発法人情報通信研究機構、及び独立行政法人情報処理推進機構）が共同で運営する下記の Web サイトから参照できる。
http://www.cryptrec.go.jp/report.html

本報告書ならびに上記 Web サイトから入手した CRYPTREC 活動に関する情報の利用に起因して生じた不利益や問題について、本委員会及び事務局は一切責任をもっていない。
本報告書に対するご意見、お問い合わせは、CRYPTREC 事務局までご連絡いただけると幸いである。
【問合せ先】 info@cryptrec.go.jp

1

GPKI：Government Public Key Infrastructure（政府認証基盤）

2

委員会構成暗号技術活用委員会（以下「活用委員会」）は、図 1 に示すように、総務省と経済産業省が共同で運営する暗号技術検討会の下に設置され、独立行政法人情報処理推進機構（IPA）と国立研究開発法
人情報通信研究機構（NICT）が共同で運営している。
活用委員会は、電子政府の安全性及び信頼性を確保し国民が安心して電子政府を利用できる環境を整備するため、暗号利用に関するセキュリティ対策の推進、暗号技術の利用促進に向けた環境整備を主に担当する委員会である。
2016 年度は、2015 年度に定めた活動計画に基づいて活用委員会の活動を開始した。活用委員会では 2017 年度以降、運用ガイドラインの作成を開始するため、運用ガイドラインの対象範囲等について検討を行い、特に暗号プロトコルについては暗号プロトコル課題検討 WG にて検討した。
なお、活用委員会と連携して活動する「暗号技術評価委員会（以下「評価委員会」）」も暗号技術検討会の下に設置され、IPA と NICT が共同で運営している。

図 1

2016 年度の CRYPTREC の体制

3

4

委員名簿
暗号技術活用委員会
委員長

松本 勉

横浜国立大学 教授

委員

上原 哲太郎立命館大学 教授

委員

菊池 浩明

明治大学 教授委員

須賀 祐治

株式会社インターネットイニシアティブ シニアエンジニア

委員

杉尾 信行

株式会社 NTT ドコモ

委員

清藤 武暢

日本銀行

委員

手塚 悟

慶應義塾大学 特任教授

委員

寺村 亮一

NRI セキュアテクノロジーズ株式会社 主任

委員

松本 泰

セコム株式会社 ディビジョンマネージャー

委員

三澤 学

三菱電機株式会社 主席研究員

委員

満塩 尚史

内閣官房 政府 CIO 補佐官

委員

村木 由梨香日本マイクロソフト株式会社 セキュリティプログラムマネージャー

委員

山岸 篤弘

一般財団法人日本情報経済社会推進協会 主席研究員

委員

山口 利恵

東京大学 特任准教授

委員

渡邊 創

国立研究開発法人産業技術総合研究所 企画主幹

暗号プロトコル課題検討ワーキンググループ
主査

菊池 浩明

明治大学 教授委員

大泰司 章

一般財団法人日本情報経済社会推進協会 室長

委員

坂根 昌一

シスコシステムズ合同会社 エンジニア

委員

佐古 和恵

日本電気株式会社 技術主幹

委員

佐藤 直之

SCSK 株式会社 シニアプロフェッショナルコンサルタント

委員

下山 武司

株式会社富士通研究所 主管研究員

委員

須賀 祐治

株式会社インターネットイニシアティブ シニアエンジニア

委員

清藤 武暢

日本銀行

委員

寺村 亮一

NRI セキュアテクノロジーズ株式会社 主任

委員

村木 由梨香日本マイクロソフト株式会社 セキュリティプログラムマネージャー

委員

吉田 博隆

国立研究開発法人産業技術総合研究所 主任研究員

委員

渡辺 大

株式会社日立製作所 主任研究員

オブザーバー内田 稔

内閣官房内閣サイバーセキュリティセンター[2016 年 10 月まで]

久保山 拓

内閣官房内閣サイバーセキュリティセンター

高木 浩光

内閣官房内閣サイバーセキュリティセンター
5

眞弓 隆浩

内閣官房内閣サイバーセキュリティセンター

森安 隆

内閣官房内閣サイバーセキュリティセンター[2016 年 9 月まで]

赤谷 俊彦

総務省 行政管理局[2016 年 8 月まで]

廣田 亮

総務省 行政管理局

筒井 邦弘

総務省 情報流通行政局[2016 年 6 月まで]

上東 孝旭

総務省 情報流通行政局[2016 年 7 月から]

丸橋 弘人

総務省 情報流通行政局

今野 孝紀

総務省 情報流通行政局

加藤 誠司

経済産業省 産業技術環境局

上坪 健治

経済産業省 商務情報政策局

希代 浩正

経済産業省 商務情報政策局[2016 年 6 月まで]

中野 辰実

経済産業省 商務情報政策局[2016 年 6 月まで]

中村 博美

経済産業省 商務情報政策局[2016 年 6 月まで]

森川 淳

経済産業省 商務情報政策局[2016 年 7 月から]

松本 裕悟

防衛省 整備計画局

吉岡 達宏

防衛省 整備計画局

岡野 孝子

警察大学校

多賀 文吾

警察大学校

相原 大輔

警察大学校

事務局
独立行政法人情報処理推進機構 (江口純一、時田俊雄、小暮淳、神田雅透、稲垣詔喬、兼城麻子)
国立研究開発法人情報通信研究機構 （宮崎哲弥、能見正、盛合志帆、野島良、吉田真紀、
大久保美也子、篠原直行、黒川貴司、金森祥子）

6

2016 年度の活動内容と成果概要
1.

活動内容
2015 年度に、「CRYPTREC の在り方に関する検討グループ」及び「重点課題検討タスクフォー

ス」での検討結果に基づき、暗号技術活用委員会での活動方針の軸足を、「暗号技術を主軸とした検討」から「情報システムとしてのセキュリティ確保に寄与する成果物の提供」に移し、新たな活動
方針を以下のように定義し直した。
【活動目的】
暗号技術活用委員会では、情報システム全般のセキュリティ確保に寄与することを目的として必要な活動を行うものとする。具体的には、実運用とセキュリティ確保の両面の観点から、以下の対象を取り扱う。
 暗号アルゴリズムの利用及び設定に関する運用マネジメント
 暗号プロトコルの利用及び設定に関する運用マネジメント
 その他、情報システム全体のセキュリティ確保に有用な暗号に関わる運用マネジメント
2016 年度は、上記の活動目的を踏まえ、運用面でのマネジメントに関するガイドライン（以下、運用ガイドライン）を本格的に整備していくことを今後の暗号技術活用委員会（以下、活用委員会）
での活動の中心に据えることを視野に、以下の項目について検討を行った。
① 作成すべき運用ガイドラインの対象及び取扱い範囲の切り分けの検討② 作成した運用ガイドラインのメンテナンス体制の検討③ 外部組織や業界団体との連携方法の検討④ 運用ガイドラインの作成⑤ ベンダや業界団体等の意向をバランスよく取り入れつつ、セキュリティも担保する利用価値の高い成果物となるようにコントロールする⑥ その他
CRYPTREC として暗号プロトコルをどのように扱うかを重点的に検討するため、「暗号プロトコル課題検討 WG（以下、課題検討 WG）」を設置
なお、①については、暗号プロトコルに関わる部分を課題検討 WG で、それ以外の範囲を活用委員
会でそれぞれ検討した。また、④と⑤については、実際の運用ガイドラインを作成する際に、テーマに応じて適切な手段を活用委員会で判断して実施していくことになった。

7

2.

今年度の委員会の開催状況

2016 年度暗号技術活用委員会は 2 回開催された。各回会合の概要は表 1 のとおり。また、暗号プ
ロトコル課題検討 WG は 3 回開催された。各回会合の概要は表 2 のとおり。
表 1
回

2016 年度暗号技術活用委員会

開催日

開催概要

議案
・暗号プロトコル課題検討 WG 活動状況報告

第1回

2016 年 11 月 9 日

・運用ガイドライン（「SSL/TLS 暗号設定ガイドライン」）のメ
ンテナンス方法に関する検討
・運用ガイドラインの対象範囲に関する検討
・暗号プロトコル課題検討 WG 活動報告

第2回

2017 年 3 月 15 日

・暗号プロトコル以外の運用ガイドラインの対象の検討
・外部連携の進め方の検討
・2016 年度暗号技術活用委員会報告書

表 2
回

暗号プロトコル課題検討 WG

開催日

開催概要

議案

第1回

2016 年 10 月 27 日 WG 活動概要の説明、課題についての自由討議

第2回

2016 年 12 月 26 日 第 1 回 WG での討議を踏まえた課題の整理と更なる検討

第3回

2017 年 2 月 10 日

報告書案の取りまとめ

3. 成果概要
3.1. 運用ガイドラインの対象について
2017 年度以降に活用委員会として運用ガイドラインを作成する価値がある対象を検討するにあたっては、以下の目的と領域に合致する範囲のガイドラインを想定して議論を行った。なお、
暗号設定ガイドラインのうち、暗号プロトコルに関する部分については課題検討 WG にて検討を行い、それ以外の部分については活用委員会にて検討を行った。


どのような目的をもつ運用ガイドラインにするか
1.

現在利用されている仕組みの中で安全ではない使われ方を排除し、安全性の底上げを図る（NIST SP800 シリーズのような推奨設定の基準（ガイドライン）をイメージしたもの）

2.

利用者が理解しやすく、かつ採用しやすいベストプラクティスを示す（NIST SP1800 シ
リーズのような利用しやすいガイドをイメージしたもの）
8

3.

普及が進んでいない安全な仕組みの普及・活用を促進させる（安全な仕組みへの移行を促すようなガイドをイメージしたもの）

4.

政府、業界団体等が守るべき（半）強制的基準として示す（そうなるような環境整備を含む）



どのような領域の運用ガイドラインにするか
A.

B.

暗号設定ガイドライン


開発実装に関連するガイドライン



暗号利用・運用・設定に関連するガイドラインで暗号プロトコル以外のもの



暗号利用・運用・設定に関連するガイドラインで暗号プロトコルに関するもの



特定の製品・サービスを安全にするために関連するガイドライン

マネジメント関連のガイドライン


暗号システムの運用マネジメントに関連するガイドライン

整備すべき運用ガイドラインの対象は何か
暗号設定ガイドライン（利用方法、及び設定方法）

マネジメント関連のガイドライン（鍵管理、リスク管理等）

暗号プロトコルに関する運用ガイドライン（⇒ 課題検討WGにて検討）

図 2

整備すべき運用ガイドラインの対象及び取扱い範囲の切り分け【暗号プロトコルに関する運用ガイドライン以外の対象】
もともと運用ガイドラインの必要性が高いと考えられている対象を中心に、以下の観点から整理を行った。
表 3 に検討結果をまとめる。今後、運用ガイドラインを作成していく際には、表 3 に挙げたもののなかから優先的に取り上げていくことが望ましい。なお、「課題」には CRYPTREC が作成する運用ガイドラインの価値を高めるために考慮しなければならないポイントをまとめており、
また「関連組織」には連携先として有効と期待される国内組織（国際組織の日本支部を含む）を記した。活動計画の立案に当たっては、これらのポイントを踏まえた計画であることが望まれる。
【対象】
どのような用途で使う運用ガイドラインであるか【目的・内容】
どのような目的をもった運用ガイドラインを意図したものか（3.1 で挙げた目的の 1. ～4.
のどれに当たるか）
9



【内容】
運用ガイドラインに記載される内容はどのようなものか【想定読者】
その運用ガイドラインの想定読者は誰か



【必要性】
なぜ運用ガイドラインが必要なのか、あるいは運用ガイドラインがないとどのように困る
のか



【課題】
ガイドラインを作るうえで問題となりそうな課題／注意しなければならない課題は何か【他組織のガイドライン等】
他組織が同種のガイドラインを作っていないか／作ろうとしていないか

【関連組織】
どのような他組織と連携していくのがよいか

なお、表 3 の「領域」列、及び「目的」列の表記についての注意は次のとおりである。
●「領域」列について
・開発実装に関連する文書類
・暗号利用・運用・設定に関連する文書類で暗号プロトコル以外に関するもの
・暗号システムの運用マネジメントに関連する文書類
・特定の製品・サービスを安全にするために関連する文書類●「目的」列の表記の意味①・・・現在利用されている仕組みの中で安全ではない使われ方を排除し、安全性の底上げを図る（安全性評価を含む）②・・・利用者が理解しやすく、かつ採用しやすいベストプラクティスを示す③・・・普及が進んでいない安全な仕組みの普及・活用を促進させる④・・・政府、業界団体等が守るべき（半）強制的基準として示す（そうなるような環境整備
を含む）

10

表 3

取りまとめ結果一覧
他組織

目
領域

No

対象

内容

想定読者

ガイドライン作成にが発行しあたっての課題

たガイド

関連組織

必要性（※委員から意見）

的

ライン等
・他の対象に比べて、「鍵管理」を優先的に検討してほしい。

・書くべきことの範囲が・鍵の元となる技術であるため、重要（特に公開鍵暗号の鍵広い。

・システム開生成）。不適切な実装では、知らないうちに素因数を他の鍵・抽象的な文書になるこ

発者（特に、と共有している事例もある。

とが予想されるので、範・乱数性テストのチェック項目

プログラマ

・日本の情報セキュリティ対策の底上げになる。暗号を応用

囲や対象読者を限定し①

・安全な鍵生成方法ー）、運用者（利用）したシステム全般の参考にもなる。

ないと作成が困難。

②

・鍵の保管

・今後システ・システム開発者や運用者が想定読者になりうるかは定かで・鍵管理に関する規格

・鍵の削除

ムを構築する

ないが、製品開発者向けには必要。

を網羅的に調査する必中小企業

・SP800-90 では、乱数に必要なエントロピー等について言要がある。

・製品開発者及しているが、実際には最低限どのようにすればよいのかが※「鍵管理」の全体像をわからない。特に、リアルタイム性を要する鍵についてどこま

整理したのちに優先順

でやればよいかがわかるものがほしい。

位をつけて作成

SP800-

鍵管理（生成・開発
1

90A, B,

保管・削除）の実装

C

実装

システム開発・アプリでのサーバ証明書検証不備の脆弱性が多い。

者(特に、ア・IoT 向けに、大量、高速、省リソースという様な観点で、サープリケーショ

バ証明書の検証方法だけでなく、PKI の構築全般について

ン開発者)

策定されれば、組込機器向けにも参考になる。

アプリにおけるサーバ証明書がサーバ証明書2①

適切に検証されるための実装

の検証方法
方法

①

システムに電子署名や検証ア

3②

プリを実装する方法（ネイティブ・実装方法が、技術依少ない。今までは Java でブラウザプラグインとドライバーとを

者

実装方法
③

アプリを作る場合やマルチプラ

JNSA 電・システムへの電子署名や検証アプリの実装者向け文書がシステム開発電子署名・検証

子署名存する可能性があり、時つないでいたが、Java がブラウザプラグインをサポートしない

11

WGットフォームを想定したブラウザ

方針が表明されており、様々な実装が出てくることが予想さ期によって変化する。

ベースの場合等）れるため、実装に関する情報が必要。

・実装方法が複数ある。

・民間企業が、JPKI の署名検証を行うことができるようになったので、民間企業のアプリにおいても、電子署名を行うアプ
リを実装することが現実化してきた。
・実装方法を示さないと多くのアプリが開発されず、電子署名が普及しない。普及のために、実装方法をレクチャーする
ものという位置づけである。
・従来は専門家が電子署名の実装を行っていたが、今後は専門ではない SIer も実装に携わる可能性があるため、電子署名を適切に実装させるために必要である。
・各社勝手に導入しているシステム開発・各社様々な方式で導入している。銀行などのウェブサイト

者（特に、アへのログインにも多用されている。

プリケーショ

・チャレンジレスポンスだと考えれば、必ずしも暗号に無関係

ン開発者）

ではないため、ガイドラインがあるとよい。

Captcha の最低限の安全性検開発

Captcha の検証

①
査

4
実装

方法

②
・過度に利便性を下げていないか・今後開発されるシステムにおいて、暗号危殆化対応の観点
将来の暗号危から、設計段階で考慮すべきことを明確化・明文化する必要・一般的な留意点は整がある。

理可能である一方、利・2030 年頃に使用を停止する 112bit 安全性の暗号に対す用しているシステム毎にる危殆化対策は、時期尚早であるため、他のテーマに比べ暗号の使い方が異なる

替)て、優先度は低い。

ため、具体手にガイドす－当該暗号の使用停止 等

・ただし、これから IoT や組み込みなどが普及してくるため、るのは難しい。

将来の暗号危殆化対策を見据殆化対策を見
えたシステム設計・開発方法
システム設計据えたシステム－インシデント対応方針
5

設計・開発方法者、開発者②－暗号アルゴリズムの切替(代（運用者）※C. 暗号シス
テムの運用マネ
ジメントにも記載

2030 年ぎりぎりまでやらなくてもよいというわけではない。

12

・暗号をカセッタブルに実装することが必要であり、それをガイドする必要がある。

・安全な
暗号鍵

・暗号を利用するうえで、鍵を秘密に保つことが重要であるのライフにも関わらず、IT 担当者の中には鍵がどういうものかを知ら・書くべきことの範囲がサイクルない人すらいる状況であるため、普及啓発が必要。
非常に広いため、対象

マネージ・他の対象と比べて「鍵管理」を優先的に検討してほしい。
範囲を絞る必要がある。
・システム開メントに・日本の情報セキュリティ対策の底上げになる。暗号を応用
・抽象的な文書になるこ

発者（例え

暗号利

とが予想されるので、範ば、プログラ用・運鍵管理（生成・①の要求事項

保管・削除）の②

・代表的な製品での具体的な設

6
（暗号プ

設定/運用

③

IPA

ないと作成が困難。
者ても必要。

・今後システ・例えば、SQL, Exchange といったアプリケーションや、

ライン・鍵の生成・削除の文書（案）と併せて用意ができるとKey Vault 等）
以外）

理ガイド

・データ処分(Data Disposed)にも関連する鍵の削除につい

定方法例（BitLocker, Azure

ロトコル

査 鍵管

・鍵管理について個別の製品ごとの設定例が必要である。
囲や対象読者を限定しマー）、運用

用・設定

関する調（利用）したシステム全般の参考にもなる。

・鍵管理（生成・保管・削除）上ムを構築する・SP

Active Directory での証明書を利用した認証、Federation
よい。

中小企業

800-57での認証などを含めると証明書および鍵の管理が必要とな※「鍵管理」の全体像をPart 2

る対象が大規模に存在する。
整理したのちに優先順

・SP・ファイル暗号、ディスク暗号に関しても同様に大規模な対位をつけて作成。
象がある。EFS 暗号化、BitLocker （あるいはデバイス暗号

800-57化）の利用率は年々高まっている。

Part 3
Rev. 113

他組織ですでに存在す

・OpenSSL の鍵管理
SSL・SSH の鍵

①

管理

②

システム管理・他の組織で作成していないようであれば、作成できるのが

者、運用者

望ましい。

るようであれば、作成す

・CSR を作るときのパスワードの

7

IPAる必要がない。

設定
・PDF への署名ということでガイドラインがあるべき。PDF の・PDF にいくつものバー
署名で利用する証明書には SHA-1 が利用されている例もジョンがあり、互換性なあり、適切に利用させる必要があるので、ガイドを作成するべど懸念。
き。
・ドキュメント管理というと・署名なしの PDF を出している人も多いため、署名をさせる
PDF だけでなく、PDF
ドキュメントへの①

・PDF の暗号化/署名における

署名

③

暗号の設定

べき。
JNSA

だけでも製品数が多PDF 利用者

8

・ユーザが不正な署名に気が付かないので、ユーザへの啓
い。

暗号利

蒙が必要。

用 ・ 運

・検討範囲を明確化する必要があるため、時期尚早。代替用・設定

手段（ファイル暗号化ソフトや Cloud 環境）も存在しており、（暗号プ

すぐに対応しなければならないわけではないため、優先度

ロトコル

は低い。

以外）

・「高度な暗号化」の定義が明確に定まっていないため、明・日本では主に JNSA が署名について、検討しているため、JNSA との相談（連携）が必要。

確にした文書（ガイドライン）があるとよい。
他の組織でも検討して・保管データを暗号化する方法についての文書（や基準）が・保管データにおける暗号化方
保管データ
9

法

システム開発ないため、個人情報保護ガイドラインから参照できるような文・保管データ暗号化における鍵者、運用者書が必要。暗号について議論できる組織体が CRYPTREC④(Data at Rest)

管理いるため、歩調を合わ

NIST

個人情報

せた基準とするためにも

SP800-

保護委員

リエゾンを組みながらや

111

会

しかないので、作成すべき。
らなければならない。
・法律的に定められる必要があり、民間では実施が困難であるため、CRYPTREC で作成するのが望ましい。

14

・暗号化を利用して、機密情報を破棄する方法についての文書（や基準）が日本にはないため、個人情報保護ガイドラ
他の組織でも検討してNIST

インから参照できるような文書が必要。CRYPTREC は国内
データの処分暗号利
10④

システム開発で暗号について議論できる組織体の代表であるため、検討

者、運用者

すべき。

SP800保護委員せた基準とするためにも情報の処分についての考え方(Data Disposed)

用 ・ 運

個人情報

いるため、歩調を合わ

暗号鍵破棄による暗号化された

88会

リエゾンを組みながらや

や方法
用・設定

・Cryptographic erase がベストプラクティスであり、法律上認（暗号プ

められないとデータの破棄が大変になるので、非常に困るた

ロトコル

め、検討すべき（例えば、バックアップテープの破棄）。

Rev.1
らなければならない。

以外）

他の組織でも検討して使用中のデータ
11の暗号化いるため、歩調を合わ

・暗号化されたまま情報を利用②(Data in Use)

システム開発・NIST にもガイドラインはないため、検索可能暗号等高機能者、運用者

暗号のガイドラインが必要。

せた基準とするためにもすることについての考え方や方リエゾンを組みながらや法

らなければならない。
・技術的な観点だけで・暗号を利用するうえで、鍵を秘密に保つことが重要である
なく、法制度を考慮してにも関わらず、IT 担当者の中には鍵がどういうものかを知ら作成すべき。

・システム開暗号シ

・NISTない人すらいる状況である（普及啓発も必要）。
・書くべきことの範囲が

発者（例え

ステムの

広い。

ば、プログラ12

考え方とが予想されるので、範

者

③

・NIST

したシステム全般の参考にもなるため、日本の情報セキュリ

・人がどのように運用するかとい

囲や対象読者を限定し・今後システ※考え

1 Rev. 4

・鍵管理の考え方が整理されていれば、暗号を応用（利用）

イクル

保管・削除）のト

・抽象的な文書になるこマー）、運用①57 Part係の中で、優先的に取り組むべき。

・鍵生成・管理・削除のライフサ

鍵管理（生成・ネジメン

SP 800-・まずは考え方をまとめたものを作るべきなので、鍵管理関・鍵管理の考え方
運用マ

SP800-

ティ対策の底上げになる。

う手続きも含む方・思想ムを構築するを含む

中小企業

ないと作成が困難。
130A

・すでに、2010 年度版リストガイド（鍵管理）があるため、参考※「鍵管理」の全体像をにする、もしくはアップデートするといった方法も視野に入整理したのちに優先順
れ、検討すべき。
位をつけて作成。

15

・システム内で利用する暗号機
能のマッピング（全体像）

・例えば、得られる費用対効果が大きくないにも関わらず、・ネットワークのゾーニングと暗SSL 通信と IP-VPN を利用した 2 重の暗号化を実施する、・システム構成のサンプ
ル種類がとても多いた

システム開発機密性を確保できる範囲を意識せず、SSL アクセラレーター

号機能の関係を配置するなど、ユーザ及び SIer は暗号対策をどこまでど・ユースケース別の暗号の使いのように実施すればよいかわからないため、暗号機能を含めどころを示す（SSL/TLS 暗号設

ザイン

難しい。

SIer）、運用②

13め、網羅的に書くのは者（特に①
暗号システムデ・効果的でない使い方

者、プログラ(③)

たネットワーク設計パターンを示す文書が必要。

定ガイドラインの上位レイヤのドをバッドプラクティスとし

マー等
キュメントとして位置づけ）

・システムとして、適切なコストでセキュリティを確保するため・効果的な使い方と効果的でなの指針が必要。

て検討するのは難しい。
い使い方の例示
暗号シ

・今後開発されるシステムにおいて、暗号危殆化対応の観点

ステムのから、設計段階で考慮すべきことを明確化・明文化する必要

運用マ

将来の暗号危将来の暗号危殆化対策を見据

ネジメン

殆化対策を見

えたシステム設計・開発方法がある。

一般的な留意点は整理

・2030 年頃に使用を停止する 112bit 安全性の暗号に対す可能である一方、利用る危殆化対策は、時期尚早であるため、他のテーマに比べしているシステム毎に暗て、優先度は低い。

号の使い方が異なるた

システム設計－インシデント対応方針

据えたシステムト－暗号アルゴリズムの切替(代設計・開発方法

※考え

者、開発者

②

14

（運用者）
方・思想

※A. 実装開発

替)・ただし、これから IoT や組み込みなどが普及してくるため、め、具体的にガイドする

を含む

にも記載

－当該暗号の使用停止 等

2030 年ぎりぎりまでやらなくてもよいというわけではない。

のは難しい。

・暗号をカセッタブルに実装することが必要であるため、ガイドする必要がある。
・暗号技術は移行が必要となるので、移行を促進するガイド
システム設計RSA から楕円曲
①
15

者、開発者
③

行

ラインを作成する必要がある（さしあたっては、特に RSA から

RSA から楕円曲線暗号への移線暗号への移楕円曲線暗号）。

行の推進
（運用者）

・PKI が最も影響を受ける。

16

・暗号の移行には時間がかかるため、RSA から楕円曲線暗号への移行について、早々に整理する必要がある。

・クラウドが採用している暗号化の対象・方式・設定をサービス
・サービス提供者が情・ユーザがクラウド利用時も暗号に注意して利用するためにごとに列挙（秘密計算、秘密分
セキュリティメカ
製品・サ

ニズムの比較調

散も含む）

企画者、シス必要。

・クラウドサービスにおける TLS

テム開発者

・統一基準でも、クラウドの利用に関しては、クラウドのセキュで利用している暗号化方式（特に SIer）

リティを確認することになっているが、現状では個別に暗号

①

16

ービス

CSA

報を開示してくれるかはクラウドにおける
特定の
②

不明。

JIS Q

(Cloud・そもそもガイドラインで

27017

Security

はなく、調査報告書にな

査・ストレージの暗号化方式

方式や設定等を確認することが困難。
る可能性がある。

※定期的に調査を実施するの
が好ましい

17

Alliance)

【暗号プロトコルに関する運用ガイドラインの対象】
暗号プロトコルに関する運用ガイドラインの対象を検討するにあたっては、「（STEP1）検討対象とする暗号プロトコルの列挙」と「（STEP2）列挙した暗号プロトコルのなかから運用ガイド
ラインを作る価値がある／必要性が高いと判断したものを抽出」の 2 段階で議論を行った。
（STEP1）検討対象とする暗号プロトコルの列挙
課題検討 WG では、暗号プロトコルの列挙にあたって、以下の観点から整理を行った。
その結果、表 5 にまとめる暗号プロトコルが検討対象として列挙された。
【種類】どのような性質のガイドラインが必要と考えられるか
表 4
ガイドライン

ガイドラインの種類

ガイドラインの概要例

状況

安全性評価に• 安全性のお墨付きをつけたプロト• 特定目的のために多くのプロト

関する

コル（＝CRYPTREC 暗号リスト

コルが提案されているのプロトコル版）• 暗号の専門家が関与しないでプ• 評価されていないプロトコルに対ロトコルが作られており、安全する安全性方法

性評価が不十分• 安全なプロトコルを設計するため• 標準化を待っていられないたのガイドライン

め、先行して実装が進んでいる• 製品の安全な実装・開発をするた• この種のガイドラインがないめのガイドライン• 各社独自の実装になっているの種類

ガイドライン

実装・開発に関するガイドライン• 安全な実装であることを検証するための基準設定に関する• 製品に実装されている設定方法を• プロトコルレベルよりも製品レ

ガイドライン

適切に設定して安全に利用するたベルのほうが需要があるめのガイドライン• 仕様が固まっている低レイヤのプロトコルであれば、運用ガイ
ドラインが作りやすい

【対象】どのようなところで使われる暗号プロトコルを対象範囲とするのがよいか
Web／証明書失効管理／DNS／NW 管理／鍵管理／ユーザ管理／ユーザ認証／デバイス
認証／バイオメトリクス暗号／ID 連携／無線通信／近距離通信／IC カード／メール／リ
アルタイム通信／ファイル共有／ファイル転送／リモート接続／VPN／自動車／制御シ
ステム／仮想通貨／放送暗号

18

表 5

検討対象となりうる暗号プロトコルの列挙一覧（「★」がついているプロトコルは暗号に直接関係がないもの）
種類

対象

プロトコル名称種類

対象
バイオメトリクス

ID 連携

プロトコル名称・テンプレート保護・OpenID Connect
暗号

・FIDO
・OpenID Connect

無線通信

・LoRaWAN
・SAML
・OpenID Connect
・Zigbee（HTTPS 上で利用）
ID 連携

安全性評価

・代理認証
（暗号技術評価

近距離通信
・SAML

委員会への参考・Bluetooth（HTTPS 上で利用）意見とする）
・代理認証
・Bitcoin プロトコル
・Ethereum
仮想通貨

・WEP

・Hyperledger Fabric

無線通信・ブロックチェーン応

・WPA
・WPA2

用（証券決済/契約）
・NFC

設定／運用

・Felica
Zigbee

近距離通信・ISO/IEC14443

近距離通信

TypeA，TypeB
IC カードBluetooth・Felica【車内】CAN，CAN
FD，LIN，FlexRay【車外】DSRC，

実装／開発

・DKIM
ETC2.0
自動車

メール

・SPF★

【ハードウェア】
・DMARC★

EVITA【センサ】空気圧セン
サ、ミリ波レーダー

S/MIME を
制御システ

・PLC
利用したメール送信ム・SCADA
メール

19（メールへの署名）

・パスワードつき Zip を添付したメール送信・S/MIME を利用したメール送信（メールの暗号

・QUIC

化）

Web

・オンラインストレージサービス
OpenPGP を・HTTP/2★
利用したメール送信
・POP3
証明書

・CRL

失効管理

・OCSP

・SMTP
メール

・IMAP （－/over SSL/
with SASL)

・DNS
・メッセージングサービ
・DNSSEC
DNSス（SMS、Skype、（DANE,DPRIV を含
Slack、Line、･･･）
む）
・SNMP

設定／運用
NW 管理

設定／運用

・SIP★
リアルタイム通信

・NETCONF(VoIP 等)

・RTP★
・SRTP

・UPnP

・SMB
鍵管理

・KMIP

ファイル共有・CIFS・WebDAV・RADIUS（EAP-TLS
等の利用を含む）

・SFTP
ファイル転送・PAP★
・CHAPv2

・FTPS
・FTP★

ユーザ管理
・IEEE802.1X
・SSH
・LDAP★
リモート接続・RDP(kerberos)・telnet★

ユーザ管理

・PAP★

・IPsec-VPN

・CHAPv2

・TLS-VPN
VPN

・TESLA
ユーザ認証

・二要素認証・IPsec-VPN
・TLS-VPN

20

・Bitcoin プロトコル
・Ethereum・クライアント証明書
デバイス認・TPM を利用した認証

仮想通貨

・Hyperledger Fabric

証・ブロックチェーン応用

・ISO/IEC9798
設定／運用

設定／運用

（証券決済/契約）

・Apple MDM

・DRM

デバイス認
放送暗号

・MS ライセンス認証

・ARIB

証
・W-CDMA・PUF を利用した認証（STEP2）運用ガイドラインを作る価値がある／必要性が高いと判断したものを抽出
表 5 に挙げた暗号プロトコルのうち、運用ガイドラインを作る価値があるか／必要性が高いかを判断するために、以下の観点から整理を行った。その結果、「必要性」「目的・内容」「想定読者」の 3 点について明確に説明できるものを「運用ガイドラインを作る価値がある／必要性が高い」と判断・抽出し（表 3 内の網掛け部分）、より詳細な検討を加えた。
【必要性】
運用ガイドラインを作る価値／必要性を明確に示すことができるか（なぜ運用ガイドラインが必要なのか、あるいは運用ガイドラインがないとどのように困るのか）【目的・内容】
どのような目的・内容をもった運用ガイドラインを意図したものかを明確に示すことができるか（3.1 で挙げた目的の 1. ～4. のどれに当たるかが明確であるか）【想定読者】
その運用ガイドラインの想定読者を具体的に示すことができるか【課題】
ガイドラインを作るうえで問題となりそうな課題／注意しなければならない課題は何か【他組織のガイドライン等】
他組織が同種のガイドラインを作っていないか／作ろうとしていないか

【関連組織】
どのような他組織と連携していくのがよいか

表 6 に検討結果をまとめる。今後、暗号プロトコルに関する運用ガイドラインを作成していく
際には、表 6 に挙げたもののなかから優先的に取り上げていくことが望ましい。なお、「課題」には CRYPTREC が作成する運用ガイドラインの価値を高めるために考慮しなければならない
ポイントをまとめており、また「関連組織」には連携先として有効と期待される国内組織（国際
組織の日本支部を含む）を記した。活動計画の立案に当たっては、これらのポイントを踏まえた計画であることが望まれる。

21

なお、表 6 の「目的」列、及び「プロトコル名称」列の表記についての注意は次のとおりである。
「目的」の表記①・・・現在利用されている仕組みの中で安全ではない使われ方を排除し、安全性の底上げを図る（安全性評価を含む）②・・・利用者が理解しやすく、かつ採用しやすいベストプラクティスを示す③・・・普及が進んでいない安全な仕組みの普及・活用を促進させる④・・・政府、業界団体等が守るべき（半）強制的基準として示す（そうなるような環境整備を含む）「プロトコル名称」の表記
・「★」がついているプロトコルは暗号に直接関係がないものを指す
・具体的なプロトコル名称がわからないものについては規格やサービスの名称を示す

22

表 6 取りまとめ結果一覧
プロトコル
種類

No

対象

他組織が発行し
目的

内容

想定読者

必要性

課題

名称

関連組織
たガイドライン等
一般社団法

OpenID

・OpenID Connect は安全性が評価され・OpenID Connect は暗号プロトコルとていないため、CRYPTREC で安全性評いうよりは枠のようなもので、組み合わ価できるとよい。

せで安全性は当然変わる。

人 OpenID

OpenID
1

ID 連携①

Connect の安（議論せず）（議論せず）

ファウンデーConnect
全性評価

ション・ジャパ
ン

LoRa で利用
無線通信（議論せず）①（議論せず）（議論せず）（議論せず）（議論せず）（議論せず）

様を見ることができない。

ロトコルの安N

安全性・業界団体に加入していなければ、仕されているプ

LoRaWA
2

全性評価

評価
（暗号技

・Bitcoin

術評価

プロトコル

委員会

・

への参

Ethereum

考意見）・
ブロックチェー
・標準化が行われている最中であるた

Hyperledg
3

①

仮想通貨

ンの安全性評（議論せず）（議論せず）
め、時期尚早。

er Fabric
価
・ブロック
チェーン
応用（証
券決済/
契約）

23

・標準化が行われている最中である。
・規模が大きく CRYPTREC のリソースで対応できる範囲は限られる。
・プロトコルで挙がっているものを、より【車内】
細分化し優先順位を付ける必要があ
CAN，る。

・SAE j3061：

・自動車ベンダの協力が必要である。

Cybersecurity

・国内では自動車工業会（JAMA）と連

Guidebook for

携するか、二人三脚で進めないと作

Cyber-Physicalっても受け入れられない懸念あり。

Vehicle Systems

・自動車業界は、まず欧米の評価を・Cybersecurity

参考とするため、CRYPTREC がガイド

Best Practices forラインを作成する場合には自動車業

Modern Vehicles

界に受け入れてもらえるような工夫が- NHTSA必要である。

・Automotive

・DSRC,ETC2.0 のセキュリティを管理

Cybersecurity

するのは ITS-TEA であり、ガイドライ

Best Practices -ンを作成する場合、こことコンタクトすAuto ISACCAN FD，
LIN，
FlexRay【車外】

自動車の中でDSRC，利用されていETC2.0る暗号の実装・今後の自動運転車などを見据えた

実装／
開発

1

自動車ベンダ、

②

自動車
【ハードウ

ガイドライン

ェア】（検証方法含EVITA

む）

部品サプライヤ・JSAE

際、セキュリティに問題が発生した場

・JasPar

合、社会的に大きな問題となることが想定されるため。

【センサ】
空気圧セ
ンサ、ミリ
波レーダ
る必要があるかもしれない。
ー・SHE（Secure Hardware Extension）のように仕様が一般公開されないものに対して CRYPTREC がガイドラインを作るべきかは議論する必要がある。

24

・PLC、SCADA と挙げているがプロト
・制御システム・PLC

・制御系システムで利用されているソフ

コル名称ではない。プロトコルは沢山

トウエアに脆弱性が発見された場合は、あり、安全性を挙げるために色々なガ・JPCERT/CC の生命・身体や重要インフラおよび環境

イドラインを作る必要はあるが沢山ありガイドライン、参考へ直接影響を与える可能性があり、重過ぎて、まずどれから手を付けていい

資料

要な問題となりうる。

かわからない。他組織との連携も考え

JPCERT/CCの中で利用さ・SCADA
れている暗号制御シス
・

2

プロトコルのテム

https://www.

システム開発①②jpcert.or.jp/i

者、運用者

BACKnet,cs/

実装ガイドライ
OPC 等

・CSSC

ン
る必要がある。
・無線 LAN ビジネ
スガイドライン・Radius＋

・SP 800-48 Rev.

EAP の推奨

1 Guide to・RADIUS
（EAP-

む）

理

・PAP★

るのであれば RADIUS 認証を利用する）。

SIer、VPN を使・ユーザが「野良 AP」にアクセスしな

う企業よりのベ

Establishing

ICT 総研調べ)。

CHAPv2 の非

いように促すことも検討が必要。

ンダ
推奨

・SP 800-97ており、3,532 万人を突破している(（株）

・PAP、
・

Networks

・公衆無線 LAN 利用者が年々増加し

非推奨

・CHAPv2

Wirelessント（AP）の設置が増えていくため。
ーザ管理者）、①②

1
運用

象とする技術が変わる（企業向けにす者、運用者（ユCHAPv2）のユーザ管IEEE 802.11

た、オリンピックに向けて、アクセスポイ（PAP or設定／

・想定読者を誰にするかによって、対システム開発利用を含Securing Legacy

・無線 LAN 環境は利用者が多く、ま・Radius＋
TLS 等の・VPN のユーザ認証に使われている。

Wireless Robust

IEEE802.
・Radius の設

Security

定Networks: A

1X
Guide to IEEE
802.11i

25

総務省

・Active Directoryのセキュリティを保護するためのベス
ト プラクティス（MS）
・CRYPTREC で扱う内容であるのか
・攻撃に対する保・Active Directory をはじめとしてディレというと疑問、そしてプロトコルの設定

護のドメインコント

クトリサービスは企業の ID 管理として利として変更できるものはなく、全体的

ローラ（MS）

用されているが、特に標的型攻撃で侵に AD の安全性の設定やシステム設・PtH（Pass-the-

入される糸口となるケースが昨今急増し

設定／
ユーザ管

①②
理

Sheet （MS）

われている技術である。

定（MS, Oracle,

・主に Kerberos の設定ガイドになりそーザー管理(kerberos)

Papers and Data

・Windows の Active Directory は広く使

Kerberos の設

製品ベンダ

れる。

者、運用者（ユLDAP★

2Hash) White

ている。

LDAP＋

運用

各種 LDAP

計思想が含まれる内容となると考えらシステム開発IBM など）うである。

者）、SIer・『LDAP 認証と・組織内データのうち最も狙われやすい・LDAP に関わる認証方式としてAzure Multi-

情報であり、内部犯行やマルウエア発
Kerberos 以外の実装や運用に関してFactor動による中からの攻撃にも対処する必
調査する必要がある。

Authentication

要がある。
・Windows サーバの設定も含まれる。

Server』
・『RFC2251
Lightweight
Directory AccessProtocol (v3)』26

・（パスワードに関するガイドラインで・パスワード管・かつて RFC 化（RFC2289）されてい触れられているか

るが MD4 ベースであり脆弱である。

もしれないが、現それ以降の OTP は RFC4226

時点では OTP に

HMAC-BasedOTP，RFC6238 Time-

関するガイドライン

BasedOTP が標準化されているが利は見つけられず）

用状況は不明であり、Proprietary な

・医療システムのシステムもあると考えられる（＝調査不安全管理に関す

能）。

るガイドライン（厚・OTP 自体はプロトコルではない。

生労働省）

OTP の生成方法は本 WG の対象で・オンライン手続きはない。

におけるリスク評・クラウドやバンキングなどで二要素認理のガイドライ

銀行、オンラ証の利用が増加しているが適切に管理
ユーザ認・サービサー、

管理の一環とSIer、ID プロバ

して二要素認イダ

インゲームサ

できていないケースがある。

・二要素

3

①②
証

ン（パスワード

ービス企業、・金銭や証券だけでなく、ポイント・アイ

認証

SIer

テムの管理に利用されているため安全設定／

証を位置付け運用

る形）

なログイン環境が必要である。

価及び電子署名・
認証ガイドライン
4・クライアント・システム開発

・IoT 機器なども含め、ネットワーク接続

ント証明

証明書や

者、運用者

機器が大きく増える見込みの中、デバイ

・Proprietary なシステムが多く標準化

書

TPM を使ったスレベルでの認証は安全性確保のため文書はない可能性が高い。また仕様

・TPM を

実際のデバイ

極めて有効である。

の入手が困難かもしれない。

・TCG アライアン

利用した

ス認証のガイ

・広く利用されつつあるデバイス認証の・幅広い技術があるので、対象を絞る

ス発行の文書等

認証

ドライン

セキュリティを強化するため。

必要があるか。

・ISO/IEC9798

・ISO/IEC

・相互認証等

・利用が増えているが、適切な管理など

・「暗号プロトコル」に整理できない技

9798

の規格

に明るくない管理者が多い。

術も含まれる。

（ISO/IEC979

・社内もしくは組込み機器等でネットワ

デバイス

・クライア

認証

①②

TCG アライアンス

278）が定めていークに接続する機器が増え、IT 系と同るパラメータの様の対策を講じる際に、設計者、開発

選定方法や利者の指針になる文書があるとネットワー

用方法の具体クを構築する際に参考になる。

化、設計時の指針
・無線 LAN<危険回避> 対策のしおり・企業等での無・SP 800-48 Rev.
線 LAN の管理
1 Guide to者（企業で簡易・想定読者を誰にするかによって、対Securing Legacy

象とする技術が変わる（企業向けにすIEEE 802.11

るのであれば RADIUS 認証を利用す

Wirelessる）。

Networks

・ユーザが「野良 AP」にアクセスしな・SP 800-97

いように促すことも検討が必要。

Establishing

・発言力のある人が言うレベルになっ

Wireless Robustているのではないか。

Securityに無線 LAN を設定する人）

・3DS が WEP しか対応されていないこ

・一般家庭等でとなど利便性を考慮して脆弱な古いプの無線 LAN のロトコルが未だに利用されていると考え

・WEP の非推
・WEP
奨

設定／
5

無線通信

・WPA

①②
・WPA、WPA2

運用
・WPA2

利用者（一般家られる。それを排除する必要がある。

庭等で無線・無線 LAN の設置が増えているため。

の設定

総務省

LAN を利用する人）
Networks: A
・IoT で Wi-Fi
Guide to IEEEの利用者
802.11i
・無線 LAN ビジネ
スガイドライン（総28務省）
・一般家庭における無線 LAN のセ
キュリティに関する注意・dkim.jp リコメン
ド文書
・電子メールのセ
キュリティ
・標的型攻撃に対

設定／
6
運用

・DKIM

DMARC（SPF

メールサーバを・メール送信ドメインのなりすまし対策と・SPF★

と DKIM を含構築するシステして必要。

・DMARCむ）の設定/普ム開発者、運用・SPF、DKIM、DMARC を全て合わせて

★

及

者

使うことを普及すべき。

②③

メール

抗するための通信・JIPDEC

規格の標準化動・迷惑メール・ガイドラインを書くにあたっての課題

向に関する調査対策推進協

は特段ない。

結果

議会(事務・迷惑メール対策推進協議会、および・ 府省庁対策基

局：デ協)

迷惑メール対策委員会と同期を取っ

準策定のための・迷惑メールて、普及することが望ましい。

ガイドライン（平成対策委員会

28 年度版）(NISC)（事務局：

・フィッシング対策

IAJapan)

ガイドライン(フィッシング対策協議会)
・迷惑メール対策
ハンドブック 2016

29

（迷惑メール対策推進協議会）
・「有害情報対策
ポータルサイト－
迷惑メール対策編－」（迷惑メー
ル対策委員会）・SP 800-45
Version 2
Guidelines on
・メールのなりすまし対策として必要。
Electronic Mail
・現在未対応の Web メールやスマホの・ガイドラインを書くにあたっての課題

Securityは特段ない。

・SP 800-177

・Google の新システムでは秘密鍵をク

Trustworthy Emailラウド上で管理するようであり、これま・標的型攻撃に対でこの手のガイドラインでは想定して抗するための通信いなかった使われ方がなされることも規格の標準化動視野に入れる必要があるかもしれな向に関する調査い。

結果

メーラに対応を促したい（Office365 や

設定／
メール

S/MIME
メールサーバを運用を利用し構築するシステム開発者、運用

②③

7
送信

対策協議会

とに癖があり設定の方法がわかりにく

（メールへ
信者

・フィッシング

署名で）使われ始めているが、メーラご

定／普及者、メール送受・JIPDEC・なりすまし対策として S/MIME が（特にS/MIME の設

たメール

・総務省

Gmail は一部対応済）。

・IPA

い。

の署名）
・フィッシング対策として銀行や大手プ
ロバイダが S/MIME を導入する傾向に

・ 府省庁対策基ある。
準策定のためのガイドライン（平成28 年度版）(NISC)

30

・フィッシング対策
ガイドライン（フィッシング対策協議会）
・電子メールのセ
キュリティ（IPA）

・パスワー

・ガイドラインを書くにあたっての課題

ドつき Zipは特段ない。

・SP 800-45を添付し・オンラインストレージサービスは様々

Version 2あり、少々書きにくい面はある。

Guidelines on

・Google の新システムでは秘密鍵をクElectronic Mail

ラウド上で管理するようであり、これまSecurity

でこの手のガイドラインでは想定して・SP 800-177

いなかった使われ方がなされることもTrustworthy Email

視野に入れる必要があるかもしれな

・ 府省庁対策基い。

準策定のための・政府系向けのガイドラインでは、組ガイドライン（平成織間の暗号化のように、組織のどこか

28 年度版）(NISC)

ンストレー

で責任をもって、一旦、暗号化を外し

・電子メールのセ

ジサービて中を見る等を考慮したガイドライン

キュリティ（IPA）

ス

が必要となるかもしれない。

設定／
メール

・パスワード付

たメール

・メールの秘匿性を高めるため。

運用
き zip 添付メ

送信・パスワード付き zip ファイルのメール送
ールの排除

・S/MIME

メールサーバを信をやめることで、受信サイドの業務効・S/MIME のを利用し構築するシステ率の向上と受信サイドのセキュリティ強

①②
8

設定／普及

たメール

ム開発者、運用
化。

③
送信（メー

・オンラインス

者、メール送受・現在未対応の Web メールやスマホのルの暗号

トレージサー信者
メーラに対応を促したい（Office365 や化）

ビスの使い方Gmail は一部対応済）。

・オンライ

の解説

31

・JIPDEC

・SIer のほとんどが SSH を利用している
ため、SSH は必要。
・IoT でも SSH は広く利用されるため。
・IPsec や SSH のガイドラインはリファレ
・SSH サーバセキ

・企業等でサーンスとして出せれば役に立つ。

ュリティ設定ガイド

バにリモート接・Web ホスティングサービスでは SSH サ

Ver 1.0

続するシステムービスを開放しているケースもあり、想・telnet の非
設定／
運用

推奨

リモート接
・RDP

9

・他組織との連携（例．他組織で作成

ユーザにも拡大される可能性がある。

済みのガイドラインを取り込む）が必・パラメータが多い為、SSH サーバの設要。

ップ接続を行う・telnet★
・RDP の設定

定読者はエンジニアだけではなく一般
・リモートデスクト①②
・SSH の設定

続・SP 800-46 Rev.

運用者

・SSH

2 Guide to

日本シーサEnterpriseート協議会

Telework, Remote

システムを構築
定によっては非常に危険な状態になAccess, and Bring

しているシステる。特に特権ユーザのパスワードログイYour Own Device

ム管理者、運用
ンを可能にしている場合は注意が必(BYOD) Security

者
要。
・RDP は、クラウド上でも利用されていて、設定が悪いと世界中誰からも乗っ取られて利用される恐れがあるため。

32

3.2.

運用ガイドラインのアップデート方法に関連する検討
運用ガイドラインは、ガイドライン作成時の標準化状況や製品状況、利用環境や利用実績等を踏まえて、作成時における現実的かつ効果的な推奨設定や推奨基準を提示する
ものである。このことは、ある程度の時間が経過し、標準化状況や製品状況、利用環境
や利用実績等が変化すれば、運用ガイドラインの中身も陳腐化し、ガイドラインとしてふさわしくないものとなることを意味する。
このため、今後運用ガイドラインの整備を進めるにあたっては、単に運用ガイドラインを作るだけでなく、運用ガイドラインの質を維持するためにどのような方法でアップ
デートを行っていくかを検討しておく必要がある。そこで、活用委員会では、具体的な運用ガイドラインの例として「SSL/TLS 暗号設定ガイドライン」を取り上げ、アップデートの在り方の検討を行った。

一般的なアップデートの方向性について

見直しの期限を設定（定期的なアップデートの実施是非）について：
ガイドラインの内容自体のアップデート（内容をどのように改訂するか）とガイ
ドラインのステータス管理（アップデートを実施するか否かの判断）を切り分けて考える。具体的には、ステータス管理については定期的に行うが、内容の改訂を行う期限自体はあらかじめ決めておかない。
なお、ステータス管理ではアップデートを実施するか否かだけを決めることとし、実際の内容の改訂はアップデートすることが決まった後に実施する。



アップデート方法について：
毎回本体のアップデートを行うのではなく、注釈を加える程度であれば比較的負荷は掛からないため、必要に応じて注釈を後ろに付け加えていくやり方もある。
例えば 2～5 年経過して、注釈が溜まってきたら大きなバージョンアップをして、内容を大幅に改訂する。
また、緊急に対応すべき情報（補足情報）は、少なくとも運用ガイドラインと併せてインターネット上で入手できるようにすべき。本体と補足情報を合わせて同時に参照することにより対策を打つことができる。

「SSL/TLS 暗号設定ガイドライン」に関してのアップデートの方向性について

どこまでの内容をアップデートすべきか（次回アップデートの範囲）：
IETF では、RC4 の使用禁止、SSL3.0 の非推奨、TripleDES の非推奨等の RFCを発行しており、2015 年の「SSL/TLS 暗号設定ガイドライン」発行時とは劇的に状況が変わっている。実際、認定認証事業者が発行する証明書では SHA256 へ

33

の移行が完了し、パブリック証明書もほぼ SHA256 with RSA2048 ビットになっている。また、2015 年には問題になっていたフィーチャーフォンについてもキャリアが SHA1 証明書での接続はできないと注意喚起しているはずであるため、必ずしもセキュリティ例外型が必要とは言えなくなってきている。
したがって、早期に最新動向の反映、及びセキュリティ例外型の見直しまで含めて、内容の改訂を実施すべきである。
一方、各社の製品の設定は徐々に各社で作るようになっていくべきであるため、市販製品の暗号設定状況の調査結果及び Appendix に乗っている OSS 製品等の暗号設定状況については、ガイドラインから分離すべきである。また、各社の製品の設定例を各社で整備するようにアピールをすべきである。



セキュリティ例外型の利用を終了させる時期（EOL）の導入是非について：EOL を導入することで、EOL までは利用を容認すると誤解される恐れがあるた
め、セキュリティ例外型について EOL を導入すべきではない。また将来的には、現在の推奨セキュリティ型からセキュリティ例外型に移す必要がある設定が出てくる可能性を踏まえれば、セキュリティ例外型の枠を無くさないほうが望ましい。

3.3.

外部連携について運用ガイドラインの作成については、CRYPTREC 単独で作成するよりも関連する外部組織や業界団体等（以降、他組織等という）との連携を進めたほうがよいとの指摘があった。例えば、以下のような指摘である。


暗号プロトコル課題検討 WG の検討結果では、必要性が高いと認められた暗号プ
ロトコルはいずれも、外部組織や業界団体との連携するほうが、効果が高い運用
ガイドラインが作れると考えられる。



重点課題検討 TF での議論の中では、従来は民間が必要としていた情報と電子政府を作るうえで必要となる情報の方向性がほぼ一致していたが、現在はそうでないという指摘があった。



ベンダや業界団体等の意向をバランスよく取り入れつつ、セキュリティも担保す
ることが効果的なガイドラインとして評価される。

これらの指摘を踏まえ、来年度より開始する運用ガイドラインの作成にあたっては、
従来の WG 形式での作成に捕らわれずに柔軟な作成スタイルを考慮する。具体的には、運用ガイドラインの作成手段を次の 4 種類とし（図 3 参照）、作成するガイドラインのテーマによって、暗号技術活用委員会にて適切な作成手段を決定する。
1) CRYPTREC が単独で作成（2 種類）

34

CRYPTREC が他組織等と連携なしに単独で作成する。ただし、具体的な作成手段としては、従来の WG 形式のほか、スキルのある他組織等にアウトソーシングしてベースとなる素案を作成してもらい活用委員会で内容を確認・承認する形式も含める。
2) 他組織等と共同で作成
他組織等と共同で作成したものを活用委員会で確認・承認する形式である。
3) 他組織等で実施したものをベースに作成
他組織等がすでに作成したものをベースに委員会で確認し、適切なものであれば承認する形式。その際、他組織がすでに作成したものを参照したうえで、必要最小限の追記等を行う可能性がある。

3)の場合のイメージ
3) 他組織等が作成したものをベースに委員会で確認し、適切なものであれば承認する
他組織等で作成したものをベースに作成

外部組織等
委員会

CRYPTREC ○○ガイドライン○○については、■■団体が発行している△△ガイドライン
を参照すること。
なお、××の部分については◇◇を採用すること。
(CRYPTREC GL-xxx-yyy)

参照部分
修正部分

<■■団体>△△ガイドライン○○については、・・・・のように設定する(■■団体)

2)の場合のイメージ
ＷＧで自ら実施

他組織等と共同で作成○○ガイドラインＷＧ

他組織等

他組織等

1) CRYPTRECが単独で作成2) 他組織等と共同で作成したものを委員会で確認し、適切なものであれば承認する●◆ガイドライン●◆については、・・・・のように設定する(CRYPTREC, △◇団体)
CRYPTREC ●◆ガイドライン●◆については、・・・・のように設定する(CRYPTREC GL-zzz-www)※△◇団体との共著△◇団体 ●◆ガイドライン●◆については、・・・・のように設定する(△◇団体)

他組織等にアウトソーシング※CRYPTRECとの共著

図 3

作成手段の説明図

実際の運用ガイドラインの作成手段を決定するにあたっては、以下のポイントを重視
して判断を行う。


他組織等と連携するほうが有用性のある運用ガイドラインが作成できるか35

連携先の外部組織等が信頼できる組織・団体であるか

他組織等と連携することによって作業効率を上げることができるか（例えば作業スケジュール等）

4.

予算面やリソース面からの考慮

今後に向けて2017 年度は新たな運用ガイドラインを実際に作成していく方向で活動計画を検討する。具体的な対象の選定等については、2017 年度第一回暗号技術活用委員会にて決定する方向である。
また、SSL/TLS 暗号設定ガイドラインについては、2016 年度活動で出た意見を踏まえ、2017 年度にアップデートを行う計画とする予定である。

36

CRYPTREC Report 2016
(暗号技術活用委員会報告

CRYPTREC-RP-0003-2016)

不許複製 禁無断転載
発行日 2017年6月30日 第1版
発行者
・〒113-6591
東京都文京区本駒込二丁目28番8号
独立行政法人 情報処理推進機構（技術本部 セキュリティセンター 暗号グループ）
INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN
2-28-8 HONKOMAGOME, BUNKYO-KU
TOKYO, 113-6591 JAPAN・〒184-8795
東京都小金井市貫井北町四丁目2番1号
国立研究開発法人 情報通信研究機構（サイバーセキュリティ研究所 セキュリティ基盤研究室）
NATIONAL INSTITUTE OFINFORMATION AND COMMUNICATIONS TECHNOLOGY
4-2-1 NUKUI-KITAMACHI, KOGANEITOKYO, 184-8795 JAPAN