CRYPTREC MT-1021-2022
資料１

2022年度 第２回 暗号技術検討会
令 和 ５ 年 ３ 月 ３ ０ 日
９ ： ０ ０ ～ ０ ０ ： ０ ０
オ ン ラ イ ン 開 催

議事次第
１．開会
２．議事
(1) 2022年度暗号技術評価委員会 活動報告について【報告】(2) CRYPTREC暗号技術ガイドライン（耐量子計算機暗号）及び CRYPTREC暗号技術
ガイドライン（高機能暗号）について【承認】(3) 2022年度暗号技術活用委員会 活動報告について【報告】(4) 暗号鍵管理ガイダンスについて【承認】(5) 「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」（案）に対する意見募集に寄せられたご意見に対するデジタル庁、総務省
及び経済産業省の考え方（暗号技術検討会事務局案）並びにCRYPTREC暗号リストの改定版（暗号技術検討会事務局案）について【承認】(6) 2023年度暗号技術評価委員会活動計画 (案) について【承認】(7) 2023年度暗号技術活用委員会活動計画 (案) について【承認】(8) 暗号技術検討会 2022年度 報告書（案）について【承認】(9) その他
３．閉会

配付資料一覧
資料１
資料２
資料３－１
資料３－２
資料３－３
資料３－４
資料３－５
資料３－６
資料３－７
資料３－８
資料３ー９
資料４－１
資料４－２
資料４－３
資料４－４
資料５－１
資料５－２

議事次第・配付資料一覧
暗号技術検討会 開催要綱（構成員・オブザーバ名簿）
2022年度 暗号技術評価委員会 活動報告
監視状況報告2022年度暗号技術評価委員会 電子メールによる審議とその結果
2022年度暗号技術調査ワーキンググループ（耐量子計算機暗号）活動報告
CRYPTREC暗号技術ガイドライン (耐量子計算機暗号)
2022年度暗号技術調査ワーキンググループ（高機能暗号）活動報告
CRYPTREC暗号技術ガイドライン（高機能暗号）
軽量暗号に関する技術動向調査報告（外部評価）
CRYPTREC暗号技術ガイドライン（耐量子計算機暗号）及びCRYPTREC暗号技術ガイドライン（高機能暗号）について
2022年度 暗号技術活用委員会 活動報告
暗号鍵管理ガイダンスワーキンググループ活動報告
暗号鍵管理ガイダンス概要について
暗号鍵管理ガイダンス
CRYPTREC暗号リストの改定について「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号資料５－３
資料５－４
資料６
資料７
資料８

リスト）
」
（案）に対する意見募集に寄せられたご意見並びにそれらに対するデジタル庁、総務省及び経済産業省の考え方（暗号技術検討会事務局案）
CRYPTREC暗号リスト（改定版）（暗号技術検討会事務局案）
CRYPTREC暗号リスト（現行版）
2023年度暗号技術評価委員会活動計画 (案)
2023年度暗号技術活用委員会活動計画 (案)
暗号技術検討会 2022年度 報告書（案）
以上

資料２

「暗号技術検討会」開催要綱
１ 名

称
本検討会は「暗号技術検討会」（以下「検討会」という。）と称する。

２ 開催の趣旨・目的
検討会は、デジタル庁統括官、総務省サイバーセキュリティ統括官及び経済産業省商務情報政策局長が有識者の参集を求め、暗号技術の普及による情報セキュリティ対策の推進を図る観点から、専門家による意見等を聴取することにより、デジタル庁、総務省及び経済産業省における施策の検討に資することを目的として開催する。
３ 検討事項（１）CRYPTREC暗号リスト掲載暗号技術の監視（２）CRYPTREC暗号リスト掲載暗号技術の安全性及び信頼性確保のための調査・検討（３）CRYPTREC暗号リストの改定に関する調査・検討（４）CRYPTREC暗号リスト掲載暗号技術の普及促進及び暗号技術の利用促進・産業化に向けた取組の検討（５）その他、システム全体のセキュリティ確保のために必要となる活動の検討
等、暗号技術の評価及び利用に関すること
４ 構成等（１）検討会の構成は、別紙１のとおりとする。
（２）検討会には、座長１名を置く。
（３）座長は、構成員の互選により定める。
（４）座長は、検討会構成員の中から顧問及び座長代理を指名できる。
（５）構成員の任期は委嘱時に定めるものとし、再任を妨げないものとする。
５ 運営（１）座長は、検討会の議事を掌握する。
（２）座長が、緊急の理由によりやむを得ず不在となった場合、座長代理が座長に代わり議事を掌握する。
（３）関係する政府機関等で、座長が特に認めたものについては、オブザーバとして検討会に出席することができる。
（４）座長が必要と認めるときは、暗号技術の提案者、関連する利害関係者その他の参考人から意見を聴取することができる。

（５）座長は、検討会が調査する事項について特に専門的な調査を行う必要があると認めるときは、委員会等を置くことができる。
（６）座長は、必要があると認めるときは電子メールによる審議を行うことができる。なお、この審議を行った場合は、次の検討会において当該審議の結果を報告するものとする。
（７）その他検討会の運営に関し必要な事項は、座長が定めるところによる。
６ スケジュール
検討会は、年度内に１回以上開催する。
７ 開催方法検討会は、集合開催を原則とするが、必要に応じ、その一部又は全部をオンラインにより開催することができることとする。
８ 議事・資料等の取扱い
別紙２のとおりとする。
９ 庶

務
検討会の庶務は、デジタル庁デジタル社会共通機能グループ、総務省サイバ
ーセキュリティ統括官室及び経済産業省商務情報政策局サイバーセキュリ
ティ課において処理する。

（令和４年３月３０日

最終改訂）

別紙１
暗号技術検討会

構成員・オブザーバ名簿
2023.3.30現在

構成員
阿部 正幸
石井 義則
上原哲太郎
太田 和夫
高木
剛
田村 裕子
近澤
武
手塚
悟
本間 尚文
松井
充
松浦 幹太
松本
勉
松本
泰
向山 友也
吉田 博隆

渡邊

創

日本電信電話株式会社 社会情報研究所 上席特別研究員
一般社団法人情報通信ネットワーク産業協会 常務理事
立命館大学 情報理工学部 教授
国立大学法人電気通信大学 名誉教授
国立大学法人東京大学大学院 情報理工学系研究科 教授
日本銀行 金融研究所 企画役
三菱電機株式会社 情報技術総合研究所 開発戦略部 担当部長
慶應義塾大学 環境情報学部 教授
国立大学法人東北大学 電気通信研究所 教授
三菱電機株式会社 開発本部 役員技監
国立大学法人東京大学 生産技術研究所 教授
国立大学法人横浜国立大学大学院 環境情報研究院 教授
セコム株式会社 IS研究所 顧問
一般社団法人テレコムサービス協会 技術・サービス委員会 副委員長
国立研究開発法人産業技術総合研究所
サイバーフィジカルセキュリティ研究センター
セキュリティ保証スキーム研究チーム 研究チーム長
国立研究開発法人産業技術総合研究所
サイバーフィジカルセキュリティ研究センター 副研究センター長（五十音順、敬称略）

オブザーバ
内閣官房内閣サイバーセキュリティセンター 内閣参事官（政府機関総合対策担当）
個人情報保護委員会事務局 参事官
警察庁 情報通信局 情報管理課 情報セキュリティ対策官
総務省 自治行政局 住民制度課長
総務省 自治行政局 住民制度課 マイナンバー制度支援室長
法務省 民事局 商事課長
外務省 大臣官房 情報通信課長
財務省 大臣官房 文書課 業務企画室長
文部科学省 大臣官房 政策課 サイバーセキュリティ・情報化推進室長
厚生労働省 大臣官房参事官（サイバーセキュリティ・情報システム管理担当）
経済産業省 産業技術環境局 国際電気標準課長
防衛省 整備計画局 情報通信課 AI・サイバーセキュリティ推進室長
国立研究開発法人情報通信研究機構 サイバーセキュリティ研究所長
国立研究開発法人産業技術総合研究所 サイバーフィジカルセキュリティ研究センター 高機能暗号研究チーム長
独立行政法人情報処理推進機構
技術本部セキュリティセンター長
一般財団法人日本情報経済社会推進協会 デジタルトラスト評価センター長
公益財団法人金融情報システムセンター 監査安全部長

別紙２
暗号技術検討会の公開について

１ 会議の公開について（１）民間企業の暗号技術（既製品を含む）の解読方法等について議論を行う
可能性があり、当事者又は第三者の権利、利益や公共の利益を害するおそれがあるため、検討会は原則非公開とする。
（２）検討会の出席者は、検討会において知り得た情報で、当事者又は第三者の権利、利益や公共の利益を害するおそれがあるものについては、検討会の出席者及び座長が特に認めた者以外に漏えいしてはならないものとする。
２ 検討会の資料の公開について（１）検討会の資料については、原則公開とする。
（２）ただし、検討会の資料を公開することにより、当事者又は第三者の権利、利益や公共の利益を害するおそれがある場合は、検討会は資料の公開を延期又は非公開とすることができる。
（３）資料は、ホームページ（cryptrec.go.jp）への掲載その他の方法により公開するものとする。
３ 議事概要の公開について（１）議事概要については、原則公開とする。
（２）ただし、議事概要を公開することにより、当事者又は第三者の権利、利益や公共の利益を害するおそれがある場合は、議事概要の該当部分を削除した上で公開することができる。
（３）議事概要は、ホームページ（cryptrec.go.jp）への掲載その他の方法により公開するものとする。

資料３―１2022 年度暗号技術評価委員会活動報告
1. 活動目的
CRYPTREC 暗号リストに掲載されている暗号技術や電子政府システム等で利用される暗号技術の安全性維持及び信頼性確保のために安全性及び実装に係る監視及び評価を行う。

2. 活動概要(1) 暗号技術の安全性及び実装に係る監視及び評価
下記の通り、暗号技術の安全性に係る監視・評価 及び 実装に係る技術の監視・評価を実施する。
① CRYPTREC 暗号等の監視
国際会議等で発表される CRYPTREC 暗号リストの安全性及び実装に係る技術（暗号モジュールに対する攻撃とその対策も含む）に関する監視を行い、会議や ML を通して報告する。


今年度時点では、電子政府推奨暗号リストの安全性に懸念を持たせるよ
うな事態は生じていない。今年度実施の監視報告の詳細については、
CRYPTREC Report 2022 で報告する。
（資料３－２参照）

ECDSA 及び ECDH については、現状通り、当該暗号技術を電子政府推奨暗号リストに記載しておくことは妥当であると判断した。SC2000 について
は、応募社の判断を尊重し、取り下げを認め、当該暗号技術を推奨候補暗号リストから削除することは妥当であると判断した。
（資料３－３参照）② 電子政府推奨暗号リストからの運用監視暗号リストへの降格、並びに、推奨候補
暗号リスト及び運用監視暗号リストからの危殆化が進んだ暗号の削除
CRYPTREC 暗号リストの安全性に係る監視活動を継続的に行い、急速に危殆化が進んだ暗号技術やその予兆のある暗号技術の安全性について評価を行う。
また、リストからの降格や削除、注釈の改訂が必要か検討を行う。


降格や削除が必要となる暗号技術は無かった。

③ CRYPTREC 注意喚起レポートの発行
CRYPTREC 暗号リストの安全性及び実装に係る技術の監視活動を通じて、国際会議等で発表された攻撃等の概要や想定される影響範囲、対処方法について

早期に公開することが望ましいと判断された場合、注意喚起レポートを発行する。


注意喚起レポートの発行を要する事案は発生しなかった。

④ 推奨候補暗号リストへの新規暗号（事務局選出）の追加
標準化動向に鑑み電子政府システム等での利用が見込まれると判断される暗号技術の追加を検討する。


追加が必要となる暗号技術は無かった。

⑤ 新技術等に関する調査及び評価
将来的に有用になると考えられる技術やリストに関わる技術について、安全性・性能評価を行う。必要に応じて、暗号技術調査ワーキンググループによる調査・評価、または、外部評価による安全性・性能評価などを行う。


2021 年度から継続して耐量子計算機暗号に関するワーキンググループを設置し、耐量子計算機暗号に関するガイドラインを作成し、「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図を更新した。


暗号技術調査ワーキンググループ（耐量子計算機暗号）を開催し、2021 年度に決定した執筆方針及び目次案に沿ってガイドラインの案及び調査報告書の案を作成した。特に、耐量子計算機暗号の中で今後の利用が見込まれる暗号方式について議論し、それらを選択してガイドラインに記載した。また、近年に脆弱性が発見された世界標準の有力候補の暗号方式とその脆弱性については調査報告書の案にまとめた。



同ワーキンググループを開催し、2020 年度に決定した「今後の予測図の取り扱い」の説明を読みやすく修正し、これに基づいて「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新を行った。
（資料３‐４）、（資料３‐５）

 高機能暗号に関するガイドラインを作成するため、2021 年度に引き続き、高機能暗号に関するワーキンググループを設置する。


暗号技術調査ワーキンググループ(高機能暗号)を開催し 2021 年度に決定した目次案に沿って、高機能暗号ガイドラインの案を作成した。執筆に際し、専門性の高い新規委員に依頼し、技術、応用、標準化等の内容を精査した。また、高機能暗号の応用事例に関するヒアリングを日本電気株式会社、三菱電機株式会社に対して行い、その内容をガイドラインの案に反映した。
（資料３‐６）、（資料３‐７）
 2016 年度に NICT 及び IPA が策定・公表した「CRYPTREC 暗号技術ガイドライン(軽量暗号)」の更新のため、2022 年度は、NIST Lightweight コンペティションファイナリストを主な対象とした安全性および実装性能などに関わる調査・評価を行う。



NIST Lightweight Cryptography Project のファイナリスト 10 方式を対象とした安全性評価及び実装性能評価を外部評価により実施した。なお、
安全性評価に関しては、上記 10 方式に加え、ISO/IEC 標準規格として29192 シリーズで規格化された軽量メッセージ認証コードの 1 つである
Tsudik's keymode も対象とした。また、軽量暗号に関わる NIST 公開文
書や ISO/IEC などの標準化動向調査も外部評価により実施した。
(資料３‐８参照）
なお、来年度は、2021 年度第 2 回暗号技術評価委員会において承認された更新方針に従い、事務局によりガイドラインの更新案を編集し、ドラフト版について外部有識者にガイドラインとして掲載内容の適切性や情報の過不足などについてレビュー頂き、完成版を 2023 年度第 2 回暗号技術評価委員会にて審議する予定である。

(2) 暗号技術の安全な利用方法に関する調査（技術ガイドラインの整備、学術的な安全性の調査・公表等）
暗号技術を利用する際の技術面での注意点に関する調査、新技術の安全性・性能に関する調査・評価を行う。

3.活動スケジュール
暗号技術評価委員会は、下の表のとおり 2 回開催した。
回

開催日

メール
2022 年 6 月 1－7 日
審議

議案



暗号技術調査ワーキンググループ（高機能暗号）の活動計画案の審議



暗号技術評価委員会活動計画の具体的な進め方についての審議
暗号技術調査ワーキンググループ（耐

第 1 回 2022 年 7 月 26 日



量子計算機暗号）の活動計画案の審議
暗号技術調査ワーキンググループ（高機能暗号）の活動計画案の報告
外部評価（軽量暗号に関するガイドラ
イン係る技術動向調査）実施についての審議
監視状況報告メール 2023 年 1 月 30 日－2 月 10 
審議 日

自主取下げに係る電子メールによる審議

自主取下げに係る電子メールによる審議内容と結果の報告
暗号技術調査ワーキンググループ（耐
量子計算機暗号）の活動内容の報告
暗号技術調査ワーキンググループ（高機能暗号）の活動内容の報告
軽量暗号ガイドラインに係る技術動向
調査結果の報告
監視状況報告CRYPTREC Report 2022 作成について
CRYPTREC シンポジウム開催について






第 2 回 2023 月 2 月 27 日






以上

暗号技術評価委員会委員名簿（五十音順、敬称略）
委員長

高木

剛

東京大学 教授

委員青木 和麻呂文教大学 准教授

委員

岩田

哲

名古屋大学 准教授

委員

上原

哲太郎

立命館大学 教授

委員

大東

俊博

東海大学 准教授

委員

國廣

昇

筑波大学 教授

委員

四方

順司

横浜国立大学 教授

委員

手塚

悟

慶應義塾大学 教授

委員

花岡

悟一郎

国立研究開発法人産業技術総合研究所
サイバーフィジカル研究センター 首席研究員

委員

藤﨑

英一郎

北陸先端科学技術大学院大学 教授

委員

本間

尚文

東北大学 教授委員

松本勉

横浜国立大学 教授

委員

松本

泰

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

委員

山村

明弘

秋田大学 教授

資料３－２

監視状況報告1. 監視活動報告
2021 年度第二回暗号技術評価委員会（2022 年 2 月 26 日）から 2022 年度第二回暗号技術評価委員会（2023 年 2 月 27 日）までに、表 1 に示す国際会議に参加するとともに各種調査を行い、暗号解読技術等に関する研究動向を収集した。

Eurocrypt 2022

Crypto 2022

表 1 国際会議への参加状況
学会名・会議名
開催国・都市The 41st Annual International(Virtual
Conference on the Theory andConference)
Applications of Cryptographic
Techniques
The 42nd Annual International(Virtual
Cryptology Conference
Conference)

PQCrypto 2022

Post-Quantum Cryptography
The 13th International Workshop(Virtual
Conference)

TCC2022

Theory of Cryptography
The 20th International
Conference
Fourth PQC Standardization
Conference(in-person)

The 28th International
Conference on the Theory andApplication of Cryptology andInformation Security(Virtual
Conference)

NIST 4thStandardizationAsiacrypt 2022

(Virtual
Conference)

期間2022 年 5 月
30 日～6 月
3日
2022 年 8 月
13 日～8 月
18 日
2022 年 9 月
28 日～9 月
30 日
2022 年 11
月 7 日～11
月 10 日2022 年 11月 29 日～
12 月 1 日
2022 年 12
月 5 日～12月9日

2. 解読技術等の動向
各国際会議における報告等より、具体的な暗号の攻撃に関する発表を抽出し、CRYPTREC 暗号リスト記載の暗号の安全性に直接関わる技術動向（2.1）およびその他の注視すべき技術動向（2.2）について分析を行った。

2.1. CRYPTREC 暗号リスト記載の暗号に直接関わる解読技術動向
CRYPTREC 暗号リスト（電子政府推奨暗号リスト）掲載の暗号に関して報告する。
AES については、AsiaCrypt 2022 にて、ブーメラン攻撃の計算量の更新が発表された。また同学会で、AES の量子回路実装の最適化がなされており、今後の量子計算機による AES 解析に応用が期待されている。

またストリーム暗号の ChaCha についての攻撃論文も 3 件報告された（CRYPTO2022、
Eurocrypt 2022、Asiacrypt 2022）。特に Eurocrypt 2022 にて、6 ラウンドの ChaCha128 に対する攻撃について大きな更新が見られた。
RSA については、CRT-RSA に対して、部分的に鍵が公開された場合の素因数分解である、
部分的鍵公開攻撃（Partial Key Exposure attack）が、Eurocrypt 2022 と AsiaCrypt 2022
で 2 件発表された。Eurocrypt 2022 では純粋な CRT-RSA に対して、AsiaCrypt 2022 では指数ブラインディングされた場合に対して、それぞれ新たな攻撃が報告された。
また、SHAKE128 の 6 ラウンドに対する衝突攻撃が、AsiaCrypt 2022 で発表された。同論
文では、量子的な設定の下での衝突攻撃が、SHA3-224 と SHA3-256 の 6 ラウンドに対しても行われている。

いずれも、現実的な脅威となるには至っていないが、今後動向を注視すべきである。

2.1.1. 共通鍵暗号に関する解読技術･Revisiting Related-Key Boomerang attacks on AES using computer-aided tool
[Asiacrypt 2022]

Patrick Derbez, Marie Euler, Pierre-Alain Fouque, Phuong Hoa Nguyen
近年、ブロック暗号のブーメラン識別器やブーメラン攻撃を自動的に探索するために、いくつかの MILP モデルが導入されている。しかし、それらは鍵スケジュールが線形である場合にのみ使用可能である。ここでは、AES のような非線形の鍵スケジュールに対して、新しいモデルを導入する。このモデルはより複雑であり、網羅的な探索には時間がかかりすぎる。しかしながら、ソルバにいくつかのヒントを追加することで、時間計
算量 2124、データ計算量 2124、メモリ計算量 279.8 で AES-192 に対する現在最高の関連鍵
ブーメラン攻撃を発見した。これは、ASIACRYPT 2009 で Biryukov と Hovratovich による攻撃の計算量（それぞれ 2176、2123、2152）より優れている。特に時間計算量とメモリ計
算量において大きな改善を与え、暗号解読における MILP の威力が示された。
･Synthesizing Quantum Circuits of AES with Lower T-depth and Less Qubits[Asiacrypt 2022]

Zhenyu Huang, Siwei Sun
量子アルゴリズムによる暗号解読に必要な資源を正確に見積もるためには、量子アルゴリズムを基本的な量子ゲートで構成される量子回路に帰着する必要がある。本研究では、Grover と Simon のアルゴリズムに基づく量子攻撃でよく用いられる反復型共通鍵暗号の量子オラクルを実装する回路について、いくつかの汎用的な合成技術と最適化技術が提案された。まず、ブロック暗号のラウンド関数を in-place に実装するための一般的な構造を提2案する。次に、線形および非線形な暗号構成要素の効率的な量子回路を合成するための新しい技術が導入される。これらの技術を AES に適用し、深さ-幅のトレードオフ（depth-widthtradeoff）の戦略が系統的に調べられる。その過程で、AES の S-box の古典的回路に関する新しい知見に基づいて、証明可能な最小の T-depth を持つ量子回路が導出されている。その
結果、AES の量子回路の実装に必要な T-depth と幅（量子ビット数）が大幅に削減された。
著者らの回路と EUROCRYPT 2020 で提案された回路と比較すると、幅を増やさずに T-depth
を 60 から 40 に、あるいは幅をわずかに増やして 30 に減らすことに成功している。これらの回路は、Microsoft Q#で実装されており、ソースコードも公開されている。ASIACRYPT 2020で提案された回路と比較すると、著者ら回路の 1 つは幅が 512 から 371 に減少し、同時にToffoli-depth が 2016 から 1558 に減少していることが確認されている。また実際、深さを増やす代わりに、幅を 270 に減らすことができる。さらに、深さと幅のトレードオフの全範囲が提供され、AES の量子回路の合成と最適化における新記録も樹立されている。

･Revamped Differential-Linear Cryptanalysis on Reduced Round ChaCha [Eurocrypt2022]

Sabyasachi Dey, Hirendra Kumar Garai, Santanu Sarkar, Nitin Kumar Sharma
本論文では、ChaCha に対する既存の差分線形攻撃に対するいくつかの改良点を提供する。ChaCha は 20 ラウンドを持つストリーム暗号である。CRYPTO 2020 において、Beierle らは正しいペアを選択した場合、3.5 ラウンド目に差分が発生することを観測している。彼らはこれを用いて改良した攻撃を行ったが、正しいペアを実現するためには平均で 25 回の繰り返しが必要であることを示した。
この方向で、リスト化（listing）の助けを借りて、正しいペアを見つける技術を提供する。また、PNB 構築の戦略的改善、計算量見積の修正、2 つの入出力ペアを用いた代替攻撃法も提供する。これらを用いて、時間計算量を改善し、Beierle らが 256 ビット版の ChaCha で報告した 2230.86 から 2221.95 に減少させることに成功した。また、10 年ぶ
りに 6 ラウンドの 128 ビット版 ChaCha に対する既存の計算量（Shi et al: ICISC 2012）を 1100 万倍以上改善し、6.5 ラウンド ChaCha128 に対する史上初の攻撃で時間計算量
2123.04 を実現した。
･Rotational Differential-Linear Distinguishers of ARX Ciphers with Arbitrary
Output Linear Masks [CRYPTO 2022]

Zhongfeng Niu, Siwei Sun, Yunwen Liu, Chao Li
EUROCRYPT 2021 で提案された回転差分線形攻撃は、差分線形攻撃の差分部分を回転差分に置き換えて一般化したものである。EUROCRYPT 2021 では、Liu らが Morawiecki
らの手法（FSE 2013）に基づき、出力線形マスクが単位ベクトルである特殊なケースについて、回転微分線形相関を評価する方法を発表した。この手法により、Friet、Xoodoo、3Alzette に対して、出力線形マスクが単位ベクトルである強力な（回転）微分線形識別器がいくつか発見された。しかし、任意の出力マスクに対する回転微分線形相関をどのように計算するかは未解決であった。
本研究では、この未解決問題の一部を解決している。任意の出力線形マスクに対するモジュロ加算の（回転）微分線形相関を計算する効率的なアルゴリズムを提示し、それを基に ARX 暗号の（回転）
微分線形相関を評価する手法が導出された。本技術を Alzette、
SipHash、Chacha、Speck に適用した結果、決定論的なものを含め、大幅に改善された（回転）微分線形識別器が確認された。本研究の成果は全て実用的であり、実験的に検証され、手法の有効性が確認された。さらに、FSE2008、FSE2016、CRYPTO2020 で採用された ChaCha に対する実験的な識別器を説明することを試みている。予測された相関は実験的な相関に近いものであった。
･Latin Dances Reloaded: Improved Cryptanalysis against Salsa and ChaCha, andthe proposal of Forró [Asiacrypt 2022]

Murilo Coutinho, Iago Passos, Juan Grados, Fábio de Mendonça, Rafael Timóteo,Fábio Borges
本論文では、ARX 暗号、特にストリーム暗号の Salsa/ChaCha ファミリに対する 4 つの主要な貢献を紹介する。
(a) ChaCha に対する差分-線形識別器を改善した。このために、アルゴリズムをより単純なサブラウンドの観点から見ることによって、線形近似の導出にアプローチする新
しい方法が提案されている。このアイデアを用いて、3 つの単純なルールから、過去の研究から得られる全ての線形近似を導き出すことが可能であることを示した。さらに、
もう 1 つのルールを追加することで、Eurocrypt 2021 で Coutinho と Souza が提案した線形近似を改善できることを示す。
(b) Salsa に対する攻撃を改善するため、双方向線形展開（Bidirectional Linear
Expansions、BLE）と呼ばれる技術を提案する。これまでの研究では、ラウンドに前進する線形拡張のみを検討していたが、BLE では 1 ビットを前進と後退の両方向に拡張することが検討されている。
(c) これらの暗号の暗号解析の研究から得られた全ての知識を用いて、ラウンドごとの拡散と暗号解析への耐性を向上させるためのいくつかの修正を提案し、新しいストリーム暗号 Forró を完成させた。これにより、安全性を維持したままラウンド数を減らすことができ、多くのプラットフォーム、特に制約のあるデバイスにおいて、より高速な暗号を実現することができるとしている。
(d) さ らに 著 者 ら は、 GPU を 用い た 高 い パフ ォ ー マ ン ス 環 境 で使用 可 能 な 、CryptDances という、Salsa、ChaCha、Forró の暗号解析ツールを開発している。
CryptDances では、差分相関の計算、ChaCha の新しい線形近似の自動導出、PNB 攻撃の

4

計 算 量 の 見 積 の 自 動 化 な ど が 可 能 に な っ て い る 。 CryptDances はhttps://github.com/MurCoutinho/cryptDances で利用可能である。

2.1.2. 公開鍵暗号に関する解読技術･Approximate Divisor Multiples - Factoring with Only a Third of the Secret
CRT-Exponents [Eurocrypt 2022]

Alexander May, Julian Nowakowski, Santanu Sarkar
本論文は、CRT-RSA の秘密指数𝑑𝑝 , 𝑑𝑞 で、公開指数𝑒が小さい場合の部分鍵公開攻撃について研究している。𝑒が定数である場合、𝑑𝑝 , 𝑑𝑞 のうち 1 つのビットの半分を知ること
で、Coppersmith の有名な「factoring with a hint」の結果によって RSA 剰余𝑁を因子分解できることが知られている。この設定を𝑒が定数でない場合に拡張する。
少し意外な結論として、𝑒のサイズが 𝑁1/12 である RSA が部分鍵公開攻撃に対して最も弱いということが、本論文の攻撃によって示された。これは、最上位ビット（MSB）
または最下位ビット（LSB）のいずれかを含む𝑑𝑝 , 𝑑𝑞 の両ビットの 3 分の 1 があれば、多項式時間で𝑁を因数分解できるためである。
𝑒𝑑𝑝 = 1 + 𝑘(𝑝 − 1), 𝑒𝑑𝑞 = 1 + ℓ(𝑞 − 1)とせよ。技術的には、著者らは𝑁の素因数
分解を二つの新しいアプローチで求めている。第一のステップでは、𝑘とℓを多項式時間で復元する。これは、MSB の場合は完全に初等的に、LSB の場合は Coppersmith の格子に基づく方法を用いて実現される。これにより、求められた𝑘を用いて、𝑘𝑝を法とする
一変数多項式の根を計算することで、𝑁の素因数分解を得ることができる。これは、Howgrave-Graham の approximate divisor アルゴリズムの、𝑁の未知の約数𝑝の既知の倍数𝑘に対する approximate divisor multiples の場合への拡張と見なすことができる。
approximate divisor multiples のポイントは、多項式時間で復元可能な未知数が、倍数𝑘の大きさに対して線形に増加することである。
この部分鍵公開攻撃は、MSB がわかっている場合は厳密である一方、LSB の場合は標準的な Coppersmith タイプのヒューリスティックに依存する。このヒューリスティックを実験的に検証することにより、実際には小さな格子寸法で既に漸近的な境界値に到達することを示すことで、この部分鍵公開攻撃の実用性も示されている。
･A Third is All You Need: Extended Partial Key Exposure Attack on CRT-RSA withAdditive Exponent Blinding [Asiacrypt 2022]

Yuanyuan Zhou, Joop van de Pol, Yu Yu, François-Xavier Standaert
Eurocrypt 2022 において、May らは CRT-RSA に対する部分鍵公開（PKE）攻撃を提案
し、公開指数𝑒のサイズが𝑁1/12の場合の、秘密指数𝑑𝑝 および𝑑𝑞 の最上位ビットら（MSBs）の 1/3、または最下位ビットら（LSBs）の 1/3 どちらかだけを知って、𝑁を効

5

率よく素因数分解した。実際には、PKE 攻撃はこれらの指数のサイドチャネル漏洩に依存している。CRT-RSA のサイドチャネル耐性実装では、未知のランダムなブラインド係数𝑟𝑝 ,𝑟𝑞 における加法的なブラインド指数𝑑𝑝′ = 𝑑𝑝 + 𝑟𝑝 (𝑝 − 1), 𝑑𝑞′ = 𝑑𝑞 +𝑟𝑞 (𝑞 − 1)を用いているため、PKE 攻撃はより困難なものになることが多い。
以上のことの背景に、本論文は、May らの PKE 攻撃を加法的なブラインド指数の CRTRSA に拡張している。この場合、ブラインドされた CRT 指数 𝑑𝑝𝜋 と 𝑑𝑞𝜋 の既知の MSB ま
たは LSB のみを使用して秘密鍵全体を復元することができる。設定上では𝑟𝑝 𝑒 ∈ (0, 𝑁1/4 )を許容するが、著者らが拡張した PKE 攻撃は、𝑟𝑝 𝑒 ≈ 𝑁1/12 の時理想的に働く。このケースでは、ブラインドされた CRT 指数 𝑑𝑝′ と 𝑑𝑞′ の MSB もしくは LSB の 1/3 から全ての秘密鍵が復元可能である。著者らの拡張した PKE 攻撃は、May らによる以下の 2 ステップのアプローチに準拠している：第一ステップで鍵に依存する定数 𝑘′ (𝑒𝑑𝑝′ = 1 +𝑘 ′ (𝑝 − 1), 𝑒𝑑𝑞′ = 1 + 𝑙′(𝑞 − 1) ) を計算し、第二ステップで 𝑘′𝑝 を法とする一変数多項式の根を計算することで𝑁を素因数分解する。本論文では、この手法を以下のように拡張している。MSB の場合では、第一ステップにおいて、𝑘′𝑙′の値を一つ推定した後𝑘′を因数分解により計算する方法と、𝑘 ′ 𝑙1′ , … , 𝑘 ′ 𝑙𝑧′ という複数の推定値から𝑘′を GCD により確率的に計算するという、2 つのオプションを提案している。LSB の場合では、第二ステッ
プで現れる差分一変数多項式を構成するアプローチが拡張されている。形式的な分析によって、本手法における LSB 攻撃は通常の Coppersmith タイプの仮定の下、多項式時間で機能することがわかっている。一方、本手法における MSB 攻撃は、簡約された入力サイズに対し劣指数時間を要する（問題が𝑒 2 𝑟𝑝 𝑟𝑞 ≈ 𝑁1/6 のサイズの素因数分解に帰着される）か、新しいヒューリスティックな仮定の下で確率的多項式時間で機能する。最も一
般的な鍵サイズ（1024 ビット、2048 ビット、3072 ビット）とブラインド因数のサイズ（32 ビット、64 ビット、128 ビット）の設定の下で、著者らの実験を行い、このCoppersmith タイプの仮定と、彼らの新たなヒューリスティックな仮定の両方が尤もらしい事を確認している。
以上の攻撃は、128 ビットのブラインド指数が存在する場合の CRT-RSA に対して、初めて実験的な有効性が確認された PKE 攻撃であると著者らは主張している。さらに、Montgomery Ladder 指数 CRT 実装を対象としたリアルなサイドチャネル部分鍵漏洩に対して、提案された攻撃の応用実験も行っている。

2.1.3. ハッシュ関数に関する解読技術･Exploring SAT for Cryptanalysis: (Quantum) Collision Attacks against 6-Round
SHA-3 [Asiacrypt 2022]

Jian Guo, Guozhen Liu, Ling Song, Yi Tu

6

本研究では、古典的および量子的な設定における SHA-3 ハッシュ族のインスタンスに対する衝突攻撃に焦点を当てる。JoC 2020 で Guo らが提案した SHA3-256 および他の変種に対する 5 ラウンドの衝突攻撃以来、他に本質的な進展は発表されていない。徹底的な調査により、このような SHA-3 への衝突攻撃をより多くのラウンドに拡張することの課題は、差分トレイル探索の非効率性にあることが突き止められた。
この障害を克服するために、本論文の著者らは、SAT ベースの自動探索ツールキットを開発した。このツールは衝突攻撃の複数の中間ステップで使用され、その過程で遭遇する差分トレイル探索やその他の最適化問題において高い効率性を示しているとされる。その結果、6 ラウンド SHAKE128 に対する古典衝突攻撃、量子衝突攻撃、SHA3-224 とSHA3-256 に対する 6 ラウンド量子衝突攻撃が発表された。時間計算量はそれぞれ、2123.5 、267.25 /√𝑆、297.75 /√𝑆、2104.25 /√𝑆である（𝑆は量子コンピュータのハードウェア
リソースを表す）。6 ラウンドの SHA3-224 と SHA3-256 に古典衝突攻撃が適用されない
ことは、量子衝突攻撃のカバー率が高いことを示していて、CRYPTO 2021 で Hosoyamadaと Sasaki が観測した SHA-2 に対するものと一致すると、著者らは指摘している。

2.2. その他の注視すべき技術動向
CRYPTREC 暗号リストの対象ではないが、特に NIST の耐量子計算機暗号の標準化に関して、いくつかの報告がなされた。
2023 年 2 月現在、耐量子計算機暗号として、CRYSTALS-KYBER、CRYSTALS-DILITHIUM、FALCON、
SPHINCS+が標準化方式として既に選出されている。他候補を選別中の Round 4 において、同種写像を用いた KEM である SIKE が、セキュアではないということが、SIKE チームから発表された。これは、Castryck と Decru によりクリティカルな攻撃論文が、プレプリントとして発表されたためである。この攻撃によって、同種写像ベースの暗号形式である SIDH、SIKE、
B-SIDH、SIOT はセキュアではないことが判明している。
その一方、
SIDH 署名、CSIDH、
SeaSign、
CSI-FiSH、OSIDH、SQISign はまだ攻撃が発表されてはいない。これについては、今後の情勢を注視する必要がある。
また、Rainbow に対して、NIST が設定している安全性レベル 1 のパラメータ設定に対して、2.5 GHz の PC で約 53 時間で攻撃が可能であるという報告が、CRYPTO2022、PQCrypto2022 両方で発表された。
その他、共通鍵暗号などについても複数の攻撃が報告されている。より詳しくは、使用される機会が多いか今後多くなると予想される、共通鍵暗号、公開鍵暗号、ハッシュ関数、電子署名、それらに関連する暗号プリミティブ技術について、次の事項が発表された。

2.2.1. 共通鍵暗号に関する技術動向

7

･Key Guessing Strategies for Linear Key-Schedule Algorithms in Rectangle
Attacks [Eurocrypt 2022]

Xiaoyang Dong, Lingyue Qin, Siwei Sun, Xiaoyun Wang
著者らは、線形鍵スケジュール暗号に対する矩形攻撃（rectangle attack）のための四分位を生成する際、鍵候補を示唆しうる正しい四分位は、いくつかの非線形な関係を満たす必要があることを見出した。しかし、生成される四分位の中には、常にこれらの関係に違反し、鍵候補を示唆しないものがある。著者らは、過去の矩形攻撃フレームワークからヒントを得て、四分位を生成する前に特定のキーセルを推測することで、無効な四分位法の数を減少させることができることを見出した。しかし、一度に多くのキーセルを推測すると、早期に中止する手法の利点が失われ、全体の計算量が増す可能性がある。そこで本論文では、より良いトレードオフを得るために、線形鍵スケジュール暗号に対する新しい矩形攻撃フレーム
ワークを構築し、全体的な計算量を軽減するか、より多くのラウンドを攻撃することを目的としている。
このトレードオフモデルでは、全体の計算量に影響を与える多くのパラメータが存在しており、特に四分位生成前の鍵推測セルの数と位置の選択について重要となる。最適なパラメータを特定するため、SKINNY を例として、鍵回復フェーズに最適な矩形識別器、四分位
生成前の鍵推測セルの数と位置、網羅的な探索ステップに影響を与える構築する鍵カウン
タのサイズなど、均一な自動ツールを構築する。この自動化ツールを用いて、SKINNY-128384 に対する、関連鍵設定における 32 ラウンドの鍵回復攻撃を確認し、これまでの攻撃を
2 ラウンド拡張した。また、n-2n や n-3n の他のバージョンについても、従来よりも 1 ラウ
ンド多く達成することができた。 さらに、これまでの矩形識別器を用いて、ラウンド数を削減した ForkSkinny、Deoxys-BC-384、GIFT-64 に対してより良い攻撃を行っている。最後に、著者らの矩形暗号の枠組みを関連鍵設定から単一鍵設定に変換し、10 ラウンドの
Serpent に対する新しい単一鍵矩形暗号攻撃を与えることを議論する。

･A Correlation Attack on Full SNOW-V and SNOW-Vi [Eurocrypt 2022]

Zhen Shi, Chenhui Jin, Jiyan Zhang, Ting Cui, Lin Ding, Yu Jin
本論文では、線形フィードバックシフトレジスタ（Linear Feedback Shift Register、以下 LFSR）のバイナリストリームと SNOW-V および SNOW-Vi のキーストリーム間の相関を合成関数に近似する手法に基づいて探索する方法を示す。有限状態機械（Finite State Machine、
以下 FSM）に入力される LFSR の 4 つのタップが連続する 3 クロックの間の線形関係を利用
して、SAT/SMT 手法に基づく自動探索モデルを示し、高い相関を持つ一連の線形近似トレイ
ルを探し出す。中間マスクを使い切ることで、相関が-2-47.76 の 2 値線形近似を見つけることができる。この近似を用い、SNOW-V に対する相関攻撃を、予想時間計算量 2246.53、メモリ計
算量 2238.77, 同じ鍵および初期ベクトル（IV）で生成された 2237.5 の鍵ストリームで提案8

する。SNOW-Vi については、同じ相関を持つバイナリ線形近似を提供し、SNOW-V と同じ複雑さで相関攻撃を実装する。本論文の著者らの知る限りでは、これは完全な SNOW-V および
SNOW-Vi に対する、網羅的な鍵探索を上回る効率的な攻撃として初めて知られるものである。
その結果、鍵と IV の単一ペアの鍵流の最大長が 264 未満であるという設計制約を無視すれ
ば、SNOW-V と SNOW-Vi のいずれも 256 ビットのセキュリティレベルを保証できないことが示された。

･Refined Cryptanalysis of the GPRS Ciphers GEA-1 and GEA-2 [Eurocrypt 2022]

Itai Dinur, Dor Amzaleg
EUROCRYPT 2021 で、Beierle らは GPRS 暗号 GEA-1 と GEA-2 の最初の公開解析を発表した。
彼らは、GEA-1 は 64 ビットのセッション鍵を使用しているが、65 ビットのキーストリーム
を知るだけで、44 GiB のメモリを使用して時間計算量 240 で復元可能であることを示した。
この攻撃は、暗号の初期化処理にある弱点を利用したもので、設計者が意図的に隠して安全性を低下させたと推測される。
GEA-2 ではそのような弱点は見つかっていなかったが、Beierle らはこの暗号に対して、
約 245 の時間複雑性を持つ攻撃を発表している。主な実用上の障害は、GPRS フレームを完全に暗号化するために使用される 12800 ビットのキーストリームを知る必要があることである。この攻撃のバリエーションは、連続するキーストリームのビットが少ない場合や、（連続する長いブロックがない）利用可能なキーストリームが断片化されている場合にも、よりコストはかかるものの、適用可能である。
本論文は、GEA-1 および GEA-2 について、これまでの解析を改善し、補完するものである。
GEA-1 では、メモリ使用量を 44 GiB から 213 = 8192 倍、時間使用量を 240 倍に削減した攻撃を考案した。実装では、最新のラップトップで GEA-1 のセッションキーを平均 2.5〜時間で回復させることができる。GEA-2 に関しては、Beierle らの解析を補完する 2 つの攻撃が説明される。最初の攻撃は、攻撃者が利用できる連続したキーストリームビット数（ℓで示される）と時間計算量の間の線形トレードオフを得ることができる。これは、おおよそℓ ≤7000 の範囲において、従来の攻撃より改善される。具体的には、 ℓ = 1100 の場合、本攻撃の計算量は約 254 である（従来の攻撃はブルートフォースの計算量 264 より高速ではない）。利用可能なキーストリームが断片化されている場合、第二の攻撃は、時間計算量のコスト増加なしに、前攻撃のメモリ計算量を 32 GiB から 64 MiB に 512 倍減少させることができる。
本攻撃は、ストリーム暗号の解析技術と他の文脈で用いられるアルゴリズム技術（例えばk-XOR 問題の解決など）の新しい組み合わせに基づくものである。

･A

Greater

GIFT:

Strengthening

GIFT[Eurocrypt 2022]

9

againstStatistical

Cryptanalysis

Ling Sun, Bart Preneel, Wei Wang, Meiqin Wang
GIFT-64 は PRESENT より軽量な 128 ビット鍵による 64 ビットブロック暗号である。本論
文では、差分攻撃と線形攻撃に対する GIFT-64 の詳細な分析を行う。著者らの研究は、最適な差分および線形特性の自動探索手法を、注意深い手動分析で補完している。差分攻撃の設定では、ラウンドごとに 2 つのアクティブな S-box を持つ差分特性の存在を理論的に説明し、これらの特性のいくつかの新しい性質を導いている。さらに、7 ラウンド以上をカバーする GIFT-64 の最適な差分特性はすべて、1 ラウンドにつき 2 つの S-box をアクティブにしなければならないことを証明する。すべての最適な特性は手作業で構成することができる。
差分的な設定における作業と並行して、線形的な設定においても同様の分析を行う。しかし、差分設定での明確な見解とは異なり、GIFT-64 の最適な線形特性は、少なくとも 1 ラウンドが 1 つの S-box のみを活性化させるものでなければならない。さらに、自動探索手法の助けを借りて、線形攻撃に対して同等の安全性を維持しながら、差分攻撃に対してより優れた耐性を持つ 24 種類の GIFT-64 の亜種を見出した。これらの亜種は統計的暗号解析に対して
GIFT-64 を強化されたため、ラウンド数を 28 から 26 に減らすことができると著者らは主張した。この観測により、GIFT-64 よりもエネルギー消費量の少ない暗号を作ることが可能になった。GIFT-64 の場合と同様に、ラウンド数を削減した亜種についても、ほとんどのアプ
リケーションに関係がないため、関連鍵の安全性を主張することはない。

･Beyond quadratic speedups in quantum attacks on symmetric schemes [Eurocrypt2022]

Xavier Bonnetain, André Schrottenloher, Ferdinand Sibleyras
本論文では、古典的な問合せのみを用いてブロック暗号設計に対する初の量子鍵回復攻撃を行い、古典的な最良の攻撃と比較して 2 次以上の時間短縮を達成したことを報告する。
著者らは、EUROCRYPT 2012 での Gaži and Tessaro の 2XOR-Cascade 構成を研究している。
これは、2n ビットの鍵を持つ n ビットブロック暗号から 5n/2 ビットの安全性を持つ n ビットブロック暗号を提供する鍵長拡張技術であり、理想モデルにおける安全性証明がなされている。ASIACRYPT 2019 での Bonnetain らの offline-Simon アルゴリズムが拡張され、特にこの構成を量子時間𝑂̃(2𝑛 )で攻撃できることを示し、最高の古典攻撃より 2.5 の量子速度向上を提供する。
一般に、共通鍵暗号のポスト量子安全性については、鍵のサイズを 2 倍にすれば十分であると考えられている。これは、Grover の量子探索アルゴリズムやその派生アルゴリズムが、最大でも 2 次関数的な高速化にしか到達できないためである。著者らの攻撃は、いくつかの対称構成の構造を利用することで、この限界を克服できることを示すものである。特に、2XOR-Cascade をブロック暗号強化として用いることは、量子敵対者に対してはそのブロック暗号自身と同じ安全性しか提供できないために、できない。

10

･Post-Quantum Security of the Even-Mansour Cipher [Eurocrypt 2022]

Gorjan Alagic, Chen Bai, Jonathan Katz, Christian Majenz
Even-Mansour 暗号は、公開されたランダム置換 𝑃; {0,1}𝑛 → {0,1}𝑛 から、（鍵付きの）疑似ランダム置換 𝐸 を構成する簡単な方法である。現在 NIST で標準化が検討されている軽量な暗号システムなど、さまざまな共通鍵暗号の中核をなしている。古典的な攻撃に対して安全であり、最適な攻撃には 𝑞𝑃 𝑞𝐸 ≈ 2𝑛 のオーダーで 𝐸 への 𝑞𝐸 回の問合せと 𝑃 への𝑞𝑃 回問合せが必要となる。しかし、攻撃者に 𝐸 と 𝑃 の両方に対する量子アクセスが与えられた場合、この暗号は全く安全ではなく、 𝑞𝑃 = 𝑞𝐸 = 𝑂(𝑛) 回のクエリを用いた攻撃が知られている。
しかし、もっともらしい設定では、量子攻撃者は、𝑃に対しては量子アクセス権を保持することができる一方で、信頼できるパーティにより実装された鍵付き並べ換え𝐸については、
古典的なアクセス権しかもたない。この設定では、𝑞𝑃2 𝑞𝐸 ≈ 2𝑛 の攻撃が知られており、純粋な古典的ケースと比較して安全性が低下することが示されているが、この自然な「ポスト量子」設定においても Even-Mansour 暗号の安全性がまだ証明できるかという疑問も残されている。
本論文では、この未解決の問題を解決し、このポスト量子設定における攻撃には𝑞𝑃2 𝑞𝐸 +𝑞𝑃 𝑞𝐸2 ≈ 2𝑛 が必要であることを示す。著者らの結果は Even-Mansour の 2 鍵版と 1 鍵版の両方に適用される。また、量子問合せの下界に関する先行研究の結果を一般化したものでもあるため、その方面からも興味深いと思われる。

･Information-Combining Differential Fault Attacks on DEFAULT [Eurocrypt 2022]

Marcel Nageler, Christoph Dobraunig, Maria Eichlseder
差分故障解析（DFA）は、共通鍵暗号の実装に対する非常に強力な攻撃である。 ほとんどの対策は実装レベルで適用される。ASIACRYPT 2021 で Baksi らは、線形構造を持つ S-boxを使用することで、DFA に対して暗号レベルの耐性を内在させることを目的とした設計戦略を提案した。彼らは、彼らのインスタンスであるブロック暗号 DEFAULT において、DFA 敵対
者は 128 鍵ビットのうち最大 64 ビットしか学習できないため、残りのブルートフォース計
算量 264 は現実的ではないと主張した。
本論文では、DFA 敵対者がラウンド間の情報を組み合わせて完全な鍵を復元できることを示し、その安全性の主張を無効とする。特にこのような暗号は、線形方程式を用いた正規化で効率的に表現できる等価な鍵の大きなクラスを示すことを観察する。 これを DEFAULT の強力な鍵スケジュールと組み合わせて利用することで、100 回以下の欠陥計算と無視できる
時間計算量で鍵復元に成功している。さらに、独立したラウンド鍵を持つ DEFAULT の理想化バージョンでさえ、正規化された鍵に基づく情報結合攻撃に対して脆弱であることを示す。

･Superposition Meet-in-the-Middle Attacks: Updates on Fundamental Security of11

AES-like Ciphers [CRYPTO 2022]

Zhenzhen Bao, Jian Guo, Danping Shi, Yi Tu
中間一致攻撃アプローチは最も強力な共通鍵暗号解読技術の一つとして良く知れらており、MD4, MD5, Tiger, HAVAL, Haraka-512 v2 ハッシュ関数全体に対する原像攻撃や、完全ブロック暗号 KTANTAN の鍵回復への応用で実証されている。攻撃が成功するには、プリミテ
ィブを 2 つの独立したチャンクに分離し、各アクティブセルが 1 つのチャンクのみを表現するために使用されるか、または混合されると使用不可能とみなされる状態にすることが重要である。本論文では、そのようなセルの一部が線形に混合され、独立したセルと同様に有用であることを観察する。これは、重ね合わせ状態の導入と付随する一連の技術につながり、EUROCRYPT 2021 で Bao らが、CRYPTO 2021 で Dong らが提案した MILP ベースの探索フ
レームワークに組み込まれ、AES ライクのハッシュ関数やブロック暗号に幅広く応用できる
ことが分かる。

･Triangulating Rebound Attack on AES-like Hashing [CRYPTO 2022]

Xiaoyang Dong, Jian Guo, Shun Li, Phuong Pham
Rebound attack は FSE 2009 で Mendel らによって導入され、状態からの自由度を利用して、差分パスの重い中間ラウンドをフリーに実現することができる。ASIACRYPT 2009 でLamberger ら、FSE 2010 で Gilbert と Peyrin が発明した Super-Sbox 技術により、インバ
ウンドフェーズが 2 ラウンドに拡張された。ASIACRYPT 2010 では、Sasaki らが non-fullactive Super-Sbox を導入し、メモリ使用量をさらに削減した。
本論文では、この研究成果を発展させ、複数の 1 ラウンドまたは（non-full-active）2 ラ
ウンドの Super-Sbox インバウンドフェーズを、状態と鍵の自由度を十分に活用し、かつ大容量メモリを使用せずに接続できる、Super-Inbound を紹介している。この技術を応用して、いくつかの AES ライクなハッシュ関数で古典的または量子衝突を発見し、AES-128 と Skinny
ハッシュモード、Saturnin-hash、Grostl-512 などのターゲットで攻撃ラウンド数を 1～5向上させた。本攻撃の正しさを実証するため、古典的な設定において推定時間計算量 224 の6 ラウンド AES-128-MMO/MP に対する semi-free-start 衝突を実装し、標準的な PC で瞬時にペアのインスタンスを見つけることができた。

･Simplified MITM Modeling for Permutations: New (Quantum) Attacks [CRYPTO
2022]

André Schrottenloher, Marc Stevens
中間一致攻撃（Meet-in-the-middle、MITM）とは、内部状態が 2 つの独立した経路（「前方」と「後方」）に沿って計算され、それが一致する一般的なパラダイムである。近年
では、EUROCRYPT 2021 で Bao らが開発した MILP モデルに代表されるように、汎用ソル
バに詳細な攻撃モデルを用いて、改良された攻撃を自動的に探索することが行われてい12る。本論文では、汎用ソルバへの入力として大幅に削減された攻撃表現と、任意の解に対して詳細な攻撃の存在と計算量を証明する理論分析を組み合わせた、よりシンプルな
MILP モデリングを研究している。このモデル化により、広範な暗号並べ換えに対する古典的攻撃と量子的攻撃の両方を発見することができる。第一に、Spongent ハッシュ関数の並べ替えを用いた Present ライクな構成がある。識別器の中間一致攻撃ステップを最大 3 ラウンド改善された。第二に、AES のような設計がある。Bao らのモデルよりはるかに単純であるにもかかわらず、提案されたモデルは以前の最良の結果を回復することができる。唯一の制限は、鍵スケジュールから自由度を使用しないことである。第三に、このモデルは Feistel ネットワークのような、より多くの並べ替えをターゲットに拡張できることを示す。この文脈で、Simpira v2 や Sparkle の縮小版に対する新しい推測と決定の攻撃を行った。最後に、このモデルを用いて、古典的な攻撃と同じラウンド数で、新しい量子的な前像および擬似原像攻撃（例：Haraka v2, Simpira v2 ...）を見つけることができる。
･Simon's Algorithm and Symmetric Crypto: Generalizations and Automatized
Applications [CRYPTO 2022]

Federico Canale, Gregor Leander, Lukas Stennes
本論文では、共通鍵暗号プリミティブを破るために Simon のアルゴリズムを適用する
方法についての理解が深められる。一方では、新しい攻撃の探索を自動化する。この方法を用いて、5 ラウンド MISTY L-FK や 5 ラウンド Feistel-FK（内部並べ替えあり）な
どの構成に対する最初の効率的な鍵回復攻撃を Simon のアルゴリズムを用いて自動的に見つけることができた。また、Simon アルゴリズムの一般化として、非標準的なHadamard 行列を用いた研究を行い、周期以外の性質を持つ量子共通鍵暗号解読ツールの拡張を目指す。主な結果としては、いずれの一般化もそれを達成できないことであり、量子計算機で非標準的な Hadamard 行列を利用して共通鍵暗号プリミティブを破るには、
根本的に新しい攻撃が必要であると結論付けている。
･Quantum Attacks on Lai-Massey Structure [PQCrypto 2022]

Shuping Mao, Tingting Guo, Peng Wang, Lei Hu
Aaram Yun らは、Lai-Massey 構造が Feistel 構造と同等の安全性を有すると考えた。
しかし、Luo らは、3 ラウンドの Lai-Massey 構造が、Feistel 構造とは異なる Simon ア
ルゴリズムの量子攻撃に耐性があることを示した。本研究では、典型的な Lai-Massey
構造に対する量子攻撃を行う。その結果、3 ラウンド Lai-Massey 構造に対する量子 CPA
識別器と、Feistel 構造と同じ 4 ラウンド Lai-Massey 構造に対する量子 CCA 識別器が存在することが示された。Lai-Massey 攻撃に対する攻撃を準 Feistel 攻撃に拡張する。
準 Feistel 構造の結合（combiner）が線形である場合、3 ラウンド balanced 準 Feistel

13

構造に対する量子 CPA 識別器と、4 ラウンド balanced 準 Feistel 構造に対する量子 CCA
識別器が存在することを示す。
･Algebraic Meet-in-the-Middle Attack on LowMC [Asiacrypt 2022]

Fukang Liu, Santanu Sarkar, Gaoli Wang, Willi Meier, Takanori Isobe
本論文では、部分的な非線形層の特徴を利用し、LowMC の安全性を解析するために代数的な中間一致攻撃（MITM）という新しい手法を提案している。これにより、単純な差分列挙攻撃のメモリ計算量を最先端のものより削減することが可能である。
LowMC の差分トレイルから完全な鍵を取り出す効率的な代数的手法が CRYPTO 2021 で提案されているが、その時間計算量は鍵サイズに対して指数関数的であることに変わりはなかった。本研究では、トレイルに十分な数のアクティブな S-box が存在する場合、これを定数時間にまで短縮する方法を示している。上記の新技法により、CRYPTO 2021
で発表された LowMC および LowMC-M に対する攻撃はさらに改善され、いくつかの LowMC
インスタンスを初めて破ることができた。
･Mind the TWEAKEY Schedule: Cryptanalysis on SKINNYe-64-256 [Asiacrypt 2022]

Lingyue Qin, Xiaoyang Dong, Anyu Wang, Jialiang Hua, Xiaoyun Wang
近年、特定の用途に合わせた共通鍵暗号の設計が話題となっている。EUROCRYPT 2020
で、Naito、Sasaki、Sugawara は、認証付き暗号 PFB_Plus の要件を満たすために、閾値
実装フレンドリー暗号 SKINNYe-64-256 を考案した。やがて Thomas Peyrin が、SKINNYe64-256 は新しい tweakey スケジュールにより安全性の期待を失う可能性があると指摘した。SKINNYe-64-256 の安全性の問題はまだ不明だが、Naito らは対応策として、
SKINNYe-64-256 v2 を導入することを決定した。
本論文では、SKINNYe-64-256 の新しい tweakey スケジュールについて形式的な暗号
解 析 を 行 い 、 tweakey ス ケ ジ ュ ー ル に お け る 予 想 外 の 差 分 キ ャ ン セ レ ー シ ョ ン（differential cancellation）を発見している。例えば、連続する 30 ラウンドのうち、
キャンセレーションが起こる回数は最大 8 回であり、予想される 3 回のキャンセレーシ
ョンより大幅に多いことを発見した。この性質は、線形代数による tweakey の更新関数（LFSR）の解析によって導き出される。さらに、矩形攻撃、MITM 攻撃、不可能差分攻撃（impossible differential attack）について新たな発見をし、対応する自動化ツールに著者らの発見による新たな制約を適応させた。最終的に、SKINNYe-64-256 に対する
41 ラウンドの関連 tweakey 矩形攻撃が発見された。残っているセキュリティマージン
は 3 ラウンドのみである。STK は任意のサイズの tweakey を受け付ける一方、SKINNY とSKINNYe-64-256 v2 は最大 4n の tweakey サイズまでしかサポートしていない。本論文
では、SKINNY-64 のために、サポートする tweakey のサイズをさらに拡張する新しいtweakey スケジュールを紹介し、このスケジュールが STK と SKINNY のセキュリティ要14

件を継承していることをフォーマルに証明する。
･Enhancing Differential-Neural Cryptanalysis [Asiacrypt 2022]

Zhenzhen Bao, Jian Guo, Meicheng Liu, Li Ma, Yi TuCRYPTO 2019 で Gohr は、十分に訓練されたニューラルネットワークが、従来の差分識別器よりも優れた暗号解読の識別タスクを実行できることを示した。さらに、通常ではない鍵推測戦略を適用することで、最新のブロック暗号 Speck32/64 に対する 11 ラウ
ンドの鍵回復攻撃を行い、公表された最先端の結果を改善した。このことから、次のような疑問が浮かぶ：機械学習（ML）は従来の手法に対してどの程度の優位性があるのか、
また、現代暗号の暗号解読においてその優位性は一般的に存在するのか？
本論文では、最初の疑問に対する答えとして、より拡張されたラウンド数削減型のSpeck32/64 に対して、ML を用いた鍵回復攻撃が考案されている。その結果、改良型 12
ラウンド攻撃と、初の実用的な 13 ラウンド攻撃が達成された。この成果において本質的な点は、ML ベースの攻撃における古典的な要素、すなわちニュートラルビットを強化することにある。2 番目の質問に対しては、ラウンド削減された Simon32/64 上で様々なニューラルネットワーク識別器を生成し、純粋な差分ベースの対応するものとの比較を行っている。
･Optimizing Rectangle Attacks: A Unified and Generic Framework for Key Recovery[Asiacrypt 2022]

Ling Song, Nana Zhang, Qianqian Yang, Danping Shi, Jiahao Zhao, Lei Hu, JianWeng
矩形攻撃はブロック暗号に対して非常に強力な暗号解読法である。矩形識別器がある
場合、鍵回復攻撃を可能な限り効率的に行うことが期待できる。文献上では、矩形鍵回
復攻撃のアルゴリズムは 4 種類存在している。しかし、その性能はケースバイケースである。また、攻撃方法が最適化されていないアプリケーションも数多く存在する。
本論文では、矩形鍵回復攻撃について深く考察し、あらゆる攻撃パラメータに対応可
能な統一的かつ汎用的な鍵回復アルゴリズムが提案される。特に、従来の 4 つの矩形鍵
回復アルゴリズムをカバーするだけでなく、従来は見落とされていた 5 種類の新しい攻撃も明らかにされている。また、新しい鍵回復アルゴリズムとともに、最適な攻撃パラ
メータを自動的に見つけるフレームワークを提案し、新しいアルゴリズムを用いて矩形
攻撃の時間複雑性を最小にする。新しい鍵回復アルゴリズムの効率性を実証するため、既存の識別器に基づく Serpent、CRAFT、SKINNY、Deoxys-BC-256 に適用し、一連の改良
型矩形攻撃が得られた。
･Optimising Linear Key Recovery Attacks with Affine Walsh Transform Pruning

15

[Asiacrypt 2022]

Antonio Flórez-Gutiérrez
線形暗号解読は、ブロック暗号に対する鍵回復攻撃の主要な族の 1 つである。いくつかの論文では、高速な Walsh 変換を使用することで、その時間計算量を低減できる可能性に注目している。これらの先行研究は、鍵回復ラウンドの構造を無視して、任意のブール関数として扱っていた。本論文では、Walsh 変換のための新しいアフィン枝刈り技術を使用して、これらの関数の Walsh スペクトルのゼロを利用することによって、これらのアルゴリズムの時間とメモリの計算量を最適化した。これらの新しい最適化戦略は、
DES に対する改良された攻撃と 29 ラウンドの PRESENT-128 に対する最初の既知の攻撃という 2 つの応用例で紹介される。
･Stretching Cube Attacks: Improved Methods to Recover Massive Superpolies[Asiacrypt 2022]

Jiahui He, Kai Hu, Meiqin Wang, Bart Preneel
キューブ攻撃は、共通鍵暗号の代数的性質を利用して、特殊な多項式である superpoly を復元し、その後に秘密鍵を復元するものである。対応するブール関数の ANF（algebraic
normal form）が利用できない場合、分割特性に基づくアプローチにより、巧妙な方法で正確な Superpoly を復元することができる。しかし、Superpoly を復元するための計算コスト
は、暗号のラウンド数が増加するにつれて法外に大きくなる。例えば、ASIACRYPT2021 で提案された NMP（nested monomial prediction）は、 Trivium の 845 ラウンドまでの解析に留まっている。この NMP 技術のボトルネック、すなわち単項トレイルの数が多すぎて解けないモデルを緩和するために、著者らは superpoly に寄与する特定の中間ラウンドのいわゆるvaluable term に焦点を当てている。2 つの新しい技術、すなわち、NBDP（Non-zero Bitbased Division Property）と CMP（Core Monomial Prediction）を導入し、MP の MILP モデルと比較して、より単純な MILP モデルを実現することが可能となる。CMP 技法は、valuable
term を回復する計算量の点で、monomial prediction よりも大幅な改善をもたらすことが示されている。分割統治法とこれら 2 つの新しい技術を組み合わせることで、より効果的に
valuable term を捕らえ、superpoly に何も貢献しない中間項に対する計算リソースの浪費を避けることが可能となる。 その結果、以前の攻撃の計算コストを大幅に削減することができ、846、847、848 ラウンドの Trivium、192 ラウンドの Grain、895 ラウンドの Kreyvium、
776 ラウンドの Acorn が実用時間で復元された。さらに、Möbius 変換の内部的な性質を調べることで、鍵の全ビットを含む superpoly を用いた鍵回復方法を示し、対象となる暗号に対して最適な鍵回復攻撃を行うことができるようになった。

･On the Field-Based Division Property: Applications to MiMC, Feistel MiMC and
GMiMC [Asiacrypt 2022]

16

Jiamin Cui, Kai Hu, Puwen Wei, Meiqin Wang
近年、MPC や ZKP などの高度な暗号プロトコルが実用化され、AO 暗号と呼ばれる有限体上の共通鍵暗号が開発されている。このような AO 暗号は、代数的攻撃、特に高階の差分攻撃に対して脆弱であることが指摘されている。そのため、代数的次数の増大を注意深く評価することに意義がある。しかし、AO 暗号の次数推定は、一般的で正確な方法がないため、
暗号解析者の課題となっている。
本論文では、代数的次数の上界を求めるための最先端のフレームワークである division
property を、バイナリ体から𝔽2𝑛 をスコープにいれた範囲に拡張する。
これは、AO 暗号の代数的次数を検出する汎用的な手法であり、Feistel 暗号にも適用可能である。この一般化された division property における著者らのアイデアは、ブロック暗号の多項式表現がある特定の単項式を含んでいるかどうかを評価することにある。演算の特徴を深く調べることで、SMT のビットベクトル理論を用いて効率的にモデル化できる体演算
ベースの単項式の伝搬規則が紹介される。そして、代数的次数と単項式の指数との関係から、
次数推定のための新しい検索ツールを構築することができる。
著者らは、この新しい枠組みを Feistel MiMC、GMiMC、MiMC などのいくつかの重要な AO
暗号に適用した。Feistel MiMC については、代数的次数の増大が本来の指数関数的な限界
よりも大幅に遅くなることが示された。また、CRYPTO 2020 で提案された Feistel MiMC の83 ラウンドの順列識別器よりもはるかに優れた、124 ラウンドまでの秘密鍵高次差分識別器が初めて提示された。また、データ計算量 2251 のフルラウンドゼロサム識別器も提示される。本手法は、より多くの分岐を持つ一般的な Feistel 構造に対してさらに拡張でき、GMiMCの実用的なインスタンスに対して、最大 50 ラウンドの高次の差分識別器を示すことが可能である。SP-network における MiMC については、本結果は Bouvier によって証明された正確な代数的次数と対応する。著者らはさらに、異なる指数をもつ MiMC のような方式に対する高階差分攻撃に対する安全性を保証するために、MiMC 仕様のラウンド数は十分ではないことを指摘した。

2.2.2. 公開鍵暗号に関する解読技術･How to Backdoor (Classic) McEliece and How to Guard Against Backdoors[PQCrypto 2022]

Tobias Hemmert, Alexander May, Johannes Mittmann, Carl Richard Theodor
Schneider
本論文では、McEliece 暗号をバックドア化し、バックドア化された公開鍵は通常の公開鍵と区別がつかないが、秘密鍵は効率的に取得できる方法を示す。暗号学上の理由から、
McEliece は小さな乱数種𝛅を使用し、何らかの疑似乱数生成器（PRG）により秘密鍵を決定17

する乱数を生成する。本論文のバックドアメカニズムは、𝛅の暗号化を公開鍵にエンコードすることで機能する。𝛅を取り出すことで、（バックドアされた）秘密鍵を効率的に復元することができる。興味深いことに、McEliece は𝛅を暗号化するために使用することができ、それにより著者らのバックドア機構を強力なポスト量子セキュリティ保証で保護することができる。この構成は、非圧縮秘密鍵に対する現在の古典的 McEliece NIST 標準提案に対しても有効であり、悪意を持ってバックドアを施した実装が広まる可能性がある。幸いなことに、
このバックドアメカニズムは、Classic McEliece の提案で規定されているように、鍵生成後に𝛅を保存すれば、（バックドアされた）秘密鍵の所有者によって検出することができる。
したがって本結果は、実装者に対して、秘密鍵の内部に𝛅を格納し、バックドア機構から保護するために𝛅を使用するようにという強い助言を与えるものである。

･Improving Bounds on Elliptic Curve Hidden Number Problem for ECDH Key Exchange[Asiacrypt 2022]

Jun Xu, Santanu Sarkar, Huaxiong Wang, Lei Hu
Elliptic Curve Hidden Number Problem（EC-HNP）は、Boneh、Halevi、Howgrave-Graham
によって Asiacrypt 2001 で初めて導入された。そして、ECDH のビット安全性を厳密に評価するため、Hidden Number Problem（HNP）の楕円曲線アナロジーとみなされる EC-HNP のDiffie-Hellman 亜種が PKC 2017 で発表された。この変種は、サイドチャネル攻撃の状況下
で、ECDH 鍵交換の実用的な暗号解読にも利用できる。
本論文では、EC-HNP の Diffie-Hellman 亜種において、関係するモジュラー多変量多項式を解くための Coppersmith 法を再検討し、任意の正の整数𝑑、与えられた十分に大きな素数𝑝、𝔽𝑝 上の楕円曲線において、
ECDH 鍵の𝑥座標の LSB を1/(𝑑 + 1)出力するオラクルがあれば、全ビットをlog2 𝑝の多項式時間で計算するヒューリスティックアルゴリズムが与えられることが実証された。𝑑 > 1のとき、ヒューリスティックな結果1/(𝑑 + 1)は厳密な評価5/6とヒューリスティックな評価1/2の両方を著しく上回る。Coppersmith 法に含まれるヒューリ
スティックのため、固定された楕円曲線上での ECDH ビット安全性は得られない。しかし、小次元格子の NIST 曲線において、ヒューリスティックの有効性が実験的に検証する。

･Lattice sieving via quantum random walks [Asiacrypt 2021]

Johanna Loyer, André Chailloux
格子暗号は、ポスト量子暗号の有力な提案の一つである。最短ベクトル問題（Shortest
Vector Problem、SVP）は格子暗号の暗号解析において最も重要な問題であり、多くの格子暗号はその困難性に基づく安全性を主張している。SVP に対する最良の量子アルゴ
リズムは Laarhoven によるもので、（ヒューリスティックに）時間 20.2653𝑑 + 𝑜(𝑑) で実行される（𝑑は格子の次元）。
本論文では、Laarhoven の結果を改良し、（ヒューリスティックに）時間 20.2570 𝑑 + 𝑜(𝑑)18で実行されるアルゴリズムが提示される。また、本アルゴリズムの量子メモリと量子ランダムアクセスメモリの量を定量化し、時間とメモリの間のトレードオフを提示する。
･A Systematic Approach and Analysis of Key Mismatch Attacks on Lattice-BasedNIST Candidate KEMs [Asiacrypt 2021]

Yue Qin, Chi Cheng, Xiaohan Zhang, Yanbin Pan, Lei Hu, Jintai Ding
格子ベースの KEM に対する鍵不一致攻撃の研究は、現在進行中の NIST のポスト量子暗号の標準化における暗号評価の重要な部分である。このような攻撃は数多く存在しているが、しかしこれらの KEM の鍵不一致攻撃に対する耐性を評価する統一的な手法はまだない。効率性の重要な指標は、そのような攻撃を成功させるために必要なクエリ数である。
本論文では、そのような攻撃に必要な最小平均クエリ数の下界を求める体系的アプローチの提案、開発が行われる。基本的な考え方は、クエリの下限を求める問題を最適なバイナリ復元木（binary recovery tree、BRT）を見つけることに変換することである。
この BRT において、下限の計算は、本質的には特定のシャノンエントロピーの計算となる。またこの最適 BRT のアプローチにより、いくつかの格子ベースの NIST 候補 KEM において、必要なクエリの数に関して、理論的な下限と実際の攻撃で観測された下限の間に大きなギャップがある理由を説明できる。さらにこれら既存攻撃に対する汎用的な改善方法が提案され、実験により確認された。提案された手法は、CCA 安全な NIST 候補
KEM に対するサイドチャネル攻撃を改善するために直接利用することができる。

2.2.3. ハッシュ関数に関する解読技術･SwiftEC: Shallue--van de Woestijne Indifferentiable Function to Elliptic
Curves [Asiacrypt 2022]

Jorge Chávez-Saab, Francisco Rodrı́guez-Henrı́quez, Mehdi Tibouchi
任意の値を楕円曲線上の点にハッシュ化することは、多くの暗号構成で必要とされるステップであり、長年にわたって多くの技術が提案されてきた。最初のものは Shallueと van de Woestijne によるもので、有限体上のすべての楕円曲線に適用できるという興味深い性質を持っていた(ANTS-VII)。しかしながら、基礎体に対するランダムオラク
ルと合成したときに、「ランダムオラクルと区別できない」という望ましい性質は持っていなかった。
この制限を克服するために、Brier らの基礎研究(CRYPTO 2011)を皮切りに、様々なアプローチが検討されている。例えば、𝑓: 𝔽𝑞 → 𝐸(𝔽𝑞 ) を Shallue-van de Woestijne(SW) とし、𝐻と𝐻′が 2 つのランダムオラクルの場合、𝑚 ↦ 𝑓(𝐻(𝑚)) + 𝑓(𝐻′(𝑚))はラン

19

ダムオラクルと区別できないことが示されている。この方法は、素直な、しかし区別不可能ではない関数𝑚 ↦ 𝑓(𝐻(𝑚))に比べて計算コストが 2 倍かかるという欠点がある。
これまでの他のほとんどの解決策も同じ問題で、𝑓のような単純な符号化写像が 1 回の基礎体指数計算で済むのに対し、それらは少なくとも 2 回の指数計算と同じコストがかかっている。最近、Koshelev (DCC 2022)は、1 つの指数化のコストで無分別ハッシュの最初の構成を提供したが、それは曲線の非常に特定のクラス（𝑗不変量 0 のものもある）
に対してのみであり、より広く適用できそうにない技術を使っていた。
本研究では、この長年の未解決問題を再検討し、SW 写像を 1 パラメータ族(𝑓𝑢 )𝑢∈𝔽𝑞 に拡張した上で、独立なランダムオラクル𝐻, 𝐻′を用いた𝐹: 𝑚 ↦ 𝑓𝐻′ (𝑚) (𝐻(𝑚))が、ランダ
ムオラクルと区別不可能であることを確認した。さらに、非常に大きな曲線のクラスにおいて、1 パラメータ族は有理的にパラメトライズされ、それにより小さな𝑓とほぼ同じコストで𝐹を計算することができる。最終的に、ほとんどの曲線に対して単一の指数化で無差別的ハッシュを達成することに成功した。この新しいアプローチは、任意の楕
円曲線の点を一様に近いランダムな文字列として表現する Tibouchi (FC 2014)のElligator Squared 技術の改良型をもたらすものである。

2.2.4. 署名に関する解読技術･Breaking Rainbow Takes a Weekend on a Laptop [CRYPTO 2022,PQCrypto 2022]

Ward Beullens
本研究で、NIST のポスト量子暗号標準化プロジェクトで最終選考に残った 3 つの署名方式の 1 つである Rainbow 署名方式に対する新しい鍵回復攻撃を導入された。この新しい攻撃は、NIST に提出されたすべてのパラメータセットに対して既知の攻撃を上回
り、SL 1 パラメータに対する鍵回復を実用している。具体的には、第二ラウンドに提出された SL 1 パラメータの Rainbow 公開鍵が与えられた場合、提案された攻撃は標準的なノートパソコンで平均 53 時間（1 週末）の計算時間で対応する秘密鍵を返す。
･Improving Support-Minors rank attacks: applications to GeMSS and Rainbow[CRYPTO 2022]

Pierre Briaud, Javier Verbel, Daniel Smith--Tone, Ray Perlner, Daniel
Cabarcas, John Baena
Support-Minors（SM）法は、NIST のラウンド 3 候補である GeMSS と Rainbow に対す
る最近の攻撃に見られるように、これまで利用不可能だったランク特性を持つ多変量解
析を攻撃する新しいルートを切り開いた。本論文では、この SM 方式をより深く研究し、この Support-Minors 方式に基づく GeMSS への攻撃を大幅に改善したものが提案されている。GeMSS はすでに最近の攻撃の影響を受けていたが、この攻撃はさらなる影響を与20

え、単にパラメータのサイズを大きくする、最近の射影技術（projection technique）
を適用することによっては、このスキームを修復することは不可能となった。例えば、
GeMSS128 のパラメータセットに対する提案された攻撃は、推定時間計算量 272 であり、射影技術により方式を修復した場合は、署名にかかる時間が非現実的なファクター 214
で遅くなってしまう。もう一つの貢献は、大規模 SM システムにおいて、XL 戦略のメモ
リアクセスコストが懸念される場合に、Block-Wiedemann アルゴリズムをサブルーチンとして使用し、そのコストを削減できる最適化を提案することである。とあるメモリコ
ストモデルにおいて、矩形 MinRank 攻撃は、実際にすべてのラウンド 3 の Rainbow パラ
メータセットのセキュリティをその目標セキュリティ強度以下に低下させ得ることを示し、同じメモリコストモデルを用いて、Rainbow 開発チームによって主張されていた下界と矛盾することが示される。
･A New Fault Attack on UOV Multivariate Signature Scheme [PQCrypto 2022]

Hiroki Furue, Yutaro Kiyomura, Tatsuya Nagasawa, Tsuyoshi Takagi
多変量署名方式の一つである unbalanced oil and vinegar 署名方式（UOV）は、量子攻撃に対する安全性が期待されている。暗号システムの安全性を実用的に実現するためには、計
算誤差を発生させて安全性を破綻させる故障攻撃などの物理攻撃に対する安全性に対処する必要がある。
本研究では、
秘密鍵に発生する故障を利用した UOV に対する新たな故障攻撃を提案する。
提案攻撃では、まず秘密鍵に発生する故障を利用して秘密鍵の線形写像の一部を復元し、その後、公開鍵システムを変換する。その結果、提案攻撃は与えられた公開鍵システムを元のシステムよりも少ない変数で構成されるシステムに変換することができる。また、提案する攻撃を適用した後、既存の鍵回復攻撃を用いることで、元のシステムよりも少ない計算量で秘密鍵を回復することができる。シミュレーションの結果、100bit の安全性を満たす 2 つの実用的なパラメータセットに対して、提案する攻撃は約 80〜90%の確率で 90bit の安全性しか持たないシステムに縮小できることを示した。また提案されている攻撃は、上記の場合よりも低い確率で、より小さなシステムを実現し、結果そのようなシステムをより効率的に破ることができることを示す。

･Breaking Category Five SPHINCS+ with SHA-256 [PQCrypto 2022, Best Paper Award]

Ray Perlner, John Kelsey, David Cooper
SPHINCS+は、NIST のポスト量子暗号（PQC）標準化プロセスの一環として標準化されたス
テートレスハッシュベースの署名方式である。その安全性の証明は、鍵付きハッシュ関数のDM-SPR（distinct-function multi-target second-preimage resistance）に依存している。
SPHINCS+では、SHA-256 をベースにしたものなど、いくつかの鍵付きハッシュ関数のインスタンスが提案されている。
PQC メーリングリストの Sydney Antonov による最近の観測では、

21

SHA-256 に基づく構成は、NIST に提出されたパラメータセットのいくつかについて、NIST
カテゴリ 5 の DM-SPR を持たないことが実証されたが、この観測が偽造攻撃につながるかど
うかは未解決のままだった。
本論文では、これらのパラメータセットの具体的な古典的安全性を約 40 ビット減少させる完全な偽造攻撃を与えることによって、この質問に肯定的に答える。提案された攻撃は、
SPHINCS の WOTS+公開鍵に Antonov の技術を適用し、非常に限られたハッシュ値群に署名できる新しいワンタイムキーを導き出すことで機能する。この鍵から、元のハイパーツリー(hypertree)を少し改変したものを作成し、それを使って任意のメッセージに署名することで、有効であるかのように見える署名を得ることができる。

2.2.5. サイドチャネル攻撃の技術動向･A Novel Completeness Test for Leakage Models and its Application to Side
Channel Attacks and Responsibly Engineered Simulators [Eurocrypt 2022]

Si Gao, Elisabeth Oswald
今日のサイドチャネル攻撃のターゲットは、命令が並列に処理され、32 ビットのデータ語で動作する複雑なデバイスであることが多い。その結果、これらの最新デバイスでリークを発生させるのに関与する状態は大きく、不完全である可能性のある状態に基づいて評価（ワーストケース攻撃など）、シミュレータ、および（マスキング）対策の仮定を建てると、結論が大幅に間違ってしまう可能性がある。
本論文では、想定される状態の「完全性」に対する新しい概念と、「崩壊モデル」に基づく効率的な統計的検定を提案する。この新しいテストは、グレーボックスの設定において、複数の 32 ビット変数を含む状態を回復するために使用することができる。さらにこの新しいテストがサイドチャネル攻撃分析に役立つことを説明し、既存の実装に対する新しい攻撃方向を明らかにする。また、統計的テストを適用することで、最新の漏洩シミュレータでさえ、それぞれのターゲットデバイスの利用可能な漏洩をすべて捕捉していないことを示す。

･Towards Micro-Architectural Leakage Simulators: Reverse Engineering MicroArchitectural Leakage Features is Practical [Eurocrypt 2022]

Si Gao, Elisabeth Oswald, Dan Page
リークシミュレータは、サイドチャネルリークを考慮したソフトウェアのテストを簡単かつ迅速に行えるという魅力的な機能を備えている。そのため、リークモデルの品質は非常に重要であり、これにはマイクロアーキテクチャのリークを忠実に含めることが含まれる。
マイクロアーキテクチャのリークは、ARM Cortex M シリーズのようなローからミッドレン

22

ジの商用プロセッサでも現実的なものである。マイクロアーキテクチャの要素が公に知られていない場合、どのようにそれを記述すればよいのだろうか？という問に、グレーボック
ス状況で対応することは、当初は実行不可能と思われていた。
本論文では、最新のリークモデリング技術を用いて、商用プロセッサのマイクロアーキテ
クチャのリークの重要な要素をリバースエンジニアリングすることが可能であることを、初めて実証した。このアプローチでは、まず、パイプラインの各ステージのマイクロアーキ
テクチャのリークを復元し、グリッチを発生させることが知られている要素のリークを復元する。リバースエンジニアリングされたリーク機能を用いて、一般的なリークシミュレー
タ ELMO の拡張版を構築する。

･Private Circuits with Quasilinear Randomness [Eurocrypt 2022]

Vipul Goyal, Yuval Ishai, Yifan Song関数𝑓のための𝑡-private 回路とは、入力𝑥のランダムな符号化を出力𝑓(𝑥)の符号化に対応付けるランダム化ブール回路 C であり、回路𝐶内の任意の𝑡本を探っても𝑥について何も明らかにならないものである。𝑡-private 回路は、サイドチャネル攻撃から組込み機器を保護するために使用することができる。このようなデバイスで新しいランダム性を生成するコス
トが高いことに動機づけられ、いくつかの研究が𝑡-private 回路のランダム性計算量を最小化する問題を研究してきた。Coron ら(Eurocrypt 2020)による最もよく知られた上限は、𝑠を回路のサイズとした時の、𝑂(𝑡 2𝑐 log 𝑠)-ビットである。本研究はこの上限を、入力エンコーダで使用されるランダムネスを含めて、𝑂(𝑡 log 𝑠)に改善した。さらに𝑡-private 回路のス
テートフルな亜種にもこれを拡張する。この構成は、𝑓の回路から無視できる故障確率で𝑡private 回路𝐶を生成する効率的なランダム化アルゴリズムが存在するという意味で、semiexplicit なものである。

･Efficiently Masking Polynomial Inversion at Arbitrary Order [PQCrypto 2022]

Markus Krausz, Georg Land, Jan Richter-Brockmann, Tim Güneysu
物理サイドチャネル解析は、組込み機器に実装されるポスト量子暗号方式にとって大きな脅威となる。しかし、多くの方式において安全な実装が見出されていないのが現状である。
本論文では、ポスト量子暗号の鍵生成の主要な要素であるマスク多項式反転の効率的な解決策を提案している。このために、加法的マスキングとの効率的な任意次数変換を行う多項式-多倍長マスキング方式が導入されている。さらに、多項式の反転と乗算をマスキングス
キームに統合する方法を示すことで、コストを大幅に削減している。また、Cortex-M4 上で2 種類のポスト量子暗号方式に対する本アルゴリズムの性能を実証した。NTRU では、マスクなし反転と比較して、1 次マスク反転で 35%のオーバーヘッドを計測したが、BIKE では 11%とわずかなオーバーヘッドにとどまった。最後に、TVLA に基づくサイドチャネル解析の測定と実行により、1 次マスク反転に対する著者らのアルゴリズムの安全性を検証した。

23

･Efficiently Masking Polynomial Inversion at Arbitrary Order [PQCrypto 2022]

Thomas Schamberger, Lukas Holzbaur, Julian Renner, Antonia Wachter-Zeh, Georg
Sigl
符号ベースのポスト量子アルゴリズム Hamming Quasi-Cyclic (HQC) は、NIST 標準化プ
ロジェクトの第 4 ラウンド候補である。その第 3 ラウンド版以降、新しい誤り訂正符号の組み合わせ、すなわち Reed-Muller 符号と Reed-Solomon 符号の組み合わせが利用されており、そのため公表されている攻撃を適応する必要がある。
本論文の著者らは、CHES 2021 からの Uneo らによるパワーサイドチャンネル攻撃が、実装された Reed-Muller デコーダが固定された復号境界を持たないという事実を見逃しているため、実際には機能しないことを確認している。また、この研究では、再び攻撃を成功させることができる新しい攻撃戦略が提供されている。著者らの攻撃は、その成功を検証するためにシミュレーションに頼らず、HQC パラメータセットに対して高い確率で証明される。
Guo らによるタイミングサイドチャンネル攻撃とは対照的に、著者らは必要な攻撃クエリを
12 分の 1 に減らし、タイミングオラクル固有の不確実性を排除することができる。ARM
Cortex-M4 マイコン上の Reed-Solomon デコーダのパワーサイドチャンネルを利用した実用的な攻撃結果を示す。また、本攻撃手法が、関連研究のサイドチャネルをターゲットとした
場合に、どのように利用可能であるかについて考察を行う。
最後に、情報セット復号を使用して、部分的に取得された秘密鍵に対する残りの攻撃複雑度を評価する。この研究は、HQC のすべての関連するビルディングブロックをサイドチャネ
ルで安全に実装する必要性を再度強調するものである。

･A New Key Recovery Side-Channel Attack on HQC with Chosen Ciphertext [PQCrypto
2022]

Guillaume Goy, Antoine Loiseau, Philippe Gaborit
Hamming Quasi-Cyclic (HQC) は、NIST のポスト量子標準化手順のコードベース候補である。コードベース暗号の復号ステップはサイドチャネル攻撃に対して脆弱であることが知られており、HQC もその例外ではない。
本論文では、選択暗号文を用いた HQC に対する新しい鍵回復サイドチャネル攻撃が発表されている。本攻撃は、物理的にアクセス可能なマイコン上で静的秘密鍵が再利用されることを利用している。目標は、カプセル化解除の Reed-Muller 復号ステップ、より正確にはHadamard 変換をターゲットにして、静的な秘密鍵を回収することである。この関数はその拡散性で知られており、その性質をサイドチャネル解析により利用する。サイドチャンネルの情報は、Reed-Muller 符号のいくつかの復号パターンを区別するオラクルを構築するために使用される。このオラクルに対して、静的秘密鍵に関する完全な情報を与えるようなクエリを行う方法を示す。実験によれば、2 万回以下の電磁波攻撃痕跡で、復号に使用される静24

的秘密鍵のすべてを取得することができる。最後に、本攻撃を阻止するためのマスキングに基づく対策を提示する。

2.2.6. その他に関する解読技術動向･ Quantum Algorithms for Variants of Average-Case Lattice Problems via
Filtering [Eurocrypt 2022]

Yilei Chen, Qipeng Liu, Mark Zhandry
本論文では、以下の問題に対して、多項式時間量子アルゴリズムを示す。
・L∞ノルムにおける、公開行列が非常に大きく、多項式的に大きい素数を法とする、法の数の半分から定数を引いた値でノルムが抑えられている場合の、最小整数解問題（Short Integer Solution、SIS）。
・あるパラメータにおける Extrapolated dihedral coset problem（EDCP）。
・多項式的に大きいサイズの法と、有界一様分布やラプラス分布といった特定のエラー分布における LWE ライクな量子状態が与えられたときの、誤差付き学習問題（Learning-With-Errors、LWE）。
標準的な形式の SIS、EDCP、LWE 問題は、最悪の場合、格子問題を解くのと同じぐらい難しい。しかし、著者らが解くことのできる亜種の問題は、ワーストケースでの格子問題を解くのと同じくらい難しいことが知られているパラメータ領域にはない。ただ、SIS と LWE については、古典的なアルゴリズムも量子多項式時間アルゴリズムも知られていなかった。EDCP については、著者らの量子アルゴリズムは Ivanyos ら（2018）の結果をわずかに拡張している。SIS と EDCP の変種に対する本アルゴリズムは、それらの問題から LWE への（より正確には LWE ライクな量子状態を与えられた LWE を解く問題への）既存の量子簡約を使用している。主な貢献は、フィルタリング技術を用いて、興味深いパラメータを持つ LWE 的量子状態が与えられた場合に、LWE を解くことである。
･Orientations and the supersingular endomorphism ring problem [Eurocrypt 2022]

Benjamin Wesolowski
本論文では、同種を基礎とする暗号における二つの重要な問題族と、それらがどう関連しているかを研究している。一つ目は超特異楕円曲線の自己準同型環の計算、二つ目
は向きづけられた超特異曲線上の類群作用を用いた逆問題である。この 2 つの問題は、一般化リーマン仮説を仮定した多項式時間簡約によって、密接に関連していることが証明される。
著者は、本質的に等価な問題の 2 つのクラスを同定する。最初のクラスは、向きづけ

25

られた曲線の自己準同型環を計算する問題に対応する。CSIDH のような大規模な暗号シ
ステムの安全性は、劣指数時間で実行されるヒューリスティック量子アルゴリズムが知られている、このクラスに還元される。2 つ目のクラスは、向きづけ可能な曲線の自己準同型環の計算に対応する。本質的に全ての同種を基礎とする暗号系の安全性はこの第二のクラスに帰着されるが、このクラスでは、最もよく知られたアルゴリズムは未だに指数関数時間で実行されている。
本論文が提案する方式は、一般化だけでなく、既知の結果を強化するものもある。例
えば、𝔽𝑝 上で定義された曲線の場合、CSIDH の安全性は自己準同型環問題に劣指数時間で帰着できることが知られている。提案された方法は、CSIDH の安全性を多項式時間で自己準同型環問題に帰着する。また、そういった帰着はあり得ないと証明した議論にも反論している。
･Anonymity of NIST PQC Round 3 KEMs [Eurocrypt 2022]

Keita Xagawa
本論文では、NIST PQC Round 3 における全ての KEM の匿名性が調査される：Classic
McEliece、Kyber、NTRU、Saber、BIKE、FrodoKEM、HQC、NTRU Prime (Streamlined NTRU
Prime and NTRU LPRime)、SIKE が対象である。以下の結果が示されている。
・NTRU は決定論的 PKE が強く離散的シミュレーション可能であれば、量子ランダム
オラクルモデル (QROM) において匿名性を持つ。NTRU は QROM において無衝突である。
NTRU を KEM とし、適切な DEM から構成されるハイブリッド PKE 方式は匿名かつロバス
トである。BIKE, FrodoKEM, HQC, NTRU LPRime, SIKE についても同様の結果が、HQC の3 つのパラメータセットのうち 1 つを除いて成り立つ。
・古典的な McEliece は、基礎となる PKE が強く離散的シミュレーション可能で、KEMと適切な DEM として構築されたハイブリッド PKE スキームが匿名であれば、QROM において匿名である。
・Grubbs, Maram, Paterson は、Kyber と Saber が QROM における現在の IND-CCA セキ
ュリティ証明にギャップがあることを指摘した（EUROCRYPT 2022）。本論文では、Streamlined NTRU Prime にも QROM における IND-CCA セキュリティ証明のための技術的障害があることを示した。
これらは、Grubbs, Maram, and Paterson によって提起された NIST PQC Round 3 KEMsの匿名性と頑健性を調査する問題に答えるものである。以上の結果は、KEM の基礎となる PKE の強い disjoint-simulatability と、KEM の強い擬似ランダム性と、スムース性/スパース性を主なツールとして用いているが、これらは独立した興味を惹きうる。
･On the Impossibility of Key Agreements from Quantum Random Oracles [CRYPTO
2022]

26

Per Austrin, Hao Chung, Kai-Min Chung, Shiuan Fu, Yao-Ting Lin, Mohammad
Mahmoody
本論文では、2018 年に Hosoyamada と Yamakawa によって公に提起された以下の問題を研究する：局所的な量子計算能力を持つパーティ A、B は、ランダムオラクルと古典通信によってのみ鍵合意できるか？（A、B は量子重ね合わせでランダムオラクルを問い合わせることができることに注意せよ)。上記の質問について最初の進展を行い、次のことを証明する。
・一方が古典、他方が量子の場合、合計𝑑回のオラクル問い合わせを行い、確率 1 で鍵合意する限り、𝑂(𝑑2 )回の古典オラクル問い合わせで鍵合意を破る方法が常に存在する。
・両者がランダムオラクルに対して量子問合せを行える場合には、ある自然な予想が正しいと仮定した上で、ランダムオラクルに対する古典問合せがpoly(𝑑)回で攻撃できることを示した。この予想を大まかにいえば、任意の 2 つの次数𝑑の実係数多項式で、
influence（多項式係数の大きさのようなもの）が𝛿 = 1/poly(𝑑)で抑えられているならば、その積はブール超立方体上における値が非零である、という主張である。著者らは、指数関数的に小さい影響に対しこの予想を証明し、任意の鍵合意プロトコルに対する（無条件の）古典的な2𝑂(𝑚𝑑) 回クエリを行う攻撃（𝑚はランダムオラクルの出力長）を導き出す。
著者らの攻撃は古典的であるため、一般にそのような古典的な攻撃を見つけることが可能かどうかを問う。古典的なシミュレーションが可能であることを示す「シミュレーション予想」が偽であれば、古典的な敵によって破ることができない量子プロトコルが存在することになり、このアプローチに対する障壁を証明することができる。
･Some Easy Instances of Ideal-SVP and Implications to the Partial VandermondeKnapsack Problem [CRYPTO 2022]

Katharina Boudgoust, Erell Gachon, Alice Pellet-Mary
本論文では、Pan ら（Eurocrypt'21）と Porter ら（ArXiv'21）の研究を一般化し、理想格子が最短ベクトル問題（SVP）の容易なインスタンスを定義する簡単な条件を提供する。すなわち、イデアルを固定する自己同型が多いほど、最短ベクトルを見つけるのが容易になることを示す。この観測は、ガロア体における素イデアルに対して既になされていたが、著者らはこれを任意の数体の任意のイデアルであって、その素分解がramified でない場合に一般化する。この結果を暗号技術に応用し、部分的 Fourier 回復問題（partial Fourier recovery problem）としても知られる、部分的 Vandermonde
ナップザック問題の特定のインスタンスが、多項式時間で解けることを示す。さらに本
論文では、概念実証として、この攻撃を実装し、文献で提案されている具体的なパラメータ設定に対して、それらの特定のインスタンスを解くことに成功している。ランダム27

なインスタンスに対して、無視できない確率で格子の次元を半分にすることに成功している。
･Accelerating the Delfs-Galbraith algorithm with fast subfield root detection[CRYPTO 2022]

Maria Corte-Real Santos, Craig Costello, Jia Shi
本論文では、与えられた超特異楕円曲線𝐸/𝔽𝑝2 から部分体上の楕円曲線𝐸 ′ /𝔽𝑝 への同種を求める新しいアルゴリズムを与える。これは、一般的な超特異曲線同種問題に対する Delfs-Galbraith アルゴリズムのボトルネックとなるステップである。本手法の核となるのは、高価な根探索アルゴリズムを避けつつ、多項式𝑓 ∈ 𝐿[𝑋]が部分体𝐾 ⊂ 𝐿に根を持つかどうかを高速に決定する新しい方法である。多項式が超特異𝑗-不変量で評価されるℓ番目のモジュラー多項式 𝑓 = Φℓ,𝑝 (𝑋, 𝑗) ∈ 𝔽𝑝2 [𝑋] である特別な場合に、これは対応する楕円曲線と部分体上の曲線を結ぶℓ-同種が存在するかどうかを効率的に決定する方法を提供する。従来の Delfs-Galbraith ウォークと合わせて、この方法で多くのℓ-同種な近傍を調べることで、単位時間あたりの超特異曲線のより大きな割合を探索することができる。この改良されたアルゴリズムの漸近的な計算量 𝑂̃(𝑝1/2 ) は元の DelfsGalbraith アルゴリズムと変わらないが、本論文で為された理論解析と実際の実装は共に部分領域探索の実行時間を大幅に短縮することを示す。これは、一般的な超特異性同型問題（同型暗号の基礎となる問題）の具体的な難しさに新しい光を当て、DelfsGalbraith が最もよく知られた古典攻撃である B-SIDH や SQISign などのスキームのビットセキュリティに直接影響を与えるものである。
･Partial Key Exposure Attacks on BIKE, Rainbow and NTRU [CRYPTO 2022]

Andre Esser, Alexander May, Javier Verbel, Weiqiang Wen
いわゆる部分的鍵公開攻撃では、例えばサイドチャネルの漏洩によって秘密鍵に関する何らかの情報を得ることができる。この情報は秘密鍵のビット数の一部であったり（消去モデル）、秘密鍵の誤ったバージョンであったり（エラーモデル）する。目標は、漏洩した情報から秘密鍵を復元することである。RSA 暗号などとは対照的に、ほとんどのポスト量子暗号は鍵の部分的な漏洩攻撃に対して通常耐性があるという通説がある。
本論文は、コードベース、多変量、格子ベースの方式（BIKE、Rainbow、NTRU）に対する部分鍵公開攻撃を構築することで、この考え方に強く疑問を投げかけるものである。提案されている攻撃は、現代の耐量子計算機暗号が効率化のために本質的に使用している
冗長性を利用する。理論面では、多項式時間の鍵回復攻撃を可能にする非自明な情報漏
洩の境界を示す。例えば、全ての方式において、秘密鍵のビットの一定割合を知ること
で、多項式時間で完全な鍵を復元することができる。多項式時間攻撃にこだわらなくとも、著者らの攻撃のほとんどは、大きな消去率やエラー率まで十分に拡張でき、実行可28

能であり続ける。例えば、BIKE の場合、秘密鍵のビットの半分が消去された場合、または秘密鍵のビットの 4 分の 1 が欠陥のある場合に、60 ビット程度の攻撃複合度を得る
ことができた。この結果は、現代の耐量子計算機暗号システムにおいて、非常に誤りやすい鍵の漏洩であっても、秘密鍵の完全な復元が可能であることを示している。
･Improvement of algebraic attacks for superdetermined MinRank[PQCrypto 2022]

Magali Bardet, Manon Bertin
MinRank（MR）問題は、多くの暗号アプリケーションで発生する計算問題である。
PQCrypto 2019 にて Verbel らは、双線形 Kipnis-Shamir（KS）モデリングから始まる、
MinRank 問題の超決定インスタンスを解く新しい方法を紹介した。彼らは、特定のMacaulay 行列の線形代数を用い、変数の 1 ブロックによる初期方程式の倍数、いわゆ
るカーネル変数のみを考慮する。その後、ASIACRYPT 2020 にて Bardet らは、カーネル
変数に関連する Plücker 座標、すなわち、KS モデリングにおけるカーネル行列の最大小行列式を考慮した新しいサポートマイナーモデリング（Support Minors modeling,SM）を導入した。
本論文では、KS モデリングと SM モデリングの間のリンクについて、任意のインスタ
ンスについて完全な代数的説明を与える。そして、超決定 MinRank インスタンスは SM
モデリングの容易なインスタンスと見なすことができることを示す。特に、可能な限り小さい次数（"first degree fall"）と可能な限り小さい変数数で計算を実行することが、必ずしも最善の戦略ではないことを示す。一般的なランダムインスタンスに対する攻撃の計算量の推定値を与える。
これらの結果を、NIST の標準化プロセスの第一ラウンドに提出された DAGS 暗号に適用した。Bardet らで改良された Barelli と Couvreur による代数的攻撃は、特定のsuperdetermined MinRank インスタンスであることを示す。ここでは、インスタンスは
一般的なものではないが、DAGS から特定のインスタンスを解析し、特定のインスタン
スを解くために最適なパラメータ（短縮位置の数）を選択する方法を提供することが可能であることを示している。
･Attack on SHealS and HealS: the Secdond Wave of GPST [PQCrypto 2022]

Steven D. Galbraith, Yi-Fu Lai
Asiacrypt 2021 の Fouotsa と Petit の同種に基づく公開鍵暗号化方式 SHealS と HealS、および鍵交換方式 HealSIDH を暗号解析した。
本論文では、効率的で安全な静的-静的（static-static）鍵交換プロトコルや、同種からの公開鍵暗号化（PKE）を得ることをテーマとしている。静的-静的プロトコルは、参加者が公開鍵を随時変更することなく、目的のプリミティブを実行することを可能にする。これはCSIDH を用いて可能であり、CSIDH はいくつかの同種に基づく暗号プリミティブの構築に用29

いられている。
しかし（本論文が公開された当時は）、Kuperberg アルゴリズムに基づく CSIDH
に対する亜指数関数的な攻撃のため、SIDH がより強固な基盤を提供していた。同種からくる頑健な基礎仮定を持つ効率的なプロトコルは、いまだ未解決の問題である。
SIDH 系が静的-静的特性を実現するための主なボトルネックは、適応的 GPST 攻撃に集約される。この攻撃は、悪意のある Bob が Alice の秘密鍵を各ハンドシェイクからビット単位で抽出することを可能にし、その逆もまた可能である。この攻撃への対策としては、ゼロ知識証明の埋め込みや k-SIDH 法が知られている。しかしこれらの対策では、必然的に複数の並列な同種計算が発生するため、導出された方式は実用的ではない。これを解決するために、Fouotsa と Petit(Asiacrypt'21) は、同種図式の可換性を利用した新しい鍵検証機構を持つ SIDH の変種を発表した。この方式は、素数長を 2 倍にした SIKE よりも少ない同種計算で、上述の他の既知の解決策よりもはるかに効率的である。さらに、適応的な攻撃に耐える静的鍵交換と PKE 解を同種から与えられるということが主張されている。
本研究では、Fouotsa と Petit により提示されたプロトコルに対する適応的な攻撃を提示することで、この主張に反論している。本論文の攻撃は、彼らの中核的な成果である鍵検証
機構の欠陥に基づき、SHealS、HealS、HealSIDH を構築するものである。この攻撃は GPST 攻撃の単純な調整とみなすことができ、驚くべきことに、秘密鍵を適応的に回復するために、
SIDH に対する GPST 攻撃と同じ数のオラクルクエリーを必要とする。言い換えれば、追加の鍵検証機構は元の SIDH 方式に対してプロトコルを遅くするだけでなく、適応的攻撃を防ぐ
上でこの方式に利点を与えないということを著者らは主張している。

･Post-Quantum Insecurity from LWE [TCC 2022]

Alex Lombardi, Ethan Mook, Willy Quach, Daniel Wichs
本論文では、多くの基本的な暗号プリミティブについて、 learning-with-errors(LWE) 仮定の下で古典的な安全性を証明しても、量子後の安全性が保証されないことを示す。これは、
LWE がポスト量子的安全性を持つと広く信じられているにもかかわらず、証拠は与えられていないことを意味している。その代わりに、たとえ仮定がポスト量子的安全性であっても、暗号構成内部でポスト量子的安全性の欠如が生じうることを示している。具体的には、擬似乱数関数、CPA 暗号、メッセージ認証コード、署名、CCA 暗号など、ブラックボックス化による LWE で古典的に安全であることが証明されているが、ポスト量子安全性が証明されていない暗号を構築している。これらの暗号方式はすべてステートレスで非対話的だが、攻撃者が暗号方式に対してオラクルクエリーを行う
ことができる対話型ゲームによってその安全性が定義されている。多項式時間量子攻撃
者は、暗号システムに対して数回の古典的なクエリを行うだけでこれらの方式を破ることができ、場合によっては 1 回のクエリで十分な場合もある。これまでは、ステートフ
ルもしくは対話的なプロトコルに対して、ポスト量子仮定での安全性の欠如を示す例しかなかった。さらに、ブラックボックス安全性証明を持つステートレスもしくは非対話

30

的暗号システムについては、方式に対する量子攻撃は仮定に対する量子攻撃に変換されるはずだというフォークロアに対し、本研究はそうではないことを示している。主な手法は、上記のプリミティブの対話型セキュリティゲーム内に対話型プロトコルを注意深く埋め込むことである。また、古典的な送信者と受信者の間で、量子受信者が 3 ラウン
ド目に秘密メッセージを知るが、LWE を仮定すると古典的受信者は知らない、3 ラウン
ドの "quantum disclosure of secrets（QDS）"プロトコルを示したのも興味深い結果である。
･The Parallel Reversible Pebbling Game: Analyzing the Post-Quantum Securityof iMHFs [TCC 2022]

Jeremiah Blocki, Blake Holman, Seunghoon Lee
古典的な（並列）石移動ゲーム（以下、pebbling ゲーム）は、静的なデータ依存グラ
フを持つ関数の評価に必要なリソース（空間、時空間、累積メモリ）を分析することができる、有用な抽象化である。暗号分野で特に興味深いのは、有向非循環グラフ（DAG）
𝐺と暗号ハッシュ関数𝐻によって定義されるデータ非依存な memory-hard 関数𝑓𝐺,𝐻 である。グラフ𝐺の pebbling 計算量は、𝑓𝐺,𝐻 を複数回評価するコストと、関数𝑓𝐺,𝐻 の固定された定義域に対するブルートフォース原像攻撃に対する総コストを特徴付けるものである。古典的な攻撃者は関数𝑓𝐺,𝐻 を、少なくとも定義域の濃度（＝𝑚とする）回評価する必要があるが、Grover のアルゴリズムを実行する量子攻撃者は関数𝑓𝐺,𝐻 を評価する量
子回路𝐶𝐺,𝐻 への、ブラックボックス呼び出しを𝑂(√𝑚)回行うだけで済む。したがって、
量子攻撃のコストを分析するためには、量子回路𝐶𝐺,𝐻 の時空間コスト（幅×深さ）を理解することが極めて重要である。
古典的な計算では、グラフ𝐺に対する効率的な pebbling 戦略は𝑓𝐺,𝐻 を評価するアルゴ
リズムに相当するが、本研究ではまず、グラフ𝐺に対する pebbling 戦略は必ずしも同等の計算量を持つ量子回路の存在を意味しないことを指摘している。この観測を動機として、新しい並列な可逆（reversible）ペブリングゲームが導入され、量子計算機における量子削除不可能定理（No-Deletion Theorem）によって課される追加的な制限を捕らえる。この新しい可逆 pebbling ゲームを応用して、いくつかの重要なグラフの可逆時
空間計算量が解析された：線グラフ、Argon2i-A、Argon2i-B、そして DRSample である。
具体的には、以下が為されている(1) サイズ𝑁の線グラフに対しては、可逆的な時空間計算量が最大 𝑂(𝑁1+2/√log 𝑁 ) であることを示す。
(2) 任意の (𝑒, 𝑑)-簡約 DAG に対しては、可逆時空間計算量が 𝑂(𝑁𝑒 + 𝑑𝑁2𝑑 ) である
ことを示す。特に、Argon2i-A と Argon2i-B の可逆時空間計算量はそれぞれ最大𝑁2

𝑂(𝑁 2 log log 𝑁/√log 𝑁)、𝑂((log 𝑁)1/3 )であることが示唆される。

31

(3) DRSample に対しては、可逆時空間計算量が最大𝑂(𝑁 2 log log 𝑁/ log 𝑁)であることを示す。また、Alwen and Blocki の深さ可変型グラフに対する（非可逆）pebbling
攻撃を拡張した可逆 pebbling の累積 pebbling コストについて研究する。
･Full Quantum Equivalence of Group Action DLog and CDH, and More [Asiacrypt2022]

Hart Montgomery, Mark Zhandry
暗号学的群作用は、標準的な暗号群を緩和し、構造を少なくしたものである。構造を持たないことで、Shor のアルゴリズムがあるにもかかわらず、もっともらしく量子耐性を持ち、なおかつ多くの応用が可能である。群作用の最も有名な例は、楕円曲線の同種から構築されたものである。
本論文の主結果として、アーベル群作用に対する CDH は離散対数問題と量子的に等価であるということが証明された。Galbraith らは以前、CDH を完全に解くと量子的に離散対数問題と等価であることを示したが、この結果はどんな無視できない優位性（nonnegligible advantage）に対しても有効である。また、群作用と同種プロトコルに関す
る他のいくつかの問題についても検討している。
･Cryptographic Primitives with Hinting Property [Asiacrypt 2022]

Navid Alamati, Sikhar Patranabis
Hinting PRG は、PRG のシードに関する循環安全性（circular security）の「決定論的」な形式を持つ PRG の（潜在的に）より強い亜種である（Koppula and Waters, CRYPTO 2019）。
ヒンティング PRG は、多くの暗号アプリケーション、特に CCA 安全な公開鍵暗号とトラップドア関数を可能にする。本論文では、Hinting 性質を持つ暗号プリミティブを研究し、以下の結果を得ている。
・Hinting PRG の設計において、巡回群や同種ベースの群作用に対するある種の決定論的仮定から、より概念的に単純な新規のアプローチを提示することで、既存のアプローチと比較してより単純な安全性証明を可能にした。
・Hinting 性質を弱 PRF に自然に拡張した Hinting 弱 PRF を導入し、任意の Hinting 弱
PRF から循環もしくは KDM 安全な共通鍵暗号を実現する方法を示す。Hinting PRG を構築するための単純なアプローチは、同じ決定論的仮定の集合から Hinting 弱 PRF を実現するために拡張できることを実証する。
・Hinting 性質の強化版である機能的 Hinting 性質を提案し、秘密のシードや鍵の関数に関するヒントが存在する場合でも安全性を保証する。本論文では、平易な Hinting PRG および Hinting 弱 PRF を実現するための簡単な技術を基に、特定の関数（族）に対する機能的な
Hinting PRG および Hinting 弱 PRF を実現する方法を示す。また、ある種の代数的特性を持つ帰納的 Hinting 弱 PRF が、ブラックボックス方式で KDM 安全な公開鍵暗号を実現する

32

上で適用可能であることを実証する。
・最後に、ランダムオラクルだけが与えられたこれらのプリミティブの単純な実現を使って、Hinting 弱 PRF（および Hinting PRG）を公開鍵暗号からブラックボックス的に分離できることを示す。

･A New Isogeny Representation and Applications to Cryptography [Asiacrypt2022]

Antonin Leroux
本論文では、次数𝐷の巡回同種が存在する超特異楕円曲線𝐸1 と𝐸2 による三つ組(𝐷, 𝐸1 , 𝐸2 )の集合におけるメンバーシップの知識として定義される、同種表現について研究している。
このメンバーシップ証明は、電子署名の構築や暗号鍵の検証など、いくつかの基本的な暗号学的応用があることが知られている。本論文の前半では、同種についての既知の結果を言語と証明の枠組みで再解釈し、同種表現が NP に属することを Deuring 対応から自然に導く。
本論文の主な貢献は、（大きな）素数の場合を対象とした新しい同種表現である suborder
表現を設計したことである。新手法の核心は、余定義域の自己準同型環から注意深く選ばれた suborder 内の smooth ノルムの自己準同型を明らかにすることである。著者らは、これらの新しいメンバーシップの証明は、SubOrder to Ideal Problem (SOIP)という新しい計算問題の困難性の仮定の下で、同系列に基づく暗号の興味深い展望を開くだろうと主張している。特にその応用として、suborder 表現に基づく新しい NIKE である pSIDH が紹介されている。またその過程で、ある quaternion order の新しい族の中でノルムの等式を解くいく
つかのヒューリスティックなアルゴリズムツールが開発された。これらの新しいアルゴリ
ズムは、独立した興味を持たれるかもしれない。

･Group Action Key Encapsulation and Non-Interactive Key Exchange in the QROM
[Asiacrypt 2022]

Julien Duman, Dominik Hartmann, Eike Kiltz, Sabrina Kunzweiler, Jonas Lehmann,
Doreen Riepel
耐量子計算機暗号の文脈では、暗号学的群作用は、CSIDH における同種ベース暗号の一般化である。本研究では、過去に提案された 2 つの自然なプロトコル、群作用ハッシュ ElGamal
鍵カプセル化（Group Action Hashed ElGamal key encapsulation mechanism、GA-HEG KEM）と、群作用ハッシュ Diffie-Hellman 非対話鍵交換（Group Action Hashed Diffie-Hellman
non-interactive key-exchange、GA-HDH NIKE）の安全性についての再検討が行われている。
後者のプロトコルは、既に Post-Quantum WireGuard (S&P '21) や OPTLS (CCS '20) などの実用的なプロトコルで利用が検討されている。
本研究で、量子ランダムオラクルモデル（QROM）における 2 つのプロトコルのアクティブ
安全性（active security）は、DDH オラクルへの任意の量子アクセスをもつ攻撃者に対す

33

る群作用強 CDH 問題（Group Action Strong CDH）の非常に強い亜種に本質的に依存することが証明される。さらに、古典的な強い CDH 仮定、すなわち DDH オラクルへの古典的なアクセスを持つ CDH から、QROM の安全性を持つプロトコル変形が提案される。最初の変形は、
鍵確認を用いるため、KEM の設定にのみ適用可能である。提案された第二の、しかしかなり効率の悪い変形は、Cash ら(EUROCRYPT '08)による技術に基づいている。特に、標準 CDH 仮
定から、QROM 安全性を備えたアクティブ安全性を持つ最初の同種ベースの NIKE を生成する。

･Horizontal racewalking using radical isogenies [Asiacrypt 2022]

Wouter Castryck, Thomas Decru, Marc Houben, Frederik Vercauteren
本論文では、Castryck, Decru, Vercauteren が Asiacrypt 2020 で発表した、有限体上の楕円曲線間の間の、固定された小さな次数の長い列の計算における根基同種（ radical
isogeny）の使用に関する 3 つの主な未解決問題を扱う。まず、与えられた次数 N の根基同種を求めるための補間法を提示し、大きな関数体上の多項式を因数分解する必要を回避する。この方法を用いることで、𝑁 ≦ 13から𝑁 ≦ 37という範囲まで、自由に公式を求めることができる範囲を拡大できる。次に、既知の手法とアドホックな操作を組み合わせて、N≤19
に対してこれらの公式の最適化版を導き出すことで、いくつかのインスタンスを 2020 年に得られたものより 2 倍以上高速に実行した。第三に、𝑝 ≡ 7 (mod 8)の場合の𝔽𝑝 上の、曲面に沿った超特異楕円曲線間のウォーク（すなわち、𝔽𝑝 上の自己準同型環がℤ[

1+√−𝑝
2

]となる超

特異楕円曲線の間の同種写像たち）において、根基同種を正しく選択する問題を解決した。
これは𝑁が偶数の場合非自明で、𝑁 = 4では PKC2022 で Onuki と Moriya によって初めて解決した。著者らは、𝑁が偶数の場合の予想を建て、𝑁 ≤ 14に対してそれを証明する。これらの手法により、次のように CSIDH の実質的な高速化が得られた：次数16の同種を用いて、512ビットの素数体上での次数2の同種の長い列の計算が 3 倍に、根基同種を用いた CSIDH の実
装が 12%程度高速化された。

･Log-𝓢-unit lattices using Explicit Stickelberger Generators to solve Approx
Ideal-SVP [Asiacrypt 2022]

Olivier Bernard, Andrea Lesavourey, Tuong-Huy Nguyen, Adeline Roux-Langlois
2020 年、Bernard と Roux-Langlois は、Pelle-Mary, Hanrot, Stehlé による PHS アルゴ
リズムに基づき、任意の数体上の理想格子に対する Approx-SVP を解く Twisted-PHS アルゴ
リズムを発表した。彼らは、拡大次数高々70かつ素数導手を持つ円分体上で実験し、主なボトルネックの 1 つは、log-𝒮-unit の格子の計算で、劣指数時間が必要であることを示した。
本論文の主な貢献は、これらの実験をほとんどの導手𝑚に対して拡大次数 210 までの円分体に拡張したことである。Bernard と Kučera による Stickelberger ideal の新しい結果に基34

づいて、フルランク log-𝒮-unit 部分格子を構築するために明示的な生成器を用いて、完全な Twisted-PHS 格子の近似の役割を果たすことができる。最良の近似領域において、本論文の結果は、Twisted-PHS アルゴリズムが Cramer、Ducas、Wesolowski による CDW アルゴリズ
ムを彼らの実験範囲において上回り、時にはその漸近ボリューム下限を破ることを示す。さ+らに、類数のプラス部分が ℎ𝑚≤ 𝑂(√𝑚) であるという穏やかな制約のもと、これらの明示的な Stickelberger 生成器を用いて、CDW アルゴリズムのほぼ全ての量子ステップを削除することができる。

･A Non-heuristic Approach to Time-space Tradeoffs and Optimizations for BKW[Asiacrypt 2022]

Hanlin Liu, Yu Yu
NTRU 問題は、格子の中に例外的に短い非零ベクトルを含むという仮定のもとで、短い非零ベクトルを見つけるインスタンスとみなすことができる。さらに対象となる格子は、数体の整数環上の階数 2 の加群構造を持っている。この問題を加群一意最短ベクトル問題（module unique shortest vector problem）、略して mod-uSVP と呼ぶことにする。本論文
では、NTRU 問題が mod-uSVP の単なる特殊なケースではなく、計算の観点からそれを代表するものであることを証明する 2 つの簡約法が示される。まず、ワーストケースの mod-uSVP
をワーストケースの NTRU に還元する。これは、理想格子における短い非零ベクトルを求める問題である id-SVP のオラクルに依存している。そして、Pellet-Mary and Stehlé[ASIACRYPT'21]のワーストケース id-SVP からワーストケース NTRU への削減法を用いて、ワーストケース NTRU がワーストケース mod-uSVP と等価であることが示される。第二に、
mod-uSVP のランダムな自己帰着を行う。著者らは mod-uSVP のインスタンスに対する、とある分布 D を提案している。
この分布 D において無視できない確率でサンプリングされる moduSVP を解くことで、mod-uSVP をワーストケースで解くことができる。最初の結果を用いると、ワーストケースの mod-uSVP から、分布が D から継承されている場合での、平均的な
NTRU インスタンスを解くことができるようになる。このワーストケースを解くことから平均的な場合を解くことへの帰着は、id-SVP のオラクルを必要としている。

･Nostradamus goes Quantum [Asiacrypt 2022]

Barbara Jiabao Benedikt, Marc Fischlin, Moritz Huppert
Kelsey と Kohno によって導入された Nostradamus 攻撃（Eurocrypt 2006）では、攻撃者はイテレーションされたハッシュ関数𝐻のハッシュ値𝑦をコミットする必要がある。
また後に与えられたプレフィックス𝑃に対して、攻撃者は𝐻(𝑃||𝑆) = 𝑦となる適切な"suffix explanation" 𝑆 を見つけることができなければならなかった。Kelsey とKohno は、𝐻の圧縮関数（出力と状態が𝑛ビット）の22𝑛/3 回の評価による集め攻撃（herding attack）を示し、この攻撃を計算量の点で原像攻撃と衝突探索の間に位置づ

35

けた。
本論文は、量子敵対者に対する Nostradamus 攻撃の安全性を調査し、Nostradamus 問
題に対して量子集め攻撃アルゴリズムを提案した。これは𝑛1/3 23𝑛/7 回の圧縮関数への代入を行うものであり、古典ケースにおける評価を大幅に改善している。また、量子集
め攻撃は23𝑛/7 回の代入では実行できないことを証明し、著者らのアルゴリズムが（本質的に）最適であることを示す。また、ランダムな圧縮関数に対する一般的な Nostradamus
3𝑛

攻撃について、およそ2 7 −𝑠 回の評価についても議論されている（ここで𝑠は敵対的に選択したサフィックス𝑆の最大ブロック長である）。

36

資料３－３2022 年度暗号技術評価委員会
1

電子メールによる審議とその結果

目的
CRYPTREC 暗号リストの改定のため、暗号技術検討会がパブリック・コメント（意見公募手続）
を 2 月中に開始する予定である。2022 年度第二回暗号技術評価委員会の開催日は、2023 年 2 月
27 日（月）であるため、パブリック・コメント開始までに CRYPTREC 暗号リストに係る審議を終えておく必要がある。そのため、以下の内容を電子メールによる審議扱い1としたい。

2

審議内容
2.1 富士通株式会社からの暗号技術取り下げ申請への対応
ECDSA、ECDH 及び SC2000 の応募暗号について取り下げの申請（表 1）があったため、暗号技術評価委員会として以下の対応（表 2）を行う。

表 1：暗号技術取下げ申請書からの抜粋（表現は若干変更）
取り下げ理由暗号アルゴリズムを取り巻く状況の変化により、窓口を継続する必要性がなくなったため。

ECDSA 及び ECDH主流となっている AES などの標準と同様の取り扱いとして欲しい。

SC2000

普及していないため、取り下げの影響はない。

表 2：取り下げへの対応案
理由
ECDSA 及び ECDH

取り扱いを応募暗号技術から CRYPTREC が選出した暗号技術に変更し、現
状通り、電子政府推奨暗号リストに記載しておくことは妥当であると判断する。仕様書の参照先についても変更無しとする。

SC2000

応募者（社）の判断を尊重し、取り下げを認める。推奨候補暗号リストか
ら当該暗号技術を削除することは妥当であると判断する。

2.2 CRYPTREC 暗号リスト改定に係る暗号技術の選定
毎年実施している暗号技術の安全性及び実装に係る監視及び評価 2の活動に伴う小改定を経て、現在の CRYPTREC 暗号リストを維持してきている。
2.1 節の事項以外で、今年度の監視活動による変更がなければ、CRYPTREC 暗号リスト改定

1

暗号技術評価委員会の運営方針 項番 4
「CRYPTREC 暗号等の監視」、「電子政府推奨暗号リストからの運用監視暗号リストへの降格、並びに、推奨候補暗号リスト及び運用監視暗号リストからの危殆化が進んだ暗号の削除」及び「推奨候
補暗号リストへの新規暗号（事務局選出）の追加」の 3 つの活動
2

1

に係る暗号技術の構成は現状のままとする。

3. 審議結果
電子メールによる審議の結果、委員から異論がなかったため、原案のとおり承認とする。
以上

2

資料３－４2022 年度暗号技術調査 WG（耐量子計算機暗号）活動報告
1. 2022 年度暗号技術調査 WG（耐量子計算機暗号）活動報告の概要
2020 年度第 2 回暗号技術検討会において、耐量子計算機暗号ガイドラインを作成するために暗号技術調査ワーキンググループ(耐量子計算機暗号)（以下：PQC WG）を設置することが承認された。
2022 年度第 1 回暗号技術評価委員会において、2021 年度と同様に、PQC WG において下記 2 点について実施することが承認された。
(1) 耐量子計算機暗号の研究動向調査をもとに、主要な耐量子計算機暗号についてのガイドライン
を 2021 年度から 2022 年度にかけて作成する。
(2)「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図を更新する。

2. 委員構成（敬称略）
主査：國廣 昇（筑波大学）
委員：青木 和麻呂（文教大学）
委員：伊藤 忠彦 （セコム）
委員：草川 恵太（NTT）
委員：下山 武司（国立情報学研究所）
委員：高木 剛（東京大学）
委員：高島 克幸（早稲田大学）
委員：廣瀬 勝一 （福井大学）
委員：安田 貴徳（岡山理科大学）
委員：安田 雅哉（立教大学）

3. 耐量子計算機暗号ガイドラインの案の作成
3.1. スケジュール（2021 年度第 1 回暗号技術評価委員会で承認）
年度

回耐量子計算機暗号ガイドラインの議論・決定・報告

2021

第1回

記載すべき項目及びその章立てを議論

年度(9 月初旬頃を記載する暗号方式の選定基準を議論想定）記載する暗号方式の候補を議論
執筆担当者を議論

第2回

章立ての決定(2 月を想定)記載する暗号方式の選定基準の決定記載する暗号方式の候補の決定
執筆担当者の決定

2022

第1回

年度

(8 月下旬頃を

執筆内容の中間報告

想定)
第2回

執筆内容の最終報告(2 月を想定)

3.2. 2021 年度第 1 回 PQC WG（9/7）での実施内容及び決定事項


ガイドライン及び調査報告書の作成
ガイドラインは暗号理論に精通していない利用者を、調査報告書は暗号理論の研究者や技術者を対象とする。そのため、基本的にはガイドラインは調査報告書から技術的詳細を省き、その一部を抜粋したものとする。ただし、暗号理論に精通していない利用者のために、PQC の活用
方法をガイドラインでは記載し、調査報告書には記載しない。



記載すべき項目及び章立てと執筆担当者
執筆担当者
i. はじめに事務局（青野、篠原、高安）

ii. PQC の活用方法（ガイドラインのみ） 伊藤委員（ガイドラインのみ）

iii. 格子に基づく暗号技術

下山委員、安田（雅）委員、事務局（青野）iv. 符号に基づく暗号技術

草川委員

v. 多変数多項式に基づく暗号技術

安田（貴）委員

vi. 同種写像に基づく暗号技術

高島委員vii. ハッシュ関数に基づく署名技術

廣瀬委員

ガイドライン及び調査報告書に記載する暗号方式の選定基準及び候補について
公開鍵暗号を中心にまとめる。主要な暗号方式（NIST PQC 標準化への提案方式等）を記載す
るが、対象とする暗号方式は執筆担当者が選定する。



2021 年度第 2 回 PQC WG での調査内容の報告について各章の執筆担当者が 2021 年度第 2 回 PQC WG において、その時点までの調査内容を報告する。

3.3. 2021 年度第 2 回 PQC WG（1/28）での実施内容及び決定事項


調査内容の報告について各章の執筆担当者が 2021 年度第 2 回 PQC WG において、その時点までの調査内容を報告した。



ガイドラインの案及び調査報告書の案の執筆方針について
執筆方針が決定された。

3.4. 2022 年度第 1 回 PQC WG（9/26）での実施内容及び決定事項


ガイドラインの案及び調査報告書の案の執筆に関する中間報告
各章の執筆担当者が、ガイドラインの案及び調査報告書の案に執筆する内容の概要について節単位で説明することで、PQC WG において執筆内容を確認し、修正案等について議論した。



2022 年度第 2 回 PQC WG までのスケジュールについて
2022 年度第 1 回 PQC WG での議論を基に、各章の執筆担当者及び担当事務局員の合意の取れた原稿を 2023 年 1 月 16 日を目処に完成させることが決定された。
【各章の執筆担当者と担当事務局員】
執筆担当者

担当事務局員2 章：PQC の活用方法

伊藤委員

篠原

3 章：格子に基づく暗号技術

下山委員、安田雅哉委員 青野

4 章：符号に基づく暗号技術

草川委員

高安

5 章：多変多項式に基づく暗号技術

安田貴徳委員篠原

6 章：同種写像に基づく暗号技術

高島委員

横山

7 章：ハッシュ関数に基づく署名技術

廣瀬委員

五十部、大東3.5. 2022 年度第 2 回 PQC WG（1/30）での実施内容及び決定事項


ガイドラインの案及び調査報告書の案の執筆に関する最終報告
各章の執筆担当者が、ガイドラインの案及び調査報告書の案に執筆する内容の概要について節単位で説明することで、PQC WG において執筆内容を確認し、修正案等について議論した。



ガイドライン及び調査報告書を公開するまでのスケジュール
以下の項目が決定された。



ガイドライン及び調査報告書の発行日を 2023 年 3 月とする。



ガイドライン及び調査報告書を 2023 年 4 月に Web で公開する。

ガイドラインの案の目次については資料 3-5 別紙を参照

4. 「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新
4.1. 予測図の更新に関する説明文の修正【現状】<今後の予測図の取扱い>(1) 予測図を従来通り、いわゆるムーアの法則を仮定して外挿線を年度末からプラス20年後まで直線で引き、評価に大きな変動がないと考えられる限りにおいては、安全サイドに倒した評価として当面の間更新していく。なお、予測図は各国・国際標準化機関等により示されている主要な暗号技術の安全性基準と比較すると、より現状に則した評価であり、危殆化時期がそれらよりも先に延びるものとなっている。
<今後の公開鍵暗号のパラメータ選択>(2) 公開鍵暗号のパラメータ選択に関する対応方針については、安全性以外にも相互接続性など、運用上の観点もあるため、今後は、暗号技術評価委員会だけではなく、暗号技術検討会、暗号技術活用委員会や関係各所などを含めて検討する。
【修正案】＜今後の予測図の取り扱い＞(1) 予測図を従来通り、いわゆるムーアの法則を仮定して外挿線を年度末からプラス20年後まで従来どおり直線で引き、評価に大きな変動がないと考えられる限りにおいては、安全サイドに倒した評価※として予測図を当面の間更新していく。なお、予測図は各国・国際標準化機関等により示されている主要な暗号技術の安全性基準と比較すると、より現状に即した評価であり、危殆化時期がそれらよりも先に延びるものとなっている。
<今後の公開鍵暗号のパラメータ選択>(2) 公開鍵暗号のパラメータ選択に関する対応方針については、安全性以外にも相互接続性など、運用上の観点もあるため、今後は、暗号技術評価委員会だけではなく、暗号技術検討会、暗号技術活用委員会や関係各所などを含めて検討する。
※各国・国際標準化機関等により示されている主要な暗号技術の安全性基準と比較すると、より現状に即した評価となっており、危殆化時期は他機関等が規定している暗号技術の利用期限よりも先に延びている。

(1)の修正について
・「予測図を」が述語と離れているので、近づけた。（→予測図を当面の間更新していく。）
・「従来通り」が修飾する語と離れているので、近づけた。（→従来どおり直線で引き）
・「なお、～」は、安全サイドに倒した評価の意味を補う意味で付けた文章であるので、予測図の取り扱いから外して、注として付ける。
・第一回WG時の指摘とおりに、「則した」及び「それらよりも」を修正した。
(2)の修正について
・「今後は、」はタイトルと意味が重複するので、削除した。

4.2. 2022 年度予測図の更新
素因数分解問題の困難性および楕円曲線上の離散対数問題の困難性に関する計算量評価に大幅な進展はなかったため、2022 年 6 月・11 月のベンチマーク結果を追加して予測図の更新を行った(図 1、2）。

図 1：素因数分解の困難性に関する計算量評価(2023 年 1 月更新)

図 2：楕円曲線上の離散対数計算の困難性に関する計算量評価(2023 年 1 月更新)
以上

資料３－５CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）
CRYPTREC 暗号技術調査ワーキンググループ（耐量子計算機暗号）2023 年 3 月

目次
第1章

はじめに

1

1.1

耐量子計算機暗号 (PQC) の必要性について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

PQC の研究及び標準化等に関する動向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.3

本調査で対象とした PQC の種類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51.4

耐量子計算機暗号ガイドライン執筆者リスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

第 1 章の参照文献

7

第2章

11

2.1

2.2

2.3

PQC の活用方法

暗号の利用形態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1

署名用途での公開鍵暗号の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2

守秘用途での公開鍵暗号の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3

鍵共有用途での公開鍵暗号の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

各利用形態における課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1

署名用途での課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2

守秘用途での課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3

鍵共有用途での課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

各利用形態における対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1

署名用途固有の対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2

秘匿及び鍵共有用途固有の対策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3

耐量子計算機暗号の活用方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

第 2 章の参照文献

18

第3章

20

3.1

3.2

3.3

格子に基づく暗号技術

格子に基づく暗号技術の安全性の根拠となる問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1

LWE 問題の紹介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2

NTRU 問題の紹介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.3

格子問題の公開チャレンジの求解状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

代表的な格子に基づく暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1

Hash-and-Sign に基づく署名方式の格子問題への拡張 . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2

Fiat-Shamir 署名方式の格子問題への拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

格子に基づく主要な暗号方式. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

i

3.4

3.3.1

CRYSTALS-Kyber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.2

CRYSTALS-Dilithium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.3

FALCON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

格子に基づく暗号技術に関するまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

第 3 章の参照文献

37

第4章

42

4.1

符号に基づく暗号技術

符号に基づく暗号技術の安全性の根拠となる問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1

LPN 問題とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.2

LPN 問題の拡張 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.3

4.2

4.3

4.4

4.1.2.1

復号問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.2.2

シンドローム復号問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.2.3

Module-LPN 問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

LPN 問題に対する評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.3.1

BKW アルゴリズムおよびその改良 . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.3.2

Arora-Ge アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.3.3

SD 問題を経由するアルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.3.4

量子アルゴリズムへの耐性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.3.5

現状の進展. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

代表的な符号に基づく暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1

暗号方式 1: McEliece 暗号

4.2.2

暗号方式 2: Niederreiter 暗号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

符号に基づく主要な暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1

暗号方式 1: Classic McEliece . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.2

暗号方式 2: BIKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.3

暗号方式 3: HQC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

第 4 章の参照文献

54

第5章

59

5.1

5.2

多変数多項式に基づく暗号技術

多変数多項式に基づく暗号技術の安全性の根拠となる問題 . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.1

MP 問題（MQ 問題） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.2

MinRank 問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.3

IP 問題，EIP 問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

代表的な多変数多項式に基づく暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.1

双極型システム5.2.2

HFE 方式，HFEv-方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.2.1

暗号方式 HFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.2.2

署名方式 HFEv-. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63ii

5.2.3
5.3

多変数多項式に基づく主要な暗号方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1

5.4

署名方式 Rainbow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
署名方式 UOV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1.1

UOV の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1.2

UOV のパラメータ選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

多変数多項式に基づく暗号技術に関するまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

第 5 章の参照文献

68

第6章

70

6.1

6.2

同種写像に基づく暗号技術
同種写像に基づく暗号技術の安全性の根拠となる問題

6.1.1

同種写像問題の一般形 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.2

自己準同型環計算問題と SQISign 署名方式の安全性に関する計算問題

6.1.2.1

自己準同型環計算問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.2.2

SQISign 署名の安全性に関する計算問題 . . . . . . . . . . . . . . . . . . . . . . . . 73

GPS 署名. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

同種写像に基づく主要な暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.3.1
6.4

. . . . . . . . . . . . . 72

代表的な同種写像に基づく暗号方式の説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.1
6.3

. . . . . . . . . . . . . . . . . . . . . . . . . . 70

SQISign 署名. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

同種写像に基づく暗号技術に関するまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

第 6 章の参照文献

80

第7章

82

ハッシュ関数に基づく署名技術

7.1

ハッシュ関数に基づく署名技術の安全性の根拠となる問題 . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2

代表的なハッシュ関数に基づく署名方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.3

7.2.1

Winternitz One-Time Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.2

マークル木を用いた署名方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2.3

マークル木の階層構造による署名方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2.4

プレフィクスとビットマスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

主要な具体的なハッシュ関数に基づく署名方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3.1

7.3.2

XMSS: eXtended Merkle Signature Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3.1.1

WOTS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3.1.2

XMSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.3.1.3XMSSM T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.3.1.4

パラメータの設定と安全性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

SPHINCS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3.2.1

WOTS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.3.2.2

HT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.3.2.3

FORS (Forest Of Random Subsets) . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.3.2.4

SPHINCS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

iii

7.4

7.3.2.5

パラメータの設定と安全性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.3.2.6

ハッシュ関数の実現法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

ハッシュ関数に基づく署名技術に関するまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

第 7 章の参照文献

96

iv

第1章

はじめに
現在広く使用されている公開鍵暗号方式として RSA 暗号と楕円曲線暗号が挙げられる．RSA 暗号と楕円曲線暗号が安全であるために，素因数分解問題や楕円曲線上の離散対数問題が計算量的に困難であることが必要であり，現在普及しているコンピュータでは効率的に解くことはできないと信じられている．ただし，量子コンピュータの開発が十分に進むと Shor のアルゴリズム [39, 40] により整数の素因数分解や離散対数を高速に計算できるため，RSA 暗号と楕
円曲線暗号の安全性は大きく低下する．そのため，古典コンピュータ*1 上で効率的な実装が可能であり，なおかつ古典・量子双方のコンピュータを用いた攻撃に対しても安全性を確保できる公開鍵暗号方式が必要とされており，そのよ
うな暗号方式は耐量子計算機暗号 (Post-Quantum Cryptography: PQC) とよばれている．同様に，共通鍵暗号方式においても量子コンピュータによって安全性は低下することが知られているが [16]，公開鍵暗号に比べるとその影響は小さいと考えられている．その根拠として，電子政府推奨暗号の安全性を評価・監視し，暗号技術の適切な実装法・運用法を調査・検討するプロジェクトである CRYPTREC （図 1.1）による，量子コンピュータに対する共通鍵暗号の安全性の影響に関する 2019 年度の調査 [12] を挙げる．これらを踏まえ，本ガイドライン及び調査報告書において PQC
は共通鍵暗号方式を含まず，公開鍵暗号方式を意味する．本ガイドライン及び調査報告書は PQC に関する内容をまとめたものである．

図 1.1: 2022 年度 CRYPTREC 体制図*1 量子コンピュータに対して，現在普及しているコンピュータを古典コンピュータと呼ぶことにする．

1

近年の世界的な量子コンピュータの開発にともない，PQC に関する研究及びその標準化に向けた活動も世界各国の組織で実施されており，国内でも PQC の研究動向を把握する必要性が高まっている．2020 年度第 2 回暗号技術検討会において，2021 年度から暗号技術評価委員会の活動計画として 2 年をかけて PQC の研究動向を調査し，ガイドラ
インを作成することが決定された．暗号技術評価委員会は暗号技術調査ワーキンググループ (耐量子計算機暗号) を設置し，2021 年度及び 2022 年度において本ガイドライン及び調査報告書を作成した．
本調査では PQC の代表的な候補である 5 種類の分類（格子に基づく暗号技術，符号に基づく暗号技術，多変数多項式に基づく暗号技術，同種写像に基づく暗号技術，ハッシュ関数に基づく署名技術）について調査し，主に 2022 年 9月 30 日までの調査結果をガイドラインと調査報告書にまとめた．ガイドラインは暗号初学者を対象としており，調査報告書は暗号についての知見のある技術者や専門家を対象としている．ガイドラインと調査報告書の 1 章は共通であり，一般的な読者にむけた内容としてまとめた．ガイドラインの第 2 章には暗号初学者向けに PQC の活用方法に関する内容，特に守秘・鍵共有・署名のための PQC の利用などについてを記載しており，この章は調査報告書には記載していない．ガイドラインの第 3 章以降，そして調査報告書の第 2 章以降で，暗号技術に携わる研究者及び技術者を読者として想定し，PQC の代表的な候補である 5 種類の分類をまとめた．ただし，これらの章ではガイドラインの記
載内容は調査報告書の抜粋となっており，ガイドラインでは専門的な内容を省略し，暗号初学者が代表的な PQC 方式
を把握するために最小限の内容のみを記載した．

1.1 耐量子計算機暗号 (PQC) の必要性について
量子コンピュータは重ね合わせ・エンタングルメント等の量子的な物理現象を用いて計算を行うコンピュータの総称である [49, 22]．基本的な計算操作と物理的操作の対応関係を表すモデルにより，量子回路型計算，測定型量子計算，
断熱型量子計算，トポロジカル量子計算，ホロノミック量子計算等に大別できる*2 ．上記分類とは別に，量子アニーリ*3 これらのうち，超伝導，イオントラッ
ング (Quantum Annealing: QA) と呼ばれる計算フレームワークが存在する．

プによる量子回路型コンピュータおよび，超伝導磁束量子ビットによる量子アニーリングを行うコンピュータは物理的なハードウェアの進化とプログラミング環境の進化により商用レベルにまで達し，非専門の技術者レベルでもクラウドを通じた利用が容易となったことから注目されている．そのため，冒頭に挙げた基本的操作の種類による分類の他に，応用目的の文脈から量子回路型と量子アニーリング型のみを取り上げそれぞれ量子ゲート型と量子アニーリング型という名称で対比されることもある [49, 第 2 章, p.11]．
超伝導を用いた量子回路型コンピュータの開発は米国の民間企業を中心にここ数年で急速に進展しており，2019 年

10 月に Google が 53qubits [1]，2021 年 12 月には Rigetti が 80qubits [36]，2022 年 11 月には IBM が 433qubitsのプロセッサ [20] を発表している．また，中国においても中国科学技術大学が 66qubits の祖沖之 2.1 [52] を，百度

(Baidu) が 2022 年 8 月に 10qubits コンピュータ [6] を発表している．日本でも富士通が 2023 年度中の 64qubits 量子コンピュータの公開を目指している [37]．超伝導方式以外の開発も進んでおり，イオントラップ式では 2020 年 10 月に IonQ が 32qubits [8]，2022 年 6 月には Quantinuum が 20qubits [35] を発表している．シリコン量子ビット式ではIntel，日立製作所が開発を進めている [45]．
2020 年代終盤までのロードマップとして 10-100 万 qubits を搭載し，量子誤り訂正を組み込むことによりほぼノイ
ズの無い量子回路型コンピュータの開発目標が Google, IBM 等から公表されている．なお，量子コンピュータの性能*2 この分類に関しては [22, 47] および [42, Sect 1.6] を参照．
*3 元々はシミュレーテッドアニーリング (Simulated Annealing: SA) に類似したアルゴリズムを量子的に構成した Apolloni ら [2] によりこの名前が付けられたが，現在では断熱計算のモデル [3, Def. 1] における条件を開放系，有限時間に緩め，ハミルトニアンをイジングモデルに制限したものと見做されているようである [34, § 3]．

2

を十分に引き出す強力なアルゴリズムを実現するためには量子ビット数のみではなく，量子誤り訂正，量子ランダムア
クセスメモリ等，2022 年現在では実用化されていない技術を用いる必要があり，それらの開発スピードの予測困難性
が，量子コンピュータの暗号に与える影響を予測する際の難所となっている．
量子コンピュータによる現代暗号への脅威: Peter Shor による素因数分解問題と離散対数問題に対する量子多項式時
間アルゴリズム [40] が発表されて以降，数千 bits の RSA 暗号を危殆化させる量子コンピュータの規模，実現時期の見積りに関する研究が進められている [15, 17, 43, 4, 28, 30, 31]．特に，現在標準的に用いられている，2048bits の合成数を公開鍵とする RSA 暗号 RSA-2048 の危殆化時期に関して様々な予測が存在する．学術的な研究に基づいたもの
では 2039 年以降 [43]，2050 年前後 [4] と少なくとも 20 年程度は実現に時間がかかるとされている．量子コンピュー
ティングの専門家へのアンケートを元にした 2021 年時点での予測 [31] では 24 時間で RSA-2048 を解読可能な量子コンピュータが 15 年以内に出現する可能性が 50% 程度であると考える専門家が半数程度存在する．文部科学省 科学技術・学術政策研究所（NISTEP）による科学技術予測調査 [32, p. (II-4)48,52] ではある程度コヒーレンス時間の長い
数百 qubits 規模の量子回路コンピュータの登場は 2033 年頃としているため，現代暗号に対して脅威となる量子コン
ピュータが出現するのはそれ以降と解釈できる．一方で，セキュリティ分野の専門家の予測では，PQCrypto2014 の招待講演における Mariantoni の予測では 2029 年 [28]，Workshop on Cybersecurity in a Post-Quantum World (2015年) における Mosca の予測では 2026-2031 年 [30] と若干早めの時期を想定している．
将来的に RSA 暗号が危殆化すると考える専門家が多数存在する一方で，量子コンピュータ実機を用いた素因数分解
問題及び離散対数計算の実験は小規模なものに留まっている．量子回路型コンピュータ実機を用いた Shor のアルゴリ
ズムの実験に関しては，CRYPTREC 外部調査報告書「Shor のアルゴリズム実装動向調査」[17] に挙げられているもの及びその後の [24, 44, 48] を含めて 15，21，35 の素因数分解実験および離散対数問題 2z ≡ 1 (mod 3) の離散対数の計算実験を行ったもののみである．Shor のアルゴリズムを用いた初期の報告は N = 15 の素因数分解回路の量子フーリエ変換部分を除いた部分回路を実装する予備実験的なもの，位数や N の情報を用いて過度な簡略化を行ったものが多かった．しかし，近年では IBM Quantum を用いてほぼ完全な回路を実装した実験報告 [5] や離散対数問題の実装実
験報告 [4] が出版されるなど，実際に素因数分解できた合成数の大きさには表れない量子回路規模の拡大は着実に続いている．

Shor のアルゴリズムを用いない素因数分解の計算手法として，2 進数乗算の筆算形式で式展開したものを，組み合わせ最適化問題として定式化するものがある．特に，量子アニーリングを用いた実験がこの 10 年間で多数報告されている．初期にはハミルトニアンに合わせて有機化合物を合成し NMR 測定により結果を取り出すという手法で計算を行っていたためスケーリングが困難であったが，D-Wave 社の量子アニーリングマシンが利用可能になって以降は実験報告が相次いでいる [50]．素因数分解のターゲットとなる数は着実に大型化しており，実機を用いた最も大きな実験 [23]では 19bits の合成数 376289=571×659 の分解に成功しているが，その要因は主に方程式内の変数の省略によるものである．また，同様の組み合わせ最適化問題を量子回路型コンピュータの上で Quantum Approximate Optimization

Algorithm (QAOA) を用いて解く実験 [27](143，291311 を分解)，Digitized adiabatic quantum computation を用
いて解く実験 [19](2479 を分解) も報告されている．量子回路型コンピュータ上で QAOA を用いた素因数分解問題へのアプローチとして，Schnorr アルゴリズム [38] の部分的な量子化の研究が存在する．Schnorr アルゴリズムは数体篩
法の関係探索を係数制限付きの近似最近ベクトル問題に変換して行うが，[51] ではこれをさらに最適化問題に落とし込
み，QAOA を 10qubits 回路上で実行することで 48bits の素因数分解実験を行ったという報告がされている．

PQC の必要性について: 上述のように，現代暗号に対する量子コンピュータの直接的な脅威は現時点では生じていな
い．しかし，上に挙げた民間企業のロードマップが予定通りに達成された場合には，今後数十年で現代暗号の解読を行うのに十分な大きさの量子計算を実行可能な量子コンピュータが開発される可能性がある．そのような量子コンピュー3表 1.1: NIST 耐量子計算機暗号 Call for proposal[33] における安全性レベルと計算量の対応表
レベル

量子回路の最大深さ

古典論理ゲート数

レベル 1

2170

2143

レベル 2

–

2146

レベル 3

2233

2207

レベル 4

–

2210

レベル 5

2298

2272

タが出現した場合，守秘・鍵共有に用いられる現代の暗号方式の中で素因数分解問題や離散対数問題の計算困難性に基づいた RSA 暗号・楕円曲線暗号が危殆化するリスクがある．暗号方式の提案から社会的な普及までは RSA 暗号・楕
円曲線暗号で 20 年ほどの期間が必要とされたことから，PQC の場合でも同程度の期間が必要と想定されるため，長期間の移行スケジュールを策定し，準備を行う必要がある．

1.2 PQC の研究及び標準化等に関する動向
PQC に関する研究成果は Crypto，Eurocrypt，Asiacrypt 等，暗号分野の国際会議で 1980 年代から議論されている．さらに PQC を専門に扱う国際会議として PQCrypto が挙げられ，その第 1 回会議は 2006 年に開催され，2022
年までに計 13 回開催されている．

PQC の標準化に関する近年の動向については，まず 2015 年 8 月，アメリカ国家安全保障局 (NSA) は PQC への
将来的な移行計画を発表している．また，アメリカ国立標準技術研究所 (NIST) は 2016 年から PQC の公募を開始
し，その締切である 2017 年 11 月 30 日までに 82 件の暗号方式が提案され，そのうち公募条件を満たした暗号方式
は 69 件あり，その後 5 件の取り下げがあった．2019 年 1 月 30 日には，NIST から PQC の標準化の第 2 ラウン
ドへ進む方式として 26 件が発表された．2020 年 7 月 22 日には，NIST から PQC の標準化の第 3 ラウンドへ進む
方式として，Finalist として 7 件，Alternate Candidates として 8 件が発表された．そして，2022 年 7 月 5 日には，

NIST から標準化方式として公開鍵暗号方式 1 件と電子署名方式 3 件が発表された．同時に，第 4 ラウンドへ進む方
式として，公開鍵暗号方式として 4 件が発表され，電子署名方式については再公募を行うこととした．欧州では ETSIが PQC の調査活動を行い [14]，ISO/IEC でも標準化に向けた議論が始まっている [21]．

NIST の標準化において，安全性をレベル 1 から 5 で定義しており，各暗号方式は提案パラメータとそれによって達成される安全性レベルを示す必要があった．レベル 1, 3, 5 はそれぞれ AES128, AES192, AES256 などの 128,

192, 256bits の秘密鍵を持つブロック暗号の秘密鍵探索と同等かそれ以上の計算量であり，レベル 2 と 4 はそれぞれ
SHA256/SHA3-256 と SHA384/SHA3-384 などの 256bits と 384bits の暗号学的ハッシュ関数の衝突探索と同等かそれ以上の計算量とされている．ここで，公開鍵暗号では，適応的選択暗号文攻撃に対する識別不可能性（IND-CCA2安全性）を考える際には 264 個以下の選択暗号文を復号オラクルに古典的にクエリできるとし，電子署名では，適応的選択文書攻撃に対する存在的偽造困難性（EUF-CMA 安全性）を考える際には 264 個以下のメッセージを署名オラク
ルに古典的にクエリできるとしている．計算時間を制限するために，量子コンピュータを利用可能な攻撃者に対しては量子回路の最大の深さによって，古典コンピュータを利用可能な攻撃者に対しては古典論理ゲート数によってレベル 1から 5 の安全性における計算量を評価しており，それぞれ表 1.1 のようになると見積もっている [33]．

CRYPTREC の暗号技術調査ワーキンググループにおいても 2014 年度に PQC の代表的な候補である格子に基づ4

く暗号技術について調査を行い，報告書「格子問題等の困難性に関する調査」を公開している [10]．さらに 2017 年度
から 2018 年度にかけて，PQC の代表的な候補である 4 種類の分類（格子に基づく暗号技術，符号に基づく暗号技術，
多変数多項式に基づく暗号技術，同種写像に基づく暗号技術）について調査し，報告書にまとめた [11]．

1.3 本調査で対象とした PQC の種類
この節では本調査の対象として格子に基づく暗号技術，符号に基づく暗号技術，多変数多項式に基づく暗号, 同種写像に基づく暗号技術，ハッシュ関数に基づく署名技術を選択した理由及びその説明に必要な事項について述べる．
代表的な公開鍵暗号方式は，その安全性が数学的な計算問題の困難性と関わりがある．例えば RSA 暗号では，二つの同程度の大きさでかつ異なる素数 p, q が秘密鍵，それらの積 N = pq が公開鍵として使用される．N が素因数分解されると秘密鍵 p, q が計算されてしまい，RSA 暗号は解読されてしまう．楕円曲線暗号の場合も楕円曲線暗号の公開鍵から楕円曲線上の離散対数問題が定義され，それを解くことでその秘密鍵が計算できてしまう．本ガイドライン・報
告書で扱う代表的な 5 種類の PQC (格子に基づく暗号技術，符号に基づく暗号技術，多変数多項式に基づく暗号技術,
同種写像に基づく暗号技術，ハッシュ関数に基づく署名技術) も RSA 暗号と同様に，それらの安全性はそれぞれで利用される数学的な計算問題の困難性と関わりがある．そして，これらの問題を量子コンピュータを利用して効率よく解くアルゴリズムはまだ発見されていないことが，それら 5 種類の暗号方式が PQC とされている理由である．（本調査の対象である暗号方式と数学的な計算問題の関係は各章の第１節で説明する．）
同種写像に基づく暗号技術を除く 4 種類の暗号技術の研究の歴史は長く，格子に基づく暗号技術は 20 年以上，符号に基づく暗号技術は 40 年以上，多変数多項式に基づく暗号技術は 30 年以上，ハッシュ関数に基づく署名技術は 40
年以上研究が行われている．従って，本調査ではこれらの暗号技術を有力な PQC として調査した．同種写像に基づ
く暗号技術は新しい暗号技術ではあるが，研究が近年活発に進められており，また，NIST の PQC に関する報告書

NISTIR 8105 において，同種写像に基づく暗号技術は代表的な PQC として扱われている．(上述の各暗号方式の歴的な事実については各章の第 4 節に記載した．) 以上の理由から，本調査ではこれら 5 種類の暗号技術を調査対象とした．

5

1.4 耐量子計算機暗号ガイドライン執筆者リスト
主査

國廣 昇

筑波大学

委員

青木 和麻呂

文教大学

委員

伊藤 忠彦

セコム株式会社

委員

草川 恵太

日本電信電話株式会社

委員

下山 武司

国立情報学研究所

委員

高木 剛

東京大学

委員

高島 克幸

早稲田大学

委員

廣瀬 勝一

福井大学

委員

安田 貴徳

岡山理科大学

委員

安田 雅哉

立教大学

事務局

野島 良

国立研究開発法人情報通信研究機構

事務局

青野 良範

国立研究開発法人情報通信研究機構

事務局

五十部 孝典

国立研究開発法人情報通信研究機構

事務局

伊藤 竜馬

国立研究開発法人情報通信研究機構

事務局

大久保 美也子

国立研究開発法人情報通信研究機構

事務局

大東 俊博

国立研究開発法人情報通信研究機構

事務局

小川 一人

国立研究開発法人情報通信研究機構

事務局

金森 祥子

国立研究開発法人情報通信研究機構

事務局

黒川 貴司

国立研究開発法人情報通信研究機構

事務局

高安 敦

国立研究開発法人情報通信研究機構

事務局

横山 和弘

国立研究開発法人情報通信研究機構

事務局

吉田 真紀

国立研究開発法人情報通信研究機構

事務局

篠原 直行

国立研究開発法人情報通信研究機構

6

第 1 章の参照文献[1] F. Arute, K. Arya, R. Babbush , D. Bacon, J. Bardin, R. Barends, R. Biswas, S. Boixo et al. Quantum
supremacy using a programmable superconducting processor. Nature, 574, 505-510, 2019.
[2] D. de Falco, B. Apolloni, N. Cesa-Bianchi. A numerical implementation of “quantum annealing.” Proceedings
Of the Ascona-Locarno conference, 97-111, 1988.
[3] T. Albash, D. A. Lidar. Adiabatic quantum computation. Reviews of Modern Physics, vol. 90, Iss. 1, 015002,
2018.
[4] Y. Aono, S. Liu, T. Tanaka, S. Uno, R. Van Meter, N. Shinohara, R. Nojima. The present and future of
discrete logarithm problems on noisy quantum computers. IEEE Transactions on Quantum Engineering,
vol. 3, 1-21, 2022.
[5] M. Amico, Z. H. Saleem, M. Kumph. Experimental study of Shor’s factoring algorithm using the IBM Q
Eexperience. Physical Review A, vol. 100, 012305, 2019.
[6] ACM NEWS. China’s Baidu unveils 10-qubit quantum computer. https://cacm.acm.org/news/264095chinas-baidu-unveils-10-qubit-quantum-computer/fulltext, 2022-08-26.

（2023-01-23 閲覧）[7] J. Buchmann, E. Dahmen, M. Szydlo. Hash-based Digital Signature Schemes. Post-Quantum Cryptography,
35-93, 2009.
[8] P. Chapman,

Introducing the world’s most powerful quantum computer. https://ionq.com/posts/

october-01-2020-introducing-most-powerful-quantum-computer, 2020-10-01.（2023-01-23 閲覧）[9] L. Chen, S. Jordan, Y.-K. Liu, D. Moody, R. Peralta, R. Perlner, D. Smith-Tone. Report on Post-Quantum
Cryptography. NISTIR 8105, https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf, 2016.
[10] CRYPTREC. 格子問題等の困難性に関する調査. CRYPTREC Report 2014, https://www.cryptrec.go.jp/
exreport/cryptrec-ex-2404-2014.pdf, 2015.
[11] CRYPTREC. 耐量子計算機暗号の研究動向調査報告書. CRYPTREC Report 2018, https://www.cryptrec.
go.jp/report/cryptrec-tr-2001-2018.pdf, 2018.
[12] CRYPTREC. 量子コンピュータが共通鍵暗号の安全性に及ぼす影響の調査及び評価. CRYPTREC Report 2019,https://www.cryptrec.go.jp/exreport/cryptrec-ex-2901-2019.pdf, 2019.
[13] CRYPTREC. Shor のアルゴリズム実装動向調査. CRYPTREC Report 2020, https://www.cryptrec.go.
jp/exreport/cryptrec-ex-3005-2020.pdf, 2020.
[14] ETSI.

Quantum-Safe Cryptography. https://www.etsi.org/technologies-clusters/technologies/

quantum-safe-cryptography. （2023-03-15 閲覧）[15] C. Gidney, M. Ekerå. How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits. Quantum,
5, 433, 2021.

7

[16] L. K. Grover. A fast quantum mechanical algorithm for database search. Proceedings of the 28th Annual
ACM Symposium on the Theory of Computing, 212-219, 1996.
[17] É. Gouzien, N. Sangouard. Factoring 2048-bit RSA integers in 177 days with 13 436 qubits and a multimodememory. Physical Review Letters, 127, 2021.
[18] A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. XMSS: eXtended Merkle Signature Scheme.
RFC8391, https://tools.ietf.org/html/rfc8391, 2018-05. （2023-01-23 閲覧）[19] N. N. Hegade, K. Paul, F. Albarrán-Arriagada, X. Chen, E. Solano. Digitized adiabatic quantum factorization. Physical Review A, 104, 2021.
[20] IBM.

IBM、400 量 子 ビ ッ ト 超 え の 量 子 プ ロ セ ッ サ ー と 次 世 代 IBM Quantum System Two を発表. https://jp.newsroom.ibm.com/2022-11-10-IBM-Unveils-400-Qubit-Plus-Quantum-Processor-

and-Next-Generation-IBM-Quantum-System-Two, 2022-11-10.（2023-01-23 閲覧）[21] ISO.

PQCRYPTO: Post-quantum cryptography for long-term security. https://www.iso.org/

organization/5984715.html.
[22] 伊藤公平. 量子計算. 電子情報通信学会 知識の森, S2 群（ナノ・量子・バイオ）5 編（量子通信と量子計算）, https://www.ieice-hbkb.org/files/ad_base/view_pdf.html?p=/files/S2/S2gun_05hen_03.pdf,

2010.
[23] S. Jiang, K. A. Britt, A. J. McCaskey, T. S. Humble, S. Kais. Quantum Annealing for Prime Factorization
Scientiﬁc Reports, vol. 8, 17667, 2018.
[24] E. G. Johansen, T. Simula. Prime number factorization using a spinor Bose-Einstein condensate inspired
topological quantum computer. Quantum Information Processing, vol. 21, 31, 2022.
[25] J. Kelly. A preview of bristlecone, Google’s new quantum processor. https://ai.googleblog.com/2018/03/a-preview-of-bristlecone-googles-new.html, 2018-03-05. （2023-01-23 閲覧）[26] N. Kunihiro. Quantum factoring algorithm: Resource estimation and survey of experiments. International
Symposium on Mathematics, Quantum Theory, and Cryptography. Mathematics for Industry, vol. 33. 39-55,
2021.
[27] L. Qiu, M. Alam, A. Ash-Saki, S. Ghosh. Resiliency analysis and improvement of variational quantum
factoring in superconducting qubit. ISLPED ’20: Proceedings of the ACM/IEEE International Symposiumon Low Power Electronics and Design, 229-234, 2020.
[28] M. Mariantoni, Building a superconducting quantum computer. PQCrypto 2014, Invited talk, 2014-10-01.
[29] E. Martı́n-López, A. Laing, T. Lawson, R. Alvarez, X. -Q. Zhou, J. L. O’Brien. Experimental realization of
Shor’s quantum factoring algorithm using qubit recycling. Nature Photonics, vol. 6, num. 11, 773-776, 2012.
[30] M. Mosca. Cybersecurity in a quantum world: will we be ready?

Workshop on Cybersecurity in a

Post-Quantum World, https://csrc.nist.gov/csrc/media/events/workshop-on-cybersecurity-ina-post-quantum-world/documents/presentations/session8-mosca-michele.pdf, 2015-04-03.（202301-23 閲覧）[31] M. Mosca, M. Piani.

2021 Quantum threat timeline report:

Global risk institute. https://globalriskinstitute.org/publication/2021-quantum-threat-timeline-report-global-riskinstitute-global-risk-institute/, 2022-01-24.（2023-01-23 閲覧）[32] 文部科学省 科学技術・学術政策研究所科学技術予測センター. 第 11 回科学技術予測調査 デルファイ調
査. https://nistep.repo.nii.ac.jp/?action=repository_uri&item_id=6692&file_id=13&file_no=3,

8

2020-06.
[33] NIST. Submission requirements and evaluation criteria for the post-quantum cryptography standardization process. https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/
call-for-proposals-final-dec-2016.pdf, 2016.
[34] 大関 真之. 量子アニーリングが拓く機械学習と計算技術の新時代. 数理解析研究所講究録, 2059（量子システム推定の数理）, 13-23, 2017.

[35] Quantinuum. Quantinuum sets new record with highest ever quantum volume. https://www.quantinuum.
com/news/quantinuum-completes-hardware-upgrade-achieves-20-fully-connected-qubits,

2022-

06-14. （2023-01-23 閲覧）[36] Rigetti.

Rigetti Computing announces next-generation 40Q and 80Q quantum systems. https://investors.rigetti.com/news-releases/news-release-details/rigetti-computing-announcesnext-generation-40q-and-80q-quantum, 2021-12-15. （2023-01-23 閲覧）[37] 佐藤 信太郎. 量子コンピューティング：現状と産業化への課題 (量子技術の実用化推進 WG 第 3 回資料）.
https://www8.cao.go.jp/cstp/ryoshigijutsu/jitsuyo_wg/3kai/siryo2-3.pdf, 2022-12-06.
[38] C. P. Schnorr. Fast factoring integers by SVP algorithms, corrected. Cryptology ePrint Archive, 2021/933,
2021.
[39] P. W. Shor. Algorithms for quantum computation: discrete logarithms and factoring. 35th Annual Symposium on Foundations of Computer Science, 124-134, 1994.
[40] P. W. Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum
Computer. SIAM J. Comput., volume 26, number 5, 1484-1509, 1997.
[41] 清水 俊也, 伊豆 哲也, 篠原 直行, 盛合 志帆, 國廣 昇. アニーリング計算による素因数分解について. 2019 年 暗号と情報セキュリティシンポジウム, SCIS 2019, 2B4-3, 2019.

[42] S. P. Jordan. Quantum computation beyond the circuit model. arXiv, 0809.2307, 2008.
[43] J. Sevilla, C. J. Riedel. Forecasting timelines of quantum computing. arXiv, 2009.05045, 2020.
[44] U. Skosana, M. Tame. Demonstration of Shor’s factoring algorithm for N = 21 on IBM quantum processors.
Scientiﬁc Reports, 11, Article number 16599, 2021.
[45] 鈴 木教 洋.

日 立 の 量 子 コ ン ピ ュ ー タ 研 究 開 発 戦 略. https://www8.cao.go.jp/cstp/ryoshigijutsu/

jitsuyo_wg/3kai/siryo2-2.pdf, 2022-12-06.
[46] L. M. K. Vandersypen, M. Steﬀen, G. Breyta, C. S. Yannoni, M. H. Sherwood, I. L. Chuang, Experimental
realization of Shor’s quantum factoring algorithm using nuclear magnetic resonance. Nature, vol. 414, 883887, 2001.
[47] D. -S. Wang. A comparative study of universal quantum computing models: Toward a physical uniﬁcation.
Quantum Engineering, vol. 3, Iss. 4, e85, 2021.
[48] W. Wang, Z. You, S. Wang, Z. Tang, H. Ian. Computing Shor’s algorithmic steps with classical light beams.
Scientiﬁc Reports, vol. 12, Article number: 21157, 2022.
[49] 山本 俊. 量子情報技術（令和 3 年度 科学技術に関する調査プロジェクト）. 国立国会図書館調査及び立法考査局， 2022.

[50] 山口 純平, 伊豆 哲也. イジング計算を用いた暗号解析について. オペレーションズ・リサーチ. vol. 67, 290-296,
2022.
[51] B. Yan, Z. Tan, S. Wei, H. Jiang, W. Wang, H. Wang, L. Luo, Q. Duan et al. Factoring integers with9

sublinear resources on a superconducting quantum processor. arXiv, 2212.12372, 2022.
[52] Q. Zhu, S. Cao, F. Chen, M. -C. Chen, X. Chen, T. -H. Chung, H. Deng, Y. Du et al. Quantum
computational advantage via 60-qubit 24-cycle random circuit sampling. Science Bulletin, vol. 67, num. 3,
240-245, 2022.

10

第2章

PQC の活用方法
現在社会において，公開鍵暗号は様々な局面で利用されている．本節では，公開鍵暗号の幾つかの利用形態を紹介
し，それらの利用形態における量子コンピュータによる脅威，及び脅威への対策を記載する．また，公開鍵暗号に対する脅威を検討する上では，暗号の利用形態のほかに，保護対象となるデータの保護期間も重要となる．そこで本章では，利用形態や保護対象を踏まえた対策について概説する．

2.1 暗号の利用形態
公開鍵暗号には幾つかの利用形態が存在するが，本書では「電子政府における調達のために参照すべき暗号のリスト」（以下，CRYPTREC 暗号リストと呼ぶ）に合わせ，公開鍵暗号を署名・守秘・鍵共有に分類し，以降その分類に沿って記載する．

2.1.1 署名用途での公開鍵暗号の利用
本節では，署名を付与する行為を「デジタル署名処理」と呼び，付与される署名データを「デジタル署名」と呼ぶ．
デジタル署名が付与されたコンテンツを改竄すると，その改竄を確認することができる．そのため，署名用途の公開鍵暗号を用い，コンテンツにデジタル署名を付与することで，コンテンツの改竄を防止することができる．コンテンツはドキュメントデータであることもあれば，鍵情報*1 を含むこともある．また，デジタル署名処理に用いられる秘密鍵が，（対応する公開鍵を含む電子証明書等により）所定の人物等と紐づいている場合においては，コンテンツの生成者等を確認（認証）することもできる．このように署名用途の公開鍵暗号は，コンテンツの改竄防止，署名者等の認証，
データ元の認証等に利用される．
具体的な署名用途の公開鍵暗号の利用例としては，TLS 通信 [4] におけるクライアント認証やサーバ認証，OSのコードサイン等に広く利用されている．また，公開鍵の配布手段の 1 種である公開鍵暗号基盤（PKI）においても，電子証明書 [1] 等の形態で広く利用されている．加えて，タイムスタンプ署名 [2] では，コンテンツに対して署名が付与された時刻を確認するために利用されている．CRYPTREC 暗号リストには，DSA，ECDSA，RSA-PSS，

RSASSA-PKCS1-v1 5 及び EdDSA が署名用途の公開鍵暗号として記載されている．

*1 鍵情報には暗号鍵やメタテ゛ータを含まれ [16]，公開鍵暗号の鍵のみではなく共通鍵暗号の鍵に関する情報も含む概念となる.

11

2.1.2 守秘用途での公開鍵暗号の利用
守秘用途の公開鍵暗号によって暗号化された暗号文は，対応する秘密鍵なしに解読することは困難となる．そのため，守秘用途の公開鍵暗号は，意図した相手にデータを提示する為に利用できる．暗号化処理による保護は，ドキュメ
ントデータ等に対して行われることもあれば，別の暗号鍵の鍵情報*2 に対して行われることもある．保護が鍵情報に対して行われる具体的なユースケースとしては，鍵情報を通信当事者間で共有する場合や，暗号鍵所有者がその鍵情報をバックアップする場合等が該当する．
守秘用途及び鍵共有用途の公開鍵暗号の一般的な実装形態として，公開鍵暗号により共通鍵暗号の共通鍵を保護し，またその共通鍵を利用した共通鍵暗号によりコンテンツの秘匿性や完全生を保護するというアプローチが存在する．
守秘用途の公開鍵暗号を上記アプローチで用いる場合においては，共通鍵暗号の共通鍵は送信者により作成され，配送される．このアプローチにおいて仮に，ある時点で秘密鍵が漏洩した場合，過去にその秘密鍵を持つ利用者に対して配送された共通鍵暗号の共通鍵が漏洩するおそれがある．また，受信者は共通鍵の生成に関わることができず，仮に送信者が別の通信相手との共通鍵暗号の共通鍵を使い回し等していても察知することができない．そのため，昨今のTLS 通信等における共通鍵の共有においては，秘匿用途の公開鍵暗号でなく，（次節の）鍵共有用途での公開鍵暗号を
一時的（Ephemeral) な鍵を用いて利用することが望ましいと考えられるようになった [16, 7]．なお，「TLS 暗号設定
ガイドライン」[16] においても，鍵交換（鍵共有・守秘）においては，Perfect Forward Security（PFS）の特性をもつ

DHE（または ECDHE）を選択するのがセキュリティ上望ましいと記載されている．CRYPTREC 暗号リストには，
RSA-OAEP 及び RSAES-PKCS1-v1 5*3 が守秘用途の公開鍵暗号として記載されている．また，RFC7525 においても [7]，4.1 節において（守秘用途である）RSA key tranport は利用すべきでないと記載されており，4.2 節でも一時的（Ephemeral) な鍵を用いる暗号スイートが推奨されている．

2.1.3 鍵共有用途での公開鍵暗号の利用
鍵共有用途での公開鍵暗号は，鍵共有に参加する２者が，同一の鍵情報*4 を共有するために利用される．守秘用途の
公開鍵暗号を２者間の通信で利用する場合は，任意のコンテンツに対する暗号処理を実施できる．一方，鍵共有用途の
公開鍵暗号を２者間の通信で利用する場合，そこで共有されるものは，（共通鍵暗号や公開鍵暗号等の）何らかの暗号
アルコリズムで利用するための暗号鍵となる．
近年利用されている２者間鍵共有を目的とした多くの公開鍵暗号プロトコルにおいては，鍵共有に参加する双方ともが何らかの値を生成し，その値に対して秘密鍵を使用した計算を行う．結果として，共有される鍵には双方の生成した値が何らかの影響を与えることとなり，一方のみの計算で暗号鍵を導出することができない．そのため，守秘用途でのデータ送付と異なり，送信者が予め意図した特定の鍵を，共有鍵として利用することはできない．CRYPTREC 暗号
リストには，DH，ECDH，及び PSEC-KEM が鍵共有用途の公開鍵暗号として記載されている．

2.2 各利用形態における課題
Michel Mosca [3] によると，量子コンピュータによる攻撃の脅威は，保護対象の暗号の保護期間を X 年，暗号処理の実装の置き換えに要する期間を Y 年，暗号解読に利用可能な量計算機が実現するまでの期間を Z 年としたときに，*2 秘密鍵，共通鍵，鍵導出鍵，及びそれら鍵のメタデータを含む．
*3 守秘用途の RSAES-PKCS1-v1 5 は，運用監視暗号リストに記載されており，互換性維持以外での利用は推奨されていない．
*4 共通鍵暗号の共通鍵，鍵導出機能の鍵やパラメータ等

12図 2.1: Mosca の発表 [3] より

これらが X ＋ Y > Z である場合には，心配する必要があるとしている（図 2.1）
．もっとも，暗号解読が可能な量子コンピュータの実現時期は未だ不透明であり，Z を予想するのは難しい．また X は，暗号のみならず，保護対象となるデータの性質等によっても大きく異なる．保護対象となるデータに対して，保護期間が設定されていない場合などは，X を導出することが難しいこともありうる．加えて Y は，暗号の実装形態により大きく変化する．また，X 及び Y
は，暗号システムの運用を通して，将来において変動することもありうる．
上記を踏まえ，ある公開鍵暗号アプリケーションが与えられた時に，その公開鍵暗号アプリケーションが量子コンピュータの脅威について備える必要性があるかを判断しようとした場合において，Z は不確定であり，X や Y も将来においては変動しうるため，判断が難しいという課題がある．ここで，保護対象となるデータに保護期間が設定されていない場合においては，判断に先駆けて（X 導出のために）データの保護期間を決定する必要があり，場合によっては判断に必要な情報を収集するために相当の期間を要する可能性もある．
なお，多様な暗号ライブラリが，耐量子計算機暗号を相互運用可能な形態で受け入れるためには，共通の OID(Object

Identiﬁer) 体系を利用することが望ましい．この OID 体系については，IETF にて標準化が進んでおり [15, 14]，近い将来に解決されることが見込まれているため，以降は議論しない．

2.2.1 署名用途での課題
署名用途の公開鍵暗号は，コンテンツの改竄防止，認証等に利用されるが，ユースケースによって脅威の性質は大きく異なる．例えば，TLS 通信 [4] におけるクライアント認証やサーバ認証においては，認証用に付与されたデジタル署
名の検証を行うのはその場限りとなり，それほど長期間に渡り検証されるわけではない．一方で，電子データに対するドキュメント署名や，バイナリデータに対するコードサインであれば，署名対象のデータを利用する人が存在する限り（数十年に渡り）デジタル署名が検証されることもありうる．特に，後者においては，仮に電子証明書に有効期間等が記載されていたとしても，その有効期間満了後にも検証されることが十分に考えられる．このように，デジタル署名用
途において，図 2.1 における X は大きく異なり，個別のアプリケーションごとに判断する必要がある．また，公開鍵の配布のために PKI 等を利用していた場合，トラストアンカーの置き換え等に時間を要することになり，図 2.1 における Y が 10 年以上となることも珍しくない．なお，e-mail を保護する S/MIME プロトコルにおいては，S/MIME
証明書（に対応する秘密鍵）によって保護される対象を通信プロトコルと捉えると（data in transit に対するセキュリ
ティとなり）TLS 同様保護の対象となる期間は短いが，S/MIME 証明書（に対応する秘密鍵）によって保護される対
象をメールコンテンツと捉えると（data at rest に対するセキュリティとなり）保護の対象期間が非常に長くなりうる．
このように，X を導出する上では，個別のデータの保護期間のみでなく，プロトコルがサポートする機能も明確化する

13

ことが望ましい．

2.2.2 守秘用途での課題
守秘用途の公開鍵暗号では，保護対象となるコンテンツや鍵情報の保護期間が非常に長いことを想定していること
や，場合によっては無期限で保護されることを想定していることがある．具体的には，患者を特定または類推可能な形態で保管された遺伝性の疾病に関する情報や，外交上重要な情報，及びそれらの情報の暗号化に利用される鍵などは，長い保護期間を持つ傾向にある．また，ドキュメントの生成時には無期限に秘匿することを想定しており，公開することを想定していない情報等も存在する．このような場合においては，図 2.1 における X は非常に大きくなるため，

X ＋ Y > Z が成立すると仮定した上で，速やかに量子コンピュータによる攻撃に対する何らかの対策を行うことが望ましい．
ここへの脅威をより具体的に記載すると，無期限に保護しないといけないコンテンツを暗号化した暗号文が，パブリックな空間に保管されていた場合においては，攻撃者がその暗号文をあらかじめ保管しておき，将来に量子コンピュータが登場したのちに解読されるという脅威が含まれる．また，そのような暗号文が既にパブリックな空間に保管されている又は過去に保管されていた場合は，その暗号文が将来解読される脅威も含まれる．

2.2.3 鍵共有用途での課題
鍵共有用途での課題は，守秘用途の課題と同種の課題を含む．例えば，鍵共有で共有された共通鍵暗号の共通鍵が，非常に長い保管期間を持つデータの暗号化に利用されていた場合，図 2.1 における X は非常に大きくなり，X ＋ Y > Zが成立すると想定され，速やかに量子コンピュータによる攻撃に対する何らかの対策が必要となる．
加えて，守秘用途で存在しない新たな課題もある．例えば，一時的（Ephemeral) な鍵情報を用いた DH 鍵共有を採用した，PFS な情報システムが存在したとする．また，その情報システムは，PFS であることを前提とした運用ポリシーを策定していたとする．そして，その情報システムの DH 鍵共有処理部分を，標準化された耐量子計算機暗号を用いて置き換えることとする．この置き換え操作においては，以下の 2 つの方針が考えられる．

1) 鍵共有用途の耐量子計算暗号を利用して置き換える
2) 守秘用途の耐量子計算機暗号を利用して置き換える
標準化された鍵共有用途の公開鍵暗号が存在するのであれば，1) を選択可能であり，それは比較的容易に実現可能だと考えられる．しかしながら，標準化された鍵共有用途の公開鍵暗号が存在しなく，守秘用途の公開鍵暗号しか標準化されたものがないのであれば，2) を選択することとなり，守秘用途の耐量子計算機暗号を用いて鍵共有部分を構成することとなる．ここで，守秘用途の暗号を単純に導入した場合，PFS の性質を持たなくなる可能性があり，それによりデータ保護及び運用ポリシー策定時に想定していなかった経路からの情報漏洩等が発生する可能性が生じる．また，守秘用途の公開鍵暗号に対して何らかの手を加えて，PFS の性質を持つ暗号プロトコルを構成したとしても，その暗号プロトコルが標準化されていない場合は，運用ポリシー上，利用できないこともあり得る．上記のような課題は，既存のシステムが鍵共有用途の公開鍵暗号を利用しており，今後採用する耐量子計算機暗号が守秘用途の場合に発生する課
題となる．

14

2.3 各利用形態における対策
いずれの利用形態においても，量子コンピュータの脅威への対策を検討するにあたり，図 2.1 における X,Y ,Z を意識することが重要となる．図 2.1 における X や Y は利用形態や暗号モジュール毎に異なることも想定され，それらの値の関係は将来において変動しうる．加えて Z は不確定であり，予想することが難しい．そのような状況で，全ての暗号モジュールに対して X,Y ,Z を分析するアプローチを取ることは，作業量の観点で大きな困難が伴うことも予想さ
れ，結果として本当に保護が必要なデータに手が回らない可能性がある．そこで，優先度の高いものを割り出し，その優先度に応じて対応を行うことが適切だと考えられる．
例えば，NIST は耐量子計算機暗号への移行の一環として情報システムが利用している暗号の棚卸しや整理の方法を検討しており [10]，以下のような流れで対策を行うことを想定していると考えられる．

• ある程度以上の価値のある情報を扱う情報システムをリストアップする• 上記情報システム内において利用される，暗号モジュール及び暗号方式をリストアップする• 上記暗号方式によって保護される情報の保護期間（X の把握のために必要）を把握する．保護期間が設定されていない場合は設定する• 各暗号モジュールの移行に要する時間（Y ）を把握する• X 又は Y が一定の値以上で，またある程度以上の価値のある情報を扱う情報システムをリストアップする• 上記リストに対してプライオリティ付けを行う• プライオリティ順に，Cryptographic agility[6] の向上や暗号方式の耐量子計算機暗号への移行を実施する• 耐量子計算機暗号への速やかな移行が難しい場合は，以下の公開鍵暗号の用途に応じた対策を行う
暗号モジュールや暗号方式のリストアップは，既に管理簿や仕様書等が存在するのであればそれを利用できる．管理
簿や詳細な仕様書等が存在しない場合は，何らかの自動化ツールを使うことが，効率の面からもミスを減らす面からも望ましい．そのようなツールの利用を検討する上では，(2022 年末時点では最終報告は公開されていないものの，今後出てくるであろう)NIST NCCoE の検討 [10] が参考になるものと思われる．
保護期間の把握に際しては，過剰な期間が設定されているものに対しての保管期間の短縮，不要な情報の消去，公開可能な情報の公開等を合わせて行っても良い．そのような処理を行うことで X が減少することが期待でき，より効率的に対策を行えることが期待される．
暗号の移行に際しては，速やかに耐量子計算機暗号に移行するというアプローチと，予め Cryptographic agility[6]*5を向上させつつ，ある程度以上の Cryptographic agility が達成された後に移行するというアプローチが存在する．

Cryptographic agility が上昇した場合，Y が減少することとなる．そのため，例えば耐量子計算機暗号の評価が十分にされておらず，暗号移行開始の妨げとなっているケースにおいては，当面の間は Cryptographic agility 上昇に努めるというアプローチが合理的であると考えられる [18]．なお，Cryptographic agility 上昇に伴う Y が減少により，該当する情報システムのプライオリティが下がれば，他の（相対的にプライオリティが高くなった）情報システムへリソースを集中することもできる．

*5 より迅速に暗号を変更可能とする性質．

15

2.3.1 署名用途固有の対策
署名用途の公開鍵暗号は様々なユースケースで利用されるが，PKI 等のインフラの移行に要する時間（Y ）やコードサイン証明書が利用される期間（X ）が比較的長く，速やかな耐量子計算機暗号への移行が難しい可能性もある．このようなケースにおいても，以下のような対応を取ることが望ましい．

PKI においては一般に Y が大きくなる傾向にあるが，電子証明書の有効期間短縮や，1 枚の電子証明書に対して従来暗号と耐量子計算機暗号の 2 つの公開鍵及びデジタル署名を付与する方式などを採用することで，ある程度は Y も減少することが期待できる [11, 12]．なお，後者の 2 つの公開鍵暗とデジタル署名を利用する方式においては，実装やポリシー管理の複雑性が大きく増加すことが考えられ，その点には注意を払う必要がある．

X を実質的に短縮する技術として，タイムスタンプ更新技術が挙げられる．例えば，ERS[5] 等を利用することで，タイムスタンプの更新や，暗号の更新を行うことができる．Z 年が経過する前に，既存の公開鍵暗号を耐量子計算機暗号に更新することが可能であれば，X,Y ,Z の関係性によらず，データは保護される．一方で，実装の複雑性が増加する可能性があり，Y が上昇する可能性がある点は注意が必要となる．

2.3.2 秘匿及び鍵共有用途固有の対策
根本的な対策は，暗号を耐量子計算機暗号に移行することである．しかしながら，2.2.2 節及び 2.2.3 節に記載した通り，秘匿及び鍵共有用途で保護されたコンテンツや鍵情報は，保護期間が非常に長いことや，場合によっては無期限で保護されることを想定していることもある．そのような情報は既に将来における量子コンピュータでの解読リスクに晒されており，一刻も早く対応を始めない限り，リスクに晒された情報は増加し続ける．一方で，全ての秘匿及び鍵共有
用途の公開鍵暗号を移行するためには非常に大きなリソースが要求され，全ての暗号文に対して迅速な移行を行うことには困難が想定される．
そのような状況においても，秘匿及び鍵共有用途固有の対策を効率的に行う方法 [18] として，以下のようなアプロー
チが考えられる．Z に対して X ＋ Y が非常に小さい（X ＋ Y << Z ）と予測される暗号文に対しては，CRYPTRECによる注意喚起情報 [17] に注意を払いつつ，今まで通りの対応を行う．また，X ＋ Y > Z となることが十分予想される暗号文に対しては，2.3 節前段で述べたような，耐量子計算機暗号への移行や，暗号文の保護期間である X 年の短
縮と，情報システムの暗号処理の実装の置き換えに要する期間 Y 年の短縮を行う（その結果 X や Y が十分に小さくすることができるのであれば，上記の今まで通りの対応を行う）．一方で，前述検討の上でも X ＋ Y > Z と予想される又はそうなることが避けられない暗号文に対してしては，暗号システムの対量子計算機暗号への移行を進めつつも，
既存の公開鍵暗号によって保護されている暗号文は公開ネットワーク等に保管せず，適切にアクセスコントロールを行う．なお，現在 DH を利用している場合は 2.2.3 節で述べたような検討を行い，DH 固有の性質が必要か否かを予め検討することが望ましい．

2.3.3 耐量子計算機暗号の活用方法
耐量子計算機暗号を活用する上では，2.3 節冒頭で述べたとおり，現状において，どのようなデータに対して，どのような暗号技術を利用しているかを把握することが第一歩となる．また，保護対象となるデータの保護期間を予め把握しておくことで，より効率的な対応ができると考えられる [18]．その上で，公開できるデータは公開し，破棄可能なデータは破棄することが望ましい．上記のような検討を予め行うことで，Cryptographic agility[6] の向上も見込むことができ，より効果的に耐量子計算機暗号を活用できることが期待できる．量子コンピュータの脅威への対策を検討す

16

るにあたっては保護されている情報の価値と，図 2.1 における X,Y ,Z の関係を踏まえてプライオリティを付けて，そのプライオリティ順に対策を実施することが望ましい．

17

第 2 章の参照文献[1] D. Cooper, S. Santesson, S. Farrell, S, Boeyen, R. Housley, W. Polk. Internet X.509 Public Key Infrastructure
Certiﬁcate and Certiﬁcate Revocation List (CRL) Proﬁle https://www.rfc-editor.org/rfc/rfc5280.
[2] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP) https://www.rfc-editor.org/rfc/rfc3161.
[3] M. Mosca.

Cybersecurity in a Quantum World: will we be ready?

https://csrc.nist.gov/csrc/

media/events/workshop-on-cybersecurity-in-a-post-quantum-world/documents/presentations/session8-mosca-michele.pdf.
[4] E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3 https://www.rfc-editor.org/rfc/
rfc8446.
[5] T. Gondrom, R. Brandner, U. Pordesch. Evidence Record Syntax (ERS) https://www.rfc-editor.org/
rfc/rfc4998.
[6] R. Housley. Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms https://www.rfc-editor.org/rfc/rfc7696.
[7] Y. Sheﬀer, R. Holz, P. Saint-Andre. Recommendations for Secure Use of Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS) https://www.rfc-editor.org/rfc/rfc7525.
[8] National Security Agency. Announcing the Commercial National Security Algorithm Suite 2.0 https://
media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF.
[9] National Security Agency. The Commercial National Security Algorithm Suite 2.0 and Quantum Computing
FAQ https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF.
[10] W. Barker, M. Souppaya, W. Newhouse.
PHY

MIGRATION TO POST-QUANTUM CRYPTOGRA-

https://www.nccoe.nist.gov/sites/default/files/legacy-files/pqc-migration-project-description-final.pdf.
[11] D. Stebila, S. Fluhrer, S. Gueron. Hybrid key eXchange in TLS 1.3 https://datatracker.ietf.org/doc/
html/draft-ietf-tls-hybrid-design.
[12] M. Punsworth, J. Gray. TComposite KEM For Use In Internet PKI https://datatracker.ietf.org/doc/
html/draft-ounsworth-pq-composite-kem-00.html.
[13] A. Becker, R. Guthrie, M. Jenkins. Non-Composite Hybrid Authentication in PKIX and Applications
to Internet Protocols https://www.ietf.org/id/draft-becker-guthrie-noncomposite-hybrid-auth00.html.
[14] S. Turner, P. Kampanakis, J. Massimo, B. Westernbaan. Algorithm Identiﬁers for NIST’s PQC Algorithms
for Use in the Internet X.509 Public Key Infrastructure https://datatracker.ietf.org/doc/html/draft-18

turner-lamps-nist-pqc-kem-certificates.
[15] J. Massimo, P Kampanakis, S. Turner, B. Westernbaan. Algorithms and Identiﬁers for Post-Quantum
Algorithms https://datatracker.ietf.org/doc/draft-massimo-lamps-pq-sig-certificates.
[16] 独立行政法人情報処理推進機構. SSL/TLS 暗号設定ガイドライン https://www.ipa.go.jp/security/ipg/
documents/ipa-cryptrec-gl-3001-3.0.1.pdf.
[17] Cryptography Research and Evaluation Committees. 注意喚起一覧 https://www.cryptrec.go.jp/er.html.
[18] T. Ito, M. Une, T. Seito. 量子コンピュータによる脅威を見据えた 暗号の移行対応 https://www.imes.boj.
or.jp/research/papers/japanese/19-J-15.pdf.

19

第3章

格子に基づく暗号技術
本章では格子に基づく暗号技術についてまとめる. 格子に基づく暗号技術の安全性は, LWE (Learning With Errors)
問題, LWR (Learning with Rounding) 問題, NTRU 問題, およびそれらの変種等を含む, 格子理論に関係する問題を解く計算の困難性に依存している.

3.1 格子に基づく暗号技術の安全性の根拠となる問題
3.1.1 LWE 問題の紹介
LWE 問題は機械学習理論から派生した求解困難な問題で, 整数剰余類環 Zq 上の秘密ベクトル s ∈ Znq に関するランダムな連立線形「近似」方程式が与えられたとき, その秘密ベクトルを復元する問題である. 具体的な数値例として

n = 4, q = 17 に対して, 秘密ベクトル s = (s1 , s2 , s3 , s4 ) ∈ Z417 に関する連立線形近似方程式
14s1 + 15s2 + 5s3 + 2s4 ≈ 8





13s1 + 14s2 + 14s3 + 6s4 ≈ 16

6s1 + 10s2 + 13s3 + s4 ≈ 12


..



.



6s1 + 7s2 + 16s3 + 2s4 ≈ 3(mod 17)(mod 17)(mod 17)(mod 17)が与えられたとする. (この数値例は [55] から引用した. ) ただし, 各線形方程式の値は近似値であり, その誤差はこの
例では ±1 以内と仮定する. このとき, この連立線形近似方程式の解 s を求めるのが LWE 問題である. 上記の数値例
では s = (0, 13, 9, 11) ∈ Z417 が解となる. LWE 問題で注意すべきことは, 連立線形近似方程式に誤差がない場合は,Gauss の消去法により効率的に解を求めることができる点である. 逆に言うと, 連立線形近似方程式で与えられる誤差の大きさが LWE 問題の求解を困難にする.

3.1.2 NTRU 問題の紹介
ここでは，NTRU 問題とその代表的な求解法を紹介する. まず以下で, NTRU 問題について述べる：
定義 3.1 (NTRU 問題 [39]) 2 つの正の整数 n と q に対し, φ ∈ Z[x] を次数 n の多項式とし, Rq = Zq [x]/(φ) とす
る. 係数が小さい 2 つの多項式 f ∈ Rq× , g ∈ Rq に対して, h = g · f −1 ∈ Rq とする. (特に，f は環 Rq の可逆元に注意) このとき, 与えられた多項式 h から, f または g の多項式を復元する問題を (探索) NTRU 問題という.

20

NTRU 問題における多項式 φ の選び方として, φ = xn ± 1, xn − x − 1, xn − xn/2 + 1,

Pn−1

i=0 x

i

などがある [8,Table 1]. (最後の φ のみ，次数は n − 1 である. ) また, 多項式 f (または g) の選び方として, {−1, 0, 1} などの小さい係数を持つ多項式や, 小さい素数 p と係数が小さい多項式 F に対し f = pF または f = pF + 1 と選ぶことが多い.

3.1.3 格子問題の公開チャレンジの求解状況
SVP や LWE に対する求解アルゴリズムをテストする目的で，ドイツ・ダルムシュタット大学によって「SVP チャレ
ンジ」
・「LWE チャレンジ」と呼ばれる求解コンテストがインターネット上で開催されている [58]. 2018 年に，篩をベースとした高速な格子アルゴリズム群である General Sieve Kernel (G6K)[12] が提案され，SVP チャレンジ・LWE チャ
レンジの求解記録が飛躍的に更新された. 具体的には，SVP チャレンジにおいては，G6K 内の篩アルゴリズムを GPU
実装することで，180 次元の SVP インスタンスが 4 NVIDIA Turing GPUs の計算機（1.5TB RAM）を用いて 51.6
日で求解されたと 2021 年 2 月に報告されている [26]. （ただし，本報告では Gaussian Heuristic で期待される最短ベクトル長に対する近似因子が 1.04002 なので，今回見つかった格子ベクトルは 180 次元 SVP インスタンスの厳密解ではなく近似解である. ）また，LWE チャレンジにおいては，(n, α) = (45, 0.030), (50, 0.025), (55, 0.020), (90, 0.005)の数多くの LWE インスタンスが G6K 内の progressive-BKZ の改良により求解されたと 2022 年 6, 7 月に報告されている. （ただし，n は LWE の秘密ベクトル長で，α はノイズの大きさに関するパラメータで，組 (n, α) のバランスで

LWE インスタンスの難しさが大きく変化する. ）例えば，(n, α) = (50, 0.025) の LWE インスタンスに対して，次のスペックを持つ計算システムで約 592 時間で求解されたと報告されている：• HardwareCPU：AMD EPYCTM 7002 Series 128@2.6GHz• RAM：1.5TB• GPU：8 ∗ NVIDIA R GeForce R RTX 3090
• VRAM：8 ∗ 24GB（936.2 GB/s）

3.2 代表的な格子に基づく暗号方式の説明
3.2.1 Hash-and-Sign に基づく署名方式の格子問題への拡張
Hash-and-Sign に基づく署名方式は, Diﬃe,Hellman らによってその基本形が示されており, 落とし戸つき一方向性関数 f (x) ならびに f −1 (x) を用いて署名・検証が行われる.

• M : メッセージ• h = hash(M ): 暗号学的ハッシュ関数• σ = f −1 (h) : 署名
• h = f (σ) が成り立つかを確認 : 署名検証
Diﬃe,Hellman らによる方式では, 一方向性関数 f (x) として, 素数 p を法とした離散対数問題に基づく関数
f (x) = ax mod p が提示されている.
この署名方式は, さまざまな改良が提案されているが, 格子問題の困難性に基づく落とし戸つき関数を用いた

Hash-and-Sign 署名方式が, Gentry らによって提案されている [35]. 以下にその方式を示す. 次のパラメータを準備する.

21

• m, n : 正の整数 (セキュリティパラメータ)• hash(M ): 暗号学的ハッシュ関数• q : 素数
• L = m1+ϵ , ( > 0) : 秘密鍵の大きさの上限
以下に具体的な署名方式を示す.
鍵生成 A ∈ Zn×m
をランダムな行列, S ∈ Λ⊥qq (A, q), ||S|| < L を短いベクトルとし, SA = 0 mod q を満たす行列の組 (A, S) を生成する (具体的な手法は [2] 参照). 秘密鍵を S, 公開鍵を A とする.
署名生成

メッセージ M に対しハッシュ関数を作用させた値 H = hash(M ) を DZm ,s にマッピングし, その値を uとする. tA = u mod q を満たす t を任意に求める. 秘密鍵 S を用いて, −t に近い格子 Λ⊥q (A, q) 上の点 v を求め, σ = v + t とする. σ を署名として出力する.
署名検証

メッセージ m にハッシュ関数を作用させた値 h = hash(m) を DZm ,s にマッピングし, 値を u とする. σが短いベクトルでありかつ (σ − u)A = 0 である場合に検証を受理する.
署名の正当性については, 次のように示される. 構成の仕方から, σ − u = v であり, v は格子 Λ⊥q (A, q) 上の点であるから, (σ − u)A mod q = vA mod q = 0 が成り立つ. また 秘密鍵 S の特徴から, σ ∈ DZm ,s であることから, σは短いベクトルとなる. 本署名方式は LWE 仮定の元で SUF-CMA(Strong Existential Unforgeability under Chosen

Message Attack) 安全であることが示されている.

3.2.2 Fiat-Shamir 署名方式の格子問題への拡張
Fiat, Shamir らによって提示された Fiat-Shamir 変換 [33] に基づく署名方式を総称して Fiat-Shamir 署名と呼ばれており, 現在までさまざまな方式が提案されている. 以下に基本となる方式の一つである素因数分解問題をベースとする方式を記す. 合成数 n = pq (p, q は素数) を法とする冪乗剰余演算 g(x) = g x mod n を一方向性関数として利用
し, 秘密鍵 s, 公開鍵 a = g(s) を準備する.

• M : メッセージ m• h = hash(M ): 暗号学的ハッシュ関数• r : ランダムな値• (z, y) = (g(r)h + s, g(r)) : 署名
• g(z) = ar y が成り立つかを確認 : 署名検証
Lyubashevsky によって, Fiat-Shamir with Aborts 型の格子ベースの署名方式が提案されている [33]. 以下にその具体的な署名方式について述べる. 次のパラメータを準備する.

• hash(M ): 暗号学的ハッシュ関数• m : 正の整数 (セキュリティパラメータ)• n : 2 の冪乗 (セキュリティパラメータ)• σ : 正の整数 (セキュリティパラメータ)• κ : 2κ n Cκ > 160 を満たす整数• p : (2σ + 1)m 2−128/n 程度の素数• R = Zp [x]/(xn + 1) : 多項式剰余環22• D = {z ∈ R | ||g||∞ ≤ mnσκ} : 内積に基づくハッシュ関数向け空間• G = {g ∈ R | ||g||∞ ≤ mnσκ − σκ} : 署名空間
ただし ||z||∞ は z の最大値ノルムとする. 以下に具体的な署名方式を示す.

R に属する m 個の多項式の集合 Rm の要素 â に対し, Dm 上のハッシュ関数 hâ (ẑ), (ẑ ∈ Dm ) を以下のように定め
る. hâ (ẑ) = â · ẑ = a1 z1 + ... + am zm ∈ R.
鍵生成 短い多項式を成分とするランダムなベクトル ŝ, ならびに D m のランダムなベクトル â によるハッシュ関数hâ () を作用させた値 S = hâ (ŝ) を求め, ŝ を秘密鍵, S を公開鍵とする.
署名生成

メッセージを M とする.

多項式を成分とするベクトル ŷ ∈ D m をランダムに選択し, c = hash(hâ (ŷ)||M ), ẑ = ŷ + cŝ を求める. ẑ ∈ Gmとなるまで, ベクトル ŷ の選択をくりかえす. σ = (ẑ, c) を署名として出力する.
署名検証ẑ ∈ Gm ならびに c = hash(hâ (ẑ) − Sc, M ) が成り立つ場合に検証を受理する.

この署名方式の正当性は, hâ (ẑ) − Sc = hâ (ŷ + cŝ) − hâ (ŝ)c = hâ (ŷ) が成り立つことから保証される. 安全性については, 環 R 上のイデアルに対する γ-SVP 問題の困難性と等価であることが示されている.

3.3 格子に基づく主要な暗号方式
3.3.1 CRYSTALS-Kyber
歴史: CRYSTALS-Kyber は NICT PQC 公募への応募方式のひとつとして 2017 年 11 月に Roberto Avanzi, Joppe

Bos, Léo Ducas, Eike Kiltz, Tancréde Lepoint, Vadim Lyubashevsky, John M. Schanck, Peter Schwabe, Gregor
Seiler, Damien Stehlé の 10 名により共同で発表され [5]，その後 2018 年 4 月の国際会議 Euro S&P に Roberto Avanziを除いた 9 名の共著により査読付き論文として発表された [14]. NIST PQC 標準化の Round 3 からは Jintai Dingが加わり 11 名での提案となった．NIST の耐量子計算機暗号標準化において唯一暗号化・鍵交換目的での Selected

Algorithm として残った方式である [49]．
NIST PQC 標準化のラウンドが進むごとに主に暗号化処理のパラメータに関して修正が行われ，現在の最新版は2021 年 8 月に公開されたバージョン 3.02[7] である．以下の記述はこの仕様書に従う．
参照 URL: 開発者による公式ページ https://pq-crystals.org/kyber/ および GitHub のリファレンスコード

https://github.com/pq-crystals/kyber を参照した．
設計原理: CRYSTALS-Kyber は Module-LWE 問題を安全性の根拠とする暗号化方式であり，dual-LWE 暗号方式をひな型*1 として x256 + 1 を定義多項式とした環上で処理を行うことで効率化している．
ベースとして IND-CPA 安全な公開鍵暗号を構成し，それを藤崎-岡本変換のデカプセル化失敗時の戻り値を調整した Hofheinz らの変種 [37] により IND-CCA2 安全な KEM へと変換している．
アルゴリズムの詳細: 表 3.2，3.3，3.4 に Lindner-Peikert[44] による格子ベース公開鍵暗号と CRYSTALS-Kyber の
鍵生成，暗号化，復号アルゴリズムを並置する．
パブリックパラメータは以下で与えられる．

*1 仕様書では，アルゴリズムの形が Lyubashevsky-Peikert-Rosen の Ring-LWE ベース暗号 [45] に似ているとしている．

23

• n, q: 環を定義するための多項式 xn + 1 の次数と法を示す．用いられる多項式環は R := Z[x]/(xn + 1), Rq :=Zq [x]/(xn + 1) であり，常に n = 256, q = 3329 = 13 · 256 + 1 と固定されている*2 ．
• k: モジュール格子のランクとする．
• η1 , η2 : 鍵生成および暗号化時に生成するノイズベクトルの大きさを指定する．
• du , dv : 暗号文多項式 (u, v) を表現するためのビット数を指定する．
用いられるサブルーチンのうち主なものを以下に列挙する．

• NTT(f ) は f =255
Xfi xi ∈ Rq の NTT 表現 fˆ =

i=0

255
X

fˆi xi ∈ Rq を求める関数で，i=0fˆ2i =

127X

f2j ζ (2br7 (i)+1)j および fˆ2i+1 =

j=0

127
X

f2j+1 ζ (2br7 (i)+1)jj=0

により定義される．ただし，br7 (i) は 7bits の整数を引数にとり，そのビット反転を出力する関数である．ζ = 17
は Zq における原始元である．
こ の 表 記 は 複 数 の Rq の 元 を 並 べ た ベ ク ト ル s = (s0 , s1 , . . . , sk−1 ) ∈ Rqk に も 有 効 で ，NTT(s) =(NTT(s0 ), NTT(s1 ), . . . , NTT(sk−1 )) 等と解釈する．
• Parse(XOF(ρ, i, j)): XOF (extendable output function) を用いてシードの ρ, i, j から十分な長さの疑似乱数列を生成し，それを Parse 関数により Rq の元に変換する.

• CBDη (PRF(σ, i)): 疑似乱数生成器 PRF は長さ 32Bytes の σ と 1Byte の i をシードとして 512ηbits の疑似乱数列 β0 β1 · · · β512η−1 へと変換する．この列を 2ηbits ごとに切り分け i = 0, . . . , 255 に対して fi =

η−1
X
j=0

βi·2η+j −η−1X

βi·2η+η+j を計算．i 次の係数を fi とした 255 次多項式を CBDη 関数の出力とする．

j=0• Encodeℓ (ŝ), Decodeℓ (b): Encodeℓ 関数は 255 次の多項式 ŝ ∈ Rq を入力とし，各係数を `bits のビット列に直したものを結合した 256`bits のビット列を出力とする．Decode 関数はその逆を行う関数で，ビット列を多項式環の元に変換する．

• Compressq (x, d), Decompressq (x, d): x ∈ Zq を近似的に dbits に変換，逆変換を行う関数であり，暗号文のサイズ削減に用いられる．具体的にはCompressq (x, d):= d(2d /q) · xc mod 2d , およびDecompressq (x, d) := d(q/2d ) · xcで定義される．
疑似乱数生成器の実装について: アルゴリズムの仕様の中で用いられる疑似乱数生成器 XOF, PRF, G, H, KDF について，元々の SHAKE ハッシュ関数などを用いたものに加え，NIST PQC Round 2 に合わせてアップデートされたバー
ジョン 2.0[6] からは “90s version” として AES と SHA のみを用いたものが提案されている．これらの関数がデファク
トスタンダードとして既に多くのハードウェア上で実装されている事から，高速化を狙ったものである．以下の表 3.1に用いられる関数をまとめる．なお，本節で紹介する IND-CPA 安全な方式の中では XOF, PRF および G のみが用いられ，他の 2 つは IND-CCA2 安全な方式の構成において呼び出される．

90s version の XOF 関数では，AES-256 の CTR モードを ρ を鍵，12Bytes の nonce を nonce[0] = i, nonce[1] = j,nonce[`] = 0 for ` = 2, . . . , 11 とパディングして用いる．同様に PRF 関数では AES-256 の CTR モードを ρ を鍵，*2 Round 1 提出時には q = 7681 であったが，Round 2 からはこの値に変更された．

24

12Bytes の nonce を nonce[0] = i, nonce[`] = 0 for ` = 1, . . . , 11 として用いる．また，オリジナルバージョンのSHAKE-128 の呼び出し方に関してはリファレンス実装*3 を参照した．
表 3.1: CRYSTALS-Kyber における疑似乱数生成器の実装 [7, Sect. 1.4]

オリジナル

90s

XOF(ρ, i, j)

PRF(σ, i)

H(b)

G(b)

KDF(b)SHAKE-128(ρ||i||j)SHAKE-256(σ||i)

SHA3-256(b)SHA3-512(b)SHAKE-256(b)AES-256

AES3-256

SHA-256(b)SHA-512(b)SHA-256(b)表 3.2: Lindner-Peikert 格子ベース暗号および CRYSTALS-Kyber における鍵生成関数の比較

Lindner-Peikert [44, Sect. 3.1]

CRYSTALS-Kyber [7, Algorithm 4]

KeyGen(1 ) → (pk , sk )KeyGen(1λ ) → (pk , sk )

λ

$

d←
− B 320:(ρ, σ) ← G(d)1:

A: n1 × n2 ランダム行列

Â[i][j] ← Parse(XOF(ρ, j, i))
for i = 0, . . . , k − 1 and j = 0, . . . , k − 1

2:

S: 成分の小さい n2 × ` 行列

3:

E: 成分の小さい n1 × ` 行列

s[i] ← CBDη1 (PRF(σ, i)) for i = 0, . . . , k − 1ŝ ← NTT(s)e[i] ← CBDη1 (PRF(σ, i + k)) for i = 0, . . . , k − 1ê ← NTT(e)4:B = AS + E

t̂ ← Â ◦ ŝ + ê

returnpk = (A, B), sk = S

pk = (Encode12 (t̂ mod q)||ρ), sk = Encode12 (ŝ mod q)

CRYSTALS-Kyber の鍵生成関数（表 3.2 右）を説明する．表の中で B は 1Byte 分の情報を表す集合 {0, 1, . . . , 255}を表す．ランダムに生成した 32Bytes の d をシードとして，ハッシュ関数 G を用いて 32Bytes の疑似ランダムビットの組 (ρ, σ) を生成する．これらはそれぞれ，行列 A ∈ Rqk×k とノイズ多項式 s, e ∈ Rqk をサンプリングするためのシードとして用いられる．通常空間で Rq を一様ランダムにサンプルしたものに数論変換をかけた後の分布はまた Rq 内の一様分布となるため，A は最初から NTT 空間でサンプリングされているものと見做される．

s, e ∈ Rqk については CBDη1 を用いて通常空間でのサンプリングを行い，その成分を個別に数論変換する．数論変換の性質により，最後の t̂ は NTT(As + e) となる．公開鍵サイズを圧縮するため，A, t̂ をそれぞれシード ρ，Encode関数による圧縮形式で保存する．秘密鍵の ŝ に関しても同様である．

CRYSTALS-Kyber の暗号化関数（表 3.3 右）を説明する．圧縮形で入力された公開鍵から t̂, Â を復元する．このとき，処理のために行列は転置された形で復元される．
暗号化のため成分の小さい r, e1 ∈ Rqk と e2 ∈ Rq をサンプリングする．通常空間と NTT 空間を使い分けて処理を効率化しているが，最終的な暗号文 c1 ||c2 は通常空間でのベクトル u ∈ Rqk と多項式 v ∈ Rq を Compressq 関数で圧縮したものとなる．ここで，2 種類のノイズ η1 , η2 を使い分けるのは，η1 のみによるノイズの大きさと，最後の Encode関数によるラウンディングからの決定的ノイズと η2 のノイズを合成したものの大きさが釣り合うように調整するためである [7, Sect. 1.5]．
*3 https://github.com/pq-crystals/kyber/blob/master/ref/symmetric-shake.c25

表 3.3: Lindner-Peikert 格子ベース暗号および CRYSTALS-Kyber における暗号化関数の比較

Lindner-Peikert[44, Sect. 3.1]

CRYSTALS-Kyber [7, Algorithm 5]

Enc(pk = (A, B), m ∈ {0, 1} ) → ct

Enc(pk = (T ||ρ), m ∈ B 32 ) → ctℓt̂ ← Decode12 (T )0:ÂT [i][j] ← Parse(XOF(ρ, i, j)) //行列 Â の転置の形での復元
s′ , e′ , e′′ : 成分の小さいベクトル1:r[i] ← CBDη1 (PRF(r, i)) for i = 0, . . . , k − 1
e1 [i] ← CBDη2 (PRF(r, i + k)) for i = 0, . . . , k − 1e2 ← CBDη2 (PRF(r, 2k))′

u=sA+e2:′r̂ ← NTT(r)u ← NTT−1 (AˆT ◦ r̂) + e1
v ← NTT−1 (t̂T ◦ r̂) + e2 + Decompressq (Decode1 (m), 1)
c1 ← Encodedu (Compressq (u, du ))c2 ← Encodedv (Compressq (v, dv ))returnct = (c1 ||c2 )

ct = (u, v)

表 3.4: Lindner-Peikert 格子ベース暗号および CRYSTALS-Kyber における復号関数の比較

Lindner-Peikert[44, Sect. 3.1]
Dec(sk , ct) → m
1:′m = v − uS(
0 |mi | ≤ bq/4cm′i =1 それ以外CRYSTALS-Kyber [7, Algorithm 6]
Dec(sk , ct = (c1 ||c2 )) → m′ ∈ B 32
u ← Decompressq (Decodedu (c1 ), du )v ← Decompressq (Decodedv (c2 ), dv )ŝ ← Decode12 (sk )m′ ← Encode1 (Compressq (v − NTT−1 (ŝT ◦ NTT(u)), 1))

returnm′ = (m′1 , . . . , m′ℓ )m′CRYSTALS-Kyber の復号関数（表 3.4 右）は圧縮されたビット列の展開，NTT 空間の利用などで表現が煩雑になっているが，Lindner-Peikert 暗号の復号処理と本質的に同様である．最後の Compressq (·, 1) 関数が Lindner-Peikert 暗号における m から m′ への変換に対応している．
安全性とパラメータ: ベースとなる IND-CPA 安全な公開鍵暗号の安全性は多項式環 Rq := Zq [x]/(xn + 1) 上の判定
版 Module LWE 問題へと ROM，QROM モデルの下で帰着される．
パラメータの設定は Module LWE 問題を構造の無い LWE 問題とみなし Primal, Dual の双方の攻撃を BKZ アルゴ
リズムを用いて解いた場合の必要ブロックサイズに対応する Core SVP 計算量を通じて行われている．Module LWE
問題へと帰着する際に，二項分布によるノイズと Compressq 関数の四捨五入によるノイズを総合して詳細な解析を行っている．また，パラメータ設定用のスクリプトは [25] で公開されている．
暗号の性能を決めるパラメータは n, k, q, η1 , η2 , du , dv の 7 個であり，大まかに以下の特徴を持つ．格子の次元は多項式の次数 n と Module LWE 問題のランク k の積であり，これらのパラメータを大きくとることで暗号の安全性が上がるが処理速度が低下し，鍵と暗号文のサイズが膨らむ．法 q を大きくとることでノイズ耐性が上がり復号エラー率が下がるが，格子が疎になり暗号の安全性が低下する．

26

(η1 , η2 ) は鍵生成と暗号化に用いられるノイズ多項式の大きさで，大きくとることで暗号の安全性が上がるが復号エ
ラー率が下がる．また，ノイズの中心二項分布を生成する際に必要とされるランダムビットの長さが増える．

(du , dv ) は暗号文 (u, v) をビット列で表現するための精度を指定する．小さくとることで暗号文サイズが削減できる
が，桁落ちが発生し復号エラー率が上がる．また，これらの値を小さくとることは暗号文にノイズを与えることにな
り，安全性が僅かではあるが向上するが，復号エラー率への影響の方が大きい．
以下の表で δ は CCA2-KEM における復号エラー率を示す．正しい暗号文が KEM のデカプセル化 [7, Algorithm 9]
で非受理となる確率である．
表 3.5: CRYSTALS-Kyber のパラメータ [7, Table 1] および [3, Sect. D]. 公開鍵，秘密鍵，平文，暗号文サイズの単位はそれぞれ Byte である．
安全性

公開鍵

秘密鍵

平文

暗号文

復号

レベル

サイズ

サイズ

サイズ

サイズ

エラー率 δ

(10, 4)

レベル 1

800

1632

32

768

2−139

(2, 2)(10, 4)

レベル 3

1184

2400

32

1088

2−164

(2, 2)(11, 5)

レベル 5

1568

3168

32

1568

2−174

(n, k, q)(η1 , η2 )(du , dv )(256, 2, 3329)(3, 2)(256, 3, 3329)(256, 4, 3329)

3.3.2 CRYSTALS-Dilithium
歴史: CRYSTALS-Dilithium は 2017 年 6 月に Cryptology ePrint Archive において Léo Ducas，TancrèdeLepoint，Vadim Lyubashevsky，Peter Schwabe，Gregor Seiler，Damien Stehlé の 6 名の連名で公表 [22] され，その後論文内での予告通りに 2017 年 11 月に NIST PQC 公募への応募方式 [20] として Eike Kiltz を加えた 7 名を開発者として提出された．査読付き論文としては国際会議 CHES 2018 において公開された版 [21] が存在する．

NIST PQC のラウンドが進むごとに微修正が行われ，現在の最新版は 2021 年 2 月に公開された仕様書 V3.1[15] である．本節の記述はこの仕様書に従う．
参照 URL: 開発者による公式ページ https://pq-crystals.org/dilithium/ を参照した．
設計原理: CRYSTALS-Dilithium は格子ベースの署名方式であり，Lyubashevsky[41] による Fiat-Shamir with

Aborts 型の構成を行っている．秘密鍵復元問題の安全性の根拠を，x256 + 1 を定義多項式とした環上におけるModule-LWE 問題に，署名の強偽造不可能性の根拠を SelfTargetMSIS 問題に置いている．通信コストを下げるため，
公開鍵サイズと署名サイズの和の最小化を目的としてパラメータの設計を行っている．
最新の実装では，署名の検証にかかる計算時間の 80% はハッシュ関数 Keccak の処理時間であり，速度的にはこれ以上改良できない限界であるとしている [42]．
アルゴリズムの詳細: 表 3.6，3.7，3.9 に Lyubashevsky による Fiat-Shamir with Aborts 型の格子ベース署名，

CRYSTALS-Dilithium のテンプレートアルゴリズム [15, Fig. 1] および実装のための疑似コード [15, Fig.4] を並置して記述する．
パブリックパラメータは以下で与えられる．

• n, q: 環を定義するための多項式 xn + 1 の次数と法を示す．用いられる多項式環は R := Z[x]/(xn + 1)，
Rq := Zq [x]/(xn + 1) であり，提案方式の中では常に n = 256, q = 223 − 213 + 1 = 8380417 を用いる．
27

• k: モジュール格子のランクとする．
• l: ハッシュの (Rq における) 次元パラメータとする．
• d: 鍵生成時に t から分離する下位ビットの長さ• η: 秘密鍵ベクトルのサンプリング空間の大きさ．
• τ : 署名生成時のベクトル c のサンプリング空間の大きさ．β := η · τ• γ1 : 署名生成用ベクトル y のサンプリング空間の大きさ．
• γ2 : 署名生成用ベクトル w から取り出す上位ビットの長さ．
用いられるサブルーチンのうち主なものを以下に列挙する．

• NTT(a) は a =255
Xai xi の NTT 表現 â ∈ Z256を求める関数で，qi=0â = (a(r0 ), a(−r0 ), a(r1 ), a(−r1 ), . . . , a(r127 ), a(−r127 ))で計算される．ただし，r = 1753, ri = rbrv(128+i) mod q, brv(k) 関数は k を 8bits の 2 進数としてみたときのビット反転．[15, Sect. 2.2]

• H:ビット列の伸長のためのハッシュ関数．CRYSTALS-Dilithium の実装では SHAKE256 ハッシュ関数を用いる．

• ExpandA(ρ): 乱数生成のシード ρ を用いて，ランダム行列 A ∈ Rqk×l を生成し，その NTT 表現

a1,1
 a2,1

A= .
 ..

a1,2
a2,2
..
.

···
···
..
.



a1,l
NTT(a1,1 ) NTT(a2,1 )
a2,l ..
..  → Â = 


.
.

ak,1

ak,2

···

ak,l

NTT(a1,2 )NTT(a2,2 )
..
.

···
···
..
.

NTT(ak,1 ) NTT(ak,2 ) · · ·NTT(a1,l )NTT(a2,l ) 


..

.
NTT(ak,l )を計算し出力する．

• ExpandS(ρ′ ): 署名に用いる多項式 s1 , s2 を生成するための関数で，512bits のシードを入力とする．
• Power2Roundq (t, d), HighBitsq (t, α), LowBitsq (t, α): Zq の元 t で，0 ≤ t < q を満たすものを t = r1 · 2d +r0 , −q/2 < r ≤ q/2 と分解したときに Power2Roundq (t, d) = (r1 , r0 ) と定義する．Zq の多項式t ∈ Rq ,Rq 成分
Xのベクトル t に対しても成分ごとに同様の操作を行うものとして定義する．具体的には，t =tj,i xi
j=1,...,kと書いたときに Power2Roundq (tj,i , d) → (tj,i,1 , tj,i,0 ) とすれば，Power2Roundq (t, d) → (t1 , t0 ) は t1 =XX(
qj,i xi )j=1,...,k , t0 = (rj,i xi )j=1,...,k , ただし tj,i = qj,i · 2d + rj,i と定義したものである．

また，α を q − 1 の約数としたとき，上記と同様に整数 t を t = r1 · α + r0 , −q/2 < r0 ≤ q/2 の形で分解し，HighBitsq (t, α), LowBitsq (t, α) をそれぞれ r1 , r0 で定義する．
• MakeHintq (z, r, α), UseHintq (h, r, α): MakeHintq 関数は HighBitsq (r, α) 6= HighBitsq (r + z, α) であれば 1 を，そうでなければ 0 を返す関数である．UseHintq 関数は引数から HighBitsq (r + z, α) を復元する関数である．復元成功の十分条件は [15, Lemma 4] で与えられている．

• SampleInBall(c̃) 関数は係数のうち τ 個が ±1 で，それ以外が 0 である多項式の集合 Bτ から一様サンプリングを行う．τ はパブリックパラメータとして与えられており，引数の c̃ はサンプリングのシードとして用いられ
る．生成された多項式 c ∈ R の NTT 表現 ĉ = NTT(c) が出力される．

• #1 h は h =255
Xhi の中で hi = 1 となる項の数を表す．

i=0

28

表 3.6: CRYSTALS-Dilithium における鍵生成関数の比較
格子ベース署名

1:

CRYSTALS-Dilithium
テンプレート [15, Fig. 1]
KeyGen(1λ ) → (pk , sk )CRYSTALS-Dilithium[41, Fig. 4]
KeyGen(1λ ) → (pk , sk )ŝ: 短い多項式を

s1 ← Sηl , s2 ← Sηkζ←− {0, 1}256
H(ζ) → (ρ, ρ′ , K) ∈ {0, 1}256 × {0, 1}512 × {0, 1}256
ExpandS(ρ′ ) → (s1 , s2 ) ∈ Sηℓ × Sηk

実装のための疑似コード [15, Fig. 4]

KeyGen(1λ ) → (pk , sk )$成分とするベクトル$2:
3:

a: ハッシュ関数t ← a(ŝ)

Â ←− Rqk×l
t = As1 + s2

returnsk = (a, ŝ), pk = (a, t)

sk = (A, t, s1 , s2 ), pk = (A, t)

ExpandA(ρ) → Â ∈ Rqk×ℓt ← NTT−1 (Â · NTT(s1 )) = As1 + s2
Power2Roundq (t, d) → (t1 , t0 )H(ρ||t1 ) → tr ∈ {0, 1}256
sk = (ρ, K, tr, s1 , s2 , t0 ), pk = (ρ, t1 )表 3.6 の鍵生成関数について記述する．256bits のシード ζ をハッシュ関数 H により合計 1024bits に伸長し，そのうち ρ, ρ′ をそれぞれ公開鍵 A のシード，秘密鍵 s1 , s2 のシードとして用いる．鍵サイズ圧縮のため，行列 A はシード

ρ の形で表現され，必要に応じて展開される．秘密鍵 s1 , s2 は R の元をそれぞれ `, k 個並べたベクトルであり，各成分は集合 Sη = {w ∈ R : kwk∞ ≤ η} から一様ランダムにサンプリングされる．

Fiat-Shamir 型署名における秘密鍵 ŝ のハッシュ関数 a(ŝ) の計算が，ベクトル (s1 , s2 ) と行列 A を用いた As1 + s2の計算に対応している．
計算されたベクトル t ∈ Rqk に対して，Power2Roundq 関数により上位ビットと下位ビットに分割する．
最後に，メッセージに連結するためのランダムビット tr をハッシュ関数 H を用いて生成する．
表 3.7 の署名生成関数について記述する．ρ から行列 A の NTT 表現 Â を復元する．ランダムビット tr を用いてメッセージのハッシュ値 µ を計算し，この値に署名をつける．κ は ExpandMask 関数の中で呼び出す SHAKE256 のシードとなる値で，H(K||µ) → ρ′ とともに用いられる．計算効率化の目的で Rq の元の乗算には NTT 表現を用いる
ため，予め s1 , s2 , t0 を NTT 表現に変換しておく．

Fiat-Shamir 型署名の標準的な構成方法と同様に，署名の初期値 (z, h) を ⊥ とし，while ループの中で生成された署名が集合 G に含まれているかどうかを検査し含まれていない場合にはループをやり直す．

ExpandMask 関数の中では，(ρ′ , κ) をシードとしてランダムベクトル y ∈ Rql をサンプリングする．ここで，各成
( 255
)
X
i
分は S̃γ1 =wi x : −η < wi ≤ η から一様ランダムにサンプリングされる．このサンプリングは表 3.7 中央のi=0

y ← Dγl×1に対応する．
1
署名生成のためのベクトル c ∈ Rql は 256bits のシード c̃ により表現され，この値自体は µ と w1 を連結したハッシュ値から計算される．ここで，µ はメッセージからの要素であり，w1 は公開鍵 A と直前でサンプリングした y から来る要素である．計算効率のため，内積 c · s1 は NTT 表現で計算された後に逆変換をかけ z = y + c · s1 となる．
ステップ 5 では z 6∈ G のチェックのため，z と w − cs2 の下位ビットの `∞ ノルムがそれぞれ比較される．両方が閾値よりも小さい場合には次のヒント生成関数 (∗) が実行される．ヒント生成関数は表 3.8 により示され，MakeHintq
実行後に再びノルムの大きさがチェックされ，閾値よりも大きな場合には (z, h) ←⊥ となる．つまり，2 回の if 文の中での 4 回の不等号検査のうち一つでも満たされない条件があれば，シード κ を増やし y の生成からやり直すことになる．ここで，−cs2 + ct0 の計算は前半を r0 で用いたものを使いまわし，後半を NTT−1 (ĉ · t̂0 ) の形で計算する．
表 3.9 の署名検証関数について記述する．公開鍵，署名に含まれる乱数のシード ρ, c̃ から Â, ĉ を復元し，メッセー
ジに対応するハッシュ値 µ を計算する．Az − ct1 · 2d は Â · NTT(z) − NTT(c) · NTT(t1 · 2d ) の形で計算する．これ29

表 3.7: CRYSTALS-Dilithium における署名生成関数の比較
格子ベース署名[41, Fig. 4]
Sign(sk = (a, ŝ),µ ∈ {0, 1}∗ ) → σ

CRYSTALS-Dilithium
テンプレート [15, Fig. 1]
Sign(sk = (A, t, s1 , s2 ),µ ∈ {0, 1}∗ ) → σ

1:

z ←⊥

z ←⊥

2:
3:

while z =⊥ doŷ: 短い多項式を

while z =⊥ doy ← Dγl×1
1 −1

0:

CRYSTALS-Dilithium実装のための疑似コード [15, Fig. 4]

Sign(sk = (ρ, K, tr, s1 , s2 , t0 ),M ∈ {0, 1}∗ }) → σ
ExpandA(ρ) → ÂH(tr||M ) → µ ∈ {0, 1}512
κ ← 0, (z, h) ←⊥H(K||µ) → ρ′ ∈ {0, 1}512ŝ1 ← NTT(s1 ); ŝ2 ← NTT(s2 )t̂0 ← NTT(t0 )while (z, h) =⊥ do
ExpandMask(ρ′ , κ) → y ∈ S̃γl 1成分とするベクトル4:c ← H(a(ŷ)||µ)w1 ← HighBits(Ay, 2γ2 )c = H(µ||w1 )5:ẑ ← ŷ + cŝ

z ← y + cs1
r0 ← LowBits(Ay − cs2, 2γ2 )if (∥z∥∞ ≥ γ1 − β) OR(∥r0 ∥∞ ≥ γ2 − β) then z ←⊥if ẑ ̸∈ Gmthen z ←⊥returnσ = (ẑ, c)

σ = (z, c)w ← NTT−1 (Â · NTT(y)) = Ay
w1 ← HighBitsq (w, 2γ2 )H(µ||w1 ) → c̃ ∈ {0, 1}256
SampleInBall(c̃) → ĉ ∈ Bτ ⊂ Rqz ← y + NTT−1 (ĉ · ŝ1 )r0 ← LowBitsq (w − NTT−1 (ĉ · ŝ2 ), 2γ2 )if (∥z∥∞ ≥ γ1 − β) OR(∥r0 ∥∞ ≥ γ2 − β) then (z, h) ←⊥else
h ← MakeHintq (·) ... (*)κ←κ+lσ = (z, h, c̃)

表 3.8: 署名生成関数におけるヒント生成時のチェック関数h ← MakeHintq (−ct0 , w − cs2 + ct0 , 2γ2 )if kct0 k∞ ≥ γ2 OR #1 h > ω then (z, h) ←⊥らの値から UseHintq を用いて w1′ を復元し，z のノルム，h の 1 の数の確認を行い，正しければ accept を出力する．
安全性とパラメータ: CRYSTALS-Dilithium の安全性は，xn + 1 を定義多項式とする環上のモジュール格子問題である．ROM の下で，秘密鍵復元の困難性が Module-LWE 問題に，署名の強偽造不可能性が SelfTargetMSIS 問題にそれぞれ帰着される．SelfTargetMSIS 問題は Module-SIS 問題の変種ではあるが，タイトではないものの帰着が知られているため，Module-SIS 問題を安全性の根拠と考えることもできる．
一方で，QROM においても鍵復元，署名偽造が同様に Module-LWE 問題，SelfTargetMSIS 問題それぞれ帰着されるものの Module-SIS 問題までの量子帰着が知られていない．
具体的なパラメータは，LWE 問題と SIS 問題の双方に対して BKZ アルゴリズムで解いた際の必要ブロックサイズと Core-SVP の見積から求められている．
仕様書に掲載されたパラメータセットを表 3.10 に示す．セキュリティ強度を規定するパラメータのうち，問題が定義される環とモジュールのランクに関わるものが (n, k, l, q) の 4 個，ノイズに関わるものが (η, γ1 , γ2 , β, τ, d) の 6 個
である．

30

表 3.9: CRYSTALS-Dilithium における署名検証関数の比較
格子ベース署名 [41, Fig. 4]

Vrfy(pk = (a, t), µ ∈ {0, 1}∗ ,σ = (ẑ, c))

CRYSTALS-Dilithium
テンプレート [15, Fig. 1]
Vrfy(pk = (A, t), µ ∈ {0, 1}∗ ,σ = (z, c))

CRYSTALS-Dilithium

if ẑ ∈ Gm AND
c = H(a(ẑ) − tc, µ) then accept
else ⊥

w1′ = HighBits(Az − ct, 2γ2 )if ∥z∥∞ < γ1 − β AND
c = H(M ||w1′ ) then accept else ⊥実装のための疑似コード [15, Fig. 4]0:1:

Vrfy(pk = (ρ, t1 ), M ∈ {0, 1}∗ ,σ = (z, h, c̃))ExpandA(ρ) → ÂH(H(ρ||t1 )||M ) → µ ∈ {0, 1}512
SampleInBall(c̃) → ĉ
w1′ ← UseHintq (h, Az − ct1 · 2d , 2γ2 )if ∥z∥∞ < γ1 − β AND c̃ = H(µ||w1′ )AND #1 h ≤ ω then accept else ⊥表 3.10: CRYSTALS-Dilithium 署名方式のパラメータ [15, Table 1] , [3, Table 8]．公開鍵，秘密鍵，署名サイズの単位はそれぞれ Byte である．

(n, k, l, q)(256, 4, 4, 8380417)(256, 6, 5, 8380417)(256, 8, 7, 8380417)
注：安全性レベル

公開鍵サイズ

秘密鍵サイズ

署名サイズ

17

レベル 2

1312

2528

2420

19

レベル 3

1952

4000

3293

19

レベル 5

2592

4864

4595

(η, γ1 , γ2 , β, τ, d)(2, 2 , 95232, 78, 49, 13)(4, 2 , 261888, 196, 49, 13)(2, 2 , 261888, 120, 60, 13)

秘密鍵サイズは仕様書 [15] には掲載されていないが，NIST の第 3 ラウンド報告レポート [3] を参照した．

変種: [15, Table 3] には NIST の提唱する Category1 よりも弱いパラメータ，5 よりも強いパラメータが掲載されている．
その他補足情報: NIST PQC の第 3 ラウンド報告書において署名方式 FALCON との比較が行われ，CRYSTALS-

Dilithium はそのシンプルさから一般的な実装に向いているが，FALCON は署名の短さからリソースの制限されたデバイスで使われることが期待されている．[3, p.19]．
ハッシュ関数 H の長さについて，V3.0 までは 384bits であったが衝突耐性を考えれると 256bits セキュリティを持
たず，Category 5 の安全性を持たないことが判明したため最新の V3.1 では 512bits に修正されている [56, p.5]．

3.3.3 FALCON
歴史: FALCON は 2017 年 11 月の NIST PQC 公募に Thomas Prest, Pierre-Alain Fouque, Jeﬀrey Hoﬀstein, Paul

Kirchner, Vadim Lyubashevsky, Thomas Pornin, Thomas Ricosset, Gregor Seiler, William Whyte, Zhenfei Zhangの 10 名を開発者として公表された [31]．その後修正が加えられ，現在の最新版は 2020 年 10 月に公開された v1.2[32]である．以下の記述はこの仕様書に従う．
参照 URL: 開発者による公式ページ https://falcon-sign.info/ を参照した．
設計原理: FALCON は多項式 xn + 1, n = 2k により定義される NTRU 格子上の SIS 問題の困難性を安全性の根拠とした格子ベースの署名方式であり，形式的には Gentry ら [35] の Hash-and-sign 型の格子ベース署名をひな型としている．高速フーリエサンプリングを用いるため，定義多項式の次数を 2k の形としていることからパラメータ選択の自由度に制限があり，NIST PQC の提案方式では Category 1,5 のパラメータセットのみが提案されている．

31

アルゴリズムの詳細: 表 3.11，3.12，3.13 に，Gentry ら [35] の Hash-and-sign 型格子ベース署名と FALCON の鍵生
成，署名生成，署名検証関数を並置する．
パブリックパラメータは以下で与えられる．

• n, q: 環を定義する多項式 φ(x) = xn + 1 と法 q で，演算は Zq /φ で行われる．
• σ: 離散ガウス分布の大きさを指定する．
• β: 有効な署名のノルムの上限を指定する．
アルゴリズム中で用いられるサブルーチンのうち，主なものを列挙する．

• FFT(f ), invFFT(s):多 項 式 f ∈ R[x]/φ に 対 し て ，そ の フ ー リ エ 変 換 FFT(f ) を n 次 元 ベ ク ト ル(f (ζk ))k=0,...,n−1 で定義する．ただし，ζk := exp((2k + 1)πi/n)．逆演算を invFFT : Rn → R[x]/φ で示す．
変換，逆変換ともに標準的な高速フーリエ変換の手法が利用可能である．コンピュータ上での計算には浮動小数
点演算を用いるため，実行環境ごとに差が出ないように IEEE754 で規定される浮動小数点の表現と演算を用いることが指定されている．
多項式を成分とするベクトル，行列に対しても FFT は成分ごとのフーリエ変換と定義し，invFFT も適切な切り分けにより実数成分の行列，ベクトルから多項式成分の行列，ベクトルへ変換するものとする．

• HashToPoint(str, q, n): ビット列 str を多項式 c ∈ Zq [x]/φ に SHAKE256 ハッシュ関数を用いて写像する．
• Compress, Decompress: 多項式 s ∈ Z[x] を文字列に変換する関数とその逆関数とする．

表 3.11: Hash-and-Sign 型格子ベース署名および FALCON における鍵生成関数の比較

Gentry らの格子ベース署名 [35, Sect. 7.1]

FALCON[32, Algorithm 4]

KeyGen(1 ) → (pk , sk )KeyGen(φ, q) → (pk , sk )BA ≡ 0 (mod q) を満たす

f, g, F, G ← NTRUGen(φ, q)
#
"
g −f
B←
G −F

λ

1:

行列の組 (A, B) を生成

B: 成分の小さい行列B̂ ← FFT(B)G ← B̂ × Bˆ∗

A: ランダム行列

T ← ﬀLDL∗ (G)for each leaf leaf of T do√leaf.value ← σ/ leaf.valueh ← gf −1 mod q
retrunpk = A, sk = B

pk = h, sk = (B̂, T )NTRU 型暗号の秘密鍵 (f, g) のうち，f は環 Zq /φ の中で逆元を持つため，適当な F, G ∈ Z[x] を用いて
f G − gF = q mod φ(3.1)と書くことができる．この関係式と公開鍵 h = f −1 g を Hash-and-sign フレークワーク [35] における行列 A, B と捉
えると，


A=

1
h




, B=

32

g
G

−f
−F


(3.2)

と表現することができる．このとき，行列 A は多項式 h の情報のみで表現可能であるため，pk = h となる．
また，署名の生成には sA ≡ H(m) を満たす短いベクトル s を生成する必要があり，効率化のため Ducas-Prest[23]の高速フーリエサンプリングを用いる．サンプリングアルゴリズムに必要な情報が B の FFT 表現


FFT(B) =FFT(g) FFT(−f )FFT(G) FFT(−F )


(3.3)

およびそれを元にした LDL 木と呼ばれる木構造 T である．木の中には B̂ のグラム行列 G = B̂ × B̂ ⋆ の*4 LDL 分解における L の情報が格納され，それを用いて Babai の最近平面アルゴリズムの高速化および離散ガウス分布の高速なサンプリングが可能となる．サンプリングを行うための付加情報として，木の全ての葉にある値を leaf.value から√
σ/ leaf.value に書き換えることで鍵生成が完了する．

表 3.12: Hash-and-Sign 型格子ベース署名および FALCON における署名生成関数の比較

1:2:

Gentry らの格子ベース署名 [35, Sect. 7.1]

FALCON[32, Algorithm 10]

Sign(sk = (B̂, T ), m ∈ {0, 1}∗ ) → σ

Sign(sk = (B̂, T ), m ∈ {0, 1}∗ , bβ 2 c) → σc ← H(m)r ← {0, 1}320//平文のハッシュ値をベクトル化c ← HashToPoint(r||m, q, n)
1
1t̂ ← − FFT(c) FFT(F ), FFT(c)qqdoT を使い，sA ≡ c (mod q) を満たすベクトル s をサンプリング

FFT(f )

doz ← ﬀSamplingn (t̂, T )ŝ ← (t̂ − ẑ)B̂
while ksk2 > bβ 2 c(s1 , s2 ) ← invFFT(ŝ)
s ← Compress(s2 , 8 · sbytelen − 328)
while (s =⊥)returnσ=s

σ = (r, s)

表 3.12 の署名生成関数の説明を記述する．平文にランダムビット r を結合した後，HashToPoint 関数で多項式c ∈ Zq /φ を出力する．関係式 (3.1), (3.2) より，ベクトル t̂ は (FFT(c), FFT(0))B̂ −1 と等しい事がわかる．これらの情報を用いて、署名ベクトルのサンプリングを行う．
関数 ﬀSamplingn は，離散ガウス分布のサンプリングを行い，FFT 表現で出力するサブルーチンである．具体的には，整数ベクトル z ∈ Z2n を，t = [c, 0]B −1 を中心として exp(−k(z − t)Bk2 /2σ 2 ) に比例した確率でサンプリングを行う．実装の効率化のため，実際には近似を行っている [32, Sect. 3.9.1,3.9.2]．このとき，(t − z)B は原点を中心とした集合

t + Λ(B) = {(c, 0) + x ∈ (Z[x]/φ)2 : x ∈ Λ(B)}
上の離散ガウス分布となるため，s は短く，かつsA ≡ ([c, 0]B −1 − z)BA ≡ [c, 0]*4 B ⋆ は体 Q[x]/ϕ におけるエルミート共役．詳細は [32, p.23]

33



1
h


= c in Zq [x]/φが成り立つ．このとき，sA = c の関係から s1 + s2 h = c が成り立つ．この関係式が署名の検証時に用いられる．
サンプリングされた ŝ が kŝk2 ≤ bβ 2 c を満たしていれば invFFT により通常空間の表現に戻し，Compress 関数を用いて署名文字列 s を生成し，ハッシュ関数のシード r とともに署名とする．
表 3.13: Hash-and-Sign 型格子ベース署名および FALCON における署名検証関数の比較

Gentry らの格子ベース署名 [35, Sect. 7.1]∗

FALCON[32, Algorithm 16]

Vrfy(m ∈ {0, 1} , σ = s, pk = A)

Vrfy(m ∈ {0, 1}∗ , σ = (r, s), pk = h, bβ 2 c)

1:t ← H(m)c ← HashToPoint(r||m, q, n)2:

if t − sA ≡ 0 (mod q)

s2 ← Decompress(s, 8 · sbytelen − 328)

AND s が短い then return accept

if (s2 =⊥)retrun ⊥s1 ← c − s2 h mod q
if k(s1 , s2 )k2 ≤ bβ 2 c
retrun accept
else
retrun ⊥表 3.13 の署名検証関数の説明を記述する．平文，ハッシュ関数のシード値，署名文字列から各要素を復元し，

s1 = c − s2 h を計算する．署名が正しく生成されていれば sA = c の関係から，s1 は短い元となるはずなので，
k(s1 , s2 )k2 ≤ bβ 2 c が満たされ検証が完了する．
安全性とパラメータ: FALCON の安全性は φ(x) = xn + 1, q = 12289 を定義多項式とする NTRU 格子上の計算問題として表現される．鍵復元の困難性は SIS 問題，署名偽造はターゲットベクトルに近い点を求める計算問題として定式化される．後者は Kannan の埋め込みにより短いベクトルを求める計算問題に変換される．セキュリティに関わるパラメータは n, q, σ, β の 4 個で，n は格子の次元を表し，大きく取ることで安全性が上がるが処理速度が低下する．q は環を定義するための法で，大きくとることでノイズ耐性が上がるが格子が疎になり安全性が低下する．σ はガウス分布の大きさを指定するパラメータで，大きくとることで安全性が上がるがエラー率が上がる．β は署名ベクトルの長さの上限を指定するパラメータで，大きくとることで署名生成時のやり直し回数が下がるが，安全性が低下する．
具体的な困難性の評価およびパラメータ設定は，上記の SIS 問題を BKZ アルゴリズムを用いて解いた場合のCore-SVP 計算量により導出している．
表 3.14: FALCON のパラメータ [32, Table 3.3], [3, Table 8] 公開鍵，秘密鍵，署名サイズの単位はそれぞれ Byte である．

(n, q, σ, bβ 2 c)

安全性レベル

公開鍵サイズ

秘密鍵サイズ *5

署名サイズ( 512, 12289, 165.736617183, 34034726)

レベル 1

897

7553

666

(1024, 12289, 168.388571447, 70265242)

レベル 5

1793

13953

1280

*5 秘密鍵サイズは仕様書には掲載されていないが，NIST の第 3 ラウンド報告レポート [3, Sect. D] を参照した．

34

変種: 実装の複雑さによるサイドチャネル攻撃からの防御，セキュリティパラメータの多様性確保などを目的とした改良が多数提案されている [30], [19], [27]．特筆すべき点として，格子ベース署名 SOLMAE[40] が韓国の耐量子計算機
暗号公募 KpqC へと提出されている．
その他補足情報: 格子ベースの Hash-and-sign 署名においてエラーベクトルの圧縮表現などを用いて署名長を短くする
テクニックが提案 [28] されており，標準化の際にはこれを盛り込んだ方式に修正される可能性があったが，2022 年 11月に開催された第 4 回標準化会議におけるアップデート報告 [53] では別の削減方法を用いることが発表された．

3.4 格子に基づく暗号技術に関するまとめ
格子に基づく暗号技術は, LWE 問題, Ring-LWE 問題, NTRU 問題を安全性の根拠とする方式をはじめ、これまで数多く提案されており、米国 NIST PQC プロジェクトで提案された暗号技術としては最も多くの暗号がこのカテゴ
リーに分類されている.
この米国 NIST PQC プロジェクトを通じて 2022 年 7 月に CRYSTALS-Kyber が標準的な暗号方式として，

CRYSTALS-Dilithium お よ び FALCON が 標 準 的 な 署 名 方 式 と し て 選 定 さ れ た ．ま た ，CRYSTALS-Kyber とCRYSTALS-Dilithium は 2022 年 9 月に米国国家安全保障局の Commercial National Security Algorithm Suite
2.0 (CNSA2.0) にも選定されている [48]．NIST PQC の最終ラウンドまでの選定に漏れた方式の中でも，米国以外の公的機関において推奨暗号とされているものが存在する．一例として，FrodoKEM が 2020 年 8 月よりドイツ情報
セキュリティ庁 (BSI) の推奨暗号に [29]，2022 年 1 月にはオランダ通信・安全委員会 (NLNCSA) により最も安全な暗号の例として推奨されている [34]．Google 社の chrome ブラウザには，TLS レイヤーの性能試験目的で搭載された耐量子計算機暗号プロトコル CECPQ1[13] および CECPQ2[18] にそれぞれ NewHope の USENIX 発表バージョン [11] と NTRU が実装されていたが，2023 年 1 月現在ではともに削除されている．IBM 製テープドライブのプロ
トタイプとして、CRYSTALS-Kyber と CRYSTALS-Dilithium の組み合わせにより暗号化を行うものが制作されている [43]．DNS サーバの一種である PowerDNS において，耐量子機能を実現する署名として FALCON のテスト用の実装が行われている [36]．オープンソースライブラリへの導入として，WireGuard VPN protocol への SABER の
実装 [38]，WolfSSL への CRYSTALS-Kyber，FALCON の実装 [60]，OpenSSH への Streamlined NTRU Prime の実装 [51] などが存在する他，Open Quantum Safe (OQS) プロジェクトによる liboqs ライブラリには暗号化・鍵交換の方式として CRYSTALS-Kyber，NTRU，SABER，FALCON，FrodoKEM，NTRU-Prime が，署名方式として

CRYSTALS-Dilithium と FALCON が実装されている [52]．このように格子に基づく暗号技術の社会実装が徐々に進みつつある．
格子に基づく暗号技術の安全性の根拠となる問題としては, 先に挙げた LWE 問題, Ring-LWE 問題, NTRU 問題以
外にも Compact LWE 問題, Module-LWE 問題, LWR (Learning With Rounding) 問題, BDD (Bounded Distance

Decoding) 問題, SIS (Small Integer Solution) 問題他, 多くのバリエーションが存在している. 一般的な格子問題を解く手法としては, LLL アルゴリズム, BKZ アルゴリズムがよく知られており, LWE 問題については更に SIS 問題や

BDD 問題に還元する解析手法が知られている.
格子問題の困難性をベースとした暗号方式で最初のものは, Ajtai[1] により 1996 年に行われた, SIS 問題が格子問
題の最悪時と同等かそれ以上に困難であることの証明およびそれを用いた暗号学的ハッシュ関数の構成である. また,1997 年には Ajtai と Dwork[9] により, unique SVP の最悪困難性を安全性の根拠とした公開鍵暗号が提案されている.
この公開鍵暗号方式は翌年, Nguyen らによる解読実験 [50] により必要なパラメータが長大となり実用的でないことが明らかにされたものの, その後の格子に基づく暗号構成の基礎となっている.

35

1996 年に Hoﬀstein らによって提案された NTRU 暗号 [39]*6 は, 発表当初安全性証明が付けられておらず, 攻撃と修正が繰り返されていたが, 2011 年 Stehlé ら [57] により方式が修正され、イデアル格子上の問題の困難性に還元可能なことが示されている. 一方で, 2016 年には subﬁeld attack[4] のような体の構造を使って格子の次元を圧縮する攻撃も提案されており, 暗号の構成のためには次元や法の大きさだけでなく, 環・体の構造にも注意を払う必要がある.

2005 年に Regev[54] により提案された LWE 問題は, 論文発表と同時にそれを暗号の安全性根拠として保障する重要な三つの性質が示された. ひとつは問題の average-case to worst case reduction, つまりパラメータを固定した際,問題の (秘密ベクトル s に関する) 平均的な計算量が, 最悪計算量 (難しいインスタンスを生成するような s の集合に対する計算量) と高々多項式倍の違いしか無いことであり, 残りの二つは判定 LWE と探索 LWE の等価性, および量子ア
ルゴリズムによる困難な格子問題への還元である. これらの定理を組み合わせることにより, Regev 自身により提案された公開鍵暗号を解読することが平均的に難しいことが示され, その後の様々な LWE ベース暗号の構成の基礎なった.

LWE 格子問題への還元に関して, 2013 年には古典計算機による還元も示されている [17].
LWE 問題の欠点である鍵サイズの大きさを改善するため, 2010 年には Lyubashevsky ら [45, 46] により Ring-LWE
問題が, 2015 年には Langlois ら [47] により Module-LWE 問題が暗号化方式と同時に提案され, LWE 問題における関係と類似の, 解読の平均的な困難さが証明されている. 一方で, これらの変種とオリジナルの LWE 問題との関係性は自明ではなく, 同程度の難しさを持つかどうかは未解決問題である. 一般的に Ring(Module)-LWE 問題のインスタン
スは LWE 問題のインスタンスとして書きなおすことができるため, LWE 問題は Ring(Module)-LWE 問題よりも困難であるという関係は自明であるが, 逆の関係は知られていない. 法 q が大きい場合には, Ring-LWE は Module-LWE
よりも困難であることが知られている [10].
実装時の問題として, 離散 Gauss 分布を正確に生成することは難しいことが挙げられる. ノイズをある整数区間から一様分布として取った場合でも, 格子問題へと量子帰着が可能であることが 2013 年に Döttling ら [24] により示された. この方向性の研究として, Bai ら [16] により提案された, Rényi エントロピーを用いた, 理想的な Gauss 分布を用いた暗号方式とそれを近似的な分布に置き換えた方式の間での安全性の低下を議論するものがある.
また, 格子問題の計算機による具体的な求解に関して， 2016 年より暗号解読コンテスト LWE Challenge[58] が開催されている. 第 3.1 節に, 2022 年 8 月現在の状況について記載した. 特に 3.3 節で示された各暗号方式のパラメータから見ると, 解が得られている値からは, 大きな隔たりがみられる. 格子に基づく暗号技術は, 各方式毎にパラメータ設定
手法に対する制約が異なっていることから, 解読コンテストのサイズに基づく解読到達レベルを, 具体的な暗号方式の安全性の根拠とすることは, 難しいところではあるものの, 古典計算機での解読困難性を測る上での検討の一つに値すると考えられる.
格子に基づく暗号技術の安全性の根拠となる問題は, 古典計算機・量子計算機のいずれにおいても現時点で効率的な解読手法は見つかっていないが、格子に基づく暗号技術は未だ研究途上にあり, 今後も研究の進捗を注視する必要がある.

*6 文献上は 1998 年の国際会議 ANTS だが, 初出は CRYPTO1996 の Rump Session である.

36

第 3 章の参照文献[1] M. Ajtai. Generating hard instances of lattice problems. Proceedings of the 28th Annual ACM Symposiumon the Theory of Computing, pp. 99-108, 1996.
[2] M. Ajtai. Generating Hard Instances of the Short Basis Problem. Proceedings of ICALP’99, Springer LNCS
vol.1644, pp.1–9, 1999.
[3] G. Alagic, D. Apon, D. Cooper, Q. Dang, J. Kelsey, J. Lichtinger, Y.-K. Liu, C. Miller, D. Moody, R. Peralta, R. Perlner, A. Robinson, D. Smith-Tone. Status Report on the Third Round of the NIST PostQuantum Cryptography Standardization Process. https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.
IR.8413.pdf.
[4] M. Albrecht, S. Bai, L. Ducas. A subﬁeld lattice attack on overstretched NTRU assumptions. Advancesin Cryptology – CRYPTO 2016 – 36th Annual International Cryptology Conference, Part I, Springer LNCS
vol. 9814, pp. 153-178, 2016.
[5] R. Avanzi, J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler,
D. Stehlé. CRYSTALS-Kyber – Submission to the NIST post-quantum project. https://pq-crystals.
org/kyber/data/kyber-specification.pdf, 2023-02-21 閲覧．
[6] R. Avanzi, J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler,
D. Stehlé. CRYSTALS-Kyber – Submission to the NIST post-quantum project. https://pq-crystals.
org/kyber/data/kyber-specification-round2.pdf, 2023-02-21 閲覧．
[7] R. Avanzi, J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler,
D. Stehlé. CRYSTALS-Kyber – Submission to the NIST post-quantum project. https://pq-crystals.
org/kyber/data/kyber-specification-round3-20210804.pdf, 2023-02-21 閲覧．
[8] M. R. Albrecht, B. R. Curtis, A. Deo, A. Davidson, R. Player, E. W. Postlethwaite, F. Virdia, T. Wunderer.
Estimate all the {LWE, NTRU} schemes!(2018). Security and Cryptography for Networks – 11th International Conference, Springer LNCS vol. 11035, pp. 351-367, 2018. https://estimate-all-the-lwe-ntruschemes.github.io/docs/.
[9] M. Ajtai, C. Dwork. A public-key cryptosystem with worst-case/average-case equivalence. Proceedings ofthe 29th Annual ACM Symposium on the Theory of Computing, pp. 284-293, 1997.
[10] M. Albrecht, A. Deo. Large modulus Ring-LWE ≥ Module-LWE. Advances in Cryptology – ASIACRYPT
2017 – 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Part I, Springer LNCS vol. 10624, pp. 267-296, 2017.
[11] E. Alkim, L. Ducas, T. Pöppelmann, P. Schwabe. Post-Quantum key exchange: A new hope. Proceedings ofthe 25th USENIX Conference on Security Symposium. SEC’16. Austin, USENIX Association, pp. 327-343,

37

2016.
[12] M. R. Albrecht, L. Ducas, G. Herold, E. Kirshanova, E. W. Postlethwaite, M. Stevens. The general sieve
kernel and new records in lattice reduction. Advances in Cryptology – EUROCRYPT 2019, Springer LNCS
vol. 11477, pp. 717–746, 2019.
[13] M. Braithwaite. Experimenting with Post-Quantum Cryptography. https://security.googleblog.com/
2016/07/experimenting-with-post-quantum.html, 2023-02-21 閲覧.
[14] J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, D. Stehlé.
CRYSTALS – Kyber: A CCA-secure module-lattice-based KEM. IEEE European Symposium on Security
and Privacy (EuroS&P), pp. 353-367, 2018.
[15] S. Bai, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler, D. Stehlé. CRYSTALSDilithium algorithm speciﬁcations and supporting documentation (February 8, 2021). https://pqcrystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf.
[16] S. Bai, T. Lepoint, A. R.-Langlois, A. Sakzad, D. Stehlé, R. Steinfeld. Improved security proofs in latticebased cryptography: Using the Rényi divergence rather than the statistical distance. Journal of Cryptology,
vol. 31, Iss. 2, pp. 610-640, 2018.
[17] Z. Brakerski, A. Langlois, C. Peikert, O. Regev, D. Stehlé,. Classical hardness of learning with errors.
Symposium on Theory of Computing Conference, STOC’13, pp. 575-584, 2013.
[18] The Chromium Projects. CECPQ2. https://www.chromium.org/cecpq2/, 2023-02-21 閲覧.
[19] C. Chuengsatiansup, T. Prest, D. Stehlé, A. Wallet, K. Xagawa. ModFalcon: compact signatures based on
Module-NTRU lattices. Proceedings of the 15th ACM Asia Conference on Computer and Communications
Security, ASIA CCS

20, pp. 853-866, 2020.

[20] L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler, D. Stehlé. CRYSTALS-Dilithium
algorithm speciﬁcations and supporting documentation (November 30, 2017). https://pq-crystals.org/
dilithium/data/dilithium-specification.pdf.
[21] L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler, D. Stehlé. CRYSTALS–Dilithium:
A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded
Systems, vol. 2018, Iss. 1, pp. 238-268, 2018.
[22] L. Ducas, T. Lepoint, V. Lyubashevsky, P. Schwabe, G. Seiler, D. Stehlé. CRYSTALS–Dilithium: Digital
signatures from module lattices. Cryptology ePrint Archive, 2017/633, 2017.
[23] L. Ducas, T. Prest. Fast Fourier Orthogonalization. Proceedings of the ACM on International Symposium
on Symbolic and Algebraic Computation, ISSAC

16, pp. 191-198, 2016.

[24] N. Döttling, J. M.-Quade. Lossy codes and a new variant of the learning-with-errors problem. Advances in
Cryptology – EUROCRYPT 2013 – 32nd Annual International Conference on the Theory and Applicationsof Cryptographic Techniques, Springer LNCS vol. 7881, pp. 18-34, 2013.
[25] L. Ducas, J. Schanck. https://github.com/pq-crystals/security-estimates, 2023-02-21 閲覧．
[26] L. Ducas, M. Stevens, W. v. Woerden. Advanced lattice sieving on GPUs, with tensor cores. Advances in
Cryptology – EUROCRYPT 2021, Springer LNCS vol. 12697, pp. 249–279, 2021.
[27] T. Espitau, P.-A. Fouque, F. Gérard, M. Rossi, A. Takahashi, M. Tibouchi, A. Wallet, Y. Yu. Mitaka: A
simpler, parallelizable, maskable variant of Falcon. Advances in Cryptology – EUROCRYPT 2022, Springer
LNCS, vol. 13277, pp. 222-253, 2022.
38

[28] T. Espitau, M. Tibouchi, A. Wallet, Y. Yu. Shorter hash-and-sign lattice-based signatures. Advances in
Cryptology – CRYPTO 2022 - 42nd Annual International Cryptology Conference, Springer LNCS 13508,
245–275, 2022.
[29] Federal Oﬃce for Information Security. BSI – Technical Guideline (Cryptographic Mechanisms: Recommendations and Key Lengths). Version 2023-01, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10,2023-

02-21 閲覧．
[30] P.-A. Fouque, F. Gérard, M. Rossi, Y. Yu.

Zalcon: an alternative FPA-free NTRU sampler for Fal-con. Third PQC Standardization Conference, https://csrc.nist.gov/Presentations/2021/zalcon-analternative-fpa-free-ntru-sampler-for-fa, 2023-02-21 閲覧.
[31] P. -A. Fouque, J. Hoﬀstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Prest, T. Ricosset, G. Seiler,
W. Whyte, Z. Zhang. Falcon: Fast-Fourier lattice-based compact signatures over NTRU. Speciﬁcation
v1.0. https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/round1/submissions/Falcon.zip[32] P. -A. Fouque, J. Hoﬀstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Prest, T. Ricosset, G. Seiler,
W. Whyte, Z. Zhang. Falcon: Fast-Fourier lattice-based compact signatures over NTRU. Speciﬁcation v1.2
– 01/10/2020. https://falcon-sign.info/falcon.pdf.
[33] A. Fiat, A. Shamir. How to prove yourself: Practical solutions to identiation and signature problems.
Advances in Cryptology – CRYPTO ’86, Springer LNCS vol. 186, pp. 186-194, 1986.
[34] General Intelligence and Security Service. Prepare for the threat of quantumcomputers. https://english.
aivd.nl/publications/publications/2022/01/18/prepare-for-the-threat-of-quantumcomputers,
2023-02-21 閲覧．
[35] C. Gentry, C. Peikert, V. Vaikuntanathan. Trapdoors for hard lattices and new cryptographic constructions.
Proceedings of the Fortieth Annual ACM Symposium on Theory of Computing. STOC

08, pp. 197- 206,

2008.
[36] M. Grillere, P. Thomassen, N. Wisiol, FALCON-512 in PowerDNS. Website: https://blog.powerdns.com/
2022/04/07/falcon-512-in-powerdns/.
[37] D. Hofheinz, K. Hövelmanns, E. Kiltz. A modular analysis of the Fujisaki-Okamoto transformation. Theoryof Cryptography – TCC 2017, LNCS,vol. 10677, pp. 341-371, 2017.
[38] A. Hülsing, K. -C. Ning, P. Schwabe, F. Weber, P. R. Zimmermann. Post-quantum WireGuard. IEEE
Symposium on Security and Privacy (SP), pp. 304-321, 2021.
[39] J. Hoﬀstein, J. Pipher, J. H. Silverman. NTRU: A ring-based public key cryptosystem. Algorithmic Number
Theory, 3rd International Symposium, ANTS-III, Springer LNCS vol. 1423, pp. 267-288, 1998.
[40] K. Kim, M. Tibouchi, A. Wallet, T. Espitau, A. Takahashi, Y. Yu, S. Guilley. https://kpqc.or.kr/images/
pdf/SOLMAE.pdf, KpqC Competition Round 1.
[41] V. Lyubashevsky. Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures. Advancesin Cryptology – ASIACRYPT 2009. LNCS vol. 5912, pp. 319-339, 2009.
[42] V. Lyubashevsky.

CRYSTALS-Dilithium Round 3 Presentation.

Third PQC Standardization

Conference, 2021-06-07, https://csrc.nist.gov/Presentations/2021/crystals-dilithium-round-3presentation, 2023-02-21 閲覧.
39

[43] M. Lantz, M. Hill, World s ﬁrst quantum computing safe tape drive. https://www.ibm.com/blogs/
research/2019/08/crystals/, 2019-08-23, 2023-02-21 閲覧．
[44] R. Lindner, C. Peikert. Better Key sizes (and attacks) for LWE-Based encryption. Topics in Cryptology– CT-RSA 2011 – The Cryptographers’ Track at the RSA Conference 2011, Springer LNCS vol. 6558, pp.
319-339.
[45] V. Lyubashevsky, C. Peikert, O. Regev. On ideal lattices and learning with errors over rings. Advances in
Cryptology – EUROCRYPT 2010 – 29th Annual International Conference on the Theory and Applicationsof Cryptographic Techniques, LNCS vol. 6110, pp. 1-23, 2010.
[46] V. Lyubashevsky, C. Peikert, O. Regev. On ideal lattices and learning with errors over rings. Journal of theACM, Vol. 60, Iss. 6, pp. 1-35, 2013.
[47] A. Langlois, D. Stehlé. Worst-case to average-case reductions for module lattices. Designs, Codes andCryptography, Vol. 75, Iss. 3, pp. 565-599, 2015.
[48] National Security Agency. Announcing the Commercial National Security Algorithm Suite 2.0. https://
media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF, 2022-09-07.
[49] National Institute of Standards and Technology.

Selected Algorithms 2022. https://csrc.nist.gov/

Projects/post-quantum-cryptography/selected-algorithms-2022, 2023-02-21 閲覧.
[50] P. Q. Nguyen, J. Stern. Cryptanalysis of the Ajtai-Dwork cryptosystem. Advances in Cryptology – CRYPTO’98, 18th Annual International Cryptology Conference, LNCS vol. 1462, pp. 223-242, 1998.
[51] OpenSSH. OpenSSH 8.9 was released on 2022-02-23. https://www.openssh.com/txt/release-8.9, 202302-21 閲覧.
[52] Open Quantum Safe. Algorithms in liboqs. https://openquantumsafe.org/liboqs/algorithms/, 202302-21 閲覧．
[53] T. Prest.

FALCON Update.

Fourth PQC Standardization Conference,

2022-11-29,

https://csrc.nist.gov/csrc/media/Presentations/2022/falcon-update/images-media/session-1-prestfalcon-pqc2022.pdf, 2023-02-21 閲覧.
[54] O. Regev. On lattices, learning with errors, random linear codes, and cryptography. Proceedings of the 37th
Annual ACM Symposium on Theory of Computing, pp. 84-93.
[55] O. Regev. The learning with errors problem (invited survey). Proceedings of the 25th Annual IEEE Conference on Computational Complexity, CCC 2010, pp. 191-204, 2010.
[56] P. Schwabe. 6 years of NIST PQC, looking back and ahead. The 13th International Conference on PostQuantum Cryptography – PQCRYPTO 2022, Invited talk, 2022.
[57] D. Stehlé, R. Steinfeld,. Making NTRU as secure as worst-case problems over ideal lattices. Advances in
Cryptology – EUROCRYPT 2011 – 30th Annual International Conference on the Theory and Applicationsof Cryptographic Techniques, Springer LNCS vol. 6632, pp. 27-47, 2011.
[58] TU Darmstadt UC San Diego. LWE Challenge. https://www.latticechallenge.org/lwe_challenge/
challenge.php[59] wolfSSL. ポスト量子暗号 Falcon 署名方式を追加しました, https://www.wolfssl.jp/wolfblog/2021/12/
21/integration-falcon-signature-scheme-wolfssl/, 2023-02-21 閲覧.
[60] wolfSSL. wolfSSL support for Apache httpd and curl (Post-Quantum Edition). https://github.com/
wolfSSL/osp/blob/master/apache-httpd/README_post_quantum.md, 2023-02-21 閲覧.
40

—————————————–

41

第4章

符号に基づく暗号技術
本章では符号に基づく暗号技術についてまとめる．符号に基づく暗号技術の安全性は LPN 問題やシンドローム復号
問題を解く計算の困難性に依存している.
■準備:

本章で使用する記号・用語を以下にまとめる．以下では, q を素数 p の冪とする. すなわち, ある正整数 k が存在して q = pk である.
有限体:

Fq で位数が q の有限体を表す.

ハミング重みとハミング距離: Vn を有限体 Fq 上の n 次元ベクトル空間とする.

• ベクトル v = (v1 , v2 , . . . , vn ) ∈ Vn のハミング重みとは, 非ゼロの係数の数である. すなわち, HW(v) =#{vi | vi 6= 0} である.
• ハミング距離を dH (x, y) = HW(x − y) で定義する.
• SH (n, w) でハミング重みが w の n 次元ベクトル全体の集合を表す.
≤• SH(n, w) でハミング重みが w 以下の n 次元ベクトル全体の集合を表す.

■線形符号:

自然数 n および 素数冪 q について, Fq 上の n 次元ベクトル空間の部分空間を Fq 上の線形符号と呼び,C で表す. n を符号長と呼ぶ. Fq 上の線形符号 C の符号語 c は, 一次独立な k 個の符号語 c1 , . . . , cK の Fq 係数一次結合で表すことができる. このとき [c1 , . . . , ck ] を基底と呼ぶ. k を線形符号の次元と呼ぶ. Fq 上の線形符号の符号長がn, 次元が k であるとき, [n, k]q -線形符号とよぶ. [n, k]q -線形符号 C の生成行列とは, 符号 C の基底ベクトルを行とす
で, c ∈ Fn
る行列 G ∈ Fqk×n である. [n, k]q -線形符号 C のパリティ検査行列とは, 行列 H ∈ Fr×n
q に対して, c ∈ Cqならばかつその時に限り c · H ⊤ = 0 となるものである. H の行が線形独立であれば, r = n − k である.

[n, k]q -線形符号 C の最小距離 d とは, 符号 C の非ゼロ符号語の中で最小のハミング重みをもつ符号語のハミング重みのことを言う. すなわち, d = minc∈C\{0} HW(c) である.

[n, k]q -線形符号 C の生成行列 G が決まっている場合, メッセージ s ∈ Fkq を 符号語 sG と一対一対応させることができる. 符号は, 生成行列やパリティ検査行列をうまく設計することで, 符号語に加えられた誤りを訂正することができる. 送信する符号語を c とし, 通信路上で乗った誤りを e とする. 受信者側は受信語として, y = c + e を得る. 受信者は符号の復号アルゴリズムを用いて復号を行い, y から c を得る. 受信者がハミング重み t までの誤り e を一意に訂正できるとき, 符号の訂正能力が t であるという. 一般に, t ≤ b(d − 1)/2c であることが分かる. 復号アルゴリズムは
パリティ検査行列を用いることもある. その際に, t = yH ⊤ を計算し, これをシンドロームと呼ぶ.
本稿では、具体的な線形符号 (リード・ソロモン符号, リード・マラー符号, Goppa 符号) の詳細については扱わな
い. 符号理論の教科書や, 電子情報通信学会 知識の森 「1 群 2 編 符号理論」 [17] などを参照されたい.

42

4.1 符号に基づく暗号技術の安全性の根拠となる問題
本節では Learning Parity with Noise （LPN） 問題や符号に関連する問題の困難性について調査結果を述べる.

4.1.1 LPN 問題とはLPN 問題とは誤差付きの線形方程式を解けるかどうかという問題である. 1993 年に, Blum, Furst, Kearns,
Lipton [5] が困難と思われる問題として挙げ, 定式化を行った. 第 3 章において, この問題を一般化した LWE 問題を既に扱っている.

Berτ でパラメータ τ のベルヌーイ分布を表すことにする. (確率 τ で 1, 確率 1 − τ で 0 となる F2 上の分布である.) また, 自然数 k ≥ 1 について, Berkτ で, Berτ から独立に k 個サンプルを取ったときの Fk2 上の分布を表す.
■ LPN 問題:

F2 上の分布 χ および s ∈ Fk2 について, オラクル Os,χ を以下で定義する. (1) a を Fk2 から一様ランダムに選び, (2) e を分布 χ に従い選び, (3) b = s · a⊤ + e と計算し, (4) (a, b) を出力する.
また, オラクル U を (a, b) ← Fk+1と一様ランダムな組を出力するオラクルとして定義する.
2
定義 4.1 (探索版 LPN 問題) 探索版 LPN 問題とは, オラクル Os,χ へのアクセスが可能なときに, s を出力する問題である.
特に χ = Berτ のとき, LPNk,τ 問題と呼ぶ. また LPNk,τ 問題でオラクルからのサンプル数が n = n(k) に制限されるものを, LPNk,n,τ 問題と呼ぶ.
定義 4.2 (探索版 LPN 仮定) F2 上の確率分布 χ について, 敵 A の優位性をAdvA (k) = Pr [AOs,χ (1k ) = s]s←Fk2で定義する. 任意の多項式時間の敵 A について, その優位性が無視できるとき, 探索版 LPN 仮定が成立するという.
暗号プリミティブや暗号プロトコルの安全性証明のために, 判定版 LPN 仮定を用いることも多い. 判定版 LPN 問題と判定版 LPN 仮定は以下で定義される.
定義 4.3 (判定版 LPN 問題) 判定版 LPN 問題とは, オラクル Os,χ またはオラクル U へのアクセスが与えられたときに, どちらのオラクルにアクセスしているかを判定する問題である.
定義 4.4 (判定版 LPN 仮定) F2 上の確率分布 χ について, 敵 A の優位性をAdvA (k) =Pr [AOs,χ (1k ) = 1] − Pr[AU (1k ) = 1]s←Fk2で定義する. 任意の多項式時間の敵 A について, その優位性が無視できる関数であるとき, 判定版 LPN 仮定が成立するという.
探索版 LPN 問題にはランダム自己帰着が存在する [5]. すなわち, 一様ランダムに選ばれた s ∈ Fk2 について探索版

LPN 問題を解けるならば, 任意の s ∈ Fk2 について探索版 LPN 問題を解くことが出来る.
Katz, Shin, Smith [29] によれば, [5, 44] と同様に判定版 LPN 仮定を探索版 LPN 仮定に帰着することが出来る.

43

定理 4.5 ([29]) 判定版 LPNk,τ 仮定を破る t ステップ, n 回のクエリ, 優位性 δ の敵が存在すると仮定する. このとき, 探索版 LPNk,τ 仮定を破る t′ ステップ, n′ 回のクエリ, 優位性 δ ′ の敵が存在する. ここで,t′ = O(δ −2 tklogk), n′ = O(δ −2 nlogk), δ ′ ≥ δ/4.
■変種:

以上に列挙した LPN 問題・仮定では, 基礎となる体として F2 を用いていた. 体を Fq に変更した LPN 問

題・仮定が用いられることもある. 特に q を素数とした場合には LWE 問題と非常によく似た問題・仮定となるが, 誤差分布 χ の定義が異なることが多い.

LWE 問題では剰余環 Zq を用いている. 応用の観点からは, 誤差分布 χ からのサンプル x の絶対値が高い確率で小さいことが重視される. 一方, LPN 問題では有限体 Fq を用いている. また, 符号からの要求としてハミング重みを考えることが多いため, 誤差分布 χ は 0 を取る確率が大きいことが求められる. たとえば, ベルヌーイ分布の一般化として,
確率 τ で 0 を確率 1 − τ で Fq \ {0} のランダムな値を取る分布が用いられる. これは格子問題と符号問題のアナロ
ジーとして考えることができる.

4.1.2

LPN 問題の拡張

4.1.2.1 復号問題
オラクルからのサンプル数を固定し n = n(k) とする. LPNk,n,τ 問題での m 個のサンプル (a1 , b1 ), (a2 , b2 ), . . . , (an , bn )を行列・ベクトル表示して,k×n⊤⊤
A = [a⊤,b = s · A + e
1 a2 . . . an ] ∈ F2とする. 符号理論の観点からは, 一様ランダムな行列 A ∈ Fk×nを生成行列とする [n, k]2 -線形符号の受信語 b から元2のメッセージ s を復元する問題と捉えることができる.

4.1.2.2 シンドローム復号問題
先ほど挙げた復号問題の “双対” として, シンドローム復号問題が挙げられる. シンドローム復号問題 SDk,n,w とは,⊤⊤
H = [h⊤1 h2 . . . hn ] ∈ F2(n−k)×n, u ∈ Fk2

および自然数 w が与えられた時に, e · H ⊤ = u かつハミング重みが w 以下となる e ∈ Fn
2 を求める問題である.

A ∈ Fk×n で生成される符号のパリティ検査行列を H ∈ F(n−k)×n とし, b·H ⊤ (= e·H ⊤ ) を u とすれば, LPNk,n,τ
問題や復号問題をシンドローム復号問題 SDk,n,O(τ n) に変換可能である.

4.1.2.3

Module-LPN 問題

Module-LWE 問題 (3.1.1 節) と同様に, Module-LPN 問題を定義することができる.
定義 4.6 (探索版 Module-LPN 問題) 適当な k0 次の Fq 係数多項式 f (x) を考え, 環 Rq = Fq [x]/(f (x)) を固定する. Rq 上の確率分布 χ を固定する.

Rq 上の誤差分布 χ および s ∈ Rqk について, オラクル Os,χ を以下で定義する. (1) a を Rqk から一様ランダムに選び, (2) e を分布 χ に従い選び, (3) b = s · a⊤ + e と計算し, (4) (a, b) ∈ Rq

(k+1)

を出力する.

探索版 Module-LPN 問題とは, オラクル Os,χ へのアクセスが可能なときに, s ∈ Rqk を出力する問題である.

44

LPN 問題に対する評価

4.1.3

サンプル数を固定した場合, A および b の最悪時を考えると NP 困難になることが Berlekamp, McEliece, vanTilborg [12] によって示されている. *1 また, Håstad [25] により近似版 LPN 問題*2 の NP 困難性も示されている.
しかし平均時の困難性についてはよく分かっていない. そのため LPN 問題を解くための提案されたアルゴリズムについて調査を行った.

LPNk,n,τ 問題を解くための素 朴な方法として, 時間 poly(n, k) · O(2k ) で動作する総当たり法がある. 閾値d ≥ 1 を固定する. s ∈ Fk2 の候補ごとに, e = b − sA を計算し, e のハミング重みが (1 + 1/d)τ n 以下であれば s を解として出力するというものである. Chernoﬀ の補題*3 から e ← Bern
τ としたとき, d ≥ 1 について

Pr[HW(e) ≤ (1 + 1/d)τ n] ≤ exp(−τ n/3d2 ) のため, 高い確率で成功する.
以降では, O(2k ) 以下の時間で解を求めるアルゴリズムについて考察する. 現在, 大別して以下の 3 つのアルゴリズ
ムが知られている.

1. Blum, Kalai, Wasserman [7] の BKW アルゴリズム
2. Arora, Ge [2] の「再線形化」アルゴリズム
3. シンドローム復号問題として解くアルゴリズム

4.1.3.1

BKW アルゴリズムおよびその改良

Blum, Kalai, Wasserman [7] は BKW アルゴリズムと呼ばれるアルゴリズムを提案した.
基本アイデアは以下である. オラクルからのサンプル (a, b) が常に a = (1, 0, . . . , 0) という形であれば, b = s1 + eとなる. このようなサンプルを大量に集めれば, s1 を多数決法で求めることが出来る. 一般に uj を j 番目の単位ベク
トルとして, (uj , b) という形のサンプルを集めれば sj を多数決法で求められる. そこでオラクル Os,τ からのサンプルを用いて, 上記のようなサンプルを生成することを目指す.

Blum らの見積もりによれば, うまくパラメータを設定することで, 時間計算量・空間計算量ともに 2O(k/logk) を得る. その後, Levieil と Fouque [33], Kirchner [27], Guo, Johansson, Löndahl [23], Zhang, Jiao, Wang [46], Bogosと Vaudenay [13], Esser, Kübler, May [19], Esser, Heuer, Kübler, May, Sohler [18] などで改良やメモリと時間のト
レードオフの議論がおこなわれている.
■サンプル数が少ない場合:

これまでに挙げてきた BKW アルゴリズムおよびその改良では, サンプルが O(2k/logk )個必要であった. Lyubashevsky [35] はサンプル数が k 1+ϵ 個と少ない場合であっても, BKW アルゴリズムを適用できるような指数個のサンプルの構成法を示している. Kirchner [27] も同様の構成法を示している. Esser, Kubler,

May [19] はサンプル数が少ない場合の BKW および Gauss アルゴリズムについて, より詳細な解析を行った.
4.1.3.2

Arora-Ge アルゴリズム

Arora と Ge [2] は多変数多項式問題で古くから用いられている再線形化と呼ばれる手法を用いて, LPN 問題を解くことを考えた. このアルゴリズムを LPNk,n,τ に用いた場合, w = τ n として, poly(k w ) 時間で解くことができる.
*1 A および b を与えられたときに, 線形方程式 sa⊤ = bi を満たす数を最大化する s を探索する問題を考える.
i*2 A および b を与えられたときに, 線形方程式 sa⊤ = bi を近似度×最大値以上満たす s を探索する問題.
i*3 X1 , . . . , Xn を 相 互 に 独 立 な {0, 1} 確 率 変 数 と し, X = X1 + · · · + Xn の 期 待 値 を µ と す る と,
(
)
µ
(1+ϵ)
2

exp(ϵ)/(1 + ϵ)

. 特に, 0 < ϵ ≤ 1 の場合, Pr[X ≥ (1 + ϵ)µ] < exp(−ϵ µ/3).

45

Pr[X ≥ (1 + ϵ)µ] <表 4.1: 確率 1/2 以上で SD 問題を解く場合のパラメータ例 (Full Distance Decoding の場合)

lg(Time)/nlg(Space)/n

備考

Pra62 (Lee-Brickel)

0.121

–

[43], [31]Stern89

0.117

0.0135

[45]

MMT11

0.112

0.0216[37]

BJMM120.102

0.0286[6]MO15

0.09670.0???

[38]

BM17

0.09530.0910[10]; MO15 を最適化したもの

BM18

0.08850.0736[11]

poly(k w ) = 2O(τ nlogk) であるから, τ = o(k/(nlog2 k)) のようにエラーがスパースであれば, BKW アルゴリズムよりも効率が良い. 実際の符号暗号のパラメータ設定では, エラーを上記のようにスパースに設定することはないため, 暗号の攻撃アルゴリズムとして用いるには重要度が低い.

4.1.3.3

SD 問題を経由するアルゴリズム(n−k)×n

LPNk,n,τ に対応するシンドローム復号問題を考える. ハミング重みを w ≈ τ n とし, H ∈ F2

およびu ∈ Fn−kが与えられ, e · H ⊤ = u となるような, ハミング重みが w 以下の e ∈ Fn
2 を探索する問題である.
2
対応する線形符号の最小距離を d と置く. (2 進符号の場合, Gilvert-Varshamov 限界により, k/n ≈ 1 − H(d/n) である*4 .）w ≈ d の場合を Full Distance Decoding の場合と呼び, w ≈ d/2 の場合を Half Distance Decoding と呼ぶ.
この問題を総当りで解く場合には, ハミング重みが w の n 次元ベクトル e を列挙すればよい. そのため, 時間計算n
量は O( w
) となる.

より効率的な手法として, Prange は “Information set decoding” と呼ばれる手法 [43] を提案した. 基本アイデアは以下である:

1. 一様ランダムに H の列ベクトルを入れ替え, H̃ = H · P とする. (P は置換行列.)
2. H̃ を組織化し, [In−k | Z] = S · H̃ とする.
3. u′ = uS ⊤ を計算する.
4. u′ のハミング重みが w 以下であれば, この置換 P を採用し e = (u′ , 0k ) · P ⊤ を出力する.
u′ のハミング重みが w 以下であるため, e のハミング重みも w 以下である. また, e · H ⊤ = (u′ , 0k ) · P ⊤ H ⊤ =(u′ , 0k ) · H̃ ⊤ = (u, 0k )S ⊤ H̃ ⊤ = (u, 0k ) · [In−k | Z]⊤ = u が成立する. よって, ステップ 4 のチェックを通るならば, e はシンドローム復号問題の解となっている. このような置換は全部で n−k
通りあるため, 探索できる確率はw
 n
 n−k
n−knw / w となる. 期待計算量は poly(n, k) · O( w / w ) となり, 先ほどの列挙法よりも速くなる.
Stern [45] 以降, 空間計算量を犠牲にすることで時間計算量を引き下げるアルゴリズムが多数提案されている. 以下
では, Both と May [11] による時間計算量の表を, 表 4.1 および 4.2 に示す. この表は, 時間計算量を最小化した場合のR = k/n の最悪時 (1/2 の少し下) についてまとめられている. したがって, 問題のパラメータによっては, 表の数値よりも速く解くことが可能となる.

*4 ここで H(p) = −plog(p) − (1 − p)log(1 − p) .

46

表 4.2: 確率 1/2 以上で SD 問題を解く場合のパラメータ例 (Half Distance Decoding の場合)

lg(Time)/nlg(Space)/n

備考

Pra62 (Lee-Brickel)

0.0576–[31]

Stern890.05570.0135[45]

BLP

0.05550.0148[9]MMT110.05370.0216[37]

BJMM120.04940.0286[6]MO150.0473

0.0???

[38]

BM18

0.04650.0294[11]

パラメータ設定によっては, LPNk,n,τ 問題を SDk,n,O(τ n) 問題に置き換えることで, これらの SD 問題用アルゴリズ
ムも検討する必要がある.

4.1.3.4 量子アルゴリズムへの耐性
現在のところ多項式時間で LPN 問題を解く量子アルゴリズムは提案されていない. しかし量子アルゴリズムを利用した攻撃の高速化方法を Kachigar と Tillich [30] が提案している.*5 Esser, Kübler, May [19] は, BKW や Gauss ア
ルゴリズムの変種を量子アルゴリズムで高速化できる点を指摘している.

4.1.3.5 現状の進展
格子の場合と同様に “Decoding Challenge” (https://decodingchallenge.org/) というウェブサイトが作成された.

1. F2 係数の一様ランダムな線形符号に対するシンドローム復号問題
2. F2 係数の一様ランダムな線形符号に対するハミング重みが小さい符号語を探索する問題
3. F3 係数の一様ランダム線形符号に対するシンドローム復号問題
4. Goppa 符号を用いた Niederreiter 暗号の場合のシンドローム復号問題 (Classic McEliece の一方向性に対応
4.3.1)
5. QC-MDPC 符号に基づくシンドローム復号問題のチャレンジ (BIKE や HQC の一方向性に対応 4.3.2 4.3.3)のカテゴリが用意されている. 1, 2, 4, 5 に関しては研究および攻撃が進んでおり, 2022 年 10 月現在,

• 1. n = 550, k = n/2 に対して w = 67 (成定, 福島, 清本 2022/02）• 2. n = 1280, k = n/2 の場合に w = 215 (Neves 2020/06)• 4. n = 1284, k = 0.8n に対して w = 24 (Esser, May, Zweydinger 2021/08)• 5. n = 3138, k = n/2 に対して w = 56 (Esser, Zweydinger 2022/04)での解が得られている。1 の結果については, Narisada, Fukushima, Kiyomoto [39] を, 4 の結果については, Esser,

May, Zweydinger [20] を参照されたい.
*5 Kirshanova [28] が Kachigar と Tillich の結果 [30] の改良を提案していたが, 誤りがあったことが報告されている. そのため, 2018 年時点

でのベストな量子アルゴリズムは Kachigar と Tillich [30] であると考えられる.

47

4.2 代表的な符号に基づく暗号方式の説明
本節では, 符号に基づく代表的な暗号方式と署名方式の説明を行う. 以下では, Sn で n 次対称群を表し, GLk (Fq ) でk 次の Fq 要素正則行列全体がなす群を表す.

4.2.1 暗号方式 1: McEliece 暗号
McEliece [36] が提案した古典的な暗号方式である. 以下では q = 2 とする.
• k : 安全性パラメータ• n : サンプルの個数• τ : 誤差パラメータ (例: τ n = O(k) )• t : 誤り訂正符号の誤り訂正能力 ( t = Ω(τ n) )鍵生成:

誤り訂正能力が t である [n, k]2 -線形符号の生成行列 G を生成する. S ← GLk (F2 ) を一様ランダムに選ぶ.

P ← Sn を一様ランダムに選ぶ. G̃ = SGP とする.
公開鍵を G̃ とし, 秘密鍵を (S, G, P ) とする.
暗号化:
復号:

平文を m ∈ Fk2 とする. 乱数 e ← Bern
τ を選び, 暗号文 c = mG̃ + e を計算する.

v̂ = cP −1 を計算する. v̂ を誤り訂正符号で訂正し m′ ∈ Fk2 を得る. m = m′ S −1 を出力する.

復号の正当性は以下で確認される. c = mG̃ + e として, v̂ = cP −1 を計算すると,v̂ = mG̃P −1 + eP −1 = mSG + eP −1を得る. mSG は符号語であり, eP −1 は誤りである. eP −1 のハミング重みが t 以下であれば, 誤り訂正符号の復号
により, m′ = mS を得る. よって, 高い確率で復号に成功する.
平文 m および G̃ が一様ランダムであれば, 暗号文 c は LPN 仮定の下で疑似ランダムである. G̃ が疑似ランダムであることを言うためには, McEliece 仮定と呼ばれる仮定が必要となる.
定義 4.7 (McEliece 仮定) [n, k]q -符号のクラス C を固定する. 敵 A の優位性をAdvA (n) = Pr[S ← GLk (Fq ), G ← C, P ← Sn : A(1n , G̃ = SGP ) = 1] − Pr[G̃ ← Fk×n
: A(1n , G̃) = 1]qで定義する. 任意の確率的多項式時間の敵 A について, その優位性が無視できる関数であるとき, McEliece 仮定が成立するという.
左側の敵は McEliece 暗号の公開鍵 (または Niederreiter 暗号の公開鍵の双対) を受け取っている. そのため, この仮定
は, McEliece 暗号の公開鍵はランダムな同サイズの行列と見分けが付かないということを意味する.

McEliece 暗号の暗号文の疑似ランダム性は, 判定版 LPN 仮定および McEliece 仮定から言える. また, 暗号文の一方向性は, 探索版 LPN 仮定および McEliece 仮定から言える.

4.2.2 暗号方式 2: Niederreiter 暗号
Niederreiter [40] が 1986 年に提案した. のちに McEliece 暗号と「等価」であることが示された. 詳しくは [32] を参照のこと. 以下では q = 2 とする.

48

• k : 安全性パラメータ• n : サンプルの個数• t : 誤り訂正符号の誤り訂正能力
鍵生成:(n−k)×n

誤り訂正能力が t である [n, k] -線形符号のパリティ検査行列 H ∈ F2を生成する. T ← GLn−k (F2 )を一様ランダムに選ぶ. Q ← Sn を一様ランダムに選ぶ. H̃ = T HQ とする.
公開鍵を H̃ とし, 秘密鍵を (T , H, Q) とする.
暗号化:
復号:

平文を e ∈ SH (n, t) とする. 暗号文 d = e · H̃ ⊤ ∈ Fn−kを計算する.
2ŵ = d · T −⊤ を計算する. ŵ を誤り訂正符号で訂正し復号し, 誤りとして e′ を得る. e = e′ Q−⊤ を出力する.

復号の正当性は以下で確認される. d = e · H̃ ⊤ として, ŵ = dT −⊤ を計算すると,v̂ = e · H̃ ⊤ T −⊤ = e · Q⊤ H ⊤ T ⊤ T −⊤ = eQ⊤ · H ⊤を得る. eQ⊤ のハミング重みが t 以下であれば, 誤り訂正符号の復号により, e′ = eQ⊤ を得る. よって, 高い確率で復号に成功する.
平文 e および H̃ が一様ランダムであれば, 暗号文 d は 判定版 LPN 仮定の下で疑似ランダムである. H̃ が疑似ランダムであることを言うためには, McEliece 暗号で McEliece 仮定を考えたように, Niederreiter 仮定を考えればよい.
定義 4.8 (Niederreiter 仮定) [n, k]q -符号のクラス C を固定する. 敵 A の優位性を(n−k)×n

AdvA (n) = Pr[T ← GLn−k (F2 ), H ← C, Q ← Sn : A(1n , H̃ = T HQ) = 1]−Pr[H̃ ← F2

: A(1n , H̃) = 1]

で定義する. 任意の確率的多項式時間の敵 A について, その優位性が無視できる関数であるとき, Niederreiter 仮定が成立するという.
暗号文の疑似ランダム性は, 判定版 LPN 仮定および Niederreiter 仮定から言える. また, 暗号文の一方向性は, 探索版

LPN 仮定および Niederreiter 仮定から言える.

4.3 符号に基づく主要な暗号方式の説明
本稿では以下の暗号方式を取り上げる. いずれも NIST PQC 標準化の中で Round 4 に進んだものである.

1. Classic McEliece: Niederreiter 暗号を採用し, 符号の構成が非常に保守的という観点からこれを取り上げる.
2. BIKE: Niederreiter 暗号的な構成を採用している. McEliece 暗号を採用, QC-MDPC 符号を用いて鍵を圧縮している, という観点からこれを取り上げる.

3. HQC: 符号版の LPR/LP 暗号を採用, Quasi-Cyclic 符号を用いて鍵を圧縮している, という特徴からこれを取り上げる.

4.3.1 暗号方式 1: Classic McEliece• 提案者: Albrecht, Bernstein, Chou, Cid, Gilcher, Lange, Maram, von Maurich, Misoczki, Niederhagen,Paterson, Persichetti, Peters, Schwabe, Sendrier, Szefer, Tjhai, Tomlinson, Wang.

49表 4.3: 符号に基づく暗号の分類
文献

暗号化

鍵交換

署名

Classic McEliece [47]

〇

〇

–

BIKE [48]〇〇–

HQC [49]〇〇–• 基本方式の説明: Niederreiter 暗号方式に基づいている. 基本符号方式として F2 上の Goppa 符号を利用している. (具体的な Goppa 符号の生成方法や符号化および復号の方法については提案方式の仕様書を参照のこと.)

q = 2m とし, n ≤ q を用いる. 2 以上の t を mt < n となるように取り, k = n − mt とする.
鍵生成:(n−k)×nt 誤りを訂正できる Goppa 符号のパリティ検査行列 H ∈ F2化し, H̃ = [In−k | T ] とする.

(n−k)×kとする.
公開鍵を T ∈ F2

をランダムに生成する. 組織符号

復号鍵を符号生成に使ったパラメータ Γ(t 次のモニックな Fq 係数既約多項式および相異なる α0 , . . . , αn−1 ∈ Fq ) とする.
(n−k)×k

暗号化 E(pk , e) : 入力を, pk = T ∈ F2と e ∈ SH (n, t) とする. H̃ = [In−k | T ] とし, 暗号文として

c = H̃ · e ∈ Fn−kを出力する.
2
復号 D(sk , c) :ハミング重み t のベクトル e を復号する.

1. c に k 個ゼロを加え, v = (c, 0k ) ∈ Fn を考える
2. Goppa 符号の復号アルゴリズムを用いて, v と距離 t 以下にある符号語 d を計算する. (なければ ⊥ を出力する)

3. e = v + d とする.
4. HW(e) = t かつ c = H̃e ならば e を出力する. (そうでなければ ⊥ を出力する.)• 鍵カプセル化方式の説明: 基本方式を決定性の公開鍵暗号とみなし, U̸⊥m 変換をかけたものとみなせる. (Round
∗
256
を用いる.
3 までは HU̸⊥m を用いていた. 以下ではハッシュ関数 H : {0, 1} → {0, 1}

鍵生成:` ビットのシード δ から乱数を生成し, 鍵生成を行う. （乱数の生成方法は省略する.）公開鍵は同じくT である. 復号鍵は Γ に加えて, n ビットの一様ランダムな文字列 s を用いる.
鍵カプセル化:

1. e ← SH (n, t) をあるアルゴリズムに従ってランダム生成する.

2. C = E(pk , e) を計算する.
3. K = H(1, e, C) とする.
4. 暗号文は C , セッション鍵は K となる.
デカプセル:

1. C ∈ Fn−kを入力とする.
2

2. b = 1 とする.
3. e ← D(sk , C) とする. e = ⊥ であれば, b = 0 , e = s と上書きする
4. K = H(b, e, C) を計算する.
5. K を出力する.
パラメータセットとして mceliece348864, mceliece348864f, mceliece460896, mceliece460896f, mceliece6688128,

mceliece6688128f, mceliece6960119, mceliece6960119f, mceliece8192128, mceliece8192128f が提案されている。今回
末尾に f が着くものは扱っていない（鍵長・暗号文長は f 無しのものと変わらない）. 表 4.4 に鍵カプセル化方式の鍵長および暗号文長, 想定セキュリティレベルをまとめた.

50

表 4.4: Classic McEliece のパラメータ. 単位は全て octet とする.
パラメータ名

レベル

公開鍵長

秘密鍵長

暗号文長

mceliece348864

1

261 120

6 492

96mceliece460896

3

524 160

13 608156

mceliece6688128

5

1 044 992

13 932208

mceliece6960119

5

1 047 319

13 948194

mceliece8192128

5

1 357 824

14 120208

4.3.2 暗号方式 2: BIKE
• 提案者: Aragon, Barreto, Bettaieb, Bidoux, Blazy, Deneuville, Gaborit, Gueron, Güneysu, Aguilar Melchor,
Misoczki, Persichetti, Sendrier, Tillich, Zémor, Vasseur, Ghosh, Richter-Brokmann.
• 基本方式の説明: Niederreiter 暗号方式に基づいている. 基本となる符号に QC-MDPC 符号を採用し, 公開鍵サ
イズを圧縮している. そのため、鍵や暗号化は格子暗号の一種の NTRU 暗号と非常に近い形をしている点が特徴である. 以下では, R = F2 [X]/(X n − 1) とする.
鍵生成:

秘密鍵 h0 および h1 を SH (n, w/2) から一様ランダムに選ぶ. 公開鍵を h = h1 /h0 ∈ R とする.

((h0 , h1 ) を QC-MDPC 符号のパリティ検査行列とし, (1, h) をその組織符号化したものとみなすことができる.)
暗号化 E(pk , (e0 , e1 )):(e0 , e1 ) を SH (2n, t) 中のベクトルとみなす. c = e0 + e1 h ∈ R を出力する.

鍵生成 D(sk , c) : ハミング重み t 以下のベクトル (e0 , e1 ) を復号する.

1. ch0 を計算する.
2. QC-MDPC 符号の復号アルゴリズムを用いて, ch0 をシンドロームとするベクトル (e0 , e1 ) を計算する.
• 鍵カプセル化方式の説明: 基本方式を決定性公開鍵暗号方式とみなす. 基本方式から, 平文 m と乱数 (e0 , e1 ) に対して (c0 = E(pk , (e0 , e1 )), c1 = m ⊕ L(e0 , e1 )) と暗号化を行う, IND-CPA 安全な乱択公開鍵暗号を構成す
る. 鍵カプセル化方式は, この乱択公開鍵暗号に FO̸⊥m 変換を適用したものとみなせる. 以下ではハッシュ関数

H, L : {0, 1}∗ → {0, 1}256 と G : {0, 1}∗ → SH (2n, t) を用いる.
鍵生成:

適切な長さのシード δ から乱数を生成し, 鍵生成を行う. （乱数の生成方法は省略する.）公開鍵は同じ

く h である. 復号鍵は (h0 , h1 ) に加えて, ` ビットの一様ランダムな文字列 s を用いる.
鍵カプセル化:

1. m ← {0, 1}256 を一様ランダムに選ぶ.

2. (e0 , e1 ) = G(m) を計算する.
3. c0 = e0 + e1 h と, c1 = m ⊕ L(e0 , e1 ) を計算する.
4. K = H(m, (c0 , c1 )) を計算する.
5. 暗号文を c とし, 鍵を K とする.
デカプセル:

1. 復号鍵 (h0 , h1 ) を用いて c0 を復号して, (e′0 , e′1 ) を得る.

2. 復号に失敗したら, ⊥ を出力して停止
3. m′ ← c1 ⊕ L(e′0 , e′1 ) を計算する.
4. (e′0 , e′1 ) = G(m′ ) ならば, K = H(m′ , (c0 , c1 )) を出力して停止

51

表 4.5: BIKE のパラメータ. 単位は全て octet とする.
パラメータ名

レベル

公開鍵長

秘密鍵長

暗号文長

BIKE-Level1

1

1 541

281

1 573

BIKE-Level3

3

3 083

419

3 115

BIKE-Level5

5

5 122

580

5 154

5. そうでなければ, K = H(s, (c0 , c1 )) を計算し, 出力する.
表 4.5 に鍵カプセル化方式の鍵長および暗号文長をまとめた. 3 つのパラメータセットがそれぞれレベル 1, 3, 5 相当として提案された.

4.3.3 暗号方式 3: HQC• 提案者: Aguilar Melchor, Aragon, Bettaieb, Bidoux, Blazy, Deneuville, Gaborit, Persichetti, Zémor, Bos,
Dion, Lacan, Robert, Veron.
• 基本方式の説明: 符号版の LPR/LP 暗号に基づき, 公開鍵暗号を構成している. R = F2 [X]/(X n − 1) とする.
n′ = n1 n2 とし, [n′ , k] 線形符号 C を採用する. 線形符号 C の符号化・復号アルゴリズムを encode, decode とする. n ≥ n′ を仮定する. 以下では, 暗号文の第二要素 v を R 要素 (n ビットベクトル) として扱っているが, 実
際には n′ ビットに縮めて用いる.
鍵生成:a ← R , x, y ← SH (n, w) とし, b = ax + y を計算する. 公開鍵を pk = (a, b) ∈ R2 とし, 秘密鍵を

sk = (x, y) とする.
暗号化 E(pk , m; s, e1 , e2 ) :c = (u, v) = (sa + e1 , sb + e2 + encode(m)) を出力する. ( s ← SH (n, wr ) ,e1 , e2 ← SH (n, we ) としている)
復号 D(sk , c):c = (u, v) に対して, decode(v − ux) を出力する.

• 鍵カプセル化方式: 基本方式を乱択な公開鍵暗号とみなし, HFO⊥ 変換を適用したものとみなせる. 以下ではハッシュ関数 H, H′ : {0, 1}∗ → {0, 1}256 を用いる. また, XOF *6 として HG : {0, 1}→ {0, 1}∗ も用いる.

(Round 4 で G への入力に seed と salt が追加された.)
鍵生成:

同上. ただし a の生成をシード seed から行うこととし, pk = (seed, b) を公開する. また, 秘密鍵にも

シード seed を加える.
鍵カプセル化:

1. m ← Fk2 を一様ランダムにとる.

2. salt ← F128
を一様ランダムにとる.
2
3. θ ← HG (m, seed, salt) を計算する. θ から s, e1 , e2 を生成する.
4. c = (u, v) = E(pk , m; s, e1 , e2 ) を計算する. d = H′ (m) とする. K = H(m, c) とする.
5. 暗号文 C = (c, d, salt), セッション鍵 K を出力する.
デカプセル:

1. m′ ← D(sk , c) を計算する.

2. θ′ = HG (m′ , seed, salt) を計算する. θ′ から s′ , e′1 , e′2 を生成する.
3. c 6= E(pk , m′ ; s′ , e′1 , e′2 ) or d 6= d′ ならば ⊥ を出力して停止する.

*6 eXtendable-Output Functions の略. SHAKE128 や SHAKE256 が例として知られている.

52

表 4.6: HQC のパラメータ. 単位は全て octet とする.
パラメータ名

レベル

公開鍵長

秘密鍵長

暗号文長

hqc-128

1

2 249

40

4 497

hqc-192

3

4 522

40

9 042

hqc-256

5

7 245

40

14 485

4. K = H(m, c) を出力する.
3 つのパラメータセットがそれぞれレベル 1, 3, 5 相当として提案された. 表 4.6 に鍵カプセル化方式の鍵長および暗号文長をまとめた. 表中では, 秘密鍵はシードだけ記憶していることにされており, 40 バイトしかない. また公開鍵の aの部分もシードから再生成されることと定義されている点に注意されたい.

4.4 まとめ基本となる McEliece 暗号方式は McEliece により 40 年以上前に提案されており, パラメータは改訂されているものの, いまだに破られていない. Classic McEliece などのように, 公開鍵や秘密鍵は長いものの, 暗号文は短い方式が多い.

LPN 問題は学習理論や符号理論から派生した問題であり, 誤り確率 τ が十分大きい場合の LPN 問題を確率的多項式時間で効率的に解くことは困難であると予想されている.
共通鍵や公開鍵の分野で多くの方式が LPN 問題に基づいて提案されている. LWE 問題と比較した場合, 利点としては,

• F2 およびその拡大体を基に構成するため, ハードウェア構成との相性が良い点• 誤差分布としてベルヌーイ分布やその一般化した分布を用いるため, 誤差のサンプリングが容易である点が挙げられる. 一方, 欠点として,• 鍵や暗号文のサイズが大きくなりやすい点• 符号の復号アルゴリズムが複雑になりがちな点• ID ベース暗号や完全準同型暗号といった発展的な応用が少ない点が挙げられる.
暗号方式のパラメータ設定の際には, 4.1 節で挙げたさまざまなアルゴリズムを考慮する必要がある. アルゴリズムの高速化について盛んに研究されており, 動向を注視する必要がある. また, 攻撃に用いられるアルゴリズムの研究は理論的なものが多く, 攻撃実験報告は小さいパラメータに対して行ったものが多い. そのため, 攻撃実験に関する研究もこれから非常に重要である.
公開鍵や秘密鍵を圧縮しようと特殊な符号を採用したり, 距離の定義を変える提案も多くある. これらは解読攻撃を受けることも多く, 枯れていない暗号・署名方式については注視が必要である.

53

第 4 章の参照文献[1] B. Applebaum, D. Cash, C. Peikert, A. Sahai. Fast cryptographic primitives and circular-secure
encryption based on hard learning problems. In S. Halevi, editor, Advances in Cryptology - CRYPTO
2009, 29th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 16-20,
2009. Proceedings, volume 5677 of Lecture Notes in Computer Science, pages 595–618. Springer,
2009.
[2] S. Arora and R. Ge. New algorithms for learning in presence of errors. In L. Aceto, M. Henzinger, andJ. Sgall, editors, Automata, Languages and Programming - 38th International Colloquium, ICALP
2011, Zurich, Switzerland, July 4-8, 2011, Proceedings, Part I, volume 6755 of Lecture Notes in
Computer Science, pages 403–415. Springer, 2011.
[3] M. Alekhnovich. More on average case vs approximation complexity. Computational Complexity,
20(4):755–786, 2011.
[4] É. Barelli and A. Couvreur. An eﬃcient structural attack on NIST submission DAGS. In Peyrin and
Galbraith [42], pages 93–118.
[5] A. Blum, M. L. Furst, M. J. Kearns, and R. J. Lipton. Cryptographic primitives based on hard learning
problems. In D. R. Stinson, editor, Advances in Cryptology - CRYPTO ’93, 13th Annual International
Cryptology Conference, Santa Barbara, California, USA, August 22-26, 1993, Proceedings, volume 773
of Lecture Notes in Computer Science, pages 278–291. Springer, 1993.
[6] A. Becker, A. Joux, A. May, and A. Meurer. Decoding random binary linear codes in 2n/20 : How
1 + 1 = 0 improves information set decoding. In D. Pointcheval and T. Johansson, editors, Advancesin Cryptology - EUROCRYPT 2012 - 31st Annual International Conference on the Theory and Applications of Cryptographic Techniques, Cambridge, UK, April 15-19, 2012. Proceedings, volume 7237
of Lecture Notes in Computer Science, pages 520–536. Springer, 2012.
[7] A. Blum, A. Kalai, and H. Wasserman. Noise-tolerant learning, the parity problem, and the statisticalquery model. J. ACM, 50(4):506–519, 2003.
[8] D. J. Bernstein and T. Lange. Never trust a bunny. In J.-H. Hoepman and I. Verbauwhede, editors,
Radio Frequency Identiﬁcation. Security and Privacy Issues - 8th International Workshop, RFIDSec
2012, Nijmegen, The Netherlands, July 2-3, 2012, Revised Selected Papers, volume 7739 of Lecture
Notes in Computer Science, pages 137–148. Springer, 2012.
[9] D. J. Bernstein, T. Lange, and C. Peters. Smaller decoding exponents: Ball-collision decoding. In
P. Rogaway, editor, Advances in Cryptology - CRYPTO 2011 - 31st Annual Cryptology Conference,
Santa Barbara, CA, USA, August 14-18, 2011. Proceedings, volume 6841 of Lecture Notes in Computer

54

Science, pages 743–760. Springer, 2011.
[10] L. Both and A. May. Optimizing BJMM with nearest neighbors: Full decoding in 22n/21 and McEliece
security. In WCC 2017, 2017. See http://wcc2017.suai.ru/proceedings.html.
[11] L. Both and A. May. Decoding linear codes with high error rate and its impact for LPN security. In
Lange and Steinwandt [34], pages 25–46.
[12] E. R. Berlekamp, R. J. McEliece, and H. C. A. van Tilborg. On the inherent intractability of certain
coding problems. IEEE Trans. Information Theory, 24(3):384–386, 1978.
[13] S. Bogos and S. Vaudenay. Optimization of LPN solving algorithms. In J.-H. Cheon and T. Takagi,
editors, Advances in Cryptology - ASIACRYPT 2016 - 22nd International Conference on the Theory and Application of Cryptology and Information Security, Hanoi, Vietnam, December 4-8, 2016,
Proceedings, Part I, volume 10031 of Lecture Notes in Computer Science, pages 703–728, 2016.
[14] N. Courtois, M. Finiasz, and N. Sendrier. How to achieve a McEliece-based digital signature scheme.
In C. Boyd, editor, Advances in Cryptology - ASIACRYPT 2001, 7th International Conference on
the Theory and Application of Cryptology and Information Security, Gold Coast, Australia, December
9-13, 2001, Proceedings, volume 2248 of Lecture Notes in Computer Science, pages 157–174. Springer,
2001.
[15] S. Devadas, L. Ren, and H. Xiao. On iterative collision search for LPN and subset sum. In Y. Kalai and
L. Reyzin, editors, Theory of Cryptography - 15th International Conference, TCC 2017, Baltimore,
MD, USA, November 12-15, 2017, Proceedings, Part II, volume 10678 of Lecture Notes in Computer
Science, pages 729–746. Springer, 2017.
[16] T. Debris-Alazard and J.-P. Tillich. Two attacks on rank metric code-based schemes: RankSign andan IBE scheme. In Peyrin and Galbraith [42], pages 62–92.
[17] 電子情報通信学会. 知識ベース 1 群 (信号・システム) 2 編(符号理論). https://ieice-hbkb.org/

portal/doc_608.html[18] A. Esser, F. Heuer, R. Kübler, A. May, and C. Sohler. Dissection-BKW. In H. Shacham and
A. Boldyreva, editors, Advances in Cryptology - CRYPTO 2018 - 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19-23, 2018, Proceedings, Part II, volume 10992
of Lecture Notes in Computer Science, pages 638–666. Springer, 2018.
[19] A. Esser, R. Kübler, and A. May. LPN decoded. In J. Katz and H. Shacham, editors, Advances in
Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference, Santa Barbara, CA,
USA, August 20-24, 2017, Proceedings, Part II, volume 10402 of Lecture Notes in Computer Science,
pages 486–514. Springer, 2017.
[20] A. Esser, A. May, and F. Zweydinger. McEliece needs a break – Solving McEliece-1284 and quasicyclic-2918 with modern ISD. In O. Dunkelman and S. Dziembowski, editors, Advances in Cryptology- EUROCRYPT 2022 - 41st Annual International Conference on the Theory and Applications of
Cryptographic Techniques, Trondheim, Norway, May 30 - June 3, 2022, Proceedings, Part III, volume13277 of Lecture Notes in Computer Science, pages 433–457. Springer, 2022.
[21] J.-C. Faugère, V. Gauthier-Umaña, A. Otmani, L. Perret, and J.-P. Tillich. A distinguisher forhigh rate McEliece cryptosystems. In 2011 IEEE Information Theory Workshop, ITW 2011, Paraty,
Brazil, October 16-20, 2011, pages 282–286. IEEE, 2011.
55

[22] J.-C. Faugère, V. Gauthier-Umaña, A. Otmani, L. Perret, and J.-P. Tillich. A distinguisher for
high-rate McEliece cryptosystems. IEEE Trans. Information Theory, 59(10):6830–6844, 2013.
[23] Q. Guo, T. Johansson, and C. Löndahl. Solving LPN using covering codes. In P. Sarkar and T. Iwata,
editors, Advances in Cryptology - ASIACRYPT 2014 - 20th International Conference on the Theory
and Application of Cryptology and Information Security, Kaoshiung, Taiwan, R.O.C., December 7-11,
2014. Proceedings, Part I, volume 8873 of Lecture Notes in Computer Science, pages 1–20. Springer,
2014.
[24] H. Gilbert, M. J. B. Robshaw, and Y. Seurin. HB# : Increasing the security and eﬃciency of HB+ .
In N. P. Smart, editor, Advances in Cryptology - EUROCRYPT 2008, 27th Annual International
Conference on the Theory and Applications of Cryptographic Techniques, Istanbul, Turkey, April 1317, 2008. Proceedings, volume 4965 of Lecture Notes in Computer Science, pages 361–378. Springer,
2008.
[25] J. Håstad. Some optimal inapproximability results. J. ACM, 48(4):798–859, 2001.
[26] S. Heyse, Eike Kiltz, Vadim Lyubashevsky, Christof Paar, and Krzysztof Pietrzak. Lapin: An eﬃcientauthentication protocol based on ring-LPN. In A. Canteaut, editor, Fast Software Encryption - 19thInternational Workshop, FSE 2012, Washington, DC, USA, March 19-21, 2012. Revised Selected
Papers, volume 7549 of Lecture Notes in Computer Science, pages 346–365. Springer, 2012.
[27] P. Kirchner. Improved generalized birthday attack. IACR Cryptology ePrint Archive, 2011:377, 2011.
[28] E. Kirshanova. Improved quantum information set decoding. In Lange and Steinwandt [34], pages
507–527.
[29] J. Katz, J. S. Shin, and A. D. Smith. Parallel and concurrent security of the HB and hb+ protocols.
J. Cryptology, 23(3):402–421, 2010.
[30] G. Kachigar and J.-P. Tillich. Quantum information set decoding algorithms. In T. Lange and T. Takagi, editors, Post-Quantum Cryptography - 8th International Workshop, PQCrypto 2017, Utrecht, The
Netherlands, June 26-28, 2017, Proceedings, volume 10346 of Lecture Notes in Computer Science,
pages 69–89. Springer, 2017.
[31] P. J. Lee and E. F. Brickell. An observation on the security of mceliece’s public-key cryptosystem.
In C. G. Günther, editor, Advances in Cryptology - EUROCRYPT ’88, Workshop on the Theory
and Application of of Cryptographic Techniques, Davos, Switzerland, May 25-27, 1988, Proceedings,
volume 330 of Lecture Notes in Computer Science, pages 275–280. Springer, 1988.
[32] Y. Li, R. H. Deng, and X. Wang. On the equivalence of McEliece’s and Niederreiter’s public-key
cryptosystems. IEEE Trans. Information Theory, 40(1):271–273, 1994.
[33] É. Levieil and P.-A. Fouque. An improved LPN algorithm. In R. De Prisco and M. Yung, editors,
Security and Cryptography for Networks, 5th International Conference, SCN 2006, Maiori, Italy,
September 6-8, 2006, Proceedings, volume 4116 of Lecture Notes in Computer Science, pages 348–
359. Springer, 2006.
[34] T. Lange and R. Steinwandt, editors. Post-Quantum Cryptography - 9th International Conference,
PQCrypto 2018, Fort Lauderdale, FL, USA, April 9-11, 2018, Proceedings, volume 10786 of Lecture
Notes in Computer Science. Springer, 2018.
[35] V. Lyubashevsky. The parity problem in the presence of noise, decoding random linear codes, and the56subset sum problem. In C. Chekuri, K. Jansen, J. D. P. Rolim, and L. Trevisan, editors, Approximation, Randomization and Combinatorial Optimization, Algorithms and Techniques, 8th International
Workshop on Approximation Algorithms for Combinatorial Optimization Problems, APPROX 2005
and 9th InternationalWorkshop on Randomization and Computation, RANDOM 2005, Berkeley, CA,
USA, August 22-24, 2005, Proceedings, volume 3624 of Lecture Notes in Computer Science, pages
378–389. Springer, 2005.
[36] R. J. McEliece. A public-key cryptosystem based on algebraic coding theory. Jet Propulsion Laboratory
DSN Progress Report, 42–44:114–116, January and February 1978. https://ipnpr.jpl.nasa.gov/
progress_report2/42-44/44N.PDF.
[37] A. May, A. Meurer, and E. Thomae. Decoding random linear codes in Õ(20.054n ). In D. H. Lee andX. Wang, editors, Advances in Cryptology - ASIACRYPT 2011 - 17th International Conference on
the Theory and Application of Cryptology and Information Security, Seoul, South Korea, December
4-8, 2011. Proceedings, volume 7073 of Lecture Notes in Computer Science, pages 107–124. Springer,
2011.
[38] A. May and I. Ozerov. On computing nearest neighbors with applications to decoding of binary linear
codes. In E. Oswald and M. Fischlin, editors, Advances in Cryptology - EUROCRYPT 2015 - 34th
Annual International Conference on the Theory and Applications of Cryptographic Techniques, Soﬁa,
Bulgaria, April 26-30, 2015, Proceedings, Part I, volume 9056 of Lecture Notes in Computer Science,
pages 203–228. Springer, 2015.
[39] S. Narisada, K. Fukushima, S. Kiyomoto. Multiparallel MMT : Faster ISD algorithm solving highdimensional syndrome decoding problem. IEICE TRANSACTIONS on Fundamentals of Electronics,
Communications and Computer Sciences, 2022. https://search.ieice.org/bin/summary_advpub.
php?id=2022CIP0023&category=A&lang=E&abst=
 i[40] H. Niederreiter. Knapsack-type cryptosystems and algebraic coding theory. Problemy Upravleniia
Teorii Informatsii, 15:19–34, 1986.
[41] R. Nojima, H. Imai, K. Kobara, and K. Morozov. Semantic security for the McEliece cryptosystem
without random oracles. Des. Codes Cryptography, 49(1-3):289–305, 2008.
[42] T. Peyrin and S. D. Galbraith, editors. Advances in Cryptology - ASIACRYPT 2018 - 24th International Conference on the Theory and Application of Cryptology and Information Security, Brisbane,
QLD, Australia, December 2-6, 2018, Proceedings, Part I, volume 11272 of Lecture Notes in Computer
Science. Springer, 2018.
[43] E. Prange. The use of information sets in decoding cyclic codes. IRE Trans. Information Theory,8(5):5–9, 1962.
[44] O. Regev. On lattices, learning with errors, random linear codes, and cryptography. J. ACM,
56(6):34:1–34:40, 2009. Preliminary version was presented at STOC 2005.
[45] J. Stern. A method for ﬁnding codewords of small weight. In G. D. Cohen and J. Wolfmann, editors,
Coding Theory and Applications, 3rd International Colloquium, Toulon, France, November 2-4, 1988,
Proceedings, volume 388 of Lecture Notes in Computer Science, pages 106–113. Springer, 1988.
[46] B. Zhang, L. Jiao, and M. Wang. Faster algorithms for solving LPN. In M. Fischlin and J.-S. Coron,
editors, Advances in Cryptology - EUROCRYPT 2016 - 35th Annual International Conference on the57

Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings,
Part I, volume 9665 of Lecture Notes in Computer Science, pages 168–195. Springer, 2016.
[47] D.J. Bernstein et al. Classic McEliece (Round 4 submission). https://csrc.nist.gov/projects/
post-quantum-cryptography/round-4-submissions[48] N. Aragon et al. BIKE (Round 4 submission). https://csrc.nist.gov/projects/post-quantumcryptography/round-4-submissions[49] C. Aguilar Melchor et al. HQC (Round 4 submission). https://csrc.nist.gov/projects/postquantum-cryptography/round-4-submissions

58

第5章

多変数多項式に基づく暗号技術
多変数公開鍵暗号*1 （Multivariate Public Key Cryptosystems）における暗号方式の特徴として，有限体上の多変数多項式を用いた連立方程式


 p1 (x1 , x2 , . . . , xn ) = 0,

 p2 (x1 , x2 , . . . , xn ) = 0,
..

.



pm (x1 , x2 , . . . , xn ) = 0の求解問題（MP 問題）を解く計算の困難性が安全性の根拠として必要なことが挙げられる．連立線形方程式は多項式時間で求解可能であるから，多変数公開鍵暗号に現れる MP 問題における多項式の最大次数は 2 次以上に限定できる．
本報告書では，多変数公開鍵暗号の多くの方式で採用されている双極型システムを中心に解説する．

5.1 多変数多項式に基づく暗号技術の安全性の根拠となる問題
Fq で位数 q の有限体を表し，x = (x1 , x2 , . . . , xn ) で（代数的に独立な）変数の集合を表すものとする．x に関する
Fq 上の多変数多項式の組，すなわち，多変数多項式 pi (x) (i = 1, . . . , m) により，P (x) = (p1 (x), p2 (x), . . . , pm (x))
と表されるものを（Fq 上の）多変数多項式系と呼ぶことにする．この多変数多項式系 P (x) は代入評価により，Fn
q か
m
n
ら Fm
q への写像を構成する．この（多変数多項式）写像を P : Fq → Fq と表すことにする．

5.1.1 MP 問題（MQ 問題）
MP 問題は次のように述べられる．
MP 問題 多変数多項式系 P (x) = (p1 (x), p2 (x), . . . , pm (x)) と d = (d1 , d2 , . . . , dm ) ∈ Fm
q に対して，変数 x に関する連立方程式p1 (x1 , x2 , . . . , xn ) = d1 ,
 p2 (x1 , x2 , . . . , xn ) = d2 ,
..

.



pm (x1 , x2 , . . . , xn ) = dmの解（が存在するなら）少なくとも 1 つ求めよ．
*1 かつては「多次多変数公開鍵暗号」と呼ばれていた．

59

(5.1)

連立方程式 (5.1) の右辺の各 di を左辺に移行して pi (x) に吸収させることができるので，右辺を 0 として MP 問題を表現する場合もある．MP 問題において，P (x) の全ての成分 pi (x) が 1 次以下となる場合，MP 問題は単に線形方程式を解く問題となり，ガウスの消去法などで m, n に関し多項式時間で求解することが可能である．よって，MP 問題
を考える場合は通常，各 pi (x) の次数は 2 以上であると仮定する．特に，pi (x) の次数が全て 2 となるとき，MP 問題
は MQ 問題と呼ばれる．Fq = F2 の場合，MQ 問題は NP 完全であることが知られている [19]．

MQ 問題を解くコンテストとして Fukuoka MQ challenge が知られている．扱われている MQ 問題は，有限体は
q = 2, 31, 256 の 3 種類と m, n に関しては m = 2n, n ≈ 1.5m の 2 種類の計 6 種類である．投稿され解かれた問題の(m, n) の値の最大は表 5.1 のようになっている．
表 5.1: Fukuoka MQ challenge で解かれた MQ 問題のパラメータの最大値（2022/9/31 時点）
タイプ

I

II

III

IV

V

VI

Fq

F2

F31

F256

F2

F31

F256

(m, n)

m = 2nm = 2nm = 2nn ≈ 1.5m

n ≈ 1.5m

n ≈ 1.5m(m, n) の最大(148, 74)

(74, 37)(76, 38)(69, 103)(19, 28)(20, 30)

5.1.2 MinRank 問題
に対し，x1 , . . . , xk ∈ Fq で，(x1 , . . . , xk ) 6= (0, . . . , 0) かつ
MinRank 問題 整数 r と行列 M1 , . . . , Mk ∈ Fm×n
q
k
X

Rank

!
x i Mi≤r

i=1なるものを求めよ．（Rank M は行列 M のランクを表す．）

MinRank 問題は HFEv- や Rainbow など様々な方式の安全性に関わっている．また，MinRank 問題を解く計算の困
難性をベースとした署名方式などがいくつか提案されている [9, 4, 28, 1]．MinRank 問題は MP 問題に帰着できることが知られている [23, 17, 2]．
例えば，Support minor modeling [2] では以下のように MinRank 問題が MP 問題に帰着される．x1 , . . . , xk が

MinRank 問題の解であるとするならば，(S, C) ∈ Fm×r
× Fr×n
で
q
q
SC =

k
X

x i Mi(5.2)

i=1なるものが存在する．rj をPk

i=1 xi Mi の第 j 行とすると，(5.2) より rj は C の行ベクトルが張る空間に属する．
(r+1)×n′
よって，行列 Cj ∈ Fq
を

Cj′ =

 
rj
C

で定めると，各 j = 1, . . . , m に対して，Rank Cj′ ≤ r を満たす．従って，Cj′ の任意の (r + 1) × (r + 1) 小行列の行列式= 0 という関係式が得られるが，このような関係式は j と小行列を動かすことにより m

60

n
r+1

!

個存在する．]T = r

なる T ⊂ {1, 2, . . . , n} に対して，T に属する列番号からなる C の r × r 小行列を CT と表し，さらにその行列式を cTと表すことにすると，Cj′ の任意の (r + 1) × (r + 1) 小行列の行列式は変数 x1 , . . . , xk と cT (T ⊂ {1, . . . , m}, ]T = r)を用いて多項式で表すことができる．これらの変数の個数は k +個の変数の m

n

!

r+1

n
r

!

である．つまり，MinRank 問題は k +

n

!

r

個の方程式からなる MP 問題に帰着される．

5.1.3 IP 問題，EIP 問題
IP（Isomorphism of Polynomials）問題は以下のように述べられる．
IP 問題 S, T をそれぞれ，Fnq , Fm
q 上のアフィン同型写像とする．多変数多項式系 P (x) = (p1 (x), p2 (x), . . . , pm (x))
に対し，多変数多項式系 P̃ (x) を合成により，P̃ (x) = T ◦ P (x) ◦ S で定める．このとき，P (x), P̃ (x) の情報
から S, T を求めよ．

IP 問題において，S や T の行列成分やベクトル成分をすべて独立な変数と見た場合，等式 P̃ (x) = T ◦ P (x) ◦ S は連立多項式方程式と見ることができる．すなわち，IP 問題は MP 問題に変換される．
多変数多項式系のクラス C を 1 つ固定する．ここで多変数多項式系のクラスとは多変数多項式系の集合 Fq [x]m の部分集合のことである．このとき，（クラス C に関する）EIP（Extended Isomorphism of Polynomials）問題は以下のように述べられる．

EIP 問題 多変数多項式系 P̃ (x) = (f1 (x), . . . , fm (x)) は，Fnq , Fm
q 上のアフィン同型写像 S, T とクラス C に属する
多変数多項式系 P (x) により，P̃ (x) = T ◦ P (x) ◦ S で表されるとする．このとき，分解 P̃ (x) = T ′ ◦ P ′ (x) ◦ S ′m′
で，S ′ , T ′ は Fn
q , Fq 上のアフィン同型写像，P (x) ∈ C なるものを見つけよ．

C = {P (x)} に関する EIP 問題が通常の IP 問題であるから，EIP 問題は IP 問題の拡張である．5.2 節で見るように，
EIP 問題は双極型システムで構成される暗号方式，署名方式の鍵復元攻撃に対する安全性に関わる．EIP 問題を解く
方法はクラス C の取り方（あるいは方式）に依存する．

5.2 代表的な多変数多項式に基づく暗号方式の説明
5.2.1 双極型システム
IP 問題ベース [24] や MinRank 問題ベース [9, 1, 4, 28] の方式も存在するが，多変数公開鍵暗号の多くの方式が MP
問題をベースとして構成されている．中でも双極型システム [10] と呼ばれる構成方法が多く利用されているため，この構成方法について説明する．（1 次多項式で構成されてなくても）多変数多項式系 P (x) によっては，多くの d ∈ Fmqに対して MP 問題が効率的に計算できる場合がある．例えば，n = m とし，P (x) = (p1 (x), p2 (x), . . . , pm (x)) が三61

角型多変数多項式系である，すなわち，p1 (x) = x1 ,
p2 (x) = x2 + g2 (x1 )(g2 (x1 ) ∈ Fq [x1 ]),p3 (x) = x3 + g3 (x1 , x2 )(g2 (x1 , x2 ) ∈ Fq [x1 , x2 ]),..
.
pm (x) = xm + gm (x1 , . . . , xm−1 ) (gm (x1 , . . . , xm−1 ) ∈ Fq [x1 , . . . , xm−1 ])の形で表されるとすると，任意の d ∈ Fm
q に対して P (x) = d の（唯 1 つの）解が，x1 から逐次的に求められることが分かる．このことはすなわち，多変数多項式系のクラス C を三角型多変数多項式系の全体で定めると，任意の P ∈ C
に対して，P (x) = d (d ∈ Fmq ) の解が効率的に計算可能ということである．
双極型システムでは，まず，上の例のような MP 問題が効率的に計算できる多変数多項式系のクラス Ccent を見つけ固定する．G(x) ∈ Ccent と Fqn , Fqm 上のアフィン同型写像 S, T をそれぞれ任意にとり，これらを合成した多変数多項式系 F (x) = T ◦ G(x) ◦ S をトラップドア付き一方向関数として利用するのが，双極型システムのアイデアである．ただし，F (x) が実際にトラップドア付き一方向関数となるかどうかは Ccent のとり方に依存する．
双極型システムの鍵生成は次のように行う．
鍵生成

1. G(x) ∈ Ccent をランダムに選ぶ．
2. Fnq , Fm
q 上のアフィン同型写像 S, T をランダムに選ぶ．
3. F (x) = T ◦ G(x) ◦ S とする．
このとき，公開鍵は F (x)，秘密鍵は G(x), S, T となる．F (x) はその係数集合が公開鍵として保管される．また，G(x) を（この方式の）中心写像とよぶ．中心写像のクラス Ccent は公開鍵長（や秘密鍵長）を出来るだけ小さくする
ために 2 次の多変数多項式系の部分集合で選ぶことが多い．双極型システムは暗号方式，署名方式両方の構成に用いることができる．
暗号方式の暗号化・復号は次のように行う．
暗号化 平文 M ∈ Fn
q に対し，C = F (M ) を計算する．C が暗号文となる．
復号−1(C), (2) G(B2 ) = B1 なる B2 を計算, (3) M ′ = S −1 (B2 ) の順に計算
暗号文 C ∈ Fm
q に対し，(1) B1 = T

する．M ′ が平文と一致する．
復号が成功するためには， G(x) （あるいは F (x)）が単射である必要がある．単射の条件を少し緩めて，「G(x) （あるいは F (x)）の逆像の個数が十分少ない」とすることもできる．この場合，M ′ が複数得られることになるので，ハッシュ値などを用いて平文 M と一致する M ′ を特定する．
双極型システムの署名方式の署名生成・検証は次のように行う．
署名生成−1
メッセージ M ∈ Fm
(M ), (2) G(B2 ) = B1 なる B2 を計算, (3) σ = S −1 (B2 ) のq に対し，(1) B1 = T

順に計算する．σ が署名となる．
検証′′
署名 σ ∈ Fn
q に対し，M = F (σ) を計算する．M = M ならば署名を受理，それ以外は棄却する．

−1
署名生成がいつでも実行できるためには，どのようなメッセージ M ∈ Fm
(B1 ) の計算ができq に対しても，B2 = Gる，すなわち，G(x) （あるいは F (x)）が全射である必要がある．
双極型システムでは，中心写像のクラス Ccent の取り方を変えることで幅広い方式の構成が可能である．例えば，

62

Ccent = { 三角型多変数多項式系 } とすると暗号方式が得られる．双極型システムにおいて，Ccent に関する EIP問題がその安全性に大きく関わってくる．実際，EIP 問題を解けた場合，F (x) = T ◦ G(x) ◦ S の代わりに分解

F (x) = T ′ ◦ G′ (x) ◦ S ′ を用いても，暗号方式における復号および，署名方式における署名生成（偽造）が実行可能となる．EIP 問題はクラス C の選び方に依存するので， C の選び方に応じて個々に解析される必要がある．例えば，Ccent = { 三角型多変数多項式系 } としたときの EIP 問題は効率的に解けることが知られている [20]．
双極型システムの代表的な構成法として，simple ﬁeld 法と big ﬁeld 法がある．Simple ﬁeld 方式は中心写像の構成に Fq 以外の有限体を利用しない．Big ﬁeld 方式は中心写像の構成に Fq の n 次拡大体 Fqn を利用する．Big ﬁeld 方
式は中心写像を構成しやすいが，Gröbner 基底攻撃が効果的となる場合が多いという性質を持つ．以下では，big ﬁeld
方式の代表として署名方式 HFE および HFEv-，simple ﬁeld 方式の代表として署名方式 Rainbow について説明する．

5.2.2 HFE 方式，HFEv-方式
5.2.2.1 暗号方式 HFE∼

K = Fqn を Fq の n 次拡大体とし，Fq -線形同型写像 φ : Fqn −→ K を 1 つ固定する．D を正の整数として，K 上の 1 変数多項式

G(X) =jq i +qX≤Dαi,j X0≤i≤jq i +q j

+

i
qX
≤D

i

βi X q + γ(αi,j , βi , γ ∈ K)

0≤iをとる．G(X) の形の 1 変数多項式は HFE 多項式と呼ばれる．このとき，多変数多項式写像 G : Fqn → Fqn を

G = φ−1 ◦ G ◦ φ と定めると，対応する多変数多項式系 G(x) の成分は全て 2 次多項式となる．d ∈ Fnq に対して，
G(x) = d が解を持つならば，この解は全て効率的に計算することができる．実際，次の手順で計算できる．
1. B = φ(d) ∈ K を計算する．
2. A = G −1 (B) を Cantor-Zassenhaus アルゴリズムなどの因数分解アルゴリズムを用いて計算する．
3. φ−1 (A) を計算する．
但し，2 の計算が効率的に実行できるためには D をある程度小さくとる必要がある．上記のことを踏まえると，

αi,j , βi , γ ∈ K を動かしてできる G(x) のなすクラス CHFE に対し，Ccent = CHFE の双極型システムは暗号方式を構成する．この暗号方式を HFE [24] と呼ぶ．HFE 自体は 1999 年，Kipnis と Shamir により効果的な攻撃が発見されている [23]．その後，HFE から派生した亜種方式がいくつか提案されており，以下の HFEv- もその１つである．

5.2.2.2 署名方式 HFEvHFEv- [24] は，暗号方式 HFE を署名方式に応用したものである．HFE と同様に Fq の n 次拡大体 K = Fqn をとり，Fq -線形同型写像 φ : Fqn → K を固定する．正の整数 a (a < n) と v を固定する．まず，G(X) は次のように変更される．

G(X) =jq i +qX≤D0≤i≤jαi,j X

q i +q j

+

i
qX
≤D

i

βi (xn+1 , . . . , xn+v )X q + γ(xn+1 , . . . , xn+v )(αi,j ∈ K).

(5.3)

0≤i

ここで，βi (xn+1 , . . . , xn+v ), γ(xn+1 , . . . , xn+v ) は共に Fqv から K への多項式写像であり，βi (xn+1 , . . . , xn+v ) は線形関数，γ(xn+1 , . . . , xn+v ) は 2 次関数である．多変数多項式系 G(x) は，多変数多項式写像 G = φ−1 ◦ G ◦ (φ × idv ) :Fqn+v → Fqn により定める．αi,j ∈ K と βi (xn+1 , . . . , xn+v ), γ(xn+1 , . . . , xn+v ) を動かしてできる G(x) のなすク63

ラスを CHFEv- と定める．基本的には，これを Ccent = CHFEv- として構成される双極型システムを考えるのであるが，双極型システムを若干変更する．S は Fqn+v 上のアフィン同型写像のままでよいが，T は Fqn から Fqn−a への最大ラ
ンクのアフィン写像と変更する．公開鍵は通常の双極型システムと同じように，F (x) = T ◦ G(x) ◦ S と定める．よって，F は Fqn+v から Fqn−a への多変数多項式写像となる．メッセージ M ∈ Fqn−a に対する署名 σ = F −1 (M ) は以下のよう計算される．

1. c = T −1 (M ) ∈ Fqn （の 1 つ）を計算する．
2. B = φ(c) ∈ K を計算する．
3. B ′ ∈ Fqv をランダムに選び， A = G −1 (BkB ′ ) を Cantor-Zassenhaus アルゴリズムなどを用いて計算する．
G −1 (BkB ′ ) が存在しない場合は，B ′ の選択からやり直す．
4. e = φ−1 (A) を計算する．
5. σ = S −1 (e) を計算する．
HFEv- と同じ構造を持つ署名方式 GeMSS は NIST PQC 標準化の第 3 round の候補に選ばれたが，[30] で効率的攻撃法が提案されたため，第 4 round に進むことはできなかった．

5.2.3 署名方式 Rainbow
署名方式 Rainbow [12] は，双極型システムを用いており，署名方式 UOV [21] を多層化した構造を持っている．

UOV の詳細については，5.3.1 節で説明する．
正の整数 t, v1 , o1 , . . . , ot に対し，vi+1 = vi + oi により，v2 , . . . , vt+1 を順次定める．また，i = 1, . . . , t に対し，Si = {1, . . . , vi }, Oi = {vi + 1, . . . , vi+1 } とおく．Si の個数は vi で，Oi の個数は oi である．変数の個数を

n = vt+1 ，式数を m = n − v1 とする多変数多項式系 G(x) = (gv1 +1 (x), . . . , gn (x)) を次の形で与える：
gk (x1 , . . . , xn ) =X(k)αi,j xi xj +i∈Oh ,j∈ShX(k)βi,j xi xj +X

(k)γi xi + η (k) (k = v1 +1, . . . , n).

i∈Sh+1i,j∈Sh , i≤j

(k)

(k)

(k)

但し，h は k が属する層番号，すなわち，“k ∈ Oh ” で定まる整数 1 ≤ h ≤ t である．αi,j , βi,j , γi , η (k) ∈ Fq を動かしてできる G(x) のなすクラスを CRainbow と定め，これを Rainbow の中心写像のクラスとする．
署名生成−1
1. メッセージ M ∈ Fm(M) とする.
q に対し，c = (cv1 +1 , . . . , cn ) ← T

2. b1 , . . . , bv1 ∈ Fq をランダムにとる．
3. h = 1, 2, . . . , t に対し，以下を実行：
gvh +1 (x), . . . , gvh+1 (x) に x1 = b1 , . . . , xvh = bvh を代入し，xvh +1 , . . . , xvh+1 に関する 1 次の多項式系ḡvh +1 (xvh +1 , . . . , xvh+1 ), . . . , ḡvh+1 (xvh +1 , . . . , xvh+1 ) を得る．1 次方程式

 ḡvh +1 (xvh +1 , . . . , xvh+1 ) = cvh +1..
.
ḡvh+1 (xvh +1 , . . . , xvh+1 ) = cvh+1の解を計算し，それを bvh +1 , . . . , bvh+1 と置く．もし解がなければ 2 に戻る．

4. b ← (b1 , . . . , bn ).
5. σ ← S −1 (b). （σ が署名となる．）

64

Rainbow は NIST PQC 標準化の第 3 round の候補に選ばれたが，Rainbow の EIP 問題を解くことにより，小さなサイズの UOV への攻撃に帰着する攻撃が提案され [5, 7]，その結果，レベル 1, 3, 5 として提案されていたパラメー
タがその安全性レベルに到達しないことになり（安全性レベル 143 bits が 69 bits に，207 bits が 157 bits に，272

bits が 206 bits に下がった），第 4 round に進むことはできなかった．

5.3 多変数多項式に基づく主要な暗号方式
MPKC で標準化が期待されるのは署名方式の UOV である．5.2.3 節で述べたように Rainbow は UOV を多層化したものであるが，その多層化が結果として暗号の強度を弱めることになった [5, 7]．しかし，多層化していない UOVは高い安全性を維持している．また，NIST の PQC の新たな署名方式の公募 [29] では，短い署名と効率的な検証を持
つ方式を望んでおり，UOV はその性質を持つため標準化が期待される．
表 5.2: 多変数多項式に基づく暗号の分類
文献

暗号化

鍵交換

署名
○

UOV [21]5.3.1 署名方式 UOV
5.3.1.1

UOV の概要

UOV [21] は，双極型システムを用いた署名方式であり，署名長が短く，検証が速いという長所を持つ．署名生成では，線形連立方程式の求解を利用しており，2 次以上の連立方程式の求解は必要としない．UOV の亜種方式として，

QR-UOV [18] や MAYO [6] が提案されている．
v, o を正の整数とし，m = o, n = v + o とする．2 次多項式からなる多変数多項式系 G(x) = (g1 (x), . . . , gm (x))
を次の形で与える．

gk (x) =X(k)αi,j xi xj +1≤i≤v
v+1≤j≤n
(k)

(k)

X

(k)

βi,j xi xj +1≤i≤j≤vX(k)γi xi + η (k) (k = 1, . . . , m).

1≤i≤n

(k)

ここで，αi,j , βi,j , γi , η (k) ∈ Fq である．G(x) は逆写像を効率的に計算することができる．具体的には，任意のc = ci ) ∈ Fqm に対し，b = G−1 (c)（の一つ）が以下のように計算できる．
1. b1 , . . . , bv ∈ Fq をランダムにとる．
2. g1 (x), . . . , gm (x) に x1 = b1 , . . . , xv = bv を代入し，xv+1 , . . . , xn に関する 1 次の多項式系 ḡ1 (xv+1 , . . . , xn ),. . . , ḡm (xv+1 , . . . , xn ) を得る．1 次方程式

 ḡ1 (xv+1 , . . . , xn ) = c1..
.
ḡm (xv+1 , . . . , xn ) = cmの解を計算し，それを bv+1 , . . . , bn と置く．もし解がなければ 1 に戻る．

3. b = (b1 , . . . , bn ).

65

(k)

(k)

(k)

αi,j , βi,j , γi , η (k) ∈ Fq を動かしてできる G(x) の集合を CUOV としたとき，Ccent = CUOV として構成される双極型システムの署名方式を UOV と呼ぶ．但し，アフィン同型写像 T は UOV の安全性には貢献しないので，通常は T
は恒等写像で選ぶ．H : {0, 1}∗ → Fm
q を暗号学的ハッシュ関数とする．
鍵生成

1. G(x) ∈ CUOV をランダムに選ぶ．
2. Fnq , Fm
q 上のアフィン同型写像 S をランダムに選ぶ．
3. S −1 を計算する．
4. F (x) = G(x) ◦ S.
公開鍵は F (x)，秘密鍵は G(x), S −1 である．次に，署名生成である．メッセージを M ∈ {0, 1}∗ とする．
署名生成

1. c = (cv+1 , . . . , cn ) ← H(M ).
2. b1 , . . . , bv ∈ Fq をランダムにとる．
3. g1 (x), . . . , gm (x) に x1 = b1 , . . . , xv = bv を代入し，xv+1 , . . . , xn に関する 1 次の多項式系 ḡ1 (xv+1 , . . . , xn ),. . . , ḡm (xv+1 , . . . , xn ) を得る．1 次方程式

 ḡ1 (xv+1 , . . . , xn ) = c1..
.
ḡm (xv+1 , . . . , xn ) = cmの解を計算し，それを bv+1 , . . . , bn と置く．もし解がなければ 3 に戻る．

4. b ← (b1 , . . . , bn ).
5. σ ← S −1 (b).
σ が署名となる．最後に検証である．
検証

1. h ← H(M ).
2. h′ ← F (σ).
3. h = h′ の真偽を返す．
検証者は，h = h′ のとき，署名を受理し，それ以外は棄却する．

5.3.1.2

UOV のパラメータ選択

UOV の設計に必要なパラメータは，有限体の位数 q ，方程式数 m, 変数の個数 n である．PQC Forum [27] では，
以下のように UOV のパラメータ見積もりが公開されている．

(q, m, n)

安全性レベル

公開鍵サイズ

秘密鍵サイズ

署名サイズ(16, 64, 160)

レベル 1

3, 297, 280 Bytes

412, 160 Bytes

640 bits(256, 44, 112)

レベル 1

2, 227, 456 Bytes

278, 432 Bytes

896 bits(256, 72, 184)

レベル 3

9, 803, 520 Bytes

1, 225, 440 Bytes

1472 bits(256, 96, 244)

レベル 5

22, 955, 520 Bytes

2, 869, 440 Bytes

1952 bits

66

5.4 多変数多項式に基づく暗号技術に関するまとめ
多変数公開鍵暗号は位数が小さな有限体上の多項式を利用しており，暗号化や検証が効率的に実行できる．また，署名方式 UOV に代表されるように署名長を短く抑えることができる．双極型システムでは公開鍵（や秘密鍵）が多変数
多項式写像の係数集合となるため，鍵長が大きくなりやすいことが課題である．また，署名方式に比べ，暗号方式の構成が難しいことや高機能暗号への応用が少ないことも課題である．
署名方式 Rainbow は NIST PQC 標準化の第 4 round には進めなかったが，致命的な攻撃が報告されているわけではないので今後も安全な方式として期待される．Big ﬁeld 方式を用いて構成される暗号方式は現時点では有力なものはないが，定期的に big ﬁeld 方式を用いた暗号方式は提案されているので，今後の新たな方式の出現が期待できる．本稿では MQ 問題ベースの双極型システムのみを説明したが，まだ数は少ないが IP 問題ベースや MinRank 問題ベースの方式も存在する．近年，MinRank 問題の解析が進歩しているため，MinRank 問題ベースの新たな方式の出現も今後，期待できる．

67

第 5 章の参照文献[1] G. Adj, L. Rivera-Zamarripa, J. A. Verbel. MinRank in the Head: Short Signatures from Zero-Knowledge
Proofs. IACR Cryptol. ePrint Arch. 2022: 1501, 2022.
[2] M. Bardet, M. Bros, D. Cabarcas, P. Gaborit, R. A. Perlner, D. Smith-Tone, J.-P. Tillich, J. A. Verbel.
Improvements of algebraic attacks for solving the rank decoding and minrank problems. ASIACRYPT’20,
Springer LNCS vol. 12491, pp. 507–536. 2020.
[3] M. Bardet, J.-C. Faugère, B. Salvy, B.-Y. Yang. Asymptotic expansion of the degree of regularity forsemi-regular systems of equations. In Eﬀective Methods in Algebraic Geometry (MEGA), pp. 71–74, 2004.
[4] E. Bellini, A. Esser, C. Sanna, J. Verbel. MR-DSS - smaller MinRank-based (ring-)signatures. Cryptology
ePrint Archive, Paper 2022/973, 2022.
[5] W. Beullens. Improved cryptanalysis of UOV and Rainbow. Cryptology ePrint Archive, Paper 2020/1343,
2020.
[6] W. Beullens. MAYO: Practical Post-Quantum Signatures from Oil-and-Vinegar Maps. Cryptology eprint
Archive, Paper 2021/1144, 2021.
[7] W. Beullens. Breaking Rainbow Takes a Weekend on a Laptop. Crypto’22, Springer LNCS vol. 13508, pp.
464–479, 2022.
[8] A. Caminata, E. Gorla. Soving degree, last fall degree, and related invariants. Journal of Symbolic Computation, vol. 114, pp. 322–335, 2023.
[9] N. T. Courtois. Eﬃcient Zero-Knowledge Authentication Based on a Linear Algebra Problem MinRank.
ASIACRYPT’01, Springer LNCS vol. 2248, pp. 402–421, 2001.
[10] J. Ding, J. E. Gower, D. S. Schmidt. Multivariate Public Key Cryptosystems. Advances in Information
Security 25, Springer, 2006.
[11] J. Ding and T. J. Hodges. Inverting HFE Systems Is Quasi-Polynomial for All Fields. CRYPTO’11, Springer
LNCS vol. 6841, pp. 724–742, 2011.
[12] J. Ding and D. Schmidt. Rainbow, a New Multivariable Polynomial Signature Scheme. ACNS’05 Springer
LNCS vol. 3531, pp. 164–175, 2005.
[13] J. Ding, B.-Y. Yang, C.-H. O. Chen, M.-S. Chen, C. M. Cheng. New Diﬀerential-Algebraic Attacks andReparametrization of Rainbow. ACNS’08, Springer LNCS vol. 5037, pp. 242–257, 2008.
[14] V. Dubois and N. Gama. The Degree of Regularity of HFE Systems. ASIACRYPT’10, Springer LNCS vol.
6477, pp. 557–576, 2010.
[15] J.-C. Faugère. A new eﬃcient algorithm for computing Gröbner bases (F4). J. Pure Appl. Algebra, vol. 139
pp. 61–88, 1999.

68

[16] J.-C. Faugère. A new eﬃcient algorithm for computing Gröbner bases without reduction to zero (F5).
Proceedings of ISSAC’02, pp. 75–83, ACM Press, 2002.
[17] J.-C. Faugère, M. S. El Din, P.-J. Spaenlehauer. Computing loci of rank defects of linear matrices usinggröbner bases and applications to cryptology. In ISSAC’10, Proceedings, pp. 257–264, ACM, 2010.
[18] H. Furue, Y. Ikematsu, Y. Kiyomura, and T. Takagi. A New Variant of Unbalanced Oil and Vinegar Using
Quotient Ring: QR-UOV. ASIACRYPT’21, Springer LNCS vol. 13093, pp. 187–217, 2021.
[19] M. R. Garay and D. S. Johnson. A Guide to the Theory of NP-Completeness. In Computers and Intractability,
W.H.Freeman, 1979.
[20] L. Goubin and N.T. Courtois. Cryptanalysis of the TTM Cryptsystem. ASIACRYPT’00, Springer LNCS
vol. 1976, pp. 44–57, 2000.
[21] A. Kipnis, L. Patarin, L. Goubin. Unbalanced Oil and Vinegar Schemes. EUROCRYPT’99, Springer LNCS
vol. 1592, pp. 206–222, 1999.
[22] A. Kipnis, and A. Shamir. Cryptanalysis of the Oil and Vinegar Signature Scheme. CRYPTO’98, Springer
LNCS vol. 1462, pp. 257–266, 1998.
[23] A. Kipnis, and A. Shamir.

Cryptanalysis of the HFE Public Key Cryptosystem by Relinearization.

CRYPTO’99, Springer LNCS, vol. 1666, pp. 19–33, 1999.
[24] J. Patarin. Hidden Fields Equations (HFE) and Isomorphisms of Polynomials (IP): Two New Families ofAsymmetric Algorithms. EUROCRYPTO’96, Springer LNCS vol. 1070, pp. 33–48, 1996.
[25] J. Patarin. The Oil and Vineger Signature Scheme. Dagstuhl Workshop on Cryptography, 1997.
[26] A. Petzoldt, M.-S. Chen, B.-Y. Yang, C. Tao, J. Ding. Design principles for HFEv-based multivariate
signature schemes. ASIACRYPT’15, Springer LNCS vol. 9742 , pp. 311–334, 2015.
[27] PQC Forum,

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/B1RFy31rH8I/m/km5Ow_

GmAgAJ.
[28] B. Santoso, Y. Ikematsu, S. Nakamura, T. Yasuda. Three-Pass Identiﬁcation Scheme Based on MinRank
Problem with Half Cheating Probability. CoRR abs/2205.03255, 2022.
[29] NIST, ”Standardization of Additional Digital Signature Schemes, Call for Proposals”, https://csrc.nist.
gov/csrc/media/Projects/pqc-dig-sig/documents/call-for-proposals-dig-sig-sept-2022.pdf[30] C. Tao, A. Petzoldt, J. Ding. Eﬃcient Key Recovery for all HFE Signature Variants. CRYPTO’21, Springer
LNCS vol. 12825, pp. 70–93, 2021.
[31] C. Wolf. Taxonomy of public key schemes based on the problem of Multivariate Quadratic equations.
Cryptology ePrint Archive, Paper 2005/077, 2005.
[32] B.-Y. Yang and J.-M. Chen. All in the XL Family: Theory and Practice. ICISC’04, Springer LNCS vol.
3506, pp. 67–86, 2005.

69

第6章

同種写像に基づく暗号技術
本章では同種写像に基づく暗号技術についてまとめる. 同種写像に基づく暗号技術の安全性は, 同種写像問題を解く
計算の困難性及び（それと同値な）自己準同型環計算問題の困難性に依存している.

6.1 節では, 安全性の根拠となる問題として, 同種写像問題の一般形を述べた後，最近発見された SIDH (Supersingular
Isogeny Diﬃe–Hellman) 同種写像問題 [10] に対する解法 [3, 27, 30] が適用できない計算問題として，自己準同型環計算問題及び SQISign（Short Quaternion and Isogeny Signature）署名方式 [15] の安全性に関する計算問題の概要を記述していく. SIDH 同種写像問題に対する解法に関しては調査報告書を参照のこと．6.2 節では, 代表的な暗号方式として, 自己準同型環計算問題に基づく GPS (Galbraith–Petit–Silva) 署名 [18] を取り上げる. 6.3 節では, 主要な暗号方式として，GPS 署名を改良した SQISign 署名方式を解説する.
本章では, 超特異楕円曲線を用いた暗号技術しか扱わない．しかし，通常楕円曲線に基づく CRS (Couveignes–

Rostovtsev–Stolbunov) 鍵共有法 [9, 31] を改良した De Feo ら [14] の方式は, それ自体は実用的な性能にはまだ遠いが, 調査報告書に記載されている CSIDH 鍵共有の原型を与えているという点で重要である.
同種写像の数学的詳細については, De Feo の概説記事 [13] や Washington の楕円曲線の教科書 [35] を，四元数環については Voight の教科書 [34] を参照のこと. また, Galbraith–Vercauteren による同種写像関連問題のサーベイ [19]も参照する.
■記法

x ←R X は, x を集合 X から一様ランダムにサンプリングすることを表す. 以下では, 有限体上に定義された楕円曲線のみを扱い, 同種写像暗号では, 多くの場合, モンゴメリ型の楕円曲線定義式 Ea,b : by 2 = x3 + ax2 + x が用いられる. 標数 p の有限体 F 上定義された楕円曲線 E に対し, OE は E の無限遠点であり, F の拡大体 K に対して, K有理点群は E(K) := {(x, y) ∈ K2 | (x, y) は E の定義式を満たす } ∪ {OE } で与えられる. また, E の r-ねじれ部分群
は E[r] := {P ∈ E(Fp ) | rP = OE } で与えられる.

6.1 同種写像に基づく暗号技術の安全性の根拠となる問題
同種写像問題の一般形を述べた後，自己準同型環計算問題と SQISign 署名方式の安全性に関する計算問題の概要及びそれら問題に対する解析状況について記述していく.

6.1.1 同種写像問題の一般形
同種写像とは, 2 つの楕円曲線 E, E ′ の間の写像 ϕ であり, E の座標 (x, y) の有理式で与えられると共に, 楕円曲線の加法構造に関する準同型性, 即ち ϕ(P + Q) = ϕ(P ) + ϕ(Q), を有する非零写像である. (その正確な定義は, 前掲の70

各文献を参照のこと.) また, E, E ′ の間に, 同種写像 ϕ が存在する時に, E と E ′ は同種であるという.
同種写像 ϕ は, その核 C = ker(ϕ) によって決まるので, ϕ の定義域曲線（始点曲線）E に対して ϕ の値域となる楕円曲線を E/C と書き表す, すなわち, ϕ : E → E/C. 核 C = ker(ϕ) の位数がセキュリティパラメータ λ の多項式サイズであれば, C = ker(ϕ) となる ϕ を効率的に計算するアルゴリズムが Vélu によって与えられている [33]. (モンゴメリ型楕円曲線に対する Vélu の公式に関しては, [29] を参照のこと.) 特に核の位数 #C が小素数になる同種写像を同種写像基本演算として，それらの合成が同種写像暗号での基本的な暗号演算を与えることになる．そして, その合成における基本演算の組み合わせ方法が, 秘密鍵情報を与える.
つまり, 同種な楕円曲線の間の同種写像を計算することを要求する次の同種写像問題が, 具体的な暗号方式の安全性を根拠づける次節以降の諸問題の基本形となる．（超特異同種写像問題と自己準同型環計算問題との計算量的同値性に関しては 6.1.2 節で触れる．）
定義 6.1 (一般形同種写像問題 [19]) 2 つの同種な楕円曲線 E, E ′ に対して, 同種写像 ϕ を計算せよ. (ϕ のコンパクトな表現を与えよ.)ここで, 「ϕ のコンパクトな表現」とは, 様々な表現方法が考えられる．例えば, deg(ϕ) が小素数 `i によって

Q

ei
i `i

となっている場合には, この分解に沿って ϕ を分解した各 `i 次同種写像の像に現れる値域楕円曲線 (又は j 不変量) の列挙で与えることができる.
定義 6.1 において, ϕ の次数が多項式サイズであれば, 上記問題は簡単に解けるので, ϕ の次数は通常は指数サイズのものを考える. また, Galbraith ら [19] は, j 不変量を使って, 上記問題を定式化しているが, CSIDH 鍵共有では, Fp 有理な楕円曲線のみを対象とするので, Fp -同型であるが Fp -同型でないツイスト曲線を判別して扱う必要性が生じるた
め, 上ではあえて, より素朴な形を採用して, 2 つの同種な楕円曲線 E, E ′ を使って同種写像問題を提示した.
同種写像問題の初期の考察には, 自己準同型環計算を扱った Kohel の博士論文 [22] や Galbraith による同種写像問
題に関する研究 [17] 及び Couveignes と Rostovtsev–Stolbunov による初期の暗号応用への提案 [9, 31] がある. その後, Charles らによる同種写像に基づいたハッシュ関数の提案 [4] は, 同種写像一方向性関数を一方向性の観点からだけでなく, 衝突困難性の観点からも見直すことになり, 初期の同種写像暗号の研究では重要な役割を果たした. 特に, 同種写像グラフがエクスパンダーグラフであることに着目して暗号に応用した意義は大きい.
■超特異同種写像問題と通常同種写像問題

標数 p の有限体上の楕円曲線 E の p-ねじれ部分群 E[p] が, E[p] = {OE }の時, E を超特異楕円曲線といい, そうでない時, E を通常楕円曲線という. 超特異楕円曲線の j 不変量は, Fp2 の要素である. つまり, 超特異 j 不変量の個数は, 有限個であり, 具体的に p/12 +  (但し  ∈ {0, 1, 2}) で与えられる. 超特異,
通常という楕円曲線の性質は, 同種写像によって保存されるため, 同種写像問題も, この 2 つの性質によって, 超特異同種写像問題と通常同種写像問題という 2 つの問題に分類される.
■超特異同種写像問題の計算困難性

超特異同種写像問題の計算困難性を評価することは重要である．また，自己準同型環計算問題との関係性については 6.1.2 節を参照のこと．

√√

超特異同種写像問題の古典計算機による解読時間は Õ( p)，量子計算機による解読時間は Õ( 4 p) と見積もられて√いる．古典解読アルゴリズムは Galbraith [17] による中間一致攻撃で, 解読時間は Õ( p) であり，量子解読アルゴリ√

ズムは Biasse ら [1] によって時間計算量が Õ( 4 p) の量子アルゴリズムが知られている. これは, Fp 上の超特異楕円曲√線の同種写像問題に対する準指数時間量子アルゴリズム [5] と Grover アルゴリズムに基づく Õ( 4 p) の道探索アルゴ
リズムを結合したものである.
また，Costello ら [7], Longa ら [26] による報告，Udovenko–Vitto [32] による$IKEp182 Challenge [6] 解読報告，

Jaques–Schanck [21] による同種写像問題に対する（量子）安全性評価報告は，いずれも SIDH 鍵共有（及び SIKE 暗71

号化 [20]）法への攻撃として提案されているが，多くの部分は一般的な超特異同種写像問題に関する知見としても有効であることに注意する．

6.1.2 自己準同型環計算問題と SQISign 署名方式の安全性に関する計算問題
6.1.2.1 自己準同型環計算問題
同種写像暗号は，Kohel [22], Galbraith [17], Couveignes [9] らの先駆的研究にその起源をもつが，特に ，Kohel は有限体上の楕円曲線の自己準同型環を計算するアルゴリズムを探求しており，そのために楕円曲線の同種写像からなる「同種写像グラフ」の性質を見極めることから始めて，目的とする自己準同型環計算を同種写像グラフ上のアルゴリズ
ム構成に帰着していく．その後，Kohel–Lauter–Petit–Tignol [23] は，この「同種写像計算」と「自己準同型環計算」
を並置しながら考察する視点を，「構成的 Deuring 対応」として計算論的観点から捉え直した（表 6.1 参照）．そこでは，四元数環側での `-同種写像道探索問題を解く KLPT アルゴリズムが鍵となるアルゴリズムである．そして，この構成的 Deuring 対応に基づき「同種写像計算」と「自己準同型環計算」の等価性が示されており [11, 12, 36]，現在，
自己準同型環計算問題の困難性に基づいた暗号構成の研究が進められている [18, 15, 16]．
■自己準同型環計算問題とその超特異同種写像計算問題との同値性

以下の記述に関しては，例えば [24, 25] を参照する．有理数体 Q 上 {1, i, j, k} を基底とするベクトル空間でありかつ a, b ∈ Q により i2 = a, j 2 = b, k = ij = −ji という積構造が入った Q 上の代数（環）を四元数環 B と呼ぶ．各素点 ν （素数または ∞）における Q の完備化 Qν によるB ⊗ Qν が ν = p, ∞ の時にのみ斜体（可除環）になる四元数環 B = Bp,∞ を扱う．これを，Bp,∞ は p, ∞ の 2 点のみで分岐する四元数環であるといい，Bp,∞ は同型を除いて一意的に決まる．この同じ素数 p を標数とする有限体上の超特異楕円曲線 E の自己準同型写像がなす環 End(E) は E の自己準同型環と呼ばれて，End(E) は Bp,∞ の極大整環 Oになっている*1 ．ここで，（四元数環の）整環とは Z 上階数 4 の加群でありかつ環であるものであり，極大整環とは，そのような整環の中で包含関係に関して極大になっているものを指す．この自己準同型環 End(E) を計算する以下の問題が基本である．
定義 6.2 (自己準同型環計算問題 [22]) 超特異楕円曲線 E が与えられて，E の自己準同型環 End(E) を計算せよ．

Eisenträger らの研究 [11, 12] により，超特異同種写像計算問題と（超特異）自己準同型環計算問題の間に多項式時間
帰着による計算問題としての同値性が示された．そこではヒューリスティックな仮定が使われていたが，Wesolowski[36] は，一般化されたリーマン予想に基づいて，その同値性に対して厳密な証明を与えた．
√
6.1.1 節で，超特異同種写像問題の古典計算機による現在最速の解読時間は Õ( p) と見積もられていたので，この同値性により，自己準同型環計算問題も同等の計算時間であるが，直接に，自己準同型環計算問題を解く研究も進められ√ており，[12] において，Õ( p) 時間の自己準同型環計算（古典）アルゴリズムが報告されている．
■Deuring 対応

自己準同型環計算問題で与えられる楕円曲線 E から極大整環 O への対応は，表 6.1 に掲げたように，楕円曲線に関する様々な概念から四元数環に関する概念への対応に拡張される．その詳細に関しては，例えば [25,
第 2 章] を参照していただきたいが，特に基本的な対応としては，同種写像 ϕ : E → E1 が，極大整環の間の同型

O∼= End(E), O1 ∼= End(E1 ) を通して，左 O-整イデアルかつ右 O1 -整イデアルである Iφ に対応していることである．
これにより始点曲線 E を固定すると，同種写像 ϕ : E → E1 の終点曲線 E1 が O のイデアル類と対応することがわかり，超特異 j 不変量 (∈ Fp2 ) の集合がイデアル類集合 cl(O) と一対一に対応していることもわかる．

*1 自己準同型写像は英語で endomorphism であるので，その全体を End(E) で表す．

72

一般に表 6.1 に示されるように，幾何的な情報から成る楕円曲線側のデータと代数的な情報から成る四元数環側のデータの間に対応関係が存在しており，Deuring 対応と呼ばれる．自己準同型環計算問題（定義 6.2）は Deuring 対応に基づいた問題であり，楕円曲線側の超特異 j 不変量 j(E) から対応する四元数環側の極大整環 O = End(E) を計算する問題となっている．そして，この Deuring 対応は，6.2.1 節及び 6.3.1 節での暗号構成を理解する際にも重要な鍵となっている．
表 6.1: Deuring 対応
楕円曲線側

四元数環側

超特異 j 不変量 j(E) ∈ Fp2 (の Fp2 /Fp -Galois 共役類)

Bp,∞ 内の極大整環 O = End(E) の自己同型類（タイプ）同種写像 ϕ : E → E1 で定まる (E1 , ϕ)

左 O-整イデアルかつ右 O1 -整イデアルである Iφ

自己準同型写像 θ ∈ End(E)主イデアル Oθ同種写像の次数 deg(ϕ)

イデアルのノルム n(Iφ )双対同種写像 ϕ̂

共役イデアル Iφ

同じ定義域・値域の同種写像 ϕ : E → E1 , ψ : E → E1

同値なイデアル Iφ ∼ Iψ

超特異 j 不変量 j(E) ∈ Fp2 の集合

イデアル類の集合 cl(O)

同種写像の合成 τ ◦ ρ : E → E1 → E2

イデアル積 Iτ ◦ρ = Iρ · Iτ

N -同種写像の同型類

レベル N の Eichler 整環の類集合

6.1.2.2

SQISign 署名の安全性に関する計算問題

次に，SQISign 署名の安全性を示すために必要な計算問題を述べる．
■SQISign 署名の健全性に関する計算問題 まずは，SQISign 署名の健全性（偽造不可能性）を示すための計算問題である超特異平滑自己準同型写像計算問題（SEP：Smooth Endomorphism Problem）を定義する．以下では，核が巡回群となる自己準同型写像を巡回自己準同型写像と呼ぶ．
定義 6.3 (超特異平滑自己準同型写像計算問題 [15, 25]) 超特異楕円曲線 E が与えられて，平滑な整数を次数にもつ

E 上の（非自明な）巡回自己準同型写像を見つけよ．
上記問題で問うているような非自明な自己準同型写像が計算できれば，[12] で見るように，自己準同型環 End(E)全体も計算できることが知られているので，上記問題は，本質的に自己準同型環計算問題と同値である [15]．よって，√
Õ( p) 時間での古典アルゴリズム [12] が現状最速と見積もられる．

■特殊極値的楕円曲線

次に，SQISign 署名の零知識性を示すための計算問題を述べるが，公開パラメータで重要となる楕円曲線 E0 を示す．p = 3 mod 4 の時，j 不変量 j = 1728 となる E0 : y 2 = x3 + x の O0 = End(E0 ) は
1+ij
i2 = −1, j 2 = −p となる O0 = Z + Zi + Z i+j
2 + Z 2 となることが知られている．更に具体的に自己準同型写像√1+ιπι : (x, y) 7→ (−x, −1y), π : (x, y) 7→ (xp , y p ) により End(E0 ) = Z + Zι + Z ι+πで与えられる．
2 +Z 2

標数 p と ∞ のみで分岐する四元数環 Bp,∞ := Q[i, j] における極大整環 O0 ⊂ Bp,∞ は，最小判別式の 2 次整環である O ⊂ O0 ∩ Q[i] による O + jO ⊂ O0 が部分整環であり O ⊂ (jO)⊥ と直交分解しているとき*2 ，特殊極値的*2 Bp,∞ における内積は α, β ∈ Bp,∞ に対して 1 tr(αβ̄) で与えられて，ここは，その内積に関する直交分解である (Bp,∞ 内のトレース，共273

（special extremal）であるという．詳細は [15, 25] を参照．p = 7 mod 12 の時，上記の E0 に対して End(E0 ) は特殊
極値的であり，この時，E0 は特殊極値的曲線と呼ばれる．特殊極値的曲線 E0 は，その自己準同型環の構造が簡単で計算上扱いやすいため GPS 署名 及び SQISign 署名の公開パラメータの一部として必要である．
■SQISign 署名の零知識性に関する計算問題

SQISign 署名では，右図の同種写

SQISign 同種写像図式

像 τ が秘密鍵で，超特異楕円曲線 EA が公開鍵 (の主要な一部) である．署名生成では，同種写像 ψ, ϕ を適切に生成して得られた合成写像 ϕ ◦ ψ ◦ τ̂ を「ランダムE0化」した同種写像 σ を署名とする*5 ．[15, 16] において定義された E0 を始点とす

τ

る同種写像から成るある集合 PNτ を τ によって EA を始点とした同種写像に移した集合 [τ ]∗ PNτ （PNτ の τ による pushforward）を考える．正しく生成された署


EA

ψ

/ E1
φ

σ


/ E2

名同種写像 σ は [τ ]∗ PNτ に属するのであるが，それが EA を始点とした 2 べき次CSI-FiSh, GPS 図式と同

数 D (= 2e ) の巡回同種写像全体 IsoD,j(EA ) から一様にサンプリングしたのと区別

様に可換図式ではない．

が付くかという問題が以下であり，SQISign 署名の零知識性を示すために必要である．
定義 6.4 (SQISign 署名のランダム識別問題 [15, 25]) τ : E0 → EA を秘密同種写像として，楕円曲線 E0 を含む

SQISign 署名の公開パラメータ ppsqisign （詳しくは 6.3.1 節参照）と公開鍵 EA が入力として与えられると共に，[τ ]∗ PNτ から一様サンプリングして返すオラクル Oτ への多項式回のアクセスが許される時に，EA を始点とする同種写像 σ が与えられて σ が IsoD,j(EA ) から一様に選ばれたか，[τ ]∗ PNτ から一様に選ばれたかを判定せよ．

SQISign 署名の提案者によると，現在のところ，SQISign 署名のランダム識別問題を解くのに，E0 と EA の情報か√ら τ を暴く攻撃法より効率の良い攻撃法はまだ知られていないとのことである [15, 25]．つまり，Õ( p) 時間を必要とすると見積もられている．
また，上記の SQISign 署名に関する計算問題は，どちらも補助点を問題に含まないことにより，調査報告書に記載されている最近の SIDH 同種写像問題に対する攻撃法が適用できないことに注意する．

6.2 代表的な同種写像に基づく暗号方式の説明
6.2.1 GPS 署名
Galbraith–Petit–Silva (GPS) [18] によって始めて自己準同型環の知識証明に基づく署名方式が提案された．GPS
署名は実際に利用するのは困難であろうと思われているが，現在，GPS 署名は，SQISign 署名の原型を与えているという点で重要である．6.1.2 節で述べた Deuring 対応と KLPT アルゴリズム [23] が GPS 署名の理論的基礎を与える．

役の定義は，例えば [25] を参照のこと)．
*5 τ̂ は τ の双対同種写像である．表 6.1 も参照のこと．

74

右図において E0 は 6.1.2.2 節で与えた j(E0 ) = 1728 なる楕円曲線（特殊極値
的楕円曲線）であり，そこで見たようにその E0 に関しては End(E0 ) の構造が簡明な形で与えられている．その楕円曲線 E0 からの秘密鍵同種写像 τ : E0 → EA
を知っている証明者（署名生成者）は，EA から別の楕円曲線 E1 への同種写像

σ0 : EA → E1 と τ との合成 σ0 ◦ τ : E0 → E1 を KLPT アルゴリズムによって「ランダム化」して同じ始点 E0 と終点 E1 をもつ σ0 ◦ τ とは異なる同種写像

GPS 同種写像図式
/ E1
|>
|
||
τ
|| σ
 || 0EA
E0σ1

σ1 : E0 → E1 を得ることができる．
さらに，自己準同型環 End(EA ) を計算する問題の困難性に基づけば，このようなランダム化ができるのは，τ を知っている証明者に限られるので，チャレンジ bit c ∈ {0, 1} を送って証明者に同種写像 σc を答えさせることにより，

τ に関する知識の有無を検査することができて，認証・署名方式が構成できる．それが GPS 認証方式，そしてそのFiat–Shamir 変換署名が GPS 署名である．ここでは [18, 第 4 章] と [25, 5.1.2 節] に基づいて GPS 署名を記述する．
また，[18, 第 4 章] では，通常の Fiat–Shamir 変換を施した署名方式と Unruh 変換を施した署名方式の 2 方式が記述されているが，ここでは記述の簡便さを考慮して前者の記述を基にして以下に署名方式を与える．
鍵生成：

既知の特殊極値的自己準同型環 O0 をもつ超特異楕円曲線 E0 ，互いに素な B-べき平滑数 S1 , S2 *6 を，S1 , S2 次の同種写像グラフ上ランダムウォークが急攪拌性定理により一様分布を導く程度に十分大きくとる．
セキュリティパラメータ λ に対して t := λ（または t := 2λ）として，t bits 出力のハッシュ関数 H を選
ぶ．ppgps := (E0 , S1 , S2 , H) を公開パラメータとする．さらに，E0 を始点とする S1 次のランダムな同種写像

τ : E0 → EA を計算して，ppgps と EA を公開鍵として，τ を秘密鍵とする．
署名生成：

各 i = 1, . . . , t に関して EA を始点とする S2 次のランダムな同種写像 σ0,i : EA → E1,i を計算する．署名

対象メッセージ msg に対してチャレンジ bit 列 h := b1 k · · · k bt := H(j(E1,1 ), . . . , j(E1,t ), msg) ∈ {0, 1}t を
ハッシュ関数 H で計算する．各 i = 1, . . . , t に対して，もし bi = 1 なら KLPT アルゴリズムによって「ランダム化」したランダム同種写像 σ1,i : E0 → E1,i を計算する．署名を σ := (h, σb1 ,1 , . . . , σbt ,t ) とする．
署名検証：

公開鍵 (ppgps , EA )，メッセージ msg と署名 σ = (h, σ1 , . . . , σt ) を入力として，各 i = 1, . . . , t に対して，

同種写像 σi を計算して，その終点曲線 E1,i を得る．次に H(j(E1,1 ), . . . , j(E1,t ), msg) を計算して署名内の hと一致するかどうか検証して，全ての i = 1, . . . , t に対して検証が成功すれば受理を出力して, そうでなければ,不受理を出力する．

GPS 署名は，超特異楕円曲線同種写像計算問題またはそれと同値な自己準同型環計算問題（定義 6.2）の困難性を仮定すればランダムオラクルモデルの下で EUF-CMA 安全であることが示されている [18, 定理 10]．GPS 署名では，1bit のチャレンジを用いた Σ-プロトコルに基づいているため，署名サイズが大きくなるのが欠点である．また，署名生成で使われた KLPT アルゴリズムの計算時間改善も課題であった [25, 5.1.2 節]．以上，GPS 署名には (1) 署名サイズ 及び (2) KLPT アルゴリズム計算時間 に関する 2 つの課題が存在する．

6.3 同種写像に基づく主要な暗号方式の説明
本節では，公開鍵と署名サイズが小さいことを特長にもつ SQISign 署名について述べる（表 6.2 参照）．

∏ ek,iee*6 Sk （k = 1, 2）が B-べき平滑数（powersmooth number）とは，Sk が ℓ k,i < B なる ℓ k,i の積で表される（i.e., Sk =i ℓk,i ）こと
k,i
k,i
である．

75

表 6.2: 同種写像に基づく暗号の分類
文献

暗号化

鍵交換

署名
○

SQISign [15]6.3.1 SQISign 署名
以下，自己準同型環計算問題（定義 6.2）の困難性に安全性の根拠を置く SQISign 署名を概説する．SQISign 署名
は公開鍵と署名を合わせたサイズが小さい方式として注目されている．6.2.1 節で述べた GPS 署名を基にして改良を加えた署名方式が SQISign 署名であり，ASIACRYPT 2020 で De Feo–Kohel–Leroux–Petit–Wesolowski [15] により提案された．6.2.1 節末尾に付した GPS 署名の 2 つの課題を克服している．チャレンジ空間に同種写像の空間を用いることで，そのサイズをセキュリティパラメータ λ まで大きくして，Σ-プロトコルを 1 度適用するだけで十分な Fiat–Shamir 署名構成とした．これで署名サイズが格段に小さくなった．また，GPS 署名生成においては，表

6.1 の Deuring 対応に基づいて，同種写像のイデアル表現（表 6.1 の四元数環側）をねじれ点を使った表現（表 6.1の楕円曲線側）に変換する部分で時間が費やされていたが，SQISign 署名ではその処理を速度改善したサブルーチン（IdealToIsogeny）に置き換えるのに成功して演算効率も大きく改善した [15, 16]．
また，安全性に関しては，健全性は超特異平滑自己準同型写像計算問題（定義 6.3）の困難性に基づき，零知識性は
定義 6.4 で述べた SQISign 署名のランダム識別問題の困難性に基づいている．初期提案 [15] では，ノルム方程式を解
くサブルーチンに不備があり，生成される署名同種写像 σ に偏りが生じていたことが [16] において指摘された．そして，更に [16] でその不備を除去したアルゴリズム提案が行われた．
具体的なパラメータ，特に適切な SQISign 素数（SQISign-friendly prime）p を生成する問題は非自明であり，初期提案 [15] から始まり，[8, 16, 2] と現在も進行中の研究テーマである．その現状報告を後ほど行う．また，小貫 [28] により，SQISign 鍵生成で得られる鍵の分布の理論・実験による解析がなされており，[15] で述べられた従来仕様の不備を指摘して，改善アルゴリズムを提案している．
以下では，方式記述，SQISign 署名パラメータ，実装報告の順に既存の研究報告をまとめる．
■SQISign 署名方式記述 SQISign 署名では，右図の同種写像 τ が秘密鍵で，超特SQISign 同種写像図式

異楕円曲線 EA が公開鍵 (の主要な一部) である．署名生成では，コミットメント同種写像 ψ とチャレンジ同種写像 ϕ を適切に生成して得られた合成写像 ϕ ◦ ψ ◦ τ̂ を

E0

一般化された KLPT アルゴリズムでランダム化した同種写像 σ を署名（Σ-プロト

τ

コルのレスポンス）とする．チャレンジ ϕ によりセキュリティパラメータ分のラ


EA

ψ

/ E1
φ

σ


/ E2

ンダムネスを与えることができるので，1 度の Σ-プロトコル適用で十分な安全性が達成できる．よって，GPS 署名と比べて格段に短い署名サイズが実現できる．
鍵生成：

既知の特殊極値的自己準同型環 O0 をもつ超特異楕円曲線 E0 ，λ bits の平滑奇数 Dc （λ はセキュリティパラメータ），超特異 2-同種写像グラフの直径より大きな e による D := 2e を生成して，ppsqisign := (E0 , Dc , D)を公開パラメータとする．さらに，E0 を始点とするランダムな同種写像 τ : E0 → EA を計算して，ppsqisign とEA を公開鍵として，τ を秘密鍵とする．
署名生成：

E0 を始点とするランダムな同種写像 ψ : E0 → E1 を計算．署名対象メッセージ msg に対してハッシュ76

関数 H で計算した H(j(E1 ), msg) から決まる Dc 次の巡回同種写像 ϕ : E1 → E2 を計算．同種写像の合成

ϕ ◦ ψ ◦ τ̂ : EA → E2 から（一般化された KLPT アルゴリズムを用いて）同じ始点・終点を有して ϕ̂ ◦ σ が巡回同種写像になる D 次のランダム同種写像 σ : EA → E2 を計算．(E1 , E2 , σ) を msg の署名として出力．
署名検証：

公開鍵 (ppsqisign , EA )，メッセージ msg と署名 (E1 , E2 , σ) を入力として，E1 から E2 への同種写像

ϕ := H(j(E1 ), msg) を計算する．σ が EA から E2 への D 次同種写像であることと ϕ̂ ◦ σ が EA から E1 への巡回同種写像であることを検証して，共に成立すれば受理を出力して, そうでなければ, 不受理を出力する．
既に述べたように，SQISign 署名の安全性は，超特異平滑自己準同型写像計算問題（定義 6.3）の困難性と，定義 6.4
で述べた SQISign 署名 σ のランダム識別問題の困難性に基づいている．
■SQISign 署名パラメータ

署名同種写像 σ の次数は D = 2e ，チャレンジ同種写像 ϕ の次数は平滑奇数 Dc であるので，それら同種写像を小さい拡大次数の有限体で効率的に計算するために，超特異楕円曲線の位数 #E(Fp2 ) = p2 − 1を考慮して，できるだけ大きい正整数 f ，正奇数 T に関して 2f · T | p2 − 1 が満たされる素数 p（SQISign 素数）を生成することが必要である．具体的には，ある B に対して B-平滑な T ，T ≈ p5/4+ϵ ([2] では例えば 0.02 <  < 0.1 とする) に対して 2f · T | p2 − 1 となる素数 p を探索する必要がある．SQISign 素数の選択基準として，署名検証の効率化には f をできるだけ大きくして，署名生成の効率性にとっては√B/f をできるだけ小さくするのが望ましい [16]．

NIST 安全性レベル 1： SQISign 素数は，NIST 安全性レベル 1 については，[16] において，XGCD アルゴリズムに基づいて，B = 3923 に関して B-平滑な T を持つ以下の 254 bits 素数 p が生成された．f = 66 であり，T は式 (6.1)
で灰色でない B 以下の奇素因数の積で与えられる．T に関しては他の SQISign 素数についても同様である．また，[15, 25] によればレベル 1 パラメータでは署名 σ の次数 D = 2e の指数 e が e = 1000 で与えられている．
p + 1 = 265 · 52 · 7 · 11 · 19 · 292 · 372 · 47 · 197 · 263 · 281 · 461 · 521 · 3923 · 62731 · 96362257 · 3924006112952623,
p − 1 = 2 · 365 · 13 · 17 · 43 · 79 · 157 · 239 · 271 · 283 · 307 · 563 · 599 · 607 · 619 · 743 · 827 · 941 · 2357 · 10069. (6.1)
同じく NIST 安全性レベル 1 で最良の SQISign 素数として，[2] において，B = 523 に関して B-平滑な T を持つ以下の 254 bits 素数 p = 2r3 − 1 (r = 20461449125500374748856320) が生成されている．f = 47 である．

p + 1 = 246 · 53 · 133 · 313 · 733 · 833 · 1033 · 1073 · 1373 · 2393 · 2713 · 5233 ,(6.2)

p − 1 = 2 · 3 · 7 · 11 · 17 · 19 · 101 · 127 · 149 · 157 · 167 · 173 · 199 · 229 · 337 · 457 · 479 ·
32

2141067 · 3428098456843 · 4840475945318614791658621.
NIST 安全性レベル 3：NIST 安全性レベル 3,5 に関しては [16] までは適切なパラメータ例が与えられていなかったが，レベル 3 について，後続研究である [2] において最良の SQISign 素数として，B = 10243 に関して B-平滑な T を持つ
以下の 382 bits 素数 p = 2r 6 − 1 (r = 11896643388662145024) が生成されている．f = 80 である．

p + 1 = 279 · 36 · 2312 · 1076 · 1276 · 3076 · 4016 · 5476 ,(6.3)

p − 1 = 2 · 5 · 7 · 11 · 17 · 19 · 47 · 71 · 79 · 109 · 149 · 229 · 269 · 283 · 349 · 449 · 463 · 1019 · 1033 · 1657 · 2179 ·
22293 · 4099 · 5119 · 10243 · 381343 · 19115518067 · 740881808972441233 · 83232143791482135163921.
NIST 安全性レベル 5：また，レベル 5 についても，[2] において最良の SQISign 素数として，B = 150151 に関して
B-平滑な T を持つ以下の 508 bits 素数 p = 2r6 − 1 (r = 26697973900446483680608256) が生成されている．f = 86

77

である．

p + 1 = 285 · 1712 · 376 · 596 · 976 · 2336 · 31112 · 9116 · 12976 ,(6.4)

p − 1 = 2 · 3 · 5 · 7 · 11 · 23 · 29 · 127 · 163 · 173 · 191 · 193 · 211 · 277 · 347 · 617 · 661 · 761 · 1039 · 4637 ·22

25821 · 15649 · 19139 · 143443 · 150151 · 3813769 · 358244059 · 992456937347·
353240481781965369823897507 · 8601020069514574401371658891403021.
■SQISign 署名実装報告

NIST レベル 3,5 パラメータ (式 (6.3), (6.4)) に関しては，まだ実装報告が公開されていな

い．以下では，NIST レベル 1 パラメータ (式 (6.1), (6.2)) に関する実装報告をまとめる．
データサイズ：式 (6.1), (6.2) の NIST レベル 1 パラメータに関して，秘密鍵サイズ 16 Bytes，公開鍵サイズ 64 Bytes，
署名サイズ 204 Bytes が報告されている [15, 16]．
演算時間：式 (6.1) の NIST レベル 1 パラメータに関して，演算時間中央値は，鍵生成 218 ms（ミリ秒），署名生成1081 ms，署名検証 19 ms と報告されている [16]．詳細は [16] を参照のこと．

6.4 同種写像に基づく暗号技術に関するまとめ
本章では, 同種写像に基づいた暗号技術をまとめた．特に，SQISign 署名に関して, 関連する GPS 署名も含めた方式
記述と安全性研究についてまとめてきた.

[9] によると, Couveignes は, 1997 年の École Normale Supérieure でのセミナーで既に同種写像に基づく暗号技術を提案しており, ほぼ同時期に Kohel [22] や Galbraith [17] も, 同種写像問題に関する研究を始めていた. つまり, 同種写像暗号技術の研究は既に 25 年の歴史をもつ. そして, 最近になり, 耐量子計算機暗号の必要性が高まることで, 同種写像暗号技術は注目されて研究が進み, NIST 第 4 ラウンド コンペティションにも選ばれた SIKE 暗号化及びその基本形である SIDH 鍵共有は，最近まで堅調に安全性評価を積み重ねてきた．しかし，2022 年の Castryck–Decru の攻撃法 [3] を始めとする一連の攻撃法 [27, 30] は SIDH 鍵共有に対して決定的な結果をもたらした．
一方，それは，この 25 年の研究の一つの到達点として，同種写像暗号全体に対して基本的な安全性指標を提示することになった．現在，その新しい安全性指標に基づいて更に安全性解析が進展していると共に，また新しい方式提案も含む活発な研究活動が引き続いて行われている．例えば，調査報告書に記載されている最近新規提案された M-SIDH
鍵共有・MD-SIDH 鍵共有の安全性研究は，今後の重要な研究課題の一つである．
現在，特に，公開鍵と署名を合わせたサイズが短い SQISign 署名が注目されていると共に，調査報告書に記載されている CSIDH ベースの一方向性群作用に関する研究も注目されており，種々の暗号プロトコルへの応用も視野に入れた研究も進んでいる．それらも含めて，今後, 特に注意すべきこと数点について以下にまとめておく.

• SQISign 署名は，公開鍵と署名のサイズの小ささ，補助点なしの署名構成，そして短署名に対する強い社会的ニーズなどを踏まえると，現在有望な同種写像暗号技術と思われる．その一方，零知識性に関する計算問題（定義 6.4）の安全性検討などに関して，まだ安全性評価が不十分であり，その安全性評価は今後の重要な課題の一つである．さらに，今後，標準化などを考慮するのであれば，実装研究を進める必要があり，特にさまざまなプ
ラットフォームでの実装結果を蓄えていく必要もある．

• 調査報告書に記載されている CSIDH ベース署名である SeaSign 署名と CSI-FiSh 署名についても，今後の耐量子計算機署名として研究が進められているが，安全性評価が定まった実用的な署名を得るためには，まだ今後の安全性・実装研究が必要である．そして，リング署名・グループ署名などの高機能暗号系への応用研究も重要であり，今後の研究動向に注目する必要がある．

78

•（一般的な）超特異同種写像問題及びそれと同値な自己準同型環計算問題に関しては，これまで主に，SIKE 暗号
化パラメータに関係して，具体的な安全性評価が行われてきた．SQISign 署名パラメータを具体的に決めていく
ためには，SQISign 署名パラメータに対して，上記問題に対する古典・量子アルゴリズムの詳細な解析・見積もりを行うことが重要であり, 今後の課題である．

• 上で述べたように現在研究が進展している新しい安全性指標に基づいて，全体に，同種写像暗号技術は，まだまだ研究の余地があり，鍵・暗号文・署名サイズの小ささの点で他の耐量子暗号技術にない特長があるので，さまざまな利用用途を見据えて今後も継続的な研究が望まれる．

79

第 6 章の参照文献[1] J. Biasse, D. Jao, and A. Sankar. A quantum algorithm for computing isogenies between supersingularelliptic curves. In INDOCRYPT 2014, pages 428–442. Springer, 2014.
[2] G. Bruno, M. C.-R. Santos, C. Costello, J. K. Eriksen, M. Meyer, M. Naehrig, and B. Sterner. Cryptographic
smooth neighbors. IACR Cryptol. ePrint Arch., 2022. http://eprint.iacr.org/2022/1439.
[3] W. Castryck and T. Decru. An eﬃcient key recovery attack on SIDH (preliminary version). IACR Cryptol.
ePrint Arch., 2022. http://eprint.iacr.org/2022/975, To appear in EUROCRYPT 2023.
[4] D. Charles, K. Lauter, and E. Goren. Cryptographic hash functions from expander graphs. J. Crypt.,22(1):93–113, 2009.
[5] A. M. Childs, D. Jao, and V. Soukharev. Constructing elliptic curve isogenies in quantum subexponential
time. J. Math. Cryptol., 8(1):1–29, 2014.
[6] C. Costello. The case for SIKE: A decade of the supersingular isogeny problem. IACR Cryptol. ePrint Arch.,
2021. http://eprint.iacr.org/2021/543.
[7] C. Costello, P. Longa, M. Naehrig, J. Renes, and F. Virdia. Improved classical cryptanalysis of SIKE inpractice. In PKC 2020, Part II, volume 12111 of LNCS, pages 505–534. Springer, 2020.
[8] C. Costello, M. Meyer, and M. Naehrig. Sieving for twin smooth integers with solutions to the ProuhetTarry-Escott problem. In EUROCRYPT 2021, Part I, pages 272–301. Springer, 2021.
[9] J. Couveignes. Hard homogeneous spaces. IACR Cryptol. ePrint Arch., 2006. http://eprint.iacr.org/
2006/291.
[10] L. De Feo, D. Jao, and J. Plût. Towards quantum-resistant cryptosystems from supersingular elliptic curveisogenies. J. Math. Crypt., 8(3):209–247, 2014.
[11] K. Eisenträger, S. Hallgren, K. E. Lauter, T. Morrison, and C. Petit. Supersingular isogeny graphs andendomorphism rings: Reductions and solutions. In EUROCRYPT 2018, Part III, volume 10822 of LNCS,
pages 329–368. Springer, 2018.
[12] K. Eisenträger, S. Hallgren, C. Leonardi, T. Morrison, and J. Park. Computing endomorphism rings ofsupersingular elliptic curves and connections to pathﬁnding in isogeny graphs. In ANTS 2020, volume 4 of
The Open Book Series, pages 215–232. Mathematical Sciences Publishers, 2020.
[13] L. D. Feo. Mathematics of isogeny based cryptography. CoRR, abs/1711.04062, 2017.
[14] L. D. Feo, J. Kieﬀer, and B. Smith. Towards practical key exchange from ordinary isogeny graphs. In
ASIACRYPT 2018, Part III, volume 11274 of LNCS, pages 365–394. Springer, 2018.
[15] L. D. Feo, D. Kohel, A. Leroux, C. Petit, and B. Wesolowski. SQISign: Compact post-quantum signaturesfrom quaternions and isogenies. In ASIACRYPT 2020, Part I, pages 64–93. Springer, 2020.

80

[16] L. D. Feo, A. Leroux, and B. Wesolowski. New algorithms for the Deuring correspondence: SQISign twice
as fast. IACR Cryptol. ePrint Arch., 2022. https://eprint.iacr.org/2022/234.
[17] S. Galbraith. Constructing isogenies between elliptic curves over ﬁnite ﬁelds. Journal of Computational
Mathematics, 2:118–138, 1999.
[18] S. D. Galbraith, C. Petit, and J. Silva. Identiﬁcation protocols and signature schemes based on supersingularisogeny problems. J. Cryptol., 33(1):130–175, 2020.
[19] S. D. Galbraith and F. Vercauteren. Computational problems in supersingular elliptic curve isogenies.
Quantum Inf. Process., 17(10):265, 2018.
[20] D. Jao, R. Azarderakhsh, M. Campagna, C. Costello, L. D. Feo, B. Hess, A. Jalali, B. Koziel, B. LaMacchia,
P. Longa, M. Naehrig, G. Pereira, J. Renes, V. Soukharev, and D. Urbanik. SIKE: Supersingular isogeny
key encapsulation. submission to the NIST’s PQC standardization, round 3, October 2020.
[21] S. Jaques and J. M. Schanck. Quantum cryptanalysis in the RAM model: Claw-ﬁnding attacks on SIKE. In
CRYPTO 2019, Part I, volume 11692 of LNCS, pages 32–61. Springer, 2019.
[22] D. Kohel. Endomorphism rings of elliptic curves over ﬁnite ﬁelds. PhD thesis, University of California at
Berkeley, 1996.
[23] D. Kohel, K. Lauter, C. Petit, and J.-P. Tignol. On the quaternion `-isogeny path problem. LMS Journal ofComputation and Mathematics, 17:418–432, 2014. Special Issue A: Algorithmic Number Theory Symposium
XI.
[24] A. Leroux. A new isogeny representation and applications to cryptography. In ASIACRYPT 2022, LNCS.
Springer, 2022.
[25] A. Leroux. Quaternion algebras and isogeny-based cryptography. PhD thesis, Ecole Polytechnique, 2022.
[26] P. Longa, W. Wang, and J. Szefer. The cost to break SIKE: A comparative hardware-based analysis with
AES and SHA-3. In CRYPTO 2021, Part III, volume 12827 of LNCS, pages 402–431. Springer, 2021.
[27] L. Maino and C. Martindale. An attack on SIDH with arbitrary starting curve (draft). IACR Cryptol. ePrint
Arch., 2022. http://eprint.iacr.org/2022/1026.
[28] H. Onuki. On the key generation in SQISign. In NutMic 2021. Springer, 2022.
[29] J. Renes. Computing isogenies between Montgomery curves using the action of (0, 0). In PQCrypto 2018,
volume 10786 of LNCS, pages 229–247. Springer, 2018.
[30] D. Robert. Breaking SIDH in polynomial time. IACR Cryptol. ePrint Arch., 2022. http://eprint.iacr.
org/2022/1038.
[31] A. Rostovtsev and A. Stolbunov. Public-key cryptosystem based on isogenies. IACR Cryptology ePrint
Archive, 2006. http://eprint.iacr.org/2006/145.
[32] A. Udovenko and G. Vitto. Breaking the $IKEp182 challenge. IACR Cryptol. ePrint Arch., 2021. http://eprint.iacr.org/2021/1421.
[33] J. Vélu. Isogénies entre courbes elliptiques. C.R. Acad. Sc. Paris, Séries A., 273:238–241, 1971.
[34] J. Voight. Quaternion Algebras. Springer, June 2022.
[35] L. Washington. Elliptic Curves: Number Theory and Cryptography. CRC Press, 2nd edition, 2008.
[36] B. Wesolowski. The supersingular isogeny path and endomorphism ring problems are equivalent. In FOCS
2021, pages 1100–1111. IEEE, 2022.

81

第7章

ハッシュ関数に基づく署名技術
本章ではハッシュ関数に基づく署名技術についてまとめる．ハッシュ関数に基づく署名技術の安全性はハッシュ関数の第二原像攻撃に対する安全性に依存している．
ハッシュ関数に基づく署名技術は，最初に Lamport により one-time signature として提案された [11, 25]．また，
この方式を改良した Winternitz one-time signature が Merkle [29] により述べられている．これらの方式は一組の公開鍵と秘密鍵を用いて一つのメッセージに署名を行う 1 回署名方式である．1 回署名方式とマークル木とを用いて複数回署名を行うことを可能とする方式が Merkle [28, 29] により述べられている．

7.1 ハッシュ関数に基づく署名技術の安全性の根拠となる問題
ハッシュ関数は任意長あるいは実用上十分な長さ以下の入力 {0, 1} 系列に対して固定長の {0, 1} 系列を出力する関数である．ハッシュ関数を H : D → R とする．ここで，D は任意長の {0, 1} 系列の集合 {0, 1}∗ の部分集合であり，R は固定長の {0, 1} 系列の集合である．ハッシュ関数の第二原像攻撃は，第一原像 X ∈ D が与えられたとき，

X 6= X ′ かつ H(X) = H(X ′ ) を満たす第二原像 X ′ ∈ D を求めるという問題を解くことを目的とする攻撃である．なお，第二原像攻撃に対する安全性は，しばしば，ハッシュ関数の各入力に対する出力が無作為に選択されるようなランダム関数であると仮定して評価される．このようなランダム関数はランダムオラクルとも呼ばれる．H がランダムオ
ラクルであるとき，第二原像を得るのに必要な計算時間は Θ(|R|) である．また，量子コンピュータでは，Grover の探
索アルゴリズム [16] を用いることにより，第二原像を得るのに必要な計算時間は Θ(p|R|) となる．

本章で取り上げるハッシュ関数に基づく署名技術では，SHA-2 [13], SHA-3 [15], Haraka [23] のうちのいくつかの
ハッシュ関数を用いることが想定されている．これらのうち，SHA-2, SHA-3 は米国 NIST の指定する標準ハッシュ関数族である．

SHA-2 は Merkle-Damgård 構造 [10, 30] を有するハッシュ関数の族であり，Secure Hash Standard [13] のうち，SHA-1 を除く SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 からなる．SHA-2 の各ハッシュ関数の名称の末尾の数値は出力の bit 長を表す．SHA-3 は置換を用いたスポンジ構造 [6] を有するハッシュ関数の族であり，SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256 からなる．SHA3-224, SHA3-256,

SHA3-384, SHA3-512 については，末尾の数値は出力の bit 長を表す．SHAKE128, SHAKE256 については，出力長は任意に設定できる．

Haraka はブロック暗号 AES [8, 14] に基づく置換を用いた Davies-Meyer 構造 [33] に基づくハッシュ関数の族であり，Haraka-256, Haraka-512 からなる．Haraka-256, Haraka-512 の末尾の数値は入力の bit 長を表す．出力長はいず
れも 256 bits である．Haraka は，ハッシュ関数に基づく署名技術での使用を想定し，短い入力に対して高い処理性能82を達成するよう設計されている．
本章で使用する記号・用語を以下にまとめる．

• {0, 1} 系列 α, β の連接を αkβ と表記する．
•  は左論理シフトを表す．
• 整数 ν について [ν]l は ν の長さ l bits の 2 進数表記を表す．
• B := {0, 1}8 とする．

7.2 代表的なハッシュ関数に基づく署名方式
7.2.1 Winternitz One-Time Signature
Winternitz one-time signature [29] は，一組の公開鍵と秘密鍵を用いて一つのメッセージに署名を行う 1 回署名方式である．この方式では，署名対象のメッセージのハッシュ値 N を b 進数表記の整数とみなす．N が `m 桁の b 進
数 Nℓm −1 Nℓm −2 · · · N1 N0 で表記されるとする．このとき，0 ≤ k ≤ `m − 1 について Nk ∈ {0, 1, . . . , b − 1} であり，N=

Pℓm −1k=0

Nk 2k である．さらに，N のチェックサムを C :=Pℓm −1k=0(b − 1 − Nk ) と定義する．C が `c 桁の b 進数

Nℓm +ℓc −1 Nℓm +ℓc −2 · · · Nℓm +1 Nℓm で表記されるとする．` := `m + `c とする．
■鍵生成アルゴリズム

秘密鍵 (x0 , x1 , . . . , xℓ−1 )，公開鍵 (pub0 , pub1 , . . . , pubℓ−1 ) は以下のように生成される．

1. x0 , x1 , . . . , xℓ−1 ∈ D を無作為に選択する．
2. 0 ≤ k ≤ ` − 1 について pubk := H b−1 (xk ) := H(H(· · · (H (xk )) · · · )) とする．
|
{z}b−1 times■署名アルゴリズム

メッセージのハッシュ値 N の署名 (s0 , s1 , . . . , sℓ−1 ) は以下のように生成される．

1. 0 ≤ k ≤ ` − 1 について sk := H Nk (xk ) とする．
■検証アルゴリズム

メッセージのハッシュ値 N とその署名 (s0 , s1 , . . . , sℓ−1 ) の検証は以下のように行われる．

1. 0 ≤ k ≤ ` − 1 について pubk = H b−1−Nk (sk ) かつそのときに限り，(s0 , s1 , . . . , sℓ−1 ) は N の正しい署名である．
仮にチェックサムが導入されていないとすると，N の署名 s0 , s1 , . . . , sℓm −1 が得られたとき，0 ≤ k ≤ `m − 1 につ′いて Nk′ ≥ Nk を満たす N ′ について，s′k := H Nk −Nk (sk ) によって，署名 (s′0 , s′1 , . . . , s′ℓm −1 ) が容易に偽造できる．

Winternitz one-time signature の偽造不能性は，Dods ら [12] により論じられている．Winternitz one-time signature に基づく方式については，Lafrance と Menezes [24] によりまとめられている．

7.2.2 マークル木を用いた署名方式
1 回署名方式を用いて複数のメッセージに署名を行う場合，メッセージの個数と同じ個数の公開鍵と秘密鍵の組が必要となる．マークル木を用いることにより，このような複数回署名方式の公開鍵の大きさを削減できる [28]．

2h 個のメッセージに署名を行うための 1 回署名の公開鍵を pk0 , pk1 , . . . , pk2h −1 とする．このとき，高さが h，すな
わち，葉の個数が 2h のマークル木は以下のように構成される．高さ j(≥ 0) の左から i(≥ 0) 番目の節点を vi,j と表記

83

する．vi,j は以下のように計算される．

1. 0 ≤ i ≤ 2h − 1 について，vi,0 := H(pki ) とする．
2. 1 ≤ j ≤ h に対し，0 ≤ i ≤ 2h−j − 1 について，vi,j := H(v2i,j−1 kv2i+1,j−1 ) とする．
この署名方式の公開鍵は v0,h である．秘密鍵は 1 回署名の公開鍵 pk0 , pk1 , . . . , pk2h −1 に対応するすべての秘密鍵である．i 個目のメッセージの署名を検証するためには，v0,h を用いて pki が正しいことを検証する必要がある．このために，i 個目のメッセージの署名には，マークル木の vi,0 から v0,h に至る経路上の各節点の，経路上にない子節点が含まれる．これらの節点の列は認証パスと呼ばれる．

7.2.3 マークル木の階層構造による署名方式
前節で述べた一つのマークル木を用いた署名方式では，鍵生成時にすべての 1 回署名の公開鍵と秘密鍵を生成する必要があり，例えば，250 個の署名を行うために高さ 50 のマークル木を構成することは，所要計算時間の観点から非実用的である．このような多数のメッセージに署名を行う際には，マークル木の階層構造による署名方式が提案されている[20]．
この署名方式のマークル木の階層構造の階層数を L とする．この署名方式では，0 ≤ i ≤ L − 1 について，第 i 層のマークル木の高さはすべて等しく hi であると仮定する．このとき，この署名方式は 2
きる．

∑i−1

この署名方式で，0 ≤ i ≤ L − 1 について，第 i 層のマークル木は 2

j=0 hj

∑L−1
i=0

hi

個のメッセージに署名で個存在する．第 0 層（最上層）のマーク

ル木は 1 個であり，その根がこの署名方式の公開鍵となる．したがって，この公開鍵を生成する際には，1 回署名の公開鍵と秘密鍵の組を 2h0 個だけ生成すれば良い．0 ≤ i < L − 1 について，第 i 層の各マークル木は第 (i + 1) 層の 2hi
個のマークル木の根を署名するために使用される．第 (L − 1) 層（最下層）のマークル木は，それぞれ 2hL−1 個のメッ
セージの署名に使用される．
この署名方式では，一つのメッセージの署名の際に，各層についてそれぞれ一つのマークル木を生成しておけば十分である．各メッセージの署名は，そのメッセージに対する最下層のマークル木による署名と，0 ≤ i < L − 1 について，
そのメッセージの署名の際に使用された第 i 層のマークル木による第 (i + 1) 層のマークル木の根の署名からなる．この署名方式について，階層数 L = 3，各階層のマークル木の高さ h0 = h1 = h2 = 3 の模式図を図 7.1 に示す．灰色の節点は認証パスをなす節点である．

7.2.4 プレフィクスとビットマスク
プレフィクスは，ハッシュ関数に基づく署名方式の処理において，すべてのハッシュ関数の計算がそれぞれ異なる入力に対して行われるよう入力に付加される系列である．プレフィクスは，Lighton と Micali [26] により，security

string という名称で，ハッシュ関数に基づく署名方式の安全性をハッシュ関数の第二原像攻撃に対する安全性にタイトに帰着するために導入された．
ビットマスクは，Dahmen ら [9] により，ハッシュ関数に基づく署名方式の安全性をハッシュ関数の第二原像攻撃に対する安全性に帰着するために導入された．ビットマスクは乱数系列であり，ハッシュ関数への入力をランダム化するために，bit ごとの排他的論理和により入力に加えられる．

84

message

図 7.1: マークル木の階層構造による署名方式

7.3 主要な具体的なハッシュ関数に基づく署名方式
本章で取り上げるハッシュ関数に基づく署名方式を表 7.1 に示す．
表 7.1: ハッシュ関数に基づく署名方式
文献

暗号化

鍵交換

eXtended Merkle Signature Scheme (XMSS) [18, 31]
+

署

名
○
○

SPHINCS [1]NIST SP 800-208 [31] は，以下のハッシュ関数に基づく stateful な署名方式を規定している．
• Lighton-Micali Signatures (LMS), Hierarchical Signature System (HSS) [27]• eXtended Merkle Signature Scheme (XMSS), multi-tree XMSS (XMSSM T ) [18]LMS は Lighton と Micali による署名方式 [26] に基づく．HSS, XMSSM T はそれぞれ，7.2.3 節で述べられたような，
LMS, XMSS の階層構造による署名方式である．ハッシュ関数に基づく stateful な署名方式では，同一の秘密鍵が複数のメッセージの署名に使用されることがないように秘密鍵を管理することが必須である．LMS, HSS については，調査報告書で取り上げられている．

SPHINCS+ [1] は 2022 年 7 月に NIST Post Quantum Cryptography Standardization Process で標準化の候補ア
ルゴリズムの一つに選出された．SPHINCS+ はハッシュ関数に基づく stateless な署名方式であり，stateful な方式に求められるような秘密鍵の管理が不要な方式である．SPHINCS+ は SPHINCS [3] の改良版として提案され [4, 5]，その後も NIST Post Quantum Cryptography Standardization Process で改良が行われた．SPHINCS+ は XMSS の設計で得られた知見に基づいて設計されており，XMSSM T とよく似た構造を有することから，以下の SPHINCS+ の85

記述では適宜 XMSS を参照する．

7.3.1 XMSS: eXtended Merkle Signature Scheme
XMSS は [7, 20] で提案された方式の改良版 [21] に基づく署名方式であり，Winternitz one-time signature に基づ
く 1 回署名方式 [17] を用いる．

XMSS では三つの鍵付きハッシュ関数 F, H, Hmsg と擬似ランダム関数 R が用いられる．いずれも出力の Byte 長は等しく，これを n とする．F の入力は Byte 長 n の鍵と Byte 長 n の系列である．H の入力は Byte 長 n の鍵と Byte
長 2n の系列である．Hmsg の入力は Byte 長 3n の鍵と任意 Byte 長の系列である．R の入力は Byte 長 n の鍵と Byte
長 32 の系列である．これらの関数は SHA-2 [13] または SHA-3 [15] を用いて定義される．例えば，n = 32 のとき，

SHA-256 を用いて以下のように定義される．
F(k, x) := SHA-256([0]256 kkkx)
H(k, x) := SHA-256([1]256 kkkx)
Hmsg (k, x) := SHA-256([2]256 kkkx)
R(k, x) := SHA-256([3]256 kkkx)
XMSS では，ハッシュ関数の呼び出しをランダム化するために，それぞれのハッシュ関数の呼び出しで，鍵とビットマスクが用いられる．これらは擬似ランダム関数を用いて生成され，入力として Byte 系列の seed と長さ 32 Bytes のアドレス ADRS が与えられる．アドレスは 3 種あり，それぞれ OTS ハッシュアドレス，L 木アドレス，ハッシュ木ア
ドレスと呼ばれる．それらの構造を図 7.2 に示す．

layer address(32 bits)

layer address(32 bits)

layer address(32 bits)

tree address(64 bits)

tree address(64 bits)

tree address(64 bits)

type = 0(32 bits)

type = 1(32 bits)

type = 2(32 bits)

OTS address(32 bits)

L-tree address(32 bits)

Padding = 0(32 bits)

chain address(32 bits)

tree height(32 bits)

tree height(32 bits)

hash address(32 bits)

tree index(32 bits)

tree index(32 bits)

keyAndMask(32 bits)

keyAndMask(32 bits)

keyAndMask(32 bits)(a) OTS ハッシュアドレス

(b) L 木アドレス(c) ハッシュ木アドレス

図 7.2: アドレスの構造

7.3.1.1 WOTS+
w ∈ {4, 16} は Winternitz パラメータと呼ばれる．` := `1 + `2 は公開鍵，秘密鍵，署名を構成する Byte 長 n の要素の個数を表す．ここで，`1 := d8n/log2 we,`2 := blog2 (`1 (w − 1))/log2 wc + 1

である．

86

■チェイニング関数

チェイニング関数 chain の入力は，長さ nBytes の系列 X ，スタートインデクス i，ステップ数s，長さ 32 Bytes のアドレス ADRS，長さ n Bytes のシード seed であり，以下のように定義される．

s = 0 のとき
X
chain(X, i, s, seed, ADRS) := NULL
i + s ≥ w のときF(Key, chain(X, i, s − 1, seed, ADRS) ⊕ BM ) それ以外のとき
ここで，Key := R(seed, ADRS′ k[i + s − 1]32 k[0]32 ),BM := R(seed, ADRS′ k[i + s − 1]32 k[1]32 )である．なお，ADRS′ は ADRS の上位 24 Bytes であり，例えば，ADRS′ k[i + s − 1]32 k[0]32 は図 7.2a の ADRS のhash address, keyAndMask の値をそれぞれ，[i + s − 1]32 , [0]32 とすることを表している．
■鍵生成アルゴリズム

入力は ADRS, seed である．

1. 0 ≤ i ≤ ` − 1 について，sk i ∈ {0, 1}8n を無作為に選択する．
2. 0 ≤ i ≤ ` − 1 について，ADRS の chain address の値を [i]32 とし，
pk i := chain(sk i , 0, w − 1, seed, ADRS)とする．この計算を図 7.3 に示す．この図でKey j := R(seed, ADRS′ k[j]32 k[0]32 ),BM j := R(seed, ADRS′ k[j]32 k[1]32 )である．
公開鍵は pk := (pk 0 , pk 1 , . . . , pk ℓ−1 ) である．秘密鍵は sk := (sk 0 , sk 1 , . . . , sk ℓ−1 ) である．

図 7.3: pk i の計算■署名アルゴリズム

入力は Byte 長 n のメッセージ M ，秘密鍵 sk ，アドレス ADRS，シード seed である．

1. M をそれぞれ長さ log2 w bits の `1 個のブロックに分割し，先頭から順に M0 , M1 , . . . , Mℓ1 −1 とする．これらを整数とみなすと，0 ≤ i ≤ `1 − 1 について，Mi ∈ {0, 1, . . . , w − 1} である．

2. C :=

Pℓ1 −1i=0(w − 1 − Mi ) とする．

3. C · 28−(ℓ2 log2 w mod 8) を長さ d(`2 log2 w)/8e Bytes の系列とみなし，それぞれ長さ log2 w bits の `2 個のブロックに分割し，先頭から順に Mℓ1 , Mℓ1 +1 , . . . , Mℓ−1 とする．

4. 0 ≤ i ≤ ` − 1 について，ADRS の chain address の値を i とし，
sig i := chain(sk i , 0, Mi , seed, ADRS)とする．
メッセージ M に対する署名は sig 0 , sig 1 , . . . , sig ℓ−1 である．

87

■検証アルゴリズム

7.3.1.2

鍵生成と署名のアルゴリズムより容易に導出されるので，詳細は [18] を参照のこと．

XMSSXMSS はマークル木を用いた署名方式であり，公開鍵と秘密鍵の各組は完全二分木に対応付けられる．
XMSS のハッシュ木の構成のために，ランダム化ハッシュ関数 RH が導入されている．RH の入力は長さ n Bytes のLEFT , RIGHT ，長さ n Bytes のシード seed，長さ 32 Bytes のアドレス ADRS であり，以下のように定義される．
RH(LEFT , RIGHT , seed, ADRS) := H(Key, (LEFT ⊕ BM0 )k(RIGHT ⊕ BM1 ))ここで，

Key := R(seed, ADRS′ k[0]32 ),BM0 := R(seed, ADRS′ k[1]32 ),BM1 := R(seed, ADRS′ k[2]32 )である．なお，ADRS′ は ADRS の上位 28 Bytes であり，例えば，ADRS′ k[0]32 は ADRS の図 7.2 の keyAndMaskの値を [0]32 とすることを表している．
秘密鍵の生成には [7] に示されているような擬似ランダム鍵生成法を用いることが許容されているが，その安全性は少なくとも XMSS の安全性と同等でなければならない．
■鍵生成アルゴリズム 鍵生成アルゴリズムではマークル木が構成され，その各葉には WOTS+ の公開鍵が対応する．

WOTS+ の公開鍵に対して L 木と呼ばれるハッシュ木が構成され，その木の根のハッシュ値が XMSS のマークル木の葉に割り当てられる．L 木の高さ j(≥ 0) の左から i(≥ 0) 番目の節点を Nodei,j と表記する．L 木は以下にしたがって構成される．入力は WOTS+ の公開鍵 pk := (pk 0 , pk 1 , . . . , pk ℓ−1 )，L 木アドレス ADRS，シード seed である．

1. 0 ≤ i ≤ ` − 1 について，Nodei,0 := pk i とする．
2. j ≥ 0 について，根が得られるまで以下にしたがって Nodei,j+1 を計算する．なお，値の定義された Nodei,j の個数を `′ とする．
（a）0 ≤ i < b`′ /2c について，Nodei,j+1 := RH(Node2i,j , Node2i+1,j , seed, ADRS) とする．ここで，ADRSの tree height を [j]32 ，tree index を [i]32 とする．さらに，`′ が奇数のとき，Node⌊ℓ′ /2⌋,j+1 := Nodeℓ′ −1,jとする．
（b）j ← j + 1 とする．
鍵生成アルゴリズムで構成されるマークル木の高さを h とすると，このマークル木には 2h 個の葉が存在する．このマークル木に対応する 2h 個の WOTS+ の公開鍵，それらの L 木，さらに，このマークル木の計算に用いられる OTS
ハッシュアドレス，L 木アドレス，ハッシュ木アドレスの layer address，tree address はすべて，それぞれ [0]32 ，[0]64である．左から k (≥ 0) 番目の葉に対応する OTS ハッシュアドレスの OTS address，L 木アドレスの L-tree address
は [k]32 である．
鍵生成アルゴリズムで構成されるマークル木の葉は対応する L 木の根である．葉以外の節点は L 木の節点と同じ方法で計算される．なお，このマークル木は完全二分木なので，上記の L 木の計算手続きで，`′ は常に偶数となる．
秘密鍵は，2h 個の WOTS+ の秘密鍵，次の署名に使用される WOTS+ の秘密鍵に対応するマークル木の葉の番号

idx ，署名されるメッセージのハッシュの計算に使用される SKPRF ，マークル木の根 root ，seed である．公開鍵は，マークル木の根，seed である．ここで，SKPRF と seed はこの鍵生成アルゴリズムで無作為に選択される長さ n Bytesの系列である．また，公開鍵には識別子 OID が付される．

88

■署名アルゴリズム

メッセージ M の署名は，署名に使用される WOTS+ の秘密鍵の番号 idx ，M のダイジェストの計算に使用される乱数 r，WOTS+ による署名，マークル木の idx 番目の葉の認証パスからなる．

1. M のダイジェストを M ′ := Hmsg (rkrootk[idx ]8n , M ) とする．ここで，r := R(SKPRF , [idx ]32 ) である．
2. WOTS+ の idx 番目の秘密鍵を用いて M ′ に署名し，マークル木の idx 番目の葉の認証パスを計算する．
WOTS+ の同じ秘密鍵が 2 回以上使用されないよう，idx は idx ← idx + 1 により更新される．
■検証アルゴリズム

鍵生成と署名のアルゴリズムより容易に導出されるので，詳細は [18] を参照のこと．

XMSSM T7.3.1.3XMSSM T は，7.2.3 節のマークル木の階層構造による署名方式に相当する．XMSSM T 木はハイパー木と呼ばれ，d層の XMSS 木からなる．ここで，XMSS 木は 7.3.1.2 節の鍵生成アルゴリズムで生成される L 木とマークル木からなる木を表す．第 (d − 1) 層と第 0 層はそれぞれ，XMSSM T 木の根と葉に相当する*1 ．すべての XMSS 木の高さは等
しく，Winternitz パラメータもすべて同じ値が用いられる．第 x 層の左から y 番目の XMSS 木の構成で使用される

OTS ハッシュアドレス，L 木アドレス，ハッシュ木アドレスの layer address と tree address は，それぞれ [x]32 ，[y]32である．

XMSSM T の鍵生成，署名，検証の各アルゴリズムについての詳細は [18] を参照のこと．
7.3.1.4 パラメータの設定と安全性
Kampanakis と Fluhrer [22] により，LMS と XMSS の比較が論じられている．
Hülsing [21] らは，XMSS について安全性証明を与え，適応的選択メッセージ攻撃に対する存在偽造不能性（EUFCMA）を満たすことを鍵付きハッシュ関数 F, H, Hmsg と擬似ランダム関数 R の以下の安全性に帰着している．
• F が以下の性質を満たすこと– multi-function, multi-target second preimage resistance (MM-SPR)– すべての出力が 2 個以上の原像を持つこと• H が MM-SPR を満たすこと• Hmsg が multi-target extended target collision resistance (M-ETCR) を満たすこと• R が擬似ランダム関数 (PRF) であること
ここで，MM-SPR, M-ETCR は，F, H, Hmsg の構成に用いられるハッシュ関数の第二原像攻撃に対する安全性に基づく性質である．一方，PRF は，秘密鍵入力を有するハッシュ関数が擬似ランダム関数であることを要求する．さらに，

R による鍵とビットマスクの生成については，ハッシュ関数がランダムオラクルであることが仮定される．
IRTF RFC 8391 [18] では，上記の結果に基づいて，n = 32, 64 のとき，それぞれ，256 bit 安全性，512 bit 安全性が提供されると記されている．また，量子計算機を用いた攻撃に対してはそれぞれ，128 bit 安全性，256 bit 安全性が提供されると記されている．

IRTF RFC 8391 [18] では，ハッシュ関数として SHA-256 を用いることが要求されているが，オプションとして
SHAKE128/256, SHA-512, SHAKE256/512 を用いることが記されている．一方，NIST SP 800-208 では，SHA-256,
SHA-256/192, SHAKE256/256, SHAKE256/192 を用いることが認可されている．NIST SP 800-208 [31] と IRTF
*1 IRTF RFC 8391 [18] では，各層の番号付けが 7.2.3 節の番号付けとは逆順であり，本稿でもそれに従って記述する．

89

RFC 8391 [18] の両方に掲載されている SHA-256 を用いる場合の WOTS+ , XMSS, XMSSM T のパラメータセットの値の一覧をそれぞれ表 7.2, 7.3, 7.4 に示す．
表 7.2: WOTS+ のパラメータセット

表 7.3: XMSS のパラメータセットと署名長（単位は Byte）

名称

n

w

`

名称

n

w

`

h

署名長

WOTSP-SHA2 256

32

16

67

XMSS-SHA2 10 256

32

16

67

10

2,500

XMSS-SHA2 16 256

32

16

67

16

2,692

XMSS-SHA2 20 256

32

16

67

20

2,820

表 7.4: XMSSM T のパラメータセットと署名長（単位は Byte）
名称

n

w

`

h

d

署名長

XMSSMT-SHA2 20/2 256

32

16

67

20

2

4,963

XMSSMT-SHA2 20/4 256

32

16

67

20

4

9,251

XMSSMT-SHA2 40/2 256

32

16

67

40

2

5,605

XMSSMT-SHA2 40/4 256

32

16

67

40

4

9,893

XMSSMT-SHA2 40/8 256

32

16

67

40

8

18,469XMSSMT-SHA2 60/3 256

32

16

67

60

3

8,392

XMSSMT-SHA2 60/6 256

32

16

67

60

6

14,824XMSSMT-SHA2 60/12 256

32

16

67

60

12

27,6887.3.2 SPHINCS+
SPHINCS+ [1] は 7.2.3 節のマークル木の階層構造による署名方式に基づく方式である．ただし，XMSSM T とは異なり，stateless な署名方式である．

SPHINCS+ では，以下のような，いくつかの tweakable ハッシュ関数 Tℓ ，二つの擬似ランダム関数 PRF, PRFmsg ，一つの鍵付きハッシュ関数 Hmsg が用いられる．

Tℓ : Bn × B32 × Bℓn → Bn

PRF : Bn × B32 → Bn

Hmsg : Bn × Bn × Bn × B∗ → Bm

PRFmsg : Bn × Bn × B∗ → Bn
以下では，T1 , T2 について，F := T1 , H := T2 の表記が用いられる．

SPHINCS+ では，図 7.4 に示す 7 種のアドレスが用いられる．どのアドレスも長さは 32 Bytes である．
7.3.2.1 WOTS+SPHINCS+ でも WOTS+ が用いられているが，XMSS の WOTS+ と以下の点で異なる．
• Winternitz パラメータは w ∈ {4, 16, 256} である．

90

layer address(32 bits)

layer address(32 bits)

layer address(32 bits)

tree address(96 bits)

tree address(96 bits)

tree address(96 bits)

type = 0(32 bits)

type = 1(32 bits)

type = 2(32 bits)

key pair address(32 bits)

key pair address(32 bits)

00 · · · 0(32 bits)

chain address(32 bits)

00 · · · 0(32 bits)

tree height(32 bits)

hash address(32 bits)

00 · · · 0(32 bits)

tree index(32 bits)(a) WOTS+ ハッシュアドレス

(b) WOTS+ 公開鍵圧縮アドレス(c) ハッシュ木アドレス

layer address(32 bits)

layer address(32 bits)

tree address(96 bits)

tree address(96 bits)

type = 3(32 bits)

type = 4(32 bits)

key pair address(32 bits)

key pair address(32 bits)

tree height(32 bits)

00 · · · 0(32 bits)

treen index(32 bits)

00 · · · 0(32 bits)(d) FORS 木アドレス(e) FORS 木根圧縮アドレス

layer address(32 bits)

layer address(32 bits)

tree address(96 bits)

tree address(96 bits)

type = 5(32 bits)

type = 6(32 bits)

key pair address(32 bits)

key pair address(32 bits)

chain address(32 bits)

00 · · · 0(32 bits)

00 · · · 0(32 bits)

tree index(32 bits)(f) WOTS+ 鍵生成アドレス(g) FORS 鍵生成アドレス

図 7.4: アドレスの構造• チェイニング関数は以下のように定義される．
chain(X, i, s, PK.seed, ADRS) :=
s = 0 のとき
X
NULL
i + s ≥ w のとき
′F(PK.seed, ADRS k[i + s − 1]32 , chain(X, i, s − 1, PK.seed, ADRS)) それ以外のとき
なお，ADRS は WOTS+ ハッシュアドレスであり，ADRS′ k[i + s − 1]32 は ADRS の hash address の値を[i + s − 1]32 とすることを表している．
■鍵生成アルゴリズム

入力は SK.seed, PK.seed, WOTS+ ハッシュアドレス ADRS である．

1. 0 ≤ i ≤ ` − 1 について，ADRS の chain address の値を [i]32 ，hash address の値を [0]32 とし，sk i := PRF(SK.seed, skADRS)

pk i := chain(sk i , 0, w − 1, PK.seed, ADRS)とする．なお，skADRS は WOTS+ 鍵生成アドレスであり，layer address, tree address, key pair address,

91

chain addresss については ADRS と同じ値が用いられる．
2. pk := Tℓ (PK.seed, wotspkADRS, pk 0 k · · · kpk ℓ−1 ) とする．ここで，wotspkADRS は WOTS+ 公開鍵圧
縮アドレスであり，layer address, tree address, key pair address については ADRS と同じ値が用いられる．
公開鍵は pk である．秘密鍵は sk := (sk 0 , sk 1 , . . . , sk ℓ−1 ) である．
■署名アルゴリズム

詳細は [1] を参照のこと．

■検証アルゴリズム

詳細は [1] を参照のこと．

7.3.2.2HT

SPHINCS+ では，ハイパー木 HT と呼ばれる XMSSM T と同様の XMSS 木の階層構造が用いられる．HT が d 層の
XMSS 木からなるとき，第 (d − 1) 層と第 0 層はそれぞれ，HT の根と葉に相当する．すべての XMSS 木の高さは等し
く，Winternitz パラメータもすべて同じ値が用いられる．HT の各 XMSS 木の各葉は，7.3.2.1 節の WOTS+ の公開
鍵である．各 XMSS 木の葉以外の節点の計算にはハッシュ関数 H が用いられる．第 x 層の左から y 番目の XMSS 木の構成で使用される WOTS+ ハッシュアドレス，WOTS+ 公開鍵圧縮アドレス，WOTS+ 鍵生成アドレス，ハッシュ
木アドレスの layer address と tree address はそれぞれ [x]32 ，[y]96 である．

HT の鍵生成，署名，検証の各アルゴリズムについての詳細は [1] を参照のこと．
7.3.2.3

FORS (Forest Of Random Subsets)

SPHINCS+ では，メッセージの署名に WOTS+ ではなく，FORS と呼ばれる方式が用いられる．FORS では一組の公開鍵と秘密鍵を用いて複数個のメッセージに署名できる．FORS は，数回（few-time）署名方式 HORS [34] に基づく HORST [3] の改良版である．FORS は k, t := 2a をパラメータとし，長さ ka bits の系列に署名を行う．
■鍵生成アルゴリズム

入力は SK.seed, PK.seed, FORS 木アドレス ADRS である．

1. 0 ≤ i < kt について，
sk i := PRF(SK.seed, skADRS)

Nodei,0 := F(PK.seed, ADRS, sk i )とする．ここで，skADRS は FORS 鍵生成アドレスであり，layer address, tree address, key pair addressについては ADRS と同じ値が用いられ，tree index の値は [i]32 である．また，ADRS の tree index の値は[i]32 である．
2. 1 ≤ j ≤ a について，それぞれ，0 ≤ i < kt/2j について，
Nodei,j := H(PK.seed, ADRS, Node2i,j−1 kNode2i+1,j−1 )とする．ここで，ADRS の tree height の値は [j]32 ，tree index の値は [i]32 である．

3. pk := Tk (PK.seed, forspkADRS, Node0,a k · · · kNodek−1,a ) とする．ここで，forspkADRS は FORS 木
根圧縮アドレスであり，layer address, tree address, key pair address については ADRS と同じ値が用いられる．
このアルゴリズムにより，Node0,a , Node1,a , . . . , Nodek−1,a を根とする k 個のマークル木が構成されている．公開鍵は pk である．秘密鍵は sk 0 , sk 1 , . . . , sk kt−1 である．

92

■署名アルゴリズム 長さ ka bits のメッセージ M をそれぞれ長さ a bits の k 個のブロック M0 , M1 , . . . , Mk−1 に分割する．すなわち，M = M0 kM1 k · · · kMk−1 である．さらに，Mi を 2 進数表記の非負整数とみなす．M の署名は

sk 0·t+M0 , sk 1·t+M1 , . . . , sk (k−1)t+Mk−1 と，0 ≤ i < k について，Nodei,a を根とするマークル木の Nodeit+Mi ,0 の認証パスである．
■検証アルゴリズム

7.3.2.4

詳細は [1] を参照のこと．

SPHINCS+

前節までの構成要素を用いて SPHINCS+ の署名が構成される．SPHINCS+ のパラメータは以下のとおりである．

• セキュリティパラメータ n（単位は Byte）• Winternitz パラメータ w• ハイパー木の高さ h と階層数 d• FORS の木の個数 k と各木の葉の個数 t
メッセージダイジェストの Byte 長は m := b(klog2 t + 7)/8c + b(h − h/d + 7)/8c + b(h/d + 7)/8c となる．
■鍵生成アルゴリズム

SK.seed, SK.prf ∈ Bn はいずれも無作為に選択される．PK.seed ∈ Bn は無作為に選択される．PK.root ∈ Bn は HT の第 (d−1) 層の XMSS 木の根である．秘密鍵は SK.seed, SK.prf, PK.seed, PK.root
である．公開鍵は PK.seed, PK.root である．
■署名アルゴリズム

メッセージ M の署名は以下のように生成される．

1. R := PRFmsg (SK.prf, opt, M ) とする．opt = PK.seed であるが，opt を乱数とするオプションも用意されている．

2. digest := Hmsg (R, PK.seed, PK.root, M ) とする．digest の最初の b(ka + 7)/8c Bytes，次の b(h − h/d +7)/8c Bytes，その次の b(h/d + 7)/8c Bytes をそれぞれ tmp 0 , tmp 1 , tmp 2 とする．さらに，tmp 0 の先頭 ka
bits を md ，tmp 1 の先頭 (h − h/d) bits を idx tree ，tmp 2 の先頭 h/d bits を idx leaf とする．
3. HT の第 0 層の左から idx tree 番目の XMSS 木の左から idx leaf 番目の葉に対応する FORS の鍵を用いて mdの署名を生成する．このとき，FORS の ADRS の layer address は [0]32 ，tree address は idx tree ，key pairaddress は idx leaf である．さらに，tree height, tree index はともに [0]32 である．
4. 上の署名で用いられた FORS の公開鍵への HT による署名を生成する．
M の署名は R，md への FORS による署名，md への署名の検証に用いられる FORS の公開鍵への HT による署名からなる．
■検証アルゴリズム

詳細については [1] を参照のこと．

+

SPHINCS の秘密鍵，公開鍵，署名のサイズはそれぞれ，4n Bytes，2n Bytes，(h + k(log2 t + 1) + d` + 1)n Bytes
である．ここで，` := `1 + `2 であり，`1 := d8n/log2 we, `2 := b(log2 (`1 (w − 1)))/log2 wc + 1 である．

7.3.2.5 パラメータの設定と安全性
Hülsing と Kudinov [19] は，SPHINCS+ が適応的選択メッセージ攻撃に対する存在偽造不能性（EUF-CMA）を満たすことを tweakable ハッシュ関数 Tℓ ，鍵付きハッシュ関数 Hmsg ，擬似ランダム関数 PRF, PRFmsg の以下の安93

全性に帰着している．

• Tℓ が以下の性質を満たすこと– single-function, multi-target collision resistance (SM-TCR)– single-function, multi-target preimage resistance (SM-PRE)– single-function, multi-target decisional second preimage resistance (SM-DSPR)– single-function, multi-target undetectability (SM-UD)• Hmsg が interleaved target subset resilience (ITSR) を満たすこと• PRF, PRFmsg が擬似ランダム関数 (PRF) であること
ここで，SM-TCR, SM-DSPR, ITSR は，Tℓ , Hmsg の構成に用いられるハッシュ関数の第二原像攻撃に対する安全性に基づく性質であり，SM-PRE は原像攻撃に対する安全性に基づく性質である．一方，SM-UD, PRF は，秘密鍵入力を有するハッシュ関数が擬似ランダム関数であることを要求する．さらに，ビットマスクの生成については，ハッシュ関数がランダムオラクルであることが仮定される．

SPHINCS+ については，表 7.5 のパラメータセットが示されている．この表の最左欄のラベルの s と f はそれぞれ，
署名長，計算時間について最適化されたパラメータセットであることを示している．ただし，一方の最適化で他方が非実用的にならないよう配慮されている．また，安全性レベルは NIST Post Quantum Cryptography Standardization

Process の Call for Proposals に記された安全性強度のカテゴリである．なお，Haraka を用いる場合については，表7.5 とは異なり，n = 24, 32 のときの安全性はレベル 2 とされており，したがって，bit 安全性はおよそ 128 程度となる．Haraka の安全性について，Haraka-512 が（第二）原像攻撃に対して 256 bit 安全性を有しないことが示されている [2] が，これは Haraka を用いた SPHINCS+ の安全性がレベル 2 であることを否定するものではない．
表 7.5: SPHINCS+ のパラメータセットの例．署名長の単位は Byte である．
名称

n

h

d

log2 tkw

bit 安全性

+

16

63

7

12

14

16

+

16

66

22

6

33

+

24

63

7

14

+

24

66

22

+

32

64

+

32

68

SPHINCS -128s
SPHINCS -128f
SPHINCS -192s
SPHINCS -192f
SPHINCS -256s
SPHINCS -256f

安全性レベル

署名長

133

レベル 1

7,856

16

128

レベル 1

17,088

17

16

193

レベル 3

16,224

8

33

16

194

レベル 3

35,664

8

14

22

16

255

レベル 5

29,792

17

9

35

16

255

レベル 5

49,856

7.3.2.6 ハッシュ関数の実現法
SPHINCS+ のハッシュ関数はすべて，SHAKE256，SHA-2，Haraka のうちのいずれかを用いて定義される．なお，
tweakable ハッシュ関数については robust と simple の二つの実現が示されている．robust な実現では 7.2.4 節で述べられたビットマスクが用いられるが，simple な実現では用いられない．

SHA-2 を用いた実現では，当初は SHA-256 のみが用いられていたが，SHA-256 を用いた実現では安全性のレベル
5 が達成できないことを示す攻撃 [32] が示されたため，n = 24, 32 については，一部の関数が SHA-512 を用いて実現されることとなった．

94

SHAKE256 を用いた構成は以下のとおりである．
Hmsg (R, PK.seed, PK.root, M ) := SHAKE256(RkPK.seedkPK.rootkM, 8m)
PRF(PK.seed, SK.seed, ADRS) := SHAKE256(PK.seedkADRSkSK.seed, 8n)
PRFmsg (SK.prf, OptRand, M ) := SHAKE256(SK.prfkOptRandkM, 8n)robust な実現ではF(PK.seed, ADRS, M1 ) := SHAKE256(PK.seedkADRSkM1⊕ , 8n)H(PK.seed, ADRS, M1 kM2 ) := SHAKE256(PK.seedkADRSkM1⊕ kM2⊕ , 8n)
Tℓ (PK.seed, ADRS, M ) := SHAKE256(PK.seedkADRSkM ⊕ , 8n)
simple な実現ではF(PK.seed, ADRS, M1 ) := SHAKE256(PK.seedkADRSkM1 , 8n)H(PK.seed, ADRS, M1 kM2 ) := SHAKE256(PK.seedkADRSkM1 kM2 , 8n)
Tℓ (PK.seed, ADRS, M ) := SHAKE256(PK.seedkADRSkM, 8n)である．ここで，M ∈ {0, 1}l のとき，M ⊕ := M ⊕ SHAKE256(PK.seedkADRS, l) である．

7.4 ハッシュ関数に基づく署名技術に関するまとめ
本章では，ハッシュ関数に基づく署名技術として，XMSS, SPHINCS+ を取り上げた．これらはいずれも 7.2 節で述べた代表的なハッシュ関数に基づく署名方式に基づく構造を有する．XMSS [18] は NIST の推奨アルゴリズムであり [31]，SPHINCS+ [1] は NIST Post Quantum Cryptography Standardization Process で標準化の候補アルゴリズ
ムの一つに選出された．
ハッシュ関数に基づく署名技術の安全性はハッシュ関数の第二原像攻撃に対する安全性に依存しているが，XMSS,SPHINCS+ については，秘密鍵入力を有するハッシュ関数が擬似ランダム関数であることにも依存する．さらに，
ビットマスクの生成についてはハッシュ関数がランダムオラクルであることが仮定される．また，偽造攻撃の計算量
は，ハッシュ関数がランダムオラクルであることを仮定して見積もられている．
ハッシュ関数に基づく署名技術については，stateful であること，すなわち，各メッセージの署名に用いられる 1 回
署名の秘密鍵を 2 回以上使用することのないよう管理しなければならないことが問題であった．XMSS は stateful な
署名方式であるが，それを推奨アルゴリズムとする NIST SP 800-208 [31] には，ハッシュ関数に基づく stateful な署
名方式は一般的な使用には適するものでなく，近い将来に実装が必要であり，その実装が長期間の使用を予定されており，かつ，使用開始後に他の署名方式への移行が実用的でないような応用での使用が意図されていると述べられている．

SPHINCS+ は XMSS の設計で得られた知見に基づいて設計されており，XMSSM T と同様の構造を有するが，各メッセージの署名に一つの秘密鍵で数回署名可能な FORS を用いることによって署名可能な回数を増加させることにより，stateless であることを達成している．

95

第 7 章の参照文献[1] J.-P. Aumasson, D. J. Bernstein, W. Beullens, C. Dobraunig, M. Eichlseder, S. Fluhrer, S.-L. Gazdag,
A. Hülsing, P. Kampanakis, S. Kölbl, T. Lange, M. M. Lauridsen, F. Mendel, R. Niederhagen, C. Rechberger,
J. Rijneveld, P. Schwabe, and B. Westerbaan. SPHINCS+ . Submission to the NIST post-quantum project,v.3.1, 2022. https://sphincs.org/resources.html.
[2] Z. Bao, X. Dong, J. Guo, Z. Li, D. Shi, S. Sun, and X. Wang. Automatic search of meet-in-the-middle
preimage attacks on AES-like hashing. In A. Canteaut and F. Standaert, editors, EUROCRYPT 2021,
Proceedings, Part I, volume 12696 of Lecture Notes in Computer Science, pages 771–804. Springer, 2021.
[3] D. J. Bernstein, D. Hopwood, A. Hülsing, T. Lange, R. Niederhagen, L. Papachristodoulou, M. Schneider,P. Schwabe, and Z. Wilcox-O’Hearn. SPHINCS: practical stateless hash-based signatures. In E. Oswald and
M. Fischlin, editors, EUROCRYPT 2015, Proceedings, Part I, volume 9056 of Lecture Notes in Computer
Science, pages 368–397. Springer, 2015.
[4] D. J. Bernstein, A. Hülsing, S. Kölbl, R. Niederhagen, J. Rijneveld, and P. Schwabe. The SPHINCS+
signature framework. Cryptology ePrint Archive, Report 2019/1086, 2019. https://ia.cr/2019/1086.
[5] D. J. Bernstein, A. Hülsing, S. Kölbl, R. Niederhagen, J. Rijneveld, and P. Schwabe. The SPHINCS+
signature framework. In L. Cavallaro, J. Kinder, X. Wang, and J. Katz, editors, Proceedings of the 2019
ACM SIGSAC Conference on Computer and Communications Security, CCS 2019, pages 2129–2146. ACM,
2019.
[6] G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche. Sponge functions. ECRYPT Hash Workshop, 2007.
[7] J. Buchmann, E. Dahmen, and A. Hülsing. XMSS - A practical forward secure signature scheme based onminimal security assumptions. In B. Yang, editor, PQCrypto 2011, Proceedings, volume 7071 of Lecture
Notes in Computer Science, pages 117–129. Springer, 2011.
[8] J. Daemen and V. Rijmen. The Design of Rijndael: AES - The Advanced Encryption Standard. Information
Security and Cryptography. Springer, 2002.
[9] E. Dahmen, K. Okeya, T. Takagi, and C. Vuillaume. Digital signatures out of second-preimage resistanthash functions. In J. Buchmann and J. Ding, editors, PQCrypto 2008, Proceedings, volume 5299 of Lecture
Notes in Computer Science, pages 109–123. Springer, 2008.
[10] I. Damgård. A design principle for hash functions. In G. Brassard, editor, CRYPTO ’89, Proceedings, volume
435 of Lecture Notes in Computer Science, pages 416–427. Springer, 1989.
[11] W. Diﬃe and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory,
IT-22(6):644–654, 1976.
[12] C. Dods, N. P. Smart, and M. Stam. Hash based digital signature schemes. In N. P. Smart, editor,

96

Cryptography and Coding, 10th IMA International Conference, Proceedings, volume 3796 of Lecture Notes
in Computer Science, pages 96–115. Springer, 2005.
[13] FIPS PUB 180-4. Secure hash standard (SHS), Aug. 2015.
[14] FIPS PUB 197. Advanced encryption standard (AES), 2001.
[15] FIPS PUB 202. SHA-3 standard: Permutation-based hash and extendable-output functions, 2015.
[16] L. K. Grover. A fast quantum mechanical algorithm for database search. In G. L. Miller, editor, Proceedingsof the Twenty-Eighth Annual ACM Symposium on the Theory of Computing, pages 212–219. ACM, 1996.
[17] A. Hülsing. W-OTS+ - shorter signatures for hash-based signature schemes. In A. M. Youssef, A. Nitaj, andA. E. Hassanien, editors, AFRICACRYPT 2013, Proceedings, volume 7918 of Lecture Notes in Computer
Science, pages 173–188. Springer, 2013.
[18] A. Hülsing, D. Butin, S. Gazdag, J. Rijneveld, and A. Mohaisen. XMSS: eXtended Merkle Signature Scheme.
IRTF RFC 8391, 2018.
[19] A. Hülsing and M. Kudinov. Recovering the tight security proof of SPHINCS+ . Cryptology ePrint Archive,
Paper 2022/346, 2022. https://eprint.iacr.org/2022/346.
[20] A. Hülsing, L. Rausch, and J. Buchmann. Optimal parameters for XMSSM T . In A. Cuzzocrea, C. Kittl,
D. E. Simos, E. R. Weippl, and L. Xu, editors, Security Engineering and Intelligence Informatics - CD-ARES
2013 Workshops: MoCrySEn and SeCIHD, Proceedings, volume 8128 of Lecture Notes in Computer Science,
pages 194–208. Springer, 2013.
[21] A. Hülsing, J. Rijneveld, and F. Song. Mitigating multi-target attacks in hash-based signatures. In C. Cheng,
K. Chung, G. Persiano, and B. Yang, editors, PKC 2016, Proceedings, Part I, volume 9614 of Lecture Notes
in Computer Science, pages 387–416. Springer, 2016.
[22] P. Kampanakis and S. Fluhrer. LMS vs XMSS: Comparion of two hash-based signature standards. Cryptology
ePrint Archive, Paper 2017/349, 2017. https://eprint.iacr.org/2017/349.
[23] S. Kölbl, M. M. Lauridsen, F. Mendel, and C. Rechberger. Haraka v2 - eﬃcient short-input hashing forpost-quantum applications. IACR Trans. Symmetric Cryptol., 2016(2):1–29, 2016.
[24] P. Lafrance and A. Menezes. On the security of the WOTS-PRF signature scheme. Advances in Mathematics
of Communications, 13(1):185–193, 2019.
[25] L. Lamport. Constructing digital signatures from a one-way function. Technical Report CSL-98, SRI
International, 1979.
[26] F. T. Leighton and S. Micali. Large provably fast and secure digital signature schemes based on secure hashfunctions. US Patent 5,432,852, 1995.
[27] D. A. McGrew, M. Curcio, and S. R. Fluhrer. Leighton-Micali hash-based signatures. IRTF RFC 8554,
2019.
[28] R. C. Merkle. Secrecy, Authentication, and Public Key Systems. PhD thesis, Stanford University, 1979.
https://www.merkle.com/papers/Thesis1979.pdf.
[29] R. C. Merkle. A certiﬁed digital signature. In G. Brassard, editor, CRYPTO ’89, Proceedings, volume 435
of Lecture Notes in Computer Science, pages 218–238. Springer, 1989.
[30] R. C. Merkle. One way hash functions and DES. In G. Brassard, editor, CRYPTO ’89, Proceedings, volume
435 of Lecture Notes in Computer Science, pages 428–446. Springer, 1989.
[31] NIST Special Publication 800-208. Recommendation for stateful hash-based signature schemes, 2020.
97

[32] R. A. Perlner, J. Kelsey, and D. A. Cooper. Breaking category ﬁve SPHINCS+ with SHA-256. In J. H.
Cheon and T. Johansson, editors, PQCrypto 2022, Proceedings, volume 13512 of Lecture Notes in Computer
Science, pages 501–522. Springer, 2022.
[33] J. Quisquater and M. Girault. 2n-bit hash-functions using n-bit symmetric block cipher algorithms. In
J. Quisquater and J. Vandewalle, editors, EUROCRYPT ’89, Proceedings, volume 434 of Lecture Notes in
Computer Science, pages 102–109. Springer, 1989.
[34] L. Reyzin and N. Reyzin. Better than BiBa: Short one-time signatures with fast signing and verifying. In
L. M. Batten and J. Seberry, editors, ACISP 2002, Proceedings, volume 2384 of Lecture Notes in Computer
Science, pages 144–153. Springer, 2002.

98

CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）[CRYPTREC GL-2004-2023]
不許複製

禁無断転載

発行日：2023 年 3 月 31 日（第１版）
発行者
・ 〒184-8795
東京都小金井市貫井北町四丁目２番１号
国立研究開発法人

情報通信研究機構（サイバーセキュリティ研究所

セキュリティ基盤研究室）

NATIONAL INSTITUTE OF INFORMATION AND COMMUNICATIONS TECHNOLOGY
4-2-1 NUKUI-KITAMACHI, KOGANEITOKYO, 184-8795 JAPAN・ 〒113-6591
東京都文京区本駒込二丁目２８番８号
独立行政法人情報処理推進機構(技術本部 セキュリティセンター 暗号グループ）
INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN
2-28-8 HONKOMAGOME, BUNKYO-KU
TOKYO, 113-6591 JAPAN99

資料３ー６2022 年度暗号技術調査ＷＧ（高機能暗号）活動報告
1. 暗号技術調査ＷＧ（高機能暗号ＷＧ）の活動目的
高機能暗号の研究動向調査をもとに、高機能暗号ガイドラインを 2021 年度、2022 年度において作成する。

2. 委員構成（敬称略）
主査

四方 順司

横浜国立大学 教授

委員

岩本 貢

電気通信大学 教授

委員

大原 一真

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

委員

勝又 秀一

PQShield委員

金岡 晃

東邦大学 准教授

委員

川原 祐人

日本電信電話株式会社 主任研究員

委員

国井 裕樹

セコム株式会社 グループリーダー

委員

須賀 祐治

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

委員

鈴木 幸太郎豊橋技術科学大学 教授

委員

花岡 悟一郎

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

委員

濱田 浩気

日本電信電話株式会社 主任研究員

委員

外園 康智

野村総合研究所 上級研究員

委員

山田 翔太

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

委員

米山 一樹

茨城大学 教授委員

渡邉 洋平

電気通信大学 助教

Lead Cryptography Researcher

3. 2022 年度暗号技術調査ＷＧ（高機能暗号）活動報告の概要
3.1. 背景
公開鍵暗号は、アプリケーションが多様となりその活用が広まっている。その中で、従来の公開鍵暗号よりも機能が向上した高機能暗号を利用してアプリケーションに適用することが有効と考えられている。そこで、2020 年度第 2 回暗号技術検討会において高機能暗号ガイドラインを作成するために高機能暗号ＷＧを設置することが承認された。

3.2. 2021 年度活動概要
検討会により高機能暗号ＷＧを設置することが承認されたことをうけ、2021 年度より高機能暗号ＷＧが設置され、2021 年 7 月 6 日に開催された 2021 年度第 1 回暗号技術評価委員会において、2021 年度の高機能暗号ＷＧの活動として下記 4 点について実施する活動計画が承認された。
(1) 2021-2022 年度において高機能暗号ガイドラインを作成すること(2) 高機能暗号のスコープの明確化(3) 高機能暗号技術に関する現状調査

(4) 高機能暗号のアプリケーションに関する調査
この活動計画に沿い、2021 年 8 月 3 日に第 1 回 WG、2021 年 12 月 8 日に第 2 回 WG、2022 年 2 月
8 日に第 3 回 WG の年 3 回の高機能暗号ＷＧを開催した。これらの活動によりガイドラインに記載
する高機能暗号、および、目次案が決定された。その概要については、2022 年 2 月 22 日に開催された 2021 年度第 2 回暗号技術評価委員会において報告した。
① 第 1 回高機能暗号ＷＧ（2021 年 8 月 3 日）(ア)

高機能暗号のスコープの議論(イ)

高機能暗号技術に関する現状調査について作業方針・分担を議論(ウ)

高機能暗号のアプリケーションに関する現状調査について作業方針・分担を議論(エ)

高機能暗号のアプリケーションについて、エンドユーザのヒアリング先の検討② 第 2 回高機能暗号ＷＧ（2021 年 12 月 8 日）
(ア)

現状調査・アプリケーションに関する中間報告(イ)

ヒアリングに関する中間報告(ウ)

ガイドラインの目次案についての議論③ 第 3 回高機能暗号ＷＧ（2022 年 2 月 8 日）
(ア)2021 年度高機能暗号ＷＧ報告資料の確認(イ)

2021 年度調査内容の確認(ウ)

ガイドラインの執筆方針に関する確認(エ)2022 年度の検討項目の抽出および方針決定

3.3. 2022 年度活動計画概要
2022 年 4 月に行われた暗号技術評価委員会のメール審議により、2022 年度の高機能暗号ＷＧの活動として下記２点について実施する活動計画が承認された。
(1) 2021 年度の作成した目次案に沿ったガイドラインの案の執筆(2) 高機能暗号のアプリケーションに関するヒアリング調査および調査内容のガイドラインの案への反映また、高機能暗号が多岐にわたることがあり、新たに 8 名の委員がＷＧの委員として高木委員長
より指名された。

3.4. 2022 年度活動概要
2022 年度活動計画に沿い、年 3 回の高機能暗号ＷＧを開催した。
(1) 第 1 回高機能暗号ＷＧ（2022 年 6 月 15 日）(ア)

高機能暗号の技術内容に関する執筆分担の議論(イ)

高機能暗号のアプリケーションについて、ＮＥＣ様へのヒアリング(2) 第 2 回高機能暗号ＷＧ（2022 年 11 月 9 日）
(ア)ガイドラインの案の執筆状況の中間報告および内容確認・議論(イ)

高機能暗号のアプリケーションについて三菱電機様へのヒアリング(3) 第 3 回高機能暗号ＷＧ（2023 年 2 月 10 日）(ア)

高機能暗号ガイドラインの案の内容の最終確認

第 3 回 WG でのコメント修正版を 2 月 17 日に完成し、WG でのガイドラインの案の完成版とした。

4. 高機能暗号ガイドラインの案の執筆
2021 年度の WG の活動により、高機能暗号を“守秘”、“認証・署名”、“その他”（表１の第 1
列参照）に分類した。そして、ガイドラインに記載すべき高機能暗号の対象を守秘：ID ベース暗号、属性ベース暗号、放送型暗号、準同型暗号、プロキシ再暗号化

認証・署名：ID ベース署名、集約署名・MAC・マルチ署名、グループ署名、リング署名、しきい値署名
その他：秘密分散、マルチパーティ計算－秘密分散ベース、マルチパーティ計算－Garbled
Circuit ベース、ゼロ知識証明、検索可能暗号、Private Information Retrieval、ObliviousRAMの１７項目として、執筆を分担した。執筆分担を表１に示す。
表１

作業（執筆）分担表（敬称略）（各章のタイトルは略称）

章

章タイトル

2.1
2.2
2.3
2.4

2.4.1

はじめに
高機能暗号とはどこに使えるか、その有用性
種類と分類
守秘関連の活用事例と標準化

2.4.2

認証・署名関連の活用事例

2.4.3

その他の活用事例

2.4.4
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7

活用事例からみた利用方法
ID ベース暗号
属性ベース暗号
放送型暗号
準同型暗号
プロキシ再暗号化
属性ベース署名
集約署名／MAC、マルチ署名
グループ署名
リング署名
閾値署名
秘密分散
MPC-秘密分散ベース
MPC-Garbled Circuit ベース
ゼロ知識証明Oblivious RAM
PIR
検索可能暗号
おわりに

第1章

第2章

3.1

3.2

第3章
3.3

第4章

執筆担当
四方、事務局
四方、事務局
四方、事務局
四方、事務局
四方、金岡、国井、花岡、
外園、米山、事務局
四方、国井、須賀、米山、
事務局
金岡、国井、須賀、花岡、
外園、米山、事務局
外園、事務局
金岡、渡邉、四方川原、山田、四方
山田、花岡
山田、四方
花岡、勝又
勝又、四方
勝又、花岡、四方
米山、鈴木
鈴木、米山
国井、米山
花岡、大原、岩本
濱田、大原、花岡
大原、花岡
外園、川原
米山、濱田
岩本、須賀
渡邉、米山、岩本四方、事務局

5. 高機能暗号のアプリケーションに関するヒアリング調査
ＮＥＣ様と三菱電機様にＷＧに参加していただき、ヒアリングを実施した。ヒアリング内容については、ガイドラインの案の“2.4.4 章活用事例から見た高機能暗号の利用方法”に反映させた。
5.1. ＮＥＣ様ヒアリング（2022 年 6 月 15 日）
個々のデータのプライバシを強化するために、秘密計算を利用する事例、ゲノム解析、創薬等の報告をいただき、質疑を行った。
5.2. 三菱電機様ヒアリング（2022 年 11 月 9 日）
企業が持つデータベースのデータを共有するにあたり、パブリッククラウドを使用してコストを削減しつつ、不要なデータが他企業に渡る（漏洩する）ことを防ぐために、検索可能暗号や属性ベース暗号を利用する事例、組織内文書管理、委託作業等の報告をいただき、質疑を行った。

6. 今後の予定（ガイドライン発行に向けた手順）
ＷＧで作成したガイドラインの案を本日の資料３－７別紙として配布。
2023 年 3 月 31 日までに第 1 版高機能暗号ガイドラインを完成させ、四月上旬に CRYPTREC ホー
ムページで公開する。
以上

資料３－７CRYPTREC 暗号技術ガイドライン（高機能暗号）
CRYPTREC 暗号技術調査ワーキンググループ（高機能暗号）

2023 年 3 月

表1

CRYPTREC 高機能暗号 WG 委員構成

主査

四方 順司

横浜国立大学委員

岩本 貢

電気通信大学委員

大原 一真

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

委員

勝又 秀一

ＰＱＳｈｉ e ｌｄ

委員

金岡 晃

東邦大学

委員

川原 祐人

日本電信電話株式会社

委員

国井 裕樹

セコム株式会社委員

須賀 祐治

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

委員鈴木 幸太郎豊橋技術科学大学委員

花岡 悟一郎

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

委員

濱田 浩気

日本電信電話株式会社

委員

外園 康智

株式会社野村総合研究所

委員

山田 翔太

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

委員

米山 一樹

茨城大学

委員

渡邉 洋平

電気通信大学

Ｌｔｄ．／国立研究開発法人産業技術総合研究所

目次
第1章

はじめに

4

第2章

高機能暗号技術とその活用法

7
8
8
8
9
10
10
12
17
21
28
37

2.1
2.2

高機能暗号とは . . . . . . . . . . . . . . . . . . . . . . . . . . .
高機能暗号はどこに使えるか、その有用性 . . . . . . . . . . . .

CRYPTREC 暗号リストの暗号方式との違い . . . . . .
高機能暗号の有用性 . . . . . . . . . . . . . . . . . . . .
高機能暗号の種類と分類 . . . . . . . . . . . . . . . . . . . . . .
高機能暗号の活用例と標準化動向 . . . . . . . . . . . . . . . . .
2.4.1 守秘関連の活用事例と標準化動向 . . . . . . . . . . . . .
2.4.2 認証・署名関連の活用事例と標準化動向 . . . . . . . . .
2.4.3 その他の高機能暗号の活用事例と標準化動向 . . . . . . .
2.4.4 活用事例からみた高機能暗号の利用方法 . . . . . . . . .
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
2.2.2

2.3
2.4

第3章

3.1

主な高機能暗号技術のアルゴリズム・プロトコルとその性能
守秘を目的とした高機能暗号技術 . . . . . . . . . . . . . . . . .

3.1.1
3.1.2
3.1.3
3.1.4
3.1.5

ＩＤベース暗号 . . . . . . . . . . . . . . . . . . . . . .
属性ベース暗号 . . . . . . . . . . . . . . . . . . . . . .
放送型暗号 . . . . . . . . . . . . . . . . . . . . . . . . .
準同型暗号 . . . . . . . . . . . . . . . . . . . . . . . . .
プロキシ再暗号化 . . . . . . . . . . . . . . . . . . . . .

参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

認証・署名を目的とした高機能暗号技術 . . . . . . . . . . . . .

3.2.1
3.2.2
3.2.3

属性ベース署名 . . . . . . . . . . . . . . . . . . . . . .
集約 MAC、マルチ MAC、集約署名、マルチ署名 . . . .
グループ署名 . . . . . . . . . . . . . . . . . . . . . . . .

2

46
47
47
49
53
55
58
60
65
65
67
70

3.2.4
3.2.5

リング署名 . . . . . . . . . . . . . . . . . . . . . . . . .

Oblivious Random Access Machine（ORAM） . . . . .
Private Information Retrieval（PIR） . . . . . . . . . .
検索可能暗号 . . . . . . . . . . . . . . . . . . . . . . . .
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73
76
79
84
84
87
90
94
99
101
105
108

おわりに

116

しきい値署名 . . . . . . . . . . . . . . . . . . . . . . . .

参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

その他の高機能暗号技術 . . . . . . . . . . . . . . . . . . . . . .

3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7

第4章

秘密分散 . . . . . . . . . . . . . . . . . . . . . . . . . .
マルチパーティ計算–秘密分散ベース– . . . . . . . . . .
マルチパーティ計算–Garbled Circuit ベース– . . . . . .
ゼロ知識証明 . . . . . . . . . . . . . . . . . . . . . . . .

3

第1章

はじめに
ネットワークの高速化、広帯域化、さらには、すさまじい勢いでのコンピュータの高性能化に伴い、サイバー空間とフィジカル空間が融合したいわゆる Society5.0の世界が現実的なものになりつつある。特に、クラウドサービスの充実、人工知能（Artiﬁcial Intelligence，AI）技術の進歩等もあいまって、多くの分野でオンラ
インサービスの需要が高まっている。また、暗号資産の出現により、経済も変化しつつある。さらに、2020 年に訪れたコロナ禍においては、すべての対応をオンライン化しなければならない状況が生じ、在宅勤務を含むリモートワークや、リ
モート会議等のオンラインサービス、それに伴う技術が著しく進歩し、いわゆるニューノーマルな社会を実現するための環境作りが進んできた。
以前より、これらの技術の進歩、社会の変化に伴った現状のサービスの改善や、将来のサービス変化を見越して、既存の暗号技術よりも効率的で高機能な方式の研究開発が進められている。従来技術より、低コスト、高機能の特徴をもつ「高機能暗号」は、ゲノムのような重要な個人情報を扱う医療データの活用、AI 用の
秘密計算、DB の秘匿検索をはじめとするさまざまな用途での利用が期待されている。しかし、どの高機能暗号を選べばよいのか、選ばれた高機能暗号方式は従来の暗号方式よりもどのような点で優れているのか、運用時にはどのようなことに注意することが必要か等、実際に利用する際には専門家以外では、判断基準がわからず、実運用の判断に困難な場合も多い。

CRYPTREC では、主として電子政府で利用する暗号技術について検討を行っているが、それに加えて、今後さまざまな領域で利用が想定される暗号技術について技術調査を行い、社会に役立つ形で情報提供を行うことを目指している。特に、高機能暗号技術が求められる製品やサービスにおいて、利用者が適切な暗号方式を選択でき、容易に調達できることを目指し、2021 年度より CRYPTREC 暗号技術評価委員会の下に、“暗号技術調査ワーキンググループ（高機能暗号）”（以下、4高機能暗号 WG）が設置された。本ガイドラインは、高機能暗号の方式を選択・利用する際の技術的判断に資すること、今後の利用促進を図ることを目的として、高機能暗号 WG が作成したものである。主たる読者として、セキュリティ技術の標
準化等を目指すコンソーシアムや団体、情報システムのセキュリティ機能の設計・開発・実装において暗号技術を活用する技術者や、セキュリティ機能を搭載した
情報システムの導入を推進する企業等を想定しているが、高機能暗号技術に興味を持つ方に広く読んで頂ければ幸いである。

1 章は、本ガイドラインの総説である。2 章では、高機能暗号の概説をまとめている。まず、対象とする高機能暗号と、その活用例を示し、その上で、高機能暗号を実際に活用する際の手引きを示している。特に、高機能暗号の特徴、代表的なユースケース、方式の選択方法等を記載している。3 章では、代表的な高機能暗号のアルゴリズムと性能等を示している。多くの高機能暗号方式が提案されている
中、優位な特徴がある方式を取り上げ、アルゴリズムを紹介するとともに、その優位性を示している。
本ガイドラインを読むにあたり、どのような暗号があるかを知りたい読者は、第

1 章、第 2 章までを読み、より暗号技術の詳細内容まで知りたい読者は、第 3 章まで読むことをお勧めする。
本ガイドラインで紹介している高機能暗号技術は、執筆時点までに、主要国際学会で発表されており、有力な攻撃法が発見されておらず、かつ、十分な性能を持つと考えられる方式を選んでいる。このため、本ガイドラインで紹介する高機能
暗号は、CRYPTREC 暗号リストの暗号方式とは異なり、CRYPTREC において安全性評価を行った方式ではなく、国際会議等の発表により脆弱性が発見されていないことを安全性の根拠としている。そして、可能な限り最新の情報に基づき安全性や、性能比較、標準化動向等を紹介している。しかしながら、高機能暗号の研究開発は今まさに盛んに行われており、年々新たな方式や評価結果が出ている
ところであり、記載内容が執筆時点のものであることに留意いただきたい。また、本ガイドラインで紹介する高機能暗号は、その機能の優位な特徴を明確に示す暗号を掲載している。このため、アプリケーションに本ガイドラインに記載されている暗号方式を実装することで、その暗号方式が有する優位な特徴を利用することはできるものの、必ずしもそのアプリケーションにとって最適な方式とは限らないケースもある。この場合、最適な方式を選択するためには、暗号方式の詳細を理解し、改良したり、別の暗号方式を利用する等の検討が必要となることがある
ことをご留意いただきたい。
本ガイドラインは表 1.1 に示す高機能暗号 WG 委員および CRYPTTREC 事務5

局で執筆・編集を行った。所属は、WG 委員、事務局を担当した期間におけるものである。また、本ガイドラインを作成する上で、活用事例からみた高機能暗号の利用方法において、日本電気株式会社の横田治樹氏、藤井了氏、三菱電機株式会社の平野貴人氏、川合豊氏、反町亨氏、早坂健一郎氏に多くの有益な情報をご提供いただいた。
表 1.1

高機能暗号ガイドライン執筆者リスト

主査

四方 順司

横浜国立大学委員

岩本 貢

電気通信大学委員

大原 一真

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

委員

勝又 秀一

PQShield Ltd. ／国立研究開発法人産業技術総合研究所

委員

金岡 晃

東邦大学

委員

川原 祐人

日本電信電話株式会社

委員

国井 裕樹

セコム株式会社委員

須賀 祐治

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

委員鈴木 幸太郎豊橋技術科学大学委員

花岡 悟一郎

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

委員

濱田 浩気

日本電信電話株式会社

委員

外園 康智

株式会社野村総合研究所

委員

山田 翔太

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

委員

米山 一樹

茨城大学

委員

渡邉 洋平

電気通信大学事務局

野島 良

国立研究開発法人情報通信研究機構

事務局

青野 良範

国立研究開発法人情報通信研究機構

事務局

伊藤 竜馬

国立研究開発法人情報通信研究機構

事務局

大久保 美也子

国立研究開発法人情報通信研究機構

事務局

金森 祥子

国立研究開発法人情報通信研究機構

事務局

黒川 貴司

国立研究開発法人情報通信研究機構

事務局

篠原 直行

国立研究開発法人情報通信研究機構

事務局

吉田 真紀

国立研究開発法人情報通信研究機構

事務局

小川 一人

国立研究開発法人情報通信研究機構

6

第2章

高機能暗号技術とその活用法

7

2.1 高機能暗号とは
近年、従来の守秘、認証、署名の機能だけではなく、様々な機能を持つ「高機能暗号」（Advanced Cryptography）の研究開発が進んでおり、学会等で提案されている。高機能暗号は日本が強みを持つ分野であり、日本での研究開発が盛んである。そして、日本発の高機能暗号が、多くの著名な国際会議で発表されている。
また、ISO/IEC 等において標準化が進められている高機能暗号技術もある。
様々な機能を有する高機能暗号技術は、今後の発展が予想される 5G および

Beyond5G の社会における種々のサービスで利用できる可能性があり、Internet ofThings（IoT）や AI にとどまらず、Society5.0 における基盤となる Cyber Phisical
System（CPS）といった次世代のネットワークサービスを構築する上でも有効な
セキュリティ技術の一つとなることが期待されている。
一方で、これまで提案されてきた高機能暗号技術には、様々な機能を有する方式が存在する。機能に応じて、それぞれ暗号技術が発展しており、それらを一つの指標で比較することは困難である。このため、国際的に「高機能暗号」に対して一般的に合意されている定義はない。ただし、ガイドラインを読み進めるにあたり、高機能暗号を定義しておくことは読者の理解の支えになると考えられる。以上の状況を鑑み、本ガイドラインでは、「従来の暗号技術に対して、機能が追加・向上される等の優位性を主張する暗号技
術、および、従来の暗号技術では困難であった事象を解決できる等の新規機能を有することを主張する暗号技術」
をスコープとし、従来の暗号技術に対して、なんらかの機能・性能で優位性（高機能性）を持つ暗号技術を高機能暗号における主な対象とする。ここで述べた従来の暗号技術とは、CRYPTREC 暗号リスト [1] に挙げられているような暗号基礎技術を指す。そして、この高機能性については、各項目において明示することにする。

2.2 高機能暗号はどこに使えるか、その有用性
2.2.1 CRYPTREC 暗号リストの暗号方式との違い
CRYPTREC 暗号リスト [1] には、公開鍵暗号、共通鍵暗号、ハッシュ関数、暗号利用モード、メッセージ認証コード、認証暗号、エンティティ認証が記載されて8

いる。さらに、公開鍵暗号は、署名、守秘、鍵共有に分かれている。また、共通鍵
暗号は、64 ビットブロック暗号、128 ビットブロック暗号、ストリーム暗号に分かれ、暗号利用モードは、秘匿モード、認証付き秘匿モードに分かれている。
本ガイドラインで紹介する高機能暗号方式は、これらの暗号方式単独では実現できない機能を持つ暗号方式、もしくは、これらの暗号方式で実現するには非効率である事象を効率的に実現する暗号方式である。前者の例としては、CRYPTREC
暗号リストにおける公開鍵暗号では鍵生成においてランダムに出力される値が公開鍵として使用される。これに対し、任意の記号列、例えば、人名やメールア
ドレス、を公開鍵として利用することを可能とした高機能暗号が開発されている(第 3.1.1 章 ID ベース暗号参照)。また、後者の例としては、一つの平文を複数の利用者に送る際に、復号権限のある利用者の人数分の暗号文を生成し全利用者に暗号文を送ることに比べて、さらにコンパクトな暗号文のサイズで同じ機能を達成する高機能暗号も開発されている（第 3.1.3 章放送型暗号参照）。
第 1 章でも述べたように、本ガイドラインで紹介する高機能暗号方式は、CRYPTREC により安全性評価を行った方式ではない。これは、高機能暗号は発展途上にあるが、できる限り最新の情報を提供することを目指したためである。
発展途上にある最新の技術を CRYPTREC で評価をするためには、多大な時間を要することになり、逆に、最新の技術が掲載できなくなる。とはいえ、ガイドラ
インに掲載するためには、安全性が保障されない技術を記載するわけにはゆかない。そこで、主要な国際会議等の発表により脆弱性が発見されていないことを安
全性の根拠とし、世界の研究者を評価者と考えることで、安全性を担保する方針とした。

2.2.2 高機能暗号の有用性
本ガイドラインで扱う高機能暗号は、従来の暗号技術と比べ、

 ランダムな暗号化鍵ではなく、良く知っているメールアドレスや人名を暗号化鍵に利用できる。

 属性、例えば課長以上の役職の職員、を指定した、ファイル、ドキュメント
へのアクセス制御ができる。

 復号鍵の漏洩対策として、複数人の復号情報が集まらなければ、もとのデータに復号できない設定にできる。

 暗号化したまま論理演算や算術演算ができる。
 個人情報を秘匿したまま、あるグループに所属しているメンバーシップを認9証できる。

 個人が実際に所有する秘密情報を公開することなく、その秘密を持っていることを他者に証明することができる。

 DB へのアクセスパターンを秘匿することができる。
 管理者等によるコンピュータの RAM の解析を防ぐことができる。
 DB 管理者等に、どんなデータを検索したかを秘匿したまま、所望のデータを検索できる。
等の特徴を持つ暗号技術であり、これらの特徴が従来の暗号技術よりも優位な点となる。
このように様々な高機能暗号があるが、その優位性は種別毎に異なっている。
このため、高機能暗号を使用するにあたり、その目的にあった高機能暗号の選択が必要となる。

2.3 高機能暗号の種類と分類
2.2.2 章で述べたように、高機能暗号は、その使用目的にあった選択が必要となる。そこで、本ガイドラインでは、高機能暗号の目的に応じて、“守秘”、“認証・署名”、“その他” の 3 つに分類した。
守秘は、第３者に秘匿する文書等を暗号化するための技術である。認証・署名
は、文書等を作成する人、文書等を送る人、および、通信している機器の認証を行う、もしくは、それらに署名を付与するための技術である。その他については、上記の守秘、認証・署名には属さない新たな技術である。例えば、複数の人やサーバが協調しつつ各利用者が持つ秘密情報は秘匿して計算を行う方式や、秘密情報を提示することなく個人が秘密情報を持っていることを提示する方法等の技術である。
守秘と認証・署名は CRYPTREC 暗号リストにも同じ分類があるが、その他については、CRYPTREC 暗号リストの分類では、どの分類にも当てはまらない暗号技術となる。表 2.1 に、本ガイドラインで扱う暗号方式の一覧を示す。

2.4 高機能暗号の活用例と標準化動向
以前は、セキュリティ技術は付加機能であり、開発コストが高く、敬遠され、進んで導入する組織は多くなかった。現在では、企業からの情報漏洩は、企業のイ
メージを落とすことにもつながるため、たとえ一部の情報であっても漏洩することがあってはならない状況である。そして、サイバー攻撃等による情報漏洩の危10

表 2.1

分類

守秘本ガイドラインで扱う高機能暗号一覧

高機能暗号

特徴

ＩＤベース暗号

任意の記号列を公開鍵にすることが可能

属性ベース暗号

受信者の属性に応じた復号権限の付与が可能

放送型暗号

多数の受信者に対して放送用のコンテンツの効率的な復号権限の制御が可能

準同型暗号

暗号化した状態での演算が可能

プロキシ再暗号化

サーバにおいて暗号化鍵を変更することが可能

属性ベース署名

個人ではなく、属性に応じた署名権限の付与が可能

集約 MAC、マルチ MAC、 複数の MAC ／署名をコンパクトに圧縮すること
認証・署名

集約署名、マルチ署名が可能

グループ署名、リング署名

グループを構成するメンバの誰かが匿名で署名をすることが可能

しきい値署名

一定数以上の署名者がそろうことで、一つの署名
生成が可能

秘密分散

秘密データを複数に分割し秘匿する方法

マルチパーティ計算

複数のサーバが入力情報を秘匿したまま協調的に計算して結果を得ることが可能

ゼロ知識証明証明者が検証者に命題の正しさを証明でき、それ以外の情報を漏らさないことが可能

その他

Oblivious Random Ac-

サーバ内のデータアクセスにおいて、データの秘cess Machine （ORAM） 匿に加えてデータへのアクセスパターンをサーバに対して秘匿することが可能

Private Information Re-

サーバ内のデータアクセスにおいて、どのデータ

trieval （PIR）にアクセスしたかをサーバに秘匿することが可能

検索可能暗号サーバ内のデータへのキーワード検索において、検索キーワードを秘匿したままデータ検索が可能

険性もあり、セキュリティ対策を堅実に行うことが組織のアピールにもつながり、
セキュリティ技術を積極的に導入する組織が増加している。
さらに、社会環境も変化し、種々多様なサービスが発展してきている。この変化に伴い、ネットワークや、データの保護方法も変化し、高機能暗号が期待され、提案されている。また、すでに導入、活用され、実用化の段階に入っている高機能
暗号も増加している。以下では、個々の高機能暗号に対し、どのような活用例が11考えられているかを示すとともに、使用可能なライブラリや、標準化に向けた活動がある方式については標準化動向を示す。その後、活用事例に対し、高機能暗号を利用した実例を紹介する。

2.4.1 守秘関連の活用事例と標準化動向■ID ベース暗号

ID ベース暗号は、利用者の ID をはじめとする任意の文字列を公開鍵に利用できる公開鍵暗号方式の一種である。暗号文を受け取る相手の名前、
メールアドレス、ID、企業名、部署名等、よく知っており、一目で相手がわかる
情報を公開鍵として利用することができるため、相手とは全く無関係の公開鍵を利用した従来の暗号方式よりも利便性に優れている。
具体的には、メールの本文や添付ファイルを暗号化するサービス等が商用化されている。そのメールサービスでは、個々の利用者の公開情報であるメールアド
レスを公開鍵として、それに対する秘密鍵がサービス事業者により生成され、秘密
鍵はそれぞれの利用者に送られ保持される。メールの送信者は、メール送信先のメールアドレスを公開鍵（暗号鍵）として、メール本文を暗号化する。メール受信
者は、メールアドレスに対する秘密鍵（復号鍵）を持っているので、このメールを復号して読むことができる。秘密鍵は、メールアドレスの受信者しか持っていな
い情報であるため、メールの守秘性が保たれる。この方式では、送信者はメール
受信者の公開鍵を知る必要はなく、メールアドレスだけを知っていれば、受信者が復号できる暗号文を作ることができるため、従来の公開鍵暗号のように受信者の公開鍵を取得するための通信等の必要がない。

ID ベース暗号では、複数のライブラリがオープンソースソフトウェアとして公開されるなどソフトウェアが充実しており、パフォーマンスも高い [2]。まず、ID
ベース暗号に限らず近年の多くの公開鍵暗号方式で使われている Pairing と呼ばれる基盤技術がある。この Pairing をベースに最初に作られたライブラリが PBC
ライブラリ（Pairing-based Cryptography Libraly） [3] である。PBC ライブラリの中には ID ベース暗号関連のソフトウェアも含まれている。PBC ライブラリ以
外にも ID ベース暗号関係のライブラリは存在するが、PBC ライブラリが最も参照され、使用されている。商用のサービスとしては Voltage 社による電子メールの暗号化ソリューションである Voltage SecureMail がある [4]。また Cloudﬂare社が提供する CDN 顧客の秘密鍵管理のソリューションである Geo Key Manager
において ID ベース暗号の発展である Identity-based Broadcast Encryption とIdentity-based Revocation が採用されている [5]。
また、標準化活動も活発である。IETF では 2007 年 12 月に RFC 5091 として
12

Boneh-Franklin の手法と Boneh-Boyen の手法が標準化された [6] ことを皮切りに、ID ベース暗号関連の標準化がすすめられた。RFC 5091 をもとにデータ構造
等が RFC 5408、5409 として 2009 年 1 月に標準化された [7, 8]。2011 年に入り、ID ベースの認証鍵交換（ID based Authenticated Key Exchange，IDAKE）手法
が RFC 6267 として標準化され [9]、2012 年に、IDAKE 自体が RFC 6539 [10]、ID ベース暗号向けの Certiﬁcateless Signature 手法が RFC 6507 [11]、境-笠原の手法が RFC 6508 として標準化された [12]。IEEE では P1363.3 として ID ベース暗号だけではなくより広い Identity-based Cryptography（IBC）として標準化の活動が行われ、2013 年に IEEE Std 1363.3-2013 として標準化されている [13]。
そこでは 境-笠原の Key Encapsulation Mechanism（KEM）、Boneh-Boyen のKEM、Boneh-Franklin と Boneh-Boyen の ID ベース暗号方式が Identity-based
encryption scheme として標準化されている。ISO/IEC でも ID ベース暗号だけ
ではなくより広い範囲で Identity-based ciphers として ISO/IEC 18033-5:2015 が策定されている。そこでは IEEE Std 1363.3 と同様に Boneh-Franklin、BonehBoyen、境-笠原の手法が標準仕様として掲載されている [14]。
ID ベース暗号の活用に関する学術の研究としては、2003 年に ID ベース暗号のパラメータ配付に DNS を利用する方式が Smetters らにより提案されている [15]。
また 2013 年に Ruoti らによる電子メール暗号化の高いユーザビリティを実現す
る Private Webmail（PWM）において ID ベース暗号が採用されている [16, 17]。
Miklejohn らは交通系の料金収受システムの提案内において Blind Identity-based
Encryption を利用し、被発行者 ID を利用した暗号化を行っている [18]。機器認証において ID ベース暗号を用いる手法は Software Deﬁned Network（SDN）の研究において 2012 年の Veltri らの研究を筆頭に、2010 年代半ばに複数研究されている [19, 20, 21]。
■属性ベース暗号

属性ベース暗号は、暗号文の復号の際に、暗号文の受信者の肩書、会社名、地域名等の属性に応じて復号権限を変更することができる公開鍵暗号方式の一種である。より正確には、暗号文または復号鍵（秘密鍵）に属性に対応したアクセス構造を持たせることにより、当該暗号文の復号権限を一括で制御できる。従来の公開鍵暗号方式により属性毎のアクセス構造を持たせる場合、同じ属性を持つ利用者の公開鍵を用いて、利用者数に応じた暗号文を作ることになる。
これに対し、属性ベース暗号では、暗号文は一つでアクセス構造を持たせることができ、効率性において従来の公開鍵暗号方式よりも優れている。
属性ベース暗号の活用事例としては、クラウド環境を介したファイル交換サー
ビスにおける暗号化されたファイルへのアクセス制御の仕組みをセキュアかつ効13

率よく実現するために属性ベース暗号を利用しているソリューションが提供されている [22]。
具体的には、ある企業内のファイルにおいて、部長、課長は閲覧可能であるが、他の職員は閲覧できないようにするソリューションである。そのソリューション
では、部長、課長が持つ秘密鍵には、部長、課長に対応する属性情報が埋め込まれている。他の職員には、部長、課長の属性情報が埋め込まれていない秘密鍵が配布されている。ある企業内の機密ファイルに、部長、課長の属性をもつ復号鍵であれば復号可能となるように、公開鍵（暗号化鍵）と部長、課長という属性を用いて暗号化し、クラウドに保存する。クラウドからファイルの取得は誰でも可能であるが、復号時に、復号者の秘密鍵に埋め込まれた属性が適合しなければ復号できない。すなわち、属性に応じた復号のアクセス制御が可能となる。
一般に、公開鍵暗号においては、暗号文生成時においての復号権限をもつエン
ティティは唯一に指定されるため、複数エンティティに復号権限を与える場合にはその数に比例する暗号文の生成が必要である。一方、属性ベース暗号では上記の機能を単一の暗号文で実現可能となる。属性ベース暗号は、暗号文ポリシー型と鍵ポリシー型に大別され、それぞれ暗号文と秘密鍵にアクセス構造を埋め込む技術である。利用者は、この特徴に応じて、どちらかの型を選択することになる。
すなわち、ユースケースにおける暗号文と秘密鍵の更新頻度を比較し、相対的に更新頻度が少ない方へアクセス制御を埋め込む型を選択する方が効果的である。
そして、属性ベース暗号の様々な実現手法を実装したライブラリがオープンソー
スソフトウェアとして公開されている [23, 24, 25]。[23] は、ID ベース暗号の項で述べた PBC ライブラリを用いて作成された暗号文ポリシー型属性ベース暗号のソ
フトウェアである。[24] は Garg らによる GCH+13 方式 [26] の属性ベース暗号を用いて作成された Java ベースのライブラリである。[25] は Goyal らの属性ベース
暗号 [27] をもとにして作成されたライブラリである。
■放送型暗号

放送型暗号とは、一つの暗号化鍵を用いて暗号化されたコンテンツ

を、複数の利用者が同時に復号できるようにする方式であり、暗号化鍵と復号鍵が異なる公開鍵型放送型暗号と、暗号化鍵と復号鍵が等しい共通鍵型放送型暗号がある。複数の利用者に同じコンテンツを送る場合であっても、暗号化鍵は一つしかなく、すなわち、暗号化は一度でよい、という点で効率性に優れている。
公開鍵型放送型暗号は、利用者毎に異なる復号鍵を持つが、暗号化のための公開鍵は一つである。暗号化鍵は公開情報であり、公開情報のみで誰でも暗号化が可能だが、この性質を積極的に活用可能な応用先が乏しく、現時点では具体的な社会実装例は見当たらない。
14

共通鍵型放送型暗号は、暗号化鍵と復号鍵が同一であり、また、利用者すべてが同じ復号鍵を持つ方式である。誰でも暗号化を行うことができる公開鍵暗号型放送型暗号とは異なり、暗号化を行うことができる機関が暗号化鍵を共有したエンティティに限定されるものの、大規模コンテンツ配信システム等においては、暗号化するエンティティがごく少数であるため、そのような制約はそれほど問題とはならず、大規模コンテンツ配信の実用システム上では共通鍵型放送型暗号方式が利用されている。また、Blu-ray 等のメディア用にも使用されており、具体的には、Blu-ray 等のコンテンツ保護に用いられる Advanced Access Content System（AACS） [28] は、Naor らにより開発された放送型暗号である SD 法 [29] と共通
鍵暗号を組み合わせた共通鍵型放送型暗号に基づき構成されている。AACS については、デジタル家電業界、パソコン業界、映画業界の主導により、規格策定団
体 AACS LA [30] が設立され、IBM、 Intel、 Microsoft、 Panasonic、 SONY、

Disney、 Toshiba、 Warner Brothers 等により運営されている。
■準同型暗号準同型暗号は、データを暗号化したまま演算処理（四則演算等）ができる暗号技術である。可能な演算は暗号方式により異なっており、加算のみ、乗
算のみ、加算と乗算の両方が可能な方式等がある。暗号化状態での演算であるた
め、演算の途中でデータが漏洩したとしても、生のデータが解読されることはな
く、データを処理速度の速いコンピュータに預けて演算を行う分析等の応用例が具体化されている。具体的には、機械学習の分野で準同型暗号を活用することにより、学習データのプライバシを確保しつつ機械学習モデルを生成する手法に関する研究開発等がある。
すでに実証実験に至っている事例もある。複数の金融機関の取引データを利用して不正取引検知の精度を向上することを目的とする実証実験である。この実験
では、複数の金融機関が持つ取引データを持ち寄り、不正取引検知用の AI モデルを構築する方法が提案されている [31]。複数の金融機関のデータは、他の金融機
関や中央サーバには秘匿すべきデータとして扱う。そして、それらを AI の連合学習に利用する。深層学習を行う際には、DeepProtect と呼ばれるプライバシ保護
深層学習技術が使われている [32, 33]。DeepProtect では、準同型暗号により学習
中のパラメータ（勾配情報）を暗号化して中央サーバに送り、中央サーバでは、暗号化したまま、学習モデルのパラメータの更新を行う。
鉄道会社の IC カードの分析に秘密計算を取り入れる検証等も実施されている [34]。そして、IC カードの利用履歴、乗降履歴や購買履歴等のセキュアな利用に取り組んでいる。この検証では、加算型の準同型暗号の一つである Paillier 暗号 [35] が使用されている。また、暗号化前と暗号化後の順番が変化しない順序保15

存型暗号（Order Preserving Encryption）も活用しているとされている。
準同型暗号については、ライブラリ、ソフトウェアが数多くオープンソースソフ
トウェアとして公開されている。Brakerski らによる準同型暗号 BGV12 方式 [36]と Cheon らによる準同型暗号 CKKS17 方式 [37] を基に開発されたライブラリ

HElib [38]、Brakerski による準同型暗号 Bra12 方式 [39]、Fan らによる準同型暗号 FV12 方式 [40]、CKKS17 方式に基づくライブラリ SEAL [41]、 CKKS17 方
式 に基づくライブラリ HEAAN [42]、Bra12 方式、 FV12 方式、BGV12 方式、CKKS17 方式、Ducas らによる準同型暗号 DM15 方式 [43]、 Chillotti らによる準同型暗号 CGGI16 方式 [44] に基づくライブラリ PALISADE [45]、Bra12 方式、FV12 方式、CKKS17 方式に基づくライブラリ Lattigo [46] 等がある。さらに、
HEAAN を用いたプラットフォーム等の製品 [47] が商用化されている。
準同型暗号の標準化も行われており、標準化団体 Homomorphic Encryption
Standardization [48] は準同型暗号のセキュリティ、API ＆アプリケーションの標準化を目指している。この標準化では、記法と準同型暗号化のセキュリティプロ
パティ、完全準同型暗号スキーム、推奨パラメータ値、標準的な攻撃方法とその耐性、推定実行時間だけでなく、将来を見越した耐量子計算機対応としてラティ
ス攻撃、LWE に対する Arora-Ge 攻撃、RLWE に対する代数攻撃方法とその耐性が標準化の対象となり、今後も、API 設計、アプリケーション例が追加される予定となっている。さらに、ISO/IEC では、単一演算型の準同型のアルゴリズム（Exponential ElGamal encryption、Paillier encryption）の暗号処理にかかるプ
ロセスを規定している [49]。
■プロキシ再暗号化

プロキシ再暗号化は、ある暗号文を復号せずに、暗号文の作成者とは異なるエンティティ（プロキシ）が、平文が同じである別の暗号文に変換する暗号方式である。入力された暗号文と出力される暗号文では、秘密鍵が異なることが一般的であり、このため、秘密鍵の更新が必要となるアプリケーションや、所有者変更等のアプリケーションでの応用例が報告されている。
例えば、復号を実行せずに動的に受信者を変更できるため、動的にアクセス権限の変更をすることを想定するクラウドストレージ等において特に有用であると考えられる。そして、NuCypher 社は、Umbral PRE と呼ばれるプロキシ再暗号化方式を開発し、これを用いた事業展開を進めている [50]。ここでは、サーバにおかれた暗号化データを利用者に配布する場合、その利用者の秘密鍵で復号できる
ようにアクセス制御する方式等が提供されている。また、東芝も独自に開発したプロキシ再暗号化方式を用いて、デジタル貸金庫と呼ばれるサービスを 2021 年まで展開していた [51]。デジタル貸金庫では、サーバに蓄えられたデータを、複数の
16

デバイスで利用できるようになっている。ただし、個々のデバイスの復号鍵は異なっている。この個々のデバイスで利用するために、サーバに蓄えられた暗号文から、利用するデバイスの復号鍵で復号できる暗号文にプロキシ再暗号化を利用して変換していた。

2.4.2 認証・署名関連の活用事例と標準化動向■属性ベース署名

属性ベース署名とは、属性ベース暗号の署名版と考えて差支えない。属性ベース暗号の場合は、復号する利用者の属性に応じて、より正確には、復号する利用者が持つ復号鍵に応じて、暗号文へのアクセス制御を行っている。これに対し、属性ベース署名では、署名者の持つ署名鍵が、署名者の属性に応じて異なっており署名者の属性集合が埋め込まれた署名鍵になっている。そして、ある文書に対して署名鍵を用いて署名を生成するわけであるが、その署名の中に属性に関するアクセス制御構造が埋め込まれる。署名検証において、署名者の持つ属性集合が、アクセス制御のために埋め込まれた構造にマッチしている場合は、署名検証をパスすることができる。すなわち、署名者の属性に応じて、検証判定ができる署名方式である。
この属性ベース署名を使うことで、社内に送付する文書において、名前ではなく、文書作成者の属性（役職、部局等）等に応じた署名を付与することができる。
ある社の A さんが作成した文書を、その課長、部長等が押印して回付することはよくあることである。紙媒体の場合、A さんの印、課長印、部長印が押印される。
この課長印、部長印は、課長もしくは部長の権限を持つ人が、課長／部長の責任に応じた役割を果たし、文書を確認したことを、文書の受領者に示すものであり、課長、部長の名前よりも、その役職に意味がある印である。さらに、詳細に、総務部の課長印のように、部署名も必要なこともある。この押印を電子的に行う場合、
属性ベース署名が役に立つ。
総務部の課長 B さんは、 所属：総務部 、 役職：課長 の属性を持つ。このため、B さんの署名鍵（秘密鍵）は、 所属：総務部 、 役職：課長 に応じた署名鍵となる。B さんが署名を生成する際に、署名を受理するためのアクセス条件を付与する。この例の場合、 総務部かつ課長

であれば、受理するという条件になる。文書の受信者は、署名がアクセス条件にあっているかどうかを確認することになる。B さんの署名は、 総務部

かつが通る。もしではない第 3 者が署名を偽造したとしても、

総務部

かつ

課長

課長

の属性であるため、署名検証

署名検証でエラーとなる。
この例で示す通り、名前による確認ではなく、役職や所属部署名による確認を17

行うことができる。もちろん、企業によっては、課長印、部長印以外に、名前が必要な場合もある。この場合は、 名前：B さん または 名前：C さん または 名
前：D さん等をアクセス条件に入れることで対応ができる。

また、属性の作り方を工夫することで、多くの活用方法が考えられ、例えば、ブロックチェーンやユーザ認証において匿名性を確保するために属性ベース署名を活用する手法の研究が行われている [52, 53]。
■集約 MAC・マルチ MAC・集約署名・マルチ署名

集約 MAC は、異なる複数の文書に対し、複数もしくは一つの秘密鍵でメッセージ認証符号（Message Authentication

Code，MAC）を付与する場合を効率よくするための技術である。例えば、企業内
で文書に対し、文書の作成者とその上司、および、別の部の担当者等、複数の人が異なる秘密鍵により MAC を付与する場合である。通常の MAC 方式であれば、MAC を付与する人数が多くなると、人数に比例して MAC 部分のサイズが大きくなる。これに対し、集約 MAC では、複数の MAC を単一の MAC に集約するた
め、MAC サイズが小さくなるという優位性を持つ。
マルチ MAC は一つの文書に対し、複数の異なる秘密鍵で生成された MAC を統合し、集約する技術である。MAC を付与する文書が共通であり、集約 MAC の特殊ケースとして捉えることができる。そして、集約 MAC と同じように、MAC
サイズが小さくなる優位性を持つ。
集約署名は集約 MAC の電子署名版と考えることができる。複数の文書に対し、複数人が署名するような場合を効率よくするための技術である。通常の署名方式であれば、署名を付与する人数が多くなると、人数に比例して署名部分のサイズが大きくなる。これに対し、集約署名では、複数の署名を単一の署名に集約するため、署名サイズが小さくなる、という優位性を持つ。また、署名を検証する人は、これを効率よく検証できる提案もある。すなわち、集約された署名の人数分の検証を行うのではなく、一回の検証処理で行う方式である。
マルチ署名は、一つの文書に対し、複数人が署名を行う場合、この署名を単一の署名にまとめる技術である。集約署名と同じように、署名サイズが小さくなる点がメリットである。
集約 MAC および集約署名については、現時点で具体的なサービス等の提供は行われていないが、ITU により廣瀬らによる方式 [54]、佐藤らによる方式 [55] の
技術内容の標準化が行われている [56]。また、この技術を用いた認証関連のデー
タ量の削減効果を考慮し、認証に係るインターネット上のトラフィック量削減を目的とする活用に関する研究が行われている [57]。
マルチ署名は、暗号資産 Bitcoin やブロックチェーンプラットフォームである18

Ethereum におけるマルチシグウォレットにおいて活用されている。マルチシグ
ウォレットは、複数のユーザが共同利用することを前提とし、取引の実行には全てのユーザの同意が必要となるものであり、同意形成の仕組みとしてマルチ署名が利用されている。例えば、信頼できる第三者に署名生成鍵を委託することにより、他のユーザによる不正送金等を防ぐことを目的に利用される [58, 59]。
■グループ署名

グループ署名は、署名者があるグループの一員であることは明示的に分かるが、グループ内の誰であるかまでは分からない匿名性を保証することができる署名方式である。一般の署名方式では不可能であった、署名者のプライバ
シ保護、匿名性が必要となるアプリケーションにおいて需要がある。
例えば、プログラム開発での確認作業、いわゆる Attestation において、2000 年
代からグループ署名が利用されるようになった。ここでの Attestation とはプログラムが製造者やユーザの意図した通りに動作しているかを確認するための処理であり、ブート結果や周辺機器の接続状況等の予め想定された処理結果に対して
デジタル署名をつけて正当性を確認できるようにするものである。集中管理するケースにおいては通常のデジタル署名や PKI を利用した場合、Attestation をしたエンティティの活動に対するプライバシ侵害が起こりうるため、グループ署名を利用してそれを回避する仕組みが取られることが多い。
また、ISO/IEC において、標準化も行われている [60, 61]。
■リング署名

リング署名では、署名者があるグループの一員であることは明示的に分かるが、グループ内の誰であるかまでは分からない匿名性を保証する署名方式である。一般の署名方式では不可能であった、署名者のプライバシ保護、匿名性が必要となるアプリケーションにおいて需要がある。この意味では、グループ
署名と同じ効果を有する署名方式である。ただし、グループ署名とは異なり、グループ管理者を置く必要がなく、署名生成時に柔軟にグループを選ぶことができるという点で、グループ署名とは異なっている。
グループ管理者を置かないことにより、グループ生成を柔軟にできることはメリットであるが、逆に、署名者の誰かが不正を行った場合に、不正を行った署名者が誰かを特定することは困難である、というデメリットもある。グループ署名を使用するか、リング署名を使用するかは、その利用環境に応じて決められるべきことである。例えば、署名を生成できるユーザを管理者が認可したユーザだけに絞りたい場合はグループ署名を使用する。この場合、管理者に対して、署名者の匿名性を担保することは困難となる。これに対し、リング署名の場合は完全な匿名性を担保したい場合に使用する。グループ署名とは逆に、署名者を管理する管理19

者がいないため、誰でも署名を生成することができる。
リング署名は、実用事例は少ないが、活動が盛んになっている暗号資産において使われている [62]。
■しきい値署名

しきい値署名は、「シェア」と呼ばれるある情報の分散情報を利用する。まず、一つの平文に対し、複数の署名鍵のシェアを用いて署名のシェアを生成する。この署名のシェアをあるしきい以上集めて、結合することで真の署名を生成する方式である。検証鍵は一つだけであり、各署名シェアではなく、真の署名の検証時に利用する。平文の正当性を一人の署名だけで確認するのではなく、
しきい値以上の複数人の署名、すなわち、複数人が個々に平文を確認し、署名することにより、複数人が確認した平文となる。しきい値署名では、この複数人が生成した署名を、一度に検証することができる。
暗号資産における鍵漏洩への対策としてしきい値署名が使われることが多くなっている。例えば、しきい値署名の利用例として Bitcoin 等での利用が挙げられる。Bitcoin ではマルチ署名のような複数の署名者によるトランザクションの生成が可能である。しかし、この方法では複数の署名を必要とするため、ストレージ
効率が悪いことや、署名者の構成が公開されてしまう等のデメリットがある。一方、しきい値署名はオフチェーンで利用することが前提となるが、複数の署名者がしきい値署名を使って署名の断片を作り、その署名を集めて一つの有効な署名としてトランザクションを生成する。この署名は単一の署名値でありマルチ署名に比べてストレージ効率が良く、署名者の構成が署名値からは分からない。ここでのオフチェーンとは直接ブロックチェーンの処理に組み込まれることのない処理のことを指している。
そして、このオフチェーン処理の署名について、特に Bitcoin が利用する署名方式を ECDSA からシュノア署名に置き換わるにあたり、しきい値署名の利用が推進される可能性が種々報告されている [63]。また、暗号資産 quredo のイエローペーパーではしきい値署名が使用され [64]、フレセッツ社では HSM を利用した
しきい値署名 [65] による Ethereum 秘密鍵保護方式 [66]、Coinbase 社では DApp

Wallet [67] と呼ばれる暗号資産用のアプリで採用しているようであり、分散型のブロックチェーンを開発するプロジェクトである DFINITY ではスマートコント
ラクト canister が保持する Bitcoin や Ethereum の鍵をしきい値 ECDSA にする提案（V.Shoup） [68] 等の報告がある。
これに応じて、標準化活動もおこっている。アメリカ国立標準技術研究所（National Institute of Standards and Technology, NIST) では、2019 年にしきい値暗号に関する NIST の標準化の目的等について記述された NISTIR 8214 [69] が20

発行され、さらに 2020 年にそのロードマップとなる NISTIR 8214A が発行された [70]。そして、2021 年 9 月にフィードバックの締切があり、2022 年 8 月に開発者向けガイドラインと推奨の 8214B が発行された [71]。また、IETF では、標準化提案が行われ、標準化プロセスが始められている [72]。

2.4.3 その他の高機能暗号の活用事例と標準化動向■秘密分散

秘密分散法は、その名の通り秘密情報を何らかのグループのメンバー間で分散する暗号技術の一種である。秘密鍵などの秘密情報を保管する際は、その秘密情報の紛失、破損、盗難、漏洩といった脅威を考慮する必要がある。破損や紛失については情報のコピーを作ることで対策できるが、コピーが増えれば増えるほど盗難や漏洩のリスクが高まる。これを解決するため、秘密分散法は秘密情報を「シェア」と呼ばれる複数のデータに分割し、これを複数の当事者間で分散して保管する。このシェアは、ある定められた組み合わせを揃えたときのみ元の秘密情報が復元でき、また、復元の条件を満たさないシェアを揃えても、元の秘密に関する情報が漏れないように作られる。最もシンプルでよく用いられる「組み合わせ」の例はしきい値型である。すなわち、n 個のシェアのうち、k (≤ n) 個のシェアを集めることで秘密が復元できるような方式である。
上述の特徴の通り、秘密分散法の直接的な応用は分散ストレージサービスである。秘密分散法を用いて分散保管することで、データの秘匿性を保証しながら冗長性を確保することが可能となる。そして、この冗長性の確保により、一部のストレージに障害が起きた場合への耐性を取ることが可能となる。具体的なアプ
リケーションとしては、文書管理システムやコンテンツ配信システムなどへの適用事例がある [73]。自然災害の多い日本国においては、事業継続計画（BusinessContinuity Plan，BCP） 対策は重要な課題であると認識されており、とりわけ
東日本大震災の直後は、Azure 等のクラウドストレージサービスを利用しながら世界中のサーバにデータを秘密分散するサービス [74] が登場するなど、セキュリ
ティと災害対策を両立する技術として活用されている。
ま た 、計 算 量 的 な 秘 密 分 散 法 と し て 知 ら れ る All-Or-Nothing Transform（AONT）を利用したものでは、Shin らによる AONT [75] を用いたサービスがZenmuTech 社によって実装され、近年実用化されている [76]。
秘密分散法の応用は分散保管にとどまらず、様々な暗号プロトコルの要素技術としても用いられている。特に、複数のエンティティで一つの計算を行うマルチ
パーティ計算との関連が深い。近年ではブロックチェーンと組み合わせた秘密鍵の分散管理システムなどへの応用もあり、マルチパーティ計算と組み合わせるこ
21

とで暗号資産等の秘密鍵を安全に運用する手段として注目されている [77]。
標準化も進められており、ISO/IEC SC27 WG2 においては、秘密分散法の定義、記法、代表的な方式の標準規格が発行されている [78]。現在の規格では、5 つの代表的な方式が記載されている。1 つ目は、しきい値型の完全秘匿性を達成する

Shamir の秘密分散法 [79] であり、今日においては最もよく知られた方式である。
完全秘匿性とは、攻撃者が無限の計算能力を持っていたとしても破ることができな秘匿性のことである。2 つ目は、完全秘匿性の要件を緩和する代わりに、シェアのサイズを秘密情報のサイズより小さくするランプ型秘密分散法（Ramp Secret

Sharing） [80, 81] であり、Shamir の秘密分散法の一般化として構成される。3 つ目は、加法型秘密分散法（Additive Secret Sharing）と呼ばれる手法に基づく、一般的なアクセス構造を実現する秘密分散法 [82] である。これは、秘密情報へのア
クセスを許されるシェア集合と、許されないシェア集合を指定可能な秘密分散法
であり、しきい値型よりも柔軟なアクセス構造を導入することが可能である。4 つ目は、複製型秘密分散法（Replicated Secret Sharing）と呼ばれる手法に基づく、
一般的なアクセス構造を実現する秘密分散法 [83] である。この方式も、任意のアクセス構造を実現することが可能である。こちらの方式はシェアのサイズがパーティ数に対して大きいが、方式の特殊ケースは近年の効率的なマルチパーティ計
算にも利用されている [84, 85]。5 つ目は、計算量的安全な秘密分散法 [86, 87] である。これは、情報理論的に安全な秘密分散法と共通鍵暗号を組み合わせることで実現でき、情報理論的な秘密分散法と比較してシェアサイズが大幅に削減できることが知られている。
■マルチパーティ計算

マルチパーティ計算（Multi-Party Computation，MPC）は、複数の参加者（マルチパーティ）が自身の秘密情報を秘匿しながら、それらの秘密情報を入力とする種々の関数をパーティ間で協調計算することを可能とする技術である。MPC には、大きく分けて秘密分散法をベースにしたものと、Garbled

Circuit をベースにしたものがある。前者は後者に比べて参加者間で複数回の通信を必要とする代わりに、計算量・総通信量が小さい傾向にある。また、両者ともに参加者のうち一定数が結託しないという仮定の下で安全性が保証される。そして、標準的な公開鍵暗号では困難であった暗号化しながらの計算処理が、MPC では可能となる。また、準同型暗号と比較した場合、通信量や計算量に優れるため、処理のスループットが高いという特徴がある。
秘密分散法をベースにした MPC 方式の活用事例として、個人の秘密情報を秘匿したまま、統計情報の計算・機械学習等のデータ分析を行うサービス提供がある [88]。例えば、病院の臨床データの分析のために、ディープラーニングをする
22

際、入力に対してマルチパーティ計算させることで、平文の入力データを誰にも知られることなく、分析結果を得ることができる。秘密分散法がベースであるため、前述の秘密分散の項で説明したように、入力データはシェアと呼ばれるデータに分割され、複数の入力データシェアが作成される。その後、マルチパーティ計算を行う複数のサーバにそれぞれの入力データシェアが入力される。入力シェアを得たサーバは、ディープラーニング用にサーバ独自の計算を行うとともに、別のサーバと通信をすることで、分析結果データを分割したものとなる出力シェアを生成する。この出力シェアを全部集めて合成することで、分析結果を得る方法である。
さらに、複数の医療機関が保持するゲノム情報や診療情報を統合して解析することにも応用されている [89]。このゲノム情報は非常に機微性の高い情報であり、漏洩は絶対に許されない。そこで、MPC を用いてデータ秘匿性を守りながらデータを収集し、医療・医学に活用する方法としている。
さらに、国外でも、政府の持つ TAX Records と STUDENT Records より、教育と年収の関係、大学在学中のアルバイトと留年の関係、大学の学問分野とアルバイト量の関係を分析 [90] したり、エネルギー消費の最適化を行うために大手企業の産業データを秘匿化して収集し分析するエネルギー供給の最適化 [91] 等、多くの応用例がある。また、国内外で多くのスタートアップ等による活用が進んでおり、コミュニティの形成を通じた知見の共有、企業間の連携が進んでいる [92]。
さらに、秘密計算技術が広く社会実装され、クラウドサービスのデータ保護に対する不安の払拭や、組織や企業の枠を超えたデータ利活用により新たな価値が創出されることを目的とし、様々な秘密計算方式を俯瞰した実用的かつ客観的な安全性基準や、ユーザが秘密計算を活用する際の参考となる指針の検討、ホームページ
やイベントを通じた、上記基準や指針の検討状況、方式の性能等に関する技術資料
や先端事例の情報発信 [93]、秘密計算を中心としたプライバシ保護関連技術に関連する情報発信、および、個人情報保護法の改正を始めとしたデータ活用とプライ
バシ保護がコンフリクトしている現状に対応すべく、法令遵守したデータ活用やプライバシ保護テクノロジの勉強会や情報発信を行っている団体もある [94]。さらに、NIST はプライバシに関するプロジェクト Project on Privacy-Enhancing

Cryptography（PEC）の中で、MPC の普及に務めている [95]。
標準化も進められており、現在、ISO/IEC SC27 WG2 において、秘密分散型
MPC の定義、記法、代表的な方式の標準化に向けたドラフト作成が進められている [96]。
Garbled Circuit をベースにした方式では、2 者計算の様々なシーンで利用されるが、近年では鍵管理の文脈において、秘密鍵を分散して保護しながら、それを23

Garbled Circuit によって復元することなく暗号化・復号・署名等の計算を可能とする Hardware Secure Module（HSM）の代替としての応用が存在する。特に、暗号資産における電子署名の鍵管理手法として注目を集めており、従来の取引所等が集中的に鍵を管理する形態と比べて、鍵管理を集中して行う必要がなくなり、取引所等の単一障害点が排除されており、秘密情報を含む情報漏洩に対しても耐性があり、安全性が高い利点がある [97]。

Garbled Circuit ベースの MPC についての標準化の動向はないが、先に紹介した NIST の PEC プロジェクトにおいては、PEC 技術の一種として Garbled
Circuit に関するワークショップ等での報告が行われている [95]。
■ゼロ知識証明

ゼロ知識証明とは、ある人が他の人に特定の命題を証明したいときに、証明したいこと以外の知識を与えることなく証明する手法であり、以下に示す
完全性、健全性、ゼロ知識性の３つの性質をもつ。

 完全性：証明者の命題が真ならば、検証者は真であることが必ずわかること。
 健全性：証明者の命題が偽ならば、検証者はかなり高い確率で、偽であることを見抜けること。

 ゼロ知識性：あらゆる場合で、検証者が証明者から何らかの知識を得ようとしても、証明者の命題が真であること以上の知識は得られないこと。
ここで証明したい命題には、ある値が規定の範囲内に存在するかの「範囲の証明」
や、任意の演算が正しく実行されたか「演算の証明」がある。一番の特徴は、証明したいこと以外の知識を与えないため、安全性が高いことである。
この特徴を利用して、いろいろな場面での活用が考えられている。例えば、不動産会社と顧客と金融機関の間での取引において「不動産会社は、顧客に対して『住宅を借りるために十分な所得があるか』を証明してほしいと考えている。顧客は、正確な所得金額を明かしたくない。顧客は、命題『一定金額以上の所得がある』ことを、金融機関を通して、ゼロ知識証明により証明する。
」
より具体的には、銀行において、顧客の本人確認を行う時に、正確な数字を明らかにすることなく、給与が特定の範囲内にあることを証明したり（ZKRP）、特定の地域の住人であることを具体的な住所を明かすことなく居住地区の範囲を証明す
ることをゼロ知識証明により行う。そして、ZKRP をオープンソースソフトウェ
アとしてリリースしているケースもある [98]。
また、匿名性のある暗号資産の Zcash においては、zk-SNARK と呼ばれるゼロ
知識証明を用いて、トランザクションを生成することにより、送信アドレスと受信
24

アドレス、送金額を秘匿することができる [99]。
さらに、パブリックブロックチェーンの一番の課題は、BtoC もしくは BtoB
でやりとりされるトランザクションの匿名性の確保である。そこで、パブリック
チェーンの Ethereum 上でトークンのプライベートトランザクション（匿名送金）を可能にするゼロ知識証明を用いたプロトコルが開発されている [100]。ただし、プライベートトランザクションはデータサイズが大きくなり、Ethereum のシステ
ムを稼働させるための手数料にあたる、いわゆる gas 代 の負担が高くなる傾向にあるが、複数の証明のバッチ化の工夫により、コスト負担を軽減させている。
また、標準化を目的とした団体があり、その中には NIST も参加している団体もある。標準化では、ゼロ知識証明を用いたデータプライバシ製品やアプリケー
ションのセキュリティ保証と相互運用性を向上させることを目的としている。そして、作成されたドキュメントでは、理論から実装までの情報がカバーされている [101]。
■Oblivious Random Access Machine （ORAM）

サーバに暗号化データを格納し必要に応じて読み込み/書き込みを行う場合に、データは秘匿されているが、暗号化デー
タへのアクセス頻度等のアクセスパターンの情報からサーバに統計的な部分情報が漏れてしまう。Oblivious Random Access Machine（ORAM）においては、サーバにアクセスパターンを隠しながら、暗号化データの読み込み/書き込みが可能となる。具体的には、ORAM 上で暗号化データに対して読み込み/書き込みを行う
たびに、格納位置をシャッフルするとともに再暗号化することで、各アクセス間の関係を秘匿する。

ORAM を利用して、プライバシ保護を可能としたデータベースサービスが開発されている [102]。このサービスでは、プライバシ保護の安全性指標である差分プ
ライバシの概念に従ったプライバシ保護技術を利用して個別のデータを明らかにすることなくデータ分析を可能とし、ORAM によりアクセスパターンの漏えいを防ぐことができる。また、暗号資産のトランザクションにおいて、マイナーによりトランザクションの順番を、マイナーに有利な順番に操作する攻撃が考えられている。このような攻撃を防ぐために、ORAM を利用した仕組みが開発されている [103]。この攻撃では、マイナーはユーザのアクセスを監視して攻撃を行うが、ORAM を用いることによってアクセスパターンをマイナーに秘匿できることになる。
■Private Information Retrieval （PIR）

ユーザがデータベース（DB）を検索し、ユー

ザに必要な情報を取得するサービスは多数ある。この DB 検索を行うためには、

25

DB に対してクエリと呼ばれる質問を入力し、その質問に対する回答として、DBからファイルやデータ等の検索結果を受け取っている。この際、ユーザは、 質問
内容も個人情報であり、この内容を DB の管理者であっても知られたくない という場合もある。このような情報秘匿を行うために創出されたプロトコルが Private

Information Retrieval（PIR）である。そして、PIR は暗号方式そのものではな
く、暗号方式を用いて、ユーザのプライバシを保護した情報検索法である。
具体的には、ある DB が n 個のデータ D = {D1 , . . . , Dn } を持っている時に、ユーザは質問 i にある処理を施しクエリ qi を作成し、qi を DB に送る。この qi からは i の情報は全く漏洩しないように工夫されている。そして、DB は i に関する情報を何も得られないが、qi を用いてある演算をすることで、検索結果を含む複数の候補を出力することができる。ユーザは、受け取った複数の候補から、所望の Di を抽出する。全体として、DB が得られる情報から i については何の情報も得られないプロトコルとなっている。
具体的な提案としては、Wang らは安全で信頼できるハードウエアの存在を前提として、データベースのアウトソーシングに関する考察を行なった [104]。ここでは信頼できる第 3 者機関（Trusted Third Party，TTP） の存在、非存在の両方について議論されている。当時の解決方法としては、AMD，HP，Intel，Microsoft等が中心となっている Trusted Computing Group（TCG）の仕様に準拠したセキュリティチップ Trusted Platform Module（TPM）や Intel 社による LaGrandeTechnology などの採用を検討していたことが論文からは窺える一方で速度の面から効率的な実装は少なかったと判断される。
コンピュータシステム・ストレージ系の書籍 [105] において PIR を用いた活用
事例でのセキュリティとプライバシを考慮したデータマイニングが実利用される
場合の懸念点が示されている。１）コントロール外のデータの扱い、２）技術的に担保されていたとしても非匿名化の可能性、３）サービスに対する法域外の扱い、
４）法律と現在の技術の対応が未熟、という 4 点である。PIR を適用するデータ
はセンシティブな扱いを要することが容易に想像できるか、上記のような課題が存在していることに留意しなければならない。
近年では 2020 年に Mozaﬀari らによる PIR の改良方式 [106] が広く知られることとなった。この論文の中で以下のようなアプリケーションが列挙されており、幅広い適用が検討されていることが見て取れる。

 インターネット ドメインの登録 Tor サーバのリレー情報の取得
 プライベート メディア配信
26 プライバシを保護する電子商取引アプリケーション
 オープン アクセス電子論文リポジトリでのプライベート クエリ
 メッセージング アプリケーション
 プライベート オンライン通知
 プライベート ファイル共有アプリケーション
また日本でもブロックチェーン技術への応用に関するプレスが 2020 年 6 月に発表されている [107]。Bitcoin 等で利用されている Unspent Transaction Output（UTXO）と呼ばれるトランザクション（価値の移動を表現するフォーマット）のデータベースが運用されていると仮定して、この DB に対して検索を行う際の検索クエリが流出するというプライバシ問題を解決するために PIR を利用するというアナウンスであった。ただし、Bitcoin 関連のイベントに合わせたプレスである
ことや、その後、このプレスを発行した組織は買収されるなどして、その後の動きなどはなく実際には実用化されていないと考えられる。
また、暗号資産のアクセスの秘匿化に使用する実装が報告され、実用化されているている [107]。この実装では、Microsoft から公開されている PIR のオープン
ソースソフトウェア SealPIR [108] が使われている。
■検索可能暗号

一般的な共通鍵暗号や公開鍵暗号では、サーバに暗号化文書を格納した場合に、暗号化すると平文が秘匿されるため、ある暗号文に対応する平文があるキーワードを含んでいるか検索することができない。検索可能暗号においては、サーバにキーワードの暗号文を一緒に格納することにより、検索キーワードを含むかどうか以外の平文の情報をサーバに漏らさずに、暗号文のままキーワード検索が可能となる。
検索可能暗号がもっとも活用される分野として注目されているのはデータベースと言って良い。この場合、データベースには、暗号化されたデータと、暗号化されたキーワードが保存されている。利用者はデータベースに暗号化されたキー
ワードのクエリを送る。データベースは復号鍵を持っていないので、平文のクエ
リを知ることはできない。データベースでは、その暗号化されたクエリと保存されている暗号化キーワードのマッチングを行い、検索結果を得る。検索結果も暗号化されたデータであり、その平文データをデータベースに知られることはない。
暗号化されたクエリにより検索を可能とするデータベースは MIT による

CryptDB [109] を代表に多くの事例がある。CryptDB は Paillier 暗号等、複数の暗号技術を用いて暗号化データベースを実現しており、Cipherbase や SEED、Microsoft 社のシステム等、複数の商用サービスに採用されている。この他にも、

27

学術研究をもとにした著名なオープンソースソフトウェアとして KafeDB [110] 等がある。国内の商用のソリューションとしては、日立製作所はクラウドサービス
として検索可能暗号技術を提供しており [111]、三菱電機もソフトウェアを開発している [112] 等、さまざまなアプローチで活用されている。また、Intel SGX 上で検索可能暗号を実現する技術 [113] 等、多くの実用化研究が行われている。
検索可能暗号の標準化については、IETF において過去に準同型暗号についてのプレゼンテーション等で検索可能暗号についれ触れられていたことがあったものの、標準仕様として議論されるには至っていない。

2.4.4 活用事例からみた高機能暗号の利用方法
ここまで、高機能暗号技術がどのようなものであるか、という視点に立ち、その活用例、実施例、標準化活動を紹介した。本章では、どのようなサービス、応用方法があるか、という視点に立ち、そのサービス、応用にとって、どのような暗号方式で有用であり、実用化されたか、を紹介する。
■プライバシ強化

種々のサービスにおいてプライバシを強化する目的で、秘密計算を利用した暗号を社会実装したケースがある。秘密計算とは、計算を行うサーバ等の装置に対し、ある加工されたデータを渡し、そのサーバ等の装置において計算の元となる値を知られることなく、その結果を計算する方法の総称である。代表的な方式として、準同型暗号（3.1.4 章参照）を用いた方式、秘密分散法（3.3.1
章参照）を用いた方式、マルチパーティ計算（Multi-Party Computation，MPC）（3.3.2 章、3.3.3 章参照）を用いた方式、装置内に組み込まれている信頼できる秘匿されたハードウェア（Trusted Execution Environment，TEE）を用いる方式等が広く知られている。表 2.2 に示す事例は、この秘密計算が有用であると考えられる事例である。これらの中から、数例を以下に紹介する。
例 1．ゲノム解析による実証実験
ゲノム解析に関し、秘密計算を利用した企業と大学の共同実験が行われている [114]。ゲノムは、個人の遺伝子情報の全体であり、究極のプライバシ情報と言える。これまで、ゲノム情報は個別の医療機関で所有しているが、医療機関を超えた連携は、プライバシ情報の漏洩につながるため容易ではなかった。より多くのデータを集めることで、正確でより広範なゲノム解析が可能となるが、このプラ
イバシ保護のハードルを超える必要があった。そこで利用したのが、秘密計算である。
実験の概要を図 2.1 に示す。ここでは、各医療機関が持つデータを加工し、複数
28

表 2.2

秘密計算の応用事例

領域

説明

適用例

統計処理

典型的な統計計算（合計、平均、最売上集計、ログの分析、ゲノム分

大値、最小値）析

複数のデータソースから同じキー

マーケティング、ゲノム分析

突合を持つレコードを突合
スコアリング／ AI 推論

入力および AI モデル等を秘匿しAML（不正送金）

ながら計算
マッチング

連合学習

要求条件を秘匿しながら、条件の秘密オークション、場外の証券取合うレコードを検索

引

連合学習時の AI モデルの保護

特に機微なデータを元にした AIモデルの保護

投票

投票者を秘匿しながら集計

図 2.1

選挙

実証実験１：ゲノム分析（[114] から引用）の別のデータに変換した。具体的には、個々の医療機関が持つゲノム情報や、診療情報のデータを３分割し、秘匿化する。この分割されたデータから、元のゲノム情報や診療情報のデータは復元できないようになっている。いわゆる秘密分散法を用いた方式である。そして、これらの分割され秘匿化されたデータを、それぞれ異なる３台のサーバに分散して保存する。それぞれのサーバでは、受け取ったデータを利用するとともに他のサーバと通信しつつ、あらかじめ定められた演算を行う。これは、MPC 技術の一種であり、入力データの加工方法である秘密分
29

散法と組み合わせ、秘密分散ベース MPC と呼ばれることもある。秘密分散ベー
ス MPC では他のサーバとの通信を行うが、各サーバのデータが漏洩しないように、通信路の暗号化を追加する等、実運用時にはさならる安全性を担保する。

MPC では複数のサーバが必要となる。近年の個人情報漏洩のインシデントを見る限り、何らかのオペレーション時の個人の操作ミスによるものが多い。従って、複数のサーバの管理者を分けるだけでもインシデント対策として効果はある。さらに、サーバ毎に異なる組織、事業者などで管理することで、より安全なシステムが構築できる。
演算を終えた各サーバは、演算結果を分析機関に送る。分析機関では、すべてのサーバからの演算結果を統合する。この統合方法は、入力データの加工方法と、各サーバに定められた演算によって決まるが、秘密分散の逆演算とみなすことができる演算を行う。この秘密分散の逆演算を行うことにより、分析機関では、秘匿化されたデータの可読化を行う。
実験では、この可読化されたデータに対しゲノム分析ツールを用いて、典型的
ゲノム分析、非典型的ゲノム分析の 2 種類の分析を行った。

 典型的ゲノム分析（ゲノム変異分析）：ゲノム変異が起こる割合を年代や性別ごとに集計グラフ化する。

 非典型的ゲノム分析（連鎖不平衡ブロック生成）：世代間の遺伝のし易さを変異場所のブロックで示す分析手法を利用。
これらの実験を通じ、秘密計算の処理の高速性と、分析に秘密計算が適用でき
ることが実証された。
例２．創薬向けの実証実験
創薬向けの予測モデルの構築において、秘密計算を利用した方法の実証実験も行われている [115]。創薬においては、企業毎に種々の原料が使われ、その構造デー
タは各企業の機密情報である。このため、データを企業から持ち出すことや、企業間で共有し、新たな創薬を行うことは困難であった。また、最近では、創薬にも機械学習が多く用いられている。機械学習では、学習によるモデルの構築が必要となるが、学習データが多いほど精度の高い学習が可能となる。このため、図 2.2に示すような、秘密計算を用いた連合学習を行い、モデル構築の実証実験が行われた。
実証実験では、モデル構築に参加する複数の組織を想定している。各組織で個別のデータを用いて機械学習を行う。機械学習により出力されたモデルのパラメー

30‫׼‬՛‫ב״‬ೲฝ֘‫׊‬ᅃቹጮ֪૱్֘‫׊‬ँ஽ᆾ‫׼‬՛‫״‬ँ஽ᆾ‫׼‬՛‫״‬ျ஽ଢ଼֭‫ؠ׼ؗ‬ँ஽ᆾ‫׼‬՛‫״‬図 2.2

実証実験２：創薬向け予測モデル（NEC 提供）

タを、秘密分散し、とりまとめを行う複数のサーバに送る。秘密分散を行う前のデータは、ある意味統計加工されたデータとなっており、ここから元データを知ることは困難である。複数のサーバでモデルを統合するが、その際に秘密計算を利用して統合モデルを作成する。サーバでモデルを統合する場合には、センターと各組織の間で通信するデータはモデルそのものではなく、差分値だけを扱うことで盗聴耐性を持たせることも可能である。
この実証実験では、データを暗号化したまま計算処理ができる秘密計算を用いた複数組織間のデータ統合の有効性を検証した。
例１において、サーバへのデータ入力、データの加工方法はデータを分割する方法が記されているが、加工方法は応用事例に応じて多種多様である。特に、個人のデータを利活用する場合、個人の同意を得ることが、個人情報保護法で求められている。ただし、個人のデータに対しある加工を施すことで、制限はあるものの個人のデータの利活用が可能となっている。この加工技術が、匿名加工や、仮名加工である。

 匿名加工： 各医療機関が、複数のデータを一つにまとめ、外部への提出用
データを作成する。データはまとめられ、加工データから、元データを知ることは不可能なため匿名加工したこととなる。

 仮名加工： 各医療機関では、実名と匿名の対応表を作り、外部への提出用に匿名のデータ表を作成する。匿名化されており、実名を知ることは不可能
なため、仮名加工したこととなる。
これらは、個人情報保護法に対応した個人データの利活用をするためにも、必須の技術となっている。

31

また、商用に供するために、各社で秘密計算のライブラリを整えている。MPC、準同型暗号を用いた方式、TEE を利用した方式など、利用者に合わせて利用できる。これらのライブラリを用いて、ゲノム解析、創薬の実証実験以外にも、

 商店街の活性化のイベントを行う際に、その費用対効果をしるために、各店舗の売上情報を秘密計算を用いて統合分析する統計値処理

 銀行における不正取引リスクを分析するために、各銀行が持つリスクデータを統合して分析するリスク分析の AI
 プラントのログ解析
等、多くの応用が検討されている。第 3 項目のプラントのログ解析は、個人情報保護とは直接は関係がない項目であるが、同じ要素技術で解決策を得られる項目
例として、ここに挙げている。
■データへのアクセス制御−セキュアなパブリッククラウドの利用

企業、団体、組織（以後、組織）からの種々のサービス提供のみならず、組織内における電子データのやりとりにおいては、電子データは的確に保護されなければならない。これらの目的のために、属性ベース暗号や検索可能暗号と呼ばれる高機能暗号技術を利用して、データの保護、データへのアクセス制御を社会実装したケースがある。これ
らの事例を以下に紹介する。
例１．組織内文書管理−属性ベース暗号技術の活用例
組織内の共有スペースに電子データを置き、データの共有をはかることはよく行われている。但し、電子データの中には、一部のメンバだけで共有したいデータもある。この場合、共有するデータにアクセス制御をかける必要がある。さらに、暗号化により他のメンバーに閲覧できないようにすることで、強固なアクセス制
御が可能となる。以下に紹介する社会実装例では、属性ベース暗号（3.1.2 章参照）
を利用して、強固なアクセス制御を実現している。
属性ベース暗号とは、暗号文を復号するための条件を設定し、復号できるユー
ザを制御できる暗号技術である。復号鍵を所有しないユーザは、当然、暗号文を復号することはできない。さらに、復号鍵を持っているユーザであっても、条件に適合しない場合は復号できない。すなわち、暗号化とデータへのアクセス制御が一体化した技術である。
属性ベース暗号の論文での提案時より、活用例として、企業内や学校内での文書管理が記載されている。具体的には、企業内の役員だけが閲覧できる文書、部長以上の役職であれば閲覧できる文書、ある部署（例えば総務部のみ）の職員だけ
32

が閲覧できる文書、社員であれば誰でも閲覧できる文書など、文書の閲覧には閲覧できるユーザに条件がつけられていることが多い。ユーザの役職、所属部署などを属性と見て、職員 A さんは属性（人事部、課長）であり、所属 B さんは属性（総務部、部長）を持つとする。そして、職員 A さんには、属性（人事部、課長）に対応する復号鍵が渡され、人事部あての文書や、課長以上が閲覧できる文書、職員全員が閲覧できる文書が閲覧可能となる。職員 B さんは、属性（総務部、部長）に対応する復号鍵が渡され、総務部あての文書や、部長以上が閲覧できる文書、職員全員が閲覧できる文書が閲覧可能となる。文書の作成者は、閲覧者の属性を意識して、文書を暗号化することになる。ここで紹介した暗号技術が属性ベース暗号となる。より正確には、属性ベース暗号には大きく分けて 2 種類、暗号文に条件を入れる場合と、暗号鍵に条件を入れておく場合があり、ここで紹介した事例は暗号鍵に条件を入れた属性ベース暗号となる。
属性ベース暗号のその他の利用方法として、

 複数の工場や事業所を所有する企業における、ロケーション／役職に応じた文書管理。

 クラウドサービスに文書を保管し、文書毎にアクセス可能な企業を制御できるファイル交換サービス。
などがあり、属性ベース暗号関連のソフトウェアがライブラリとして製品化されている [116, 117]。これらは、Windows ベースで開発されており、各種のインターフェース、ディレクトリサービスとの連携までも考えられている。
例２．DB に保存されたデータの保護−検索可能暗号技術の活用例
組織内、組織外を問わず、電子データをサーバに置いて管理することはよく行われている。電子データはサーバ内のデータベース（DB）で管理され、ユーザからのデータ追加や検索などに応じている。通常、サーバもしくはＤＢの管理者はＤＢ
内のデータを閲覧できる。悪意のある管理者であれば、データを悪用することは容易である。管理者の善意に頼るのみではなく、技術的な対策も求められる。さ
らに、近年はサイバー攻撃が多くなり、この対策も求められている。このため、Ｄ
Ｂのデータを管理者やサイバー攻撃者が知らない鍵によって暗号化することが対策として考えられてきた。さらに、ユーザからの検索キーワードも暗号化することで、何を検索しているのか等の情報も漏洩しないことが求められている。これ
らの要求に応える技術として、検索可能暗号（3.3.7 章参照）を利用した社会実装
例を以下に紹介する。

33

検索可能暗号とは、データベース（DB）に暗号化されたデータを復号することなく検索できる暗号技術である。DB 内のデータはすべて暗号化されているため、DB が保管されているサーバが攻撃され、データが漏洩したとしても、安全性が担保できる。さらに、検索のためのキーワードも暗号化されているため、暗号化されていない通信路を経由しての検索であっても安全である。さらに、暗号化されたキーワードや、データをサーバ内で復号することがないため、サーバの管理者に対しても安全性が担保される。
従来、DB のデータは平文で管理されていた。もしくは、DB に平文データが入力された後、DB が暗号化を行い、暗号化されたデータを保存していた。前者のように DB で平文を管理する場合、検索も高速である。すなわち、平文の検索キー
ワードにより検索が行われるためである。ただし、DB にアクセス可能なユーザであったり、サイバー攻撃によって DB の中身が漏洩する場合を考えると、情報漏洩のリスクは高いものであった。また検索キーワードも平文であり、検索キーワー
ドからも情報が漏洩していた。後者のように、DB が暗号化を行う場合は、ＤＢに保存されているデータは安全に保存される。ただし、検索はやや遅くなる。すな
わち、データの検索時には、保存されている暗号文を復号した後に、検索キーワー
ドとのマッチングを行い検索結果を出力するため、暗号文を復号する時間が必要となる。さらに、セキュリティの観点からすると、DB の管理者が悪意を持つ場
合、および、サイバー攻撃に DB がさらされた場合、情報漏洩のリスクが大きくなる。すなわち、どちらの場合も、ＤＢが保存している秘密鍵の漏洩が考えられる。
秘密鍵の漏洩は、ＤＢが保存しているすべての暗号化データが平文データとなって漏洩することと同じ結果となる。また、メモリ解析もセキュリティリスクの一つであり、攻撃として考えられる。すなわち、検索処理は多くの場合、サーバのメ
モリ上で行われる。このため、管理者やマルウェアがメモリを監視することで平文情報がわかってしまう可能性がある。
これらのセキュリティリスクを回避する目的で開発された技術が検索可能暗号である。検索可能暗号を利用することで、ＤＢに保存されているデータは暗号化され、さらに、復号鍵をＤＢは所持していない。すなわち、ＤＢの管理者が悪意を持って情報を漏洩させた場合、および、サイバー攻撃にＤＢがさらされたとしても、漏洩するのは暗号化されたデータだけであり、復号鍵は漏洩しない。さらに、
検索キーワードも暗号化されており、ＤＢ内で復号されることはないため、検索キーワードからの情報漏洩もない。
検索可能暗号の実装例として、

 クラウドにＤＢ管理を委託した場合に、ＤＢ内のデータを検索するセキュア
34

•
•
•

図 2.3

社会実装例：パブリッククラウドを用いたデータ共有

なアクセスを可能とする秘匿検索サービスなどがあり、検索可能暗号関連のソフトウェアがライブラリとして製品化されている [118]。
例３．パブリッククラウドを用いたデータ共有
多くの企業、団体、組織（以後、組織）では協業の効率化等の目的でパブリックク
ラウドを利用する機会が多くなっている。例えば、自組織のサービスをパブリック
クラウド上で展開したり、逆に、他組織のサービスを利用する際に利用することもある。さらに、パブリッククラウド上で展開されている機能／ライブラリ群なども多くなったこともあり、パブリッククラウドの活用が加速されている。このよ
うな状況下で、パブリッククラウドに置かれるデータの安全性を担保する目的で、属性ベース暗号と検索可能暗号の両方を社会実装したケースがあるので紹介する。
複数の組織で電子データを共有する場合にパブリッククラウドを利用すること
で、サービスの効率化を図れる場合がある。組織が所有する電子データが少ない
場合、他組織と共有する電子データの量が少なく、関連する他組織の数も少なくなる。このような場合には、情報を共有するとしても、メールにデータを添付した
り、記録媒体で渡すなどの、小規模な手段で情報共有が可能であった。これに対し、近年では、組織が持つ電子情報が膨大になり、他組織と共有する電子データの量が多くなり、関連する他組織の数も多くなり、状況が大きく変わっている。
例えば（図 2.3 参照）、ある組織（M 社）が業務効率化のために、他組織（A 社）と別の他組織（B 社）に作業委託を行うことがあり、M 社と A 社、B 社は機密デー

35タや顧客データを共有することもある。そして、A 社と共有する情報と B 社と共有するデータには、共通のデータもあり、異なるデータもある。そして、M 社は、社内にオンプレミス型の巨大な DB（オンプレ DB）が構築されていることはよくある状況である。委託先 A 社、B 社は M 社にとっては他組織であるため、M 社のオンプレ DB に A 社や B 社がアクセスすることは、委託に関係しないデータへのアクセスに対する危惧もあり、セキュリティ上の理由で好まれない。このため、パブリッククラウド（以後、サーバ）を利用して、オンプレ DB の中の共有すべきデータだけをサーバに置き、テンポラルな DB（テンポラリ DB）を作成し、A社、B 社とデータ共有を行うことが考えられている。
テンポラリ DB を利用し、オンプレ DB 内の必要最小限のデータ共有であったとしても、M 社にとっては機密データであるため、このデータ共有を安全に行うことは重要である。さらに、利用するサーバの管理者は、容易にテンポラリ DBに置かれたデータにアクセスできる。さらには、サーバがパブリックであるが故に、サーバの管理者、M 社、A 社、B 社とは関係のない、不特定多数のユーザがアクセスする可能性もある。
このような状況であっても、テンポラリ DB に置かれた機密データを保護するために、属性ベース暗号と検索可能暗号を利用する。M 社が共有するデータをテ
ンポラリ DB に置く際に、委託に必要なデータを抽出して、“A 社のみが閲覧できるデータ”、“B 社のみが閲覧できるデータ”、“A 社と B 社の両方が閲覧できるデータ” の 3 種類に分類する。そして、属性ベース暗号を利用して、“属性 A”、“属性 B”、“属性 A または属性 B” の属性を持つ復号鍵であれば、復号できるようにそれぞれのデータに対して暗号化を行い、暗号文をテンポラリ DB に置く。そして、A 社には “属性 A” を持つ復号鍵を、B 社には “属性 B” を持つ復号鍵を配布しておく。また、これらのデータを検索できるように、共有するデータからキーワードを抽出し、検索可能暗号を用いて、キーワードを暗号化し、テンポラリ DBに置く。A 社、B 社はテンポラリ DB のデータを閲覧する際、まず、検索キーワー
ド（クエリ）を検索可能暗号を用いて暗号化して、暗号化クエリをテンポラリ DBに送る。テンポラリ DB では、検索可能暗号の検索機能を用いて検索結果を出力し、A 社もしくは B 社に返送する。
検索結果を受領した A 社もしくは B 社では、属性ベース暗号の復号鍵を用いて、受領したデータを復号するが、A 社が持つ復号鍵は “属性 A” を持ち、B 社が持つ復号鍵は “属性 B” を持つ。このため、A 社は、“A 社のみが閲覧できるデータ” と “A 社と B 社の両方が閲覧できるデータ” を復号することができるが、“B社のみが閲覧できるデータ” を復号することはできない。逆に、B 社は、“B 社の36

みが閲覧できるデータ” と “A 社と B 社の両方が閲覧できるデータ” を復号することができるが、“A 社のみが閲覧できるデータ” を復号することはできない。
この一連の属性ベース暗号と検索可能暗号の実装により、データ閲覧に対するアクセス制御と、いわゆる秘匿検索、暗号化したままでの検索が可能となり、テン
ポラリ DB 内データに対する不要なデータ閲覧を防ぎ、キーワードからの情報漏洩を防いでいる。

参考文献[1] CRYPTREC: “電子政府における調達のために参照すべき暗号のリスト”.
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r6.pdf.
[2] S. Mitsunari: “MCL: a Portable and Fast Pairing-Based Cryptography
Library”. GitHub Repository.
[3] Stanford University: “The Pairing-Based Cryptography Library”. https://crypto.stanford.edu/pbc/.
[4] Voltage: “Voltage SecureMail”. https://www.microfocus.com/en-us/
cyberres/data-privacy-protection/secure-mail.
[5] N. Suilvan: “Geo Key Manager: How It Works”. The Cloudﬂare Blog,
https://blog.cloudflare.com/geo-key-manager-how-it-works/.
[6] IETF: “RFC 5091: Identity-Based Cryptography Standard (IBCS)#1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems”.
[7] IETF: “RFC 5408: Identity-Based Encryption Architecture and Supporting Data Structures (January 2009)”.
[8] IETF: “RFC 5409：Using the Boneh-Franklin and Boneh-Boyen IdentityBased Encryption Algorithms with the Cryptographic Message Syntax(CMS)”.
[9] IETF: “RFC 6267：MIKEY-IBAKE: Identity-Based Authenticated Key
Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet
KEYing (MIKEY)”.
[10] IETF: “RFC 6539：IBAKE: Identity-Based Authenticated Key Exchange”.
[11] IETF: “RFC 6507：Elliptic Curve-Based Certiﬁcateless Signatures for
Identity-Based Encryption (ECCSI)”.
[12] IETF: “RFC 6508：Sakai-Kasahara Key Encryption (SAKKE)”.
[13] IEEE: “IEEE Std 1363.3-2013 - IEEE Standard for Identity-Based Cryptographic Techniques using Pairings”.
37

[14] ISO/IEC: “ISO/IEC 18033-5:2015 - Identity-Based Ciphers”.
[15] D. K. Smetters and G. Durfee: “Domain-Based Administration of IdentityBased Cryptosystems for Secure Email and IPSEC”, USENIX Security
Symposium 2003 (2003).
[16] S. Ruoti, N. Kim, B. Burgon, T. W. vander Horst and K. E. Seamons:“Confused Johnny: When Automatic Encryption Leads to Confusion and
Mistakes”, Usable Privacy and Security, ACM (2013).
[17] S. Ruoti, J. Andersen, T. Hendershot, D. Zappala and K. E. Seamons:“Private Webmail 2.0: Simple and Easy-to-Use Secure Email”, User Interface Software and Technology, ACM, pp. 461–472 (2016).
[18] S. Meiklejohn, K. Mowery, S. Checkoway and H. Shacham: “The Phantom
Tollbooth: Privacy-Preserving Electronic Toll Collection in the Presenceof Driver Collusion”, USENIX security symposium, Vol. 201, No. 1 (2011).
[19] L. Veltri, G. Morabito, S. Salsano, N. Blefari-Melazzi and A. Detti: “Supporting Information-Centric Functionality in Software Deﬁned Networks”,
IEEE ICC 2012 (2012).
[20] M. Santos, B. D. Oliveira, C. Margi, B. Astuto, T. Turletti, I. S. Antipolis
and K. Obraczka: “Software-Deﬁned Networking Based Capacity Sharing
in Hybrid Networks”, IEEE ICNP 2013 (2013).
[21] M. Santos, B. Astuto, K. Obraczka, T. Turletti, B. D. Oliveira and
C. Margi: “Decentralizing SDN’s Control Plane”, IEEE Conference on
Local Computer Networks 2014 (2014).
[22] 三 菱 電 機 IT ソ リ ュ ー シ ョ ン ズ：“パ ッ ケ ー ジ プ ラ ス (R) ト ラ ン ス
ポ ー タ ー”. https://www.mdsol.co.jp/products/general_affairs/
transporter.html.
[23] テ キ サ ス 大 学：“Ciphertext-Policy Attribute-Based Encryption：PBC(Pairing-Based Cryptography) ライブラリ（C ライブラリ）を利用したライブラリ”. http://acsc.cs.utexas.edu/cpabe/.
[24] “Java Pairing-Based Cryptography Library (JPBC): [GGH+13] 方式を利用した Java による高機能暗号ライブラリ”. http://gas.dia.unisa.it/
projects/jpbc/.
[25] “OpenABE: [27] 方式の変形版を利用した C/C++ オープンソースライブラリ”. https://github.com/zeutro/openabe.
[26] S. Garg, C. Gentry, S. Halevi, A. Sahai and B. Waters: “Attribute-Based38Encryption for Circuits from Multilinear Maps”, CRYPTO 2013, Vol. 2,
Springer-Verlag, pp. 479–499 (2013).
[27] V. Goyal, O. Pandey, A. Sahai and B. Waters: “Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data”, ACM CCS 2006,
pp. 89–98 (2006).
[28] AACS: “Advanced Access Content System (AACS) Introduction and Common Cryptographic Elements Book”. https://aacsla.com/wp-content/
uploads/2019/02/AACS_Spec_Common_Final_0953.pdf.
[29] D. Naor, M. Naor and J. Lotspiech: “Revocation and Tracing Schemes forStateless Receivers”, CRYPTO 2001, Springer-Verlag, pp. 41–62 (2001).
[30] https://aacsla.com/.
[31] NICT, 神戸大学, エルテス：“プライバシー保護深層学習技術を活用した不正送金検知の実証実験において金融機関 5 行との連携を開始”. https://www.nict.go.jp/press/2020/05/19-1.html, https://www.kobe-u.ac.
jp/research_at_kobe/NEWS/collaborations/2020_05_19_01.html.
[32] “DeepProtect”. https://deepprotect.nict.go.jp/.
[33] L. T. Phong, Y. Aono, T. Hayashi, L. Wang and S. Moriai: “PrivacyPreserving Deep Learning via Additively Homomorphic Encryption”,
Vol.13, No.5, pp. 1333–1345 (2018).
[34] 日本経済新聞：“Suica 履歴を「秘密計算」データの中身、読まずに分析”.
https://www.nikkei.com/article/DGXZQOUC233NT0T20C21A6000000/.
[35] P. Paillier: “Public-Key Cryptosystems Based on Composite Degree Residuosity Classes”, EUROCRYPT 1999, Springer-Verlag, pp. 223–238 (1999).
[36] Z. Brakerski, C. Gentry and V. Vikuntantathan: “(Leveled) Fully Homomorphic Encryption without Bootstrapping”, ITCS 2012, ACM, pp.
309–325 (2012).
[37] J. Cheon, A. Kim, M. Kim and Y. Song: “Homomorphic Encryption
for Arithmetic of Approximate Numbers”, ASIACRYPT 2017, Vol. 1,
Springer-Verlag, pp. 409–437 (2017).
[38] “HElib (Homomorphic Encryption library)”.
https://github.com/
homenc/HElib.
[39] Z. Brakerski: “Fully Homomorphic Encryption without Modulus Switchingfrom Classical GapSVP”, CRYPTO 2012, Springer-Verlag, pp. 868–886(2012).

39[40] J. Fan and F. Vercauteren: “Somewhat Practical Fully Homomorphic Encryption”. ePrint 2012/144.
[41] “Simple Encrypted Arithmetic Library”. https://www.microsoft.com/
en-us/research/project/microsoft-seal/.
[42] “HEAAN”. https://github.com/snucrypto/HEAAN.
[43] L. Ducas and D. Micciancio: “FHEW: Bootstrapping Homomorphic Encryption in Less Than a Second”, EUROCRYPT 2015, Springer-Verlag,
pp. 617–640 (2015).
[44] I. Chillotti, N. Gama, M. Georgieva and M. Izabachène: “Faster Fully Homomorphic Encryption: Bootstrapping in Less Than 0.1 Seconds”, ASIACRYPT 2016, Springer-Verlag, pp. 3–33 (2016).
[45] “PLISADE”. https://palisade-crypto.org/.
[46] “Lattigo”. https://github.com/ldsec/lattigo.
[47] “CRYPTOLAB”. https://www.cryptolab.co.kr/eng/product/heaan.
php.
[48] “Homomorphic
Encryption
Standardization”.
https:
homomorphicencryption.org/standard/.
[49] ISO/IEC: “ISO/IEC 18033-6:2019 - Homomorphic Encryption”. https://www.iso.org/obp/ui/#iso:std:iso-iec:18033:-6:ed-1:v1:en.
[50] NuCypher: “Umbral: A Threshold Proxy Re-Encryption Scheme”.
https://raw.githubusercontent.com/nucypher/umbral-doc/master/umbral-doc.pdf.
[51] ITmedia: “東 芝「 デ ジ タ ル 貸 金 庫 」”. https://www.itmedia.co.jp/
pcuser/articles/1211/21/news053.html.
[52] 川 合, 小 関, 柴 田, 大 松：“属 性 ベ ー ス 署 名 を 用 い た ブ ロ
ッ ク チ ェ ー ン”, DICOMO2017, 情 報 処 理 学 会, pp. 669–671(2017). https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=190099&file_id=1&file_no=1.
[53] 堀川, 高谷, S. Z. Fazekas, 山村：“属性ベース署名を用いた匿名シングルサ
インオンの提案” (2017). https://www.kurims.kyoto-u.ac.jp/~kyodo/
kokyuroku/contents/pdf/2051-26.pdf.
[54] S. Hirose and J. Shikata: “Non-Adaptive Group-Testing Aggregate MAC
Scheme”, ISPEC 2018, Springer-Verlag, pp. 357–372 (2018).
[55] S. Sato and J. Shikata: “Interactive Aggregate Message Authentication

40

Scheme with Detecting Functionality”, AINA 2019, Springer Nature, pp.
1316–1328 (2019).
[56] ITU-T: “Recommendation ITU-T X.1366: Aggregate message authentication schemes for Internet of things environment”. https://www.itu.int/
ITU-T/recommendations/rec.aspx?rec=14262&lang=en.
[57] 日本ネットワーク・オペレーターズ・グループ：“アグリゲート署名を用いた
bgpsec の改良”. https://www.janog.gr.jp/meeting/janog43/program/
bgpsec/.
[58] ARMORY: “Armory Secure Wallet”. https://www.bitcoinarmory.com/.
[59] “ERC: Standard API for multisig wallet smart contracts #763”. https://github.com/ethereum/EIPs/issues/763.
[60] ISO/IEC: “ISO/IEC 20008-2:2013 - Information technology - Security techniques ― Anonymous digital signatures ― Part 2: Mechanisms using a group public key”. https://www.iso.org/standard/
56916.html, https://www.iso.org/obp/ui/#iso:std:iso-iec:20008:-2:ed-1:v2:en.
[61] ISO/IEC: “ISO/IEC 11889 - ISO/IEC 11889-1:2015 - Information technology ―Trusted platform module library ― Part 1: Architecture”.
https://www.iso.org/standard/66510.html.
[62] S. Noether: “Ring Conﬁdential Transactions”. ePrint 2015/1098.
[63] P. Wuille, J. Nick and T. Ruﬃng: “Bitcoin Improvement Proposal 340”
(2020). https://github.com/bitcoin/bips/blob/master/bip-0340.
mediawiki.
[64] K. McCusker and B. Spector: “Qredo Network” (2020). https://www.
qredo.com/qredo-yellow-paper.
[65] J. Doerner, Y. Kondi, E. Lee and A. Shelat: “Secure Two-party Threshold
ECDSA from ECDSA Assumptions”. ePrint 2018/499.
[66] フレセッツ株式会社：“世界初、フレセッツが hsm を活用した完全オフライ
ン環境でのセキュアなマルチシグ実装に成功” (2020). https://prtimes.
jp/main/html/rd/p/000000017.000028896.html.
[67] Coinbase 株 式 会 社：“What is a Dapp Wallet”.
https://help.
coinbase.com/en/coinbase/trading-and-funding/trade-on-dex/
what-is-a-dapp-wallet.
[68] DFINITY: “Threshold ECDSA Signatures”. https://forum.dfinity.

41

org/t/threshold-ecdsa-signatures/6152.
[69] NIST: “Threshold Schemes for Cryptographic Primitives: Challenges andOpportunities in Standardization and Validation of Threshold Cryptography”. https://csrc.nist.gov/publications/detail/nistir/8214/
final.
[70] NIST: “NIST Roadmap Toward Criteria for Threshold Schemes for Cryptographic Primitives”. https://nvlpubs.nist.gov/nistpubs/ir/2020/
NIST.IR.8214A.pdf.
[71] NIST: “NIST Roadmap Toward Criteria for Threshold Schemes
for Cryptographic Primitives”. https://csrc.nist.gov/news/2022/
nist-requests-comments-on-ir-8214b-initial-public.
[72] IETF: “Two-Round Threshold Signatures with FROST”. https://
datatracker.ietf.org/doc/draft-irtf-cfrg-frost/.
[73] 保坂, 多田, 加藤：“秘密分散法とその応用”, 東芝レビュー, 62, 7 (2007).
[74] “NRI: Windows Azure と秘密分散法を利用したセキュリティ性の高い「世界分散ストレージサービス」”, https://cloud.watch.impress.co.jp/
docs/column/cloud/493419.html.
[75] S. Shin, S. Yamada, G. Hanaoka, Y. Ishida, A. Kunii, J. Oketani, S. Kunii and K. Tomomura: “An Extended CTRT for AES-256”, WISA 2019,
Springer-Verlag, pp. 79–91 (2019).
[76] “ZENMU-AONT に関する論文が 国際会議で best paper premium awardを受賞”, https://www.atpress.ne.jp/news/191661.
[77] “Alchemy - What is MPC wallet?”, https://www.alchemy.com/
overviews/mpc-wallet.
[78] “ISO/IEC 19592-2:2017 Information technology - Security techniques Secret sharing - Part 2: Fundamental mechanisms”.
[79] R. Cleve, D. Gottesman and H.-K. Lo: “How to Share a Quantum Secret”,
Physical Review Letters, 83, 3, pp. 648–651 (1999).
[80] G. R. Blakley and C. Meadows: “Security of ramp schemes”, CRYPTO
1984, Springer-Verlag, pp. 242–268 (1984).
[81] 山本：“(k, L, n) しきい値秘密分散システム”, 電子通信学会論文誌, J68-A,
9, pp. 945–952 (1985).
[82] M. Itoh, A. Saito and T. Nishizeki: “Secret Sharing Scheme Realizing
General Access Structure”, IEEE Globecom 1987, pp. 99–102 (1987).

42

[83] R. Cramer, I. Damgård and Y. Ishai: “Share Conversion, Pseudorandom Secret-Sharing and Applications to Secure Computation”, TCC 2005,
Springer-Verlag, pp. 342–362 (2005).
[84] T. Araki, J. Furukawa, Y. Lindell, A. Nof and K. Ohara: “HighThroughput Semi-Honest Secure Three-Party Computation with an Honest Majority”, ACM CCS 2016, pp. 805–817 (2016).
[85] K. Chida, D. Genkin, K. Hamada, D. Ikarashi, R. Kikuchi, Y. Lindelland A. Nof: “Fast Large-Scale Honest-Majority MPC for Malicious Adversaries”, CRYPTO 2018, Springer-Verlag, pp. 34–64 (2018).
[86] R. Kikuchi, K. Chida, D. Ikarashi, W. Ogata, K. Hamada and K. Takahashi: “Secret Sharing with Share-Conversion: Achieving Small Share-Sizeand Extendibility to Multiparty Computation”, IEICE Trans., E98-A(1),pp. 213–222 (2015).
[87] H. Krawczyk: “Secret sharing made short”, CRYPTO 1993, SpringerVerlag, pp. 136–146 (1993).
[88] 千 葉 大 学 病 院, NTT Com：“秘 密 計 算 デ ィ ー プ ラ ー ニ ン グ 」な ど の技 術 を 活 用 し た 臨 床 デ ー タ 分 析”. https://www.ntt.com/about-us/press-releases/news/article/2021/0208.html.
[89] NEC, 大 阪 大 学：“医 療 デ ー タ 活 用”.
https://jpn.nec.com/rd/
technologies/201805/index.html.
[90] CYBERNETICA: “収入と教育履歴の分析”. https://sharemind.cyber.
ee/big-data-analytics-protection/.
[91] Cosmian: “エネルギー供給の最適化”. https://cosmian.com/use-case/.
[92] MPC Alliance. https://www.mpcalliance.org/.
[93] 秘密計算コンソーシアム. https://secure-computation.jp/.
[94] 秘密計算研究会. https://securecomputing.jp/.
[95] NIST: “NIST Project on Privacy-Enhancing Cryptography (PEC)”.
https://csrc.nist.gov/projects/pec.
[96] ISO/IEC: “ISO/IEC 4922-1/2 Information security ― Secure multiparty
computation”. https://www.iso.org/standard/80508.html.
[97] Curv.
https://medium.com/@william_97682/
curv-mpc-is-not-key-sharding-276b020130c4.
[98] INGBank.
https://www.ingwb.com/en/
insights/distributed-ledger-technology/43

ing-launches-major-addition-to-blockchain-technology.
[99] https://z.cash/technology/.
[100] Ernst & Young.
https://www.ey.com/en_gl/news/2019/12/
ey-releases-third-generation-zero-knowledge-proof-blockchain-\https://assets.ey.
technology-to-the-public-domain,com/content/dam/ey-sites/ey-com/ja_jp/topics/library/info-sensor/2020/12/pdf/ey-japan-info-sensor-2020-12-08.pdf.
[101] ZKProof Standards. https://zkproof.org/, https://docs.zkproof.
org/pages/reference/reference.pdf.
[102] TechCrunch:“Kalepso Looks to Break into The Crowded Encrypted Database Space” (2018). https://techcrunch.com/2018/11/
29/kalepso-database-encryption-battlefield-berlin/.
[103] Coinspeaker:“Decentralized Service Protocol, Automata Network, Launches a Solution for the Miner Extractable Value
https://www.coinspeaker.com/(MEV)
Issue”(2021).
automata-network-miner-extractable-value-conveyor/.
[104] S. Wang, X. Ding, R. H. Deng and F. Bao: “Private Information Retrieval Using Trusted Hardware”, ESORICS 2006, Springer-Verlag, pp.
49–64 (2006).
[105] M. Melucci and R. Baeza-Yates: “Advanced Topics in Information Retrieval”, Vol. 33, Springer (2011).
[106] D. Augot, F. Levy-dit Vehel and A. Shikfa: “A Storage-Eﬃcient and Robust Private Information Retrieval Scheme Allowing Few Servers”, CANS
2022, Springer International Publishing, pp. 222–239 (2022).
[107] “事業者向け暗号資産ウォレット開発のフレセッツ、暗号資産ウォレット
ユーザに対するプライバシー向上技術の開発に成功”. https://prtimes.
jp/main/html/rd/p/000000014.000028896.html.
[108] “Microsoft sealpir”. https://github.com/microsoft/SealPIR.
[109] MIT: “CryptDB”. http://css.csail.mit.edu/cryptdb/.
[110] “Kafedb: End-to-end structually-encrypted relational database system”.
https://zheguang.github.io/kafedb/.
[111] 日 立 製 作 所：“秘 匿 情 報 管 理 サ ー ビ ス 匿 名 バ ン ク”.
https://www.hitachi.co.jp/products/it/harmonious/cloud/service/
tokumei/index.html.

44

[112] 三 菱 電 機：“部 分 一 致 対 応 秘 匿 検 索 基 盤 ソ フ ト ウ ェ ア”.
https://www.mitsubishielectric.co.jp/corporate/randd/list/info_
tel/a29/index.html.
[113] G. Amjad, S. Kamara and T. Moataz: “Forward and Backward Private
Searchable Encryption with SGX”, European Workshop on Systems Security 2019, Vol. 4, pp. 1–6 (2019).
[114] NEC, 大阪大学：“複数機関が保有するゲノム情報をプライバシー侵害リスクを抑えて解析できることを実証”. https://jpn.nec.com/press/201907/
20190723_03.html.
[115] NEC: “連合学習技術と秘密計算技術を用いた創薬における予測モデル構築に関する実証実験を実施”. https://jpn.nec.com/press/202203/
20220311_01.html.
[116] 三 菱 電 機：“三 菱 情 報 セ キ ュ リ テ ィ ソ フ ト ウ ェ ア feﬁleprotection”. https://www.mitsubishielectric.co.jp/business/security/
fileprotect/index.html.
[117] 三菱電機：“関数型暗号とクラウドサービスを利用した機密情報ファイル交換サービス「パッケージプラス (r) トランスポーター」の提供開始”. https://www.mdsol.co.jp/newsrelease/doc/information_20160125.pdf.
[118] 三菱電機：“Mistyguard ＜検索可能暗号＞ cizouxlib を開発”. https://www.
mdis.co.jp/news/press/2021_1028.html.

45

第3章

主な高機能暗号技術のアルゴリズム・プロトコルとその性能

463.1 守秘を目的とした高機能暗号技術
3.1.1 ＩＤベース暗号
ID ベース暗号（Identity-based encryption, IBE） は、ID をはじめとする
任意の文字列を公開鍵に利用可能とする公開鍵ベースの暗号化手法である。1984
年にそのコンセプトを提案した Shamir [1] により、公開鍵の情報として ID 情報を利用可能とすることから ID ベース暗号と名付けられたが、本質的には ID 情
■特徴

報の代表的な具体例である電子メールアドレスやその他の識別情報などが利用可能であり、さらには ID 情報のみならず任意の情報を公開鍵の情報として利用可能である。公開鍵である ID 情報から容易にその所有者を特定することができることから、（通常の公開鍵暗号では必要となる）公開鍵暗号基盤 （Public-Key

Infrastructure, PKI） が発行する公開鍵証明書が不要となる。一方で、公開鍵暗号とは異なり、IBE では暗号の作成者（送信者）と秘密鍵をもつユーザ以外に、各ユーザの鍵生成を行う鍵生成センタ（Private-Key Generator, PKG） が存在する。このような機関を想定しなければ、誰でも任意の ID に対して秘密鍵を生成可能となり、安全性が担保できない。また、IBE を実現するうえで最も重要な安全性が結託耐性である。結託耐性とは、多数のユーザが結託し自身の ID の秘密鍵を共有したとしても、結託に関与していないユーザの ID 宛の暗号文の解読が難しいことを保証する安全性である。
さらに、IBE は他の暗号技術を構成するための暗号要素技術として利用価値が高い。例えば、IBE を要素技術として用いることで、秘密鍵の漏洩に耐性のある
鍵隔離暗号 [2] や前方秘匿暗号 [3]、暗号文が復号可能となる期間を指定可能な時
刻特定暗号 [4]、強い安全性を満たす公開鍵暗号 [5] 等、様々な暗号技術を実現できることが知られている。
■方式の歴史・進展

結託耐性を持つ IBE の効率的な実現は難しく、Shamir によって IBE のコンセプトが提唱された 1984 年から 15 年以上が経過して初めて、2000
年に境-大岸-笠原により ID ベースの鍵共有方式 [6] が日本国内で提案された。さらに、2001 年に Boneh-Franklin による IBE 方式 [7] が海外で提案された。これらの方式の特筆すべき点は、Pairing 写像が初めて暗号構成に利用されたことである。

Pairing 写像は 2 入力 1 出力の写像であり、暗号用途では楕円曲線上の Pairing 写像を用いる。特に、Pairing 写像のもつその双線形性によって、IBE を始めとする多くの高機能暗号技術の実現が可能となった（双線形性については具体的な構成
例で説明する）実際、Pairing 写像の登場を皮切りに多くの（高機能）暗号技術の47

構成研究が発展することとなった。

IBE 研究においても、Pairing 写像を用いた構成手法が現実的な IBE の実現方
法として主流であり、活用事例や標準化のほとんどに Pairing 写像を用いた構成手法が採用されている。Boneh-Franklin IBE の提案以降の主要な成果として、まず2004 年の IBE 方式 [8] が挙げられる。この方式は Boneh-Franklin IBE とは異なり（現実には存在し得ない）理想的なハッシュ関数が構成に不要な一方で、保証できる安全性が弱く、現実的な状況（適応的な攻撃に対する安全性）を捉え切れていなかった。その後、2005 年に（理想的なハッシュ関数なしで）適応的な攻撃に対して安全な方式 [9]、2006 年には安全性の根拠となる計算量仮定は強いものの適応的な攻撃に対して安全かつ効率的なパラメータサイズを達成する方式 [10] と、立て続けに主要成果が提案された。Boneh-Franklin IBE に続くブレークスルーとなった研究が、Waters [11] による Dual System Encryption と呼ばれる証明技法の開発である。安全性証明にのみ登場し実際には利用しない “不完全な” 暗号文や秘密鍵を定義することで、標準的な計算量仮定の下で適応的な攻撃に対して安
全かつ効率的なパラメータサイズを達成する方式を初めて提案した。このように、

Pairing 写像ベース IBE 方式は効率的なパラメータサイズを達成し得るが、一方で Pairing 写像演算それ自体の計算負荷が高いという欠点がある。
また、Pairing 写像以外を用いる IBE の構成手法として有名なものに、格子構造を用いたものがある。代表的な格子ベース IBE 方式 [12, 13] は基本的に Pairing
写像ベース IBE 方式の構成アプローチを基にして作られており、格子構造のもつ耐量子計算機性が最大の魅力である。効率性の観点では、格子ベース IBE 方式はパラメータサイズが大きくなるものの、暗号化や復号が基本的に行列演算で実現可能という特長がある。格子以外の構成手法として、古典的な乗法巡回群を用いた Döttling-Garg による IBE 方式 [14] も重要な IBE 研究の一つである。Pairing
写像の登場まで IBE が実現されなかったことからも、IBE は通常の公開鍵暗号で利用されるような基本的な代数的構造での実現は難しいと考えられていたが、この研究がその認識を覆すこととなり、IBE の実現可能性の意味で大きなブレーク
スルーとなった。
学術研究としては更に高機能な ID ベース暗号が提案されており、PKG の秘密
鍵生成の負担の分散を目的とした階層型（Hierarchical）IBE [15] や、秘密鍵が部分的に漏洩したとしても安全性を保証可能な漏洩耐性（Leakage-resilient）IBE [16]、効率的に秘密鍵の失効を実現可能な鍵失効機能付き（Revocable）IBE [17] 等、想定される機能は多岐にわたる。

48

■具体的な構成例

具体的な IBE 方式として、最も基本的かつ標準化もされている

Boneh-Franklin IBE のアルゴリズムを紹介する。各ユーザは個別のユニーク ID（ID ）を持つものとする。
Setup: 公開パラメータ M P K とマスター鍵 M SK を設定する。素数位数 pの乗法群を G1 , GT とし、G1 の生成元を g とする。また、Pairing 写像
を e : G1 × G1 → GT とする。e は双線形性を満たす。すなわち、任意の a, b ∈ Zp に対して e(g a , g b ) = e(g b , g a ) = e(g, g)ab を満たす。ランダ
ムな元 s ∈ Z∗p を選択し、gpub = g s を計算する。また、ハッシュ関数
H1 : {0, 1}∗ → G1 と H2 : GT → {0, 1}n を定めておく。公開パラメータ
M P K を M P K = (p, G1 , GT , e, n, g, gpub , H1 , H2 )、PKG のマスター秘密鍵
M SK を M SK = s とする。
Extract(M P K, M SK, ID): ユーザ鍵 SKID を生成する。ID ∈ {0, 1}∗ から
QID = H1 (ID) ∈ G1 を計算し、ユーザ鍵 SKID = QsID とする。
Encrypt(M P K, ID, M ): メッセージ M の暗号化を行い、暗号文 C を生成する。
gID = e(QID , gpub ) ∈ GT を計算し、ランダムな元 r ∈ Z∗p を選択する。その後、メッセージ M ∈ {0, 1}n から暗号文 C = (g r , M ⊕ H2 (gID r )) を作成する。

Decrypt(SKID , C): 暗号文 C を復号し、メッセージ M を復号する。暗号文
C = (U, V ) に対して、V ⊕ H2 (e(SKID , U )) を出力する。この時、正しい暗号文であれば (U, V ) = (g r , M ⊕ H2 (gID r )) であり、e(SKID , U ) =rであるから、V ⊕ H2 (e(SKID , U ) = M がe(QsID , g r ) = e(QID , g s )r = gID成り立つ。

3.1.2 属性ベース暗号■特徴

属性ベース暗号（Attribute-Based Encryption, ABE）は、暗号文または秘密鍵の一方に属性情報を、もう一方にアクセス構造を持たせ、復号時に属性情報に含まれる値がアクセス構造の条件を満たすかどうか判別することで、復号者の制御が実現可能な公開鍵暗号方式の一つである。一般に（狭義の）公開鍵暗号
や ID ベース暗号（IBE）においては、暗号文とそれを復号可能な秘密鍵は 1 対 1の関係を持つため、暗号文の生成時に復号できるエンティティは唯一に決定され、もし複数のエンティティに同一のメッセージを送付する場合には、エンティティ
数に比例する暗号文の生成が必要である。一方で、属性ベース暗号ではアクセス構造を指定することで、単一の暗号文でメッセージの秘匿ときめ細かなアクセス49

制御を同時に達成可能となる。表現可能なアクセス構造は用いる暗号方式により様々であるが、多くの方式では例えば AND, OR で記述された条件式を表現することができる。
属性ベース暗号の方式は、鍵ポリシ型（Key-Policy, KP）と暗号文ポリシ型（Ciphertext-Policy, CP）の 2 種類の型に大別される。鍵ポリシ型ではエンティ
ティが持つ秘密鍵に、暗号文ポリシ型ではメッセージにそれぞれアクセス構造を埋め込み、もう一方に属性情報を埋め込む点が異なる。そして、適応先のユース
ケースによってより効果的な型を選択する必要があり、例えば、ユーザや機器等のエンティティが固有に有する情報を元に制御したい場合には暗号文ポリシ型、暗号化対象のメッセージが固有に有する情報を元に制御したい場合には鍵ポリシ型の方式が適していることが多い。
一般に属性ベース暗号方式を構成する場合、セットアップおよび鍵発行を実行する主体である鍵生成局と、暗号化および復号を実行する主体であるエンティティが存在する。エンティティは、自身の有する属性情報（またはアクセス構造）を含む秘密鍵を鍵発行局から発行してもらい、自身のみが扱うように安全に保管する。
暗号化については、公開情報を知ることができる任意のエンティティが実行することができ、メッセージにアクセス構造（または属性情報）を指定して暗号化する。
復号については、エンティティが各自の秘密鍵と暗号文を用いて復号を行うが、属性情報とアクセス構造の関係が満足する場合には元のメッセージに復号できる。
■方式の歴史・進展

属性ベース暗号は、2005 年に ID ベース暗号の拡張である Fuzzy

IBE が Sahai らにより提案され、そのコンセプトが提唱された [18]。Fuzzy IBE
では、秘密鍵および暗号文にそれぞれ複数の ID が割り当てられており、各 ID 集
合の間で定められたしきい値以上の ID が一致した場合にのみ復号可能である。この複数の ID を属性集合、一致する ID とそのしきい値をアクセス構造と見なすことで、現在の属性ベース暗号の一種と捉えられる。翌年 2006 年、Goyal らにより、より広いクラスの条件式を扱うことができるはじめての実用的な属性ベース暗号が提案された [19]。Goyal らの方式は鍵ポリシ型であり、秘密鍵に対して AND,OR, しきい値を用いた論理式で表現された条件式を設定し、また暗号文に属性集合を指定することで、暗号文に含まれる属性値が自身の持つ秘密鍵の条件式を満たすかにより、きめ細やかな復号者の制御が可能となった。さらに 2007 年には、Bethencourt らにより、暗号文に対してアクセス構造を設定することが可能な暗号文ポリシ型の方式がはじめて提案された [20]。
その後、安全性の研究においては、適応的攻撃に対しても安全な方式 [21] や標
準モデルと呼ばれる現実的な仮定の下で安全な方式 [22] の研究等が進められ、ま50

た量子計算機に対して安全な格子ベースの方式も提案されている [23]。条件式で使えるクラス拡張の研究においては、数値の大小比較 [24]、NOT 条件 [25] を利用可能な方式等、数多くの方式が提案されている。
さらに、前述した基本的な性質以外の機能性を追加した方式も提案されてきた。
例えば、鍵発行処理をより柔軟にするものとして、ある秘密鍵で復号可能な暗号文のうち、その中の一部の暗号文のみを復号できる新たな秘密鍵を生成し、権限を移譲できる方式 [19] や鍵発行局を階層化した方式 [26]、複数の鍵発行局の秘密鍵を用いて復号制御ができるマルチオーソリティ方式 [27]、さらに特権的なルートを持たない分散型マルチオーソリティ方式 [28] 等がある。
■具体的な構成例: GPSW06 KP-ABE

本節では、AND, OR, および (k, n)-しきい値を条件式として記述でき、はじめてきめ細かなアクセス制御が可能となった

KP-ABE である Goyal らによる GPSW06 の構成を示す [19]。
はじめに本方式のアクセス構造の表現方法であるアスセスツリー T について説明する。アスセスツリー T の葉ノード以外の全てのノードはしきい値ゲー
トを表現できる。ノード x に対して、子ノードの個数を numx 、しきい値を

1 ≤ kx ≤ numx である値 kx とする。kx = 1 の場合には OR ゲートを、kx = numxの場合には AND ゲートを、1 < kx < numx の場合には (kx , numx )-しきい値ゲー
トを表現できる。各ノード x の子ノードは順序付けされており、それぞれ 1 から
numx までのインデックスが割り振られている。また葉ノードでは属性値が設定されており、kx = 1 とする。
アスセスツリー中のノードの取り扱いを容易にするため、いくつかのサブ関数を準備する。あるノード x に対して、parent(x) を x の親ノード、index(x) を親
ノード parent(x) から割り振られたインデックスを指す値とする。parent(x) の各子ノードはこのインデックスで一意に特定できる。また att(x) を x の属性値
で、x が葉ノードのときにのみ値を取るものとする。
以降では、素数 p に対して、位数 p の乗法群を G1 , GT 、G1 の生成元を g とする。また Pairing 写像を e : G1 × G1 → GT とし、双線型性を満たす。また GT の生成元を gT = e(g, g) とする。ラグランジュ補間において、Zp 上の元の集合 S での基底多項式を ∆i,S (x) =Pj∈S,j̸=i (x − j)/(i − j) とする。

このとき、セットアップ (Setup)、暗号化 (Encrypt)、鍵生成 (Keygen)、復号(Decrypt) の 4 つのアルゴリズムは以下の通りである。
Setup: 属性ユニバースを U = {1, 2, ..., n} とする。それぞれの属性値 i ∈ U に対して、Zp 上から一様ランダムに選択した値を ti とする。また値 y ∈ Zp を一51

様ランダムに選択する。このとき、公開パラメータ M P K およびマスタ秘密鍵 M SK は以下の通りとなる。


M P K := T1 := g t1 , ..., Tn := g tn , Y := gTy , M SK := (t1 , ..., tn , y)
Encrypt(M, γ, M P K): メッセージ空間を M := GT とする。また入力としてメッセージ M ∈ M、指定する属性集合 γ ⊆ U とする。暗号文は、ランダムな値 s ∈ Zp を選択し、
Cγ := (γ, C ′ := M Y s , {Ci := Tis }i∈γ )となる。

Keygen(T , M SK): ある属性集合 γ に対して T (γ) = 1 の場合に限り復号できる
アクセスツリー T に紐づいた秘密鍵を出力する。これは T を表現するノード集合 N の全てのノードに対して、ルートノードから下位ノードに向かって順に次の計算をすることで得る。
各ノード x ∈ N において、しきい値 kx から次数 dx := kx − 1 である多項式 qx を定める。ルートノード r では、多項式 qr は、qr (0) = y とし、qr 上の他の dr 個の値をランダムに選択する。非ルートノード x では、親ノード

parent(x) に割り振られたインデックス index(x) から、多項式 qx の定数を
qx (0) = qparent(x) (index(x)) とし、また qx 上の dx 個の値をランダムに選択する。最後に、葉ノード x では、att(x) ∈ U に対して、
SKx := g qx (0)/tatt(x)を計算し、これらがアクセスツリー T に対する秘密鍵、

SKT := {SKx | att(x), x ∈ N }となる。

Decrypt(Cγ , SKT ): 暗 号 文 Cγ := (γ, C ′ := M Y s , {Ci := Tis }i∈γ )、秘 密 鍵
SKT := {SKx | att(x), x ∈ N } を入力として、アクセスツリー T の各ノード x に対して、関数 DecryptNode(Cγ , SKT , x) を再帰的に実行することで計算する。関数 DecryptNode は、計算結果として GT 上の元または ⊥ を出力する。
ノード x が葉ノードである場合、i = att(x) として、以下を得る。

(
Fx := DecryptNode(Cγ , SKT , x) =52

s·q (0)e(SKx , Ci ) = gT x⊥

if i ∈ γ
if i ∈/γ

ノード x が非葉ノードである場合、ノード x の子ノード zi の結果 Fzi から
関数 DecryptNode を計算する。まずはじめに、子ノードの内、Fzi ̸= ⊥ を満たす、ある kx 個のノードを Sx := {zi1 , ..., zikx | ij ∈ [1, numx ]} とする。

またこれらのノードのインデックスの集合 Sx′ := {index(zi ) | zi ∈ S} とする。このとき、Sx のノード数が kx 個に満たない場合は、⊥ を出力する。それ以外の場合は、

Fx := DecryptNode(Cγ , SKT , x)Y ∆index(z),S′ (0)
x
=
Fz
z∈Sx

=

Y

s·q (index(z)) ∆index(z),S ′ (0)

(gT x

)

x

z∈Sx
s·q (0)= gT xとし、多項式補間によりノード x における多項式 qx の定数 qx (0) を得られる。
結果として、ルートノード r に対する DecryptNode(Cγ , SKT , r) は、再帰計
算により、Fr = gT = Y s が得られ、最後に、メッセージ M ′ := C ′ /Fr が出
sy

力される。

3.1.3 放送型暗号
放送型暗号では、送信者は複数の受信者に暗号文を同時送信し、なおかつ、そのうちの任意の受信者集合に復号権限を指定できる。この仕組みは、従来の暗号方式を単純に組み合わせても実現可能であるが、その場合は受信者数に比例した暗号文長が必要となるため、非効率的となる。これに対し、放送型暗号では受信者数よりも漸近的に短い暗号文長で同等の機能を実現することが可能である。
放送型暗号には、誰でも公開情報のみを用いた暗号化を行うことが可能な公開鍵型と暗号化にも秘密情報を必要とする共通鍵型が存在する。公開鍵型について
は、楕円曲線上の Pairing 写像に基づき、暗号文サイズが受信者数によらず定数となる方式 [29] が設計されて以降、効率化についての理論的な検討が継続されており、2020 年には、Agrawal と山田により、暗号文と鍵サイズが現実的な仮定の下で定数サイズとなる初めての方式が提案されている [30]。一方、共通鍵型に関しては、木構造などの組み合わせ論的技法を用いてパラメータを圧縮する方法が主流である。公開鍵型の構成と異なり、重い計算負荷を要する代数的な構造は必要
53としないため、ある程度高速な処理が可能であり、各利用者に求められる鍵情報のサイズは実用的な範囲に抑えられるものの、公開鍵型のように定数サイズにまで圧縮することは困難だと思われる。
■Boneh, Gentry, Waters による放送型暗号

本稿では具体的な方式の例として Boneh-

Gentry-Waters 放送型暗号方式（以下、BGW 方式）[29] を記述する。BGW 方式
は、結託耐性と受信者人数に劣線形（比例しない）短い定数長の暗号文長を達成した初めての方式であり、歴史的に非常に重要である。また、提案以来効率性や安全性の改善の検討が続いてはいるものの、当該方式は現時点においても最も効率の良い方式の一つである。なお、原論文では Key encapsulation mechanism（KEM）の形で方式が記述されているが、ここでは Encryption の形で方式を記述する。平
文空間は GT となっているが、一般の平文を暗号化するためには e(g1 , gn )t を適当な鍵導出関数に入力して得られる文字列を共通鍵暗号の秘密鍵として平文を暗号化すればよい。鍵導出関数としては、例えば SHA のような暗号的ハッシュ関数
や、Pair-wise independent ハッシュ関数を用いればよい。
以下、G と GT を素数位数 p をもつ群とし、e : G × G → GT を付随する（対称）Pairing 写像とする。

Setup(1λ , n): セットアップアルゴリズムは、システムの人数 n とセキュリティ
パラメータ λ を入力とし、適切な Pairing 写像 e を選び、公開鍵をP K = (g, g1 , . . . , gn , gn+2 , . . . , g2n , v = g γ ) ∈ G2n+1iと設定する。ここで、g は G のランダムな生成元、gi = g α 、α と v は Zp のランダムな元である。また、i 番目のユーザに対する秘密鍵を

di = giγと設定する。最終的な出力は (P K, d1 , . . . , dn ) である。

Enc(P K, S, m): 暗号化アルゴリズムは、ユーザ集合 S にむけて平文 m ∈ GT を暗号化するために、P K, S, m の入力を受け、ランダムな t ∈ Zp を選択し、暗号文をCT = (c0 = g t , c1 = (vY

gn+1−j )t , cT = e(g1 , gn )t m) ∈ G2 × GTj∈S

により計算し、出力する。

Dec(P K, S, i, di , CT ): 平文を m := cT · e(di , ·より計算し、出力する。
54

Q

j∈S,j̸=i gn+1−j+i , c0 )/e(gi , c1 ) に

BGW 方式は、暗号文長、秘密鍵長がシステム内のユーザ数に依存せず、定数長であるという利点があるが、公開鍵長はシステム内のユーザ数に比例して長くなるという欠点がある。[29] では、上記方式のほかに公開鍵長と暗号文長のトレード
オフを実現する方式が記載されている。

BGW 方式は選択的攻撃に対して結託耐性を持つことが、Pairing
群上の Bilinear Diﬃe-Hellman Exponent（BDHE）問題と呼ばれる問題の困難性■安全性についてを仮定して証明可能である。結託耐性とは、システム上の復号権限を持たないユー
ザ全員が結託しても、暗号化された平文の情報を得ることが識別不可能性の意味でできないことを指しており、選択的攻撃とは攻撃者が公開鍵を得る前に攻撃目標である受信者集合を定める種類の攻撃を指している。BDHE 問題とは、対称

Pairing 群の元 (g, h, g1 , . . . , gℓ , gℓ+2 , . . . , g2ℓ ) が与えられた時に、e(gℓ+1 , h) とラン
ダムな GT の元の識別をするという問題である。ここで、g, h はソース群の生成元iで、gi = g (α ) であり、α は Zp 上でランダムにサンプルされる。また、システム内のユーザ数 n に応じてパラメータ ℓ は大きくなる。BDHE 問題に対しては、ℓ が特定の条件を満たす際に Cheon 攻撃 [31] の適用が可能であり、特に n が大きい場
合には、パラメータ選定における注意が必要である。
■その他の放送型暗号方式について

放送型暗号の概念は Fiat と Naor らにより定式化された [32]。共通鍵型の放送型暗号としては [33] が著名である。BGW 方式は選択的攻撃に対する安全性しか証明できていないことが欠点の一つであったが、より強い適応的攻撃に対する安全性を持つ方式がランダムオラクルモデルで Gentryと Waters によって [34]、標準モデルで Waters によって提案された [11]。Watersによる方式は、decisional linear 仮定と呼ばれる BDHE 仮定よりも標準的な数論
仮定に基づき安全性証明が与えられている。標準モデルでの方式はその後の研究によってさらに効率化されている [35]。

3.1.4 準同型暗号
準同型暗号は、データを暗号化したまま演算処理（四則演算等）ができる暗号技術であり、一般には公開鍵暗号の機能要件だけで、この性質が保証されるわけではない。準同型暗号は、実現できる演算内容により、単一演算型、Leveled 型、完全型に大別される。単一演算型は、加算または乗算のみ実現可能であり、単純な演算処理のみ実現可能である。例えば、加法準同型性をもつ暗号方式として

Okamoto-Uchiyama 方式 [36] や、Paillier 方式 [37] が有名である。Leveled 型は加算と乗算をともに実現可能であるが、演算回路の深さに（特に乗算の深さに）上55

限がある。なお、回路の深さとは入力ゲートから出力ゲートまでに最大の長さのことである。完全型は、加算と乗算を共に実現可能であり、かつ乗算の回数に制限がない。実際には、Leveled 型にブートストラッピングと呼ばれる技術を組み合わせることにより完全型が実現されることが多い。また、Leveled 型のうち、扱える計算回路の深さが浅いものは Somewhat 型と呼ばれることも多い。以下に、具体的な準同型暗号技術のアルゴリズムを紹介する。
■Boneh, Goh, Nissim による準同型暗号

具体的な準同型暗号方式の例として Boneh-

Goh-Nissim 準同型暗号方式（以下、BGN 方式）[38] を記述する。BGN 方式は
2-DNF formula に対する準同型暗号方式として提案されているが、ここでは整数上の加算と一回の乗算が可能な準同型暗号として記述する。G と GT を合成数位
数 n = q1 q2 をもつ群とし、e : G × G → GT を付随する（対称）Pairing とする。
ここで、q1 および q2 は素数である。また、G は位数 q1 の群 Gq1 と位数 q2 の群
Gq2 の直積と同型であり、ここでは Gqi = {g qi : g ∈ G} を Gq3−i (i ∈ {1, 2}) と同一視することにする。

Setup(1λ ): セットアップアルゴリズムでは、適切な Pairing 写像 e を選択、および、G のランダムな生成元 g と u を選択する。さらに、h = uq2 を計算し、公開鍵をP K = (n, g, h)と設定する。また、秘密鍵は SK = (q1 , q2 ) である。

Enc(P K, m): 暗号化アルゴリズムは、 (整数として符号化された) 平文 m ∈ Z を暗号化するために、P K, m の入力を受け、ランダムな r ∈ {0, 1, . . . , n − 1}
を選択し、暗号文をCT = g m hr
により計算し、出力する。

Dec(P K, SK, CT ): 復号アルゴリズムの入力 CT は、G の元である場合と、GTの元である場合がある。前者は準同型的乗算を行う前の暗号文で、後者は準同型的乗算を行った後の場合である。どちらの場合も、復号アルゴリズム
はまず CT q1 を計算する。次に、 ĝ を底とした CT q1 の離散対数を計算し、m を得る。ここで、CT ∈ G の場合は ĝ = g q1 であり、CT ∈ G の場合はĝ = e(g, g)q1 である。復号が可能なためには m はセキュリティパラメータの多項式程度でなければならない。
次に、準同型演算を記述する。
56

Add(P K, CT1 , CT2 ): 二つの暗号文に対して加法を準同型的に行うためには、CT1 と CT2 は同じ群 (G か GT ) の元である必要がある。両者ともに G の群である場合には、ランダムな r ∈ {0, 1, . . . , n − 1} を選択し CT1 · CT2 · hr
を、両者ともに GT の群である場合には、ランダムな r ∈ {0, 1, . . . , n − 1}
を選択し CT1 · CT2 · e(h, h)r を計算する。
Mult(P K, CT1 , CT2 ): 二つの暗号文に対して加法を準同型的に行うためには、CT1 と CT2 は G の 元 で あ る 必 要 が あ る 。そ の 場 合 に ラ ン ダ ム な r ∈{0, 1, . . . , n − 1} を選択し、e(CT1 , CT2 )e(g, h)r を計算する。
BGN 方式は、部分群判定問題の困難性を仮定すると IND-CPA
安全性をもつことが証明できる。部分群判定問題とは、G のランダムな元 g 、Gq1のランダムな元 h が与えられた時、G のランダムな元と Gq1 のランダムな元が識■安全性について別不可能であるという仮定である。

BGN 方式は、合成数位数 Pairing 群の演算が必要であるが、合成数位数 Pairing 群は素数位数 Pairing 群に比べ大きいパラメータが必要であり、計算効率が悪い。BGN 方式の改良として、素数位数 Pairing 群に基づく準同型暗号方式が Freeman によって提案され [39]、のちにさらなる改良方式がAttrapadung らにより提案された [40]。Attrapadung らは提案方式の実装も行っ■BGN 方式の後続研究についてている。
■完全準同型暗号方式について

初の完全準同型暗号は Gentry によって 2009 年に提案された [41]。Gentry の提案は格子問題の困難性を利用していたものだったが、これが契機となり格子に基づく完全準同型暗号および Leveled 準同型暗号の研究が活発になった。代表的な方式としては、Brakerski らによる BGV 方式 [42]、Gentry らによる GSW 方式 [43]、Chillotti らによる TFHE 方式 [44]、Cheon らによる CKKS 方式 [45] などが挙げられる。CKKS 方式以外は、準同型演算の結果が復号によって正確に得られるタイプの完全準同型暗号方式だが、CKKS 方式
は復号結果にエラーが加わるタイプの方式であり、復号結果にエラーが加わることを容認することで効率化を図っている。CKKS を含む復号にエラーが含まれるタイプの完全準同型暗号に関しては、セキュリティ上の懸念が指摘されており、利用シナリオやパラメータ選定等に注意が必要な場合がある [46]。
完全準同型暗号の著名な実装例としては、Homomorphic Encryption library（HElib） [47] や Simple Encrypted Arithmetic Library（SEAL） [48] が挙げられる。HElib は IBM 社がオープンソースで提供している準同型暗号のライブラリであり、BGV 方式と CKKS 方式が利用可能である。また、SEAL は Microsoft 社
57

がオープンソースで提供している準同型暗号のライブラリであり、Fan らによる

FV 方式 [49] と CKKS 方式が利用可能である。
3.1.5 プロキシ再暗号化
プロキシ再暗号化は、あるユーザ宛の暗号文を、復号することなく別のユーザ宛の暗号文へ変換することが可能な暗号技術である。より具体的に、ユーザ A は、
もう一方のユーザ B とプロキシ（代理人）と呼ばれる第三者を指定し、プロキシ
に対して「再暗号化鍵 rkA→B 」を預託する。プロキシは、この再暗号化鍵 rkA→B
を使って、ユーザ A 宛の暗号文 ctA の中身を知ることなく、ユーザ B 宛の暗号文

ctB に変換することができる。
プロキシ再暗号化方式は、再暗号化鍵 rkA→B の性質や暗号文が備える安全性レ
ベルによっていくつかに分類可能である。以下、代表的な分類のいくつかを紹介する。

 一方向/双方向変換: ユーザ A から B への再暗号化鍵 rkA→B を用いて、ユー
ザ B 宛の暗号文をユーザ A 宛の暗号文に変換することができない場合は一方向、できる場合は双方向。

 CPA/CCA 安全性: 選択的平文攻撃に対してのみ安全であれば CPA 安全で、選択的暗号文攻撃に対しも安全であれば CPA 安全。
 シングル/マルチホップ: 再暗号化した暗号文をそれ以上再暗号化できなけ
ればシングルホップ、連続して再暗号化できればマルチホップ。
これらの性質については、用途に応じて選定を行う必要があるが、求められる性質
によって処理性能に差が生じるため、慎重な判断が必要となる。なお、双方向変換可能で CPA 安全なマルチホップ方式が、最も高速な処理が可能となる。以下、Blaze ら [50] により初めて提案された双方向変換可能で CPA 安全なマルチホップ
な方式である BBS 方式を紹介する。BBS 方式は、ElGamal 暗号の簡単な変形で導かれ、その後のプロキシ再暗号化の構成の基盤となっている。
■Blaze, Bleumer, Strauss によるプロキシ再暗号化方式 [50]以下、G を素数位数 p を持つ群とし、g ∈ G をその生成元とする。

KeyGen: 各ユーザは、鍵生成アルゴリズムを実行し、公開鍵 pk = g x ∈ G と秘密
鍵 sk = x ∈ Zp \{0} を生成する。
ReKeyGen(skA , skB ): ユーザ A と B は、各々の秘密鍵 skA = a と skB = b を入力に再暗号化鍵生成アルゴリズムを実行し、再暗号化鍵 rkA→B = b/a ∈ Zp を58

プロキシに渡す。

Enc(pkA , msg ∈ G): 暗号化アルゴリズムを利用し、ユーザ A 宛の暗号文 ctA =(msg · g r , (pkA )r ) を生成する。なお、r はアルゴリズムがサンプルする乱数である。ここで、通常の ElGamal 暗号は ctA = (g r , msg · (pkA )r ) であることに注意されたい。

ReEnc(rkA→B , ctA ): プロキシは、再暗号化アルゴリズムを実行し、ユーザ A 宛の暗号文 ctA = (ct1 , ct2 ) から、ユーザ B 宛の暗号文 ctB = (ct1 , (ct2 )rkA→B ) を生成する。

Dec(sk, ct): 各ユーザは、復号アルゴリズムを実行し、まず自身宛の暗号文 ct =(ct1 , ct2 ) から msg′ = (ct1 )sk /ct2 を計算し、平文 msg = (msg′ )1/sk を出力する。
暗号文 ctA がユーザ A 宛であれば、ctA は (msg·g r , g ar ) であるため、秘密鍵 skA = aを用いて、msg が正しく復号できることが確認できる。また、rkA→B = b/a を利用することで、暗号文 ctA の第 2 項目が、g br に変換できるため、プロキシがユーザ

B 宛の暗号文 ctB に正しく変換できていることも確認できる。rkB→A = (rkA→B )−1であることに注意すると、rkA→B = b/a が双方向変換に対応していることが確認できる。最後に、異なるユーザ C に対する再暗号化鍵 rkB→C を渡されたプロキシ
は、ctB をさらにユーザ C 宛の暗号文 ctC に変換できるため、マルチホップ性も満たす。

BBS 方式は、通常の公開鍵暗号が備える最も基本的な選択平文攻撃に対する安全性（CPA 安全性）に類似した CPA 安全性を備える。通常の CPA 安全性では、攻撃者は公開鍵 pkA 、および、自身が選んだ任意の平文 msg0 と msg1 のいずれかに関する暗号文 ct∗A を入手し、ct∗A がどちらの■BBS 方式の安全性について

平文を暗号化しているか識別できないことを要求する。プロキシ再暗号化方式においては、これに加え、任意の n ∈ N に対して、攻撃者は n 人の異なるユーザの公開鍵 {pkBi }i∈[n] と再暗号化鍵 {rkA→Bi }i∈[n] を与えられた上での、識別不能性を要求する。具体的に BBS 方式では、(g, g a , {g bi , bi /a}i∈[n] , g r , g ar ) の組みと、′(g, g a , {g bi , bi /a}i∈[n] , g r , g r ) の組みが識別不可能であることを意味する。ここで、後者の下線部に現れる r′ は他の変数に依存しないランダムな Zp 上の要素である。
この組みを識別する問題は、Decisional Diﬃe-Hellman（DDH）問題の困難性に帰着でき、BBS 方式は DDH 問題の困難性仮定に基づいて CPA 安全であることが
示される。

59

BBS 方式は、もし攻撃者が（ct∗A 以外の）暗号文を復号できる復号オラクルと対話できる場合、平文 msg0 か msg1 のどちらが暗号化されているかを自明に識別することができる。従って、BBS 方式は CPA 安全
であるが、より強い選択暗号文攻撃に対する安全性（CCA 安全性）を持たない。
Canetti と Hohenberger [51] は、CCA 安全性を備える、双方向変換可能でマルチホップな再暗号化方式を提案した。BBS 方式と比べ、構成に双線型写像を要する■その他のプロキシ再暗号化方式

ため、安全性と引き換えに効率性が少し劣る。
双方向変換可能なプロキシ再暗号化方式は、再暗号化鍵 rkA→B を生成する際にユーザ A と B の秘密鍵 skA と skB を必要とする。しかし、一方向変換可能なプロ
キシ再暗号化方式は、再暗号化鍵 rkA→B を生成する際に、ユーザ A の秘密鍵 skAとユーザ B の公開鍵 pkB だけが必要になり、rkA→B からユーザ B の秘密鍵 skBの情報が漏洩することはない。従って、ユーザ B の暗号文をユーザ A の暗号文に変更する必要がないアプリケーションにおいては、一方向変換可能なプロキシ
再暗号化方式が双方向変換可能な方式と比べ、安全性を担保できるため適切である。そして、Libert と Vergnaud [52] は、CCA 安全で一方向変換可能なプロキシ
再暗号化方式を双線型写像から構成し、花岡ら [53] は、特定の性質を満たすしきい値暗号に基づく一般的な構成を示した。いずれの方式もシングルホップであり、CCA 安全で一方向変換可能、かつ、マルチホップな効率的なプロキシ再暗号化方式は現段階では開発されていない。

参考文献[1] A. Shamir: “Identity-Based Cryptosystems and Signature Schemes”,
CRYPTO 1984, Springer-Verlag, pp. 47–53 (1984).
[2] Y. Dodis, J. Katz, S. Xu and M. Yung: “Key-insulated public key cryptosystems”, EUROCRYPT 2002, Springer-Verlag, pp. 65–82 (2002).
[3] R. Canetti, S. Halevi and J. Katz: “A forward-secure public-key encryption
scheme”, EUROCRYPT 2003, Springer-Verlag, pp. 255–271 (2003).
[4] K. Paterson and E. Quaglia: “Time-speciﬁc encryption”, SCN 2010,
Springer-Verlag, pp. 1–16 (2010).
[5] D. Boneh, R. Canetti, S. Halevi and J. Katz: “Chosen ciphertext security
from identity based encryption”, SIAM J. Computing, 36, 5, pp. 1301–1328(2007).
[6] R. Sakai, K. Ohgishi and M. Kasahara: “Cryptosystems Based on Pairings”,
60

SCIS 2000 (2000).
[7] D. Boneh and M. Franklin: “Identity-Based Encryption from the Weil Pairing”, CRYPTO 2001, Springer-Verlag, pp. 213–229 (2001).
[8] D. Boneh and X. Boyen: “Eﬃcient Selective-ID Secure Identity Based Encryption without Random Oracles”, EUROCRYPT 2004, Springer-Verlag,
pp. 223–238 (2004).
[9] B. Waters: “Eﬃcient Identity Based Encryption without Random Oracles”,
EUROCRYPT 2005, Springer-Verlag, pp. 114–127 (2005).
[10] C. Gentry: “Practical identity-based encryption without random oracles”,
EUROCRYPT 2006, Springer-Verlag, pp. 445–464 (2006).
[11] B. Waters: “Dual System Encryption: Realizing Fully Secure IBE and
HIBE under Simple Assumptions”, CRYPTO 2009, Springer-Verlag, pp.
619–636 (2009).
[12] C. Gentry, C. Peikert and V. Vaikuntanathan: “Trapdoors for Hard Lattices
and New Cryptographic Constructions”, STOC 2008, ACM, pp. 197–206(2008).
[13] S. Agrawal, D. Boneh and X. Boyen: “Eﬃcient lattice (H)IBE in the standard model”, EUROCRYPT 2010, Springer-Verlag, pp. 553–572 (2010).
[14] N. Döttling and S. Garg: “Identity-based encryption from the DiﬃeHellman assumption”, CRYPTO 2017, Springer-Verlag, pp. 537–569 (2017).
[15] D. Boneh, X. Boyen and E.-J. Goh: “Hierarchical Identity Based Encryption
with Constant Size Ciphertext”, EUROCRYPTO 2005, Springer-Verlag,
pp. 440–456 (2005).
[16] S. S. Chow, Y. Dodis, Y. Rouselakis and B. Waters: “Practical leakageresilient identity-based encryption from simple assumptions”, ACM CCS
2010, pp. 152–161 (2010).
[17] A. Boldyreva, V. Goyal and V. Kumar: “Identity-based encryption with
eﬃcient revocation”, ACM CCS 2008, pp. 417–426 (2008).
[18] A. Sahai and B. Waters: “Fuzzy Identity-Based Encryption”, EUROCRYPT 2005, Springer-Verlag, pp. 457–473 (2005).
[19] V. Goyal, O. Pandey, A. Sahai and B. Waters: “Attribute-Based Encryption
for Fine-Grained Access Control of Encrypted Data”, ACM CCS 2006, pp.
89–98 (2006).
[20] J. Bethencourt, A. Sahai and B. Waters: “Ciphertext-Policy Attribute-61Based Encryption”, IEEE S&P 2007 (2007).
[21] A. Lewko, T. Okamoto, A. Sahai, K. Takashima and B. Waters: “Fully
Secure Functional Encryption: Attribute-Based Encryption and (Hierarchical) Inner Product Encryption”, EUROCRYPT 2010, Springer-Verlag, pp.
62–91 (2010).
[22] B. Waters: “Ciphertext-Policy Attribute-Based Encryption: An Expressive,Eﬃcient, and Provably Secure Realization”, PKC 2011, Springer-Verlag, pp.
53–70 (2011).
[23] S. Gorbunov, V. Vaikuntanathan and H. Wee: “Attribute-Based Encryption
for Circuits”, STOC 2013, ACM, pp. 545–554 (2013).
[24] D. Boneh and B. Waters: “Conjunctive, Subset, and Range Queries on
Encrypted Data”, TCC 2007, Springer-Verlag, pp. 535–554 (2007).
[25] R. Ostrovsky, A. Sahai and B.Waters: “Attribute-Based Encryption with
Non-Monotonic Access Structures”, ACM CCS 2007, pp. 195–203 (2007).
[26] G. Wang, Q. Liu, J. Wu and M. Guo: “Hierarchical Attribute-Based Encryption and Scalable User Revocation for Sharing Data in Cloud Servers”,
Computers and Security, Vol. 30, Issue 5, ACM, pp. 320–331 (2011).
[27] M. Chase: “Multi-Authority Attribute Based Encryption”, TCC 2007,
Springer-Verlag, pp. 515–534 (2007).
[28] A. Lewko and B. Waters: “Decentralizing Attribute-Based Encryption”,
EUROCRYPT 2011, Springer-Verlag, pp. 568–588 (2011).
[29] D. Boneh, C. Gentry and B. Waters: “Collusion Resistant Broadcast
Encryption with Short Ciphertexts and Private Keys”, CRYPTO 2005,
Springer-Verlag, pp. 258–275 (2005).
[30] S. Agrawal and S. Yamada: “Optimal Broadcast Encryption from Pairingsand LWE”, EUROCRYPT 2020, Springer-Verlag, pp. 13–43 (2020).
[31] J. Cheon: “Security Analysis of the Strong Diﬃe-Hellman Problem”, EUROCRYPT 2006, Springer-Verlag, pp. 1–11 (2006).
[32] A. Fiat and M. Naor: “Broadcast Encryption”, CRYPTO 1993, SpringerVerlag, pp. 480–491 (1993).
[33] D. Naor, M. Naor and J. Lotspiech: “Revocation and Tracing Schemes forStateless Receivers”, CRYPTO 2001, Springer-Verlag, pp. 41–62 (2001).
[34] C. Gentry and B. Waters: “Adaptive Security in Broadcast Encryption
Systems (with Short Ciphertexts)”, EUROCRYPT 2009, Springer-Verlag,

62pp. 171–188 (2009).
[35] J. Chen, R. Gay and H. Wee: “Improved Dual System ABE in Prime-OrderGroups via Predicate Encodings”, EUROCRYPT 2015, Springer-Verlag, pp.
595–624 (2015).
[36] T. Okamoto and S. Uchiyama: “A New Public-Key Cryptosystem as Secure
as Factoring”, EUROCRYPT 1998, Springer-Verlag, pp. 308–318 (1998).
[37] P. Paillier: “Public-Key Cryptosystems Based on Composite Degree Residuosity Classes”, EUROCRYPT 1999, Springer-Verlag, pp. 223–238 (1999).
[38] D. Boneh, E. Goh and K. Nissim: “Evaluating 2-DNF Formulas on Ciphertexts”, TCC 2005, Springer-Verlag, pp. 325–341 (2005).
[39] D. Freeman: “Converting Pairing-Based Cryptosystems from CompositeOrder Groups to Prime-Order Groups”, EUROCRYPT 2010, SpringerVerlag, pp. 44–61 (2010).
[40] N. Attrapadung, G. Hanaoka, S. Mitsunari, Y. Sakai, K. Shimizu and
T. Teruya: “Eﬃcient Two-level Homomorphic Encryption in Prime-order
Bilinear Groups and A Fast Implementation in WebAssembly”, AsiaCCS
2018, ACM, pp. 685–697 (2018).
[41] C. Gentry: “Fully Homomorphic Encryption Using Ideal Lattices”, STOC
2009, ACM, pp. 169–178 (2009).
[42] Z. Brakerski, C. Gentry and V. Vikuntantathan: “(Leveled) Fully Homomorphic Encryption without Bootstrapping”, ITCS 2012, ACM, pp. 309–
325 (2012).
[43] C. Gentry, A. Sahai and B. Waters: “Homomorphic Encryption from Learning with Errors: Coceptually-Simpler, Asymptotically-Faster, AttributeBased”, CRYPTO 2013, Springer-Verlag, pp. 75–92 (2013).
[44] I. Chillotti, N. Gama, M. Georgieva and M. Izabachène: “Faster Fully Homomorphic Encryption: Bootstrapping in Less Than 0.1 Seconds”, ASIACRYPT 2016, Springer-Verlag, pp. 3–33 (2016).
[45] J. Cheon, A. Kim, M. Kim and Y. Song: “Homomorphic Encryption for
Arithmetic of Approximate Numbers”, ASIACRYPT 2017, Springer-Verlag,
pp. 409–437 (2017).
[46] B. Li and D. Micciancio: “On the Security of Homomorphic Encryption on
Approximate Numbers”, EUROCRYPT 2021, Springer-Verlag, pp. 648–677(2021).

63

[47] “HElib (Homomorphic Encryption library)”.
https://github.com/
homenc/HElib.
[48] “Simple Encrypted Arithmetic Library”. https://www.microsoft.com/
en-us/research/project/microsoft-seal/.
[49] J. Fan and F. Vercauteren: “Somewhat Practical Fully Homomorphic Encryption”. ePrint 2012/144.
[50] M. Blaze, G. Bleumer and M. Strauss: “Divertible Protocols and Atomic
Proxy Cryptography”, EUROCRYPT 1998, Springer-Verlag, pp. 127–144(1998).
[51] R. Canetti and S. Hohenberger: “Chosen-Ciphertext Secure Proxy ReEncryption”, ACM CCS 2007, pp. 185–194 (2007).
[52] B. Libert and D. Vergnaud: “Unidirectional Chosen-Ciphertext Secure
Proxy Re-Encryption”, PKC 2008, Springer-Verlag, pp. 360–379 (2008).
[53] G. Hanaoka, Y. Kawai, N. Kunihiro, T. Matsuda, J. Weng, R. Zhang and
Y. Zhao: “Generic Construction of Chosen Ciphertext Secure Proxy ReEncryption”, CT-RSA 2012, Springer-Verlag, pp. 349–364 (2012).

64

3.2 認証・署名を目的とした高機能暗号技術
3.2.1 属性ベース署名
属性ベース署名は、署名者が持つ署名鍵が、署名を付与する平文に付随する条件を満たしている時に限り署名を生成でき、かつ、署名からは条件が満たされたという情報以外は漏れない署名方式である。より具体的に、属性ベース署名は、平文ポリシー型と鍵ポリシー型に大別されるが、前者は平文に条件、いわゆるアクセス構造が付随し、署名生成鍵に属性が付随する。平文と署名鍵に付随する情報を逆転させると後者になる。この際、属性（例えば、 会社員、30 歳以上、東京都在住）がアクセス構造（例えば、18 歳以上の都民であるか？）を満たす時に限り、署名を生成することができる。例えば平文ポリシー型であれば、アクセス構造を満たす属性を所持する署名者が署名したという情報以外が漏れないため、匿名性を担保しながらアクセス制御が可能になる。どちらのポリシー型が適切かはアプ
リケーションによるが、一般的に平文ポリシー型の方が利便性が高い属性ベース
署名と考えられており、より多くの構成方法が知られている。

Maji ら [1] により初めて属性ベース署名が提案されて以降、扱えるアクセス構造
をより豊かにする研究が進み、今では論理回路やチューリング機械によって表現できる非常に幅広いアクセス構造を扱える属性ベース署名が知られている [2, 3, 4]。
いずれの方式も構成方法の概略は似ている。以下典型的な、論理回路をアクセス構造に扱える平文ポリシー型の属性ベース署名の実現方法の概略を説明する。記載する方式は、初めて論理回路をアクセス構造に扱える方式を楕円曲線上で達成した坂井ら [2] の方式を、電子署名・コミットメント方式・非対話型ゼロ知識証明と呼ばれる暗号要素技術で一般化した El Kaafarani と勝又 [4] の方式に基づいている。
■論理回路をアクセス構造に扱える平文ポリシー型の属性ベース署名

Setup: 管理者は、Setup アルゴリズムを実行し、システム共有のパラメータを生成する。具体的に、電子署名の公開鍵 vk と秘密鍵 sk、コミットメント方式の公開鍵 pkc を生成し、属性ベース署名の管理者公開鍵 mpk = (vk, pkc ) を公開し、管理者秘密鍵 msk = sk を保管する。
KeyGen(msk, x): 管理者は、KeyGen アルゴリズムを実行し、（L ビットにエンコードされた）属性 x ∈ {0, 1}L を所持するユーザの署名鍵 Kx を生成する。具体的に、管理者は sk を用いて、x に対して署名 σ を生成し、署名鍵 Kx = σ を65

出力する。

Sign(mpk, Kx , C, msg): 属性 x を所持するユーザは、Sign アルゴリズムを実行し、C(x) = 1 を満たす論理回路 C : {0, 1}L → {0, 1} で表されるアクセス構造が付随する平文 msg に対して署名を生成する。具体的に、以下の手順で署名を生成する。

1. 属性 x ∈ {0, 1} と署名鍵 Kx = σ を管理者公開鍵に含まれる pkc でコミットし、それらを各々 comx と comσ と置く。
2. 属性 x ∈ {0, 1} と署名鍵 Kx = σ を秘匿にしながら、次のような関係を示す非対話型ゼロ知識証明 π を生成し、Σ = (comx , comσ , π) を署名として出力する。本説明では、平文 msg が署名 Σ に紐づいていないが、一般
的には、論理回路 C か非対話型ゼロ知識証明の内部に msg を埋め込むことで紐づけられることに注意されたい。
（a） C(x) = 1 である。つまり、属性がアクセス構造を満たす。
（b） σ が管理者公開鍵に含まれる vk の下で正当な署名である。
（c） comx と comσ が管理者公開鍵に含まれる pkc の下で x と σ に対する
コミットメントである。

Verify(mpk, Σ, C, msg): 検証者は、Verify アルゴリズムを実行し、論理式 C によって表されるアクセス構造を満たす属性を所持したユーザが msg に対して署名 Σ を生成したかを確認する。具体的に、非対話型ゼロ知識証明の証明
Σ の第 3 項 π が正しいことを検証する。
■安全性について属性ベース署名は、適応的文書攻撃に対して存在的偽造不可能性（EUF-CMA 安全性）、および、秘匿性を満たす必要がある。前者は、一般的な電子署名における EUF-CMA 安全性に似ており、攻撃者がある論理回路 C ∗ で表されるアクセス構造が付随した（以下、C ∗ が付随した）平文 msg に対する署名 Σを偽造できないことを要求する。この際、攻撃者は、C ∗ (x) = 0 を満たす任意の属性 x（つまり、アクセス構造を満たさない x）に対する署名鍵 Kx を管理者から入手でき、さらに、異なる論理回路 C ̸= C ∗ が付随した平文 msg に対する署名を得られる。後者は、属性ベース署名に特有な安全性要件で、署名から属性情報が漏′れないことを要求する。具体的には、異なる属性 x∗ と x∗ が論理回路 C ∗ を満たす′

場合、C ∗ が付随した平文 msg に対して属性 x と x∗ を所持するいずれのユーザが署名を打ったかが識別できないことを要求する。これは、署名からはアクセス構
造を満たした誰かが署名を作成したことしか漏れず、具体的な属性が秘匿されることを表す。

66

上記で紹介した方式の EUF-CMA 安全性は、概略的には電子署名の EUF-CMA
安全性と非対話型ゼロ知識証明の健全性から導かれる。仮に攻撃者に属性ベース
署名の偽造ができたとした場合、非対話型ゼロ知識証明の健全性より、管理者公開鍵に含まれる電子署名の公開鍵 vk の下で正当な署名 σ を利用していなければならない。攻撃者は、管理者から C ∗ (x) = 0 を満たす任意の属性 x に対する署名
鍵 Kx = σ ′ を入手できるが、これらは C ∗ が付随した平文に署名することはできない。従って、攻撃者が偽造に利用した σ は、管理者から入手した σ ′ とは異なるが、これは電子署名の EUF-CMA 安全性に矛盾する。以上より、属性ベース署名の偽造を生成できる攻撃者がいないことが示される。
また、秘匿性については、コミットメントの秘匿性と非対話型ゼロ知識証明のゼロ知識性から直ちに導かれる。署名 Σ は、(comx , comσ , π) という形をしているが、コミットメントの秘匿性より comx と comσ は、属性 x と署名鍵 Kx の情報を隠す。さらに、非対話型ゼロ知識証明のゼロ知識性より、証明 π も正しい証拠を利用して証明が作られた以上の情報を漏らさない。以上より、Σ は、論理回路 C ∗を満たす属性で生成された署名である以上の情報を漏らしていない。
■具体的な実現方法について

現在知られている属性ベース署名のほとんどは上記構成に従っており、違いはどのような電子署名、コミットメント、非対話型ゼロ知識
証明を用いるかである。例えば、坂井ら [2] は上記一般構成の 2.(a) と 2.(b), (c) に各々特化した非対話型ゼロ知識証明 Groth-Sahai [5] と Groth-Ostrovsky-Sahai [6]を融合させることにより、Pairing 写像に基づく効率的な属性ベース署名を構成した。一方で、El Kaafarani と勝又 [4] は上記の暗号要素技術を耐量子計算機安全な道具で実現することで、初めて耐量子計算機安全な論理回路をアクセス構造に扱える属性ベース署名を構成した。

3.2.2 集約 MAC、マルチ MAC、集約署名、マルチ署名
メッセージ認証コード（Message Authentication Code，MAC）や電子署名は、ある平文を特定のユーザが認証したこと、署名したことを暗号学的に保証できる暗号技術である。MAC は秘密鍵を利用してタグを検証することができ、電子署名は
公開情報のみで署名を検証できる。通常の MAC や電子署名では、複数のユーザや平文に対してタグを付与したり、署名を生成する場合、MAC や署名を行う回数
だけタグや署名が生成されるため、タグや署名が数多く生成される。アプリケー
ションにおいてはスケーラビリティの課題となる。そこで、この課題を解決するための技術である集約 MAC、マルチ MAC、集約署名、マルチ署名を紹介する。

67

 集約 MAC [7]: 異なる平文に対して、複数の異なる秘密鍵で生成されたタ
グを、単一のタグに集約する技術であり、タグサイズの削減が可能となる。
タグ検証においても、集約したタグの検証のみで複数の平文の正当性を一括で検証可能となる。ただし、平文や秘密鍵は必ずしも異なるとは限らない。

 マルチ MAC [7]: 単一の平文に対して、複数の異なる秘密鍵で生成されたタグを、単一のタグに集約する技術である。タグ生成の際の平文が全ユーザで同一な、集約 MAC の特殊ケースとして捉えることができ、集約 MAC と比べてより効率的な構成が可能となる。

 集約署名 [8, 9]: 電子署名の枠組みで集約 MAC と同じ機能を実現する方法である。

 マルチ署名 [8, 9, 10, 11, 12]: 電子署名の枠組みでマルチ MAC と同じ機能を実現する方法である。
集約・マルチ MAC/署名の中には、集約する際に MAC/署名を生成するユーザ同士が対話する必要がある方式や、集約が逐次的にしか行えない方式等様々な方式があるため、用途に応じて選定することが求められる。一般的に、利便性が高い
方式ほど効率性が悪くなる傾向があることに注意されたい。例えば、常にネットに繋がっているサーバ同士でタグや署名を集約する場合は、効率を高めるために対話型の集約方式の利用が好ましい。一方で、一般のユーザがクラウドやブロッ
クチェーン上にアップロードしたタグや署名を集約する応用では、全ユーザが同時にオンラインであるとは限らないため、非対話型の集約方式の方が好ましい。
以下、代表的な方式を二つを紹介する。

F を鍵空間と出力空間が {0, 1}λ で入力空間が M の擬似ランダム関数とする。以下、平文空間に M を持つ集約 MAC を
F から構成する。
■Katz と Lindell による集約・マルチ MAC [7]KeyGen(1λ ): 各ユーザは、鍵生成アルゴリズムを実行し、F の鍵 K ← {0, 1}λ をサンプルし、秘密鍵 key = K を出力する。
MAC(key, msg ∈ M): ユーザは、タグ生成アルゴリズムを実行し、タグ tag ←F(K, msg) を生成する。
Aggregate((msgi , tagi )i∈[N ] ): タグ集約者は、各ユーザが生成した平文 msgi に対するタグ tagi を入力にタグ集約アルゴリズムを実行し、集約タグ tag =L
λi∈[N ] tagi ∈ {0, 1} を生成する。
Verify((keyi , msgi )i∈[N ] , tag): タグ検証者は、各ユーザの秘密鍵 keyi = Ki と署
名したであろう平文 msgi を入力にタグ検証アルゴリズムを実行し、tag =68

Li∈[N ] F(Ki , msgi ) が成り立てば、集約タグが正当だと判定する。ただし、異なる i, j ∈ [N ] に対して (keyi , msgi ) ̸= (keyj , msgj ) とする。
タグ検証アルゴリズムはタグ生成を再度行い、それが集約タグと同一かを確認する。タグ生成が決定的であることより、方式の正当性は確認できる。参考までに、
上記方式は擬似ランダム関数の代わりに、タグ生成が決定的な任意の MAC を利用することができる。詳細は [7] を参考にされたい。また、上記方式はタグ集約ア
ルゴリズムが同じ平文だけを入力に取るように制限することで、マルチ MAC にもなる。
■集約・マルチ MAC の安全性について

通常の MAC と同様に、適応的平文と署名攻撃に対して存在的偽造不可能性（EUF-CMVA 安全性）と同等の安全性を要求する。
この安全性は、秘密鍵 keyi = Ki を持つユーザが平文 msgi を署名していない限
り、Verify((keyi , msgi )i∈[N ] , tag) が正当と判断するような組み (keyi , msgi )i̸=j,i∈[N ]と集約タグ τ を攻撃者が出力できないことを意味する。ただし、攻撃者は任意のタグと平文の組み (σ, msg) が秘密鍵 keyi の元で正しい署名か検証してもらえるとする。EUF-CMVA 安全性を上記方式が満たすことは、F が擬似ランダム関数であることより直ちに導かれる。

G0 , G1 , GT を素数位数 p を持つ群として、g0 を G0 の生成元、e : G0 × G1 → GT を付随する（非対称）Pairing 写像とする。また、H0 と H1 をハッシュ関数とする。以下、平文空間に M を持つ集

■Boneh, Drijvers と Neven による集約・マルチ署名 [9]約署名を構成する。

KeyGen : 各ユーザは、鍵生成アルゴリズムを実行し、a ← Zp をサンプルし、公開鍵 pk = h = g0a ∈ G0 と秘密鍵 sk = a を生成する。
Sign(sk, msg) : ユーザは、署名生成アルゴリズムを実行し、署名 σ = H0 (msg)sk ∈G1 を生成する。
Aggregate((pki , msgi , σi )i∈[N ] ) : 署名集約者は、各ユーザが生成した平文 msgi に対する署名 σi を入力に署名集約アルゴリズムを実行し、まず (t1 , · · · , tN ) ←Qti
H1 (pk1 , · · · , pkN ) ∈ ZNを計算し、集約署名σ=pi∈[N ] σi を生成する。
Verify((pki , msgi )i∈[N ] , σ) : 署 名 検 証 者 は 、各 ユ ー ザ の 公 開 鍵 pki = g aiと 署 名 し た で あ ろ う 平 文 msgi を 入 力 に 署 名 検 証 ア ル ゴ リ ズ ム を
実 行 し 、ま ず (t1 , · · · , tN ) ← H1 (pk1 , · · · , pkN ) ∈ ZN
p を計算し、Qtie(g, σ) =i∈[N ] e(pki , H0 (msgi )) が 成 り 立 て ば 、集 約 タ グ が 正 当 な ものだと判定する。

69

アルゴリズムの正当性は、下記の数式が成立するこから確認できる。

Ye(g0 , σ) = e(g0 ,Yσiti ) =i∈[N ]e(g0 , H0 (msgi )ski ·ti ) =i∈[N ]Ye(pktii , H0 (msgi ))i∈[N ]

さらに、各ユーザが同じ平文 msg を署名するマルチ署名の設定においては、予め集約された公開鍵 apk =Qi∈[N ] pki ∈ G0 を計算することで、集約署名の検証

は e(g, σ) = e(apk, H0 (msg)) を確かめるだけである。計算コストが比較的に高い

Pairing 写像の計算が (n + 1) 回から 2 回にでき、マルチ署名の方が集約署名よりも検証コストが少なくなる。集約・マルチ MAC の場合、このような検証コストの差はない。
■集約・マルチ署名の安全性について

集約・マルチ MAC の場合と同様、通常の電子署名における適応的平文攻撃に対して存在的偽造不可能性（EUF-CMA 安全性）と同等の安全性を要求する。ただし、MAC とは違い、電子署名では検証を攻撃
者自身が行えるため、選択署名攻撃を考慮に入れなくてよいことに注意されたい。上述の方式は、Boneh ら [13] の電子署名の自然な集約・マルチ署名への拡張になっているが、EUF-CMA 安全性も大まかには同様に導かれる。具体的には、(g0a , g1a , g b ) ∈ G0 × G1 × G1 を与えられても g0ab ∈ G0 を求めることができないという、co-Computational Diﬃe-Hellman 仮定の困難性より導かれる。
■その他の方式

署名の設定において、現在最も効率的な集約署名は上記で紹介した Boneh ら [9] の方式である。マルチ署名については、署名集約アルゴリズムで各ユーザが対話することを許せば、Pairing 写像を用いないより効率的な方式がある。Bellare と Neven[10] は、対話を 3 ラウンド許すことで離散対数問題の困難性仮定を基にしたマルチ署名を構成し、署名長は Schnorr 署名 [14] と同じである。
近年、より強い困難性仮定を基にすることで、[10] の方式のラウンド数を減らしより効率性を高めた方式が提案されている [11, 12]。

3.2.3 グループ署名■グループ署名の特徴

従来の電子署名では、署名検証の際に署名者が誰であるか明

示的に分かってしまう。グループ署名は、従来の電子署名と異なり、署名者の匿名性を保証することができる特徴を有する。グループ署名における匿名性とは、ある組織（グループ）に属するメンバのだれかが署名したことしか検証者には分からない性質である。グループ署名では、署名者と検証者に加えて、発行者と呼ばれる各グループメンバに署名生成用の署名鍵を発行する管理者と、開示者と呼ばれる署名から真の署名者を開示する管理者を含む。ただし、それぞれの管理者は機70

能分離されていなくてもよい。
署名者の匿名性を保証する高機能暗号技術としてリング署名 (第 3.2.4 章参照）があるが、グループ署名とリング署名は以下の相違がある。

 アドホック性：リング署名では各署名者は独自に鍵生成を行い検証鍵を公開し、署名生成時に任意の検証鍵集合を選択して含めることでグループをアドホックに構成できるのに対し、グループ署名では発行者と署名鍵を生成したユーザ集合がグループとなる。

 署名者開示の有無：リング署名では署名鍵が開示されたとしても真の署名者であるかどうか分からないのに対し、グループ署名では開示者により真の署名者を開示できる。
この相違に応じ、リング署名は管理者無しの環境で強い匿名性を要求する状況、グループ署名は管理者がグループを管理し緊急時には真の署名者を開示可能である
ことを要求する状況で使い分けることが望ましい。
■グループ署名の歴史

グループ署名の概念は、Chaum と Van Heyst [15] によって初めて提案された。同時にいくつかの方式が提案されたが、グループメンバをセッ
トアップ後は追加不可能である静的グループに制限されている方式であるか、もしくは開示者が真の署名者を開示する際にグループメンバとの対話が必要という問題があった。また、数学的な安全性定義が示されておらず、非形式的な安全性評価しかされていなかった。
その後、Bellare らによって、静的グループの場合 [16] と署名生成後でも新たなグループメンバを追加可能な動的グループの場合 [17] における統一的な数学的安全性定義がそれぞれ提案された。加えて、Bellare らは従来の電子署名、公開鍵
暗号、非対話ゼロ知識証明から一般的に安全なグループ署名を構成する手法を提案した。Bellare らの構成法では、メンバ追加時は、各メンバは発行者から自分がグループに属していることを示す証明書を受け取り、証明書を含む署名鍵を生成する。署名生成時は、自分の ID に紐づいた証明書の暗号文とともに、証明書を知ることと暗号文が正しいことを証明する非対話ゼロ知識証明を署名として出力する。開示者による署名開示時は、署名に含まれる暗号文を復号し、ID を特定した上で、（必要に応じて）開示内容が正しいことを示す非対話ゼロ知識証明を出力する。Bellare らの安全性定義に基づき、Pairing 写像を利用した署名長の短い方式 [18, 19] 等が提案されている。
また、グループメンバの証明書を失効する機能を持つ方式も知られており、グループ管理者が失効リストを配布し、署名者がそれに基づいて署名を生成し、検証
71

者が失効済みかどうか検証するリスト公開型失効 [20] と、署名生成時は失効リス
トを用いずに検証者のみがリスト検証する検証者ローカル型失効 [21] がある。検証者ローカル型失効では、新たな失効者が出る際に、その都度、グループメンバに通知する必要が無いため、リスト公開型失効よりも効率的である。
近年では、量子計算機実用化の研究の進展に伴い、大規模な量子計算機が実現したとしても安全性を保つ耐量子計算機安全な方式の研究が進んでおり、格子問
題に基づく方式 [22, 23, 24] が主に提案されている。
■グループ署名方式の比較

一般に、グループ署名の安全性として以下の 3 つの性質が要求される。

 匿名性：開示者以外（発行者も含む）は署名から真の署名者を識別できない。
 追跡可能性：開示者が署名者を追跡不可能であり、かつ、検証に合格する署
名を攻撃者は生成することができない。

 濡れ衣不可能性：管理者であっても、署名を作成していないメンバに対して真の署名者であると証明できない。

Bellare らの構成法 [16, 17] 以降に提案された方式の多くは、彼らの構成法を基としており、上記の性質を満たしている。
また、グループ署名の効率は以下の観点で比較できる。

 グループ公開鍵長
 署名長
 署名計算量

Chaum と Van Heyst の方式 [15] の方式は、グループ公開鍵長、署名長、署名計
算量のいずれもグループメンバ数に比例しているが、Camenisch と Stadler [25]によってグループ公開鍵長、署名長、署名計算量のいずれも定数長の RSA 仮定に基づく方式が提案され、以後古典計算機に対して安全な方式のほとんどは定数長を達成している。その中でも、Pairing 写像を利用したグループ署名方式 [18, 19]
では署名長をグループ署名ではない CRYPTREC 暗号リスト [26] に掲載されている電子署名の数倍程度まで短くすることができる。耐量子計算機安全な方式では、
グループ公開鍵長と署名計算量が定数長の方式 [24] やグループ公開鍵長と署名長が定数長の方式 [23] が知られている。
■代表的な方式のアルゴリズム

具体的なグループ署名の実現方法として、公開鍵暗号と電子署名に基づく静的な方式 [16] を紹介する。

72

Setup(1k , 1n ): 管理者鍵生成アルゴリズム。k をセキュリティパラメータ、n をグ
ループの最大メンバ数とし、共通参照情報 crs、公開鍵暗号の復号鍵と暗号化
鍵 (dk, ek)、電子署名の署名鍵と検証鍵 (msk, mvk) を生成し、発行者の秘密
鍵 ik = msk 、開示者の秘密鍵 ok = dk 、グループ公開鍵 gpk = (crs, mvk, ek)を出力する。

KeyGen(i, ik, gpk): メンバ鍵生成アルゴリズム。メンバ i は電子署名の署名鍵と検証鍵 (ski , vki ) を生成し、vki を発行者に送る。発行者は msk を用いて、(i, vki ) をメッセージとした署名 certi を生成し、証明書としてメンバに送る。
メンバは秘密鍵 gski = (i, ski , vki , certi ) を出力する。
Sign(gski , m): 署名者 i の署名生成アルゴリズム。メッセージ m に対して、skiを用いて署名 s を生成し、乱数 r を選び、ek を用いて (i, vki , certi , s) を暗号化した暗号文 ct を計算する。crs を用いて、次のような関係を示す非対話
ゼロ知識証明 π を生成する。
(mvk の下で ((i, vki) , certi ) が正しい署名) かつ (vki の下で (m, s) が正しい署名)
かつ (ek の下で ct が(i, vki , certi , s) の正しい暗号文) 署名 σ = (ct, π) を出力する。
Verify(gpk, m, σ): 署名検証アルゴリズム。π が成り立つかチェックする。
Open(ok, gpk, m, σ): 署名者開示アルゴリズム。π が成り立つかチェックし、dkを用いて ct から (i, vki , certi , s) を復号し、i を出力する。
3.2.4 リング署名■リング署名の特徴

リング署名は、匿名署名の一種であり、あるグループの誰かが署名したことはわかる（偽造不可能性）が、そのグループの誰が署名したかはわからない（匿名性）、という性質を持っている。具体的には、リング署名は、リングと呼ばれる n 人の署名参加者の集合に対して、リングのなかの少なくとも 1 人の署名者が署名を生成したことは確認できるが、リングのなかの誰が署名を生成したかはわからない、ことを示す署名である。リング署名は、リングに属する n 人の署名参加者の公開鍵に対して、少なくとも 1 人の署名参加者の秘密鍵を知っていることを示す、非対話 1-out-of-n OR 証明と見ることもできる。
匿名署名の一種であるグループ署名（第 3.2.3 章参照）と比較すると、以下ような相違がある。

 アドホック性：リング署名では、各署名者は独自に鍵生成を行い検証鍵を公開し、署名生成時に署名者が任意の検証鍵集合を選択することでグループを
アドホックに構成できる。一方、グループ署名では、発行者（グループ管理
73者）と協力して署名鍵を生成したユーザの集合がグループとなる。

 署名者開示の有無：リング署名では、署名者であっても、真の署名者を開示することはできない。一方、グループ署名では、開示者（グループ管理者）
は、真の署名者を開示することができる。
このように、リング署名は、署名生成時にアドホックにグループを選ぶことができ、グループ管理者が必要なく非中央集権的である、という特徴を持っている。
■リング署名の歴史

リング署名は、Rivest, Shamir, Tauman [27] によって初めて提案され、落戸付一方向性置換に基づく方式が示された。その後、離散対数問題に基づくリング署名方式 [28] が提案された。これらの方式で用いられている典型的なリング署名の構成法では、n 人の署名参加者の集合であるリングに対して、リングのなかの署名者以外の署名参加者の公開鍵を用いて n − 1 個の値の連鎖を生成し、署名者の秘密鍵を用いて連鎖を環になるように連結する 1 個の値を生成することによって、値の連鎖の環を構成しそれを署名としている。署名者の秘密鍵を用いて連結した部分は、署名者の秘密鍵が分かったとしても特定することができず、強い匿名性を実現している。また、署名サイズは O(n) となっている。
通常のリング署名は前述の通り、署名者であっても自分が真の署名者であることを証明できない強い匿名性を保証しているが、応用のために匿名性を制限した
方式も知られている。リンク可能リング署名 [29] では、同じ秘密鍵とタグを用いて異なる 2 つのメッセージについて生成された署名を、リンクすることができる。
トレース可能リング署名 [30] では、同じ秘密鍵とタグを用いて異なる 2 つのメッ
セージについて生成された署名から、署名者を特定することができる。リング署
名の非中央集権的な構成が暗号資産に適しており、上記の性質により暗号資産の二重使用を防ぐことができるため、リンク可能リング署名やトレース可能リング
署名は匿名の暗号資産で用いられている。
また、しきい値リング署名 [31, 32] は、1-out-of-n のリング署名を k-out-of-n に一般化したものであり、n 人の署名参加者の集合であるリングに対して、リングのなかの少なくとも k 人の署名者が協力して署名を生成したことを確認することができる署名である。
■リング署名方式の比較

リング署名の安全性として以下の 2 つの性質が要求される。

 匿名性: n 人のリングのなかの誰が署名者であるか、署名から特定できない。
 偽造不可能性: n 人のリングのなかの少なくとも 1 人の署名者の秘密鍵がな
ければ、署名を生成できない。

74

リング署名方式の多くは、上記の性質を満たしている。匿名性を制限したものとして、前述のリンク可能リング署名とトレース可能リング署名がある。さらに、ア
カウント可能リング署名 [33] では、開示者を置くことによって署名者の開示を可能としている。ただし、アカウント可能リング署名では、グループ署名とは異なり発行者は必要なく署名生成時にグループを選ぶことができる。また、偽造不可能性を k-out-of-n に一般化したものとして、前述のしきい値リング署名がある。
また、リング署名の効率は以下の観点で評価される。

 署名サイズ 署名生成と検証に必要な計算量
リング署名方式の多くは、リングの署名参加者の数を n とすると、署名サイズがO(n) である。1-out-of-n の効率的なゼロ知識証明を用いることで、署名サイズをO(log n) にできる方式が知られている [34, 35, 36, 37]。また、信頼できるセット
アップを仮定することで、アキュムレータにより n 個の公開鍵を圧縮し署名サイズを定数にできる方式も提案されている [38]。
また、基づいている計算量仮定の観点では、耐量子計算機安全性を持つリング
署名方式が提案されている [39, 35, 36, 37]。
■代表的な方式のアルゴリズム

具体的なリング署名の実現方法として、Abe, Ohkubo,

Suzuki による離散対数問題に基づく方式 [28] を紹介する。署名者 i について、qiを素数、gi を位数 qi の巡回群 Gi の生成元、Hi : {0, 1}∗ → Zqi をハッシュ関数とする。

KeyGen(qi , Gi , gi ): 鍵生成アルゴリズム。
1. 署名者 i は、秘密鍵 xi ∈ Zqi をランダムに選び、公開鍵 (qi , Gi , gi , yi = gixi )を計算する。

Sign(xa , L = {y1 , ..., yn }, m): 署名生成アルゴリズム。
1. 署名者 a ∈ {1, ..., n} は、秘密鍵 xa と公開鍵のリスト L = {y1 , ..., yn } とメッセージ m を入力として受け取る。
2. 署 名 者 a は 、ra ∈ Zqa を ラ ン ダ ム に 選 び 、ea = gara と ca+1 =Ha+1 (L, m, ea ) を計算する。
3. 署 名 者 a は 、si ∈ Zqi を ラ ン ダ ム に 選 び 、ei = gisi yici と ci+1 =Hi+1 (L, m, ei ) を、i = a + 1, ...n, 1, ..., a − 1（ただし i = n + 1 = 1 とする）について計算する。

4. 署名者 a は、sa = ra − ca xa mod qa を計算する。

75

5. 署名者 a は、署名 σ = (c1 , s1 , ..., sn ) を出力する。
Verify(L = {y1 , ..., yn }, σ, m): 署名検証アルゴリズム。
1. 検証者は、公開鍵のリスト L = {y1 , ..., yn } と署名 σ = (c1 , s1 , ..., sn ) とメッセージ m を入力として受け取る。
2. 検証者は、ei = gisi yici と ci+1 = Hi+1 (L, m, ei ) を、i = 1, ..., n − 1 について計算する。

3. 検証者は、en = gnsn yncn を計算する。
4. 検証者は、もし c1 = H1 (L, m, en ) なら受理を出力し、そうでなければ非受理を出力する。
なお、この方式は、n = 1 のとき Schnorr 署名となっており、Schnorr 署名の自然な拡張になっている。

3.2.5 しきい値署名■しきい値署名の特徴(k, n) しきい値署名とは、ある (k, n : k ≤ n) である自然数の組に対して、以下のアルゴリズムから成る公開鍵署名方式である。

1. 公開鍵署名の署名生成鍵と検証鍵のペアを生成する。
2. 署名生成鍵を n 個のシェアに分割する（しきい値秘密分散）。シェアとは、元のデータを複数のデータに分割したものである。

3. 1 つのメッセージに対していくつかのシェアで署名を生成する。
4. シェアから生成された署名を k 個以上集め、組み合わせる処理を行う。
5. 組み合わされた署名に対し、検証鍵で検証を行い、検証結果を出力する。
偽造等の不正が行われず正当にこのアルゴリズムが実行された場合、第 4 項で組み合わされた署名は、第 1 項で生成された署名鍵を用いて生成された署名と同等となり、第 5 項の検証処理を通る署名となる。
しきい値署名は一般的な DSA 等の公開鍵署名方式と比較すると、ベースとなる
しきい値秘密分散の特性によって署名生成鍵を複数にすることができるため、しきい値未満の漏洩や故障に対して優位性を持つ。類似したアクセス構造を実現する署名方式として「署名生成の際に設定された（しきい値等の）アクセス構造を満たす属性集合に対応する署名生成鍵を持つ署名者は単一の正当な署名を生成できる」属性ベース署名が存在するが、属性ベース署名では署名者は単一であり、単体ではアクセス構造を満たさない属性を複数の署名者が持ち寄っても正当な署名は作れない。一方でしきい値署名は複数の署名者に署名生成権限を分散すること76を想定しており、漏洩・故障等への耐性を持つことが属性ベース署名とは異なる。
また、マルチパーティ計算のように複数の参加者が想定される署名プロトコルであるため、鍵生成については、信頼できる鍵生成・配布を行うトラステッドディー
ラーを仮定する場合と、各参加者が独自に鍵を生成した上で暗黙的に署名生成鍵や署名検証鍵が決定される分散鍵生成を用いる方式が存在する。
しきい値署名におけるの安全性の定義には以下が存在する。

 偽造不可能性（Unforgeablity）：しきい値未満のシェアで生成された署名を集めただけでは、検証鍵で検証可能である正当な署名は生成不可能。さらに不正者の数によって以下のように定義が分かれる。

– dishonest majority：不正者が n/2 以上しきい値未満– honest majority：不正者が n/2、かつしきい値未満
 堅牢性（Robustness）：正規のシェアがしきい値以上集まれば、必ず正当な署名が生成可能 Identiﬁable abort：正直な署名者は不正なシェアが少なくとも 1 つ以上含まれていることを検知可能

 Proactive security：長期的な期間でのシェアの漏洩に対して安全
また署名アルゴリズムとしての安全性もあるため、例えば後述する BLS 署名
をベースとしたしきい値署名ではランダムオラクルモデルのもとで Gap Diﬃe-Hellman 問題の困難性を安全性の根拠として、選択メッセージ攻撃に対する存在
的偽造不可能性が証明されている。
■しきい値署名の歴史

しきい値署名は 1987 年 Desmedt によって最初にコンセプ

トが提案 [40] され、同じく Desmedt と Frankel によって ElGamal 暗号 [41] とShamir のしきい値秘密分散 [42] を組み合わせた方式が提案された [43]。Gennaro
らは安全性証明がついた ElGamal 方式ベースのしきい値署名を 1996 年に発表し[44]、Shoup は同期通信を必要としない RSA 署名をベースとした方式を発表している [45]。また署名の検証に署名生成者の協力が必要な Undeniable な方式や、検証者を複数にする (k, l)-Shared Veriﬁcation 方式等、様々な方式が提案されている。
近年では暗号資産に関連した技術として注目されている。例えば、Bitcoin では
署名者のプライバシに関する問題やトランザクションのストレージ効率化に向けてしきい値署名を採用しやすい Schnorr 署名をとりいれている [46]。また、効率的なスキームとして FROST[47] 等が考案されており、利用されるケースが増えてきている。ECDSA を取り入れたしきい値署名に関する提案が数多くあり [48] セ77

キュリティの強化やプロトコルの効率化を目指して様々な方式があげられている[49, 50, 51, 52, 53, 54, 55, 56]。最近では Groth と Shoup によって効率的で堅牢な方式 [57] が提案されている。
■しきい値署名方式の比較

しきい値署名は様々な方式が提案されているがベースとなる署名方式やしきい値秘密分散・分散鍵生成の方式によって効率性や安全性が異なる。
効率性では、(1) 鍵長・署名長などの各パラメータサイズ、(2) シェア生成・組み合わせ処理などの各オペレーション速度、(3) エンティティ間の同期が必要か否かの違いがあげられるが、(1)(2) はベースとなる署名方式や定義されている演算処理（楕円曲線演算や Pairing 写像）によって異なる。例えば、128bit セキュリティ程
度のパラメータを基準とすると ECDSA（secp256r1）および EdDSA（Ed25519）
ベースのしきい値署名 [57, 47] の各シェア自身のサイズは署名生成鍵と同等で256bit、シェアから生成される署名長は 512bit となる。BLS 署名（BLS12-381）
ベースのしきい値署名 [58] の場合、各シェアのサイズは 256bit、署名長は 768bitとなる [59]。なお、数値については圧縮を使った表現も含まれており、シェアに対するコミットメントの保持や通信回数の効率化や安全性の向上のために事前計算を行った signature helpers を共有することもあるため、参加者が保持するデータ量はこれより増加することがある。(3) については方式が同期式・非同期式なのかによって異なり先の項目でもあげたが事前計算を行うことによって非同期式を実現し高速化を行うことがある。また鍵生成方式においてもベースとなる分散鍵生成方式の違いによって決まってくる。例えば通信ラウンド数の比較では Pedersen-

DKG[60] は 3 ラウンド、Gennaro-DKG[61] は 4 ラウンド、FROST-DKG[47] は
1 ラウンドというように方式によって大きな違いがありネットワークレイテンシを考慮すると性能に大きな差が生じる可能性がある。しきい値署名に関する各文献で多くの方式が比較されているが、最近の比較では [56] の Figure1 や [62] のTable1 などがあげられる。
■代 表 的 な ア ル ゴ リ ズ ム・方 式

こ こ で は Ethereum な ど で 既 に 用 い ら れ て い る

Boldyreva が提案した BLS 署名 [13] ベースのしきい値署名 [58] を紹介する。
以下では、(t, n)-しきい値署名とし、n 人の参加者を P1 , ..., Pn とする
Setup(1κ ): BLS 署名のセットアップはセキュリティパラメータ κ を入力にとり、素数 p、p を位数とする巡回群 G1 , G2 , GT 、各巡回群を使って定義される Pairing 写像 e : G1 × G2 → GT 、文字列から G1 の元へのハッシュ関数
H : {0, 1}∗ → G1 、G2 の元からランダムに決定した Q を準備し公開パラ78

メータ P arams := (p, G1 , G2 , GT , e, H, Q) とする

SharedKeygen(P arams, t, n): 分散鍵生成アルゴリズム [61] を利用して BLS 署
名鍵ペア (vk, sk)（ただし、sk ∈ Z∗p , vk = skQ) に対するシェア {vki , ski :1 ≤ i ≤ n} を (t, n) 秘密分散になるよう各参加者が保持する。
SharedSign(P arams, m, ski ): 参加者はメッセージ m に対して σi = ski H(m) を計算し提出する

Verify((P arams, m, {σij }1≤j≤t , {vkij }1≤j≤t , vk)): 1. 参加者から収集した各 j に対して、e(σij , Q) = e(H(m), vkij ) が成り立つことを確認する
P
2. 正規の署名を σ = 1≤j≤t L(ij )σij により計算する。ただし、L(ij ) は分
散鍵生成におけるラグランジュ補間係数である。

3. vk を使って e(σ, Q) = e(H(m), vk) により署名を検証する。

参考文献[1] H. K. Maji, M. Prabhakaran and M. Rosulek: “Attribute-Based Signatures”, CT-RSA 2011, Springer-Verlag, pp. 376–392 (2011).
[2] Y. Sakai, N. Attrapadung and G. Hanaoka: “Attribute-Based Signatures
for Circuits from Bilinear Map”, PKC 2016, Springer-Verlag, pp. 283–300(2016).
[3] Y. Sakai, S. Katsumata, N. Attrapadung and G. Hanaoka: “AttributeBased Signatures for Unbounded Languages from Standard Assumptions”,
ASIACRYPT 2018, Springer-Verlag, pp. 493–522 (2018).
[4] A. El Kaafarani and S. Katsumata: “Attribute-Based Signatures for Unbounded Circuits in the ROM and Eﬃcient Instantiations from Lattices”,
PKC 2018, Springer-Verlag, pp. 89–119 (2018).
[5] J. Groth and A. Sahai: “Eﬃcient Noninteractive Proof Systems for Bilinear
Groups”, SIAM J. Computing, 41(5), pp. 1193–1232 (2012).
[6] J. Groth, R. Ostrovsky and A. Sahai: “New Techniques for Noninteractive
Zero-Knowledge”, J. ACM, 59(3), pp. 1–35 (2012).
[7] J. Katz and A. Y. Lindell: “Aggregate Message Authentication Codes”,
CT-RSA 2008, Springer-Verlag, pp. 155–169 (2008).
[8] D. Boneh, C. Gentry, B. Lynn and H. Shacham: “Aggregate and Veriﬁably
Encrypted Signatures from Bilinear Maps”, EUROCRYPT 2003, SpringerVerlag, pp. 416–432 (2003).
79[9] D. Boneh, M. Drijvers and G. Neven: “Compact Multi-Signatures for
Smaller Blockchains”, ASIACRYPT 2018, Springer-Verlag, pp. 435–464(2018).
[10] M. Bellare and G. Neven: “Multi-Signatures in the Plain Public-Key Modeland a General Forking Lemma”, ACM CCS 2006, pp. 390–399 (2006).
[11] C. Komlo and I. Goldberg: “FROST: Flexible Round-Optimized Schnorr
Threshold Signatures”, SAC 2020, Springer-Verlag, pp. 34–65 (2020).
[12] J. Nick, T. Ruﬃng and Y. Seurin: “MuSig2: Simple Two-Round Schnorr
Multi-Signatures”, CRYPTO 2021, Springer-Verlag, pp. 189–221 (2021).
[13] D. Boneh, B. Lynn and H. Shacham: “Short Signatures from the Weil
Pairing”, J. of Cryptology, 17(4), pp. 297–319 (2004).
[14] C.-P. Schnorr: “Eﬃcient Identiﬁcation and Signatures for Smart Cards”,
CRYPTO 1989, Springer-Verlag, pp. 239–252 (1989).
[15] D. Chaum and E. V. Heyst: “Group Signatures”, EUROCRYPT 1991,
Springer-Verlag, pp. 257–265 (1991).
[16] M. Bellare, D. Micciancio and B. Warinschi: “Foundations of Group Signatures: Formal Deﬁnitions, Simpliﬁed Requirements, and a Construction
Based on General Assumptions”, EUROCRYPT 2003, Springer-Verlag, pp.
614–629 (2003).
[17] M. Bellare, H. Shi and C. Zhang: “Foundations of Group Signatures: The
Case of Dynamic Groups”, CT-RSA 2005, Springer-Verlag, pp. 136–153(2005).
[18] D. Boneh, X. Boyen and H. Shacham: “Short Group Signatures”, CRYPTO
2004, Springer-Verlag, pp. 41–55 (2004).
[19] J. Groth: “Fully Anonymous Group Signatures without Random Oracles”,
ASIACRYPT 2007, Springer-Verlag, pp. 164–180 (2007).
[20] J. Camenisch and A. Lysyanskaya: “Dynamic Accumulators and Application to Eﬃcient Revocation of Anonymous Credentials”, CRYPTO 2002,
Springer-Verlag, pp. 61–76 (2002).
[21] B. Boneh and H. Shacham: “Group Signatures with Veriﬁer-Local Revocation”, ACM CCS 2004, pp. 168–177 (2004).
[22] S. D. Gordon, J. Katz and V. Vaikuntanathan: “A Group Signature Schemefrom Lattice Assumptions”, ASIACRYPT 2010, Springer-Verlag, pp. 395–
412 (2010).

80

[23] S. Katsumata and S. Yamada: “Group Signatures Without NIZK: From
Lattices in the Standard Model”, EUROCRYPT 2019, Springer-Verlag, pp.
312–344 (2019).
[24] V. Lyubashevsky, N. Nguyen, M. Plancon and G. Seiler: “Shorter LatticeBased Group Signatures via Almost Free Encryption and Other Optimizations”, ASIACRYPT 2021, Springer-Verlag, pp. 218–248 (2021).
[25] J. Camenisch and M. Stadler: “Eﬃcient group signature schemes for large
groups”, CRYPTO 1997, Springer-Verlag, pp. 410–424 (1997).
[26] CRYPTREC: “電子政府における調達のために参照すべき暗号のリスト”.
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r6.pdf.
[27] R. Rivest, A. Shamir and Y. Tauman: “How to Leak a Secret”, ASIACRYPT 2001, Springer-Verlag, pp. 552–565 (2001).
[28] M. Abe, M. Ohkubo and K. Suzuki: “1-out-of-n Signatures from a Variety
of Keys”, ASIACRYPT 2002, Springer-Verlag, pp. 415–432 (2002).
[29] J. Liu, V. Wei and D. Wong: “Linkable Spontaneous Anonymous Group
Signature for Ad Hoc Groups (Extended Abstract)”, ACISP 2004, SpringerVerlag, pp. 325–335 (2004).
[30] E. Fujisaki and K. Suzuki: “Traceable Ring Signature”, PKC 2007,
Springer-Verlag, pp. 181–200 (2007).
[31] E. Bresson, J. Stern and M. Szydlo: “Threshold Ring Signatures and Applications to Ad-hoc Groups”, CRYPTO 2002, Springer-Verlag, pp. 465–480(2002).
[32] M. Abe, M. Ohkubo and K. Suzuki: “Eﬃcient Threshold Signer-Ambiguous
Signatures from Variety of Keys”, IEICE Trans., E87-A(2), pp. 471–479(2004).
[33] S. Xu and M. Yung: “Accountable Ring Signatures: A Smart Card Approach”, CARDIS, vol. 153 of IFIP, pp. 271–286 (2004).
[34] J. Groth and M. Kohlweiss: “One-out-of-Many Proofs: Or How to Leak a
Secret and Spend a Coin”, EUROCRYPT 2015, Springer-Verlag, pp. 253–
280 (2015).
[35] W. Beullens, S. Katsumata and F. Pintore: “Calamari and Falaﬂ: Logarithmic (Linkable) Ring Signatures from Isogenies and Lattices”, ASIACRYPT
2020, Springer-Verlag, pp. 464–492 (2020).
[36] V. Lyubashevsky, N. Nguyen and G. Seiler: “SMILE: Set Membership from81

Ideal Lattices with Applications to Ring Signatures and Conﬁdential Transactions”, CRYPTO 2021, Springer-Verlag, pp. 611–640 (2021).
[37] T. Yuen, M. Esgin, J. Liu, M. Au and Z. Ding: “Dualring: Generic Construction of Ring Signatures with Eﬃcient Instantiations”, CRYPTO 2021,
Springer-Verlag, pp. 251–281 (2021).
[38] Y. Dodis, A. Kiayias, A. Nicolosi and V. Shoup: “Anonymous Identiﬁcation in Ad Hoc Groups”, EUROCRYPT 2004, Springer-Verlag, pp. 609–626(2004).
[39] M. Esgin, R. Zhao, R. Steinfeld, J. Liu and D. Liu: “MatRiCT: Eﬃcient,
Scalable and Post Quantum Blockchain Conﬁdential Transactions Protocol”, ACM CCS 2019, pp. 567–584 (2019).
[40] Y. Desmedt: “Society and Group Oriented Cryptography: A New Concept”, CRYPTO 1987, Springer-Verlag, pp. 120–127 (1987).
[41] T. ElGamal: “A Public Key Cryptosystem and Signature Scheme Based on
Discrete Logarithms”, IEEE Trans. Inform. Theory, 31, pp. 469–472 (1985).
[42] A. Shamir: “How to Share a Secret”, Commun. ACM, 22, 11, pp. 612–613(1979).
[43] Y. Desmedt and Y. Frankel: “Threshold Cryptosystems”, CRYPTO 1989,
Springer-Verlag, pp. 307–315 (1989).
[44] R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin: “Robust Threshold
DSS”, EUROCRYPT 1996, Springer-Verlag, pp. 354–371 (1996).
[45] V. Shoup: “Practical Threshold Signatures”, EUROCRYPT 2000, SpringerVerlag, pp. 207–220 (2000).
[46] “BBitcoin Improvement Proposal 340”. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki.
[47] C. Komlo and I. Goldberg: “FROST: Flexible Round-Optimized Schnorr
Threshold Signatures”. ePrint 2020/852.
[48] J. P. Aumasson, A. Hamelink and O. Shlomovits: “A Survey of ECDSA
Threshold Signing”. ePrint 2020/1390.
[49] Y. Lindell, A. Nof and S. Ranellucci: “Fast Secure Multiparty ECDSA with
Practical Distributed Key Generation and Applications to Cryptocurrency
Custody”, ACM CCS 2018, pp. 1837–1854 (2018).
[50] R. Gennaro and S. Goldfeder: “Fast Multiparty Threshold ECDSA with
Fast Trustless Setup”, ACM CCS 2018, pp. 1179–1194 (2018).

82

[51] J. Doerner, Y. Kondi, E. Lee and A. Shelat: “Secure Two-Party Threshold
ECDSA from ECDSA Assumptions: The multiparty Case”, IEEE S&P2018, pp. 980–997 (2018).
[52] I. Damgard, T. P. Jakobsen, J. B. Nielsen, J. I. Pagter and M. B. Østergaard:“Fast Threshold ECDSA with Honest Majority”, SCN 2020, SpringerVerlag, pp. 382–400 (2020).
[53] R. Gennaro and S. Goldfeder: “One Round Threshold ECDSA with Identiﬁable Abort”. ePrint 2020/540.
[54] G. Castagnos, D. Catalano, F. Laguillaumie, F. Savasta and I. Tucker:“Bandwidth-Eﬃcient Threshold EC-DSA”, PKC 2020, Springer-Verlag, pp.
266–296 (2020).
[55] A. Gagol, J. Kula, D. Straszak and M. Świetek: “Threshold ECDSA for
Decentralized Asset Custody”. ePrint 2020/498.
[56] R. Canetti, R. Gennaro, S. Goldfeder, N. Makriyannis and U. Peled: “UC
Non-Interactive, Proactive, Threshold ECDSA with Identiﬁable Aborts”,
ACM CCS 2020, pp. 1769–1787 (2020).
[57] J. Groth and V. Shoup: “Design and Analysis of A Distributed ECDSA
Signing Service”. ePrint 2022/506,.
[58] A. Boldyreva: “Threshold Signatures, Multisignatures and Blind Signatures
Based on the Gap-Diﬃe-Hellman Group Signature Scheme”, PKC 2003,
Springer-Verlag, pp. 31–46 (2003).
[59] Y. Sakemi, T. Kobayashi, T. Saito and R. S. Wahby: “Draft-irtf-cfrgpairing-friendly-curves-10” (2021).
[60] T. P. Pedersen: “A Threshold Cryptosystem without a Trusted Party”,
EUROCRYPT 1991, Springer-Verlag, pp. 522–526 (1991).
[61] R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin: “Secure Distributed
Key Generation for Discrete-Log Based Cryptosystems”, EUROCRYPT
1999, Springer-Verlag, pp. 295–310 (1999).
[62] M. Pettit: “Eﬃcient Threshold-Optimal ECDSA”, CANS 2021, SpringerVerlag, pp. 116–135 (2021).

83

3.3 その他の高機能暗号技術
3.3.1 秘密分散
■秘密分散法の特徴

秘密分散法（Secret Sharing Scheme，SSS）は現在、様々な暗号技術の要素技術として用いられているが、提案された当時は秘密鍵などの安全な管理を目的としていた [1, 2]。通信の秘匿性を担保するために保持しなければな
らない秘密鍵のような情報を保管する際に、破損や紛失を避けるためにはいくつかのコピーを作る必要がある一方で、コピーを作ることは盗難や漏洩の危険性を増大させるといった相反する問題が存在する。そこで、秘密情報を「シェア」と呼ばれる n 個の分散情報に符号化し、そのうちの任意の k ≤ n 個のシェアを集めることで秘密が復元できるが、k − 1 個では秘密情報が情報理論的に一切漏洩しない方式を考える。このような方式は (k, n) しきい値法と呼ばれ、n − k 個以下の破損や紛失、k − 1 個以下の盗難や漏洩に対して安全となることから、上記の問題に対する一つの解決策となる。(k, n) しきい値法は、秘密情報へのアクセスを許される
シェア集合と、許されないシェア集合を指定可能な秘密分散法に拡張することができる。このような秘密分散法を、一般アクセス構造に対する秘密分散法と呼ぶ[3]。また、可検証秘密分散法（Veriﬁable SSS、[4]）などをはじめとして様々な機能拡張がなされている。
秘密分散法は、上記のような秘密情報の分散保管を目的として提案されたが、現在ではマルチパーティ計算（Multi-Party Computation，MPC）をはじめとした
様々な暗号プロトコルの要素技術として用いられている [5]。また、様々な媒体でも実現手法が知られており、視覚暗号 [6]、量子秘密分散法 [7, 8] などが提案されている。
■秘密分散法の歴史、実装例

秘密分散法は 1979 年に Shamir [9] と Blakley [2] によって独立に提案された。どちらの論文も (k, n) しきい値法の構成手法であるが、Shamir は多項式補間（Lagrange 補間）による方法を、Blakley は射影幾何に基づく方法を提案している。これらの手法は線形変換のランクを元にした構成法に一般化できる [10]。このような線形変換のランク関数と関連付ける研究は一般ア
クセス構造をもつ秘密分散法の構成法やシェアサイズの下界を求める際にも有用であり、ポリマトロイドの性質などと関連付けられて近年でも研究が進んでいる[11]。また、線形代数的なアプローチとして Monotone span program による構成法が挙げられる [12]。
文献 [10] では線形変換に基づく構成法に加えて、情報理論的な手法でシェアの84

サイズの下界が導出されており、秘密情報へのアクセスが許されないシェア集合
から 1 ビットも情報が漏れない完全秘匿性という性質を要求する場合、秘密情報 S
を確率変数としたときの S のシャノンエントロピー（直観的にはビット長）H(S)は i 番目のシェア Vi のシャノンエントロピー H(Vi ) に対して常に H(Vi ) ≥ H(S)が成り立つ。Shamir の手法は任意の i に対して H(Vi ) = H(S) が成り立つことが容易に分かるため、Shamir の構成法がシェアサイズの観点からは最良であることになる。これらの結果を受けて、完全秘匿性を弱める代わりに、シェアのサイズを
秘密情報のサイズより小さくするランプ型秘密分散法（ramp SSS）が提案された[13, 14]。ランプ型秘密分散法は Shamir の秘密分散法の一般化として構成できる。
計算量的秘密分散法は、Shamir 法と共通鍵暗号を組み合わせることで実現でき、
Shamir 法に比べて大幅にシェアサイズが削減できることが知られている [15]。近年では、計算量的 (n, n) しきい値法として All-Or-Nothing Transform（AONT）が知られている。Shin らによる AONT [16] は ZenmuTech 社によって実装され、実用化されている [17]。
■秘密分散法の代表的アルゴリズム

秘密分散法は極めて多くの方式が提案されているため、最も基本的で利用頻度が多いと思われる Shamir の多項式補間によるアルゴ
リズム [9]、およびその拡張方式について、ISO/IEC 標準 [18] に関連するいくつかの方式を説明する。以下では全ての計算を有限体 F の上で行うものとする。また、
自然数 n をシェアの総数として、参加者の集合を P = {p1 , p2 , . . . , pn } とし、参加
者 pi がシェア vi を持つとする。
Shamir 法とランプ型秘密分散法

はじめに最も基本的な Shamir の (k, n) しきい値法 [9]（Shamir 法）を説明する。秘密情報 ss ∈ F をもつディーラは、秘密情報と独立で、互いに独立かつ一様な乱数を k − 1 個選び、r1 , r2 , . . . , rk−1 ∈ F とする。このようにして選んだ値から、k − 1 次のランダム多項式 f (x) := s + r1 x1 + r2 x2 + · · · + rk−1 xk−1を作成し、参加者 Pi にシェアとして vi := f (i) を秘密通信路を介して配布する。復号にあたっては、任意の k 人の参加者 Pi1 , Pi2 , . . . , Pik が各自のシェア

vi1 , vi2 , . . . , vik をもって集まり、多項式 f (x) を復元することによって秘密情報
s = f (0) が復元される。多項式は Lagrange 補間によって求められるので、秘密Pk
Qk
情報は s = f (0) = α=1 viα β=1,β̸=α (−iβ )/(iα − iβ ) で求められる。
完全秘匿性を達成する秘密分散法では、シェアのサイズをこれ以上短くできな
いことが知られている [10]。ただし、秘密情報の一部を漏らすことを許せば、シェアのサイズを小さくすることができる。このように、情報漏洩とシェアのサイズのトレードオフを実現する秘密分散法がランプ型秘密分散法である [13, 14]。ラン85

プ型秘密分散法は秘密情報を s0 , s1 , . . . , sL−1 ∈ F として、Shamir 法の多項式 f (·)

Pk−1 11x+sii=L ri x を用いる事で構成できる。シェアが ki=0個以上ある場合、Shamir 法と同様に Lagrange 補間を用いて復号が可能であり、シェアが k − L 個以下なら s に関する情報が情報理論的に（完全）秘匿される。一方で、シェアを k − ℓ (1 ≤ ℓ ≤ L − 1) 個集めた場合は秘密情報は条件付エントロ
ピーの意味で (1 − ℓ/L)H(S) だけ情報が漏洩する。
ただし、完全秘匿性を満たす Shamir 法では秘密情報 S はどのような確率分布に従っても良いが、ランプ型秘密分散法は s0 , s1 , . . . , sL−1 ∈ F を独立かつ一様ラの代わりに g(x) :=PL−1

ンダムに選ぶ必要があることに注意する。また、ランプ型秘密分散における情報
漏洩は、秘密情報が存在しうる空間のサイズが FL ではなく F となることを表し、秘密情報の探索空間のサイズは同じでも、秘密情報の一部が一意に定まる場合と一意に定まらない場合がある。秘密情報のどのシンボルも一意に定まらないラン
プ型秘密分散法は強いランプ型秘密分散（strong ramp SSS）と呼ばれるが [14]、上に示した Shamir 法のランプ型への拡張は必ずしも強いランプ型秘密分散法になるとは限らないことが知られている [19]。
一般アクセス構造への拡張と複製型秘密分散法

しきい値型秘密分散法を用いると、一般アクセス構造に対する秘密分散法を構成することもできる。まず、参加者の集合を P = {p1 , p2 , . . . , pn } に対する一般アクセス構造について簡単に説明する。アクセス構造とは参加者の集合 X ⊆ P に秘密
情報 s ∈ F へのアクセス権を与えるかどうかを決定するものであり、秘密情報へのアクセス権を有する有資格集合の族 ΓQ ⊆ 2P とアクセス権のない禁止集合の族

ΓF ⊆ 2P からなる。ΓQ ∩ ΓF = ∅ が要請される一方で、ΓQ ∪ ΓF = 2P である必要はない。また、アクセス構造が自然に意味をもつために、任意の A ∈ ΓQ および任意の A′ ⊇ A に対して A′ ∈ ΓQ であること、および、任意の A ∈ ΓF および任意の A′ ⊆ A に対して A′ ∈ ΓF であることが必要となる。この性質を単調性と呼ぶ。
単調性をもつ任意のアクセス構造に対する秘密分散法は [3] で初めて提案されたが、ここでは [20] による、加法的秘密分散法を用いた一般アクセス構造に対する秘密分散法を説明する。
加法的秘密分散法とは、有限体における秘密鍵の加算と減算で暗号化と復号をおこなう、いわゆる使い捨て暗号 [21] の拡張であり、秘密情報 s ∈ F に対して (m, m) しきい値法を実現する方法である。具体的には、独立で一様な乱数

r1 , r2 , . . . , rm−1 ∈ F を用意し、i = 1, 2, . . . , m − 1 に対するシェアを vi = ri とす
Pm−1
る。そして、m 番目のシェアは vm = s − i=1 ri により計算し、m 個のシェア
Pmとする方法である。また、秘密情報 s は m 個のシェアを全て集め、s =i=1 vi86

により計算できる。この加法的秘密分散法を用いた一般アクセス構造に対する秘密分散法 [20] は、任意の A ∈ ΓA に対して、s を秘密情報とした加法的秘密分散法（(|A|, |A|) しきい値法）を独立に実現し、それぞれの加法的秘密分散法で pi に割り当てられるシェアをまとめて vi と考えることで実現できる。
なお、[3] で提案された方式は単一の (m, m) しきい値法のシェアを複製型秘密分散法を用いて、適切に配布することで一般アクセス構造を実現している。第 3.3.2
章「MPC - 秘密分散ベース」の項で紹介する「参加者が 3 人の複製秘密分散法に基づく方法」で用いる秘密分散法はこれの特殊ケースであり、加法型の (3, 3) しきい値法に対して複製型秘密分散法を適用して構成された (2, 3) しきい値の秘密分散法である。

3.3.2 マルチパーティ計算–秘密分散ベース–
秘密分散ベースのマルチパーティ計算（Multi-Party Computation，MPC）は、
第 3.3.3 章に記載する Garbled Circuit ベースのマルチパーティ計算と異なり、乗算回数などに応じた通信回数が必要となる。一方で、Garbled Circuit ベースのMPC において支配的であった、共通鍵暗号による真理値表の暗号文の送受信を必要としない分、通信量の面では秘密ベース分散ベースの MPC の方が小さくなる。
この特徴から、秘密分散ベースの MPC は Garbled Circuit に基づく方法と比較して、通信量を抑えたい状況の処理に適していると考えられている。秘密分散ベースの MPC と Garbled Circuit ベースの MPC とを組み合わせて用いることもあり、特に 3 者以上の多人数の MPC において、定数回の通信による方式を実現する
ときなどに利用される [22, 23]。
■秘密分散ベースのマルチパーティ計算の歴史

秘密分散ベースのマルチパーティ計算の草分けとして、Goldreich らによる GMW 方式 [24] や Ben-Or らによる BGW
方式 [25] が知られている。GMW 方式は、加法的秘密分散法に基づく MPC プロ
トコルである。秘密情報を「シェア」と呼ばれる分散情報に分割して符号化し、シェアから秘密情報を復元することなく、秘密情報どうしの加算・乗算の計算を実現する。本章で紹介する MPC は秘密分散ベースであるため、このシェアとは、第 3.3.1 章に記載したシェアと同じものであり、元となるデータを分割したものとなる。この方式では、紛失通信と呼ばれる暗号プロトコルを利用して乗算を実現している。BGW 方式は、Shamir の秘密分散法 [1] に基づく MPC プロトコルであり、GMW 方式と同様に秘密情報のシェアを復元することなく、秘密情報どうしの加算・乗算の計算を実現する。この方式では、ローカルでの計算による乱数の偏り、多項式の次数増加を回避するため、計算結果を再分散することによって再87

ランダム化・次数の削減を行って乗算を実現している。

GMW 方式と BGW 方式やその後に提案された多くの具体的な MPC プロトコ
ルは、共通する基本的な枠組みの中で構築されている。それは、線形秘密分散法と総称される方式群に含まれる秘密分散法をベースとし、線形秘密分散法の性質を利用したローカル計算のみからなる加算プロトコルを持ち、他の参加者との通信を必要とする乗算プロトコルを備える、というものである。そのため、複雑なデータ処理を MPC で実行する際は、当該処理を論理回路/算術回路として見なした場合の AND/乗算の回数分の通信が発生し、これが処理時間全体の多くの部分を占めることになる。従って、この点に関する改善が処理全体の高速化に寄与すると考えられ、さまざまな改良がなされている。アルゴリズムの改良や実装の洗練化により、近年は実用的な処理性能が得られており、たとえば、NEC などが7,000,000,000 ゲート/秒を達成 [26] し、また、産総研などは、データベース処理等における重要な構成要素となる秘匿状態でのシャッフルを加算・乗算のレベルまで分解せずに効率的に実現する手法を提案し、当該処理について従来の 100 倍程度の高速化に成功している [27]。
■代表的な方式 1: 参加者が 3 人の複製秘密分散法に基づく方法

効率的な方式の代表例として、参加者が 3 人の場合に向けて設計された、Araki らの方法 [26] を単純化した MPC プロトコル [28] を紹介する。以下では、各値はある整数 q を法とする剰余環の元とする。[28] の方式は、以下のような 3 つのうち任意の 2 つのシェアから復元可能な複製秘密分散法に基づいている。秘密情報 x の秘密分散は、x = x1 + x2 + x3 を満たす 3 つの乱数 x1 ，x2 ，x3 に加法的秘密分散し、それらのうち 2 つずつの対 (x2 , x3 )、(x3 , x1 )、(x1 , x2 ) をそれぞれ参加者 P1 ,P2 , P3 のシェアとすることにより実現される。復元の際は、いずれか 2 つのシェ
アを集め、x1 + x2 + x3 を計算すればよい。
加算のプロトコルは、各参加者が自身の持つ 2 つのシェアを加算することで実現される。2 つの秘密情報 x，y が秘密分散されているとき、z := x + y の秘密分散を計算する加算のプロトコルを以下に示す。各参加者 Pi (i ∈ {1, 2, 3})
は zi+1 := xi+1 + yi+1 と zi+2 := xi+2 + yi+2 を計算し、(zi+1 , zi+2 ) を z を秘密分散した Pi のシェアとする。ただし、添字の 4 は 1 と読み替えるものとし、以下も同様とする。正当性は z1 + z2 + z3 = (x1 + y1 ) + (x2 + y2 ) + (x3 + y3 ) =(x1 + x2 + x3 ) + (y1 + y2 + y3 ) = x + y = z により確認できる。このプロトコル
は一切の通信を必要とせず、各参加者のローカルの計算で完結している。
乗算のプロトコルを以下に示す。入力は加算の場合と同じとし、w := xy の秘密分散を計算するものとする。
88

1. 参加者間で 0 を加法的秘密分散し、各参加者 Pi (i ∈ {1, 2, 3}) は ai を得る。
ここで、a1 ，a2 ，a3 は a1 + a2 + a3 = 0 を満たす乱数である。
2. 各参加者 Pi (i ∈ {1, 2, 3}) は wi+2 := xi+1 yi+1 + xi+1 yi+2 + xi+2 yi+1 + ai を計算し、Pi+1 に送る。
3. (wi+2 , wi+3 ) を w の秘密分散の Pi (i ∈ {1, 2, 3}) のシェアとする。
P
基本的なアイデアは、xy を分解した i,j∈{1,2,3} xi yj の 9 個の項のうち、参加者
Pi が自身の持つシェアから計算可能な xi+1 yi+1 + xi+1 yi+2 + xi+2 yi+1 を計算結果 w の加法的秘密分散のシェアとするものである。この値は入力 x, y に関する情報を含んでいるため、ステップ 2 で隣の参加者に送る前に乱数 ai を加算する
ことによって見かけ上ランダムな値にしている。ステップ 1 の 0 の加法的秘密
分散の作成は、各参加者が乱数を作成して次の参加者へ送り、自身の作った乱数から受け取った乱数を引いた値をシェアとすることで実現できる。正当性は、

w1 + w2 + w3 = (x3 y3 + x3 y1 + x1 y3 + a1 ) + (x1 y1 + x1 y2 + x2 y1 + a2 ) + (x2 y2 +x2 y3 + x3 y2 + a3 ) = (x1 + x2 + x3 )(y1 + y2 + y3 ) + (a1 + a2 + a3 ) = xy = w により確認できる。このプロトコルは通信を伴い、1 回の実行につき各参加者は 2 つの値を送信する。さらに、pseudorandom secret sharing [29] と呼ばれる方法を使うと、送信する乱数の一部を隣接する参加者間で共有していたシードから生成した
擬似乱数で代用でき、各参加者が送信する値を 1 つにまで減らすことができる。
本方式は、NTT の秘密計算システム算師 [30] などに実装され実用化されている [31]。
■代表的な方式 2: Beaver triple を使う乗算プロトコル

参加者が 3 人の複製秘密分散法に基づく方法で述べた MPC プロトコルとは異なる特性を持つ代表的な方式として、Beaver 乗算と呼ぶ乗算プロトコルを紹介する。
この方式は Beaver triple [32] と呼ばれる互いに関連した乱数の組を利用するものであり、任意の線形秘密分散法の上で構築することができる。また、事前計算を行うことにより、入力を受け取った後に必要な通信を少量にすることができるという特徴を持つ。

Beaver 乗算の基本的なアイデアは以下の通りである。乗算の実行に先立って、
2 つの乱数とそれらの積をそれぞれ秘密分散したシェアの 3 つ組（これを Beaver
triple と呼ぶ）を用意しておく。乗算の実行時には、まず、入力の 2 つの値にBeaver triple の 2 つの乱数をそれぞれ減算し、入力値と乱数の差分値のシェアを各参加者と通信して共有する。そして、各参加者は共有した値から差分値を復元する。差分値は乱数によりマスクされているので、復元しても入力値が参加者に89

知られることはなく安全である。そして、これらの復元した差分値どうしの積を計算する。この計算は公開値どうしの計算であるから、ローカルで計算可能である。この公開値どうしの積と元々欲しかった入力の積との差は、Beaver triple の各値の（マスクして復元した値を定数として使った）線型結合として表現でき、線形秘密分散法の性質によりローカルで計算できる。すなわち、Beaver triple を消費することで、入力をマスクした値の復元以外はローカル計算だけで乗算が実現される。

Beaver 乗算のプロトコルを説明する。以下では、ある値 x が秘密分散された状態を [x] と書くこととし、秘密分散された x と y の加減算をそれぞれ [x] + [y]と [x] − [y]、秘密分散された x の定数 c による定数倍を c[x] と書くことにする。
Beaver triple は、a と b を乱数、c := ab として、([a], [b], [c]) とする。乗算プロト
コルの入力は [x] と [y] とし、w := xy を満たす [w] を出力とする。プロトコルは
以下の通りである。

1. 各参加者は自身の持つシェアから [α] := [x] − [a] と [β] := [y] − [b] を計算する。

2. 各参加者は自身の [α] および [β] のシェアを他参加者に共有し、α と β を復元する。

3. 各参加者は自身の持つシェアから [w] := [c] + α[b] + β[a] + αβ を計算して出力する。
正当性は、w = c + αb + βa + αβ = ab + (x − a)b + (y − b)a + (x − a)(y − b) =ab + bx − ab + ay − ab + xy − bx − ay + ab = xy により確認できる。
Beaver triple は乗算プロトコルの入力とは無関係であるため、入力を受け取る
前に計算して蓄えておくことができる。これにより、実際の入力を受け取った後の処理時間を小さくすることができる。Beaver triple の事前計算の方法はいくつも提案されており、例えば MPC プロトコルにより計算する方法 [33] や、信頼する第三者が作成する方法 [34] がある。

Beaver triple を使う方式は ZenmuTech 社と産総研の秘密計算ソフトウェア
QueryAhead [35] などに実装され実用化されている [36]。
3.3.3 マルチパーティ計算–Garbled Circuit ベース–
Garbled Circuit（GC）は、1986 年に Yao [37] により提案された 2 者間のマルチパーティ計算（Multi-Party Computation，MPC）のためのフレームワークである。この方式では、2 者が協調計算したい関数を論理回路と■Garbled Circuit の概要

90

して表現した後、その回路の各ゲートに対応する真理値表に対し、乱数を鍵として暗号化することで、Garbled Truth Table（GTT）と呼ばれる「暗号化された真理値表」に相当する暗号文リストを作成する。この GTT に含まれる暗号文のうち、2 者の入力に対応する暗号文のみが正しく復号されるように乱数の交換を行うことで、関数値のみが復元される仕組みを実現する。

GC に基づく MPC は、第 3.3.2 章に記載の秘密分散ベースの MPC とは異なり、乗算回数などに応じた膨大な通信回数を必要とはしないが、上記の通り、処理全
体をすべての入力に対する真理値表とみなしたうえで、真理値表全体の暗号文を送受信しなければならないため、通信量が非常に大きくなることが知られている。
これらの特徴から、GC に基づく MPC は秘密分散ベースの MPC と比較すると遅延の大きいネットワーク環境における小規模な処理に適していると考えられる。

GC と秘密分散ベースの MPC を組み合わせて用いることもあり、特に 3 者以上の多人数の MPC において、定数回の通信による方式を実現するときなどに利用される [22, 23]。
また、GC の概念は 1980 年代から知られていたものの、厳密な安全性の取り扱いについては長期にわたり十分な整備がなされていなかったが、Bellare らなどの成果 [38] により、理論的に厳密な取り扱いが可能となっている。
■代表的な方式

ここでは、GC に基づく 2 者計算の代表的な構成方法をいくつか紹介する。
以下、プロトコルに参加する 2 人の参加者を P1 と P2 とし、P1 および P2 が持
つ入力をそれぞれ x ∈ {0, 1}n , y ∈ {0, 1}n として、お互いの入力を秘匿したまま関数 F(x, y) を計算することを目標とする。関数 F の論理回路による表現を C と表記する。また、κ をセキュリティパラメータとし、H : {0, 1}∗ ← {0, 1}κ を暗号
学的ハッシュ関数とする。
方式 1: Yao の Garbled Circuit [37]

代表的な方式の一つとして、Yao [37] による GC の構成法を紹介する。
以下の手順で回路 C に対する GC を構成することができる。
回路 C の各ワイヤ wi および b ∈ {0, 1} について、ランダムにラベb
ル wi = (kib ∈ {0, 1}κ , pbi ∈ {0, 1}) を生成する。ただし、pbi = 1 − pi1−b とする。wi0 および wi1 は、このワイヤにおける値 0 と 1 に対応するラベルでラベル生成:ある。

GTT の生成: C に含まれる各論理ゲート Gi について、入力ワイヤに近いワイヤ

91

から順に以下の処理を行い、GTT を作成する。

 Gi を関数 gi : wc = gi (wa , wb ) のゲートとする。入力 wa に対応する
ラベルを wa0 = (ka0 , p0a ), wa1 = (ka1 , p1a )、wb に対応するラベルを wb0 =(kb0 , p0b ), wb1 = (kb1 , p1b )、出力 wc に対応するラベルが wc0 = (kc0 , p0c ), wc1 =(kc1 , p1c ) とする。
 Gi への入力 va , vb ∈ {0, 1} の考えられる組み合わせ 4 通り（2×2）それg (v ,v )ぞれについて、eva ,vb = H(kava ||kbvb ||i) ⊕ wc i a b を計算する。
 前ステップで計算した {eva ,vb }va ,vb ∈{0,1} を、(pvaa , pvb b ) の順でソートする。
出力復号用テーブルの作成: 各ゲートの出力ワイヤ wi （ラベル wi0 = (ki0 , p0i ) お
よび wi1 = (ki1 , p1i ) に対応）およびワイヤが取りうる値 v ∈ {0, 1} について、
ev = H(kiv ||“out′′ ||j) ⊕ v を計算する。ただし、この計算においては H の最下位ビット（LSB）のみを用いる。得られた出力 {ev } を pvi の順でソートする。

GC に基づく MPC においては、上記の手順を P1 が行う。この計算を行う参加者のことを Garbler とも呼ぶ。
上記の手順により生成した出力復号用テーブルを含む GC を、P1 から P2 へ送信する。同時に、各入力ワイヤについて、P1 自身の入力に対応するラベルも P2 へ送信する。

GC の “復号”には、P2 の入力に対応するラベルを P1 から P2 の入力を知ることなく P2 へ送信する必要がある。このような機能は、紛失通信 （Oblivious
Transfer，OT） [39] によって実現することができる。各 P2 の入力ワイヤ wb について、P1 は 0, 1 それぞれの入力に対するラベル wb0 , wb1 を入力し、P2 は選択ビット c を入力することで、P1 から P2 へ wbc のみを送信することができる。
以降は P2 が受け取った入力を基に GC の評価を行う。この手順を行う参加者をEvaluator とも呼ぶ。各ゲートに対応する GTT T = (e0,0 , e0,1 , e1,0 , e1,1 ) および入力ラベル wa = (ka , pa ), wb = (kb , pb ) を用いて、P2 は wc = H(ka ||kb ||i) ⊕ epa ,pb を計算する。
すべてのゲートを評価し終えたら、最終的な出力を復号するために、第 2 キーに “out” を用いて、計算の平文結果となる最終出力を得ることができる。P2 は得られた出力を P1 に返却することで、両者が結果を得ることができる。
方式 2: Half-Gates [40]

GC においては、GTT のサイズを削減するためにいくつかのテクニックが知られている。Yao の方式では 2 入力 1 出力のゲート 1 つあたりに 4 つの暗号文を必要92としたが、XOR ゲートの暗号文数を 0 に削減する Free-XOR と呼ばれるテクニッ
ク [41] や、一般のゲートにおける暗号文数を 3 あるいは 2 へ削減する Garbled

Row Reduction（GRR）テクニック [42, 43] などが知られる。
これらのテクニックを組み合わせた方式で効率が良い方式の一つとして、Zahur
らによって提案された Half-gates [40] と呼ばれる方式を説明する。この方式では、

XOR ゲートの GTT を必要とせず、AND ゲートの GTT を暗号文 2 つで構成することが可能である。AND ゲートと XOR ゲートの組み合わせで、任意の回路を表現可能であることに注意する。

Half-gates のアイデアのポイントは、AND ゲートを 2 つの “half gate”の XORとして表現することである。このそれぞれの half gate は、入力の 1 つが参加者のいずれかに既知の AND ゲートであり、暗号文 2 つで GTT を構成することができる。この暗号文 2 つの GTT を GRR テクニックによって暗号文 1 つに圧縮し、2つの half gate を接続する XOR を Free-XOR テクニックによって削減することで暗号文 2 つによる AND ゲートの GC を達成している。
2 つの half gate はそれぞれ、“generator half gate” と “evaluator half gate” と呼ばれる。以下でそれぞれについて説明する。
・Generator half gate
入力ワイヤを a と b、出力ワイヤを c とする AND ゲートを考える。Generator

half gate は vc = va ∧ vb のような回路で、va が generator (P1 ) に対して何らかの形で既知であり、evaluator (P2 ) はいずれの入力も未知の回路である。このとき、
va = 0 であれば vc = 0 であり、va = 1 であれば vc = vb であることに注意する。
いま、ka0 , kb0 , kc0 をワイヤ a, b, c それぞれの入力 0 に対応するラベルとする。このとき、generator half gate の GTT は以下のように表される。
H(kb0 ) ⊕ kc0
H(kb1 ) ⊕ kc0 ⊕ va · R
ただし、kb1 = kb0 ⊕ R であり、R はランダムなグローバルオフセットである。

Free-XOR を用いる際はこのように、0 と 1 それぞれに対応する 2 つのラベルを(X, X ⊕ R) のように差分を固定した形で設定する。
Evaluator (P2 ) はこの half gate を評価するために、自身の入力 b に対応するラベル（kb0 あるいは kb1 ）を用いてそのハッシュ値を計算する。もしワイヤ b の値が0 の場合、evaluator は kb0 を持ち、H(kb0 ) を計算して kc0 を得ることができる。一方、もし b の値が 1 の場合は、kb1 = kb0 ⊕ R によって H(kb1 ) を計算して kc0 ⊕ va · Rを得ることができる。ちなみに、va = 0 のとき kc0 となり、va = 1 のとき kc0 ⊕ Rとなる。
93・Evaluator half gate

Evaluator half gate は、vc = va ∧ vb のような形で、va が evaluator (P2 ) にとって既知であり、generator (P1 ) はいずれの入力も未知の回路である。このとき、
evaluator は自分の知るワイヤ a の入力に応じて異なる振る舞いをすることができる。Evaluator half gate の GTT は以下のように実現される。
H(ka0 ) ⊕ kc0
H(ka1 ) ⊕ kc0 ⊕ kb0
ただし、generator half gate と同様、ka1 = ka0 ⊕ R であり、R はグローバルなオフ
セットである。ワイヤ a の値が 0 の場合、H(ka0 ) を計算し、kc0 を得ることができる。一方、a の値が 1 の場合は、kc0 ⊕ kb0 を得ることができる。最終的に、これをb に対応するラベルと XOR を取ることで、b の値が 0 の場合、すなわち evaluatorが kb0 を持っている場合は kc0 を、b の値が 1 の場合、すなわち、evaluator が kb1 を持っている場合は kc1 = kc0 ⊕ R を得ることができる。
・Generator half gate/Evaluator half gate の結合
上記の 2 種類の half gate を用いて vc = va ∧ vb のゲートを GC で評価するた
めに、generator は GC の生成時にランダムなビット r を生成し、これを用いてAND ゲートを以下のように変形する。
vc = va ∧ (r + r + b)
= (va ∧ r) ⊕ (va ∧ (r ⊕ vb ))(va ∧ r) は generator half gate を用いて garbling することができ、(va ∧ (r ⊕ vb ))は point-and-permute [22] を用いると r ⊕ vb を evaluator に伝えることができる
ため、evaluator half gate を用いて garbling することができる。XOR ゲートについては上記の通り、Free-XOR テクニックを用いると GTT が不要であるため、GRR で圧縮した generator half gate の GTT と evaluator half gate の GTT の組が、所望の AND ゲート va ∧ vb に対する GTT となる。
3.3.4 ゼロ知識証明■ゼロ知識証明の特徴

ゼロ知識証明とは、ある命題 X に対して、証明者と検証者の間で情報をやりとりし、証明者が検証者に命題 X が正しいことを確信させ、かつ命題が正しいこと以外の情報を検証者に与えないプロトコルである。次に述べる
完全性、健全性、ゼロ知識性の性質をもつ。
完全性：

証明者の命題が真ならば、検証者は真であることが必ずわかること。
94

健全性：

証明者の命題が偽ならば、検証者はかなり高い確率で、偽であることを見抜けること。
ゼロ知識性：

あらゆる場合で検証者が証明者から何らかの知識を得ようとしても、証明者の命題が真であること以上の知識は得られないこと。
さらに、ゼロ知識証明の中でも zk-SNARKs 方式（Zero-Knowledge Succinct

Non-Interactive Argument of Knowledge）は、命題が正しいことの証拠の保有を証明するもので、名前に由来する以下の特徴を持つ。
簡潔 Succinct： 知識証明のサイズが命題のサイズに依存せず一定で、十分に短い
非対話 N onInteractive：

検証者は証明者からの一度の知識証明の送付で検証可能
アーギュメント Argument：

検証者は計算能力に限りある（多項式時間計算力）

証明者からは守られる
知識 Knowledge： 証明者は証拠なしでは知識証明の生成は不可能
ゼロ知識証明で扱える命題は、その証拠を使って多項式時間アルゴリズムで真偽判定できる「クラス NP 問題」であり、関数の解や充足可能問題なども含み幅広い。
■ゼロ知識証明の歴史

ゼロ知識証明の歴史は古く、1985 年に Goldwasser らにより、証明者と検証者間で対話を繰り返し、知識を証明するプロトコルとして定式化された [44]。この対話型の改良として、信頼できる第三者機関が、共通参照情報（Common Reference String, CRS ）を事前に生成し、配布することで、非対話型が達成される [45]。また健全性について、離散対数問題をベースとしたシュノア
プロトコル [46] は、証明者の計算能力を限定することで健全性を保証する方式で、計算困難な数学的問題を根拠とする方式の原型といえる。
クラス NP 問題に、一方向性関数の存在を仮定すると、非対話型ゼロ知識証
明が適用できることは保証されていたが、実用的な手法は 2013 年の Gennaro
らによる zk-SNARK である [47]。これを一般化した zk-SNARKs 方式の中でも Pinocchio [48] は、暗号資産の取引システム上で実用化されている。また

Pinocchio の効率化が Groth により定式されている [49]。さらに、zk-STARKs [50]と BulletProofs [51] は、証明サイズや計算量は大きくなるが、事前準備を必要としないことを特徴とする。

95

■代表的なゼロ知識証明方式

Pinocchio アルゴリズムの概要を説明する。はじめに、

命題「多項式 F の解の存在」をゼロ知識証明する場合を例に、全体の流れを示す。

1. F を加算と積算演算ゲートを持つ算術回路に変換する。
2. 具体的な手続きに従って、回路を 2 次算術プログラム（QAP ）で表現する。
ここで QAP は 3 つの多項式の集合 V, W, Y と目的多項式 t(x) で構成される。回路を満たす割り当て {ci } がある時、V, W, Y と {ci } から多項式 p(x)が定まり、後述の QAP 定理 [47] より「F の解の存在」と「h(x)t(x) = p(x)を満たす多項式 h(x) の存在」が同値になる。
3. 証明者は、証拠から h(x) を計算し、h(x) を暗号化した知識証明 π を作り、検証者に渡す。

4. 検証者は、知識証明 π から、h(x)t(x) = p(x) の成立を、Pairing 写像を用いて検証する。
以上のプロセスを、非対話型にするために CRS と呼ばれる乱数の共有が必要である。第 2 項にある QAP 定理を以下に示す。

QAP 定理 [47]: F を n 個の元を入力し n′ 個の元を出力する関数とし、N = n+n′とする 。こ の 時、3 つの 多 項式 集合 V = {vk (x)}, W = {wk (x)}, Y ={yk (x)}k=1,…,m と目的多項式 t(x) が存在し (これを F の QAP と呼ぶ）、
次が成立する。入出力値 (c1 , …, cN ) が F から得られる回路の正しい割り当て（値）とすると、係数 (cN +1 , …, cm ) が存在し、t(x) が p(x) を割り切る。
この時、係数 (cN +1 , …, cm ) を証拠と呼ぶ。ここで p(x) と t(x) は以下の式となる。

p(x) = (mX
k=1t(x) =

ck vk (x))(

YmX

ck wk (x)) −

k=1

m
X

ck yk (x),k=1(x − rg )g:積算演算ゲート

具体例として、F(C1 , C2 , C3 , C4 ) = (C1 × C2 ) × (C3 + C4 ) ＝ C6 を当てはめると、F の QAP は目的多項式 t(x) = (x − r5 )(x − r6 ) と V = {vk (x)}, W ={wk (x)}, Y = {yk (x)}k=1,…,6 で構成される。V の初項は v1 (x) = (x − r5 )(x − r6 +1)/(r6 −r5 ) であり、i ≥ 2 の vi (x) と W ,Y は順次計算できるが、残りの項の記載は省略する。そして、F を満たす解 x = (c1 , c2 , c3 , c4 , c6 ) と途中ゲートの入出力制約をみたす c5 を使用して、p(x) = {c1 v1 (x)+c2 v2 (x)+c3 v3 (x)}{c4 w4 (x)+c5 w5 (x)}−{c5 y5 (x) + c6 y6 (x)} を計算する。p(x) を展開すると、「(c1 × c2 ) × (c3 + c4 ) = c6
96

の成立」と「t(x) が p(x) を割り切る」が同値であることが分かる。
定式化のため写像を 2 つ用意する。1 つ目は巡回群 G とその生成元 g による、暗号化写像 E(s) := g s であり、単射かつ E(s + t) = E(s)E(t) を満たす。値 g s とg からは s が計算困難な離散対数困難性を持つ。2 つ目は G 上の Pairing 写像 eで、双線形性 e(g a , g b ) = e(g, g)ab を持つ。Pinocchio は（CRSGen,Proof, Verify）の 3 つのアルゴリズムからなる。
CRSGen(1λ , F): 信頼できる第三者により CRS を生成するアルゴリズム。
証明したい命題 F を、算術回路変換を通して QAP 表現する。QAP がサイ
ズ m、次数 d、V = {vk (x)}, W = {wk (x)}, Y = {yk (x)}k=1,…,m , t(x) で構成される時、[N ] = {1, …, N }, Imid = {N, …, m}, [d] = {1, …, d} と置く。
s, α, βv , βw , βy , γ をランダムに選び、CRS = (EK, V K) を生成する。証明者に EK を、検証者に V K を送付する。
EK = {{E(si ), E(αsi )}i∈[d] , {E(vk (s)), E(αvk (s)), E(βv vk (s))}k∈Imid ,{E(wk (s)), E(yk (s)), E(αwk (s)), E(αyk (s), E(βw wk (s)),
E(βy yk (s))}k∈[N ] }V K = {E(1), E(α), E(γ), E(βv γ), E(βw γ), E(βy γ), E(t(s)), E(vk (s)k∈[N ] }Proof(EK, u): 証明者により知識証明 π を生成するアルゴリズム。
証明者は、入力 u から y = F(u) を計算し、回路が満たす {ck }k∈[m] を得る。
これから

p(x) = (mX

ck vk (x))(

k=1

m
X

ck wk (x)) −mX

ck yk (x)

k=1

k=1

h(x) = p(x)/t(x)と多項式 h(x) を得る。次に、この h(x) の暗号化を行う。h(x) の係数 hiからE(h(s)) =Y

E(si )hii∈[d]を 計 算 す る 。さ ら に 、秘 匿 し た い 入 出 力 値 と 証 拠 {ck }k∈Imid も 使 い 、E(vmid (s)) =Qk∈Imid E(vk (s))

ck

や E(w(s)) なども同様の計算を行い、合わせて、知識証明 π を構成する。

π = {E(h(s)), E(vmid (s)), E(w(s)), E(y(s)), E(αh(s)),
E(αvmid (s)), E(αw(s)), E(αy(s))E(βv v(s))E(βw w(s))E(βy y(s))}
97π に、y と u の中で秘匿しない入出力値に対応する {ck } を加えて、検証者に送る。
しかし、上記の定式化では、π のゼロ知識性が満たされていない。そのた′め、一様乱数の組と区別できないように、vmid(x) = vmid (x) + δt(x) と、暗号化前の各多項式に乱数 δ を加えてゼロ知識性を達成する。これに合わせて

p(x) と h(x) も変更される。
Verify(V K, u, y, π):
検証者により証明者の知識 π を検証するアルゴリズム。
次の 2 種類のチェックのすべてが通った時に、検証成立となる。
?
1. 等式 p(s) = h(s)t(s) の成立チェック
V K と 回 路 の 秘 匿 し な い 入 出 力 値 {ck } を 使 い 、E(vi/o (s)) =Q
ckk∈[N ] E(vk (s)) を計算する。そして、?

e(E(vi/o (s))E(vmid (s)), E(w(s))/e(E(y(s), E(1)) = e(E(h(s)), E(t(s))の両辺を比較し一致する時、e の双線形性より (vi/o (s) + vmid (s))w(s) −y(s)) = h(s)t(s) が成立する。
2. 線形結合チェック?

e(E(αh(s)), E(1)) = e(E(h(s)), E(α)),?

e(E(βv v(s)), E(γ)) = e(E(v(s)), E(βv γ))を含む、α に関する 8 ペアと β に関する 3 ペアの Pairing 写像を用いたチェックを行う。
■ゼロ知識証明の安全性など

アルゴリズムを支える根拠と安全性を述べる。Proof の知識証明 π は回路のサイズに関わらず巡回群 G の 8 つの元で構成され、サイズは一定となる。さらに、多項式自身でなく、ランダム s での評価値 h(s) が知識証明に使用されている。これは Schwartz-Zipple 補題により、異なる多項式をランダムな点で評価すると高い確率で異なる値となることが示されており、このようなランダム点での評価値を用いることができる。さらに、多項式の秘匿評価手法により CRS の E(si ) を使うことで s 自身を知らずとも E(h(s)) が計算可能である。

Verify において、線形結合チェックが加えられている。これは、証明者は h(x) や
vmid (x) を、証拠（の係数）を持たずとも、等式が成立する任意の多項式として作ることができる。この不正な攻撃に対応するために、検証者は h(s) が {si }i∈[d]の線形結合から作られていることの確認が必要である。Knowledge of Coeﬃcient（KC）に基づくと、e(E(αh(s)), E(1)) = e(E(h(s)), E(α)) が成立する時に、この98線形結合性が確認できる。そして、検証は一度の知識証明の送付で達成しており、非対話型である。

3.3.5 Oblivious Random Access Machine（ORAM）■ORAM の特徴

外部サーバにデータを預ける際、暗号化していればデータの内容は漏洩しないが、あるデータへのアクセスの偏りが発生した場合、サーバはそのア
クセスの偏りから該当データの情報を推測できてしまう可能性がある。ORAM では、暗号化データに対して読み込み書き込みを行うたびに、格納位置をシャッフ
ルするとともに再暗号化することで各アクセス間の関係を秘匿し、サーバに対してアクセスパターンを秘匿できる。クライアントは格納位置に関する情報を保持することによって、目的の暗号化データの格納位置を知ることができる。
同様にサーバに対するプライバシ保護を目的とする高機能暗号技術である第3.3.6 章に記載の Private Information Retrieval（PIR）と第 3.3.7 章に記載の検索可能暗号との違いは以下の通りである。

 サーバへのクエリ内容：検索可能暗号では格納したデータがあるキーワードを含んでいるかどうかをクエリするのに対し、ORAM と PIR ではクライア
ントがアクセスしたいデータそのものについてクエリする。

 格納したデータの暗号文：検索可能暗号と PIR では基本的にサーバに格納されたデータやその暗号文は（データの更新処理などが行われない限り）ク
エリによって変わることが無いのに対し、ORAM では毎回のクエリごとにデータの更新と暗号文の再暗号化、格納位置のシャッフルが行われる。

 秘匿できる情報：検索可能暗号では検索に該当するデータの頻度などの情報は秘匿しないのに対し、ORAM と PIR では頻度を含めたアクセスパターンを秘匿する。

 クライアントとサーバの処理：検索可能暗号と PIR ではクエリに応じてサーバが暗号化データベースに対して検索処理を行うのに対し、ORAM では暗号化データベースの一部をサーバから受け取りクライアントが検索処理（およびにシャッフルと再暗号化）を行う。
このように、検索可能暗号はアクセスパターンの秘匿までは必要のない状況、PIR
は通信量とサーバの計算量が増えてもクライアントの計算量を抑えたい状況、

ORAM はある程度クライアントは計算量を要するが通信量を抑えたい状況で使い分けることが望ましい。

99

ORAM の概念は、Goldreich [52] によって初めて提案された。元々はソフトウェア保護の文脈で CPU によるメモリアクセスパターンの秘匿を目的として考案されたが、その後、CPU をクライアント、メモリをサー■ORAM の歴史と方式の比較

バに置き換えることにより、暗号化データベースのアクセスパターン秘匿への適用が主な応用先となった。Goldreich と Ostrovsky による初期の方式 [52, 53, 54]
では、データブロック数 N に対してアクセスごとの償却通信計算量は O(log4 N )であったが、最悪通信計算量は Ω(log N ) であった。
その後、Shi ら [55] や Kushilevitz ら [56] によって、木構造を用いてデータを管理することによって最悪通信計算量がそれぞれ O(log3 N/ log log N ) と O(log4 N )となる方式が提案された。通信計算量の観点で効率の良い ORAM 方式として、

Stefanov ら [57] による Path ORAM が知られており、データブロック数 N に対して通信計算量は O(log3 N ) でよい。ただし、Path ORAM では、クライアント
が position map と呼ばれるテーブルとスタッシュと呼ばれるローカルなメモリに情報を格納するため、クライアントの記憶容量は N に依存したサイズが必要である。
近年はクライアントの記憶容量や通信計算量を漸近的に減らす研究が進ん で い る 。Patel ら [58] は O(log N ) ビ ッ ト の ク ラ イ ア ン ト 記 憶 容 量 か つO(log2 N log log N ) の償却通信計算量の方式を提案した。Asharov ら [59] はこれを改良し、O(log2 N ) の償却通信計算量の方式を提案した。さらに、Asharov
ら [60] により O(log N ) ビットのクライアント記憶容量かつ O(log2 N ) の最悪通信計算量の方式が提案された。この方式は漸近的には効率的であるものの、オーダー表記に隠れた定数倍が大きいため実用は現実的ではない。

ORAM の拡張として、サーバを複数台に分けてデータを格納することによって、単一サーバの ORAM より効率が良い分散 ORAM [61] が知られている。また、通常の ORAM ではクライアントは単一だが、複数のクライアントを含むことができる並行 ORAM [62] も知られている。
■代表的な方式のアルゴリズム

具体的な ORAM の実現方法として、木構造を用いた

Path ORAM [57] を紹介する。
 サーバのセットアップ： 高さ L の二分木を生成する。各ノードにそれぞれZ 個のブロックを割り当て、暗号化データを格納する。もしあるノードに入るブロックが Z 個未満になる場合は、真のブロックとは識別できないダミーのブロックを格納することで常に Z 個のブロックで満たされるようにする。
 クライアントのセットアップ： それぞれのブロックと葉ノードを紐づけた
100position map と呼ばれるテーブルを生成する。position map は、ブロックが根ノードから紐づけられた葉ノードの経路上のいずれかにあることを保証
し、あるブロック a が左から x 番目の葉ノードと紐づけられているならば、

a は根ノードから x 番目の葉ノードへの経路上のいずれかにあることになる。初期状態においてブロックは全て空の状態で、各ブロックはそれぞれランダムに選ばれた葉ノードと紐付けられて、その葉ノードの経路上に配置される。また、いくつかのブロックを保存できるスタッシュと呼ばれるメモリを用意する。

 アクセス：
1. 処理 op ∈ {read, write}、ブロック a、データ d に対して、クライアント
は position map からブロック a に対応した葉ノード x を選択し、x をサーバに送信する。その後 position map の a に対応した葉ノードをラン
ダムな葉ノード x′ に上書きする。
2. サーバは受け取った x から根ノードへの経路上にあるブロックを全てク
ライアントに送る。

3. クライアントはサーバから受け取ったブロックをスタッシュに保存し、スタッシュにある暗号化データを全て復号する。a を用い参照したい
データを探し出し、op = write ならば内容を d に更新する。
4. クライアントは全てのデータを再暗号化し、position map と x の最小共通祖先ノードに格納する。参照した a は、x と x′ の最小共通祖先ノードに格納される。この時ノードに空きが出来た場合、ダミーのブロックを格納する。入るべきノードがすべて埋まってしまいスタッシュに残ったブロックは、そのままスタッシュに一時保存する。

3.3.6 Private Information Retrieval（PIR）■PIR の特徴および他の関連技術との差異

クライアントがサーバ上のデータを検索する際、クライアントは検索のためのクエリをサーバに送信し、そのレスポンスとして、クライアントはサーバから検索結果を受け取る。これら一連の作業において検索履歴や検索結果、サーバに保存されたデータ自体の秘匿性をどのように考えるかによって様々な方式が提案されている。秘匿情報検索（Private Information

Retrieval，PIR）は、サーバ上のデータは、暗号化されず平文のまま保存されている状況で、クライアントがどのデータにアクセスしたか、サーバに秘匿することを目的とする。サーバに預けたデータをクエリする際に、そのアクセス情報を秘101

匿する暗号技術としては、PIR の他に第 3.3.5 章に記載された Oblivious Random

Access Machine（ORAM）や第 3.3.7 章に記載された検索可能暗号がある。これ
らの暗号技術と PIR の具体的な相違点は以下の通りである。
 サーバが保持する情報：PIR ではデータを暗号化しない状態で保持する一方、ORAM や検索可能暗号ではデータを暗号化した状態で保持する。言い換えれば、PIR では元々サーバが管理するデータを、ORAM 及び検索可能
暗号ではクライアントが管理するデータを扱うことを想定している。

 格納した暗号化データの取り扱い： PIR では基本的にサーバに格納されたデータやその暗号文はクエリによって変わることが無いのに対し、ORAM
や検索可能暗号では毎回のクエリごとにデータの更新と暗号文の再暗号化等が行われる。特に ORAM では格納位置のシャッフルも行われる。

 サーバへのクエリ内容：ORAM と PIR ではクライアントがアクセスしたい
データそのものについてクエリするが、検索可能暗号では格納したデータがあるキーワードを含んでいるかどうかをクエリする。

 サーバに対して秘匿できる情報：いずれの技術もクエリ内容を秘匿する。
特に、クエリに対してどのデータが返されたかに関する情報を秘匿する。

ORAM と PIR では頻度を含めた全ての情報を秘匿するが、検索可能暗号
では検索に該当するデータの頻度などの一部の情報が漏洩することを許容する。

PIR の具体的な設定は以下の通りである。クライアント U と t 個のサーバ
DB1 , DB2 , . . . , DBt がある。各サーバは同じデータ x = (x1 , x2 , . . . , xn ) ∈ {0, 1}n
をもっており、結託はしないものとする。U が xi を検索するために各サーバにクエリを送信し、サーバがレスポンスを返す。必要に応じてこれを繰り返すことでクライアントは xi を得る。安全性要件として、クライアントが送信するクエリは、
クライアントが検索しようとしているデータのインデックス i をサーバに漏らさないことを要請する。この安全性要件に対して、PIR では、情報理論的安全性、計算量的安全性を満たすプロトコルがそれぞれ提案されている。
このような設定のもとで自明なプロトコルは、t = 1 として、クライアントはクエリを生成せず、サーバが全てのデータ x1 , x2 , . . . , xn をサーバに送ることである。従って、PIR を考えるとき、この自明な方式よりは効率的な手法であることが求められる。

PIR は Chor らによって最初に提案された [63, 64]。ここで提案された方式は情報理論的安全性を満たす。彼らは PIR を情報理論的に達成するために■PIR の歴史

102

は（自明な方式を除いて）サーバ 1 台では不可能であることを示し、結託しない

2 台のサーバが同じデータのコピーをもっていれば PIR が実現できることを示した。この結果から、計算量的安全性のもとで、サーバの数を 1 台まで減らせるかが重要な課題となったが、これは Kushilevitz ら [65] によって肯定的に解決された。この方式でのサーバの計算時間は Ω(n) であり、平方剰余を用いていた。近年の方式では完全準同形暗号を用いて、さらに前処理を含めた複数ラウンドのプロトコルで劣線形時間で実行できるプロトコルが知られている [66, 67]。また符号に基づく PIR も Holzbaur らによって提案されている [68, 69]。
情報理論的な観点からは、t 個のサーバからダウンロードするデータ 1 ビットに対して、検索可能なビット数（通信レート）の最大値（通信容量）に興味がある。例えば、PIR の特徴および他の関連技術との差異の項で示した自明な方式のレートは 1/n である。Sun らはこの最大値が 1/

Pk−1

u=0 n

−u

であることを示し、実際にこの容量を与えるプロトコルを示した [70]。この研究に端を発して、情報理論的な PIR の研究は符号理論などの情報理論的な技術と関連して活発になってきた。例えば、t 台のサーバに同一のコピーを置かずに、サーバに置くデータサイズの削減を目指した Coded PIR [71] は、Katz らによる Locally decodable code[72] を用いて構成される。また、複数のサーバからの応答のうち、いくつかが破損したり改竄されている場合にも正しく情報が得られるロバスト PIR に関する研究も行われている。ロバスト PIR は Beimel と Stahl によって提案され [73]、Belekamp–Welch アルゴリズムによる効率化が Kurosawa によって提案されている [74]。
■代表的方式

本節では、情報理論的に安全な方式として [64] を、計算量的に安全な方式として単一サーバの PIR として初の方式である [65] を紹介する。
情報理論的に安全な 2 サーバ PIR [64][64] では、結託しない 2 台のサーバ DB1 , DB2 を準備し、それぞれが n ビットのデータ x := (x1 , x2 , . . . , xn ) ∈ {0, 1}n を保持しているものとする。ここでクライ
アントが xi の値を知りたいとするとき、以下のようなプロトコルを実行する。
自然数 n に対して、[n] := {1, 2 . . . , n} と定める。
1) 2[n] 上の一様分布から集合 S ⊆ [n] を選ぶ。
2) S1 := S として、s ∈ S であるなら、S2 := S\{i}、s ̸∈ S であるなら
S2 := S ∪ {i} として集合 S1 , S2 をそれぞれ DB1 , DB2 に送る。
3) i = 1, 2 に対して、集合 Si を受け取った DBi は ri = ⊕j∈Si xj をクライアン
トに返送する。ここで ⊕ は XOR を表す。
103

4) クライアントは r1 ⊕ r2 として xi を求める。
プロトコルの健全性は方式からほぼ明らかである。また、集合 S が 2[n] から一様分布に従って選ばれているため、i が S に属す確率は 1/2 である。従って、i がS1 に属す確率も 1/2 であり、S2 に属する確率も 1/2 となる。このことから、i の
情報は DB1 , DB2 のどちらにも情報理論的な意味で漏洩しない。
計算量的に安全な単一サーバ PIR [65]

情報理論的な設定の下で、サーバの数を 1 つにすることができないが [64]、計算量的安全性のもとではサーバを 1 台にすることができる。以下に、Kushilevitz ら[65] によって初めて提案された単一サーバによる PIR プロトコルを示す。
本方式は一人のクライアントとサーバ DB のみで構成され、サーバには s 行 t
列の二値行列 x ∈ {0, 1}s×t が格納されているものとする。クライアントが行列 Mの第 a, b 成分、Ma,b (1 ≤ a ≤ s, 1 ≤ b ≤ t) をの値を知りたいとするとき、以下のようなプロトコルを実行する。

1) 自然数 k に対して、クライアント U は k/2 ビット素数をランダムに 2 つ選
び、その積を N とする。
2) クライアント U は t 個の自然数 y1 , y2 , . . . , yt ∈ {y ∈ Z∗N | ( Ny ) = 1} を、ybは平方非剰余、それ以外は平方剰余であるように一様ランダムに選ぶ。ここ
で

·
·



は Jacobi 記号である。

3) 行列 M の第 i, j 成分 Mi,j ∈ {0, 1}, 1 ≤ i ≤ s, 1 ≤ j ≤ t に対して、サーバ DB は Mi,j = 0 のときに wi,j := yj2 、Mi,j = 1 のときに wi,j := yj としQtて W := (wi,j )(i,j)∈[s]×[t] を作成する。DB はさらに、W から zi := j=1 wi,j ,i = 1, 2, . . . , s を計算する。
4) サーバは z1 , z2 , . . . , zt をクライアントに送る。
5) クライアントは za を取り出し、za が N を法として平方剰余なら Ma,b = 0、
平方非剰余であるなら Ma,b = 1 とする。
構成法から、Ma,b = 1 のときに限って za は N を法として平方剰余となる。ク
ライアントは N の 2 つの素因数を用いて、任意の y ∈ Z∗N が N を法とした平方（非）剰余であるかを多項式時間で判定できるため、Ma,b の値が計算できる。一方で、サーバは N の 2 つの素因数を知らないため、平方剰余仮定により yj や zi が平方剰余であるか否かを判定できない。このことから、直観的にはサーバが a, b
を特定出来ないことがわかる。

104

3.3.7 検索可能暗号
検索可能暗号とは、サーバに保存されている（暗号化）文書に対して、クライアン
トが検索したいキーワード及び暗号化文書の内容を秘匿しながらも、当該キーワー
ドを含む（暗号化）文書のみを効率的に検索できる高機能暗号技術である。特に関連する高機能暗号技術として、第 3.3.5 章に記載された Oblivious Random Access

Machine（ORAM）や第 3.3.6 章に記載された Private Information Retrieval（PIR）がある。以下に各技術の違いをまとめる。

 サーバが保持する情報：PIR ではデータを暗号化しない状態で保持する一方、ORAM や検索可能暗号ではデータを暗号化した状態で保持する。言い換えれば、PIR では元々サーバが管理するデータを、ORAM 及び検索可能
暗号ではクライアントが管理するデータを扱うことを想定している。

 格納した暗号化データの取り扱い：PIR では基本的にサーバに格納されたデータやその暗号文はクエリによって変わることが無いのに対し、ORAM
や検索可能暗号では毎回のクエリごとにデータの更新と暗号文の再暗号化等が行われる。特に ORAM では格納位置のシャッフルも行われる。

 サーバへのクエリ内容：検索可能暗号では格納したデータがあるキーワードを含んでいるかどうかをクエリするのに対し、PIR と ORAM ではクライア
ントがアクセスしたいデータそのものについてクエリする。

 サーバに対して秘匿できる情報：いずれの技術もクエリ内容を秘匿する。特に、クエリに対してどのデータが返されたかに関する情報を秘匿する。しかし、検索可能暗号では検索に該当するデータの頻度などの一部の情報は秘匿しないのに対し、PIR と ORAM では頻度を含めた全ての情報を秘匿する。

ORAM は一般に検索可能暗号よりも強い安全性を保証できる代わりに効率性の理論限界が知られており、検索可能暗号ではサーバ自身もサーバに保存された内容を知り得ないという意味で PIR とは異なる。検索可能暗号では、サーバ上の暗号化された文書に対して、実用上問題ないと考えられる程度の多少の情報の漏洩を許しつつ、ORAM の理論限界を超えた効率的な検索機能を達成可能である。
■検索可能暗号の分類と歴史検索可能暗号は、公開鍵暗号に基づく方式と共通鍵暗号に基づく方式に分類できる。公開鍵ベース方式 [75, 76]（Public-key Encryption

with Keyword Search，PEKS）では公開鍵を用いて暗号化が可能であり、任意のクライアントがサーバに（暗号化）文書を格納可能となる。PEKS は Boneh ら [75]によって提案され、Abdalla ら [76] によって任意の匿名 ID ベース暗号方式を効率
105

的に PEKS に変換できることが示され、基本的な構成枠組みが完成した。以降、当初は考えられていなかった種々の攻撃に対する安全性 [77, 78] や複数キーワー
ドを扱う方式 [79] 等の研究が進められている。一方で、共通鍵ベース方式 [80, 81]（Searchable Symmetric Encryption，SSE）では秘密鍵を知っている特定のクライ
アントしか（暗号化）文書を格納できないものの、処理が高速であるという特長がある。特に、暗号文一つ一つと検索キーワードの一致を判定するアルゴリズムを考え、そして全ての暗号文にそのアルゴリズムを実行することを想定する PEKS とは異なり、SSE では暗号化データベース全体に対して検索を行うアルゴリズムを考えており、検索処理全体の効率性を意識して設計されている。そのような効率性の観点から、SSE に関する研究が現在の検索可能暗号研究の主流となっている。

SSE はその概念自体が Song ら [82] によって提案された後、Curtmola ら [80, 81]
によってそのモデルと安全性が定式化され、具体的な方式も提案された。以降、SSE 方式の効率性改善だけでなく、理論限界の解析 [83, 84, 85] や、正しく結果を返さない不正なサーバを検知することで外部プロトコルと組み合わせた時の安全性を保証する方式 [86]、複数キーワードを扱う方式 [87]、一般的な情報検索を扱う方式 [88] 等の様々な研究が続けられているが、最も盛んに研究が進められているのは、暗号化データベースの動的な更新（任意のタイミングでの文書ファイル・
キーワードの追加/削除）を可能とする Dynamic SSE [89] である。実システム運用を考えると、暗号化データベースの更新機能は重要となる。
■(Dynamic) SSE 方式の特徴と比較上で述べた通り、（Dynamic）SSE ではあらかじ

め “漏洩を許す情報” を定め、検索処理や更新処理から “許した漏洩” 以上の情報を漏らさないことを保証する。特に Dynamic SSE では、許す漏洩の程度によってフォワード安全性 [90] やバックワード安全性 [91] が明示的に定義される。前者
は “文書がデータベースに追加された時、それ以前の検索処理からは追加された文書に関する情報がサーバに漏れない” ことを保証し、検索可能暗号本来の目的である “暗号化したまま検索を行う” ためには、フォワード安全性を満たすことが実用上重要である。後者のバックワード安全性は “文書がデータベースから削除された後、以降の検索処理から削除された文書の情報がサーバに漏れない” ことを保証し、近年最も盛んに研究されている Dynamic SSE の研究テーマである。しかし、その安全性の強さから効率的な実現が難しく構成が複雑になること、バックワー
ド安全性が必要かどうかは応用先に強く依存すると考えられることから、具体的な構成については本ガイドラインでは割愛する。
表 3.1 にいくつかの代表的な Dynamic SSE 方式を示す。表中の記法は次の通り。n はデータベース中の全文書ファイル数を表し、N はデータベース中の（ファ106表 3.1

方式比較。方式名があるものは方式名を、方式名がない場合は著者名を記載している。

計算量はいずれもクライアント側のものであり、◎は漸近的に最適である（原理上これ以上の効率化ができない）ことを表す。FP と BP はそれぞれフォワード安全性とバックワード安全性を表す。

データベース

更新計算量

検索計算量

FP

BP

備考

◎：O(N )◎：O(µ)△：O(n)✓–

シンプルな構成[90]◎：O(N )◎：O(µ)◎：O(nw )

✓

–

[93]

◎：O(N )◎：O(µ)◎：O(nw )

✓

–

[94]

e)
○：O(N

○：O(uw )○：O(uw )

✓

✓

サイズ

[80, 81]（[92]）

公開鍵暗号技術が構成に必要
検索時に少し多く情報漏洩を許す
比較的シンプルな構成

イル識別子, キーワード） のペアの数である（データベースの表現については後述する）。通常、削除処理によってデータベースから削除ファイルに対応するペアが削除されるが、多くのバックワード安全な方式では当該ペアを削除せずに “当該ペアが削除された” という情報を新たにデータベースに追加することで削除したとみなす（検索時にクライアントがその情報を確認し、当該ペアを取り除くことで正しく検索結果を取り出すことができる）。そのため、データベースサイズは増大e (≥ N ) で書く。µ はその更新処理によってデータベースに追加/
し、表中では N
削除されるキーワードの数を表す。nw はデータベース中の検索キーワード w を含むファイル数を表し、uw はこれまでに w に対して行われてきた更新処理（追加及び削除）の総数を表す。すなわち、nw ≤ uw が成り立つ。
なお、ほとんどの Dynamic SSE 方式においてクライアント側で秘密鍵以外の秘密情報を記憶しておく必要がある。そのような情報のサイズも比較対象ではある
ものの、ここでは割愛する。
■代表的な（Dynamic）SSE 方式の紹介

具体的な検索可能暗号の実現方法として、代表的かつシンプルな方式を紹介する。なお、構成要素技術として、疑似ランダム関数（Pseudo-Random Function，PRF）π を用いる。PRF π は、秘密鍵 k と任意の値 x を入力に取り、y を出力する。この時、y は同じ長さの乱数と見分けがつ
かず、疑似乱数として扱うことができる。また、データベースの記法についてもまとめる。識別子 id を持つ文書ファイル fid に対し、 形態素解析等を用いてキー107

ワードを抽出した集合を Wid とする。ここで、識別子 id は文書ファイル fid とは全く関係のない値（たとえば文書管理番号や文書ファイルのハッシュ値）であるとする。（Dynamic） SSE で考えるデータベースは、文書ファイル (id, Wid ) を基に作られた（ファイル識別子, キーワード） のペア (id, w) の集合とする。
以下では、Curtmola らによる SSE 方式である SSE-2 [80, 81] を紹介する。より正確には、オリジナルの方式 [80, 81] には誤り及び冗長な点が含まれるため、その点を修正し、かつ Dynamic SSE に拡張した方式 [92]（表 3.1 の一つ目の方式）を示す。なお、本方式はフォワード安全性を満たす。

 セットアップ及びデータベース生成：クライアントは、PRF 鍵 k をランダムに選び、空の配列 Index を暗号化データベースとして用意しておく。
 文書ファイルの追加：追加したい文書ファイルを fid = (id, Wid ) とする。クライアントは、全ての w ∈ Wid に対して、addr := π(k, w∥id) を計算する。
クライアントは計算した全てのアドレスと識別子 id をサーバに送り、サーバは全てのアドレス addr に対し、Index[addr] に id を格納し、暗号化データ
ベースを更新する。クライアントは別途追加した id を記憶しておく。
 文書ファイルの削除：削除したい文書ファイルの識別子 id に対し、クライア
ントは id をサーバに送る。サーバは Index の格納値を調べ、id が格納されているアドレスを全て空にし、暗号化データベースを更新する。クライアント
は記憶していた id を削除する。

 検索：検索したいキーワード q に対し、クライアントは記憶している全ての識別子 id に対して、トラップドア τid := π(k, q∥id) を計算し、計算した
トラップドアを全てサーバに送る。サーバは、受け取った各 τid に対して、
Index[τid ] の格納値を確認する。もし何かしらの値（すなわち id）が格納されていれば、それを集合 Xq に含める（Xq は最初に空集合として初期化しておく）。最終的にサーバはクライアントに Xq を渡し、クライアントは Xq を検索結果として受理する。
上記の構成において、文書ファイルの追加をセットアップ時のみに行い、それ以降追加も削除も行わなければ、Dynamic ではない通常の SSE 方式となる。

参考文献[1] A. Shamir: “How to Share a Secret”, Commun. ACM, 22, 11, pp. 612–613(1979).
[2] G. R. Blakley: “Safeguarding cryptographic keys”, MARK 1979, pp. 313–
108

317 (1979).
[3] M. Itoh, A. Saito and T. Nishizeki: “Secret Sharing Scheme Realizing General Access Structure”, IEEE Globecom 1987, pp. 99–102 (1987).
[4] B. Chor, G. Goldwasser, S. Micali and B. Awerbuch: “Veriﬁable Secret
Sharing Simultaneity in the Presence of Faults”, FOCS 1985, ACM, pp.
383–395 (1985).
[5] M. Ben-Or, S. Goldwasser and a. Wigderson: “Completeness Theorems for
Non-Cryptographic Fault Tolerant Distributed Computation”, STOC 1988,
ACM, pp. 1–10 (1988).
[6] M. Naor and A. Shamir: “Visual Cryptography”, EUROCRYPT 1994,
Springer-Verlag, pp. 1–12 (1994).
[7] M. Hillery, V. Buzěk and A. Berthiaume: “Quantum Secret Sharing”, Los
Alamos e-print archive, quant-ph/9806063, (1998).
[8] R. Cleve, D. Gottesman and H.-K. Lo: “How to Share a Quantum Secret”,
Physical Review Letters, 83, 3, pp. 648–651 (1999).
[9] A. Shamir: “How to share a secret”, Commun. ACM, 22, 11, pp. 612–613(1979).
[10] E. Karnin, J. Greene and M. E. Hellman: “On Secret Sharing Systems”,
IEEE Trans. Information Theory, 29, 1, pp. 35–41 (1983).
[11] S. Martı́n, C. Padró and A. Yang: “Secret Sharing, Rank Inequalities andInformation Inequalities”, CRYPTO 2013, Springer-Verlag, pp. 277–288(2013).
[12] M. Karchmer and A. Wigderson: “On Span Programs”, Annual Structurein Complexity Theory Conference, pp. 102–111 (1993).
[13] G. R. Blakley and C. Meadows: “Security of ramp schemes”, CRYPTO
1984, Springer-Verlag, pp. 242–268 (1984).
[14] 山本：“(k, L, n) しきい値秘密分散システム”, 電子通信学会論文誌, J68-A,
9, pp. 945–952 (1985).
[15] H. Krawczyk: “Secret sharing made short”, CRYPTO 1993, SpringerVerlag, pp. 136–146 (1993).
[16] S. Shin, S. Yamada, G. Hanaoka, Y. Ishida, A. Kunii, J. Oketani, S. Kunii
and K. Tomomura: “How to Extend CTRT for AES-256 and AES-192”,
IEICE Trans., E105-A(8), pp. 1121–1133 (2022).
[17] “ZENMU-AONT に関する論文が 国際会議で best paper premium award を109受賞”, https://www.atpress.ne.jp/news/191661.

[18] “ISO/IEC 19592-2:2017 Information technology - Security techniques - Secret sharing - Part 2: Fundamental mechanisms”.
[19] M. Iwamoto and H. Yamamoto: “Strongly Secure Ramp Secret Sharing
Schemes for General Access Structures”, Information Processing Letters,
97, 2, pp. 52–57 (2006).
[20] J. Benaloh and J. Leichter: “Generalized Secret Sharing and Monotone
Functions”, CRYPTO 1988, Springer New York, pp. 27–35 (1988).
[21] G. S. Vernam: “Cipher Printing Telegraph Systems for Secret Wire andRadio Telegraphic Communications”, J. of American Institute for ElectricalEngineering, 45, pp. 109–115 (1926).
[22] D. Beaver, S. Micali and P. Rogaway: “The Round Complexity of Secure
Protocols (Extended Abstract)”, STOC 1990, ACM, pp. 503–513 (1990).
[23] Y. Lindell, B. Pinkas, N. P. Smart and A. Yanai: “Eﬃcient Constant-RoundMulti-party Computation Combining BMR and SPDZ”, J. of Cryptology,
32, 3, pp. 1026–1069 (2019).
[24] O. Goldreich, S. Micali and A. Wigderson: “How to Play any Mental Gameor A Completeness Theorem for Protocols with Honest Majority”, STOC
1987, ACM, pp. 218–229 (1987).
[25] M. Ben-Or, O. Goldreich, S. Goldwasser, J. Håstad, J. Kilian, S. Micali
and P. Rogaway: “Everything Provable is Provable in Zero-Knowledge”,
CRYPTO 1988, Springer-Verlag, pp. 37–56 (1988).
[26] T. Araki, J. Furukawa, Y. Lindell, A. Nof and K. Ohara: “High-Throughput
Semi-Honest Secure Three-Party Computation with an Honest Majority”,
ACM CCS 2016, pp. 805–817 (2016).
[27] N. Attrapadung, G. Hanaoka, T. Matsuda, H. Morita, K. Ohara, J. C. N.
Schuldt, T. Teruya and K. Tozawa: “Oblivious Linear Group Actions andApplications”, ACM CCS 2021, pp. 630–650 (2021).
[28] Y. Lindell and A. Nof: “A Framework for Constructing Fast MPC overArithmetic Circuits with Malicious Adversaries and an Honest-Majority”,
ACM CCS 2017, pp. 259–276 (2017).
[29] R. Cramer, I. Damgård and Y. Ishai: “Share Conversion, Pseudorandom Secret-Sharing and Applications to Secure Computation”, TCC 2005,
Springer-Verlag, pp. 342–362 (2005).

110[30] NTT: “秘密計算基盤（Trust-SC）V3.0「算師（R)」｜ NTT R&D Website”.
https://www.rd.ntt/research/SI0005.html.
[31] R. Kikuchi, D. Ikarashi, T. Matsuda, K. Hamada and K. Chida: “Eﬃcient
Bit-Decomposition and Modulus-Conversion Protocols with an Honest Majority”, ACISP 2018, Springer-Verlag, pp. 64–82 (2018).
[32] D. Beaver: “Eﬃcient Multiparty Protocols Using Circuit Randomization”,
CRYPTO 1991, Springer-Verlag, pp. 420–432 (1991).
[33] I. Damgård, V. Pastro, N. P. Smart and S. Zakarias: “Multiparty Computation from Somewhat Homomorphic Encryption”, CRYPTO 2012, SpringerVerlag, pp. 643–662 (2012).
[34] N. P. Smart and T. Tanguy: “TaaS: Commodity MPC via Triples-as-aService”, CCSW@CCS 2019, ACM, pp. 105–116 (2019).
[35] ZenmuTech: “デ ー タ を 秘 匿 化 し た ま 計 算 ｜ ZenmuTech”. https://zenmutech.com/products/secure-computation/.
[36] 石田, 國井, 桶谷, 大畑, 松田, アッタラパドゥン, 花岡：“Query Ahead: 平易な記述が可能な秘匿 DB クエリーシステムの設計と実装”, SCIS 2020 (2020).
[37] A. C. Yao: “How to Generate and Exchange Secrets (Extended Abstract)”,
FOCS 1986, IEEE Computer Society, pp. 162–167 (1986).
[38] M. Bellare, V. T. Hoang and P. Rogaway: “Foundations of Garbled Circuits”, ACM CCS 2012, pp. 784–796 (2012).
[39] M. O. Rabin: “How To Exchange Secrets with Oblivious Transfer”. ePrint
187/2005.
[40] S. Zahur, M. Rosulek and D. Evans: “Two Halves Make a Whole - Reducing
Data Transfer in Garbled Circuits Using Half Gates”, EUROCRYPT 2015,
Springer-Verlag, pp. 220–250 (2015).
[41] V. Kolesnikov and T. Schneider: “Improved Garbled Circuit: Free XOR
Gates and Applications”, ICALP 2008, Springer-Verlag, pp. 486–498 (2008).
[42] M. Naor, B. Pinkas and R. Sumner: “Privacy preserving auctions and mechanism design”, ACM EC 1999, pp. 129–139 (1999).
[43] B. Pinkas, T. Schneider, N. P. Smart and S. C. Williams: “Secure TwoParty Computation Is Practical”, ASIACRYPT 2009, Springer-Verlag, pp.
250–267 (2009).
[44] S. Goldwasser, S. Micali and C. Rackoﬀ: “The Knowledge Complexity ofInteractive Proof Systems”, SIAM J. Computing, 18, 1, pp. 186–208 (1989).

111

[45] B. Manuel, Feldman and P. M. Silvio: “Non-Interactive Zero-Knowledge
and Its Applications”, STOC 1988, ACM, pp. 103–112 (1988).
[46] C.-P. Schnorr: “Eﬃcient Identiﬁcation and Signatures for Smart Cards”,
CRYPTO 1989, Springer-Verlag, pp. 239–252 (1989).
[47] R. Gennaro, C. Gentry, B. Parno and M. Raykova: “Quadratic Span Programs and Succinct NIZKs without PCPs”, EUROCRYPT 2013, SpringerVerlag, pp. 626–645 (2013).
[48] B. Parno, J. Howell, C. Gentry and M. Raykova: “Pinocchio: Nearly Practical Veriﬁable Computation”, IEEE S&P 2013 (2013).
[49] J. Groth: “On the Size of Pairing-Based Non-interactive Arguments”, EUROCRYPT 2016, Springer-Verlag, pp. 305–326 (2016).
[50] E. Ben-Sasson, I. Bentov, Y. Horesh and M. Riabzev: “Scalable Zero Knowledge with No Trusted Setup”, CRYPTO 2019, Springer-Verlag, p. 701–732(2019).
[51] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille and G. Maxwell:“Bulletproofs: Short Proofs for Conﬁdential Transactions and More ”, IEEE
S&P 2018, pp. 315–334 (2018).
[52] O. Goldreich: “Towards a Theory of Software Protection and Simulation
by Oblivious RAMs”, STOC 1987, ACM, pp. 182–194 (1987).
[53] R. Ostrovsky: “Eﬃcient computation on oblivious RAMs”, STOC 1990,
ACM, pp. 514–523 (1990).
[54] O. Goldreich and R. Ostrovsky: “Software protection and simulation on
oblivious RAMs”, 43 (3), pp. 431–473 (1996).
[55] E. Shi, T.-H. H. Chan, E. Stefanov and M. Li: “Oblivious RAM with
O((log N )3 ) worst-case cost”, ASIACRYPT 2011, Springer-Verlag, pp. 197–
214 (2011).
[56] E. Kushilevitz, S. Lu and R. Ostrovsky: “On the (In)Security of Hash-Based
Oblivious RAM and A New Balancing Scheme”, SODA 2012, pp. 143–156(2012).
[57] E. Stefanov, M. van Dijk, E. Shi, C. W. Fletcher, L. Ren, X. Yu and S. Devadas: “Path ORAM: an extremely simple oblivious RAM protocol”, ACM
CCS 2013, pp. 299–310 (2013).
[58] S. Patel, G. Persiano, M. Raykova and K. Yeo: “PanORAMa: Oblivious
RAM with Logarithmic Overhead”, FOCS 2018, ACM, pp. 871–882 (2018).

112

[59] G. Asharov, I. Komargodski, W.-K. Lin, K. Nayak, E. Peserico and
E. Shi: “OptORAMa: Optimal Oblivious RAM”, EUROCRYPT (2) 2020,
Springer-Verlag, pp. 403–432 (2020).
[60] G. Asharov, I. Komargodski, W.-K. Lin and E. Shi: “Oblivious RAM with
Worst-Case Logarithmic Overhead”, CRYPTO (4) 2021, Springer-Verlag,
pp. 610–640 (2021).
[61] S. Lu and R. Ostrovsky: “Distributed Oblivious RAM for Secure Two-Party
Computation”, TCC 2013, Springer-Verlag, pp. 377–396 (2013).
[62] E. Boyle, K.-M. Chung and R. Pass: “Oblivious parallel ram and applications”, TCC 2016, Springer-Verlag, pp. 175–204 (2016).
[63] B. Chor, E. Kushilevitz, O. Goldreich and M. Sudan: “Private Information
Retrieval”, FOCS, IEEE, pp. 41–50 (1995).
[64] B. Chor, E. Kushilevitz, O. Goldreich and M. Sudan: “Private Information
Retrieval”, J. ACM, 45, 6, pp. 965–981 (1998).
[65] E. Kushilevitz and R. Ostrovsky: “Replication Is Not Needed: Single
Database, Computationally-Private Information Retrieval”, FOCS 1997,
IEEE, pp. 364–373 (1997).
[66] H. Corrigan-Gibbs and D. Kogan: “Private Information Retrieval with
Sublinear Online Time”, EUROCRYPT 2020, Springer-Verlag, pp. 44–75(2020).
[67] H. Corrigan-Gibbs, A. Henzinger and D. Kogan: “Single-Server Private Information Retrieval with Sublinear Amortized Time”, EUROCRYPT 2022,
Springer International Publishing, pp. 3–33 (2022).
[68] L. Holzbaur, C. Hollanti and A. Wachter-Zeh: “Computational Code-BasedSingle-Server Private Information Retrieval”, IEEE ISIT 2020, pp. 1065–
1070 (2020).
[69] G. N. Alfarano, K. Khathuria and V. Weger: “A Survey on Single Server
Private Information Retrieval in A Coding Theory Perspective”, Applicable
Algebra in Engineering, Communication and Computing (2021).
[70] H. Sun and S. A. Jafar: “The Capacity of Private Information Retrieval”,
IEEE Trans. Information Theory, 63, 7, pp. 4075–4088 (2017).
[71] D. Augot, F. Levy-dit Vehel and A. Shikfa: “A Storage-Eﬃcient and Robust
Private Information Retrieval Scheme Allowing Few Servers”, CANS 2014,
Springer International Publishing, pp. 222–239 (2014).

113

[72] J. Katz and L. Trevisan: “On The Eﬃciency of +Local Decoding Proceduresfor Error-Correcting Codes”, STOC 2000, ACM, pp. 80–86 (2000).
[73] A. Beimel and Y. Stahl: “Robust Information-Theoretic Private Information Retrieval”, J. of Cryptology, 20, 3, pp. 295–321 (2007).
[74] K. Kurosawa: “How to Correct Errors in Multi-server PIR”, ASIACRYPT
2019, Springer-Verlag, pp. 564–574.
[75] D. Boneh, G. Di Crescenzo, R. Ostrovsky and G. Persiano: “Public Key
Encryption with Keyword Search”, EUROCRYPT 2004, Springer-Verlag,
pp. 506–522 (2004).
[76] M. Abdalla, M. Bellare, D. Catalano, E. Kiltz, T. Kohno, T. Lange,
J. Malone-Lee, G. Neven, P. Paillier and H. Shi: “Searchable Encryption
Revisited: Consistency Properties, Relation to Anonymous IBE, and Extensions”, J. of Cryptology, 21, 3, pp. 350–391 (2007).
[77] Q. Tang: “Towards Forward Security Properties for PEKS and IBE”, Information Security and Privacy, ACISP 2015, Springer-Verlag, pp. 127–144(2015).
[78] R. Chen, Y. Mu, G. Yang, F. Guo and X. Wang: “A New General Framework for Secure Public Key Encryption with Keyword Search”, Information
Security and Privacy, ACISP 2015, Springer-Verlag, pp. 59–76 (2015).
[79] P. Golle, J. Staddon and B. Waters: “Secure Conjunctive Keyword Searchover Encrypted Data”, ACNS 2004, Springer-Verlag, pp. 31–45 (2004).
[80] R. Curtmola, J. Garay, S. Kamara and R. Ostrovsky: “Searchable Symmetric Encryption: Improved Deﬁnitions and Eﬃcient Constructions”, ACM
CCS 2006, pp. 79–88 (2006).
[81] R. Curtmola, J. A. Garay, S. Kamara and R. Ostrovsky: “Searchable Symmetric Encryption: Improved Deﬁnitions and Eﬃcient Constructions”, J.
of Computer Security, 19, 5, pp. 895–934 (2011).
[82] D. X. Song, D. Wagner and A. Perrig: “Practical Techniques for Searches
on Encrypted Data”, IEEE S&P 2000, pp. 44–55 (2000).
[83] G. Asharov, G. Segev and I. Shahaf: “Tight Tradeoﬀs in Searchable Symmetric Encryption”, J. of Cryptology, 34, 9, pp. 1–37 (2021).
[84] G. Asharov, M. Naor, G. Segev and I. Shahaf: “Searchable Symmetric Encryption: Optimal Locality in Linear Space via Two-Dimensional Balanced
Allocations”, SIAM J. Computing, 50, 5, pp. 1501–1536 (2021).

114

[85] D. Cash and S. Tessaro: “The Locality of Searchable Symmetric Encryption”, EUROCRYPT 2014, Springer-Verlag, pp. 351–368 (2014).
[86] K. Kurosawa and Y. Ohtaki: “UC-Secure Searchable Symmetric Encryption”, Financial Cryptography and Data Security, FC 2012, Springer-Verlag,
pp. 285–298 (2012).
[87] D. Cash, S. Jarecki, C. Jutla, H. Krawczyk, M.-C. Roşu and M. Steiner:“Highly-Scalable Searchable Symmetric Encryption with Support for
Boolean Queries”, CRYPTO 2013, Springer-Verlag, pp. 353–373 (2013).
[88] M. Chase and S. Kamara: “Structured Encryption and Controlled Disclosure”, ASIACRYPT 2010, Springer-Verlag, pp. 577–594 (2010).
[89] S. Kamara, C. Papamanthou and T. Roeder: “Dynamic Searchable Symmetric Encryption”, ACM CCS 2012, pp. 965–976 (2012).
[90] R. Bost: “Σoφoς: Forward Secure Searchable Encryption”, ACM CCS 2016,
pp. 1143–1154 (2016).
[91] R. Bost, B. Minaud and O. Ohrimenko: “Forward and Backward Private
Searchable Encryption from Constrained Cryptographic Primitives”, ACM
CCS 2017, pp. 1465–1482 (2017).
[92] Y. Watanabe, T. Nakai, K. Ohara, T. Nojima, Y. Liu, M. Iwamoto and
K. Ohta: “How to Make a Secure Index for Searchable Symmetric Encryption, Revisited”, IEICE Trans., E105-A(12), pp. 1559–1577 (2022).
[93] M. Etemad, A. Küpçü, C. Papamanthou and D. Evans: “Eﬃcient Dynamic
Searchable Encryption with Forward Privacy”, Privacy Enhancing Technologies (PoPETs), Vol. 2018(1), pp. 5–20 (2018).
[94] J. G. Chamani, D. Papadopoulos, C. Papamanthou and R. Jalili: “NewConstructions for Forward and Backward Private Symmetric Searchable
Encryption”, ACM CCS 2018, pp. 1038–1055 (2018).

115

第4章

おわりに
本ガイドラインに記載した内容は、2022 年 9 月以前に公開された情報に基づいている。2022 年 9 月以降も多くの高機能暗号に関連する情報が、各社の広報、学会、標準化団体において公開されてきているが、発表されたばかりであり、安全性の評価が完全には行われていない方式もある。本ガイドラインで記載した高機能
暗号は、2022 年 9 月時点で、主要国際学会で発表されており、有力な攻撃法が発見されておらず、かつ、十分な性能を持つと考えられる方式を選んでいる。
高機能暗号の特徴であるが、機能が異なれば、異なる暗号となる。このため、多くの種類の高機能暗号があり、それらすべて本ガイドラインに掲載することはできない。主要と考えられる高機能暗号に絞って掲載することになった。
また、高機能暗号は多種多様であるが故に、導入するためには専門的な知識が要求される。この知識を有し、かみ砕いて説明でき、ケースに応じて応用するスキルを有する人材の確保は課題となっている。さらに、既存システムとの整合性を考慮し、例えば、組織内の端末にソフトウェアとして導入できるか、マネージメン
トシステムと連携できるか、Web ブラウザ上で動作ができるか、インターフェー
スはどのような形態がよいか等、これらは実際のシステム開発者や利用者と密に連携をとりつつ開発することが必要となる。
本ガイドラインが、用途に適した高機能暗号を選択するため、および、研究者、システム開発者、利用者にとっての指針となれば幸いである。

116

CRYPTREC 暗号技術ガイドライン（高機能暗号）[CRYPTREC GL-2005-2022]
不許複製

禁無断転載

発行日：2023 年 3 月 31 日（第１版）
発行者
・ 〒184-8795
東京都小金井市貫井北町四丁目２番１号
国立研究開発法人

情報通信研究機構（サイバーセキュリティ研究所

セキュリティ基盤研究室）

NATIONAL INSTITUTE OF INFORMATION AND COMMUNICATIONS TECHNOLOGY
4-2-1 NUKUI-KITAMACHI, KOGANEITOKYO, 184-8795 JAPAN・ 〒113-6591
東京都文京区本駒込二丁目２８番８号
独立行政法人情報処理推進機構(技術本部 セキュリティセンター 暗号グループ）
INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN
2-28-8 HONKOMAGOME, BUNKYO-KU
TOKYO, 113-6591 JAPAN117

資料３－８軽量暗号に関する技術動向調査報告（外部評価）
1. 背景
2019 年度に設置された量子コンピュータ時代に向けた暗号の在り方検討タスクフォースにて、「CRYPTREC において、軽量暗号は CRYPTREC 暗号リストには組み込まず、別途ガイドラインという形で取り扱う」ことが決定された。本決定を受け、2020 年度
第 2 回暗号技術検討会において、2016 年度に作成した「CRYPTREC 暗号技術ガイドライン（軽量暗号）」（以下、「2016 年度版ガイドライン」という）について 2023 年度
中を目処に更新することが承認された。
2016 年度版ガイドラインの更新方針を決定するにあたり、2021 年度に『2016 年度
版ガイドラインに掲載されている暗号方式の大幅な安全性の劣化に繋がる脆弱性の有無』『軽量暗号に関わる ISO/IEC 29192 シリーズに近年採択された、又は採択予定の暗号方式の 2016 年度版ガイドライン掲載の有無及びその安全性』『CAESAR プロジェ
クトで最終的に選ばれたポートフォリオ 6 方式の 2016 年度版ガイドライン掲載の有無
および掲載されていない暗号方式の安全性』に関して調査した。
上記の調査結果に基づき 2016 年度版ガイドラインの更新方針を策定し、2021 年度
第 2 回暗号技術評価委員会において本更新方針が承認された。
承認された更新方針に従い、今年度は、NIST 軽量暗号プロジェクト（NIST1Lightweight Cryptography Project2. 以下、「NIST LWC」という）のファイナリスト
10 方式（ASCON, Elephant, GIFT-COFB, Grain-128AEAD, ISAP, PHOTON-Beetle,
Romulus, SPARKLE, TinyJAMBU, Xoodyak）を対象とした安全性評価及び実装性能評価
を外部評価により実施した。なお、安全性評価に関しては、上記 10 方式に加え、ISO/IEC 標準規格として 29192 シリーズで規格化された軽量メッセージ認証コードの1 つである Tsudik’s keymode も対象としている。また、軽量暗号に関わる NIST 公開
文書や ISO などの標準化動向に関わる調査を外部評価により実施した。
本資料にて、外部評価実施内容について報告する。
なお、2023 年 2 月 7 日に、NIST LWC 最終選考結果が発表され ASCON が選ばれた。

1
2

アメリカ国立標準技術研究所 (National Institute of Standards and Technology)
https://csrc.nist.gov/projects/lightweight-cryptography2. 実施概要
2.1. 安全性評価
NIST LWC ファイナリストに選定された 10 方式と ISO/IEC 標準規格として承認された Tsudik's keymode の安全性に関する調査及び評価を実施した。
【件名】
軽量暗号の安全性に関する調査及び評価（各依頼先に応じた暗号方式を記載）【依頼内容】
対象方式の安全性評価について、公開されている評価結果の有無を調査し、評価結果が存在する場合にはその影響範囲についてまとめ、評価結果が存在しない場合には安全性評価を実施し、評価報告書を作成する。
【依頼先および依頼対象方式】
岩田 哲 准教授（名古屋大学）
・認証暗号＋ハッシュ関数：PHOTON-Beetle, SPARKLE
・軽量 MAC：Tsudik’s keymode
内藤 祐介 様（三菱電機株式会社）
・認証暗号＋ハッシュ関数：Xoodyak
・認証暗号：GIFT-COFB
藤堂 洋介 様（日本電信電話株式会社）
・認証暗号＋ハッシュ関数：ASCON
・認証暗号：Grain-128AEAD, TinyJAMBU
井上 明子 様（日本電気株式会社）
・認証暗号＋ハッシュ関数：Romulus
・認証暗号：Elephant, ISAP

2.2. 実装性能評価
NIST LWC ファイナリストに選定された 10 方式の実装性能（ハードウェア及びソフトウェア）に関する調査及び評価を実施した。
【件名】
軽量暗号の実装性能に関する調査及び評価（NIST LWC）
【依頼内容】NIST LWC でファイナリストに選定された 10 方式に対する実装性能評価について、公開されている評価結果を調査し、評価結果についてまとめ、考察などを行い、評価報告書を作成する。

【依頼先および依頼対象方式】
崎山 一男 教授（電気通信大学）
・認証暗号＋ハッシュ関数：ASCON, PHOTON-Beetle, Romulus, SPARKLE, Xoodyak
・認証暗号：Elephant, GIFT-COFB, Grain-128AEAD, ISAP, TinyJAMBU

2.3 . 標準化動向など
軽量暗号を取り巻く標準化動向(CAESAR プロジェクト、ISO/IEC の軽量暗号関連カ
テゴリ、NIST LWC など)の調査を実施した。
【件名】
軽量暗号の評価指標、標準化動向に関する調査（NIST LWC ファイナリストなど）【依頼内容】「NIST LWC 最終選考に選定された方式」に関わる選定指標や評価の観点をまとめると
ともに、「軽量な方式として ISO/IEC 標準規格として近年承認されたもしくは承認される予定の方式」に関わる軽量暗号に関わる技術動向について、公開情報を基にまとめ、考察などを行い、報告書を作成する。
【依頼先】
菅野 哲 様（GMO サイバーセキュリティ by イエラエ株式会社）

3. 調査結果概要
3.1. 安全性評価
3.1.1. 概要
本節では安全性評価に関する調査結果の概要を方式ごとにまとめた。
NIST LWC ファイナリストに選定された 10 方式（ASCON, Elephant, GIFT-COFB,
Grain-128AEAD, ISAP, PHOTON-Beetle, Romulus, SPARKLE, TinyJAMBU, Xoodyak）とISO 採択方式である Tsudik's keymode の安全性評価について、2022 年 9 月現在における調査結果を次のとおり表にまとめた。
安全性を脅かす攻撃が存在しない方式

特定の場合を除き、安全性を脅かす方式が存在しない方式

ASCON, Elephant, GIFT-COFB, Grain128AEAD, ISAP, PHOTON-Beetle, Romulus,
SPARKLE, Xoodyak

TinyJAMBU, Tsudik's keymodeTinyJAMBU では、関連鍵設定の場合に現実的な計算量での偽造攻撃が実行可能である。本攻撃が成立するような関連鍵の使用を避けることで TinyJambu の安全性を確保できることを確認した。
Tsudik's keymode では、使用するハッシュ関数が伸長攻撃3を許す場合に偽造攻撃が実行可能となるという既知の脆弱性が存在する。伸長攻撃が実行不可能なハッシュ関数を使用することで Tsudik's keymode の安全性を確保できることを確認した。

3.1.2. ASCONASCON は独自の暗号学的置換をプリミティブとして使用した Duplex 構造の認証暗号（ASCON-128, ASCON-128a）と Sponge 構造のハッシュ関数（ASCON-Hash, ASCONHasha）をサポートしている。認証暗号における暗号化処理とハッシュ関数における処理は図 1 と図 2 のとおり。Primary member4は ASCON-128 と ASCON-Hash である。

図 1 ：ASCON の認証暗号における暗号化処理

図 2：ASCON のハッシュ関数における処理3

伸長攻撃（length-extention attack）は、マークル・ダンガード構成のような反復型ハッシュ関数𝐻について、𝐻(𝑀|𝑀′)が𝐻(𝑀)と𝑀′のみから計算できるという性質を利用する攻撃である。
4
複数個の提案方式の中から設計者が一番に推奨する暗号方式のことを指す。primary recommendation と記載している仕様書もあるが、本資料では primary member で統一する。なお、提案方式におけるパラメ
ータは NIST LWC の要件である鍵長 128 ビット以上、ナンス長 96 ビット以上、タグ長 64 ビット以上を満たす値が設定されている。

認証暗号に対する安全性は Duplex 構造の安全性に依存する5。プリミティブを考慮
した安全性評価として、初期化フェーズ、データ処理フェーズ、タグ生成フェーズの3 つのフェーズを対象とした解析結果が多数報告されている。各フェーズに対する最良の攻撃手法は次のとおり。なお、攻撃可能段数は暗号学的置換におけるラウンド関数の段数を表している。
フェーズ

攻撃手法

攻撃目標

攻撃可能段数

初期化

キューブ攻撃鍵回復

12 段中 7 段

データ処理

SAT solver

内部状態復元8 段中 2 段

タグ生成

差分攻撃

偽造

12 段中 2 段

設計者による安全性評価によると、仕様段数である 12 段の暗号学的置換に対してゼロ
サム識別攻撃が実行可能である。しかし、本攻撃が ASCON の認証暗号としての脆弱性に繋がらないため認証暗号は安全である、と設計者は主張している。
ハッシュ関数に対する安全性は Sponge 構造の安全性に依存する。プリミティブを考慮した安全性評価として、いくつかの解析結果が報告されている。ハッシュ関数に対する最良の攻撃手法は次のとおり。
攻撃手法

攻撃目標

攻撃可能段数

代数攻撃

原像回復

12 段中 6 段

差分攻撃

衝突

12 段中 2 段

以上より、ASCON の安全性解析に関する文献が多数報告されているものの、認証暗号とハッシュ関数について安全性を脅かす攻撃手法は存在しないことを確認した。

3.1.3. Elephant
Elephant は暗号学的置換をプリミティブとして使用した認証暗号利用モードの名称であり、このモード構成を利用した 3 つの認証暗号 Dumbo, Jumbo, Delirium をまとめた総称でもある。これら 3 つの暗号方式は使用する暗号学的置換が異なり、それぞれ
SPONGENT-π[160], SPONGENT-π[176], Keccak-𝑓[200]をプリミティブとして使用する。Primary member は Dumbo である。
設計者が主張する Elephant の安全性は次のとおり。ここで、オフライン計算量は公開ランダム置換へのアクセス回数、オンライン計算量は 1 つの鍵で処理可能なデータ量の上限を表す。

5

プリミティブを理想化した場合において使用する暗号利用モードの安全性に帰着できることを意味する。別途、暗号利用モードで使用されるプリミティブを考慮した安全性評価が必要となる。

方式

オフライン計算量

オンライン計算量

Dumbo

2112

250 バイト

Jumbo

2127

250 バイト

Delirium

2127

274 バイト

Elephant の安全性証明に関する文献、使用するプリミティブの安全性解析に関する文
献、サイドチャネル攻撃等の非ブラックボックス安全性の解析に関する文献がいくつか報告されているものの、これら 3 つの暗号方式について、設計者が主張する安全性を脅かす攻撃は存在しないことを確認した。

3.1.4. GIFT-COFB
GIFT-COFB はブロック暗号をプリミティブとして使用した認証暗号であり、ブロッ
ク暗号ベースの認証暗号利用モード COFB とブロック暗号 GIFT-128 を組み合わせた方式である。
設計者が主張する GIFT-COFB の安全性は次のとおり。ここで、オフライン計算量は
公開ランダム置換へのアクセス回数、オンライン計算量は 1 つの鍵で処理可能なデー
タ量の上限を表す。
IND-CPA

INT-CTXT

オフライン計算量 オンライン計算量 オフライン計算量 オンライン計算量
112 ビット

64 ビット112 ビット

58 ビットGIFT-128 に対する最良の攻撃手法は差分解読法による鍵回復攻撃であり、20 段の差分識別子を使用して 40 段中 27 段に対して鍵回復攻撃が実行可能となる。つまり、オフライン計算に関して設計者が主張する 112 ビット安全性を有していると言える。
COFB の安全性はブロック暗号が擬似ランダム置換（PRP）であることを仮定している。上述のとおり、GIFT-128 の安全性は担保されているため、GIFT-COFB の安全性はCOFB の安全性に依存する。COFB の提案論文において、ブロックサイズが n ビット、ブロック暗号が PRP 安全であると仮定すると、IND-CPA のオンライン計算に関して n/2
ビット、INT-CTXT のオンライン計算に関して n/2-log2 n ビットとなることが証明されている。現時点でこの安全性証明を覆す結果が報告されていないことを確認した。

3.1.5. Grain-128AEAD
Grain-128AEAD はストリーム暗号 Grain の系譜（Grain v0, Grain v1, Grain-128,
Grain-128a）を継ぐ認証暗号である。NIST LWC 期間中、内部状態が既知という仮定の下で鍵回復攻撃が実行可能であるとの報告を受け、現在は Grain-128AEADv2 として仕様が更新されている。
Grain-128AEADv1 と Grain-128AEADv2 の安全性評価に関する文献は少ないものの、
概ね等価な Grain-128a の安全性評価に関する文献は多数報告されており、これらの解
析結果に基づき Grain-128AEADv2 の安全性を考察できる。Grain-128a に対して脅威となった攻撃手法は高速相関攻撃とキューブ攻撃であり、これらの攻撃手法に対するGrain-128AEADv2 の安全性を考察した結果、Grain-128AEADv2 はこれらの攻撃手法に対して安全性マージンを十分に有していることを確認した。

3.1.6. ISAP
ISAP は暗号学的置換をプリミティブとして使用した認証暗号利用モードの名称であり、このモード構成を利用した 4 つの認証暗号 ISAP-A-128A, ISAP-K-128A, ISAP-A128, ISAP-K-128 をまとめた総称でもある。これら 4 つの暗号方式は使用する暗号学的置換が異なり、ISAP-A-128A と ISAP-A-128 は ASCON-p、ISAP-K-128A と ISAP-K-128
は Keccak-p[400]を使用する。Primary member は ISAP-A-128A である。サイドチャネ
ル攻撃に対して堅牢となるよう Fresh rekeying と呼ばれる概念を導入していることが特徴である。
設計者は全ての ISAP members があらゆる攻撃に対して 128 ビット安全性を有していると主張している。ブラックボックス安全性証明に関する文献、耐漏洩安全性証明に関する文献、使用するプリミティブの安全性解析に関する文献、サイドチャネル攻撃
耐性の解析に関する文献がいくつか報告されているものの、設計者が主張する安全性を脅かす攻撃は存在しないことを確認した。

3.1.7. PHOTON-Beetle
PHOTON-Beetle は暗号学的置換をプリミティブとして使用した認証暗号（PHOTONBeetle-AEAD[32], PHOTON-Beetle-AEAD[128]）とハッシュ関数（PHOTON-BeetleHash[32]）をサポートしており、認証暗号の primary member は PHOTON-BeetleAEAD[128]である。認証暗号に関しては Duplex 構造を改良した認証暗号利用モード
Beetle と暗号学的置換 PHOTON-256、ハッシュ関数に関しては Sponge 構造と PHOTON256 をそれぞれ組み合わせた方式となっている。
PHOTON-256 に対する最良の攻撃手法はゼロサム識別攻撃であり、仕様段数である 12段に対して識別攻撃が実行可能である。ただし、本攻撃が PHOTON-Beetle の安全性に

直接影響を及ぼすものではないことに注意が必要である。本攻撃を除き、仕様段数に対して実行可能な攻撃手法は報告されていないことを確認した。
設計者が主張する認証暗号の安全性は次のとおり。
IND-CPA方式

INT-CTXT

データ量

計算量

データ量

計算量

PHOTON-Beetle-AEAD[32]128 ビット

128 ビット

128 ビット

128 ビット

PHOTON-Beetle-AEAD[128]121 ビット

121 ビット

121 ビット

121 ビット

認証暗号の安全性証明に関する文献がいくつか報告されているものの、一部を除き設計者が主張する安全性と齟齬がないことを確認した。なお、PHOTON-Beetle-AEAD[32]の IND-CPA と INT-CTXT の計算量に関して理論的根拠が無いことに注意が必要である。
また、設計者が主張するハッシュ関数の安全性は次のとおり。
方式
PHOTON-Beetle-Hash[32]

衝突困難性

原像計算困難性

112 ビット

128 ビット（データ量：2111.5）

ハッシュ関数の安全性は Sponge 構造の安全性に依存する。ハッシュ関数の安全性証明に関する文献がいくつか報告されているものの、設計者が主張する安全性と齟齬がないことを確認した。

3.1.8. Romulus
Romulus は Tweakable ブロック暗号の Skinny-128-384+をプリミティブとして使用した認証暗号（Romulus-N, Romulus-M, Romulus-T）とハッシュ関数（Romulus-H）をサ
ポートしている。これら 4 方式は全て同じプリミティブを使用するがモード構成が異なる。認証暗号の Primary member は Romulus-N である。
設計者が主張する認証暗号 3 方式の安全性は次のとおり。ここで、NR は Noncerespecting、NM は Nonce-misuse を表す。
方式

IND-CPA (NR)INT-CTXT (NR)IND-CPA (NM)INT-CTXT (NM)Romulus-N

128 ビット

128 ビット--

Romulus-M

128 ビット

128 ビット

64〜128 ビット

64〜128 ビット

Romulus-T

121 ビット

121 ビット-

121 ビット

これら 3 方式の安全性証明に関する文献がいくつか報告されているものの、全て設計者が主張する安全性と齟齬がないことを確認した。
また、設計者が主張するハッシュ関数の安全性は次のとおり。

方式

衝突困難性

原像計算困難性

第 2 原像計算困難性

Romulus-H

121 ビット

121 ビット

121 ビット

Romulus-H の安全性証明に関する第三者評価の文献は報告されていない。また、40 段
中 23 段に簡略化したプリミティブを使用した場合、原像攻撃と Free-start 設定における衝突攻撃が実行できると報告されているが、これらの攻撃は仕様上の安全性を脅かすものではないことを確認した。

3.1.9. SPARKLESPARKLE は独自の暗号学的置換をプリミティブとして使用した Duplex 構造の認証暗号（SCHWAEMM）と Sponge 構造のハッシュ関数（ESCH）をサポートしている。暗号学的置換は入出力サイズに応じて SPARKLE256, SPARKLE384, SPARKLE512 を定義しており、これらの暗号学的置換を使用してキャパシティとレートが異なる 4 つの認証暗号と 2
つのハッシュ関数が提案されている。Primary member は SPARKLE384 を使用した
SCHWAEMM256-128 と ESCH256 である。
暗号学的置換としての SPARKLE には big instances と slim instances があり、これらはラウンド関数の段数のみ異なる。例えば、SPARKLE384 の big instance は 11 段、
slim instance は 7 段である。設計者による SPARKLE の安全性評価によると、3 方式全てにおいて slim instances を脅かす攻撃手法が存在しないと主張されている。第三者による安全性評価に関する文献がいくつか報告されているものの、設計者が主張する安全性を脅かす結果は報告されていないことを確認した。
設計者が主張する SCHWAEMM の安全性は次のとおり。
方式

IND-CPA

INT-CTXT

データ制限

SCHWAEMM256-128

120 ビット

120 ビット

268 バイトSCHWAEMM192-192

184 ビット

184 ビット

268 バイトSCHWAEMM128-128

120 ビット

120 ビット

268 バイトSCHWAEMM256-256

248 ビット

248 ビット

2133 バイト

SCHWAEMM は Duplex 構造の認証暗号利用モードである Beetle をベースに構成されており、SCHWAEMM の安全性は Beetle の安全性に依存する。現時点で設計者が主張する安
全性を脅かす解析結果は存在しないことを確認した。
また、設計者が主張する ESCH の安全性は次のとおり。

方式

衝突困難性

原像計算困難性

第 2 原像計算困難性

データ制限

ESCH256

128 ビット

128 ビット

128 ビット

2132 バイト

ESCH384

192 ビット

192 ビット

192 ビット

2196 バイト

ESCH の安全性は Sponge 構造の安全性に依存する。現時点で設計者が主張する安全性を脅かす解析結果は存在しないことを確認した。

3.1.10. TinyJAMBU
TinyJAMBU は独自の鍵付き暗号学的置換をプリミティブとして使用した Duplex 構造の認証暗号である。秘密鍵のサイズは 128, 192, 256 ビットの 3 種類をサポートしており、それぞれ TinyJAMBU-128, TinyJAMBU-192, TinyJAMBU-256 と呼ばれている。
単一鍵設定での最良な攻撃手法は、タグ生成フェーズを対象とした線形解読法による部分鍵回復攻撃である。攻撃可能段数は 640 段中 387 段であるため、安全性マージ
ンを十分に有していることを確認した。なお、TinyJAMBU の現バージョンは v2 であるが、v1 のタグ生成フェーズにおける暗号学的置換は 384 段構成であったため、v1 は単一鍵設定において安全性を有していないことを確認した。
関連鍵設定での最良な攻撃手法は、差分解読法による偽造攻撃である。適切な秘密
鍵とナンスペアを利用することで、232+214 の計算量で関連鍵偽造攻撃が実行可能となる。なお、本攻撃は TinyJAMBU-128 には有効ではない。
その他、プリミティブに対する安全性評価として、スライド攻撃による鍵回復攻撃が報告されている。TinyJAMBU を構成する鍵付き暗号学的置換をブロック暗号とみなした場合、約 264 の計算量で鍵回復攻撃が実行可能となる。なお、本攻撃は認証暗号としての安全性に影響を及ぼすものではない。
以上より、単一鍵設定では TinyJAMBU の安全性を脅かす攻撃は存在しないものの、関連鍵設定では現実的な計算量で偽造攻撃が実行できることに注意が必要である。

3.1.11. Xoodyak
Xoodyak は Xoodoo と呼ばれる暗号学的置換をプリミティブとして使用した Duplex
構造の認証暗号と Sponge 構造のハッシュ関数をサポートしている。
Xoodoo に対する最良の攻撃手法はゼロサム識別攻撃であり、仕様段数である 12 段
に対して現実的な計算量での識別攻撃が実行可能である。ただし、本攻撃が Xoodyakの安全性に直接影響を及ぼすものではないことに注意が必要である。本攻撃を除き、仕様段数に対して実行可能な攻撃手法は報告されていないことを確認した。

設計者が主張する認証暗号の安全性は次のとおり。
IND-CPA

INT-CTXT

オフライン計算量 オンライン計算量 オフライン計算量 オンライン計算量
128 ビット

160 ビット

128 ビット

160 ビット

認証暗号の安全性は Duplex 構造の安全性に依存するが、INT-CTXT に関して設計者の主張する安全性と Duplex 構造の安全性（オフライン計算で 128 ビット、オンライン計
算で 64 ビット）に齟齬があることに注意が必要である。なお、現時点で設計者が主張する安全性を破る攻撃は存在しない。プリミティブとして 12 段中 6 段に簡略化した
Xoodoo を考慮した場合、条件付きキューブ攻撃による鍵回復攻撃が実行可能である。
現時点で本攻撃が最良の攻撃手法であるため、認証暗号が安全性マージンを十分に有していることを確認した。
また、設計者が主張するハッシュ関数の安全性は次のとおり。
衝突困難性

原像計算困難性

第 2 原像計算困難性

128 ビット

128 ビット

128 ビット

ハッシュ関数の安全性は Sponge 構造の安全性に依存する。設計者の主張する安全性とSponge 構造の安全性に齟齬はなく、現時点でハッシュ関数に対する攻撃は報告されていない。

3.1.12. Tsudik’s keymode
Tsudik’s keymode はハッシュ関数をプリミティブとして使用した軽量メッセージ認証コードであり、ISO/IEC 29192-6 にて国際標準化されている。秘密鍵とメッセージの組み合わせをハッシュ関数への入力とし、ハッシュ関数の出力値における最下位 t
ビットをタグとして出力する方式である。
Tsudik’s keymode の安全性は使用するハッシュ関数の安全性に依存する。ハッシュ関数が伸長攻撃を許す場合には偽造攻撃が実行可能となるため、明らかな脆弱性を有している。マークル・ダンガード構成のハッシュ関数（例：SHA-256）では伸長攻撃が可能であり、これらのハッシュ関数を Tsudik’s keymode で使用すべきではない。実際に、ISO/IEC 29192-6 では、ハッシュ関数が衝突困難性を有することに加え、伸長攻撃が不可能であることを要件として挙げている。
一方、ランダムオラクルからの強識別不可能性が証明できるようなハッシュ関数を使用する場合、Tsudik’s keymode は証明可能安全性を有する方式となる。ISO/IEC
29192-6 には具体例として、ISO/IEC 29192-5 において軽量ハッシュ関数として国際標準化されている PHOTON、SPONGENT、Lesamnta-LW の使用を推奨している。Lesamnta-LW
はマークル・ダンガード構成のハッシュ関数であるが、提案者が Tsudik’s keymode で利用した場合の擬似ランダム性を証明している。つまり、これら 3 方式の軽量ハッシ
ュ関数はいずれも Tsudik’s keymode での使用に適していることを確認した。

3.2. 実装性能評価
調査報告書概要は以下の通り。
ハードウェア実装性能の評価について、最も多く使用されたプラットフォームの一
つに Xilinx 社 の Artix-7 がある。このプラットフォーム上で面積コストとスルー
プット性能を図 3 にプロットした。

図 3 NIST LWC ファイナリストの Xilinx Artix-7 上の実装性能．
Grain128-AEAD は，今回の調査で結果が見つからなかったためプロットはない．
詳細の設定や測定条件の違いにより同じアルゴリズム同じ面積コストでも異なるス
ループット性能も存在している6。読み取れることとして、TinyJAMBU の回路面積が小さいこと、SPARKLE は比較的面積コストが大きくなることなどが挙げられる。また、
ASCON、Elephant、GIFT-COFB、Romulus のプロットは広く分散していることから軽量実装から高速実装まで、FPGA 実装における設計の選択肢が多いアルゴリズムであるこ6

例えば、同じプラットフォームであってもインタフェースの仕様や最適化の方針が異なることにより、面積コストや処理性能は大きな影響を受ける。また、暗号化/復号や AD の有無などによっても異なる。そのため、同じプラットフォーム上であっても、一つの方式について数値にばらつきが出る。

とが分かった。ただし、今後の研究の進展およびデータの公開により他のアルゴリズ
ムについても同様の柔軟性がある可能性はある。
ソフトウェア実装性能の評価について、低リソースプラットフォーム上での実装性
能評価は有用である。低リソースプラットフォームの一例として[1]では、Arm
Cortex-M0 上のソフトウェア実装の結果が公開されている。これを表 1 に示す。
表 1 NIST LWC ファイナリストの Arm Cortex-M0 上の実装性能

表 1 ではレイテンシとコードサイズをまとめている。なお、括弧内の名称は、各ア
ルゴリズムの Primary member のリファレンスソフトウェアである。RAM の使用量は、コンパイル時の静的なメモリサイズのレポートから、どのアルゴリズムも約 1kByte
程度であることが分かった。
レイテンシは、平文と AD(Associated Data)を 0 バイトから 32 バイトまで変化させた共通のテストベクトルを用いた際に、暗号化にかかった時間を平均した値で比較をしたところ、Elephant が最もレイテンシが高く、TinyJAMBU、Xoodyak、ASCON、SPARKLE が低レイテンシであることが分かった。コートサイズは、 ASCON が最も大き
く、他の候補暗号方式には大きな差は見られなかった。この観測結果はある一面であり、プラットフォームに適した最適化実装を施すことにより、より良い結果が得られることは考慮の余地がある7。
他、報告書では、それぞれの暗号方式毎に、実装性能に関わる調査結果をまとめている。
[1] Ryota Hira, Tomoaki Kitahara, Daiki Miyahara, Yuko Hara-Azumi, Yang Li,
Kazuo Sakiyama:Software Evaluation for Second Round Candidates in NISTLightweight Cryptography. IACR Cryptol. ePrint Arch. 2022: 591 (2022)

7

一例として、ASCON について別のプラットフォーム上でコードサイズを最適化した実装などの結果も示されている。プラットフォームに即した最適化や最適化方針の違いによりコードサイズは異なる。

3.3. 標準化動向
調査報告書概要は以下の通り。
2016 年度版ガイドライン(2017 年 3 月発行)、CAESAR プロジェクト(2013 年～2019年)、ISO/IEC の軽量暗号関連カテゴリ(2012 年～)、および NIST LWC ファイナリスト(2021 年 3 月)について、いずれにも掲載/規格化/選出されている方式はあまりないということが明らかとなった。このような現象が起きた要因としては、それぞれの選考
時期のずれや対象カテゴリが完全一致していないなどが考えられる。例えば、ISO/IECに採録された暗号方式や CAESAR プロジェクトに応募されていた暗号方式を基に改良された方式が NIST LWC に応募されているといった方式などがある。
2016 年度版ガイドラインに掲載されている SIMON と SPECK については、ISO/IECの軽量暗号のカテゴリで議論されていたが、結果として軽量暗号としては ISO/IEC 標
準規格として承認されず、自動認識・データキャプチャ技術に関する仕様で利用可能な軽量暗号方式として規格化されていること8が確認された。
評価指標に関して、安全性評価については、提案方式の設計根拠が十分に提示されない場合に第 3 者による評価が十分に行えないと判断され、評価対象から外されるな
どの事例があった。実装性能評価については、従来論文ごとに異なる環境や測定シナリオで示されることが多くあったが、近年は AES-GCM や SHA-256 など広く世界で利用されているアルゴリズムとの比較などにより統一的な測定フレームワークを用いて実施することが一般化されてきていることが分かった。

4. 外部評価報告書に対する暗号技術評価委員会の見解
外部有識者による評価報告書は、今年度に目的としていた調査対象の暗号方式に対して、安全性・実装性能・標準化動向の調査として十分な内容を含んでいると考えられることから、本報告書を CRYPTREC の技術調査報告書とすることを承諾した。

8[SIMON] ISO/IEC (JTC 1/SC31) 29167-21:2018 Information technology - Automatic identificationand data capture techniques - Part 21: Crypto suite SIMON security services for air interface
communications .(2018 年 10 月出版)
[SPECK] ISO/IEC (JTC 1/SC31) 29167-21:2018 Information technology - Automatic identificationand data capture techniques - Part 22: Crypto suite SPECK security services for air interface
communications. (2018 年 11 月出版)
(暗号技術評価委員会事務局調べ)

【参考】表 外部評価依頼先および依頼対象方式

資料３－９CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）及びCRYPTREC 暗号技術ガイドライン（高機能暗号）について
1. 背景
2020 年度第 2 回暗号技術検討会にて、暗号技術評価委員会の活動として、耐量子計
算機暗号ガイドラインを作成するために暗号技術調査ワーキンググループ(耐量子計算機暗号) を設置すること、並びに、高機能暗号ガイドラインを作成するために暗号技術調査ワーキンググループ(高機能暗号) を設置することが承認された。
2021 年度及び 2022 年度に、各ワーキンググループで検討及び執筆を進め、『CRYPTREC
暗号技術ガイドライン (耐量子計算機暗号)』及び『CRYPTREC 暗号技術ガイドライン(高機能暗号)』の案を作成した。（資料３－４、資料３－５、資料３－６、資料３－７
参照）

2. CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）及び CRYPTREC 暗号技術ガイドライン（高機能暗号）【承認事項】
各ワーキンググループで作成したガイドラインの案(資料３－５、資料３－７) を、『CRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）』及び 『CRYPTREC 暗号技術
ガイドライン（高機能暗号）』として NICT 及び IPA が策定・公開するにあたって、検討会として内容に問題がないことをご承認頂きたい。

資料４－１2022 度1.

暗号技術活用委員会活動報告

2022 年度の活動概要
1.1

活動目的

活用委員会では、情報システム全般のセキュリティ確保に寄与することを目的として、暗号の取り扱いに関する観点から必要な活動を行っている。
2022 年度は、CRYPTREC 暗号リスト改定に向け、利用実績に関する評価を行う。また、
2021 年度に引き続き、暗号鍵管理ガイダンスを作成する。

1.2

活動概要

今年度の活動概要は以下の通りである。
(1) 利用実績に関する評価
2022 年度は CRYPTREC 暗号リストの改定が予定されており、その際、推奨候補暗号リストから電子政府推奨暗号リストへの昇格にあたって利用実績に基づいた選定が行われることが決まっている。
そこで、IPA が実施する「暗号アルゴリズムの利用実績に関する調査」による調査結果に基づき、2021 年度に承認された利用実績による選定基準の下で利用実績に関する評価を行う。
(2) 暗号鍵管理ガイダンスの作成
暗号鍵管理ガイドラインの拡充を目的として、2021 年度に取りまとめた作業の進め方に基づき、暗号鍵管理ガイダンス WG にて暗号鍵管理ガイダンスを作成する。
(3) 暗号利活用のために作成すべきガイダンス候補の検討
暗号利活用のために作成すべきガイダンス候補を検討し、今後の執筆に向けた準備を
行う。

1.3

暗号技術活用委員会の委員構成及び開催状況

暗号技術活用委員会の委員構成は表 1-1 のとおりである。また、2022 年度に開催された暗号技術活用委員会での議案は表 1-2 のとおりである。

1

表 1-1 暗号技術活用委員会

委員構成

委員長 松本勉

横浜国立大学 教授

委員

上原

哲太郎

立命館大学

委員

垣内

由梨香

マイクロソフト株式会社 セキュリティプログラムマネージャー

委員

菊池

浩明

明治大学 教授

委員

佐藤

直之

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

委員

須賀

祐治

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

委員

田村

裕子

日本銀行 企画役補佐

委員

手塚

悟

慶應義塾大学 教授

委員

寺村

亮一

株式会社イエラエセキュリティ 執行役員

委員

松本

泰

セコム株式会社 IS 研究所

委員

三澤

学

三菱電機株式会社

委員

満塩

尚史

デジタル庁

委員

山口

利恵

東京大学 特任准教授

委員

渡邊

創

国立研究開発法人産業技術総合研究所 副研究センター長

教授

兼 高度解析部

部長

顧問

主席研究員

セキュリティアーキテクト（2023 年 3 月 31 日現在）

表 1-2 暗号技術活用委員会
回

メール

開催日

議案

2022 年 7 月 7 日⚫ 2022 年度暗号鍵管理ガイダンス WG 活動計画について～ 7 月 15 日
⚫
⚫
⚫
⚫
⚫

第一回

2022 年 8 月 4 日

第二回

⚫
⚫
2022 年 12 月 20 日
⚫
⚫

第三回

開催状況

2023 年 3 月 14 日

2022 年度暗号技術活用委員会活動計画について
暗号アルゴリズム利用実績調査の中間報告について
2022 年度暗号鍵管理ガイダンス WG 活動計画について
暗号鍵管理ガイダンス WG 進捗報告について
運用ガイドライン／ガイダンス候補について
暗号アルゴリズム利用実績調査の最終報告について
電子政府推奨暗号リスト掲載への推薦候補案について
暗号鍵管理ガイダンス WG 進捗報告について
運用ガイドライン／ガイダンス候補について⚫ 暗号鍵管理ガイダンス WG 活動報告
⚫ 運用ガイドライン／ガイダンス候補について⚫ 2022 年度暗号技術活用委員会活動報告案について

2

2.

成果概要
以下に成果概要の要約を記載する。詳細については、CRYPTREC Report 2022 暗号技術活用委員会報告1を参照されたい。
2.1

利用実績に関する評価

IPA が実施した暗号アルゴリズム利用実績調査の結果、及び 2021 年度に承認された利用実績に基づく選定基準（選定ルール）に基づき、現在の推奨候補暗号リストに掲載のアルゴリ
ズムのうち、電子政府推奨暗号リスト掲載への推薦候補案について検討・選定し、暗号技術検討会に推薦した。
【検討方針】IPA が実施した暗号アルゴリズム利用実績調査では、現在の推奨候補暗号リストに掲載のアルゴリズムのうち、EdDSA のみアンケートによる利用実績調査の対象外であった。
このため、「EdDSA」以外の「推奨候補暗号リスト」に掲載の暗号アルゴリズムについて
は「利用実績調査（考慮項目①～⑥）」結果に基づいて判定し、「EdDSA」については「利用実態確認（考慮項目②～⑤）」結果に基づいて判定することとした。

考慮項目

選定目安

採用実 以下のいずれかを満たす場合、昇格の検討対象績に含める。なお、採用実績は、⚫ 5 年ごとに実施予定の大規模アンケート調
査による「利用実績調査」⚫ 必要に応じて、事務局が（大規模アンケー
ト調査によらずに）情報収集する「利用実態確認」
により確認するものとする。

1① 利用実績調査の結果、電子政府推奨暗号リストに掲載されている（同一カテゴリの）暗号技術の採用実績と遜色がないことが確認された場合電子政府推奨暗号リスト掲載の（同一カテゴリの）暗号技術の採用実績
を同等以上の採用実績がある推奨候
補暗号リスト掲載の暗号技術を昇格検討対象とする。

② 利用実績調査又は利用実態確認の結果、電子政府システムや重要インフラ等、日本の基幹システムにおいてすでに利用されていることが確認された場合

必要に応じて、利用実績調査に代わって、各府省庁等への照会を実施
し、照会結果（クローズドな利用を含め）を基に昇格検討対象を選定する。

CRYPTREC Report 2022 暗号技術活用委員会報告, https://www.cryptrec.go.jp/promo_cmte.html

3利用実績調査又は利用実態確認の結果、③～⑤のいずれかが確認された場合：③ 利用者が多い主要な汎用製品群の複数に搭載されるなど、明らかに採用が進展していると判断された場合④ 利用者が多い主要なオープンソースソフト
ウェアの複数に搭載されるなど、明らかに採用が進展していると判断された場合⑤ 利用者が多い主要なサービスやプロトコルの複数で利用されるなど、明らかに採用が進展していると判断された場合「複数」「利用者が多い（主要な）」というキーワードの両方を十分に満たし、明らかな採用促進が確認された場合には、必要に応じて、昇格検討対象とする。
※「複数」の意味は、必要条件として「2 個以上が必要」ということであって、「2 個以上あればよい」という十分条件としての意味ではないことに留意

標準化 以下を満たす場合、昇格の検討対象に含める。
実績⑥ 利用実績調査の結果、電子政府推奨暗号リ 電子政府推奨暗号リスト掲載の（同
ストに掲載されている（同一カテゴリの） 一カテゴリの）暗号技術の採用実績
暗号技術の採用実績と遜色がないことが確 を同等以上の採用実績がある推奨候
認された場合補暗号リスト掲載の暗号技術は昇格検討対象とする。

【IPA が実施した暗号アルゴリズム利用実績調査2概要】
本調査では、電子政府推奨暗号リストに掲載する暗号アルゴリズムを選定するために、製品やシステム等で利用している暗号アルゴリズム名称を特定し、当該暗号アルゴリズムがどの程度利用されているか、またどの程度の標準化や規格化に採用されているかといった「暗号アルゴリズムの製品化、利用実績」を収集することを意図しております。また、政府機関
に対する調査、国際標準規格・民間規格に対する調査、オープンソースソフトウェアでの利用実績調査も併せて実施しております。
本調査は株式会社野村総合研究所に委託して実施しております。
調査対象(A) 応募暗号アルゴリズムの応募者に対するアンケート調査

調査実績⚫ 応募暗号アルゴリズムの応募会社全 8 社（16 アルゴリズム）から回答受領➢ アルゴリズム実績提供：11 アルゴリズム→ 調査(C)(D)(E)の情報として活用➢ 製品実績提供：4 アルゴリズム→ 調査(B)の情報として活用

IPA, 暗号アルゴリズムの利用実績に関する調査へのご協力のお願い,https://www.ipa.go.jp/security/ipg/crypt_usageperformance2

4

(B) 暗号アルゴリズムを搭載している
市販製品の販売会社への調査⚫ アンケート配布数：➢ 14 業界団体 2,535 社➢ 個別コンタクト 102 社➢ 調査パネル 23,747 名⇓⚫ アンケート回収数：合計 211 社 301 製品➢ 業界団体：2,535 社 → 65 社 114 製品➢ 個別：108 社 → 28 社 37 製品➢ (A)調査：4 社 4 製品
➢ 調査パネル：23,747 名 → 146 製品⇓⚫ アンケート有効回答数：➢ 合計 82 社 128 製品（利用アルゴリズム不明 19製品を含む）⇓(C) 日本の政府機関等に対する調査(D) 国際標準規格・民間規格等に対する調査(E) オープンソースソフトウェアでの利用実績調査⚫ 集計対象：合計 101 社 209 製品➢ アンケート有効回答：109 製品➢ 公開情報調査（補充調査）：41 社 100 製品⚫ アンケート集計数：
政府機関で利用されている 98 システム
⚫ 規格調査数：全 30 件
うち、暗号アルゴリズム記載ありは 17 件
⚫ 規格調査数：IPA が指定した 25 件⇓
⚫ 集計対象：合計 171 件➢ 別途追加分：146 件➢ EdDSA だけ独自調査実施⚫ OSS 調査数：IPA が指定した 30 件⇓
⚫ 集計対象：合計 30 件
➢ EdDSA だけ独自調査実施【電子政府推奨暗号リスト掲載への推薦候補案】⚫

エンティティ認証、ハッシュ関数、署名を除いた技術分類について：

技術分類

推薦候補

推薦しない候補理由

公 開 鍵 鍵共有
暗号

該当なし

PSEC-KEM⚫ 他の鍵共有と比較して優位な利用実績があるとは認められない

5

共 通 鍵 64 ビットブ 該当なし
暗号
ロック暗号

CIPHERUNICORN-E
Hierocrypt-L1
MISTY1⚫ 他の 64 ビットブロック暗号と比較して優位な利用実績があるとは認められない

128 ビットブ 該当なし
ロック暗号

CIPHERUNICORN-A
CLEFIA
Hierocrypt-3
SC2000⚫ 他の 128 ビットブロック暗号と比較して優位な利用実績があるとは認められないス ト リ ー ム 該当なし
暗号

Enocoro-128v2
MUGI
MULTI-S01⚫ 他のストリーム暗号と比較して優位な利用実績があるとは認められない認証暗号

ChaCha20Poly1305

該当なし⚫ 考慮項目①②④について、利用実績があると認められる

暗 号 利 秘匿モード
用 モ ー
ド

XTS

該当なし

⚫ 考慮項目①②④について、他の秘匿モードと比較して利用実績があると認められるメッセージ認証コード

該当なし

PC-MAC-AES⚫ 他のメッセージ認証コードと比較して優位な利用実績があるとは認められない⚫

エンティティ認証について：

技術分類

推薦候補

推薦しない候補

理由

エンティティ認証

ISO/IEC 9798-4

該当なし⚫ 考慮項目①②において、他のエンティティ認証と比較して利用実績があると認められる

推薦しない候補
該当なし

理由⚫ 考慮項目④において、他のハッシュ関数と比較して利用実績があると認められる⚫

ハッシュ関数について：
技術分類
推薦候補
SHA-512/256
ハッシュ関数
SHA3-256
SHA3-384
SHA3-512SHAKE128SHAKE256⚫

EdDSA について：

技術分類

推薦候補

推薦しない候補理由

公 開 鍵 署名
暗号

EdDSA

該当なし

⚫ 考慮項目④において、他の署名と比較して利用実績があると認められる

2.2

SC2000 の CRYPTREC 暗号リストからの取下げ申請への対応
6富士通株式会社から取下げ申請があった SC2000 について、審議の結果、暗号技術検討会
で CRYPTREC 暗号リストからの取下げルールを整備することを条件に、申請を了承するこ
ととした。

2.3

暗号鍵管理ガイダンスの作成

暗号鍵管理検討の初めとして、暗号鍵管理が必要なシステムの設計者向けに、暗号鍵管理の設計で明記する事項や考慮する点などを解説することを目的としたガイダンスである。本
ガイダンスの位置づけと想定読者は以下の通りとする。
位置づけ⚫

暗号鍵管理機能を持つシステム設計者のガイダンスを作成する。このガイダンスは2020 年に発行した「暗号鍵管理システム設計指針（基本編）」を詳しく解説することを中心に作成する⚫

暗号鍵管理で必要となる項目について、シンプルなモデルを例示し説明する⚫

シンプルなモデルを用いた説明においては、鍵管理における要求や思想が理解できるような記載を行う⚫

暗号鍵管理における特に注意すべきリスクを説明する

想定読者⚫

暗号鍵管理機能を持つシステム設計者

本ガイダンスは「暗号鍵管理システム設計指針（基本編）」で記載が求められる項目について検討する際の有用な副読本となることを目的として書かれたものであり、中でも、下図において、CKMS の利用環境に関わらず検討する必要がある項目のうちの【B】
、
【C】
、【D】に
該当する項目に関して、各検討項目についての解説・考慮点を具体的に説明している。また、これらの理解を助けるため、簡単なシステム（トイモデル）を具体的に取り上げ、そのシステムで設定された構成や運用条件などを踏まえた場合の各々の検討項目における記載例を提供している。

7

図

暗号鍵管理における目的別分類関係（「暗号鍵管理システム設計指針」より）

2022 年度版暗号鍵ガイダンスの章構成は以下のとおりである。
1. はじめに
2. 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策
3. 暗号アルゴリズムの選択
4. 暗号アルゴリズム運用に必要な鍵情報の管理
1 章では、イントロダクションとして、暗号鍵管理の重要性、及び本ガイダンスの位置づけについて説明している。
2 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用のための暗号
鍵管理オペレーション対策」における検討項目についての解説・考慮点を記載している。具
体的には、CKMS においてどのように暗号鍵が管理されるかを対象にしており、暗号鍵の生
成から廃棄までのライフサイクル全期間にわたって暗号鍵を管理するのに必要となる機能や運用方法を取り決める検討項目を取り扱っている。例えば、CKMS をどのような設計方針の下でどのように構築されるのかの高レベルの概要を整理し、それ以降に決めなければならな
い各項目ではここで決めた内容に矛盾するような内容で定めてはならないことの重要性を指8摘している。このほか、使用している暗号鍵の状態や遷移条件、実施する処理に関する管理機能や、鍵情報の保管、鍵確立、鍵情報の喪失、破損、危殆化などが発生したときの BCP 対策に求められる項目での解説・考慮点を説明している。また、簡単なモデル（トイモデル）
として S/MIME をモデルに取り上げ、記載例を示した。
3 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズムの選択」における検討項目についての解説・考慮点を記載している。具体的には、暗号アルゴリズムや鍵長を選択に関する重要なポイントの解説、特に CRYPTREC 暗号リスト（電子政府推奨暗号リスト）、暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準や暗号鍵設定ガイダンスを参考に選択することを推奨している。また、Web ブラウザをクライアントとするクライア
ント－サーバシステムをモデルにした記載例を示した。
4 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用に必要な鍵情報の管理」における検討項目についての解説・考慮点を記載している。ここでは、3 章で決定した暗号アルゴリズムを運用するときに必要な鍵情報の管理の説明、具体的には管理すべき全ての鍵を明確にし、その鍵とメタデータの保護方法についての解説・考慮点を記載している。また、関係者がアクセス可能な Web サーバシステムをモデルにして記載例を示した。

2.4

暗号利活用のために作成すべきガイダンス候補の検討

2023 年度以降に作成すべきガイドライン／ガイダンスの候補について、以下の視点を踏まえ、検討を行った。今回の議論を踏まえ、どのガイドライン／ガイダンスを作成するかを
2023 年度活動計画に反映することを決定した。
⚫

ガイドライン／ガイダンスの整理学
A. 以前から求められていた利用方法のガイドライン・ガイダンス：1)、2)、3)、8）、9）B. 設定・設計に関するガイドライン・ガイダンス：4)、12)
C. 啓発ガイダンス：5)、6)、7)、15)
D. 新しい利用方法のガイドライン・ガイダンス：10)、11)
E. 少し早い（2023 年度着手ではなくてもいい）かもしれないガイドライン・ガイダンス：13)、14)
F.
⚫

他団体との連携で作るといいかもしれないガイドライン・ガイダンス：16)、17)、18)
検討にあたっての視点➢ どのようなガイドライン／ガイダンスが求められているか➢ CRYPTREC がメインで作るのがよいか、それとも他の組織（IPA、業界団体など）がメインで／共同で作るのがよいか➢ 暗号技術の切り口メインで有用なガイドライン／ガイダンスになるか（暗号以外の部分がメインになったりしないか）
9⚫

候補に挙がったガイドライン／ガイダンスのテーマ

1

認証についてのガイダンス（特に二要素認証）

2

身元（本人）確認のためのガイダンス（例えば eKYC）

3

電子メールに関するガイドライン／ガイダンス4

クラウドにおける鍵管理ガイダンス

5

組込機器の開発における、暗号プロトコル（例：認証プロトコル）のパラメータ選定基準

6

経営層も含めた人達を対象にした、暗号技術の啓発ドキュメント

7

暗号の使い方に関するガイドライン（ガイダンス）

8

PKI ガイドライン（ガイダンス）

9

暗号化消去

10 DNS の暗号に関わるガイドライン（ガイダンス）
11 暗号資産12 e シール
13 API に関するガイドライン／ガイダンス
14 高機能暗号の標準化
15 耐量子計算機暗号のガイダンス
16 耐量子計算機暗号への移行に関するガイダンス
17 FIDO などの普及促進を促すガイダンス
18 リモート署名などの普及促進を促すガイダンス
19 暗号化消去などの普及促進を促すガイダンス
20 TLS 暗号設定ガイドラインのアップデート
21 運用ガイドラインやガイダンスに求められるニーズ／課題の整理

3.

今後に向けて「暗号鍵管理システム設計指針（基本編）」の【A】【E】【F】に対する検討項目についても、
引き続き、暗号鍵管理ガイダンス WG にて解説・考慮点を検討し、2022 年度版暗号鍵管理ガ
イダンスに追加していく予定である。
また、暗号利活用のために作成すべきガイダンス候補での議論を踏まえ、新たなガイドラ
イン／ガイダンス作成に着手する予定である。

10

資料４－２2022 年度
1.

暗号鍵管理ガイダンス WG 活動報告

2022 年度の活動内容と成果概要
1.1

活動内容

暗号鍵管理ガイダンス WG は、2021 年度に暗号鍵管理ガイダンスの作成するために活動を開始した。暗号鍵管理ガイダンスは、暗号鍵管理が必要なシステムの設計者向けに、暗号鍵管理の設計で明記する事項や考慮する点などを解説することを目的としたガイダンスである。
CRYPTREC では、情報システム設計者とシステム調達者が、暗号鍵管理システムを適切に扱うための支援を目的に活動をおこなっているが、本 WG では暗号鍵管理検討の初めとして、
上記目的のため暗号鍵管理ガイダンスを作成している。
暗号鍵管理ガイダンスの位置づけと想定読者は以下の通りとする。
位置づけ⚫

暗号鍵管理機能を持つシステム設計者のガイダンスを作成する。このガイダンスは2020 年に発行した「暗号鍵管理システム設計指針（基本編）」を詳しく解説することを中心に作成する⚫

暗号鍵管理で必要となる項目について、シンプルなモデルを例示し説明する⚫

シンプルなモデルを用いた説明においては、鍵管理における要求や思想が理解できるような記載を行う⚫

暗号鍵管理における特に注意すべきリスクを説明する

想定読者
⚫
1.2

暗号鍵管理機能を持つシステム設計者
暗号鍵管理ガイダンス WG の委員構成及び開催状況

暗号鍵管理ガイダンス WG の委員構成は表 1-1 のとおりである。また、2022 年度に開催された暗号鍵管理ガイダンス WG での審議概要は表 1-2 のとおりである。
表 1-1 暗号鍵管理ガイダンス WG
情報理工学部

委員構成

主査

上原

哲太郎

立命館大学

委員

漆嶌

賢二

GMO グローバルサイン株式会社 プロダクトマネジメント部 部長

委員

垣内

由梨香

Microsoft Corporation セキュリティ レスポンスチーム
セキュリティプログラムマネージャー

委員

菅野

哲

GMO サイバーセキュリティ by イエラエ株式会社
取締役 CTO of Development1

情報理工学科

教授

委員

菊池

浩明

明治大学 総合数理学部 先端メディアサイエンス学科 教授

委員

小林

浩二

パナソニック オートモーティブシステムズ株式会社
開発本部 プラットフォーム開発センター
セキュリティ開発部セキュリティ PF 開発課 係長

委員

須賀

祐治

株式会社インターネットイニシアティブ
セキュリティ本部セキュリティ情報統括室

シニアエンジニア

委員

西原

敏夫

シスコシステムズ合同会社 カスタマーエクスペリエンス
シニアセキュリティアーキテクト

委員

舟木

康浩

タレス DIS CPL ジャパン株式会社
クラウドプロテクション＆ライセンシング
データプロテクション事業本部 セールスエンジニアマネージャ

委員

満塩

尚史

デジタル庁 戦略・組織グループ セキュリティ危機管理チーム
セキュリティアーキテクト（2023 年 2 月 14 日現在）
表 1-2 暗号鍵管理ガイダンス WG

回

開催日

第一回

第二回

第三回

2.

開催状況

議案

2022 年7 月 21 日◼ 2022 年度 WG 活動計画の確認◼ 「暗号鍵管理システム（CKMS）の設計原理と運用ポリシー」の内容に関する審議◼ 「暗号アルゴリズム運用に必要な鍵情報の管理」の内容に関する審議◼ 「暗号鍵管理デバイスへのセキュリティ対策」の内容に関する審議2022 年
11 月 29 日◼ 暗号鍵管理ガイダンス作成方針の変更◼ 「暗号アルゴリズムの選択」に関する審議◼ 「暗号アルゴリズム運用に必要な鍵情報の管理」に関する審議◼ 「暗号アルゴリズム運用のための暗号鍵管理オペレーション対策」の内容に関する審議

2023 年2 月 14 日◼ 「暗号アルゴリズム運用のための暗号鍵管理オペレーション対策」の記載内容について◼ 「暗号アルゴリズムの選択」の記載内容について◼ 「暗号アルゴリズム運用に必要な鍵情報の管理」の記載内容について◼ 「はじめに」の記載内容について

成果概要
2.1

活動概要

本年度は表 1-2 のように WG を 3 回開催した。節ごとの記載内容について審議し、暗号鍵管理ガイダンスを作成した。
2

2.2

暗号鍵ガイダンスの構成の見直し
2021 年度 WG にて決定した執筆方針に基づき、想定読者を「暗号鍵管理機能を持つシス

テム設計者」「暗号鍵管理の参照プロファイル作成担当者」「暗号鍵管理プロファイルの利
用者／暗号鍵管理機能を持つシステム調達者」とし、「暗号鍵管理プロファイルを作成する
ためのガイダンス」とすることを目的として、作業を実施していた。しかしながら、これらの想定読者の皆に対して理解してもらおうと多くの恩恵や効用を記載した結果、各節ごとの記載内容に大きなブレが生じ、逆に本来伝えるべき人に伝えるべき内容が伝わらない状態になったと判断した。
このため、想定読者の範囲を見直して、「暗号鍵管理システム設計指針（基本編）」と同様、「暗号鍵管理機能を持つシステム設計者」に絞り込んだうえで、システム設計者に伝えるべき内容に整理し、記載内容を修正することとした。この変更作業に伴い、暗号鍵ガイ
ダンスの構成を見直し、2021 年度 WG にて決定した「暗号鍵管理システム設計指針（基本編）」に記載された章立てに沿った形での取りまとめではなく、関連性が強い部分をまとめた形に分割して取りまとめを行うこととした。具体的には、以下のように見直した。
なお、2022 年度に取りまとめを行わなかった部分については、2023 年度以降にも執筆を継続し、2022 年度版に補充していくものとする。
ガイダンス章構成（旧章構成）

見直し後

1. はじめに2022 年度発行

2. 概要説明（1 章に集約）

3. 暗号鍵管理システム（CKMS）
2023 年度以降の設計原理と運用ポリシー
4. 暗号アルゴリズム運用のための2022 年度発行
暗号鍵管理オペレーション対策
2022 年度発行

5. 暗号アルゴリズムの選択

6. 暗号アルゴリズム運用に必要な2022 年度発行
鍵情報の管理7. 暗号鍵管理デバイスへのセキュ
2023 年度以降
リティ対策
8. 暗号鍵管理システム（CKMS）
2023 年度以降のオペレーション対策
2.3 2022 年度版暗号鍵ガイダンスの概要
本ガイダンスは「暗号鍵管理システム設計指針（基本編）」で記載が求められる項目について検討する際の有用な副読本となることを目的として書かれたものであり、中でも、図1-1 において、CKMS の利用環境に関わらず検討する必要がある項目のうちの【B】、【C】、【D】に該当する項目に関して、各検討項目についての解説・考慮点を具体的に説明している。また、これらの理解を助けるため、簡単なシステム（トイモデル）を具体的に取り上3

げ、そのシステムで設定された構成や運用条件などを踏まえた場合の各々の検討項目における記載例を提供している。

図 1-1

暗号鍵管理における目的別分類関係（「暗号鍵管理システム設計指針」より）

2022 年度版暗号鍵ガイダンスの章構成は以下のとおりである。
1. はじめに
2. 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策
3. 暗号アルゴリズムの選択
4. 暗号アルゴリズム運用に必要な鍵情報の管理
1 章では、イントロダクションとして、暗号鍵管理の重要性、及び本ガイダンスの位置づけについて説明している。
2 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用のための暗号鍵管理オペレーション対策」における検討項目についての解説・考慮点を記載している。
具体的には、CKMS においてどのように暗号鍵が管理されるかを対象にしており、暗号鍵の生成から廃棄までのライフサイクル全期間にわたって暗号鍵を管理するのに必要となる
4

機能や運用方法を取り決める検討項目を取り扱っている。例えば、CKMS をどのような設計方針の下でどのように構築されるのかの高レベルの概要を整理し、それ以降に決めなけ
ればならない各項目ではここで決めた内容に矛盾するような内容で定めてはならないことの重要性を指摘している。このほか、使用している暗号鍵の状態や遷移条件、実施する処理に関する管理機能や、鍵情報の保管、鍵確立、鍵情報の喪失、破損、危殆化などが発生したときの BCP 対策に求められる項目での解説・考慮点を説明している。また、簡単なモデル（トイモデル）として S/MIME をモデルに取り上げ、記載例を示した。
3 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズムの選択」における検討項目についての解説・考慮点を記載している。具体的には、暗号アルゴリズムや鍵長を選択に関する重要なポイントの解説、特に CRYPTREC 暗号リスト（電子政府推奨暗号リスト）、暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準や暗号鍵設定ガ
イダンスを参考に選択することを推奨している。また、Web ブラウザをクライアントとするクライアント－サーバシステムをモデルにした記載例を示した。
4 章は、暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用に必要な鍵情報の管理」における検討項目についての解説・考慮点を記載している。ここでは、3 章で決定した暗号アルゴリズムを運用するときに必要な鍵情報の管理の説明、具体的には管理すべき全ての鍵を明確にし、その鍵とメタデータの保護方法についての解説・考慮点を記載している。また、関係者がアクセス可能な Web サーバシステムをモデルにして記載例を
示した。

3.

今後に向けて2023 年度以降も暗号鍵管理ガイダンス WG にて、2022 年度に取りまとめを行わなかった
残りの部分について検討・執筆を継続し、暗号鍵管理ガイダンスの内容を拡充していく。

5

資料４－３

暗号鍵管理ガイダンス概要

01章 はじめに
1.1 位置づけ⚫ 「暗号鍵管理システム設計指針（基本編）」で記載が求められる項目について検討する際の有用な副読本となることを目的⚫ CKMSの利用環境に関わらず検討する必要な項目のうちの【B】、【C】、【D】に該当する項目に関して、項目の概説及びその記載例を提供

1.2 想定読者⚫ 主としてCKMS設計者（暗号鍵管理システム
設計指針（基本編）での想定読者と同様）

1.3 構成⚫ 各章での検討項目についての解説・考慮点を示す⚫ 理解を助けるため、簡単なシステム（トイモデル）を具体的に取り上げ、そのシステムで設定された構成や運用条件などを踏まえた場合の各々の検討項目における記載例を示す⚫ ここでのトイモデルの構成や運用条件は、これらの内容と各々の検討項目における記載例との対応関係が“理解しやすくなる”ように設けたものであり、これらの内容を“推奨しているわけではない”ことに十分に注意

12章 暗号アルゴリズム運用のための暗号鍵管理オペレーション
対策
CKMS設計における、暗号鍵の生成から廃棄までのライフサイクル全期間にわたって暗号鍵を管理するのに必要となる機能や運用方法を取り決める⚫ 2.1 CKMS設計⚫ 2.2 暗号鍵のライフサイクル

CKMS設計の全体的な考え方の整理⚫ 2.3 暗号鍵のライフサイクル管理機能⚫ 2.4 鍵情報の保管方法⚫ 2.5 鍵情報の鍵確立方法

上記の考え方を実現するために必要となる機能要件や運用方法の明確化⚫ 2.6 鍵情報の喪失・破損時のBCP対策⚫ 2.7 鍵情報の危殆化時のBCP対策

BCP対策（例外運用方法）の明確化

2

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.1 KMCS設計／2.2 暗号鍵のライフサイクル）
2.1 CKMS設計① 暗号鍵を提供するためにCKMSをどのように構築するかの概要⚫ CKMSをどのような設計方針の下でどのように構築されるのかの高レベルの概要整理⚫ 次節以降に決める必要がある事項を検討する際に本概要で定めたことと矛盾していないことが確認できる程度に具体化した情報のことであり、次節以降では、本概要に記載したことに矛盾するような内容を定めてはならないことに注意⚫ CKMS設計としてどこまでの範囲を対象とするのかを決め、それに応じて境界を定める

2.2 暗号鍵のライフサイクル① 暗号鍵のライフサイクル全体にわたって取り得る鍵状態及び遷移条件の決定⚫ CKMS設計の観点からは、どのような状態が存在し、どのような条件によって状態遷移が起きるのかを明らかにする⚫ 本節で記載したことと次節での内容とが整合的であるようにしなければならないことに注意

3

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）
2.3 暗号鍵のライフサイクル管理機能① 鍵情報に対する管理のために実行される機能の全体像⚫ 暗号鍵のライフサイクル管理機能として②以降で対象となる機能を全て明記することによって、詳細を定めなければいけない項目に抜けが生じないようにする⚫ ライフサイクル管理機能が暗号鍵のライフサイクルを実現するための手段であるので、2.2節で記載したことと整合的であるようにしなければならない⚫ 鍵情報が誤った使い方をされていないことを確認② 鍵活性化機能への要求事項⚫ 活性化前状態から活性化状態への遷移を実現するための手順や遷移条件を具体化⚫ 2.2節で記載した活性化状態への遷移条件と整合的であるようにしなければならない③ 暗号機能の実行場所の特定⚫ 暗号機能が実行されるところでは必ず暗号鍵が平文の形で使われることになるため、暗号鍵が保管される場所と並んで、もっとも暗号鍵の危殆化が発生しやすい場所⚫ したがって、暗号機能がある場所や実行場所を把握しておくことで、暗号鍵が狙われるリスクを低減させるために重点的に対策・保護すべき場所の絞り込みに活用できる4

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）④ 鍵非活性化機能への要求事項⚫ どのような条件を満たしたときにどのような方法で非活性化状態に遷移するのかを決める⚫ CKMSセキュリティポリシーやCKMS設計などで最大許容暗号鍵有効期間が決まっている場合には、その最大期間と矛盾しないようにしなければならない⚫ システム上の要請などにより例外的に遷移条件の変更を容認する必要がある場合にはそのことを明確にしておくこと、例外がなし崩しにならないような明確な条件として定めておくことが重要⑤ 鍵失効機能への要求事項⚫ 暗号鍵の漏えいなどによる予期せぬ原因により、当該暗号鍵の安全性が担保できないと判断された場合に実行⚫ どのようなことが発生したら危殆化状態と見なすのかといった遷移条件と誰にどのように危殆化
状態に遷移した事実を知らせるのかといった通知方法などの要求事項を明確化⚫ 2.2節の危殆化状態への遷移条件と整合していなければならない⑥ 暗号鍵の一時停止機能及び再活性化機能への要求事項⚫ どのようなことが発生したら一時停止させるのかといった一時停止状態への遷移条件と、どのようなことが満たされたら解除するのかといった活性化状態への遷移条件を必ずセットで準備⚫ 2.2節の一時停止状態への遷移条件及び再活性化の遷移条件と整合していなければならない

5

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）⑦ 鍵情報の破壊機能への要求事項⚫ 暗号鍵の漏えいリスクを完全に排除するためには、当該暗号鍵が完全に存在しなくなった状況にするしかない⚫ バックアップやアーカイブされたものも含めて完全に存在しない状況にする必要がある⚫ バックアップやアーカイブしている場合で鍵の破壊を行うケースでは、鍵の破壊に関してB.20の記載内容とB.54やB.56の記載内容が整合していなければならない⚫ 誤って暗号鍵の破壊をしてしまうことがないようにしておくことも重要⑧ 鍵生成機能への要求事項⚫ 利用する暗号鍵が何らかの方法で予測できるのであれば、どんなに強力な暗号アルゴリズムを使っていたとしても安全性は担保されない⚫ 予測できない暗号鍵を生成する手段を利用することが極めて重要⑨ 鍵導出機能／鍵更新機能への要求事項⚫ 暗号鍵の予測可能性の観点でいえば、鍵生成機能を利用して生成される暗号鍵よりも予測がしやすくなっている可能性がある⚫ 信頼できる鍵導出方法や鍵更新方法を使うことで暗号鍵の予測可能性のリスクを低減している
ことの確認を行う
6

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）⑩ 対称鍵の検証機能への要求事項⑪ 公開鍵の検証機能への要求事項⚫ 生成されたり、共有されたりした暗号鍵が正当なものであることは、暗号アルゴリズムを利用する上での前提条件⚫ 確認を行うタイミングは、利用する暗号鍵の種類や利用方法、利用環境などによってさまざま⑫ トラストアンカー管理機能への要求事項⚫ 信頼できる第三者であるトラストアンカーを用意し、そのトラストアンカーが「信頼できるかわからない公開鍵」にお墨付きを与えることで「信頼できる公開鍵」にする仕組みが必要⚫ トラストアンカーが公開鍵の信頼性の起点となることを意味し、その信頼性のうえで公開鍵暗号・
署名の安全性が確保されている⚫ トラストアンカーの完全性確保は死活的に重要であり、そのための要求事項を明確化⑬ 公開鍵の有効期間延長機能への要求事項⚫ 有効期間が経過すると非活性化状態に自動的に遷移して当該公開鍵は失効し、また新しい公開鍵が鍵生成機能を使って生成されるのが一般的⚫ CKMSセキュリティポリシー等で定める公開鍵の最大許容暗号鍵有効期間は、セキュリティ上の要件として定められたものであるので、これに違反するような延長は認められないことに注意

7

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）⑭ 所有者登録機能への要求事項⚫ 登録時点で誤った所有者登録が行われてしまうと、誤ったエンティティと暗号鍵が結び付くことになり、その後の暗号鍵のライフサイクルが正しく実行されたとしても全く安全性が担保されない⑮ プライベート鍵所持の検証機能への要求事項⑯ プライベート鍵の検証機能への要求事項⚫ トラストアンカーが「信頼できるかわからない公開鍵」を「信頼できる公開鍵」として利用できるお墨付きを与えるためには、その公開鍵に対応する「正しい」プライベート鍵（及びそれに付随するメタデータ）を「正当な」エンティティが所有していることを確認する必要がある⚫ プライベート鍵は基本的に唯一のエンティティのみが秘密に所持することが求められるため、当該公開鍵に対応する「正しい」プライベート鍵（及び付随メタデータ）を「正当な」エンティティが所有していることを、トラストアンカーにその中身を直接示して証明するわけにはいかない⚫ プライベート鍵（及び付随メタデータ）（と称するデータ）を所持していることを「正しい」エンティティが所有していることを確認するための検証方法の明確化

8

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.3 暗号鍵のライフサイクル管理機能）⑰ 暗号鍵とメタデータの関連付け機能への要求事項⚫ 鍵タイプによってはメタデータとの組み合わせによりその暗号鍵の完全性を確保する場合もあり、そのようなタイプの暗号鍵ではメタデータの管理も安全な鍵情報の管理を実施するために重要⚫ 関連付けを提供する保護メカニズムには、暗号学的プロセスを使用する場合と信頼プロセスを使用する場合とがある⚫ 4章に記載された暗号鍵とメタデータの関連付けを行う上で必要となる機能が用意されているか、整合的であるかの観点で確認することが重要⑱ メタデータの変更機能への要求事項⑲ メタデータの削除機能への要求事項⑳ 暗号鍵のメタデータリスト化機能への要求事項⚫ メタデータの完全性に影響するような処理を行えるエンティティを制限し、かつ認可されたエンティティであっても許可された範囲内、例えば自分の管理下にあるメタデータに対してのみ変更
や削除、参照が行えるようにしておくことが望ましい

9

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.4 鍵情報の保管方法）
2.4 鍵情報の保管方法① 保管中の鍵情報のセキュリティを確保するための手段の決定⚫ 「格納権限がある信頼できるエンティティ（利用者）」によって「正しい暗号鍵」が「正しく保管」されることが重要。「格納権限がある信頼できるエンティティ（利用者）」であることを確認するための認証認可機能、「正しい暗号鍵」であることを確認するための完全性検証機能、対称鍵やプライベート鍵では秘密裏に「正しく保管」するための機密性保護機能が求められる⚫ 利用権限を有する正しいエンティティ（利用者）のみが保管された暗号鍵にアクセスできることを保証するためのアクセス制御機能・認証認可機能が求められる⚫ ストレージなどでの保管中も、誤操作や故障、改ざん攻撃などによって、暗号鍵の完全性が損なわれないように保護することが必要⚫ クラウドサービスを利用する場合の鍵情報のセキュリティ確保については、クラウド事
業者とクラウド利用者との責任分界点を認識し、それに応じて検討すべき範囲が変わることを記載10

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.4 鍵情報の保管方法）② 運用中の鍵情報の保管場所及び保護方法の決定⚫ 運用中の暗号鍵は、ストレージなどに保管された状態から読み込まれ、メモリ上などに保存された状態で暗号処理に使われるのが一般的。暗号処理のスループットを上げるため、暗号鍵が平文の形で置かれることが多く、暗号鍵の漏えいリスクが高い場所の一つになっている⚫ 暗号鍵の漏えいリスクの低減策として、運用中の暗号鍵がどこに存在し、どのように保護されているのかを把握しておくことが重要③ 鍵情報のバックアップ方法の決定⚫ バックアップを行うことによるメリットとデメリットを天秤にかけて、暗号鍵のバックアップを行うかどうかを決定することが重要⚫ できる限り、暗号鍵の複製を作ることによる漏えいリスクを低減する対策を検討する必要があり、そのためには具体的なバックアップの条件や実施方法などを取りまとめておくことが重要⚫ バックアップした暗号鍵が使用されることがなくなったとき、復元できないように破壊されるべき11

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.4 鍵情報の保管方法）④ 鍵情報のアーカイブ方法の決定⚫ バックアップもアーカイブも、暗号鍵の複製を作ることで漏えいリスクを高めることにつながるという点では同じであるが、バックアップが比較的頻繁に復元を行うことが想定されているのに対して、アーカイブは長期保管用ストレージ設備などに保管され、限定的な条件下でのみ復元されることが想定されている点が異なる⚫ アーカイブは、適用される法律や規則等も考慮して最小限の範囲で実施し、暗号鍵の複製を作ることによる漏えいリスクを低減する対策を検討する必要⚫ バックアップと比較して、復元頻度が少なく、長期保管が想定されることから、可用性よりも機密性保護を優先して対策を考えるべき⚫ アーカイブする必要がなくなれば、復元できないようにそのアーカイブは破壊されるべき⚫ アーカイブ鍵のほうが先に有効期間切れになった時に、機密性保護の継続性を確保するための要求事項を明確化⑤ 鍵情報の復元方法の決定⚫ 厳格な復元ルールを規定し、そのルールが全て満たされていることを検証された後に、認可されたエンティティ（利用者）によって復元できるようにすべき⚫ 実現されるセキュリティ水準は、バックアップやアーカイブで実現されるセキュリティ水準と整合的であることが重要
12

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.5 鍵情報の鍵確立方法）
2.5 鍵情報の鍵確立方法① 鍵確立機能の利用局面の特定⚫ 鍵確立が行われるタイミングは、「盗聴」という手段－すなわち、鍵確立に係る正当なエンティティに検知されない手段－で第三者が暗号鍵を窃取できる唯一のタイミング⚫ 鍵確立の方法として、鍵配送と鍵合意がある。

⚫ 鍵確立を行うとき、(i)確立される暗号鍵が誤りなく、正しく共有されること（暗号鍵の完全性）が求められるだけではなく、(ii)関係するエンティティが全員正当であることの確認と(iii)セキュアな通信路での通信による暗号鍵の機密性保護が極めて重要② 鍵配送における鍵情報のセキュリティを確保するための要求事項⚫ 全ての暗号鍵は完全性保護を、加えて対称鍵及びプライベート鍵は機密性保護も必要⚫ 機密性保護の観点からは、物理的保護が行われる手段か、対称鍵ラッピング鍵又はひとつ以上の非対称配送鍵ペアが関わる鍵配送手段を使用⚫ 完全性保護の観点からは、暗号鍵の送信者が信頼できることと、暗号鍵に改ざんやエラーがな
いことが求められる13

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.5 鍵情報の鍵確立方法）③ 鍵合意における鍵情報のセキュリティを確保するための要求事項⚫ 不正なエンティティに合意鍵を窃取されないためには認可されていないエンティティが鍵合意プ
ロセスに不正に入り込むことを防止することが絶対条件④ 鍵確認機能を利用するための要求事項⚫ 実際の暗号処理で利用する前に共有された暗号鍵を鍵確認することにより、何らかの理由で誤った暗号鍵が生成されたり、暗号鍵がうまく共有できなかったりした場合であっても、実害が発生する前に当該暗号鍵の利用を止めることが可能⑤ 利用する鍵確立プロトコルの決定⚫ セキュアなプロトコルであることが確認されたものだけを使うべき⚫ 「必ずしもセキュアとは言えないが相互接続性を実現するために必要」とされる手順や暗号アル
ゴリズムもデフォルトで選択できるようになっていることがあるので、意図せずに誤って利用することがないよう、CKMS設計の段階でデフォルトでは使えないように設定しておき、真に必要な場
合には「例外として意図的に設定変更する」ようにすることが重要⚫ 安全性と相互接続性のバランスを踏まえた推奨の設定ガイダンスが存在する場合にはその設定に従うことで、セキュアな鍵確立プロトコルを確保できる14

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.6 鍵情報の喪失・破損時のBCP対策）
2.6 鍵情報の喪失・破損時のBCP対策① 鍵情報の喪失・破損に対するBCP対策の決定⚫ 鍵情報（暗号鍵やメタデータ）が喪失又は破損した場合で、バックアップもアーカイブもされていなかった場合、当該暗号鍵で保護されているデータの喪失につながる可能性がある⚫ 重大な災害は、多数の運用中の鍵情報の喪失又は破損を一気に引き起こす可能性が高い⚫ 鍵情報の喪失や破損時のBCPを実現するためにどのような対策が必要かを検討し、その結果、

鍵情報のバックアップやアーカイブを行うこととした場合には、バックアップやアーカイブの方針をまず定める必要がある⚫ ここで定めたことはB.52～B.61（バックアップ方法／アーカイブ方法／復元方法）の上位規定として機能することから、B.52～B.61の内容はここでの内容に沿って設定されなければならず、また矛盾していないことを確認することが重要

15

2章 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策（2.7 鍵情報の危殆化時のBCP対策）
2.7 鍵情報の危殆化時のBCP対策① 暗号鍵の危殆化に対するBCP対策の決定② メタデータの危殆化に対するBCP対策の決定⚫ 暗号鍵が危殆化した場合には、利用を停止し、新しい暗号鍵に置き換えるとともに、すでに暗号処理（暗号化や署名生成）が行われた情報に対しては個別にその正当性の判断を行う⚫ 危殆化した暗号鍵の使われ方によっては、当該鍵で保護されたデータに対してだけでなく、他の多くの暗号鍵についても危殆化を連鎖的に引き起こす可能性があることに留意⚫ 暗号鍵が危殆化した場合にどの程度の他の暗号鍵に影響を与える可能性があるかを、暗号鍵ごとに把握しておき、さらにBCP対策として影響を受ける可能性がある暗号鍵の更新方法までを決めておく⚫ 危殆化の影響を小さくするために、使用するそれぞれの暗号鍵に対して適切な暗号鍵有効期間の設定や利用範囲の制限をすることで、暗号鍵の危殆化のリスクを低減することも重要③ 役員・従業員によるセキュリティ危殆化に対するBCP対策の決定⚫ 権限必要最小限ルールの徹底が重要であり、必要な人に必要な権限しか与えない、権限を悪用していないかを監査する、操作ログを隠蔽できないようにする、といった事前対策が重要⚫ 役員・従業員によるセキュリティ危殆化が発生した場合には、あらかじめ決められた情報セキュ
リティポリシー及びCKMS機能に基づいた回復手続きで対応・復旧することが重要

16

3章 暗号アルゴリズムの選択
CKMS設計では、要求される保護レベル（セキュリティ強度）を満たすように
暗号アルゴリズムと鍵長を決定しなければならない
セキュリティ強度

暗号アルゴリズムと鍵長

3.1 暗号アルゴリズムのセキュリティ① 要求される保護レベル（セキュリティ強度）に対応した暗号アルゴリズムの決定⚫ セキュリティ強度の決定では、扱う情報の資産価値、情報の機密性や完全性などのほか、該当システムの利用期間の終了年も重要な要因の一つ⚫ 具体的に必要なセキュリティ強度の決定にあたっては、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」又は「暗号鍵設定ガイダンス」を参考⚫ 資産価値が高い情報と評価されると、その情報を扱うシステムではより強いセキュリティが求められることがある

17

4章 暗号アルゴリズム運用に必要な鍵情報の管理
CKMS設計において管理すべき暗号鍵を漏れなく洗い出し、（2章で用意される機能や運用方法等を適切に組み合わせて）それらの暗号鍵を安全に管理していることを明確にする※ 鍵情報＝暗号鍵＋メタデータ⚫ 4.1 鍵情報の種類 ・・・ 暗号鍵とメタデータの説明⚫ 4.2 鍵情報の選択 ・・・ 暗号鍵の洗い出しと個々の暗号鍵に対する管理方法を明確化⚫ 4.3 鍵情報の保護方針 ・・・ 主にメタデータを対象とした保護方針が対象

4.1 鍵情報の種類⚫ 「暗号鍵管理システム設計指針（基本編）」に記載されている21種類の暗号鍵の鍵タイプを記載⚫ メタデータは、暗号鍵を適切に管理するために、その暗号鍵に関連付けられている情報。メタ
データの典型的な要素として23種類を記載

18

4章 暗号アルゴリズム運用に必要な鍵情報の管理（4.2 鍵情報の選択）
4.2 鍵情報の選択① CKMSが取り扱う全ての鍵タイプの利用用途及び生成手段、メタデータ、信頼関係、保護方針などの決定⚫ CKMS設計で明示的に選択や管理する必要がある全ての鍵（タイプ）が対象⚫ CKMS設計で明示的に選択や管理しておらず、プロトコルや製品仕様により内部処理として自動的に生成・使用される暗号鍵は基本的には含まない⚫ 製品やアプリケーション、システムが自動的に生成・使用される暗号鍵を「ブラックボックスとして使っている」という認識を持つことが重要⚫ 信頼性に確信が持てない暗号モジュールを使用している場合などは、可能であれば、内部の処理を調査し、暗号鍵の信頼性を確認することが望ましい⚫ 暗号鍵とメタデータが正しく関連付けられていることを保証するための方法を明確化し、利用用途や想定される脅威等を踏まえて必要なセキュリティ強度を提供する機能や方法を選択するこ
とが重要

19

4章 暗号アルゴリズム運用に必要な鍵情報の管理（4.3 鍵情報の保護方針）
4.3 鍵情報の保護方針① メタデータ要素内に含まれている情報の保護方法の決定⚫ 鍵タイプによってはメタデータとの組み合わせによりその暗号鍵の完全性を確保する場合もあり、そのようなタイプの暗号鍵ではメタデータの管理も安全な鍵情報の管理を実施するために重要⚫ 暗号鍵やメタデータ、信頼関係の保護方針を明確にすることで、鍵情報が安全に管理されていることを確認⚫ 保護手段として暗号メカニズムを使用している場合は、そこで利用している具体的な暗号アルゴ
リズムや鍵パラメタなどを明確化。信頼プロセスを使用している場合は、そこで利用している具体的なプロセスについての項目を明確化⚫ ここでの内容は、D.02、D.03での記載内容と整合していなければならない

20

2章でのトイモデル◼ メールの送信元認証をS/MIMEの署名付きメールで実現するシステム

CKMS設計範囲⚫ メールの署名生成と署名検証の処理⚫ 署名生成や署名検証に使う暗号鍵の管理⚫ 公開鍵証明書の発行処理※ メール送受信などを処理する通信モジュールは含まない※ CAは、外部のパブリックCAであり、CKMSには含まない

21

2章でのトイモデル

SP 800-57 Pt.1 Rev.5でのライフサイクル

トイモデルでのライフサイクル⚫ 有効期間前の活性化前状態、有効期間内の活性化状態、有効期間
後の非活性化状態に遷移（証明書の有効期限ベースに自動遷移）⚫ 実際に鍵が破壊されると破壊状態に遷移（手動）⚫ 署名プライベート鍵の危殆化が疑われる場合は危殆化状態に遷移⚫ 署名プライベート鍵が危殆化状態に遷移した場合、署名公開鍵も同時に危殆化状態に遷移⚫ 一時停止状態は設定しない⚫ これら以外の遷移条件は設定しない
22

2章でのトイモデル【運用条件】
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫

鍵生成はメール送信PCにおいて信頼できる方法で生成し、プライベート鍵はライフサイクル全般を通じてPC
外部に複製されることはない。【B.04, B.22, B23】
CAから公開鍵証明書を受信したときに、当該証明書の正当性を確認する。【B.27, B.28】
公開鍵証明書の有効期間が始まった鍵は自動的に活性化状態となる。【B.04, B.06, B.07】
署名の生成や検証は、メール送受信PCのメール管理部でのみ行う。【B.08】
署名付きメールを受信したとき、受信した公開鍵証明書の正当性を検証する。【B.04, B.27～B.29, B.36】
公開鍵証明書の有効期限切れした鍵は、自動的に非活性化状態になる。【B.04, B.09～B.11】
鍵の所有者が鍵を必要ないと判断したとき、手動で削除する。【B.04, B.20, B.21】
情報システム部を介してパブリックなCA局に署名を依頼することで、信頼できる証明書チェーンを構築し、基本的なトラストアンカー管理は更新機能などOSの機能より実現する。【B.04, B.05, B.29～B.32, B.37】
公開鍵証明書の運用管理は、情報システム部の担当者が行う。【B.12, B.33～B.35】
鍵の危殆化が疑われるときは失効処理を行う。【B.04, B.13, B.14】
鍵のバックアップ、アーカイブは行わない。【B.04】
鍵とメタデータの関連付けは公開鍵証明書により行う（暗号学的プロセス）。【B.38, B.39】
メタデータの変更・削除・リスト化は認めない。【B.11, B.33, B.40～B.43】
鍵の一時停止状態は設定しない。【B.04, B.15～B.19】
鍵導出機能や鍵更新機能は使用しない。【B.04, B.24, B.25】
対象鍵は使用しない。【B.04, B.26】

23

2章でのトイモデル【運用条件（続）】
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫

鍵情報の機密性保護や完全性保護は、OSのアクセスコントロールシステム（ACS: Microsoft Windowsの
ACL、Linuxのパーミッション機能）により保護する。【B.44, B.46, B.48】
ストレージに入力する鍵情報において、署名プライベート鍵は証明書の公開鍵とペアになっていることを確認し、メタデータは証明書の内容と一致することを確認する。【B.45】
OSのACSにより、基本的に鍵を生成したユーザ以外、鍵情報にアクセスできない。【B.49, B.51】
暗号鍵のバックアップとアーカイブは実施しない。【B.52～B.61】
保管していた鍵が使用できなくなった場合の復元手段は用意しない。【B.50】
保管された鍵を保護するために鍵ラッピング鍵や鍵ペアは使用しない。【B.47】
署名プライベート鍵と署名公開鍵の有効期間は、公開鍵証明書の有効期間とする。【B.73】
署名プライベート鍵が危殆化すると署名公開鍵も同時に危殆化したとみなす。【B.74, B.75】
特に、危殆化しやすいと想定できるメタデータ要素はない。【B.76～B.78】
役割を分離して権限を必要な範囲にしている。【B.79】
個々のメール利用者が使用するPCにおいて、使用しているOSのログ保存機能により、署名プライベート鍵のアクセスログを管理する。アクセスログはシステム管理者しか確認できない。【B.79, B.80】
情報システム部の公開鍵証明書発行依頼の担当者の公開鍵証明書発行依頼ログと操作ログがPC内に保存され、操作ログへのアクセスは情報システム部の管理者しかできない。【B.79, B.80】
鍵の危殆化が疑われるときは失効処理を行い、鍵を再生成し、証明書を再発行する。【B.81】

24

2章でのトイモデル【記載例】

B.01 a) 利用するそれぞれの鍵タイプ
B.04 ⚫ メール送信者PCの鍵生成機能により、署名プライベート鍵と署名公開
署名プライベート鍵、署名公開鍵
鍵を生成する。
b) 鍵が生成される場所と手段⚫ 公開鍵証明書の有効期間が開始したら、鍵活性化機能により、署名プ
鍵の生成はメール送信者のPCで行われる
ライベート鍵と署名公開鍵を活性化状態にする。
c) それぞれの鍵タイプとの信頼関係で使用されるメタデータ要素（4.1節⚫ メール送信者PCの暗号機能により、メールのドキュメントに署名する。
参照）⚫ メールを受信したら、メール送信者から送られてきたことを確認する
鍵の有効期間、親鍵（CAの署名公開鍵）、CAとの信頼関係ために、メール受信者PCの暗号機能により署名の完全性を確認する。
d) 鍵情報（暗号鍵やメタデータ）が存在しているそれぞれのエンティ⚫ 公開鍵の検証機能により、署名公開鍵に対する公開鍵証明書に対するティのストレージにおける、鍵情報（暗号鍵やメタデータ）の保護方法
完全性を確認し、公開鍵及びパラメタの検証を行う。
署名プライベート鍵はアクセスコントロールで保護される⚫ OSでのトラストアンカー管理機能により、ルートCAの公開鍵証明書をe) 配送時の鍵情報（暗号鍵やメタデータ）の保護方法
保管・管理する。情報の更新は、OS又はブラウザの自動アップデート
メール受信者に送信する公開鍵証明書はCAが署名しているにより実施する。
f) 鍵情報（暗号鍵やメタデータ）が配送され得る先となるエンティティ⚫ 公開鍵証明書の有効期間が終了したら、鍵非活性化機能により、署名の種類（例えば、ユーザ、ユーザデバイス、ネットワークデバイス）
プライベート鍵と署名公開鍵を非活性化状態にする。
公開鍵証明書はメールを送受信するユーザに配布⚫ 署名プライベート鍵と署名公開鍵は、破壊条件を満たした場合、破壊機能により、鍵を破壊する。
B.02 活性化前状態、活性化状態、危殆化状態、非活性化状態、破壊状態⚫ 署名プライベート鍵の危殆化が疑われるときは、鍵失効機能により、
B.03 ⚫ 署名プライベート鍵と署名公開鍵の鍵ペア生成後に活性化前状態に遷署名プライベート鍵の失効処理を行う。署名公開鍵についても同様の移（図2-6の①）処理を行う。
⚫ 証明書に記載された有効期間の開始時に活性化前状態から活性化状態⚫ 利用者の管理は情報システム部が行うものとし、そのために必要な管に遷移（図2-6の④）
理機能は情報システム部管理の機器により実現する。
⚫ 活性化状態に遷移前に署名プライベート鍵に問題が生じた場合は、活⚫ 暗号鍵とメタデータの検証及び関連付けについては、公開鍵証明書の性化前状態から破壊状態へ遷移（図2-6の②）
申請段階で情報システム部がその正当性を検証するものとし、そのた⚫ 有効期限の終了時に活性化状態から非活性化状態に遷移（図2-6の⑧）めに必要な管理機能は情報システム部管理の機器により実現する。
⚫ 鍵の破壊条件を満たした場合に非活性化状態から破壊状態に遷移（図B.05 ⚫ 署名公開鍵と関連メタデータの完全性は、公開鍵証明書のCA署名検証
2-6の⑭）
により確認する。
⚫ 活性化状態に遷移後に署名プライベート鍵の危殆化が疑われる事象が⚫ 署名プライベート鍵の機密性は、OSのファイルアクセス機能により当発生した場合は、活性化状態又は非活性化状態から危殆化状態に遷移
該鍵を作成したユーザ以外が鍵ファイルにアクセスできないように管（図2-6の⑥⑬）。署名公開鍵も同時に危殆化状態に遷移させる
理することで実現する。
⚫ 証明書失効リスト（CRLリスト）に記載された署名公開鍵は危殆化状⚫ CAの署名公開鍵はOSの信頼できる公開鍵証明書（トラストアンカー）態に遷移（図2-6の⑥⑬）からなるチェーンの有効性により完全性を確認する。
⚫ 危殆化処理完了時に破壊状態に遷移（図2-6の⑮）⚫ OSの信頼できる公開鍵証明書（トラストアンカー）の更新は、OS又はブラウザの自動アップデートにより実行される。
注）本システムでは、図2-5の③⑤⑦⑨⑩⑪⑫の遷移は設定しない。

25

3章でのトイモデル◼ Webブラウザをクライアントとするクライアント－サーバシステム【運用条件】⚫

該当システムは2023年から8年間使用し2031年末破棄する予定 ⇒ 必要なセキュリティ強度は128ビット⚫

「TLS暗号設定ガイドライン」の「高セキュリティ型での暗号スイート推奨設定（TLS1.3限定）」に従って設定⚫

サーバ証明書での署名方式はECDSA（P-256）、ハッシュ関数はSHA-256を使用

26

4章でのトイモデル◼ 関係者のみがアクセス可能なWebサーバシステム【運用条件】⚫
⚫
⚫
⚫
⚫
⚫

Webサーバは、OSにLinux、Webサーバ機能を実現するソフトウェアにApache HTTP Server、TLS 1.3を実現するソフトウェアにOpenSSLを使用
セキュリティプロトコルとしてTLS 1.3だけを許可
サーバ証明書の署名方式はECDSA（P-256）を使用
鍵交換（鍵合意）のECDHはX25519, X448, P-256, P-386, P-521を使用
プライベート鍵の保護のためにroot権限でプライベート鍵ファイルを保存（信頼プロセスを利用）
暗号学的プロセスはデジタル署名を利用して公開鍵やメタデータの完全性を保護
27

資料４－４

暗号鍵管理ガイダンス（2023 年 3 月 24 日版）

目次
1

はじめに ................................................................................................................... 2

1.1

位置づけ ........................................................................................................................... 2

1.2

想定読者 ........................................................................................................................... 5

1.3

構成 ................................................................................................................................... 5

1.4

検討体制 ........................................................................................................................... 62

暗号アルゴリズム運用のための暗号鍵管理オペレーション対策 ................................ 7

2.1

CKMS 設計 ....................................................................................................................... 7

2.2

暗号鍵のライフサイクル ................................................................................................ 12

2.3

暗号鍵のライフサイクル管理機能 .................................................................................. 16

2.4

鍵情報の保管方法 ........................................................................................................... 39

2.5

鍵情報の鍵確立方法 ....................................................................................................... 48

2.6

鍵情報の喪失・破損時の BCP 対策 ................................................................................ 52

2.7

鍵情報の危殆化時の BCP 対策 ....................................................................................... 543

暗号アルゴリズムの選択 ......................................................................................... 60

3.1

暗号アルゴリズムのセキュリティ .................................................................................. 60

4暗号アルゴリズム運用に必要な鍵情報の管理 ......................................................... 66

4.1

鍵情報の種類 .................................................................................................................. 66

4.2

鍵情報の選択 .................................................................................................................. 73

4.3

鍵情報の保護方針 ........................................................................................................... 80

1

1 はじめに
1.1

位置づけ

企業や個人の管理する情報を保護するために暗号アルゴリズムが広く利用されている。各暗号
アルゴリズムは、それぞれの情報が必要とする機密性、完全性、認証を提供する目的で利用される。
デジタル庁と総務省、経済産業省は、暗号技術に関する有識者で構成される CRYPTREC 活動
を通して、電子政府で利用される暗号技術の評価を行っており、2023 年 3 月に「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗号リスト）」を改定した。CRYPTREC
暗号リストは、安全性、実装性能及び市場における利用実績を踏まえ、「電子政府推奨暗号リスト」、「推奨候補暗号リスト」及び「運用監視暗号リスト」で構成される。
CRYPTREC 暗号リスト（電子政府推奨暗号リスト）：
https://www.cryptrec.go.jp/list.html
実際、「政府機関の情報セキュリティ対策のための統一基準（令和 3 年度版）1」（令和 3 年 7 月
7 日、サイバーセキュリティ戦略本部。以下、「統一基準」という）では、政府機関における情報システムの調達及び利用において、図 1-1 の通り、CRYPTREC 暗号リストのうち「電子政府推奨暗号リスト」に記載された暗号アルゴリズムを原則的に利用するように記載されている。このように、セキュアな暗号アルゴリズムの選択に関しては電子政府推奨暗号リストを活用する等により、比較的容易に満たすことができる。
しかしながら、実際のシステムがセキュアに動作し続けるためには暗号アルゴリズム自体がセキュアであるだけでは不十分である。統一基準でも暗号鍵の管理手順を定めることになっている
ように、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要がある。もし、暗号鍵がセキュアに管理されていなければ、管理が不十分な点を悪用した何らかの手段で暗号鍵が漏えいする可能性があり、その漏えいした暗号鍵を使ってシス
テムへの侵入、機密データの窃取や改ざん、なりすましなどが行われる。
一般に、暗号鍵管理の脆弱性を突く攻撃方法のほうが、セキュアな暗号アルゴリズム自体を解読するよりもはるかに容易な攻撃方法である。また、漏えいまでは至らなくても、暗号鍵にデー
タ不整合等が発生すればシステムエラーの原因となり、業務が停止するなどの悪影響が発生する場合もある。実際、セキュアな暗号アルゴリズムを利用していても、不十分な暗号鍵管理が原因となっている数多くのインシデントが発生している。

1

内閣サイバーセキュリティセンター（NISC）, https://www.nisc.go.jp/pdf/policy/general/kijyunr3.pdf

2

6.1.5 暗号・電子署名
遵守事項(1) 暗号化機能・電子署名機能の導入(a) 情報システムセキュリティ責任者は、情報システムで取り扱う情報の漏えいや改ざん等を防ぐため、以下の措置を講ずること。
（略）(b) 情 報 シ ス テ ム セ キ ュ リ テ ィ 責 任 者 は 、 暗 号 技 術 検 討 会 及 び 関 連 委 員 会（CRYPTREC）により安全性及び実装性能が確認された「電子政府推奨暗号リスト」を参照した上で、情報システムで使用する暗号及び電子署名のアルゴリズム並びにそれを利用した安全なプロトコル及びその運用方法について、以下の事項を含めて定めること。
(ア) 職員等が暗号化及び電子署名に対して使用するアルゴリズム及びそれを利用した安全なプロトコルについて、「電子政府推奨暗号リスト」に記載された暗号化及び電子署名のアル ゴリズムが使用可能な 場合には、それを使用 させること。
(イ) 情報システムの新規構築又は更新に伴い、暗号化又は電子署名を導入する場
合には、やむを得ない場合を除き、「電子政府推奨暗号リスト」に記載されたア
ルゴリズム及びそれを利用した安全なプロトコルを採用 すること。
(ウ) 暗号化及び電子署名に使用するアルゴリズムが危殆化した場合又はそれを利用した安全なプロトコルに脆弱性が確認された場合を想定した緊急対応手順を定めること。
(エ) 暗号化された情報の復号又は電子署名の付与に用いる鍵について、管理手順を定めること。
（以下、略）
図 1-1

政府機関の情報セキュリティ対策のための統一基準（抜粋）

さらに、暗号鍵管理はうまく利用すると、大規模なデータ管理をセキュアに実現することも可能になる。例えば、クラウドサービスなど、外部の第三者にデータを預ける場合であっても、 それらのデータを暗号化し、そのときの暗号鍵管理を利用者側が実施することで、クラウドサービ
ス事業者に対しても機密性を維持できる。また、データセンタや大規模な記録メディアなどに保存されたデータで、物理的な破砕によるデータの完全削除を実現することが困難なケースでは、
暗号鍵の破壊によって当該鍵で暗号化されたデータを事実上復号できなくすることでそれらのデータが完全に削除されたとみなす暗号化消去（Cryptographic Erase）といった方法を実現することもできる。
このような背景のもと、CRYPTREC では暗号鍵管理に関するガイドライン／ガイダンスを作成している。

3

⚫

暗号鍵管理システム設計指針（基本編） 2⚫

暗号鍵設定ガイダンス 3⚫

暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準 4

このうち、「暗号鍵管理システム設計指針（基本編）」は、暗号鍵管理システム（以下、「CKMS(Cryptographic Key Management System)」という）を設計・構築・運用する際に参考すべきドキュメントとして作成されたものであり、「暗号鍵管理についての技術的内容」について解説している。具体的には、あらゆるユースケースにおける暗号鍵管理を安全に行うための構築・運用・
役割・責任等に関する対応方針として考慮すべき事項一覧を提供し、CKMS 設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を示している。これは、CKMS の包括的な設計指針であり、CKMS 設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を列挙した NIST SP800-130「A Framework for Designing Cryptographic Key Management
Systems」をベースに作成されている。

図 1-2

2
3
4

暗号鍵管理における目的別分類関係（「暗号鍵管理システム設計指針」より）

https://www.cryptrec.go.jp/report/cryptrec-gl-3002-1.0.pdf
https://www.cryptrec.go.jp/report/cryptrec-gl-3003-1.0.pdf
https://www.cryptrec.go.jp/list/cryptrec-ls-0003-2022.pdf

4

本ガイダンスは、本設計指針で記載が求められる項目について検討する際の有用な副読本となることを目的として書かれたものである。中でも、図 1-2 において、CKMS の利用環境に関わらず検討する必要がある項目のうちの【B】、【C】、【D】に該当する項目に関して、項目の概説及びその記載例を提供している。これらの項目は「狭義」の意味での暗号鍵管理に相当するものである。CKMS を設計する場合だけでなく、暗号アルゴリズムを使ったアプリケーション等を利用する場合なども含めて、全ての暗号鍵管理に対して検討が必要となる項目であることに留意されたい（ちなみに、【E】や【F】までを含む場合、「広義」の意味での暗号鍵管理を称す）。

1.2

想定読者

暗号鍵管理システム設計指針（基本編）での「暗号鍵管理についての技術的内容」での想定読者と同様、主として CKMS 設計者を想定読者としている。

1.3

構成

本設計指針は、4 章で構成されており、章立ては以下のとおりである。
2 章は「暗号アルゴリズム運用のための暗号鍵管理オペレーション対策」における項目についての解説・考慮点を示す。さらに、これらの理解を助けるため、簡単なシステム（トイモデル）
を具体的に取り上げ、そのシステムで設定された構成や運用条件などを踏まえた場合の各々の項目における記載例を示す。
【トイモデルにおける注意】
ここでのトイモデルの構成や運用条件は、これらの内容と各々の項目における記載例との対応関係が“理解しやすくなる”ように設けたものであり、これらの内容を“推奨しているわけではない”ことに十分に注意されたい。
同様に、3 章では「暗号アルゴリズムの選択」における項目についての解説・考慮点を記載し、トイモデルでの記載例を示す。
4 章では、「暗号アルゴリズム運用に必要な鍵情報の管理」における項目についての解説・考慮点を記載し、トイモデルでの記載例を示す。
なお、本ガイダンスは、暗号鍵管理システム設計指針（基本編）と合わせて利用することを想定している。また、「暗号鍵管理システム設計指針（基本編）チェックリスト 5」を利用する際に有用である。

5

IPA, https://www.ipa.go.jp/security/vuln/ckms.html

5

1.4

検討体制

本ガイダンスは、2021 年度及び 2022 年度 CRYPTREC 暗号鍵管理ガイダンス WG において作
成された。
表 1-1

暗号鍵管理ガイダンス WG の構成（2023 年 3 月時点）

主査

上原

哲太郎

立命館大学

情報理工学部

情報理工学科委員

漆嶌

賢二

GMO グローバルサイン株式会社

委員

垣内

由梨香

Microsoft Corporation

教授

プロダクトマネジメント部 部長

セキュリティ レスポンスチーム

セキュリティプログラムマネージャー
委員

菅野

哲

GMO サイバーセキュリティ by イエラエ株式会社
取締役 CTO of Development

委員

菊池

浩明

明治大学

委員

小林

浩二

パナソニック オートモーティブシステムズ株式会社
開発本部

総合数理学部

先端メディアサイエンス学科

教授

プラットフォーム開発センター

セキュリティ開発部セキュリティ PF 開発課 係長
委員

須賀

祐治

株式会社インターネットイニシアティブ
セキュリティ本部セキュリティ情報統括室

委員

西原

敏夫

シスコシステムズ合同会社

シニアエンジニア

カスタマーエクスペリエンス

シニアセキュリティアーキテクト
委員

舟木

康浩

タレス DIS CPL ジャパン株式会社
クラウドプロテクション＆ライセンシング
データプロテクション事業本部 セールスエンジニアマネージャ

委員

満塩

尚史

デジタル庁 戦略・組織グループ
セキュリティアーキテクト

6

セキュリティ危機管理チーム

2 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策
本章の目的・趣旨
本章は、設計指針（基本編）の 5 章に記載されている要求事項（各節での色付き枠内で示している内容）について解説したものである。
CKMS においてどのように暗号鍵が管理されるかを記載するものであり、「狭義」の意味での暗号鍵管理に相当するものである。暗号鍵の生成から廃棄までのライフサイクル全期間にわたって暗号鍵を管理するのに必要となる機能や運用方法を取り決める項目（B.01～B.81）を集めている。ここには、主に以下のような項目を含んでいる。
⚫ 各暗号鍵は、どのような処理を目的として使われるのか。
⚫ それら暗号鍵の保管場所や保管方法⚫ 各暗号鍵の生成から廃棄までのライフサイクルを通し、暗号鍵がどのように管理されるか。またその管理を行う上で必要となる機能群はどのようなものか。
CKMS を設計する場合だけでなく、暗号アルゴリズムを使ったアプリケーション等を利用する場合なども含めて、全ての暗号鍵管理に対して検討が必要となる項目であることに留意されたい。

2.1

CKMS 設計①

暗号鍵を提供するために CKMS をどのように構築するかの概要

項目

FR 番号 Framework Requirements の内容

B.01 FR2.4

CKMS 設計は、以下を含む CKMS システムの高レベルの概要を明記しなければならない：
a)

利用するそれぞれの鍵タイプb)

鍵が生成される場所と手段c)

それぞれの鍵タイプとの信頼関係で使用されるメタデータ要素（7.1 節表 7 2 参照）d)

鍵情報（暗号鍵やメタデータ）が存在しているそれぞれのエン
ティティのストレージにおける、鍵情報（暗号鍵やメタデー
タ）の保護方法e)

配送時の鍵情報（暗号鍵やメタデータ）の保護方法f)

鍵情報（暗号鍵やメタデータ）が配送され得る先となるエンテ
ィティの種類（例えば、ユーザ、ユーザデバイス、ネットワー
クデバイス）

7

SP800-130
2.5 節

解説・考慮点
項目 B.01 は、CKMS の設計にあたって、暗号鍵を提供するために CKMS をどのように構築す
るかの概要を明確化することを要求したものである。ここでは、機微なデータを保護するための暗号鍵に対する設計方針や実現目標、詳細を決める文書へのインデックス等を簡潔な概要で明記することが求められる。
本節で要求していることは、CKMS をどのような設計方針の下でどのように構築されるのかの
高レベルの概要を整理し、明らかにしておくことである。ここでの「高レベルの概要」の意味は、次節以降に決める必要がある事項を検討する際に本概要で定めたことと矛盾していないことが確認できる程度に具体化した情報、ということである。
CKMS 設定の詳細については次節以降で取り扱うことになるので、ここであまり詳細に定める必要はない。
重要なことは、安全な CKMS 設計の第一歩として、B.01 において少なくとも以下のような事項を検討し、明らかにしておくことで、次節以降で詳細を定めなければいけない項目に抜けが生じないようにすることである。また、ここでの概要は CKMS の基本設定となるものであるので、次節以降では、本概要に記載したことに矛盾するような内容を定めてはならないことに注意する必要がある。
⚫ a）と c）では、「どのような種類」の暗号鍵（及びそれに付随するメタデータ）を保護管理対象とする必要があるのかの把握⚫ b）では、暗号鍵が「どのように生成」されるのかの概要把握⚫ d）と e）では、暗号鍵が「どのような場所でどのように保護」されるのかの概要把握⚫ f）では、暗号鍵を「誰」が所持したり利用したりするのかの特定
その際、注意する必要があるのは、CKMS 設計としてどこまでの範囲を対象とするのかであり、それに応じて境界を定めることである。この範囲は、CKMS が取り扱う目的や設置場所、利用するエンティティやアプリケーション、プロトコルなどにより異なる。
例えば、図 2-1 のようなシステム（System A、System B、System C）間で、暗号鍵管理を含む暗号処理全体を担う各々の CKMS モジュールを経由して暗号通信をするプロトコルを利用するシステムを対象とした場合、CKMS 設計の対象範囲はシステム内での全ての CKMS モジュール（図 2-1 では CKMS Module A、CKMS Module B、CKMS Module C）の和集合、及び個々の
CKMS モジュールと連携して動作する機器類やそのモジュールを利用するエンティティなどから構成される。一方、System A 内部に閉じたデータ保管を対象とした場合には、CKMS 設計の対象範囲は System A の CKMS モジュール（図 2-1 では CKMS Module A）、及び当該 CKMS モ
ジュールと連携して動作する機器類やそのモジュールを利用するエンティティなどだけとなる。
この範囲を正しく定めておかなければ、本来管理対象とすべき暗号鍵が対象から漏れ、必要な対策が取られなかったり、逆に、不必要に多くの暗号鍵が管理対象となり、無駄な対策を実施することで余分なコストがかかったり利便性が低下したり、といった問題が生じることとなることに留意されたい。
8図 2-1CKMS 概要例（NIST SP 800-130 より）《トイモデルと記載例》
本節のトイモデルは、図 2-2～図 2-4 に示す、メールの送信元認証を S/MIME の署名付きメールで実現するシステムとする。
このシステムの CKMS 設計範囲は、図 2-2 の通り、メールの署名生成と署名検証の処理、署名生成や署名検証に使う暗号鍵の管理、公開鍵証明書の申請処理である。メールの送受信などを処理する通信モジュールは含まない。また、CA は外部のパブリック CA であり、これも CKMS には含まない。
準備として、図 2-3 の通り、メール送信者は、メール管理部において、信頼できる手段で署名
プライベート鍵と署名公開鍵のペアを作成する。次いで、その署名公開鍵の CSR（証明書署名要求; Certificate Signing Request）を作成し、その CSR を組織内の情報システム部に送る。情報システム部は、証明書管理部において、CSR を確認し、確認後に CSR をパブリック CA に送り、CA が署名した公開鍵証明書を情報システム部が受信し、確認後にその公開鍵証明書をメール送
信者に送信する。なお、CKMS の対象範囲はメール送受信 PC のメール管理部と情報システム部の証明書管理部だけであるので、図 2-3 での色が塗られた部分が該当する。
メールの署名と検証は図 2-4 の通りであり、メール送信者は、メール送信 PC のメール管理部
において、送信するドキュメントのハッシュ値を計算し、そのハッシュ値に自分の署名プライベ
ート鍵を使って署名し、ドキュメント、署名、自分の署名公開鍵の公開鍵証明書をメールで送信する。
9メール受信者は、メール受信 PC のメール管理部において、(a)メール送信者の公開鍵証明書が有効であることを CA 証明書を使って確認し、(b)受信したメールからドキュメントを取り出し、ハッシュ値を計算し、その値とメール送信者の公開鍵証明書から取り出した公開鍵で署名が正し
いか検証し、メール送信者から送られたメールであることを確認する。
なお、CKMS の対象範囲はメール送受信 PC のメール管理部となるので、図 2-4 での色が塗られた部分が該当する。また、パブリック CA は CKMS の対象範囲外としているので、CA が使う
署名プライベート鍵や対応する署名公開鍵は CA が適正に管理していることを前提とし、その前提に問題がないことだけを CA 証明書によって確認する。

図 2-2

トイモデルでの CKMS 概要図

図 2-3

鍵生成、CSR 送信、証明書受信10図 2-4

メールの署名と検証

以上のトイモデルにおける記載例は、以下の「署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例」のようになる。
署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.01

a)

利用するそれぞれの鍵タイプ
署名プライベート鍵、署名公開鍵b)

鍵が生成される場所と手段
鍵生成はメール送信者の PC で行われる

c)

それぞれの鍵タイプとの信頼関係で使用されるメタデータ要素（4.1 節参照）
鍵の有効期間、親鍵（CA の署名公開鍵）、CA との信頼関係d)

鍵情報（暗号鍵やメタデータ）が存在しているそれぞれのエンティティのストレー
ジにおける、鍵情報（暗号鍵やメタデータ）の保護方法
署名プライベート鍵はアクセスコントロールで保護されるe)

配送時の鍵情報（暗号鍵やメタデータ）の保護方法
メール受信者に送信する公開鍵証明書は CA が署名しているf)

鍵情報（暗号鍵やメタデータ）が配送され得る先となるエンティティの種類（例えば、ユーザ、ユーザデバイス、ネットワークデバイス）
公開鍵証明書はメールを送受信するユーザに配布

11

2.2

暗号鍵のライフサイクル①

暗号鍵のライフサイクル全体にわたって取り得る鍵状態及び遷移条件の決定

項目

FR 番号 Framework Requirements の内容

B.02 FR6.15

CKMS 設計は、CKMS の鍵が取り得る全ての状態を明記しなければ

SP800-130
6.3 節

ならない。
B.03 FR6.16

CKMS 設計は、全ての CKMS 鍵状態間の遷移、及び遷移を起こすこ

6.3 節とに関係するデータ（入力と出力）を明記しなければならない。

解説・考慮点
暗号鍵のライフサイクルの一般形は、SP 800-57 part1 の 7 節「鍵状態と遷移（Key States andTransitions）」に基づく。これをベースに、CKMS とそのアプリケーションに適切な鍵状態と遷移条件を選択し定義する。
項目 B.02 及び B.03 は、CKMS の設計にあたって、暗号鍵のライフサイクル全体を対象に定義した全ての鍵状態及び遷移条件を明確化することを要求したものである。ここで定義した鍵状
態及び遷移条件を管理・実行するために必要な全ての管理機能を次節以降で規定することが求められる。
暗号鍵は、生成から破壊までの間（ライフサイクルという）にいくつかの状態を経由することとなる。これらの状態に応じて暗号鍵は異なる方法で使用される（又は使用が禁止される）ので 、
CKMS 設計の観点からは、どのような状態が存在し、どのような条件によって状態遷移が起きるのかを明らかにしておく必要がある。
項目 B.02 及び B.03 は、CKMS の設計にあたって、そのような暗号鍵のライフサイクル全体を対象に全ての鍵状態及び遷移条件を明確化することを要求したものである。その際、B.02 では、
項目 B.01 で記載した暗号鍵が遷移する必要がある全ての状態を含まなければならない。
また、遷移の処理は次節でのライフサイクル管理機能により実現され、遷移条件に基づいて暗号鍵の状態がコントロールされるようにしなければならないので、B.02 及び B.03 で記載したことと次節での内容とが整合的であるようにしなければならないことに注意する必要がある。
暗号鍵の状態及び遷移の詳細については、NIST SP800-57 Part1 Rev5 6の第 7 章を参照された
い。図 2-5 にその概要を記す。

6

https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
日本語訳：https://www.ipa.go.jp/files/000090943.pdf

12

【遷移】


正常な遷移：①→④→⑧→⑭



それ以外はすべて何らかの異常による遷移
図 2-5

⚫

鍵状態及び遷移の例

活性化前状態：
暗号鍵は生成されたが、使用が認可されていない状態のこと。鍵の所持証明や確認など、
暗号鍵の検証にのみ使用することができ、それ以外の目的（例：暗号化や署名などの処理）に使ってはいけない。
また、活性化前状態に遷移する段階（図 2-5 の①）で、暗号鍵の生成やエンティティ・所有者の確認などが行われる。

⚫

活性化状態：
暗号鍵が、実際の暗号処理で使用することを認可されている状態のこと。暗号鍵のタイプに応じて、保護のみ（暗号化や署名生成）、処理のみ（復号や署名検証）、又は保護と処理の両方のいずれかを選んで指定できる。
また、活性化前状態からの遷移は（図 2-5 の④）は、活性化前状態に入った直後に遷移する場合もあれば、何らかのトリガー（開始日時など）により遷移する場合もある。

13⚫

非活性化状態：
暗号鍵が、保護（暗号化や署名生成）を行うために使用してはならないが、場合によっては、暗号化された保護情報を処理（復号や署名検証）するために使用されうる状態のこと。
例えば、アーカイブされている暗号鍵が非活性化状態に該当していることがあり得る。また、活性化状態は終了したが破壊状態になる前の暗号鍵も非活性化状態として取り扱われる。
活性化状態からの遷移は（図 2-5 の⑧）は、基本的に当該鍵の有効期限が終了したタイミングで行われる。

⚫

破壊状態 7：
暗号鍵が完全に存在しなくなった状態のこと。バックアップやアーカイブされている暗号
鍵についても（もしあれば同時に）破壊することが求められる。
暗号鍵が破壊されると、それ以降、当該暗号鍵の危殆化を心配する必要はなくなる。一方で、当該暗号鍵で保護（暗号化）を行った情報を処理（復号）することはできなくなり、
当該情報を永遠に喪失する結果を招くことになるので、誤って暗号鍵の破壊をしてしまう
ことがないようにしておくことも重要である。

⚫

危殆化状態：
暗号鍵が、実際の暗号処理で安全に利用できる保証がなくなった状態、又はその可能性が生じた状態のこと。例えば、暗号鍵の漏えいや暴露、認可されていないエンティティによる不正アクセスなどが生じた時（又はその疑いが生じた時）に危殆化状態への遷移（図 2-5の③⑥⑪⑬）を実施する。
危殆化状態となった暗号鍵（及びその鍵ペア）は失効させる必要があり、その後、保護（暗号化や署名生成）を行うために使用されてはならない。また、暗号化された保護情報を処理（復号や署名検証）する場合には、その情報の正当性や完全性が疑わしくなっていることを十分に認識したうえで、どのように取り扱うのかを考える必要がある。例えば、危殆化の発生前から物理的に保護されているか、信頼できるタイムスタンプの利用など別の保護手段により保護されているか、などの視点を踏まえて、当該情報の正当性や完全性を受け入れるか受け入れないかを判断することが必要となる。

⚫

一時停止状態：
暗号鍵の利用が一時的に認められなくなっている状態のこと。一時停止状態にある暗号鍵は、保護（暗号化や署名生成）を行うために使用されてはならない。
一般に、一時停止状態への遷移（図 2-5 の⑦）には、i）暗号鍵の危殆化が疑われ、その状況を調査するための時間を確保しつつ、万が一の危殆化の影響が発生しないようにするケ
ースと、ii）当該暗号鍵を所有するエンティティが一定期間利用しない（長期休暇など）こ7

設計指針（基本編）では「破壊状態」、SP 800-57 の日本語訳では「破棄状態」と記載されているが、本ガイダンスでは「破壊状態」で統一する。「暗号鍵を破棄」といった場合、「（再利用できないように）暗号鍵の存
在自体を完全に消す」場合と「（簡単には使えないように）暗号鍵を読み出せなくする」場合が考える。破壊状態とみなすのは前者だけであることに留意されたい。後者は、簡単には暗号鍵を読み出せなくなっているというだけでデータとしては残ったままということ であり、このような状態は破壊状態とはみなさない 。

14

とが明らかであり予防保全を行うケース、のどちらかの理由に起因して実施されることが考えられる。i）の場合、調査の結果により、危殆化の恐れが払拭されれば活性化状態に遷移（図 2-5 の⑩）することもあり得るが、そうでなければ危殆化状態に遷移（図 2-5 の⑪）するのが普通である。ii）の場合は、利用しない期間が明ければ（休み明けにより利用再開など）即座に活性化状態に遷移（図 2-5 の⑩）するのが一般的である。

《トイモデルと記載例》
本節のトイモデルも 2.1 節と同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムとする。
図 2-6 の通り、署名プライベート鍵は署名生成（保護）のために利用するため、有効期間前の 活性化前状態、有効期間内の活性化状態、有効期間後の非活性化状態に遷移する。その後、実際に署名プライベート鍵が破壊されると破壊状態に遷移する。また、署名プライベート鍵の危殆化が疑われる場合は危殆化状態に遷移させる。なお、本システムでは一時停止状態は設定しない。

署名プライベート鍵のペアとなる 署名公開鍵についても、 有効期間前の 活性化前状態、有効期間内の活性化状態、有効期間後の非活性化状態に遷移する。その後、実際に署名プライベート
鍵が破壊されると破壊状態に遷移する。また、 署名プライベート鍵が危殆化状態に遷移した場

合、署名公開鍵も同時に危殆化状態に遷移させる。これら以外の遷移条件は設定しないこととす
る。

図 2-6

トイモデルの鍵状態及び遷移

以上のトイモデルにおける記載例は、以下の「署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例」のようになる。
15

署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.02

活性化前状態、活性化状態、危殆化状態、非活性化状態、破壊状態

B.03⚫ 署名プライベート鍵と署名公開鍵の鍵ペア生成後に活性化前状態に遷移（ 図 2-6 の①）⚫ 証明書に記載された有効期間の開始時に活性化前状態から活性化状態に遷移（図 2-6の④）⚫ 活性化状態に遷移前に署名プライベート鍵に問題が生じた場合は、活性化前状態から破壊状態へ遷移（図 2-6 の②）⚫ 有効期限の終了時に活性化状態から非活性化状態に遷移（図 2-6 の⑧）⚫ 鍵の破壊条件を満たした場合に非活性化状態から破壊状態に遷移（ 図 2-6 の⑭）⚫ 活性化状態に遷移後に署名プライベート鍵の危殆化が疑われる事象が発生した場合
は、活性化状態又は非活性化状態から危殆化状態に遷移（図 2-6 の⑥⑬）。署名公開
鍵も同時に危殆化状態に遷移させる⚫ 証明書失効リスト（CRL リスト）に記載された署名公開鍵は危殆化状態に遷移（図2-6 の⑥⑬）⚫ 危殆化処理完了時に破壊状態に遷移（図 2-6 の⑮）
注）本システムでは、図 2-5 の③⑤⑦⑨⑩⑪⑫の遷移は設定しない。

2.3

暗号鍵のライフサイクル管理機能①

鍵情報に対する管理のために実行される機能の全体像

項目

FR 番号 Framework Requirements の内容

B.04 FR6.17

CKMS 設計は、実装されサポートされる鍵情報（暗号鍵及びメタデ

SP800-130
6.4 節ータ）の管理機能を明記しなければならない。
B.05 FR6.18

CKMS 設計は、CKMS に実装されるそれぞれの鍵情報（暗号鍵及び6.4 節

メタデータ）の管理機能のパラメタに適用される完全性、機密性、及びソース認証（source-authentication）の処理（service）を特定しなければならない。

解説・考慮点
項目 B.04 は、CKMS の設計にあたって定義した暗号鍵のライフサイクルにおける鍵状態及び遷移条件を管理・実行するために必要な全ての管理機能を明確化し、実装することを要求したものである。対象となる管理機能は本節の②以降である。
項目 B.05 は、管理機能に共通して入出力されるデータについて、完全性や機密性、ソース認証が必要となるものがあれば、それらを明確化することを要求したものである。これには、エンティティの認証及び認可が含まれることもある。
16

項目 B.04 の目的は、暗号鍵のライフサイクル管理機能として②以降で対象となる機能を全て明記することによって、詳細を定めなければいけない項目に抜けが生じないようにすることである。なお、それぞれの機能の詳細については次節以降で取り扱うことになるのでここであまり詳細に定める必要はないが、前節にも記載した通り、ライフサイクル管理機能が暗号鍵のライフサ
イクルを実現するための手段であるので、その基本方針となる B.02 及び B.03 で記載したことと整合的であるようにしなければならない。
項目 B.05 の目的は、管理機能に入出力される個々の鍵情報（暗号鍵及びメタデータ）が、完全性や機密性、ソース認証のどの処理（service）に使われるものなのかを明記することにより、鍵情報が誤った使い方をされていないことを確認することである。したがって、B.01 で記載した暗号鍵全てを包含していることが求められる。また、②以降での処理（service）についての項目に
おいて、B.05 と矛盾していないことを確認する必要がある。

②

鍵活性化機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.06 FR6.22

CKMS 設計は、それぞれの鍵タイプがどのように活性化されるか、

SP800-130
6.4.3 節及び鍵が活性化される状況を明記しなければならない。
B.07 FR6.23

それぞれの鍵タイプに対して、CKMS 設計は、鍵活性化の通知の要6.4.3 節求事項を明記しなければならない。それには、どの当事者に通知されるか、どのように通知されるか、どのセキュリティ処理（services）
が通知に適用されるか、及び通知の期間が含まれる。

解説・考慮点
暗号鍵の活性化前状態から活性化状態への遷移を提供する機能である。
項目 B.06 及び B.07 は、CKMS の設計にあたって、鍵活性化の手順や遷移条件、通知方法等、
鍵活性化機能への要求事項を明確化することを求めたものである。
項目 B.06 は、活性化前状態から活性化状態への遷移（図 2-5 の④）を実現するための手順や遷移条件を具体化することを求めたものであり、B.03 で記載した活性化状態への遷移条件と整合的であるようにしなければならない。
項目 B.07 は、暗号鍵が活性化状態になった時に、当該暗号鍵を利用するエンティティ（利用者）に、その暗号鍵が暗号処理に利用できるようになったことを通知する方法を具体化することを求めたものである。例えば、データ暗号化対称鍵であれば当該鍵の利用エンティティだけに秘密裏に通知できる手段を使って通知する必要がある一方、署名公開鍵であれば多くのエンティテ
ィに周知できる手段を使う必要があるかもしれない。
活性化状態に遷移したことが通知されない場合、当該暗号鍵を利用するエンティティ（利用者）
はいつからその暗号鍵が使えるのかが分からないため、基本的には活性化状態へ遷移する前にい17

つから使えるのか通知することが必要であると考えるのがよい。ただし、通知手段としては、利用者にも知らせる形で行われる場合もあれば、利用者に感知させることなく機器間で自動的に行われる場合もある。

③

暗号機能の実行場所の特定項目

FR 番号 Framework Requirements の内容

B.08 FR6.69

CKMS 設計は、サポートされている全ての暗号機能、及びそれらのSP800-130
6.4.27 節

暗号機能が CKMS のどこで実行されるか（例えば、CA、ホスト、又はエンドユーザシステム）を明記しなければならない。

解説・考慮点
データへの暗号学的保護を実際に提供する機能であり、署名生成、署名検証、暗号化、復号、
鍵ラッピング、鍵アンラッピング、MAC 生成、及び MAC 検証を含む。
項目 B.08 は、CKMS の設計にあたって、暗号機能がどこで実行されるのか明確化することを要求したものである。
項目 B.08 は、暗号機能がどこに存在し、どこで実行されるのかを把握しておくことを求めたものである。暗号機能が実行されるところでは必ず暗号鍵が平文の形で使われることになるため、暗号鍵が保管される場所と並んで、もっとも暗号鍵の危殆化が発生しやすい場所である。したがって、暗号機能がある場所や実行場所を把握しておくことで、暗号鍵が狙われるリスクを低減させるために重点的に対策・保護すべき場所の絞り込みに活用できる。
例えば、暗号モジュールの内部で暗号機能が実行されることとなれば、暗号鍵が平文の形で使われるのは暗号モジュール内に限定される。

④

鍵非活性化機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.09 FR6.24

CKMS 設計は、各鍵タイプに対して、鍵の非活性化がどのように決SP800-130
6.4.4 節定されるのか（例えば、暗号鍵有効期間（cryptoperiod）による、使用回数による、又はデータ量による）を明記しなければならない。
B.10 FR6.25

CKMS 設計は、それぞれの鍵タイプがどのように非活性化されるか（例えば、非活性化日時、使用回数、又は保護されたデータの量に基づいて、手動で行われるのか自動で行われるのか）を明記しなければならない。

18

6.4.4 節

B.11 FR6.26

CKMS 設計は、それぞれの鍵タイプの非活性化日時がどのように変6.4.4 節更できるかを明記しなければならない。
B.12 FR6.27

それぞれの鍵タイプに対して、CKMS 設計は、鍵タイプの非活性化

6.4.4 節の事前通知の要求事項を明記しなければならない。それには、CKMS
がサポートするどの役割に通知されるか、どのように通知されるか、どのセキュリティ処理（services）が通知に適用されるか、及び通知の期間が含まれる。

解説・考慮点
暗号鍵の非活性化状態への遷移を提供する機能である。CKMS セキュリティポリシーには当該ポリシーがカバーするあらゆる鍵タイプについて最大許容暗号鍵有効期間を記載すべきであり、その期間を超えた暗号鍵有効期間を設定してはならない。
項目 B.09～B.12 は、CKMS の設計にあたって、鍵非活性化の手順や遷移条件、変更方法、通知方法等、鍵非活性化機能への要求事項を明確化することを求めたものである。
セキュリティ対策の一環として、多くの場合、暗号鍵が無期限に使われることはなく、あるタ
イミングで暗号鍵の交換を行う。暗号鍵の活性化状態に存在している時間のことを暗号鍵有効期間という。この時間は、扱う情報の資産価値、求められる情報の機密性や完全性、CKMS への脅
威、暗号鍵の交換に伴うメリットとデメリットの比較などに基づいて決められる。
暗号鍵有効期間が経過した暗号鍵は非活性化状態に遷移することで、新たな保護（暗号化や署名生成）を行うことはできなくなる。
項目 B.09 と B.10 は、管理対象となる各々の暗号鍵がどのような条件を満たしたときにどのような方法で非活性化状態に遷移するのかを決めるためのものである。例えば、遷移条件では、暗号鍵有効期間のほか、使用回数やデータ量などを使うケースもある。いずれの条件を使うとしても、CKMS セキュリティポリシーや CKMS 設計などで最大許容暗号鍵有効期間が決まっている
場合には、その最大期間と矛盾しないようにしなければならない。また、遷移方法では、暗号鍵が自動的に利用できなくなるように非活性化状態に直接遷移する（ 図 2-5 の⑧）ような場合もあれば、例えば、一時停止状態に自動的に遷移（図 2-5 の⑦）した後、管理者等の確認処理を経て非活性化状態に遷移する（図 2-5 の⑫）ようなやり方も想定される。
項目 B.11 は、非活性化状態への遷移条件の変更を例外的に認めるかどうか、また、認める場合
でもどのような条件下で認めるのかを決めておくものである。基本的には例外を認めない方がよ
いと考えられるが、システム上の要請などにより例外的に遷移条件の変更を容認する必要がある
場合にはそのことを明確にしておくこと、また例外がなし崩しにならないような明確な条件として定めておくことが重要である。
なお、これらは B.03 の非活性化状態への遷移条件と整合していなければならない。
項目 B.12 は、暗号鍵が非活性化状態になるより前に、当該暗号鍵を利用するエンティティ（利用者）に、その暗号鍵が暗号処理に利用できなくなることを予告する方法を具体化することを求19

めたものである。非活性化状態に遷移することが事前に通知されることなく、非活性化状態に遷移した場合、当該暗号鍵を利用するエンティティ（利用者）にとっては突然その暗号鍵が使えなくなることを意味し、それが故障などの予期せぬ原因によって生じた事態だと誤認する恐れがある。このような事態を避けるのが事前通知の役割であり、何らかの方法で通知する仕組みを設けたほうがよい。ただし、通知手段としては、利用者にも知らせる形で行われる場合もあれば、利用者に感知させることなく機器間で自動的に行われる場合もある。

⑤

鍵失効機能への要求事項

項目

FR 番号

B.13 FR6.28

Framework Requirements の内容
CKMS 設計は、いつ、どのように、どのような状況で失効が実行さ

SP800-130
6.4.5 節れ、失効情報を依拠する当事者が利用可能になるかを明記しなければならない。
B.14 FR6.108

CKMS 設計は、使用される又は使用できる鍵失効メカニズム及び6.8.3 節関連付けられた依拠するエンティティへの通知メカニズムを明記しなければならない。

解説・考慮点
暗号鍵有効期間より前に当該暗号鍵の使用を終了させる必要が生じた場合に行われ、暗号鍵の危殆化状態への遷移を提供する機能である。この機能が実行されると、過去に保護された情報の処理のための使用に対しても完全なセキュリティは保証されないので、当該暗号鍵を速やかに置き換える能力とその鍵を使用する当事者に危殆化／失効を通知する能力を備えているべきである。
CKMS の設計にあたって、項目 B.13 は、鍵失効の遷移条件及び通知方法といった鍵失効機能への要求事項を明確化することを求めたものである。B.14 は、実際に利用する具体的な鍵失効メカニズム及び通知メカニズムを明確化することを要求したものである。
非活性化状態への遷移は、暗号鍵有効期間が満了したなどの予め決められた条件に従って実行される。一方、危殆化状態への遷移は、暗号鍵の漏えいなどによる予期せぬ原因により、当該暗号鍵の安全性が担保できないと判断された場合に実行される。つまり、暗号鍵の安全性低下が遷移の主要因になっているかどうかが、非活性化状態への遷移と危殆化状態への遷移の違いである。
鍵失効機能は、危殆化状態への遷移を実行するための機能のことである。
項目 B.13 は、どのようなことが発生したら危殆化状態と見なすのかといった鍵失効の遷移条
件と誰にどのように危殆化状態に遷移した事実を知らせるのかといった通知方法など、鍵失効機能への要求事項を明確化することを求めている。これは、B.03 の危殆化状態への遷移条件と整合していなければならない。B.14 は、実際に利用する具体的な鍵失効メカニズム及び通知メカニズ
ムを明確化することを要求している。

20

鍵失効の遷移条件及び具体的な鍵失効メカニズムは、「いつ、どのように、どのような状況で危殆化した（と推定される）鍵情報を失効させ、利用できなくするか」の視点で検討される。
一方で、この機能が実行されると、それ以降の保護（暗号化や署名生成）のセキュリティが担保されないだけでなく、過去に保護された情報の処理（復号や署名検証）に対しても完全なセキ
ュリティは保証されなくなる。このため、危殆化した暗号鍵を速やかに置き換え、新しい暗号鍵で保護が再開できるようにすることはもとより、当該暗号鍵を使用して過去に保護された情報を処理するエンティティ（利用者）全員に完全なセキュリティが保証されない可能性があることの注意喚起を行う必要がある。鍵失効の通知が重要であるのはこのためである。
失効情報を依拠する当事者及び依拠するエンティティへの通知メカニズムは、「危殆化した（と推定され、失効した）暗号鍵を使用して過去に保護された情報について完全なセキュリティが保証されない可能性があることをどのように関係者に通知するか」の 視点で検討される。例えば、危殆化／失効の通知方法としては、危殆化鍵リスト、証明書失効リスト（CRLs）、ホワイトリス
ト、クエリホワイトリスト、OCSP（Online Certificate Status Protocol）がある。

⑥

暗号鍵の一時停止機能及び再活性化機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.15 FR6.29

CKMS 設計は、どのように、どのような状況で鍵が一時停止される

SP800-130
6.4.6 節かを明記しなければならない。
B.16 FR6.30

CKMS 設計は、どのように一時停止情報を依拠又は通信する当事者

6.4.6 節が利用可能になるかを明記しなければならない。
B.17 FR6.32

CKMS 設計は、どのように一時停止された鍵によるセキュリティ処

6.4.6 節理（services）の実行を防止するのかを明記しなければならない。
B.18 FR6.31

CKMS 設計は、どのように、どのような状況で一時停止された鍵が6.4.6 節再活性化されるかを明記しなければならない。
B.19 FR6.33

CKMS 設計は、どのように再活性化情報を依拠又は通信する当事者

6.4.6 節が利用可能になるのかを明記しなければならない。

解説・考慮点暗号鍵の一時停止状態への遷移を提供する一時停止機能、及び活性化状態への遷移を再度提供
する再活性化機能のことであり、これらの機能は必ずセットで用いられる。
項目 B.15 及び B.16 は、CKMS の設計にあたって、暗号鍵の一時停止の遷移条件及び通知方法
といった一時停止機能への要求事項を明確化することを求めたものである。B.17 は、一時停止された暗号鍵が利用されないようにするための要求事項を明確化することを求めたものである。B.18 及び B.19 は、暗号鍵を再活性化するための遷移条件及び通知方法といった再活性化
機能への要求事項を明確化することを求めたものである。
21

なお、鍵状態において一時停止状態を定義しない場合には、これらの項目は対象外である。
一時停止状態は、暗号鍵の利用が一時的に認められなくなっている状態であり、i）暗号鍵の危殆化が疑われ、その状況を調査するための時間を確保しつつ、万が一の危殆化の影響が発生しないようにするケースと、ii）当該暗号鍵を所有するエンティティが一定期間利用しない（長期休暇など）ことが明らかであり予防保全を行うケース、のどちらかの理由で使われることが想定されている。前者の「暗号鍵の危殆化の疑い」には、暗号鍵の誤使用や誤配置などに暗号鍵の危殆化につながりかねない状況を含んでもよい。
なお、鍵状態として必ず一時停止状態を用意する必要があるわけではなく、i）のケースでは活性化状態から危殆化状態に直接遷移するようにし、ii）のケースでは活性化状態のままにしておく、という管理の仕方をしても構わない。もし一時停止状態を定義しない場合には、ここでの 項
目は全て対象外となる。
一時停止状態を用意することのメリットは、i）のケースでは、調査の結果で危殆化の恐れが払拭された場合には、同じ暗号鍵を再活性化することで継続利用が可能になり、暗号鍵の更新に関連する処理を実施する必要はないことである。もし危殆化状態に遷移させていた場合、危殆化の恐れが払拭された場合でも暗号鍵の更新・再設定が必要となる。また、ii）のケースでは、長期利用しないエンティティになりすまされて不正利用される事態を防止できることである。
一方、一時停止状態と用意する場合には、どのようなことが発生したら一時停止させるのかといった一時停止状態への遷移条件（図 2-5 の⑦）と、どのようなことが満たされたら一時停止を解除するのかといった活性化状態への遷移条件（図 2-5 の⑩）を必ずセットで準備しなければならない。また、一時停止状態になった暗号鍵は保護（暗号化や署名生成）を行うために使用できないので、当該暗号鍵を利用する処理が行われることはないことを関係するエンティティ（利用者）全員に注意喚起する必要がある。
項目 B.15 と B.18 は上述の一時停止状態への遷移条件と活性化状態への遷移条件を、B.16 とB.19 は関係エンティティ（利用者）への通知方法を明確化することを求めたものである。B.17 は、一時停止された暗号鍵が利用されないようにするための要求事項の明確化のことである。これらの要件は B.03 の一時停止状態への遷移条件及び再活性化の遷移条件と整合していなければならない。

⑦

鍵情報の破壊機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.20 FR6.38

CKMS 設計は、どのように、どのような条件で鍵が意図して破壊されるか、及び破壊がコンポーネントへの局所的（local）なものであるか CKMS 全体への共通的（universal）なものであるかを明記しなければならない。

22

SP800-130
6.4.9 節

B.21 FR6.39

それぞれの鍵タイプに対して、CKMS 設計は、鍵破壊の事前通知の6.4.9 節要求事項を明記しなければならない。それには、どの当事者に通知されるか、どのように通知されるか、どのセキュリティ処理（services）が通知に適用されるか、及び通知の時期が含まれる。

解説・考慮点
暗号鍵の破壊状態への遷移を提供する機能である。
項目 B.20 は、CKMS の設計にあたって、鍵情報を破壊するための条件及び具体的な破壊方法、並びに当該鍵情報がどこに存在するかを含めて明確化することを要求したものである。 B.21
は、鍵情報が破壊されたことの通知方法といった破壊機能への要求事項を明確化することを求めたものである。
暗号鍵が使えない状態になっていたとしても、どこかに当該暗号鍵のデータが残っていれば、攻撃や不正持出など、何らかの理由によりそのデータが漏えいするリスクを完全には排除できない。逆に言えば、暗号鍵の漏えいリスクを完全に排除するためには、当該暗号鍵が完全に存在 しなくなった状況にするしかない。当然、実際に利用中の暗号鍵だけでなく、バックアップやアーカイブされたものも含めて完全に存在しない状況にする必要がある。つまり、バックアップやアーカイブしている場合で鍵の破壊を行うケースでは、鍵の破壊 8に関して B.20 の記載内容と B.54
や B.56 の記載内容が整合していなければならない。
一方、暗号鍵を破壊してしまえば、例え当該暗号鍵の所有者であったとしても、当該暗号鍵で保護（暗号化）を行った情報を処理（復号）することはできなくなり、その情報は永遠に失われる結果を招くことになる。したがって、誤って暗号鍵の破壊をしてしまうことがないようにしておくことも重要である。
項目 B.20 では、CKMS の設計にあたって、鍵情報を破壊するための条件などの他、破壊した
暗号鍵の影響範囲がどこまで及ぶのかを明確にしておくことを求めている。例えば、利用者 A だ
けが使う暗号鍵であれば、その暗号鍵が破壊されたことによって影響を受けるのは利用者 A だけに限定される。つまり、局所的（local）な影響である。一方、CKMS 全体を管理するルート鍵が破壊されると CKMS 全体で当該ルート鍵が利用できなくなるので、その影響は共通的（universal）
であると言える。
なお、ここでの要件は B.03 の破壊状態への遷移条件と整合していなければならない。
B.21 は、鍵情報が破壊されたことの通知方法の要求事項を明確化することを求めたものである。鍵情報の破壊は、当該暗号鍵が使えなくなるだけでなく、当該暗号鍵で保護（暗号化）を行った情報も喪失することを意味するので、注意喚起の意味でも関連するエンティティ（利用者）に事前通知しておくことが特に重要になる。
8

SP 800-88 Rev.1「Guidelines for Media Sanitization（媒体のデータ抹消処理（サニタイズ）に関するガイドライン）」中に 暗号鍵 の 破壊方法 につい ての記 載 （ 5 章参照）があ るので 、必 要に応じ て参照 された い。
https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
日本語訳：https://www.ipa.go.jp/files/000094547.pdf

23⑧

鍵生成機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.22 FR6.19

CKMS 設計は、それぞれの鍵タイプに対して、CKMS で使用される

SP800-130
6.4.1 節

鍵生成手段を明記しなければならない。
B.23 FR6.20

CKMS 設計は、対称鍵及びプライベート鍵を生成するのに使用され6.4.1 節る元となる乱数生成器を明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.22 は暗号鍵を生成する手段について、B.23 は暗号鍵を生成する際に利用する乱数生成器について明確化することを要求したものである。一般に、鍵生成
手段は暗号鍵と対になる暗号アルゴリズムの仕様に依存し、暗号目的として設計された乱数生成器の使用を要求する。
暗号アルゴリズムの安全性は、利用する暗号鍵が予測できないことを前提としている。逆に言えば、利用する暗号鍵が何らかの方法で予測できるのであれば、どんなに強力な暗号アルゴリズ
ムを使っていたとしても安全性は担保されない。そのため、予測できない暗号鍵を生成する手段を利用することが極めて重要になる。
ここでの「予測できない」の意味は、①出力が一様分布になっていること、②十分なエントロ
ピー量が確保されていること、の両方を満たすことである。
①の出力が一様分布になっているということは、生成される可能性がある暗号鍵の種類が 2 128
個あるならば、どの鍵も一様に 1/2 128 の確率で生成されるということである。このような性質を持つように作られていると信頼できる鍵生成方法として、SP 800-90 や SP 800-133 などの乱数生成器を使う方法と、SP 800-56 などのような鍵導出関数を使う方法がある。
②の十分なエントロピー量を確保されているということは、極めて多数の種類の暗号鍵が生成可能であるということを意味する。例えば、鍵長 128 ビットの暗号鍵であれば 2 128 個の異なる暗号鍵が利用できることが期待されるので、利用する鍵生成手段が 2 128 個の異なる暗号鍵を生成するように作られていれば「十分なエントロピー量を確保されている」という。一方、例えば、1,000
個の異なる暗号鍵しか生成しないような鍵生成手段であれば、例え出力が一様分布になっていたとしても「エントロピー量が十分に確保されていない」と判断される。これは、暗号 鍵の全数探索で暗号解読しようとした場合、前者は平均 2 127 回のトライアルが必要となるが、後者は平均 500
回のトライアルをすればよいためである。
項目 B.22 は暗号鍵を生成する手段について、B.23 は暗号鍵を生成する際に利用する乱数生成器について明確化することを要求したものである。ここでのポイントは「信頼できる鍵生成手段」
や「信頼できる乱数生成器」を使い、十分なエントロピー量が確保されていることを確認するこ
とにある。

24

⑨

鍵導出機能／鍵更新機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.24 FR6.36

CKMS 設計は、鍵を導出又は更新するために使用される全てのプロ

SP800-130
6.4.8 節セス、及び鍵が導出又は更新される状況を明記しなければならない。
B.25 FR6.37

それぞれの鍵タイプに対して、CKMS 設計は、鍵の導出又は更新の6.4.8 節

事前通知の要求事項を明記しなければならない。それには、どの当事者に通知されるか、どのように通知されるか、どのセキュリティ
処理（services）が通知に適用されるか、及び通知の期間が含まれる。

解説・考慮点
暗号鍵の生成では、鍵生成機能を利用する代わりに、鍵導出機能や鍵更新機能を利用することがある。
項目 B.24 及び B.25 は、CKMS の設計にあたって、鍵導出機能／鍵更新機能が利用される条件
や鍵導出方法、通知方法等といった鍵導出機能／鍵更新機能への要求事項を明確化することを求めたものである。
なお、これらの機能は採用必須の機能ではなく、CKMS の設計で採用しなければ検討対象外である。逆に、採用してはならないという要求事項の場合もあり得る。
鍵導出機能では、一部が秘密であるような独立した他の情報（他の暗号鍵、共有秘密やパスワードなど）から不可逆な形で暗号鍵が導出されるプロセスを実行する。例えば、鍵確立プロトコ
ルでは互いの共有秘密から共有鍵を導出する。
鍵更新機能では、「元鍵」から「別鍵」を計算で導出し、導出した「別鍵」で「元鍵」を置き換
えるプロセスを実行する。なお、別鍵を導出する際に他の秘密データを使用しない場合には、元鍵と更新方法を知っている攻撃者が将来にわたるあらゆる時期の更新した別鍵を知りうるという
セキュリティリスクにさらされる。
暗号鍵の予測可能性の観点でいえば、二つの点で、鍵生成機能を利用して生成される暗号鍵よりも予測がしやすくなっている可能性がある。①鍵導出機能や鍵更新機能により作られる暗号鍵は、「（乱数生成器ではなく）ある種の計算方法」に従って生成されることから、入力データと出力データ（生成された暗号鍵）との間に相関が残っている可能性がある、②入力データの種類によっては十分なエントロピー量が確保できない可能性がある。例えば、パスワードなどから鍵を導出するからといって、十分なエントロピー量の確保できるような複雑なパスワードを利用させることは困難を伴う。
これらの弱点による暗号鍵の予測可能性を少しでも低減するには、信頼できる鍵導出方法や鍵更新方法を使うのが望ましい。例えば、SP 800-108 や SP 800-132、SP 800-135 などである。
一方、鍵導出機能や鍵更新機能を使うことのメリットは、i）ローカルで（鍵生成機能を使うことなく）鍵更新ができる、ii）鍵確立プロトコルを利用しなくてもそれぞれのエンティティ（利用25者）が独自に同じ秘密データを使って同じ暗号鍵を生成することができる、という点である。前者は特に大規模 CKMS の場合や CKMS につながっていない機器などの場合に効果を発揮する可能性があり、後者は鍵確立時の漏えいリスクの低減に役立つ。
項目 B.24 及び B.25 は、CKMS の設計にあたって、鍵導出機能／鍵更新機能が利用される条件
や鍵導出方法、通知方法等といった鍵導出機能／鍵更新機能への要求事項を明確化することを求めたものである。ここでのポイントは、B.24 は主に「信頼できる鍵導出方法や鍵更新方法」を使うことで暗号鍵の予測可能性のリスクを低減していることの確認を行うことである。B.25 は鍵導出や鍵更新を行う事前通知がないまま新しい暗号鍵に変わった場合、当該暗号鍵を利用するエン
ティティ（利用者）にとっては突然以前の暗号鍵が使えなくなることを意味し、それが故障などの予期せぬ原因によって生じた事態だと誤認する恐れがある。このような事態を避けるのが事前通知の役割であり、何らかの方法で通知する仕組みを設けたほうがよい。ただし、通知手段としては、利用者にも知らせる形で行われる場合もあれば、利用者に感知させることなく機器間で自動的に行われる場合もある。
なお、鍵導出機能や鍵更新機能は採用が必須の機能ではないので、CKMS 設計でこれらの機能を採用しないと決めたのであれば検討対象外となる。さらには、採用してはならないという要件を採用する場合もあり得る。

⑩

対称鍵の検証機能への要求事項／⑪

項目

FR 番号 Framework Requirements の内容

B.26 FR6.66

公開鍵の検証機能への要求事項

CKMS 設計は、どのように、どこで、どのような状況で、対称鍵やSP800-130
6.4.24 節

そのメタデータが検証されるかを明記しなければならない。
B.27 FR6.63

CKMS 設計は、どのように、どこで、どのような状況で、公開鍵ド

6.4.21 節

メインパラメタが検証されるかを明記しなければならない。
B.28 FR6.64

CKMS 設計は、どのように、どこで、どのような状況で、公開鍵が6.4.22 節

検証されるかを明記しなければならない。
B.29 FR6.65

CKMS 設計は、どのように、どこで、どのような状況で公開鍵証明

6.4.23 節

書パスが検証されるかを明記しなければならない。

解説・考慮点＜対称鍵の検証機能＞
対称鍵及びそのメタデータに対するテストを実行する機能である。
項目 B.26 は、CKMS の設計にあたって、対称鍵の検証機能が利用される条件や検証方法等といった対称鍵の検証機能への要求事項を明確化することを求めたものである。

26

＜公開鍵の検証機能＞
公開鍵についてある種の正当性チェックを実行して公開鍵が数学的に正しいことを保証し、公開ドメインパラメタについてもドメインパラメタが数学的に正しいことの保証を提供する機能である。
CKMS の設計にあたって、項目 B.27～B.29 は、公開鍵の検証機能が利用される条件や検証方法等といった公開鍵の検証機能への要求事項を明確化することを求めたものである。
生成されたり、共有されたりした暗号鍵が正当なものであることは、暗号アルゴリズムを利用する上での前提条件である。したがって、実際の暗号処理に利用する前には正当性を確認しておくことが必要である。
ただし、その確認を行うタイミングは、利用する暗号鍵の種類や利用方法、利用環境などによってさまざまである。例えば、タイミングだけ見ても、①暗号鍵が生成されたタイミングで実施、②暗号処理を行う直前に実施、③暗号鍵が活性化状態に遷移するタイミングで実施、④定期的に実施、などが考えられる。検証方法についても、a）ハッシュ値でのチェック、b）署名でのチェ
ック、c）物理的手段でのチェック、d）相互通信可否でのチェック、e）CKMS サーバでのチェック、などが考えられる。
項目 B.26～B.29 は、いずれも検証機能が利用される条件や検証方法等といった、暗号鍵の検証に必要な要求事項を明確化することを求めている。具体的には、B.26 では対称鍵とそれに関連するメタデータが、B.27 では B.28 での公開鍵が利用するドメインパラメタが、B.28 では公開鍵が、それぞれ検証の対象として、「いつ（タイミング）、どこで（検証場所）、どのように（検証方法）」検証を行うのかを洗い出すことである。
同様に、B.29 では、B.28 での公開鍵とセットで作られる公開鍵証明書について、トラストア
ンカーから始まる公開鍵証明書のチェーン（証明書パス）を使った有効性検証を対象としている。

⑫

トラストアンカー管理機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.30 FR6.70

CKMS 設計は、サポートされている全てのトラストアンカー管理機

SP800-130
6.4.28 節

能を明記しなければならない（［RFC6024］を参照）。
B.31 FR6.71

CKMS 設計は、依拠するエンティティがトラストアンカーについて

6.4.28 節のソース認証（source authentication）及び完全性検証を実行できるように、どのようにそれらのトラストアンカーがセキュアに配付されるかを明記しなければならない。
B.32 FR6.72

CKMS 設計は、依拠するエンティティのシステムのトラストアンカ
ーストアに対して、認可された追加、変更、削除のみが行えること

27

6.4.28 節

を保証するために、どのように依拠するエンティティのシステムでトラストアンカーが管理されるかを明記しなければならない。

解説・考慮点
トラストアンカーなしでは信頼できるかわからない公開鍵に対して、信頼を確立するために使用されるトラストアンカーを保管・管理する機能である。
CKMS の設計にあたって、項目 B.30 はトラストアンカー管理機能についてどのようなものを受け入れるのかといった要求事項を、B.31 及び B.32 はトラストアンカーを完全かつセキュアに配送・保管・追加・削除等といったメンテナンスを行うためのトラストアンカー管理機能への要求事項を明確化することを求めたものである。
公開鍵暗号・署名では、プライベート鍵とそれに対応する公開鍵は一対一対応しているが、問題はそのプライベート鍵の所有者が「正当な」エンティティであることの保証が「公開鍵」からは得られないことである。例えば、Eve が自分自身のプライベート鍵に対応する公開鍵を「Aliceの公開鍵」であると偽って公開していた場合に、Bob がその公開鍵が「Alice のものではない」と見破ることはほとんどできない。つまり、何も対策をしていないままの公開鍵は基本的に「信頼できるかわからない公開鍵」である。
そこで、信頼できる第三者であるトラストアンカーを用意し、そのトラストアンカーが「信頼できるかわからない公開鍵」にお墨付きを与えることで「信頼できる公開鍵」にする仕組みが必要になり、それを実現したのが公開暗号基盤（PKI）である。つまり、PKI では、トラストアン
カーが公開鍵の信頼性の起点となることを意味し、その信頼性のうえで公開鍵暗号・署名の安全性が確保されていることになる。したがって、トラストアンカーの完全性確保は CKMS のセキュ
リティにとって死活的に重要である。
項目 B.30～B.32 は PKI でのトラストアンカーの完全性確保のための要求事項を明確化することを求めたものである。ここでのポイントは、具体的に、B.30 はどんなトラストアンカーを PKIの利用エンティティのシステムに用意するのか、B.31 はそのシステムに対してトラストアンカーの情報をどのように安全に配布するのか、さらに B.32 はそのシステムでのトラストアンカーの情報をどのように安全に管理するのか、といったことを確認することである。
例えば、トラストアンカー管理機能として OS での証明書管理機能を使い（B.30）、CKMS サーバから準備するトラストアンカーの公開鍵証明書（プライベート CA ルート証明書）を当該CKMS サーバからダウンロードさせ、パスワード及びハッシュ値チェックで OK になった場合にそのルート証明書を証明書管理機能が管理するトラストアンカーストアに登録し（B.31）、OS での証明書管理機能でルート証明書の管理を行う（B.32）といったことである。

28

⑬

公開鍵の有効期間延長機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.33 FR6.34

CKMS 設計は、どのように、どのような条件で公開鍵の有効期間がSP800-130
6.4.7 節延長できるかを明記しなければならない。なお、延長後の有効期間の合計が CKMS セキュリティポリシー等で定める公開鍵の最大許容暗号鍵有効期間を超える場合には、当該公開鍵の延長を行ってはならない。
B.34 FR6.35

それぞれの鍵タイプに対して、CKMS 設計は、鍵タイプの有効期間

6.4.7 節

延長の事前通知の要求事項を明記しなければならない。それには、どの当事者に通知されるか、どのように通知されるか、どのセキュ
リティ処理（services）が通知に適用されるか、及び通知の期間が含まれる。

解説・考慮点
新しい有効期限を設定した「同じ公開鍵」を含む新しい公開鍵証明書を発行することで、以前の有効期間を超えて既存の公開鍵に対する新しい有効期間を確立するための機能である。なお、
延長後の有効期間の合計が CKMS セキュリティポリシー等で定める公開鍵の最大許容暗号鍵
有効期間を超える場合には、当該公開鍵の延長を行ってはならない。
CKMS の設計にあたって、項目 B.33 及び B.34 は、公開鍵の有効期間延長機能が利用される条件や事前通知方法等といった公開鍵の有効期間延長機能への要求事項を明確化することを求めたものである。
セキュリティ上の観点から、公開鍵証明書には有効期間が記載されている。有効期間が経過す
ると非活性化状態に自動的に遷移して当該公開鍵は失効し、また新しい公開鍵が鍵生成機能を使って生成されるのが一般的である。この場合、B.33 と B.34 は検討対象外となる。
しかし、新しい公開鍵を生成した場合、関連する鍵情報の更新も合わせて必要となったり、過去に署名したものに対する署名検証ができなくなったりするといったデメリットもある。こういったデメリットを回避する方法として、当該公開鍵の有効期間を延長するというやり方がある。
これは、公開鍵の有効期間延長機能を使って、新しい有効期間を設定した「同じ公開鍵」を含む新しい公開鍵証明書を発行することによる実現する。
そもそも公開鍵証明書の有効期間は、トラストアンカーが「信頼できるかわからない公開鍵」
を「信頼できる公開鍵」として利用できるお墨付きを与えている期間である。言い換えれば、その期間内は、公開鍵の安全性の担保をトラストアンカーが代理で受け持つということである。このことを踏まえれば、「有効期間を延長」することができるかどうかはトラストアンカーがその分の「責任を継続して負う」ことができるかどうかに依存する。項目 B.33 は、この「責任を継続して負う」ことができる条件を明確化することを求めたものである。
なお、CKMS セキュリティポリシー等で定める公開鍵の最大許容暗号鍵有効期間は、セキュリ

29

ティ上の要件として定められたものであるので、これに違反するような延長は認められないことに注意されたい。例えば、最大許容暗号鍵有効期間が 3 年である場合、1 年間有効の公開鍵証明書は 2 度延長することはできるが、3 度目の延長はできない。
公開鍵証明書の有効期間を延長するためには、その有効期間が切れる前に新たな有効期間を設定した公開鍵証明書の発行が必要となる。その手続きを行わせるためのトリガーとなるのが事前通知であり、項目 B.34 で事前通知を行うための条件の明確化を求めている。通知手段としては、利用者にも知らせる形で行われる場合もあれば、利用者に感知させることなく機器間で自動的に行われる場合もある。

⑭

所有者登録機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.35 FR6.21

SP800-130

CKMS 設計は、鍵と所有者の識別子を結び付けるプロセスを含めて、 6.4.2 節
所有者登録に関わる全てのプロセスを明記しなければならない。

解説・考慮点
セキュリティエンティティ（個人、組織、デバイス、又はプロセス）及びメタデータを伴う暗号鍵の最初の登録を行うための機能である。
項目 B.35 は、CKMS の設計にあたって、所有者登録機能への要求事項を明確化することを求めたものである。
暗号鍵は、正しいエンティティ（利用者）に届ける必要がある。もし登録時点で誤った所有者
登録が行われてしまうと、誤ったエンティティと暗号鍵が結び付くことになり、その後の暗号鍵のライフサイクルが正しく実行されたとしても全く安全性が担保されない。
したがって、所有者登録では、①どのようにエンティティ（利用者）が正しいことを確認する
か、②どのようにそのエンティティと暗号鍵とを結びつけるか、を把握しておくことが重要である。典型的には、エンティティの対称鍵、公開鍵又はプライベート鍵の初期セットと、エンティ
ティ識別子及びメタデータとも結び付ける登録プロセスが存在する。
項目 B.35 は、これら把握しておくべきことを明らかにすることを求めている。

30

⑮ プライベート鍵所持の検証機能への要求事項／⑯への要求事項項目

プライベート鍵の検証機能

FR 番号 Framework Requirements の内容

B.36 FR6.68

CKMS 設計は、どのように、どこで、どのような状況で、プライベ

SP800-130
6.4.26 節

ート鍵とそのメタデータの所持が検証されるかを明記しなければならない。
B.37 FR6.67

CKMS 設計は、どのように、どこで、どのような状況で、プライベ

6.4.25 節

ート鍵又は鍵ペア、あるいはそのメタデータが検証されるかを明記しなければならない。

解説・考慮点＜プライベート鍵所持の検証機能＞
公開鍵の所有者であると主張する者が対応するプライベート鍵を所持していることの保証を得るために、公開鍵を受領したエンティティによって使用される機能である。
項目 B.36 は、CKMS の設計にあたって、プライベート鍵所持の検証機能が利用される条件や検証方法等といったプライベート鍵所持の検証機能への要求事項を明確化することを求めたものである。
＜プライベート鍵の検証機能＞
プライベート鍵に対してある種のテストを実行し、鍵ペアの仕様を満たすことの保証を提供するための機能である。
項目 B.37 は、CKMS の設計にあたって、プライベート鍵の検証機能が利用される条件や検証方法等といったプライベート鍵の検証機能への要求事項を明確化することを求めたものである。
PKI に則り、トラストアンカーが「信頼できるかわからない公開鍵」を「信頼できる公開鍵」として利用できるお墨付きを与えるためには、その公開鍵に対応する「正しい」プライベート鍵（及びそれに付随するメタデータ）を「正当な」エンティティが所有していることを確認する必要がある。
その一方、プライベート鍵は基本的に唯一のエンティティのみが秘密に所持することが求められるため、当該公開鍵に対応する「正しい」プライベート鍵（及びそれに付随するメタデータ）
を「正当な」エンティティが所有していることを、トラストアンカーにその中身を直接示して証明するわけにはいかない。
そこで、項目 B.36 は、プライベート鍵（及びそれに付随するメタデータ）（と称するデータ）を所持していることを「正しい」エンティティが所有していることを確認するための検証方法の明確化を求めたものである。また、B.37 は B.36 での検証対象となったプライベート鍵（及びそれに付随するメタデータ）（と称するデータ）と（お墨付きを与える対象の）公開鍵とが一対一の31

正しい関係にあり、結果として「正しい」プライベート鍵（及びそれに付随するメタデータ）であることを確認するための検証方法の明確化を求めたものである。
つまり、B.36 及び B.37 に両方を実施することで、トラストアンカーにプライベート鍵（及びそれに付随するメタデータ）の中身を直接示すことなく、当該公開鍵に対応する「正しい」プラ
イベート鍵（及びそれに付随するメタデータ）を「正当な」エンティティが所有していることを証明する。なお、これらの機能は、プライベート鍵の所有者又はプライベート鍵の所有者の代理として振舞う信頼される第三者のみが実行できる。

⑰

暗号鍵とメタデータの関連付け機能への要求事項

項目

FR 番号 Framework Requirements の内容

B.38 FR6.40

使用されているそれぞれの鍵タイプに対して、CKMS 設計は、何のSP800-130
6.4.10 節

メタデータが鍵と関連付けられているか、どのようにメタデータが鍵と関連付けられているか、及びメタデータが鍵と関連付けられる状況を明記しなければならない。
B.39 FR6.41

使用されているそれぞれの鍵タイプに対して、CKMS 設計は、どの

6.4.10 節

ように次のセキュリティ処理（services）（保護）が関連付けられたメタデータに適用されるかを明記しなければならない：ソース認証（source authentication）、完全性、及び機密性。

解説・考慮点暗号鍵に関連付けられているメタデータ要素がある場合、それらを関連付けるための機能である。なお、暗号鍵とメタデータの関連付けは、当該鍵情報の生成時のほか、配送時、登録時、保管時など、暗号鍵有効期間を通じて完全性を維持する必要がある。
CKMS の設計にあたって、項目 B.38 及び B.39 は、関連付け機能が利用される対象や条件、関連付けの方法等といった関連付け機能への要求事項を明確化することを求めたものである。
鍵情報は、暗号鍵とメタデータとで構成される。4.1 節に記載があるように、メタデータとは、暗号鍵を適切に管理するために、その暗号鍵に関連付けられている情報である。例えば 、暗号鍵のパラメタ、保護方法や有効期間などである。「暗号鍵管理システム設計指針（基本編）」では、メタデータの典型的な要素として 23 種類が記載されている。鍵タイプによってはメタデータとの組み合わせによりその暗号鍵の完全性を確保する場合もあるため、とりわけそのような鍵タイプの暗号鍵ではメタデータの管理も安全な鍵情報の管理を実施するために重要となる。
項目 B.38 と B.39 は、各々の鍵タイプに対して、暗号鍵に関連付けられているメタデータがあ
るのか、ある場合にはどのようなメタデータが関連付けられているのか、どのよ うに関連付けられているのか、そして、何のためにそれが行われているのか、を把握することにポイントがあり、それを実現するために必要な機能要件を明確化することである。

32

ちなみに、関連付けを提供する保護メカニズムには、暗号学的プロセスを使用する場合と信頼プロセスを使用する場合とがある。直感的には、前者は、暗号鍵とメタデータの組で計算されたデジタル署名など、暗号アルゴリズムによって関連付けが保証される。後者は、信頼されるエン
ティティからのメタデータの対面手渡しやセキュアなストレージでの保管など、物理的な手段で関連付けが保証される。
留意するポイントとしては、B.38 と B.39 は「関連付け機能への要求事項」であるため、詳細な内容までを求めているわけではなく、そういった具体的な内容は D.02 以降で取りまとめられる。B.38 と B.39 は、D.02 以降に記載された暗号鍵とメタデータの関連付けを行う上で必要となる機能が用意されているか、整合的であるかの観点で確認することが重要である。

⑱ メタデータの変更機能への要求事項／⑲ メタデータの削除機能への要求事項／⑳ 暗号鍵のメタデータリスト化機能への要求事項
項目

FR 番号 Framework Requirements の内容

B.40 FR6.42

CKMS 設計は、関連付けられたメタデータが変更される状況を明記

SP800-130
6.4.11 節

しなければならない。
B.41 FR6.43

CKMS 設計は、鍵と関連付けられたメタデータが削除される状況を

6.4.12 節

明記しなければならない。
B.42 FR6.44

CKMS 設計は、関連付けられたメタデータを削除するために使われ6.4.12 節る手法を明記しなければならない。
B.43 FR6.45

それぞれの鍵タイプに対して、CKMS 設計は、どのメタデータが認

6.4.13 節可されたエンティティによってリスト化が可能かどうかを明記しなければならない。

解説・考慮点＜メタデータの変更機能＞認可されたエンティティが、暗号鍵と関連付けられている既存の書き込み可能なメタデータを変更するために使用する機能である。
項目 B.40 は、CKMS の設計にあたって、メタデータの変更機能が利用できる対象や条件、認可されていないエンティティの利用防止策等といったメタデータの変更機能への要求事項を明確化することを求めたものである。
＜メタデータの削除機能＞認可されたエンティティが、暗号鍵に関連付けられたメタデータを削除するために使用する機能である。
CKMS の設計にあたって、項目 B.41 は、メタデータの削除機能が利用できる対象や条件、認33

可されていないエンティティの利用防止策等といったメタデータの削除機能への要求事項を明確化することを求めたものである。B.42 は、具体的な削除方法の明確化することを要求したものである。
＜暗号鍵のメタデータリスト化機能＞
エンティティに認可されている暗号鍵のメタデータのリスト化を当該エンティティが実行するための機能である。
項目 B.43 は、CKMS の設計にあたって、メタデータリスト化機能が利用できる対象や条件といったメタデータリスト化機能への要求事項を明確化することを求めたものであ る。
前の要求事項でも記載したように、鍵タイプによってはメタデータとの組み合わせによりその暗号鍵の完全性を確保する場合もあるため、とりわけそのような鍵タイプの暗号鍵ではメタデー
タの管理も安全な鍵情報の管理を実施するために重要となる。つまり、暗号鍵だけでなく、メタデータも不用意に変更されたり削除されたりしないことが必要である。
そのためには、メタデータの完全性に影響するような処理を行えるエンティティを制限し、かつ認可されたエンティティであっても許可された範囲内、例えば自分の管理下にあるメタデータに対してのみ変更や削除、参照が行えるようにしておくことが望ましい。
項目 B.40 は変更権限を持つエンティティのみが決められた範囲内で変更機能を利用できるよ
うに、B.41 と B.42 は削除権限を持つエンティティのみが決められた範囲内で決められた方法による削除機能を利用できるように、それぞれのアクセス制御を行うために必要な要求事項の明確化を求めている。B.43 は、メタデータを一覧として参照できる権限を持つエンティティが決められた範囲内のメタデータのみ参照できるようにアクセス制御を行うために必要な要求事項の明確化を求めている。

《トイモデルと記載例》
本節のトイモデルも、2.1 節のトイモデルと同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムであり、暗号鍵のライフサイクルは 2.2 節のトイモデルで定めたものとする。

また、システムの運用条件を以下のように設定する。
【】内は記載例のどの項目に影響を与えているのかを示している。
⚫

鍵生成はメール送信 PC において信頼できる方法で生成し、プライベート鍵はライフサイ
クル全般を通じて PC 外部に複製されることはない。【B.04, B.22, B23】⚫

CA から公開鍵証明書を受信したときに、当該証明書の正当性を確認する。【B.27, B.28】⚫

公開鍵証明書の有効期間が始まった鍵は自動的に活性化状態となる。【B.04, B.06, B.07】⚫

署名の生成や検証は、メール送受信 PC のメール管理部でのみ行う。【B.08】⚫

署名付きメールを受信したとき、受信した公開鍵証明書の正当性を検証する。
【B.04, B.27
～B.29, B.36】
34

⚫

公開鍵証明書の有効期限切れした鍵は、自動的に非活性化状態になる。
【B.04, B.09～B.11】⚫

鍵の所有者が鍵を必要ないと判断したとき、手動で削除する。【B.04, B.20, B.21】⚫

情報システム部を介してパブリックな CA 局に署名を依頼することで、信頼できる証明書
チェーンを構築し、基本的なトラストアンカー管理は更新機能など OS の機能より実現する。【B.04, B.05, B.29～B.32, B.37】⚫

公開鍵証明書の運用管理は、情報システム部の担当者が行う。【B.12, B.33～B.35】⚫

鍵の危殆化が疑われるときは失効処理を行う。【B.04, B.13, B.14】⚫

鍵のバックアップ、アーカイブは行わない。【B.04】⚫

鍵とメタデータの関連付けは公開鍵証明書により行う（暗号学的プロセス）。
【B.38, B.39】⚫

メタデータの変更・削除・リスト化は認めない。【B.11, B.33, B.40～B.43】⚫

鍵の一時停止状態は設定しない。【B.04, B.15～B.19】⚫

鍵導出機能や鍵更新機能は使用しない。【B.04, B.24, B.25】⚫

対象鍵は使用しない。【B.04, B.26】

以上のトイモデルにおける記載例は、以下の「署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例」のようになる。
署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.04⚫

メール送信者 PC の鍵生成機能により、署名プライベート鍵と署名公開鍵を生成する。

⚫

公開鍵証明書の有効期間が開始したら、鍵活性化機能により、署名プライベート鍵と署名公開鍵を活性化状態にする。

⚫

メール送信者 PC の暗号機能により、メールのドキュメントに署名する。

⚫

メールを受信したら、メール送信者から送られてきたことを確認するために、メー
ル受信者 PC の暗号機能により署名の完全性を確認する。

⚫

公開鍵の検証機能により、署名公開鍵に対する公開鍵証明書に対する完 全性を確認し、公開鍵及びパラメタの検証を行う。

⚫

OS でのトラストアンカー管理機能により、ルート CA の公開鍵証明書を保管・管理する。情報の更新は、OS 又はブラウザの自動アップデートにより実施する。

⚫

公開鍵証明書の有効期間が終了したら、鍵非活性化機能により、署名プライベート
鍵と署名公開鍵を非活性化状態にする。

⚫

署名プライベート鍵と署名公開鍵は、破壊条件を満たした場合、破壊機能により、鍵を破壊する。

⚫

署名プライベート鍵の危殆化が疑われるときは、鍵失効機能により、署名プライベ
ート鍵の失効処理を行う。署名公開鍵についても同様の処理を行う。

⚫

利用者の管理は情報システム部が行うものとし、そのために必要な管理機能は情報システム部管理の機器により実現する。

⚫

暗号鍵とメタデータの検証及び関連付けについては、公開鍵証明書の申請段階で情報システム部がその正当性を検証するものとし、そのために必要な管理機能は情報システム部管理の機器により実現する。
35

参考：
⚫

一時停止状態は設定しないので、一時停止機能及び再活性化機能は使わない。

⚫

鍵生成では、鍵生成機能のみを利用するものとし、鍵導出機能／鍵更新機能は使わない。

⚫

対称鍵の生成・利用は行わないので、対称鍵の検証機能は使わない。

⚫

公開鍵の有効期間延長は認めないので、公開鍵の有効期間延長機能は使わない。

⚫

署名プライベート鍵が利用できなくなることによる影響は当該鍵の所有者だけであり、影響が局所的であるので、バックアップとアーカイブの処理は実施せず、これらの機能は使わない。

B.05

⚫

署名公開鍵と関連メタデータの完全性は、公開鍵証明書の CA 署名検証により確認する。

⚫

署名プライベート鍵の機密性は、OS のファイルアクセス機能により当該鍵を作成したユーザ以外が鍵ファイルにアクセスできないように管理することで実現する。

⚫

CA の署名公開鍵は OS の信頼できる公開鍵証明書（トラストアンカー）からなるチ
ェーンの有効性により完全性を確認する。

⚫

OS の信頼できる公開鍵証明書（トラストアンカー）の更新は、OS 又はブラウザの自動アップデートにより実行される。

B.06

CA の署名した公開鍵証明書が、OS の信頼できる公開鍵証明書（トラストアンカー）からなるチェーンの有効性確認で正当であり、かつ記載された有効期間になったら、署名
プライベート鍵と署名公開鍵は活性化状態に遷移する。

B.07

鍵活性化の通知は行わない。
メール送信者は CA が署名した公開鍵証明書の有効期間により活性化状態であることを認識できる。メール受信者は送信者の公開鍵証明書が有効期間内であることにより活性化状態であることを認識できる。

B.08

メールの署名は、メール送信 PC のメール管理部の管理下で実行される。
メールの署名検証は、メール受信 PC のメール管理部の管理下で実行される。

B.09

活性化状態の署名プライベート鍵と署名公開鍵は、公開鍵証明書の有効期間が終了すると非活性化状態へ遷移する。

B.10

署名プライベート鍵や署名公開鍵は、公開鍵証明書の有効期間が終 了すると OS の機能
及びメールアプリケーションの機能で、送信メールに署名ができなくなり、メールの署名検証も有効期限切れ表示になり、非活性化状態へ自動的に遷移する。

B.11

非活性化日時の変更は不可なので、対象外。

B.12

公開鍵証明書の有効期間が終了する一月前に、情報システム部の公開鍵証明書発行依頼の担当者が、メール送信者に証明書の有効期間の終了が近づいたので、新たに署名プラ
イベート鍵と署名公開鍵を生成し、証明書を再申請するように通知する。

B.13

⚫

以下の状況のいずれかが発生した場合は失効処理を行う。
➢

PC が保護されない状況で PC 利用者以外のエンティティがアクセス可能であ
った場合

36

➢

署名プライベート鍵に不正なアクセスがあったことを示すログが検出された場
合⚫

➢

メール送信者が認識していない署名付きメールの送信ログが確認された場合➢

その他、署名プライベート鍵の紛失・漏えいが疑われる事象が発生した場合

上記の事象が生じた場合、該当する署名プライベート鍵の所有者は情報システム部に連絡し、情報システム部は当該署名プライベート鍵に対応する署名公開鍵の公開
鍵証明書の失効処理を CA に依頼する。PC 利用者は当該署名プライベート鍵の使用を停止する。

⚫

メール受信者は B.14 の方法により配布される証明書失効リストを受信したら、OSの機能により該当する証明書を失効させる。

B.14

公開鍵証明書の失効を依頼された CA は、当該証明書に対する証明書失効リストを作成する。
通知は、CA から得た証明書失効リストを関係するエンティティに配布することにより行う。また、証明書に記載された OCSP にアクセスすることで失効情報を得ることも可
能である。

B.15

B.02 の通り、一時停止状態への遷移は設けないため、対象外。

B.16

同上

B.17

同上

B.18

同上

B.19

同上

B.20

署名プライベート鍵・署名公開鍵が非活性化状態になって一定期間が経過し鍵を必要とするケースはないと判断したとき、または危殆化状態の署名プライベート鍵・署名公開鍵について危殆化状態での管理を行う必要がないと判断したとき、署名プライベート鍵を OS の機能を使用して当該鍵の所有者が手動で削除することで当該鍵の破壊を行う。
署名プライベート鍵の破壊は局所的（Local）なものである。
署名公開鍵については公開鍵証明書にて管理されており、公開鍵証明書の有効期間の経過後、OS の証明書管理機能により自動的に削除され、破壊される。署名公開鍵の破壊
は局所的（Local）なものである。

B.21

鍵の破壊は B.20 で慎重に判断するので、通知は必要としないため、対象外。

B.22

署名プライベート鍵及び署名公開鍵の鍵生成は FIPS 186-4 で規定されている方法で生
成する。

B.23

乱数生成器は SP 800-90 で規定されている方法を使用し、乱数生成器で使用するエント
ロピーは Linux の乱数生成の疑似デバイスである/dev/random から得る。

B.24

鍵導出機能や鍵更新機能は使用していないため、対象外。

B.25

同上

B.26

対称鍵は利用しないため、対象外。

B.27

⚫

CA から公開鍵証明書を受信したとき、受信した PC で、署名公開鍵が FIPS 186-4
で規定されたドメインパラメタを使用していることを検証する。

37

⚫

署名付きメールを受信したとき、受信した PC で、一緒に受信した公開鍵証明書に記載された署名公開鍵が FIPS 186-4 で規定されたドメインパラメタを使用していることを検証する。

B.28⚫

CA から公開鍵証明書を受信したとき、受信した PC で、その証明書に記載された署
名公開鍵が、生成した署名プライベート鍵とペアになる公開鍵であることを検証する。

⚫

署名付きメールを受信したとき、受信した PC で、一緒に受信した公開鍵証明書を検証することにより、公開鍵を検証する。

B.29

⚫

CA から公開鍵証明書を受信したとき、受信した PC で、当該証明書について OS の信頼できる証明書パスを検証する。

⚫

署名付きメールを受信したとき、受信した PC で、一緒に受信した公開鍵証明書について OS の信頼できる証明書パスを検証する。

⚫

証明書失効リストを受信したときに、受信した PC で、当該リストを検証するために必要となる公開鍵証明書について OS の信頼できる証明書パスを検証する。

B.30

トラストアンカー管理機能は OS の証明書管理機能を使用する。

B.31

トラストアンカーの配布は独自に行わない。OS に標準で保存されているトラストアン
カーを使用する。トラストアンカーは信頼できる OS の更新機能により自動更新する。

B.32

トラストアンカーは信頼できる OS の更新機能により、自動的に追加、変更、削除を行う。緊急にトラストアンカーを修正したい場合、システム管理者が管理者権限により、OS の証明書管理機能で追加、変更、削除を行う。一般の利用者による追加、変更、削除はできない設定にする。

B.33

公開鍵の有効期間の延長は認めないため、対象外。

B.34

同上

B.35

メール送信者の CSR は組織内の情報システム部の公開鍵証明書発行依頼の担当者が所有者情報などを目視確認後、情報システム部から CA に CSR を送信し、CA から受信した公開鍵証明書は情報システム部が受信し、公開鍵証明書発行依頼の担当者が確認後にメール送信者に送られる。

B.36

メール受信者は、メールの署名を検証することで、一緒に受信した公開鍵証明書に記載された公開鍵とペアになる署名プライベート鍵をメール送信者が所持していることを
検証する。

B.37

新規公開鍵証明書の発行のために情報システム部の公開鍵証明書発行依頼の担当者がCSR を受け取ったときに、その担当者は CSR に保存されたメタデータと署名を確認
し、CSR 作成者がプライベート鍵の所有者であることを確認する。

B.38

鍵の有効期間、所有者情報（Subject）、key usage などのメタデータが、署名公開鍵に関連付けられ、署名公開鍵と一緒に公開鍵証明書に記載される。これらのメタデータと署名プライベート鍵とは、対応する署名公開鍵を介して関連付けられる。

B.39

署名公開鍵に関連付けられたメタデータは、公開鍵証明書に記載され、CA の署名により完全性が保護される。署名プライベート鍵は、ペアとなる署名公開鍵の保証により、完全性の関連付けが保証される。

38

B.40

メタデータの変更は認めないため、対象外。

B.41

メタデータの削除は認めないため、対象外。

B.42

同上

B.43

鍵メタデータのリスト化は認めないため、対象外。

2.4

鍵情報の保管方法①

保管中の鍵情報のセキュリティを確保するための手段の決定

項目

FR 番号 Framework Requirements の内容

B.44 FR6.73

CKMS 設計は、鍵情報（暗号鍵やメタデータ）をストレージに入れ

SP800-130
6.5 節

るエンティティの ID 認証及び認可検証に使用される手段を明記しなければならない。
B.45 FR6.74

CKMS 設計は、ストレージに入力する鍵情報（暗号鍵やメタデータ）

6.5 節の完全性検証に使用される手段を明記しなければならない。
B.46 FR6.75

CKMS 設計は、保管された対称鍵、プライベート鍵及びメタデータ

6.5 節の機密性保護に使用される手段を明記しなければならない。
B.47 FR6.76

鍵ラッピング鍵（又は鍵ペア）が保管された鍵を保護するために使6.5 節

用される場合、CKMS 設計は、鍵ラッピング鍵（又は鍵ペア）を保護し、その使用を制御するために使用される手段を明記しなければならない。
B.48 FR6.77

CKMS 設計は、保管された鍵情報（暗号鍵及びメタデータ）の完全

6.5 節

性保護に使用される手段を明記しなければならない。
B.49 FR6.78

CKMS 設計は、保管された鍵へのアクセスがどのように制御される

6.5 節

かを明記しなければならない。
B.50 FR6.79

CKMS 設計は、全ての保管された鍵を訂正又は復元するために使用

6.5 節

される手法を明記しなければならない。

解説・考慮点
鍵情報の保管にあたっては、全ての暗号鍵は完全性保護を、加えて対称鍵及びプライベート鍵
は機密性保護も必要とする。
また、認可されたユーザのみが保管された鍵情報にアクセスできるようにすべきであり、そのためのアクセスコントロールが必要である。
CKMS の設計にあたって、項目 B.44 及び B.45 は鍵情報を保管する時点での完全性保護を実現するための要求事項を、B.46～B.49 は保管中の鍵情報の完全性及び機密性の保護を実現するための要求事項を明確化することを求めたものである。B.50 は、保管中の鍵情報が破損した際
39

の対策を明確化することを要求したものである。
暗号アルゴリズムを安全に使う上で、（i）利用権限を有する正しいエンティティ（利用者）のみが暗号鍵を利用できること、（ii）暗号鍵の完全性が確保されていること、（iii）加えて対称鍵及びプライベート鍵は機密性が確保されていること、は絶対条件である。また、暗号鍵の可用性の観点では、（iv）利用権限を有する正しいエンティティ（利用者）は、暗号鍵の有効期間内はいつでも当該暗号鍵が利用できること、が求められる。
したがって、暗号鍵の保管にあたって、上記の要件を満たすように、鍵情報のセキュリティを確保するための手段を決める必要がある。なお、ここで決める手段は、後述の②以降で利用する手法を実現するものでなければならないことに留意されたい。
a）当該暗号鍵をストレージなどに保管する時：暗号鍵を保管する時点で、「偽物の暗号鍵」が正しく保管されてしまうと、その後の保護手段がいくら強固で正しく動作したとしても全く意味をなさない。そのようなことが起きないようにするには、「格納権限がある信頼できるエンティティ（利用者）」によって「正しい暗号鍵」が「正しく保管」されることが重要である。つまり、「 格納権限がある信頼できるエンティティ（利用者）」
であることを確認するための認証認可機能、「正しい暗号鍵」であることを確認するための完全性
検証機能、さらに対称鍵やプライベート鍵では秘密裏に「正しく保管」するための機密性保護機能が求められる。これらの機能を実現する具体的な手段を決めるよう求めたものが検討課題 B.44
～B.46 に該当する。
検討課題 B.47 は、暗号鍵の機密性保護のために当該暗号鍵の再暗号化を行う場合、再暗号化で利用する暗号鍵（鍵ラッピング鍵）も安全に管理・運用されていることが必要となるので、そのための必要となる機能を実現する具体的な手段を決めるよう求めている。
b）ストレージなどに保管された当該暗号鍵を利用する時：（i）の要件を満たすためには、利用権限を有する正しいエンティティ（利用者）のみが保管された暗号鍵にアクセスできることを保証するためのアクセス制御機能・認証認可機能が求められる。この機能を実現する具体的な手段を決めるよう求めたものが検討課題 B.49 となる。
また、ストレージなどでの保管中も、誤操作や故障、改ざん攻撃などによって、暗号鍵の完全性が損なわれないように保護することが必要である。例えば、誤り検知や攻撃検知などによって予期せぬ理由で暗号鍵が書き変わらないようにする、利用前には読み出した暗号鍵の完全性の検証を行う、などの対策が考えられる。このような、保管中の鍵情報の完全性保護機能を実現する
具体的な手段を決めるよう求めたものが検討課題 B.48 である。
検討課題 B.50 は、何らかの理由で保管された暗号鍵の完全性が損なわれた場合に、当該暗号鍵を正しい状態に復旧するための取られる方法を具体的に決めるよう求めたものである。例えば、誤りが検知された暗号鍵について訂正可能であれば適切な訂正を行い、訂正不能な場合には当該暗号鍵はしないようにするとか、暗号鍵のバックアップやアーカイブを行い、必要に応じて暗号鍵の復元に行うなどが考えられる。

40

最近はクラウドサービスを利用するケースも増えており、通常、クラウド上にあるデータに対する暗号処理もクラウド内で行われる。その際に利用する暗号鍵の管理・保管方法として、クラウド事業者に完全に任せる方式からクラウド利用者が自ら管理する方式までいくつかのやり方がある。代表的な方法として、クラウド事業者が全ての鍵管理を行う方式（ Cloud Native Encryption
Services）、鍵生成と管理はクラウド利用者が行うが暗号鍵の保管はクラウド事業者で行う方式（BYOK：Bring Your Own Key 9）、クラウド利用者が全ての鍵管理を行う方式（HYOK：Hold
Your Own Key 10）などがある。
これらの方式のうち、どのような方式を取るかによって暗号鍵に対するクラウド利用者の管理度合いやクラウド事業者に求めるセキュリティレベルが変わる。一般に、クラウド事業者に鍵管理を依存する方式になるほど暗号鍵管理に関する負荷を低減させることができる一方、その安全性はクラウド事業者に依存するようになる。反対に、クラウド利用者が自ら鍵管理を行う方式になるほど、安全性をクラウド事業者に依存しなくてすむようになるが、オンプレミスで暗号鍵を管理するのと同様の負荷が求められるようになる。
これらの詳細については、日本クラウドセキュリティアライアンスが発行している Cloud Data
Protection 11を参照されたい。
項目 B.44～B.50 は、暗号鍵の管理を CKMS 運用者が自ら実施することを前提としたときの暗号鍵の保管方法について CKMS 設計で考慮すべき項目となっている。したがって、クラウドサー
ビスを利用する場合には、どの部分の暗号鍵の管理をクラウド事業者に任せ、どの部分をクラウ
ド利用者自ら管理するのかを切り分けること（暗号鍵管理についての責任分界点を明確化すること）が最初にすることである。そのうえで、クラウド利用者自ら管理する必要がある部分については他と同様に検討し、クラウド事業者に任せる部分についてはクラウド事業者が提供する機能や利用するサービス内容などをわかる範囲で記載すればよい。
例えば、クラウド事業者が全ての鍵管理を行う方式であれば、B.44 や B.49 のアクセス制御に係る部分を重点的に検討し、利用権限を有する正しいエンティティ（利用者）のみが暗号鍵を使えるようにすればよい。その他の項目については、クラウド事業者に管理を委ねる部分になる。
一方、BYOK の場合は、B.44 と B.49 に加え、クラウド側に暗号鍵を移す際の方法（B.45）や暗号鍵の復元方法（B.50）についても検討することが必要となる。

利用者が暗号鍵を作成してクラウドサービスの CKMS に持ち込む方式
利用者が管理する CKMS をクラウドサービスが利用する方式。オンプレミスで実現する場合やクラウド事業者が機能提供する場合、その併用など、いろいろな実現形態がある。Microsoft Azure Double Key Encryption、
Google Cloud External Key Manager、Salesforce Cache-Only Key、Microsoft Azure Dedicated HSM、AWS
CloudHSM など
11 日本クラウドセキュリティアライアンス、Cloud Data Protection、
https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/08/Cloud_Data_Protection2_V10.pdf
9

10

41

②

運用中の鍵情報の保管場所及び保護方法の決定

項目

FR 番号 Framework Requirements の内容

B.51 FR6.46

それぞれの鍵タイプに対して、CKMS 設計は、以下のことを明記し

SP800-130
6.4.14 節

なければならない：それぞれの鍵タイプとそのメタデータが保管される状況、鍵とメタデータの保管場所、及び鍵とメタデータの保護方法。

解説・考慮点
運用中の鍵情報がどこに存在し、どのような保護状態に置かれているのかを全て明らかにしておく必要がある。
項目 B.51 は、CKMS の設計にあたって、鍵情報の保管場所や保護方法などの要求事項を明確化することを求めたものである。運用中の鍵情報は、B.51 で定めた保管場所以外に置かれない
ようにしなければならない。
運用中の暗号鍵は、ストレージなどに保管された状態から読み込まれ、メモリ上などに保存された状態で暗号処理に使われるのが一般的である。その際、暗号処理のスループットを上げるた
め、暗号鍵が平文の形で置かれることが多く、暗号鍵の漏えいリスクが高い場所の一つになっている。
そのため、暗号鍵の漏えいリスクの低減策として、運用中の暗号鍵がどこに存在し、どのように保護されているのかを把握しておくことが重要であり、項目 B.51 はそれらの情報を具体的に決めるよう求めたものである。例えば、一言に「メモリ上に保存される」といっても 、他のアプ
リケーションなどからも読み出せる汎用のメモリ上に置かれるのか、外部からの侵入が厳しく制限される暗号モジュール内のメモリ上に置かれるのかによって、その暗号鍵が置かれている保護状態は全く異なる。具体的には、前者は OS レベルでのアクセス制御による保護であるのに対して、後者は暗号モジュールが提供するアクセス制御のほか、当該暗号モジュールへの侵入検知による物理的防護などの保護が受けられる可能性がある。
なお、クラウドサービスでの運用中の鍵情報の管理方法について検討する必要があるかどうか
は、暗号鍵の保管方法と同様、暗号鍵を管理する主体がクラウド事業者なのかクラウド利用者なのかによって異なる。つまり、前者の場合、運用中の暗号鍵を安全に管理するのはクラウド事業者の責任となるので項目 B.51 は対象外としてよい。一方、後者の場合は、運用中の暗号鍵を安全に管理するのはクラウド利用者の責任となるので B.51 も検討しておく必要がある。

42

③

鍵情報のバックアップ方法の決定

項目

FR 番号 Framework Requirements の内容

B.52 FR6.47

CKMS 設計は、どのように、どこで、どのような状況において鍵及SP800-130
6.4.15 節

びそのメタデータがバックアップされるかを明記しなければならない。
B.53 FR6.48

CKMS 設計は、バックアップされた鍵情報（暗号鍵及びメタデータ） 6.4.15 節の保護のためのセキュリティポリシーを明記しなければならない。

B.54 FR6.49

CKMS 設計は、鍵情報（暗号鍵及びメタデータ）のバックアップ中

6.4.15 節のセキュリティポリシーがどのように実装されるかを明記しなければならない。例えば、バックアップされた鍵情報（暗号鍵及びメタデータ）の配送及び保管中における、機密性とマルチパーティコン
トロールの要求事項の実装方法。

解説・考慮点CKMS の設計にあたって、項目 B.52 は、鍵情報のバックアップを行うための条件を明確化することを、B.53 及び B.54 はバックアップされる鍵情報のセキュリティ、特に機密性保護を確保するための要求事項を明確化することを求めたものである。
なお、鍵情報のバックアップを実施しない場合には、検討対象外である。
運用中の暗号鍵が喪失、改変、又はその他の理由で利用不能状態になったときに、当該暗号鍵を復元できるようにするため、安全な設備・メディアなどにバックアップをする場合がある。バックアップをすることにより、暗号鍵が喪失、改変又はその他の理由で利用不能になった場合であっても、当該暗号鍵で保護されている情報まで喪失する事態を避けることが可能になる。一方、暗号鍵の複製を作ることでもあるので、暗号鍵の漏えいリスクを高めることにつながる。
したがって、ここでの項目を検討する前に、まずはバックアップを行うことによるメリットとデメリットを天秤にかけて、暗号鍵のバックアップを行うかどうかを決定することが重要である。
もしバックアップは行わないと決定した場合には、ここでの項目 B.52～B.54 は対象外となる。
一方、バックアップを行うと決定した場合には、できる限り、暗号鍵の複製を作ることによる漏えいリスクを低減する対策を検討する必要があり、そのためには、項目 B.52～B.54 の内容に沿って具体的なバックアップの条件や実施方法などを取りまとめておくことが重要である。特に、B.52 はバックアップを実施する条件を、B.53 はバックアップされる暗号鍵の保護方針を明確化することを求めており、バックアップを行う上での全体方針を決めるものである。この方針によって、バックアップのセキュリティが決まると言っても過言ではない。
B.54 は、B.53 の方針に沿った具体的なバックアップの実現方法を明確化することを求めている。
なお、B.52～B.54 では明確には求められていないが、バックアップした暗号鍵が使用されるこ43

とがなくなったとき、当該暗号鍵は復元できないように破壊されるべきである。バックアップス
トレージメディアに保管されている場合にはメディア内の暗号鍵を、コピーが存在する場合には当該コピーも含めて破壊することを、B.53 でのセキュリティポリシーの中に明記することを強く
推奨する。

④

鍵情報のアーカイブ方法の決定

項目

FR 番号 Framework Requirements の内容

B.55 FR6.50

CKMS 設計は、どのように、どこで、どのような状況で鍵情報（暗SP800-130
6.4.16 節

号鍵やメタデータ）がアーカイブされるかを明記しなければならない。
B.56 FR6.51

CKMS 設計は、鍵情報（暗号鍵やメタデータ）のセキュアな破壊、

6.4.16 節

又は新しい保管メディアに書き込まれた後の古い保管メディアのセ
キュアな破壊のための手法を明記しなければならない。
B.57 FR6.52

CKMS 設計は、アーカイブ鍵の暗号鍵有効期間（cryptoperiod）の6.4.16 節

期限切れ後に、鍵情報（暗号鍵やメタデータ）がどのように保護されるかを明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.55 は、鍵情報のアーカイブを行うための条件を明確化する
ことを、B.56 はアーカイブされた鍵情報を破棄するための要求事項を明確化することを、B.57
は機密性保護の継続性を確保するための要求事項を明確化することを求めたものである。
なお、鍵情報のアーカイブを実施しない場合には、検討対象外である。
バックアップが、「運用中の暗号鍵」が喪失、改変又はその他の理由で利用不能状態になった時の「復元対策」であるのに対して、アーカイブは、「運用中の暗号鍵かどうかに関わりなく」、法律や規則等で要求される期間中、必要に応じて、当該暗号鍵を復元できるようにしておく「長期保管対策」である。
バックアップもアーカイブも、暗号鍵の複製を作ることで漏えいリスクを高めることにつながるという点では同じであるが、バックアップが比較的頻繁に復元を行うことが想定され ているのに対して、アーカイブは長期保管用ストレージ設備などに保管され、限定的な条件下でのみ復元されることが想定されている点が異なる。
アーカイブは、適用される法律や規則等も考慮して最小限の範囲で実施し、暗号鍵の複製を作ることによる漏えいリスクを低減する対策を検討する必要がある。
なお、バックアップと比較して、復元頻度が少なく、長期保管が想定されることから、可用性
よりも機密性保護を優先して対策を考えるべきである。例えば、鍵分割による保護、アーカイブ
鍵による暗号鍵の再暗号化、物理的に保護される装置内での保管、 などがある。また、アーカイ44

ブする必要がなくなれば、当該暗号鍵が復元できないようにそのアーカイブは破壊されるべきである。
項目 B.55 は、暗号鍵のアーカイブを行うための条件や保護方針を明確化することである。
鍵情報のアーカイブを実施しない場合には、ここでの項目 B.55～B.57 は対象外となる。一方、アーカイブを実施する場合には、アーカイブされた暗号鍵は、アーカイブされている期間、物理的又は暗号学的に保護されなければならない。また、保管メディアにアーカイブする作業中に、アーカイブする暗号鍵が露見しないように対策を取る必要がある。これらの方針を明確化することにより、アーカイブを行う上での全体方針を決めるものである。この方針によって、アーカイ
ブのセキュリティが決まると言っても過言ではない。
B.56 は、アーカイブされた暗号鍵、もしくは当該暗号鍵がアーカイブされている保存媒体そのものを破壊するための要求事項を明確化することを求めたものである。また、B.57 は、アーカイブ鍵による暗号鍵の再暗号化によって機密性保護を行っているケースにおいて、アーカイブ鍵のほうが先に有効期間切れになった時に、機密性保護の継続性を確保するための要求事項を明確化することを求めたものである。例えば、アーカイブ鍵の暗号鍵有効期間が期限切れになる前の再暗号化や、新しいセキュアな保存メディアへの移動などである。

⑤

鍵情報の復元方法の決定

項目

FR 番号 Framework Requirements の内容

B.58 FR6.53

CKMS 設計は、鍵情報（暗号鍵やメタデータ）の CKMS 復元ポリシ

SP800-130
6.4.17 節

ーを明記しなければならない。
B.59 FR6.54

CKMS 設計は、鍵情報（暗号鍵やメタデータ）の復元ポリシーを実

6.4.17 節

装及び実行するために使用されるメカニズムを明記しなければならない。
B.60 FR6.55

CKMS 設計は、どのように、どのような状況で鍵情報（暗号鍵やメ

6.4.17 節

タデータ）がそれぞれの鍵データベース又はメタデータ保管設備から復元されるかを明記しなければならない。
B.61 FR6.56

CKMS 設計は、鍵情報（暗号鍵やメタデータ）が復元中にどのよう

6.4.17 節に保護されるかを明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.58～B.61 は、バックアップやアーカイブされた鍵情報を復元するための条件や復元方法、要求事項を明確化することを求めたものである。
バックアップやアーカイブされている暗号鍵を復元することは、当該暗号鍵のコピーを利用可
能にする行為であるから、万が一にも不適正に復元が行われれば、即、当該暗号鍵の漏えいにつ45ながるほど危険な行為となる。したがって、バックアップやアーカイブからの復元が不適正に行われることがないように、厳格な復元ルールを規定し、そのルールが全て満たされていることを検証された後に、認可されたエンティティ（利用者）によって復元できるようにすべきである。
項目 B.58 は、復元ポリシーとして復元を実行するために必要なルールを定めることを求めている。B.59 はそのルールを守られるように具体的にどのように実装し、実行するのかを具体化す
ること、B.60 は復元処理を行う際の保管メディアへのアクセス条件を明確化することを求めている。また、B.61 は、予定外の場所で暗号鍵が露見しないような対策を求めたものである。
なお、ここで実現されるセキュリティ水準は、バックアップやアーカイブで実現されるセキュ
リティ水準と整合的であることが重要である。また、バックアップとアーカイブのどちらも実施しない場合には、本項目 B.58～B.61 は対象外である。

《トイモデルと記載例》
本節のトイモデルも、2.1 節のトイモデルと同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムであり、暗号鍵のライフサイクルは 2.2 節のトイモデルで定めたものとする。
なお、このトイモデルでは、暗号鍵が喪失、改変、又はその他の理由で利用不能状態になったとしても影響範囲が限定的（署名生成ができなくなるだけでその他に影響しない）であるため、
鍵情報のバックアップとアーカイブのどちらも実施しないこととする。鍵情報の喪失や破損が発生したときは、新たな暗号鍵を再生成し公開鍵証明書を発行し直す。このため、バックアップとアーカイブに関連する項目は対象外となる。
また、暗号鍵の保管に関する運用条件を以下のように設定する。
【】内は記載例のどの項目に影響を与えているのかを示している。
⚫

鍵 情 報 の 機 密 性 保 護 や 完 全 性 保 護 は 、 OS の ア ク セ ス コ ン ト ロ ー ル シ ス テ ム （ ACS:
Microsoft Windows の ACL、Linux のパーミッション機能）により保護する。
【B.44, B.46,
B.48】

⚫

ストレージに入力する鍵情報において、署名プライベート鍵は証明書の公開鍵とペアになっていることを確認し、メタデータは証明書の内容と一致することを確認する。【B.45】⚫

OS の ACS により、基本的に鍵を生成したユーザ以外、鍵情報にアクセスできない。
【B.49,
B.51】⚫

暗号鍵のバックアップとアーカイブは実施しない。【B.52～B.61】⚫

保管していた鍵が使用できなくなった場合の復元手段は用意しない。【B.50】⚫

保管された鍵を保護するために鍵ラッピング鍵や鍵ペアは使用しない。【B.47】

以上のトイモデルにおける記載例は、以下の「署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例」のようになる。
46

署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.44

PC にログイン ID 及びパスワードを設定し、その ID 及びパスワードによる利用者認証を通過したエンティティに対してのみ、OS のアクセスコントロールシステム（ACS:
Microsoft Windows の ACL、Linux のパーミッション機能）による自分が管理する鍵情報へのアクセス権限を付与する。
なお、システム管理者は、管理者 ID 及び管理者パスワードによる利用者認証でログインした場合に限り、例外的に全ての利用者の鍵情報に対してアクセス権限（Microsoft
Windows の管理者権限、Linux の root 権限）が付与される。

B.45

ストレージに入力する署名プライベート鍵は、公開鍵証明書に記載された公開鍵とペアになっていることを確認し、当該証明書の CA 署名を検証することで完全性を検証する。

B.46

署名プライベート鍵と関連するメタデータは B.44 に記載した ACS により機密性を保
護する。

B.47

保管された鍵を保護するために鍵ラッピング鍵や鍵ペアを使用しないため、対象外。

B.48

署名プライベート鍵と関連するメタデータは B.44 に記載した ACS により完全性を保
護する。

B.49

署名プライベート鍵は B.44 に記載した利用者認証及び ACS を使用することで、システム管理者を除き、当該鍵を作成したユーザ以外はアクセスできない。

B.50

署名プライベート鍵の訂正や復元するための手段は用意しないため、対象外。

B.51

署名プライベート鍵、署名公開鍵や CA 署名公開鍵は署名するユーザの PC の内臓スト
レージに保管する。これらの鍵は B.44 に記載した ACS で保護される。また、署名や検証するときに一時的に当該 PC のメモリ上に置かれるが、これは OS のプロセス間メモ
リ保護機能により保護される。

B.52

鍵情報のバックアップは実施しないため、対象外。
署名プライベート鍵や署名公開鍵が利用不能になった場合、その鍵の失効処理を行う。
また、必要に応じて、新たな鍵ペアを再生成し公開鍵証明書を発行する。

B.53

同上

B.54

同上

B.55

鍵情報のアーカイブは実施しないため、対象外。

B.56

同上

B.57

同上

B.58

鍵情報のバックアップとアーカイブのどちらも実施しないため、対象外。

B.59

同上

B.60

同上

B.61

同上

47

2.5

鍵情報の鍵確立方法①

鍵確立機能の利用局面の特定項目

FR 番号 Framework Requirements の内容

B.62 FR6.57

CKMS 設計は、どのように、どのような状況で鍵及びそのメタデー

SP800-130
6.4.18 節

タが確立されるかを明記しなければならない。

解説・考慮点
項目 B.62 は、CKMS の設計にあたって、鍵確立機能を利用する状況を特定することを要求したものである。
鍵確立（key establishment）機能とは、2 つ又はそれ以上のエンティティ間で暗号鍵をセキュアに共有するプロセスのことであり、方法として以下の 2 つがある。
⚫

鍵配送（key transport）：
一方のエンティティが共有する暗号鍵を生成し、当該暗号鍵及び（あれば）メタデータを他方のエンティティに配付する。

⚫

鍵合意（key agreement）：
両方のエンティティが共有鍵を導出するために使用される情報を共有し、当該情報から暗号鍵を導出する。

鍵確立が行われるタイミングは、「盗聴」という手段－すなわち、鍵確立に係る正当なエンティ
ティに検知されない手段－で第三者が暗号鍵を窃取できる唯一のタイミングである。したがって、
鍵確立を行うとき、（i）確立される暗号鍵が誤りなく、正しく共有されること（暗号鍵の完全性）が求められるだけではなく、（ii）関係するエンティティが全員正当であることの確認と（iii）セキュアな通信路での通信による暗号鍵の機密性保護が極めて重要である。
項目 B.62 は、CKMS の設計にあたって鍵確立機能を利用する状況を特定することで、鍵確立
がいつ、どのように行われるのかを把握し、以降の②～⑤についての検討を忘れないようにすることを目的としている。②～⑤はいずれも（i）～（iii）の目的を達成するために必要な要求事項に関連するものである。
なお、鍵情報の鍵確立を使う状況がなければ、2.5 節の全て、すなわち B.62～B.70 全てが検討対象外となる。

48

②

鍵配送における鍵情報のセキュリティを確保するための要求事項

項目

FR 番号 Framework Requirements の内容

B.63 FR6.80

CKMS 設計は、配送中の対称鍵及びプライベート鍵の機密性保護に

SP800-130
6.6.1 節使用される手段を明記しなければならない。
B.64 FR6.81

CKMS 設計は、配送された鍵の完全性保護に使用される手段、及び

6.6.1 節

エラー検出後にどのように鍵が再構築又は置き換えられるのかを明記しなければならない。
B.65 FR6.82

CKMS 設計は、配送される鍵素材（keying material）の鍵受信者に、 6.6.1 節
どのように鍵送信者の識別子（ID）が認証されるかを明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.63 は鍵配送における機密性保護のための要求事項を、B.64
は完全性保護のための要求事項を、B.65 は鍵送信者を確認するための要求事項を明確化することを求めたものである。
なお、鍵情報の鍵配送を使う状況がなければ検討対象外である。
鍵情報の鍵配送には、郵便・宅配便などの物理的手段を使う場合と、ネットワークを介する電子的手段を使う場合がある。いずれの手段であっても、全ての暗号鍵は完全性保護を、加えて対称鍵及びプライベート鍵は機密性保護も必要とする。
機密性保護の観点からは、物理的保護が行われる手段か、対称鍵ラッピング鍵又はひとつ以上の非対称配送鍵ペアが関わる鍵配送手段が使用される。前者であれば信頼できる仲介者が必要であり、後者であれば当該ラッピング鍵や配送鍵が配送に関わるエンドエンティティによって保護されたうえで信頼できる鍵配送手段が必要となる。項目 B.63 はこれらの要件に対応するために利用する手段を明確化することを目的としたものである。
完全性保護の観点からは、暗号鍵の送信者が信頼できることと、暗号鍵に改ざんやエラーがな
いことが求められる。したがって、配送された暗号鍵の受信者に対して、期待する認可された鍵
送信者から当該暗号鍵が来たことを保証できることが必要である。また、暗号鍵の完全性検証を実行し、訂正可能な破損が検出された場合には適切な訂正を行い、訂正不能な破損が検出された場合には使用前に新しい又は訂正された暗号鍵を再確立する必要が ある。
項目 B.64 は暗号鍵に改ざんやエラーがないことを確認するために利用する手段を、B.65 は鍵
送信者が正当であることを鍵受信者が確認できるための方法を、それぞれ明確化することを目的としたものである。
なお、鍵情報の鍵配送を使う状況がなければ、B.63～B.65 は検討対象外である。

49

③

鍵合意における鍵情報のセキュリティを確保するための要求事項

項目

FR 番号 Framework Requirements の内容

B.66 FR6.83

CKMS 設計は、CKMS にサポートされるそれぞれの鍵合意スキーム

SP800-130
6.6.2 節を明記しなければならない。
B.67 FR6.84

CKMS 設計は、鍵合意に参加するそれぞれのエンティティがどのよ6.6.2 節うに認証されるかを明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.66 は鍵合意プロセスの手法について明確化することを、B.67
はエンティティの認証方法について明確化することを要求したものである。
なお、鍵情報の鍵合意を使う状況がなければ検討対象外である。
セキュアな鍵合意プロセスを利用する場合、そのプロセスに関与するそれぞれのエンティティ
は合意鍵を導出するために使われるある種の情報を提供しあうことで自ら合意鍵を生成することができるが、当該プロセスに関与していないエンティティは提供しあっている情報全て得たとしても合意鍵を得ることができない。逆に言えば、不正なエンティティに合意鍵を窃取されないた
めには認可されていないエンティティが鍵合意プロセスに不正に入り込むことを防止することが絶対条件となる。そのため、典型的には、鍵合意プロセスに参加する各エンティティは他方のエンティティ識別子の保証を必要とする。
項目 B.66 は鍵合意プロセスの手法について明確化することでセキュアな鍵合意プロセスであることを把握するため、また B.67 はエンティティの認証方法について明確化することで不正なエンティティに入り込むのを防止することを目的としたものである。
なお、鍵情報の鍵合意を使う状況がなければ、B.66 と B.67 は検討対象外である。

④

鍵確認機能を利用するための要求事項

項目

FR 番号 Framework Requirements の内容

B.68 FR6.86

CKMS 設計は、それぞれの鍵確認が実行される状況を明記しなけれ

SP800-130
6.6.3 節ばならない。
B.69 FR6.85

CKMS 設計は、他方のエンティティと正しい鍵を確立したことを確

6.6.3 節認するために使用されるそれぞれの鍵確認手段を明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.68 は鍵確認を行うための条件を明確化することを、B.69 は50

鍵確認の手法について明確化することを求めたものである。
なお、鍵確立した鍵情報の鍵確認を行う状況がなければ検討対象外である。
鍵確認機能は、鍵確立機能で共有された暗号鍵について、それぞれのエンティティが、実際に他方のエンティティが正しい暗号鍵を確立したことの確認をするために使用する機能である。
実際の暗号処理で利用する前に共有された暗号鍵を鍵確認することにより、何らかの理由で誤った暗号鍵が生成されたり、暗号鍵がうまく共有できなかったりした場合であっても、実害が発生する前に当該暗号鍵の利用を止めることが可能となる。
項目 B.68 はどのような状況のときに鍵確認が行うのかを把握することを、B.69 は鍵確認の手法について明確化することを求めたものである。
なお、鍵確立した鍵情報の鍵確認を行う状況がなければ、B.68 と B.69 は検討対象外である。

⑤

利用する鍵確立プロトコルの決定

項目

FR 番号 Framework Requirements の内容

B.70 FR6.87

CKMS 設計は、鍵確立と保管の目的のために CKMS によって採用

SP800-130
6.6.4 節されている全てのプロトコルを明記しなければならない。

解説・考慮点
項目 B.70 は、CKMS の設計にあたって、利用する鍵確立プロトコルを全て明確化することを要求したものである。ここで、定められた以外の鍵確立プロトコルを利用してはならない。
鍵確立で利用する通信路はセキュアであることが求められるので、CKMS 設計ではセキュアなプロトコルであることが確認されたものだけを使うべきである。項目 B.70 は、このことを確認する目的で、利用する鍵確立プロトコルを全て明確化することを求めたものである。
セキュアな鍵確立プロトコル、あるいは鍵確立機能を含んだプロトコルとして、代表的なもの
として以下のものある。
⚫

Internet Key Exchange（IKE）⚫

Transport Layer Security（TLS）⚫

Kerberos⚫

Over-The-Air-Rekeying（OTAR）Key Management Messages⚫

Secure Shell（SSH）

なお、鍵確立プロトコル自体は相互接続性の要求が強く求められることもあることから、「必ずしもセキュアとは言えないが相互接続性を実現するために必要」とされる手順や暗号アルゴリズ

51

ムもデフォルトで選択できるようになっていることがある。しかし、これらの手順や暗号アルゴ
リズムは真に必要な場合を除いて利用するべきではないので、意図せずに誤って利用することがないよう、CKMS 設計の段階でデフォルトでは使えないように設定しておき、真に必要な場合には「例外として意図的に設定変更する」ようにすることが重要である。
鍵確立プロトコルでの設定については、安全性と相互接続性のバランスを踏まえた推奨の設定
ガイダンスが公開されているものも多い。そのようなガイダンスでは、「相互接続性を実現するために含まれたセキュアとは言えない手順や暗号アルゴリズム」はデフォルトでは使えないようにするための設定オプションが記載されている。
したがって、それらのガイダンスが存在する場合にはその設定に従うことで、セキュアな鍵確
立プロトコルを確保できる。例えば、「TLS 暗号設定ガイダンス」や「SP 800-57 Part 3」などを参照されたい。

《トイモデルと記載例》
2.1 節と同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムであり、暗号鍵のライフサイクルは 2.2 節で定めたトイモデルでは、暗号鍵の鍵配送及び鍵合意は使用しないため、B.62～B.70 は対象外となる。

署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.62

B.02 の通り、暗号鍵の鍵配送及び鍵合意は使用しないため、対象外。

B.63

同上

B.64

同上

B.65

同上

B.68

同上

B.69

同上

B.70

同上

2.6

鍵情報の喪失・破損時の BCP 対策①

鍵情報の喪失・破損に対する BCP 対策の決定

項目

FR 番号

B.71 FR10.11

Framework Requirements の内容
CKMS 設計は、暗号鍵及びそのメタデータをバックアップ及びア

SP800-130
10.7 節ーカイブするための手続きを明記しなければならない。
B.72 FR10.12

CKMS 設計は、保管又は伝送された破損した鍵情報（暗号鍵及びメタデータ）を復元又は置き換えるための手続きを明記しなければ
ならない。

52

10.7 節解説・考慮点
CKMS の設計にあたって、項目 B.71 は、BCP 対策として必要な鍵情報のバックアップを行うための手続きや要求事項を明確化することを、B.72 は BCP 対策として復旧を行うための手続
きや要求事項を明確化することを求めたものである。なお、これらの項目で定めたことは B.52
～B.61 の上位規定として機能し、B.52～B.61 の内容が B.71 及び B.72 の内容に矛盾してはならない。
鍵情報（暗号鍵やメタデータ）が喪失又は破損した場合で、バックアップもアーカイブもされていなかった場合、当該暗号鍵で保護されているデータの喪失につながる可能性がある。
とりわけ重大な災害は、多数の運用中の鍵情報の喪失又は破損を一気に引き起こす可能性が高い。この場合の BCP 対策として、鍵情報のバックアップやアーカイブは有効な手段であり、鍵情報の正当な復元を行うことで保護されているデータの喪失を防止することができる。その他のよくあるケースとしては、エンティティ（利用者）の誤操作や過失などによって、当人の鍵情報が破損したり紛失したりする場合があり、必要に応じて、バックアップからの復旧が求められることがある。
一方、バックアップやアーカイブからは要求したエンティティに対して復元した鍵情報を提供することになることから、万が一にも、そのエンティティが正しいエンティティでなかったり、正当な権限を持っていなかったりした場合は、復元要求を拒絶しなければならない。
また、鍵情報の喪失・破損の原因が紛失や攻撃など人為的な要因に起因する場合は、特に鍵情報の外部への流出などが否定できず、結果として当該暗号鍵で暗号化されていたデータの危 殆化につながる可能性がある。この場合には、バックアップから単に当該鍵情報の正当な復元を行う
だけでは不十分であり、当該暗号鍵の利用停止や失効処理、潜在的なリスク評価、新しい暗号鍵への置き換え及びデータの再暗号化といった、0 節の対応を含む一連の BCP 対策が必要となる。
そのため、鍵情報の喪失や破損時の BCP を実現するためにどのような対策が必要かを検討し、その結果、鍵情報のバックアップやアーカイブを行うこととした場合には、バックアップやアーカイブの方針をまず定める必要がある。この方針を具体化するものとして、項目 B.71 では、BCP対策として必要な鍵情報のバックアップを行うための手続きや要求事項の明確化を、B.72 は BCP対策として復旧を行うための手続きや要求事項の明確化を求めている。なお、これらの 項目で定めたことは B.52～B.61 の上位規定として機能することから、B.52～B.61 の内容は B.71 及びB.72 の内容に沿って設定されなければならず、また矛盾していないことを確認することが重要である。

《トイモデルと記載例》
2.1 節と同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムであり、暗号鍵のライフサイクルは 2.2 節で定めたトイモデルにおいて、2.3 節で定めた運用条件を行った場合、BCP を実現するための鍵情報のバックアップとアーカイブのどちらも実施しないことになっている。また、鍵情報の喪失や破損が発生したときは新たな暗号鍵を再生成し公開鍵証明書
53

を発行し直す。
このようなトイモデルでは、鍵情報の喪失・破損時の BCP 対策が必要ないため、B.71 と B.72
は対象外となる。

署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.71

B.02 の通り、鍵情報のバックアップとアーカイブのどちらも実施しないため、対象外。

B.72

同上

2.7

鍵情報の危殆化時の BCP 対策① 暗号鍵の危殆化に対する BCP 対策の決定／②
BCP 対策の決定
項目

FR 番号

B.73 FR6.102

メタデータの危殆化に対するFramework Requirements の内容
CKMS 設計は、システムによって使用されているそれぞれの鍵タ

SP800-130
6.8.1 節イプの受け入れ可能な暗号鍵有効期間（cryptoperiod）又は利用制限（usage limit）の範囲を明記しなければならない。
B.74 FR6.103

それぞれの鍵に対し、CKMS 設計は、セキュリティがその鍵に依

6.8.1 節存する他の鍵タイプを明記しなければならず、また初期鍵の危殆化が発生した時にそれに依存する鍵がどのように置き換えられるかを明記しなければならない。
B.75 FR6.104

CKMS 設計は、鍵が危殆化したときに他の危殆化した鍵を特定で6.8.1 節きるための手段を明記しなければならない。例えば、鍵導出鍵が危殆化したとき、導出された鍵をどのように特定するのか？
B.76 FR6.105

導入されたそれぞれの鍵タイプに対して、CKMS 設計は、どのメ6.8.2 節

タデータ要素が危殆化（機密性、完全性、又はソース）しやすいのかを明記しなければならない。
B.77 FR6.106

CKMS 設計は、鍵のそれぞれの危殆化しやすいメタデータ要素に

6.8.2 節危殆化（機密性、完全性、又はソース）が起こったときに、起こり得るセキュリティ結果を明記しなければならない。
B.78 FR6.107

CKMS 設計は、それぞれの危殆化しやすいメタデータ要素での危6.8.2 節

殆化からどのように回復できるかを明記しなければならない。

解説・考慮点
そもそも全ての潜在的なセキュリティ問題を CKMS が防止し鍵情報の危殆化が発生しないよ
うにすることは現実的でないことを前提として、CKMS の設計においては鍵情報の危殆化を速54

やかに検知できるようにすべきである。
鍵情報の危殆化が検知された場合、次のステップを参考に、適切な当事者に危殆化を警告し、望ましくない影響を軽減し、最後にセキュアな状態に復帰することが必要である。
a)

その原因及び範囲を決定するために危殆化を評価

b)

鍵情報（暗号鍵やメタデータ）の露出を最小化するために危殆化軽減手段を実行

c)

危殆化の再発を防止するために適切な是正手段を実施

d)

CKMS をセキュアな運用状態に復帰させる＜暗号鍵の危殆化＞
CKMS の設計にあたって、項目 B.73 は暗号鍵に対する暗号鍵有効期間の設定や利用範囲の制限について明確化することを、B.74 は危殆化した暗号鍵（の鍵タイプ）だけでなく連鎖的に影響を受ける可能性がある別の暗号鍵（の鍵タイプ）を含めてどのような BCP 対策を行うかを明確化することを要求したものである。B.75 は、危殆化した暗号鍵から連鎖的に影響を受ける別の暗号鍵の特定方法の明確化を要求したものである。
＜メタデータの危殆化＞
CKMS の設計にあたって、項目 B.76 はメタデータの中でも危殆化が起こりやすい又は関連する暗号鍵の危殆化につながりやすいものがどれであるかを明確化することを、B.77 はメタデー
タに危殆化が起きた時にどのような影響が出るかを明確化することを要求したものである。
B.78 はどのような BCP 対策を行うかを明確化することを要求したものである。
暗号鍵の危殆化の影響は鍵タイプ及び鍵の用途に依存し、以下の結果をもたらし得る。
⚫

機密性の喪失⚫

完全性の喪失

⚫

認証の喪失

⚫

否認防止の喪失⚫

これらの喪失の組み合わせ

一般に、暗号鍵が危殆化した場合には、当該暗号鍵の利用を停止し、新しい暗号鍵に置き換えるとともに、すでに暗号処理（暗号化や署名生成）が行われた情報に対しては個別にその正当性の判断を行うことになる。これらは、危殆化状態への遷移に相当し、B.13 や B.14 で決められた手段が取られる。
しかしながら、危殆化した暗号鍵の使われ方によっては、当該暗号鍵で保護されたデータに対してだけでなく、当該暗号鍵が保護する他の多くの暗号鍵についても危殆化を連鎖的に引き起こす可能性があることに留意されたい。例えば、システムマスター鍵 など、上位の暗号鍵が危殆化すればシステム全体に影響が及ぶ可能性があり、鍵ラッピング鍵が危殆化すれば当該鍵で暗号化された鍵情報に影響が及ぶ。このような場合、危殆化した暗号鍵の失効・置き換えはもとより、
55

当該暗号鍵に依存して影響を受ける他の暗号鍵も可能な限り速やかに失効・置き換えを行うべきである。なお、暗号鍵の置き換えに伴い、データの再暗号化が必要となる場合もある。
また、暗号鍵の生成や更新に鍵導出手段を使っている場合、鍵導出手段に入力する元の暗号鍵が危殆化すると、それ以降に導出される暗号鍵も全て危殆化している。したがって、このような場合には、鍵導出手段を使うのではなく、改めて新しい暗号鍵を独自に生成し直す必要がある。
そこで、項目 B.74 と B.75 は、暗号鍵が危殆化した場合にどの程度の他の暗号鍵に影響を与える可能性があるかを、暗号鍵ごとに把握しておき、さらに BCP 対策として影響を受ける可能性がある暗号鍵の更新方法までを決めておくことを求めている。具体的には、B.74 は、危殆化した暗号鍵から連鎖的に影響を受ける可能性がある別の暗号鍵を含めてどのような BCP 対策を行い、暗号鍵を使う処理を再開するのかを明確化することを、B.75 は危殆化した暗号鍵から派生して生成される別の暗号鍵の特定方法の明確化を要求したものである。なお、鍵導出機能などを使わない場合には B.75 は対象外である。
暗号鍵の危殆化の影響を小さくするために、使用するそれぞれの暗号鍵に対して適切な暗号鍵
有効期間の設定や利用範囲の制限をすることで、暗号鍵の危殆化のリスクを低減することも重要である。一般的には、対称鍵ラッピング鍵、鍵配送鍵、及び鍵合意鍵の暗号鍵有効期間を実用的な最短期間にしておくことがよい。この他、鍵導出鍵とマスタ鍵も定期的に変更したほうがよい。
項目 B.73 は、暗号鍵の鍵タイプごとに有効期限や利用範囲を具体的に定めることを求めており、その範囲内で該当する暗号鍵を生成・利用するようにすることで、暗号鍵の危殆化の影響を小さくすることを目的としている。
メタデータの危殆化は、メタデータ要素及びその使われ方に依存して、暗号鍵の危殆化や当該暗号鍵によって保護されるデータの危殆化につながる可能性がある。項目が B.76 と B.77 は、メタデータのうち、どのデータが危殆化しやすいのか、さらにそのデータの危殆化が起きたら関連する暗号鍵にどのようなことが起きうるのかを具体的に把握することを求めている。B.78 は、危殆化状態からの復旧方法についての具体化を求めており、例えば、暗号鍵自体は危殆化していな
いことが確認でき、危殆化したメタデータの内容だけを更新すれば、当該暗号鍵の利用を再開できるようなケースで利用することを想定している。

③

役員・従業員によるセキュリティ危殆化に対する BCP 対策の決定

項目

FR 番号

B.79 FR6.117

Framework Requirements の内容
CKMS 設計は、それぞれのサポートされる役割に提供される、あSP800-130
6.8.7 節らゆる役員・従業員による危殆化の検知機能を明記しなければならない。
B.80 FR6.118

CKMS 設計は、それぞれのサポートされる役割に提供される、あらゆる役員・従業員による危殆化を最小化する機能を明記しなければならない。

56

6.8.7 節

B.81 FR6.119

CKMS 設 計 は 、 そ れ ぞ れ の サ ポ ー ト さ れ る 役 割 に 提 供 さ れ る 、

6.8.7 節CKMS 危殆化からの回復能力を明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 B.79 及び B.80 は役員・従業員によるセキュリティ危殆化への事前対策としての要求事項を明確化することを求めたものである。B.81 は危殆化が検知された
後にどのような BCP 対策を行うかを明確化することを要求したものである。
CKMS のセキュアな運用に責任のある人間が、与えられた権限を悪用し、自らそのセキュリテ
ィを危殆化させる場合がある。そのような事態への対策としては、基本的に権限必要最小限ルールの徹底が重要であり、必要な人に必要な権限しか与えない、権限を悪用していないかを監査する、操作ログを隠蔽できないようにする、といった事前対策が重要となる。
また、役員・従業員によるセキュリティ危殆化が発生した場合には、あらかじめ決められた情報セキュリティポリシー及び CKMS 機能に基づいて、以下のような回復手続きで対応・復旧することが重要である。さらに、再発防止策としてのセキュリティポリシーや運用規程等の改訂もあり得る。
⚫

システムの完全なシャットダウン⚫

新しい暗号鍵によるバックアップ設備及びシステムの活性化⚫

起こり得るセキュリティ障害についての現在及び潜在的ユーザへの通知⚫

危殆化した暗号鍵へのフラグ付け・失効処理

項目 B.80 は上記に示したような事前対策に関する方針を実現するための手段を具体的に示すことを、B.81 は危殆化が検知された後にどのような BCP 対策を行い、暗号鍵を使う処理を再開するかを明確化することを要求したものである。

《トイモデルと記載例》
本節のトイモデルも、2.1 節のトイモデルと同じ、メールの送信元認証を S/MIME の署名付きメールで実現するシステムであり、暗号鍵のライフサイクルは 2.2 節のトイモデルで定めたものとする。

また、システムの運用条件を以下のように設定する。
【】内は記載例のどの項目に影響を与えているのかを示している。
⚫

署名プライベート鍵と署名公開鍵の有効期間は、公開鍵証明書の有効期間とする。
【B.73】⚫

署名プライベート鍵が危殆化すると署名公開鍵も同時に危殆化したとみなす。
【B.74, B.75】⚫

特に、危殆化しやすいと想定できるメタデータ要素はない。【B.76～B.78】⚫

役割を分離して権限を必要な範囲にしている。【B.79】

57

⚫

個々のメール利用者が使用する PC において、使用している OS のログ保存機能により、署名プライベート鍵のアクセスログを管理する。アクセスログはシステム管理者しか確認できない。【B.79, B.80】⚫

情報システム部の公開鍵証明書発行依頼の担当者の公開鍵証明書発行依頼ログと操作ログが PC 内に保存され、操作ログへのアクセスは情報システム部の管理者しかできない。
【B.79, B.80】⚫

鍵の危殆化が疑われるときは失効処理を行い、鍵を再生成し、証明書を再発行する。
【B.81】

以上のトイモデルにおける記載例は、以下の「署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例」のようになる。

署名付き S/MIME を使用しメール送信元認証をするシステムにおける記載例
B.73

署名プライベート鍵と署名公開鍵の有効期間は、公開鍵証明書に記載された有効期間と一致する。システムの運用標準では 1 年プラス 10 日とする。

B.74

署名公開鍵は、署名プライベート鍵の危殆化に依存する。
署名プライベート鍵に危殆化の疑いが発生したときは、当該鍵ペアの両方の失効処理を行い、新たな鍵ペアを再生成し公開鍵証明書を発行し直すことにより、鍵の置き換
えを行う。

B.75

署名プライベート鍵が危殆化すると署名公開鍵も同時に危殆化したとみなす。

B.76

公開鍵証明書に記載されているメタデータは、CA 署名により完全性が保護される。また、保存されるメタデータは B.44 に記載した ACS により完全性を保護されている。
そのため、危殆化しやすいメタデータ要素は想定しない。

B.77

B.76 により、対象外。

B.78

同上

B.79

⚫

本システムでの役割として、以下の通りである。
➢

メール利用者（メール送信者・メール受信者）➢

当該 PC ごとのシステム管理者（情報システム部内で PC ごとに担当者を割り当てる）➢

情報システム部の公開鍵証明書発行依頼の担当者➢ 情報システム部の公開鍵証明書発行依頼の管理者⚫

メール利用者が使用する PC の署名プライベート鍵のアクセスログを保存する。
システム管理者がアクセスログを毎月確認し、不正な署名生成が行われていないかどうかを確認する。

⚫

公開鍵証明書発行依頼の担当者は、公開鍵証明書発行依頼ログを毎月確認し、不正な公開鍵証明書発行依頼が行われていないかどうかを確認する。

⚫

公開鍵証明書発行依頼の管理者は、発行依頼の担当者の操作ログを毎月確認し、不正な公開鍵証明書発行依頼が行われていないかどうかを確認する。

B.80

⚫

メール利用者が署名プライベート鍵を複製するなど、署名プライベート鍵に対するアクセスは全てアクセスログに記録される。

58

⚫

メール利用者は、署名プライベート鍵のアクセスログにアクセスできない。アクセスできるのは、システム管理者だけである。

⚫

PC は当該利用者が安全に管理する。

⚫

システム管理者は、メール利用者の許可又は別途規定に基づく手続きによる場合
を除き、メール利用者の署名プライベート鍵にアクセスしてはならない。

⚫

公開鍵証明書発行依頼の担当者が行う発行依頼は全て操作ログに記録される。

⚫

公開鍵証明書発行依頼の担当者は、操作ログにアクセスできない。アクセスできるのは、公開鍵証明書発行依頼の管理者だけである。

B.81

⚫

メール利用者が使用する PC のアクセスログにより署名プライベート鍵の危殆化を検知したシステム管理者は、CA に該当する鍵ペアの失効処理を依頼し、CA から得た証明書失効リストを関係するエンティティに配布する。

⚫

公開鍵証明書発行依頼の管理者が、証明書発行依頼の処理に使用している PC の操作ログにより不正な証明書発行を検知した場合は、CA に該当する署名公開鍵の失効処理を依頼し、CA から得た証明書失効リストを関係するエンティティに配布する。

⚫

失効処理した鍵ペアのメール利用者は新たな鍵ペアを再生成し、公開鍵証明書を新規発行する。

59

3 暗号アルゴリズムの選択
本章の目的・趣旨
本章は、設計指針（基本編）の 6 章に記載されている要求事項（各節での色付き枠内で示している内容）について解説したものである。
CKMS 設計では、要求される保護レベル（セキュリティ強度）を満たすように暗号アルゴリズ
ムと鍵長を決定しなければならない。セキュリティ強度は、扱う情報の資産価値、求められる情報の機密性や完全性、保護する期間（保護終了年）を踏まえて決定すべきである。
決定したセキュリティ強度、暗号アルゴリズムと鍵長を明記することにより、どの程度安全に情報が保護されているかを確認することも可能になる。なお、本章で扱う暗号アルゴリズムとしては主に公開鍵暗号、デジタル署名、共通鍵暗号、ハッシュ関数を想定としているが、高機能暗号や秘密分散など、新しいタイプの暗号アルゴリズムを含めることもできる。

3.1①

暗号アルゴリズムのセキュリティ要求される保護レベル（セキュリティ強度）に対応した暗号アルゴリズムの決定

項目 FR 番号 Framework Requirements の内容
C.01 FR2.1

CKMS 設計は、システムによって使用される全ての暗号アルゴリズ

SP800-130
2.1 節

ムとそれぞれのアルゴリズムでサポートされる全ての鍵長を明記しなければならない。
C.02 FR2.2

CKMS 設計は、鍵と鍵に結び付けられたメタデータを保護するため

2.1 節に導入されているそれぞれの暗号技術について推定されるセキュリ
ティ強度を明記しなければならない。

解説・考慮点暗号アルゴリズムの選定方法について取り扱う。
CKMS がライフサイクル全体にわたって管理及び保護している暗号鍵を使用することで要求される保護レベル（セキュリティ強度）を満たすことができる暗号アルゴリズムを選定することが求められる。
項目 C.01 及び C.02 は、CKMS の設計にあたって、要求される保護レベル以上を実現していることを確認するために、採用している暗号アルゴリズム（鍵長を含む）及びセキュリティ強度の明確化を求めたものである。
本節で求めているのは、要求される保護レベル（セキュリティ強度）を決定し、それに対応した暗号アルゴリズム及び鍵長を選択し、明記することである。
具体的には、C.01 では、決定したセキュリティ強度に応じて使用可能な設定を行ったりして、当該システムで利用可能な全ての暗号アルゴリズムとサポートされる全ての鍵長を洗い出すことを求めている。また、C.02 では、C.01 に明記した暗号アルゴリズムで使われる暗号鍵とメタデ

60

ータを保護するために使用している暗号技術についても、どの程度のセキュリティ強度を有しているかを評価することを求めている。これは、C.01 で使う暗号アルゴリズムと鍵長が適切に選択されていたとしても、そこで利用する鍵情報が適切なセキュリティ強度で保護されていなければ、必要とされるセキュリティ強度が達成されないためである。
上記の要求を満たすためには、まず CKMS 設計では最初に必要なセキュリティ強度を決める必要がある。セキュリティ強度の決定では、扱う情報の資産価値、情報の機密性や完全性などのほか、該当システムの利用期間の終了年も重要な要因の一つとなる。なお、扱う情報によっては、当該情報の保護がシステムの終了年以降も必要な場合がある。例えば、攻撃者が暗号化された通信 デ ー タ を 先 に 窃 取 し て お い て 解 読 が 可 能 に な っ た 時 期 に 復 号 を 行 う 攻 撃 （ Store (Harvest)then-decrypt、Store now & decrypt later、Retrospective Decryption ともいう）を考慮する必要があるケースである。その場合、システムの終了年ではなく、当該情報の保護が必要な期間を基準にセキュリティ強度を決めるべきである。
具体的に必要なセキュリティ強度の決定にあたっては、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準 12」又は「暗号鍵設定ガイダンス 13」を参考にされたい。
また、扱う情報の資産価値（重要性）では、扱う情報の機密性・完全性・可用性に危殆化が発生したときに、どの程度の影響を与えるかを段階的に評価し、その影響度が大きいほど資産価値が高いと判断される。この評価はリスク分析の一環として行われることが多く、資産価値が高い
情報と評価されると、その情報を扱うシステムではより強いセキュリティが求められることがある。このような場合には、通常のセキュリティ強度よりも高い強度を設定することが同時に求められる場合もあることに留意されたい。必要があれば、「中小企業の情報セキュリティ対策ガ イド
ライン 14」や「政府機関等の対策基準策定のためのガイドライン（令和 3 年度版）改定版 15」なども参考にされたい。
なお、情報資産は時間の経過により、陳腐化する、逆に価値が上がることもある。そのような情報資産の重要性の変化があるかどうかも含めて検討し、適切なセキュリティ強度を設定すべきである。
「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」は、CRYPTREC 暗号リス
ト 16 に掲載されている暗号技術を利用する際に、適切なセキュリティ強度を実現するためのアル
ゴリズム及び鍵長の選択方法を規定したものである。したがって、利用する鍵長についてこの設定基準に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意されたい。また、政府機関等のサイバーセキュリティ対策のための統一基準において適用対象となる電子政府システム（暗号化機能・電子署名機能の導入を行うものに限る。）の調達・開発・運用に関わる場合には、この設定基準に従う必要がある。
12

13
14
15

16

暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準、https://www.cryptrec.go.jp/list/cryptrec-ls0003-2022.pdf
暗号鍵設定ガイダンス、https://www.cryptrec.go.jp/report/cryptrec-gl-3003-1.0.pdf
中小企業の情報セキュリティ対策ガイドライン第 3 版、https://www.ipa.go.jp/files/000055520.pdf
政府機関等の対策基準策定のためのガイドライン（令和 3 年度版）改定版、
https://www.nisc.go.jp/pdf/policy/general/guider3_2.pdf
電子政府における調達のために参照すべき暗号リスト（CRYPTREC 暗号リスト）
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r7.pdf

61

表 3-1 は、本設定基準において、システムの想定運用終了・廃棄年又は利用期間の終了年を基準に必要なセキュリティ強度要件を示したものである。例えば、128 ビットセキュリティは 2022
～2040 年が利用可能であり、2041～2050 年が移行完遂期間になっているので、2050 年までに運用を停止するシステムであれば 128 ビットセキュリティでもよいが、2051 年以降も何らかの形で運用するシステムでは 2050 年までに 192 ビットセキュリティ以上のセキュリティ強度に移行することが必要となる。
表 3-1
想定運用終了・廃棄年／
利用期間
新規生成
112 ビット((a)参照)セキュリティ

処理((b)参照)セキュリティ強度要件の基本設定方針

2022～2030

2031～2040

移行完遂

利用不可

期間
((c)参照)((a)参照)セキュリティ

処理

利用可

2051～2060

2061～2070

利用不可

利用不可

利用不可

移行完遂

利用不可

許容

新規生成
128 ビット

2041～2050

利用可((b)参照)期間

利用不可((c)参照)許容

新規生成
192 ビット((a)参照)セキュリティ

処理

利用可

利用可

利用可

利用可

利用可

利用可

利用可

利用可

利用可

利用可

((b)参照)新規生成
256 ビット((a)参照)セキュリティ

処理((b)参照)(a) 新規に暗号保護を適用する（例えば、暗号化や署名生成を実行する）際は、原則として、2040
年までは 128 ビット以上のセキュリティ強度のものを選択すべきである。2041 年以降は 192
ビット以上のセキュリティ強度のものを選択すべきである。
(b) 保護済みのデータに対して処理を実行する（例えば、復号や署名検証を実行する）際は、2040
年までは 128 ビット以上、2041 年以降は 192 ビット以上のセキュリティ強度のものを選択すべきである。ただし、保護済みのデータに対する正当性を担保又は確認するための何らかの技術的又は運用的な対策やルール等（暗号技術によるものとは限らない）を併用している
場合に、2031 年以降も 2040 年までの必要な範囲内で 112 ビットセキュリティ強度のものを選択することを許容する。同様に、2051 年以降も 2060 年までの必要な範囲内で 128 ビット
セキュリティ強度のものを選択することを許容する。
(c) 移行完遂期間内に、よりセキュリティ強度の高い暗号技術又は鍵長への移行を完遂させることを前提として、利用する暗号処理が短期間で完結する場合（例：エンティティ認証）、又は既存の電子政府システムの継続利用やそれらとの互換性・相互接続性維持などの必要がある

62

場合には、2030 年までは 112 ビットセキュリティ強度のものを、2050 年までは 128 ビット
セキュリティ強度のものを選択することを許容する。
「暗号鍵設定ガイダンス」は、安全な暗号技術の導入の観点から、暗号技術を利用する際の鍵長の選択方法に関する一般的な考え方を解説したものであり、必要な鍵長を判断する上での目安となるものである。表 3-2 は、本ガイダンスにおいて、1982 年当時に DES が有していたのと同程度のセキュリティ強度を実現するために必要と推定されるビットセキュリティを示したものであり、表 3-2 でのビットセキュリティを下限のセキュリティ強度として、一定のセキュリティマ
ージン（数十ビット）を追加したそれ以上のセキュリティ強度で設定することが望ましいと記載されている。例えば、2040 年に該当システムの利用を終了するのであれば最低で 104 ビット以上、できれば 128 ビット以上のセキュリティ強度を設定するのがよい。
表 3-2

1982 年の DES と同等のセキュリティを提供すると推定される（＝その後 10～15 年程度安全と期待される）ビットセキュリティ
年

1982

2030

ANSSI（2014）

56

Lenstra（2001）

56

93

Lenstra（2004）

56

88

2040

2050

2060

2070

91 ～ 11296 ～ 120

101 ～ 128

101

109

－

－

95

102

－

－

81 ～ 96 86 ～ 104

必要なセキュリティ強度を決定したら、暗号アルゴリズムと鍵長を決定する。その際、使用する全ての暗号アルゴリズムと鍵長が必要とするセキュリティ強度を上回る強度となるように選択しなければならない。公開鍵暗号、デジタル署名、共通鍵暗号、ハッシュ関数については、
CRYPTREC 暗号リストの電子政府推奨暗号リスト（又は推奨候補暗号リスト）に掲載されている暗号アルゴリズムから選択することを推奨する。また、セキュリティ強度と鍵長の関係は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」又は「暗号鍵設定ガイダンス 」の2.2 節「暗号技術の推定セキュリティ強度表現－ビットセキュリティ」を参照する。

《トイモデルと記載例》
本節のトイモデルは、Web ブラウザをクライアントとするクライアント－サーバシステムである。暗号プロトコルとして TLS 通信を使用する。
そこで、このトイモデルでは、セキュリティ強度は「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」に従い、また TLS サーバでの暗号スイートの設定では「TLS 暗号設定ガ
イドライン 17」の「高セキュリティ型での暗号スイート推奨設定（TLS1.3 限定）」に従って設定している。
まず、該当システムは 2023 年から 8 年間使用し 2031 年末破棄する予定である。この場合、表3-1 により必要なセキュリティ強度は 128 ビットとなり、TLS1.3 の中で利用する暗号アルゴリ

17

TLS 暗号設定ガイドライン、https://www.cryptrec.go.jp/report/cryptrec-gl-3001-3.0.1.pdf

63

ズムでの鍵長は 128 ビットセキュリティを満たす鍵長を利用することになる。
TLS1.3 を利用する場合における高セキュリティ型の暗号スイートは、
TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、
TLS_AES_128_GCM_SHA256、TLS_AES_128_CCM_SHA256、
TLS_AES_128_CCM_8_SHA256であり、個々の暗号スイートの最後の SHA384/ SHA256 は鍵生成 HKDF で使用するハッシュ関数を示している。
なお、TLS 暗号設定ガイドラインにおける高セキュリティ型での推奨設定では、暗号アルゴリ
ズム自体の安全性に問題がないものだけが選定されているので、暗号アルゴリズムそのものの選択に関しては気にする必要はない。
また、このサーバで使われるサーバ証明書は、セキュリティ強度が 128 ビット以上必要なので、ここでは署名方式として ECDSA P-256、証明書に使用するハッシュ関数として SHA-256 を使用する。
このトイモデルを対象とした場合、C.01 については「TLS 暗号設定ガイドライン」の高セキュリティ型での推奨設定に従った内容となる。C.02 については、鍵とメタデータを保護するための暗号技術としては、認証局が署名したサーバ証明書によって「サーバ公開鍵」と「有効期間」とが結び付けられているので、推定セキュリティ強度は認証局の署名で使われている暗号アルゴリ
ズムと鍵長から導かれるセキュリティ強度である。
以上のトイモデルにおける記載例は、以下の「クライアント－サーバシステムにおける記載例」のようになる。
クライアント－サーバシステムにおける記載例
C.01

署名
ECDSA
P-256 - 鍵長 256 ビット
SHA-256
鍵合意
ECDHE
P-256 – 鍵長 256 ビット
X25519 - 鍵長 255 ビット
データ暗号化／復号
AES-128-GCM - 鍵長 128 ビット
AES-256-GCM - 鍵長 256 ビット
AES-128-CCM - 鍵長 128 ビット
AES-128-CCM-8 - 鍵長 128 ビット
CHACHA20-POLY1305 - 鍵長 256 ビット

64鍵生成（HKDF）
HMAC-SHA-256
HMAC-SHA-384
C.02

サーバ公開鍵とメタデータ（有効期間）の結び付きの保護は、認証局の署名により行っている。そこで利用している暗号技術は、ECDSA P-256 と SHA-256 であるので、セキュリティ強度は 128 ビットセキュリティである65

暗号アルゴリズム運用に必要な鍵情報の管理

4

本章の目的・趣旨
本章は、設計指針（基本編）の 7 章に記載されている要求事項（各節での色付き枠内で示している内容）について解説したものである。
「鍵情報の管理」の主要な効果の 1 つは、該当システムで使用している暗号鍵について、鍵タ
イプとメタデータに応じて分類した上で保護方法などを明記し管理することにより、その暗号鍵が安全に管理されていることを明確にすることである。
暗号鍵の管理方法は、扱う情報の資産価値や対策コストを考慮して CKMS 設計者が決定することとなるが、利用用途や目的等に応じた鍵タイプごとに、その特徴に合わせた相応しい鍵管理を実施することが必要になる。また、鍵タイプによってはメタデータとの組み合わせによりその暗号鍵の完全性を確保する場合もあるため、とりわけそのような鍵タイプ の暗号鍵ではメタデー
タの管理も安全な鍵情報の管理を実施するために重要となる。
このように分類して鍵情報を管理することで、CKMS 設計者が明示的に管理すべき暗号鍵を漏れなく洗い出し、それらの暗号鍵を安全に管理していることを明確にすることができる。また、ある暗号鍵の危殆化が疑われるときに、その暗号鍵の管理状況の確認や危殆化による影響リスクの判断等に利用することができ、さらに、危殆化が発生した場合に敏速な対応も可能になる。
本章では、暗号鍵の安全な管理を行うために必要な、鍵タイプ、鍵のメタデータの分類方法、
またそれらの保護方針や記載方法を解説する。

4.1

鍵情報の種類

SP800-130 に記載されている鍵タイプとメタデータを以下のように解説し ている。CKMS 設
計者は、明示的に管理すべき暗号鍵すべてについて、暗号鍵の利用用途や目的に応じて、それぞれの暗号鍵がどの鍵タイプに属するか、管理対象となる鍵情報が何であるかを分類することが必要になる。
暗号鍵は、以下の通り、特性と用途（＋オプション）に応じて分類され、これらの組み合わせで「鍵タイプ」が定義される。
公開（Public）
特性

一般に公開できる情報

プライベート（Private） 一人のユーザのみが秘密に保持する情報
対称（Symmetric）

送信者と受信者が共通して秘密に保持する情報

オプシ

静的（Static）

長期的に固定した情報ョン

一時的（Ephemeral） 1 つのセッションやトランザクションでのみ使われる情報
データの暗号化／復号（Encryption/Decryption）

用途

鍵ラッピング（Key Wrapping）
鍵配送（Key Transport）

66

鍵合意（Key Agreement）
署名（Signature）
認証（Authentication）
認可（Authorization）
乱数生成（Random Number Generator（RNG））
マスタ鍵（Master Key）
SP800-130 で分類する鍵タイプは以下の通りである。
1) 署名プライベート鍵（Private Signature Key）
2) 署名公開鍵（Public Signature Key）
3) 認証対称鍵（Symmetric Authentication Key）
4) 認証プライベート鍵（Private Authentication Key）
5) 認証公開鍵（Public Authentication Key）
6) データ暗号化／復号対称鍵（Symmetric Data Encryption/Decryption Key）
7) 鍵ラッピング対称鍵（Symmetric Key Wrapping Key）
8) 乱数生成対称鍵（Symmetric RNG Key）
9) 乱数生成プライベート鍵（Private RNG Key）
10) 乱数生成公開鍵（Public RNG Key）
11) マスタ対称鍵（Symmetric Master Key）
12) 鍵配送プライベート鍵（Private Key Transport Key）
13) 鍵配送公開鍵（Public Key Transport Key）
14) 鍵合意対称鍵（Symmetric Key Agreement Key）
15) 鍵合意静的プライベート鍵（Private Static Key Agreement Key）
16) 鍵合意静的公開鍵（Public Static Key Agreement Key）
17) 鍵合意一時的プライベート鍵（Private Ephemeral Key Agreement Key）
18) 鍵合意一時的公開鍵（Public Ephemeral Key Agreement Key）
19) 認可対称鍵（Symmetric Authorization Key）
20) 認可プライベート鍵（Private Authorization Key）
21) 認可公開鍵（Public Authorization Key）
メタデータは、CKMS によって明示的に記録され管理されている特定の暗号鍵に関連付けられている情報として定義されるものであり、特性、制約、受け入れられるユーザ及び適用可能なパラメタを指定する。メタデータの各ユニットはメタデータ要素と呼ばれる。SP800-130 で取り上げる典型的なメタデータ要素は以下の通りである。
a) 鍵ラベル（Key Label）b) 鍵識別子（Key Identifier）
c) 所有者識別子（Owner Identifier）
d) 鍵ライフサイクル状態（Key Lifecycle State）
e) 鍵フォーマット指定子（Key Format Specifier）
67

f) 鍵生成に使用した製品（Product used to create the Key）
g) 鍵を使用する暗号アルゴリズム（Cryptographic Algorithm using the Key）
h) スキーム又は暗号利用モード（Scheme or Modes of Operation）
i) 鍵パラメタ（Parameters for the Key）
j) 鍵長（Length of the Key）
k) 鍵／アルゴリズム組のセキュリティ強度（Security Strength of the Key/Algorithm
Pair）l) 鍵タイプ（Key Type）
m) 鍵に対する適切なアプリケーション（Appropriate Applications for the Key）
n) 鍵セキュリティポリシー識別子（Key Security Policy Identifier）
o) 鍵アクセスコントロールリスト（Key Access Control List（ACL））
p) 鍵使用カウント（Key Usage Count）
q) 親鍵（Parent Key）
r) 鍵機微性（Key Sensitivity）
s) 鍵保護（Key Protections）
t) メタデータ保護（Metadata Protections）u) 信頼関係保護（Trusted Association Protections）
v) 日時（Date Times）
w) 失効理由（Revocation Reason）

解説・考慮点暗号鍵は、「特性」に応じて、対称鍵、公開鍵、プライベート鍵に大きく分類できる。
対称鍵は、暗号化に使用する暗号鍵と復号に使用する暗号鍵が同一であり、情報を所有又は共有するエンティティ（情報所有者や、情報送信者と情報受信者）のみが秘密裏に利用する。
公開鍵とプライベート鍵はペアで使用する。暗号の場合、公開鍵は暗号化に使用し、プライベ
ート鍵は復号に使用する。署名と検証の場合、公開鍵は検証に使用し、プライベート鍵は署名に使用する。公開鍵は、不特定多数のエンティティに知られても良いが、プライベート鍵は復号や署名する単独のエンティティ（一人のユーザ）以外には知られることが無いようにする。
時間的な「オプション」として、暗号鍵を長期に渡り利用する場合は静的な暗号鍵と呼び、短期間しか使わない場合は一時的な暗号鍵と呼ぶ。例えば、接続ごとに(EC)DH 18で鍵交換する場合、一回の接続（1 つのセッションやトランザクション）でしか使用しない鍵であるため、一時的な鍵である。
「用途」は、その暗号鍵の利用用途や目的を表している。この用途と、上記の特性とオプションに応じて、「暗号鍵管理システム設計指針（基本編）」に記載されている 21 種類の鍵タイプに分類でき、それぞれの鍵タイプの役割は、以下の通りである。

18

一時的(EC)DH は、一時的（Ephemeral）であることを示すため(EC)DHE と記述することもある。

68

1)

署名プライベート鍵：デジタル署名を生成するためのプライベート鍵である。署名は公開鍵アルゴリズムが使用され、この鍵と鍵ペアとなる 2)の署名検証公開鍵が存在する。
適切に扱うことができれば、署名プライベート鍵は、メッセージやドキュメント、保存されたデータのソース認証と完全性認証を提供するほか、それらの否認防止をサポートするためにも、使用することができる。

2)

署名公開鍵：デジタル署名を検証するための鍵である。公開鍵アルゴリズムで使用される鍵ペアの公開鍵であり、メッセージ、ドキュメント又は保存されたデータのソース認証と完全性認証を提供するほか、それらの否認防止をサポートすることを目的としたデジタル署名を検証するために使用される。

3)

認証対称鍵：対称鍵アルゴリズムと共に使用され、通信セッション、メッセージ、文書又は保存されたデータの ID 認証と完全性認証を提供する。対称鍵アルゴリズムの認証
暗号利 用モー ドで は、 一つの 鍵が認 証と 暗号 化の両 方に使 用さ れる ことに なる 。（ SP
800-175B を参照）。

4)

認証プライベート鍵：エンティティの身元の保証（つまり、ID 認証）を提供するための鍵である。この認証は公開鍵アルゴリズムが使用され、この鍵と鍵ペアとなる 5)の認証
公開鍵が存在する。認証された通信セッション又は何らかのアクションを実行するための認可を確立するときに使用される。

5)

認証公開鍵：エンティティの身元の保証（つまり、ID 認証）を提供するための公開鍵ア
ルゴリズムで使用される鍵ペアの公開鍵である。認証された通信セ ッション又は何らかのアクションを実行するための認可を確立するときに使用される。

6)

データ暗号化／復号対称鍵：対称鍵アルゴリズムを用いて、データの機密性保護（平文
データの暗号化）をするための鍵である。同じ鍵が、機密性保護を解除（暗号文データの復号）するためにも使用される。対称鍵アルゴリズムの認証付き秘匿モードでは、一つの鍵がソース認証と暗号化の両方に使用される。

7)

鍵ラッピング対称鍵：対称鍵アルゴリズムを用いて、他の鍵を暗号化するための鍵である。鍵暗号化鍵と呼ばれることもある。鍵の暗号化に使用された鍵ラッピング鍵 は、暗号化処理を元に戻す（つまり、暗号化された鍵を復号する）ためにも使用される。鍵を使用するアルゴリズムによっては、完全性保護を提供するために鍵を使用することもできる。

8)

乱数生成対称鍵：対称暗号方式を使用して乱数を生成するための鍵である。

9)

乱数生成プライベート鍵：公開鍵アルゴリズムを使って乱数を生成するためのプライベ
ート鍵である。この鍵と鍵ペアとなる 10)の乱数生成公開鍵が存在する。

10) 乱数生成公開鍵：乱数を生成するための鍵である。9)の乱数生成プライベート鍵のペアとなる乱数生成公開鍵である。
11) マスタ対称鍵：対称暗号化方式を使用して他の対称鍵（データ暗号化鍵や鍵ラッピング鍵など）を導出するための鍵である。マスタ鍵は、鍵導出鍵とも呼ばれる。
12) 鍵配送プライベート鍵：公開鍵暗号アルゴリズムを使用してペアとなる公開鍵で暗号化
69

された鍵の復号に使用される鍵である。この鍵と鍵ペアとなる 13)の鍵配送公開鍵が存在する。鍵配送鍵は、通常、対称鍵（例えば、鍵ラッピング鍵、データ暗号化鍵、MAC鍵など）及び場合によっては他の鍵材料（例えば、初期ベクトル）を確立するために使用される。
13) 鍵配送公開鍵：公開鍵アルゴリズムを使用して鍵を暗号化するために使用される鍵である。12)の鍵配送プライベート鍵のペアとなる公開鍵である。これらの鍵ペアは、対称鍵（例えば、鍵ラッピング鍵、データ暗号化鍵、MAC 鍵など）及び場合によっては他の鍵材料（例えば、初期ベクトル）を確立するために使用される。確立された鍵の暗号化形
態は、後で鍵配送プライベート鍵を使用して復号するために保存できる。
14) 鍵合意対称鍵：対称鍵合意アルゴリズムを使用して、対称鍵（例えば、鍵ラッピング鍵、
データ暗号化鍵、MAC 鍵など）及び他の鍵材料（例えば、初期ベクトル）を確立するための鍵である。
15) 鍵合意静的プライベート鍵：公開鍵アルゴリズムを使用して対称鍵（例えば、鍵ラッピ
ング鍵、データ暗号化鍵、MAC 鍵など）及び他の鍵材料（例えば、初期ベクトル）を確立するための長期的なプライベート鍵である。この鍵と鍵ペアとなる 16)の鍵合意静的
公開鍵が存在する。
16) 鍵合意静的公開鍵：公開鍵アルゴリズムを使用して対称鍵（例えば、鍵ラッピング鍵、
データ暗号化鍵、MAC 鍵など）及び他の鍵材料（例えば、初期ベクトル）を確立するための長期的な公開鍵である。15)の静的鍵合意プライベート鍵のペアとなる公開鍵である。
17) 鍵合意一時的プライベート鍵：公開鍵アルゴリズムを使用して対称鍵（例えば、鍵ラッ
ピング鍵、データ暗号化鍵、MAC 鍵など）及び他の鍵材料（例えば、初期ベクトル）を確立するための短期的なプライベート鍵である。対称鍵や鍵材料を確立するために一度だけ使用される。この鍵と鍵ペアとなる 18)の鍵合意一時的公開鍵が存在する。
18) 鍵合意一時的公開鍵：公開鍵アルゴリズムを使用して対称鍵（例えば、鍵ラッピング鍵、
データ暗号化鍵、MAC 鍵など）及び他の鍵材料（例えば、初期ベクトル）を確立するための短期的な公開鍵である。対称鍵や鍵材料を確立するために一度だけ使用される。17)の鍵合意一時的プライベート鍵のペアとなる公開鍵である。
19) 認可対称鍵：対称暗号方式を使用してエンティティに権限を付与するための鍵である。
認可鍵は、認可されたエンティティへのアクセス権限の監視と付与を担当する責任を負うエンティティ、及びリソースへのアクセスを求めるエンティティに知らされる。
20) 認可プライベート鍵：権限に対する所有者の権利を証明するために使用（例えば、デジタル署名を使用）される非対称鍵（公開鍵）の鍵ペアのプライベート鍵である。この鍵と鍵ペアとなる 21)の認可公開鍵が存在する。
21) 認可公開鍵：関連する認可プライベート鍵を知っているエンティティに対する権限を検証するために使用される非対称鍵（プライベート鍵）の鍵ペアの公開鍵である。20)の認
可プライベート鍵のペアとなる公開鍵である。
70

メタデータは、暗号鍵を適切に管理するために、その暗号鍵に関連付けられている情報である。
例えば、鍵の保護方法や有効期間などである。「暗号鍵管理システム設計指針（基本編）」では、メタデータの典型的な要素として a)～w)の 23 種類が記載されている。詳細は以下の通りである。
なお、全ての暗号鍵に対してメタデータが必要となるわけではなく、またメタデータが必要な場合であっても全ての適用可能なメタデータ要素と関連付ける必要は必ずしもないことに留意されたい。
a) 鍵ラベル（Key Label）：人間が読解可能なテキスト文字列で書かれた鍵の記述子のことである。例えば、“root CA Private Key 2022”や“Cryptrec Secret Key 2023”などである。
b) 鍵識別子（Key Identifier）：多数の鍵から特定の鍵を識別するための識別子のことである。CKMS は一般的にユニークな識別子を割り当てる。
c) 所有者識別子（Owner Identifier）：鍵を所有するエンティティの識別子のことである。
d) 鍵ライフサイクル状態（Key Lifecycle State）：「4.2 暗号鍵のライフサイクル」に記載
した鍵の状態のことである。
e) 鍵フォーマット指定子（Key Format Specifier）：鍵のフォーマットの指定子のことである。例えば、RSA 公開鍵は法（modulus）と公開指数（public exponent）があり、その 2つの値の格納順及び値の表記方法を指定する。Internet Engineering Task Force（IETF）
は、(EC)DH、RSA、ECDSA などの鍵を格納するための方法を RFC 5208、RFC 5480、RFC 5958 で定義している。
f)

鍵生成に使用した製品（Product used to create the Key）：鍵生成に使用した製品情報のことである。

g) 鍵を使用する暗号アルゴリズム（Cryptographic Algorithm using the Key）：その鍵が使用する暗号アルゴリズムを指定する。例えば、ECDSA、RSA、AES、Camellia、HMACSHA256 などである。
h) スキーム又は暗号利用モード（Scheme or Modes of Operation）：その鍵が使用する暗号
アルゴリズムを実行するための適用可能なスキーム又は暗号利用モードのことである。例
えば、非対称アルゴリズムでは、有限体、binary field（標数 2 の体）又は楕円曲線（EC）
上の離散対数問題の演算を指定する。対称アルゴリズムでは、ブロック暗号で使用される
暗号利用モード（CBC、OFB、CCM、GCM 等）を指定する。詳細に関しては、［SP 80038A］～［SP 800-38D］を参照されたい。
i)

鍵パラメタ（Parameters for the Key）：鍵のパラメタが存在する場合に指定する。例えば、ECDSA 鍵には（素数（ p ）、楕円曲線の係数（a, b）、生成元（G）、G の位数（n）、n のコファクタ（h））のドメインパラメタがある。

j)

鍵長（Length of the Key）：鍵の長さをビット（又はバイト）で指定する。例としては、
RSA の法の 2048 ビットや楕円曲線暗号の鍵の 256 ビットである。

k) 鍵／アルゴリズム組のセキュリティ強度（Security Strength of the Key/Algorithm Pair）：「5.1.1 暗号アルゴリズムのセキュリティ強度」に記載したセキュリティ強度である。
l)

鍵タイプ（Key Type）：本節で説明している鍵タイプのことである。

71m) 鍵に対する適切なアプリケーション（Appropriate Applications for the Key）：鍵を使用してよいアプリケーションのことである。例えば、TLS、SSH、デジタル署名である。
n) 鍵セキュリティポリシー識別子（Key Security Policy Identifier）：暗号鍵又は鍵タイプに適用できるセキュリティポリシーを特定する識別子のことである。このセキュリティポ
リシーは、生成から破壊までの鍵ライフサイクル全体にわたって、暗号鍵又は鍵タイプを保護するために使用するセキュリティコントロール一式である。
o) 鍵アクセスコントロールリスト（Key Access Control List（ACL））：暗号鍵及びメタデータの管理機能で制限された通りに、暗号鍵へのアクセスが可能なエンティティを特定するリストである（「7.1 鍵情報へのアクセスコントロール」を参照）。例えば、Microsoft
Windows の ACL、Linux の ACL 、HSM を使った方法などがある。
p) 鍵使用カウント（Key Usage Count）：鍵が使用された回数のことである。
q) 親鍵（Parent Key）：メタデータに関連付けられた暗号鍵の導出元となった暗号鍵のことである。例えば、TLS 1.3 の通信に使われる暗号鍵である各種トラフィックシークレット
は、マスタシークレットやハンドシェイクシークレットなどを親鍵として導出される。
r) 鍵機微性（Key Sensitivity）：暗号鍵の機微度又は重要度のことである。これは、リスクレベル（例えば、低、中、高）又は機密区分レベル（例えば、Confidential、Secret、Top
Secret）に関係する。
s) 鍵 保 護 （ Key Protections ） ： 暗 号 鍵 に 対 す る 完 全 性 、 機 密 性 及 び ソ ー ス 認 証 （ source
authentication）の保護メカニズムのことである。公開鍵証明書は、CA のデジタル署名が完全性保護とソース認証の両方を提供する鍵保護の例である（［X.509］参照）。対称鍵
及びそのハッシュ値を共に暗号化したものは機密性と完全性の保護の例である。なお、暗号鍵及びそのメタデータを外部エンティティから受信した場合は、それらが保護されているかどうかを事前に検証する必要があり、一般に、1 つの暗号機能（例：HMAC 又はデジタル署名）が完全性保護とソース認証の両方を提供するために使用される。
この保護メカニズムでは、いくつかの下位要素を持つことがある：
i.

完全性保護に使用されるメカニズム（例：ハッシュ値、MAC、又はデジタル署名）ii.

機密性保護に使用されるメカニズム（例：鍵ラッピング、又は鍵配送）

iii.

ソース認証に使用されるメカニズム（例：MAC、又はデジタル署名）iv.

特定の非暗号学的な信頼プロセスによって実施される保護の表示t) メタデータ保護（Metadata Protections）：関連付けられたメタデータの完全性、機密性
及びソース認証を保護するために使用されるメカニズムのことである。一般には、鍵保護と同じメカニズムで保護するが、別のメカニズムで保護することもある。鍵保護と同様の下位要素を持つことがある。
u) 信頼関係保護（Trusted Association Protections）：暗号鍵とメタデータが正しく関連付
けられていることを保証するために、その暗号鍵とメタデータとの信頼関係を保護するためのメカニズムのことである。上記の項目 s）で挙げられている保護によって、暗号鍵とメタデータがひとつの集約した項目として保護されている場合、信頼関係保護は暗黙的に提供されている。それ以外で信頼関係保護が必要な場合は、以下の項目が提供されるべき
である：

72

i.

完全性保護に使用されるメカニズム（例：ハッシュ値、MAC、デジタル署名、又は信頼プロセス）

ii.

ソース認証に使用されるメカニズム（例：暗号学的メカニズム又は非暗号学的な信頼プロセス）v) 日時（Date Times）：暗号鍵の状態遷移のための日時のことである。例えば、鍵の使用開始日（活性化状態に遷移）や終了日（活性化状態から非活性化状態に遷移）、有効期限等に関するものがある。
w) 失効理由（Revocation Reason）：暗号鍵が失効した場合の失効理由のことである。例えば、暗号鍵の漏洩の疑い、暗号モジュール危殆化の疑い、鍵所有者の組織離脱、鍵の誤使用等がある。

4.2

鍵情報の選択① CKMS が取り扱う全ての鍵タイプの利用用途及び生成手段、メタデータ、信頼関係、保護方針などの決定
項目 FR 番号 Framework Requirements の内容
D.01 FR6.1

CKMS 設計は、使用されているそれぞれの鍵タイプを明記及び定SP800-130
6.1 節

義しなければならない。
D.02 FR6.2システムで使用されているそれぞれの鍵タイプに対して、CKMS

6.2.1 節設計は、信頼関係のために選択される全てのメタデータ要素、メタ
データ要素が作成され鍵との関連付けが満たされている状況、及び関連付けの手段（すなわち、暗号メカニズム又は信頼プロセス）を明記しなければならない。
D.03 FR6.13

それぞれの鍵タイプに対して、CKMS 設計は、暗号鍵及びメタデータ要素に関する以下の情報を明記しなければならない：
a)

鍵タイプ

b)

暗号鍵有効期間（cryptoperiod）（静的鍵（static key）に対
して）

c)

生成手段
i. 使用した乱数生成器（RNG）
ii. 鍵生成の仕様（例えば、署名鍵については［FIPS 186］、
Diffie-Hellman 鍵確立鍵（key establishment key）については［SP800-56A］）

d)

それぞれのメタデータ要素に対して、以下を含める
i. メタデータのソース
ii. メタデータの検証方法

e)

鍵確立（key establishment）の手段
73

6.2.2 節i. 鍵配送スキーム（使用されている場合）
ii. 鍵合意スキーム（使用されている場合）
iii. プロトコル名（名称があるプロトコルが使用されている場
合）f)

暴露に対する保護（例えば、鍵の機密性、物理セキュリティ）g)

改ざんに対する保護（例えば、MAC 又はデジタル署名）h)

鍵を使用し得るアプリ ケーション（例えば、TLS、EFS、
S/MIME、IPSec、PKINIT、SSH、等）i)

鍵の使用が許可されないアプリケーションj)

鍵保証（key assurances）
i. 対称鍵保証（Symmetric key assurances）（例えば、フォーマットチェック）• 誰が保証を得るか• 保証が得られる状況• どのように保証を得るか
ii. 非対称鍵保証（Asymmetric key assurances）（例えば、所有と有効性の保証）• 誰が保証を得るか• 保証が得られる状況• どのように保証を得るか
iii. ドメインパラメタ有効性チェック• 誰が有効性チェックを実行するか• チェックが実行される状況• どのようにドメインパラメタの有効性の保証を得るか

D.04 FR6.14

CKMS 設計は、CKMS によって生成、保管、伝送、処理、及びそ

6.2.2 節の他管理される全ての鍵タイプ及びメタデータについて、全てのシンタックス、セマンティクス、及びフォーマットを明記しなければならない。

解説・考慮点CKMS の設計にあたって、項目 D.01～D.04 は、鍵情報の選択にあたっての要求事項を明確化することを求めたものである。D.01 は利用する鍵タイプの一覧、D.02 はメタデータに関しての要求事項、D.03 は鍵情報の利用条件や取り扱い方法、D.04 は書式方法を対象にしている。
本節の要求事項で、「CKMS が取り扱う全ての鍵タイプの利用用途及び生成手段、メタデータ、
信頼関係、保護方針などを決めなければならない」と求めているが、ここでの「全ての鍵」の意
図は、CKMS 設計で「明示的に選択や管理する必要がある全ての鍵（タイプ）」に対してのことを指している。つまり、CKMS 設計で明示的に選択や管理しておらず、プロトコルや製品仕様により内部処理として自動的に生成・使用される暗号鍵は基本的には含まない。但し、このことは、
74

利用する製品やアプリケーション、システムが自動的に生成・使用される暗号鍵を「ブラックボ
ックスとして使っている」という認識を持つことが重要である。したがって、このような処理を行う部分（多くは暗号モジュール）については信頼できる製品を使うことが望ましい。例えば、
暗号モジュール認証を取得した製品などである。もし信頼性に確信が持てない暗号モジュールを使用している場合などは、可能であれば、内部の処理を調査し、暗号鍵の信頼性を確認することが望ましい。
具体的に、D.01 では、CKMS 設計者が明示的に選択して管理する全ての鍵タイプを洗い出し、
どのような鍵タイプを利用しているのかを明確化することを求めている。その際、使用するソフ
トウェアの仕様書、設計書や規格などを参考にすべきである。市販品（COTS）デバイスやオープ
ンソースソフトウェア（OSS）を使用している場合は、公開されている仕様書等を参照して記載すべき鍵タイプなどの情報を得ることができることもある。なお、システム内に他者が実装したサブモジュールや既存システム内に前任者等が設計したサブモジュールが含まれている場合には、
CKMS 設計者が明示的に選択して管理する鍵情報として、それらのモジュールで使われる鍵情報も対象に含まれる場合がある。このようなケースでは、必要に応じて、例えば SBOM（Software
Bill Of Materials：ソフトウェア部品表）などを利用して、実態調査を行うことも想定されたい。
暗号鍵の各種管理機能を実行するためには暗号鍵とメタデータが正しく関連付けられている必要がある。そのため、D.02 と D.03 では、D.01 で洗い出した個々の鍵タイプに対して、対象となる暗号鍵の完全性を確保するために必要となるメタデータの洗い出しと、その暗号鍵とメタデー
タが正しく関連付けられていることを保証するための方法を明確にすることが求められている。
D.02、D.03 における信頼関係や鍵の保護方法や利用手段の決定においては、システムで使用する OS やハードウェア環境により選択可能な方式が異なることに留意されたい。例えば暗号鍵の保管では、OS の標準的なファイル保護機能やプロセス保護機能（Microsoft Windows の ACL、
Linux のパーミッションや ACL など）を利用する方法、強固な OS の機能（SELinux 19など、
Linux LSM 20の保護）を利用する方法、TEE 21に保管する方法、IC カードや TPM 22に保管する方法、HSM 23に保管する方法などがある。なお、これらの機能や方法が提供できるセキュリティ強度には違いがあるので、利用用途や想定される脅威等を踏まえて必要なセキュリティ強度を提供する機能や方法を選択することが重要である。
また、最近では、クラウド鍵管理 SaaS など外部の暗号鍵管理システムの保護方法などを利用することも考えられる。さらに、暗号鍵やメタデータの保護や信頼関係の保護では、前述する安全な暗号鍵の保管が可能な保護方法による信頼プロセスを利用する方法、又は MAC やデジタル
19

20
21

22

23

SELinux（Security-Enhanced Linux）：NSA により開発されたユーザ管理を詳細に制御できるようにした
Linux のセキュリティ・アーキテクチャ
LSM（Linux Security Module）：Linux カーネルにセキュリティ機能を拡張するためのフレームワーク
TEE（Trusted Execution Environment）：チップ上に、通常の OS から独立した、信頼できる隔離実行可能な領域があり、その領域内で処理を完結させることができる環境のこと。その領域内に鍵の保存が可能である。Intel SGX、Arm TrustZone、AMD SEV、RISC-V Keystone などがある
TPM （ Trusted Platform Module ）： 暗 号 鍵 を 安 全 に 格 納 で き る セ キ ュ リ テ ィ チ ッ プ 。 TCG （ Trusted
Computing Group）で規定された仕様には TPM1.2 及び TPM 2.0 が存在する
HSM（Hardware Security Module）：耐タンパ性があり安全に暗号鍵管理や暗号処理をするモジュール75

署名などの暗号メカニズムを使う方法を用いて実現する。
4.3 節との関係では、D.02、D.03 で信頼関係や鍵の保護方法や利用手段をどのように設定するかを高レベルの概要で整理し明らかにしておくことで、具体的な保護方法や利用手段について、
2.3 節⑰及び 4.3 節に記載する内容との整合性を満たすことが重要である。ここでの「高レベルの概要」の意味は、4.3 節で決める事項を検討する際に本概要で定めたことと矛盾していないことが確認できる程度に具体化した情報、ということである。
加えて、D.03 で設定する情報や利用する各手段については、2 章で定める内容と矛盾なく、整合的であるようにする必要がある。例えば、鍵生成手段であれば 2.3 節⑧と、鍵確立手段であれ
ば 2.5 節と、保管手段であれば 2.4 節①②と、鍵保証であれば 2.3 節⑩⑪とそれぞれ整合性が取れていることを確認することが重要である。
また、D.02 では、暗号鍵とメタデータの関連付けの手段として、両者に適切な暗号検証機能を適用し関連性が正しいことを検証する暗号メカニズム、又は物理的なセキュリティ手段により両者の関連性が正しいことを確認する信頼プロセスのいずれを利用しているか（または両方を利用しているか）を明らかにする。ここで、暗号メカニズムを選択した場合は、4.3 節の「暗号学的プ
ロセスを利用するケース」に該当し、D.05～D.07 を記載することとなる。信頼プロセスを選択した場合は、「信頼プロセスを利用するケース」に該当し、D.08～D.10 を記載することになることに留意されたい。
D.04 は、主に自動処理する際に、全ての鍵タイプ及びメタデータが誤りなく適切に使われるよ
うにするため、鍵タイプやメタデータの利用形態を統一化しておくための情報となる。これには、仕様書として明確化しておくほか、利用する標準規格や API などの情報を記載するなどのやり方がある。
これらの情報を記載しておくことにより、例えばある暗号鍵に対して危殆化が発生し、またその疑いが生じた場合においても、その危殆化の範囲をいち早く調査可能となることが期待される。
また、監査等の効率も向上することが期待される。

《トイモデルと記載例》
本節のトイモデルでは、図 4-1 の通り、関係者のみがアクセス可能な施設内 Web サーバシステ
ムとする。また、関係者のみが利用するシステムであることから、サーバ証明書を発行する認証局としては施設内にプライベート CA を独自に構築する形をとっている。ただし、トイモデルとしての説明を簡単にするため、ここでは CKMS の対象範囲を Web サーバに絞って定めるものとし、プライベート CA における暗号鍵管理については別途検討するものとする 24。
24

プライベート CA での暗号鍵管理においては、設置場所や運用環境、目的などに依存して、要求されるセキュリティレベルは大きく異なる。認証局のセキュリティとして最も高いレベルは、 多くの民間認証局（パブリック CA）などが使っている WebTrust CA の基準（WebTrust Principles and criteria）に準拠する水準であるが、プライベート CA ではそこまでの水準を求められるケースはかなり少ない。なお、WebTrust CA の基準に近いセキュリティを確保することが求められるようなケースでは、 CA 運用上どのような点に注意する必要があるかを検討する際に WebTrust のガイダンスが参考になる。
https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-ofwebtrust-services/principles-and-criteria76図 4-1

施設内 Web サーバシステム

Web サーバは、OS に Linux、Web サーバの機能を実現するソフトウェアに Apache HTTP
Server を使用する。セキュリティプロトコルとして TLS 1.3 だけを許可し、TLS 1.3 を実現する
ソフトウェアには OpenSSL を使用する。
TLS における暗号鍵を適切に設定するために「TLS 暗号設定ガイドライン」などを参照し、証明書の署名方式は ECDSA NIST P-256 を使用し、鍵交換（鍵合意）の ECDH は X25519、X448、P-256、P-386、P-521 を使用する。なお、この設定は「TLS 暗号設定サーバ設定編」の Apacheに関係する部分も参考にしている。
D.01 に明記する鍵タイプは、解説・考慮点に記載したように、CKMS 設計者が明示的に選択して管理する鍵である。本モデルでは、Web サイト正当性のための Web サーバの署名用のプラ
イベート鍵と公開鍵が記載対象となる。また、TLS 1.3 の鍵交換（鍵合意）の ECDH 関係の鍵も記載対象となる。なお、OpenSSL 内部で生成する TLS セッションで利用される鍵は管理対象外となる。また、Web サーバの署名用のプライベート鍵と公開鍵は、PKCS#8（RFC 5958）形式のパスワード付き暗号ファイルで保存する。この暗号化には AES128 ビットの CBC モードを利用する。
ここで使用する証明書はサイトの正当性のためなので、証明書の key usage は電子署名（Digital
Signature）を含まなければならない。なお、証明書はここで指定した用途以外では使用できないことに留意されたい。
以上のトイモデルにおける記載例は、以下の「施設内 Web サーバシステムにおける記載例」のようになる。

77

施設内 Web サーバシステムにおける記載例
D.01[Web サーバが利用する鍵タイプ]⚫ 署名アルゴリズム：ECDSA（P-256）⚫ 署名プライベート鍵（Private Signature Key）
⚫ 署名公開鍵（Public Signature Key）
[鍵交換（鍵合意）で利用される鍵タイプ]⚫ 鍵交換（鍵合意）アルゴリズム：ECDH（X25519, X448, P-256, P-386, P-521）⚫ 鍵合意一時的プライベート鍵（Private Ephemeral Key Agreement Key）
⚫ 鍵合意一時的公開鍵（Public Ephemeral Key Agreement Key）

D.02

⚫ 署名プライベート鍵は、PKCS#8（RFC 5958）形式のパスワード付き暗号ファイルで保存する。ファイル暗号化には AES128-CBC を利用する。このファイルは Linuxの root 権限で保存し、root 権限の無いユーザは Linux の ACL でアクセスすることができないようにしている⚫ 署名公開鍵の完全性保護のために、証明書に記載されている署名公開鍵とメタデー
タ（subjectAltName, subject key id など）は暗号メカニズム（デジタル署名）により関連付けられる

D.03[署名プライベート鍵と署名公開鍵]a) 鍵タイプ⚫ 署名プライベート鍵（Private Signature Key）
⚫ 署名公開鍵（Public Signature Key）
b) 暗号鍵有効期間⚫ 証明書の有効期間（署名プライベート鍵、署名公開鍵の有効期間）⚫ 日本時間 2023 年 5 月 8 日 00:00:00 ～ 日本時間 2024 年 6 月 7 日 23:59:59c) 生成手段i)

使 用 し た 乱 数 生 成 器 （ RNG ）： Linux の 乱 数 生 成 の 疑 似 デ バ イ ス で あ る/dev/random を使用する

ii)

鍵生成の仕様：FIPS186-4d) それぞれのメタデータ要素に対して、以下を含める
i)

メタデータのソース
メタデータ要素（common name, 組織名、有効期間、subjectAltName, subject
key id など）のソースは、証明書を作成したときの Web サーバの FQDN、IP
アドレス、使用する鍵やアルゴリズムなどの各種設定情報により決定する

ii)

メタデータの検証方法
証明書に記述されているメタデータの内容検証のために、プライベート CA から始まる証明書パスの有効性検証、及び FQDN と IP アドレスの一致確認を実施する

e) 鍵確立（key establishment）の手段：対象外
f) 暴露に対する保護（例えば、鍵の機密性、物理セキュリティ）署名プライベート鍵は PKCS#8（RFC 5958）形式のパスワード付き暗号化状態で
78

保存している。このファイルは Linux の root を所有者にして保存し、ルート以外のユーザは Linux の ACL でアクセスすることができないようにしているg) 改ざんに対する保護（例えば、MAC 又はデジタル署名）
証明書はプライベート CA によるデジタル署名により保護するh) 鍵を使用し得るアプリケーション
Web Server（Apache HTTP Server）、TLS 1.3i) 鍵の使用が許可されないアプリケーションh)で指定したアプリケーション以外は使用を許可しないj) 鍵保証（key assurances）
i)

対称鍵保証（Symmetric key assurances）
該当無し

ii)

非対称鍵保証（Asymmetric key assurances）
証明書発行者（Issuer）の署名により署名プライベート鍵を保証する

iii) ドメインパラメタ有効性チェック
証明書の ECDSA 署名で使用している楕円曲線 P-256 はパラメタを OID で示している。ドメインパラメタの値自体を保管、伝送しないので、有効性は保証
される[鍵合意一時的プライベート鍵と公開鍵]a) 鍵タイプ⚫ 鍵合意一時的プライベート鍵（Private Ephemeral Key Agreement Key）
⚫ 鍵合意一時的公開鍵（Public Ephemeral Key Agreement Key）
b) 暗号鍵有効期間
一時的c) 生成手段i)

使 用 し た 乱 数 生 成 器 （ RNG ）： Linux の 乱 数 生 成 の 疑 似 デ バ イ ス で あ る/dev/random を使用

ii)

鍵生成の仕様：SP800-56A Rev.3

d) それぞれのメタデータ要素に対して、以下を含める
i)

メタデータのソース
TLS 1.3 のプロトコルii)

メタデータの検証方法
TLS 1.3 のプロトコルで検証e) 鍵確立（key establishment）の手段
i)

鍵配送スキーム：使用していない

ii)

鍵合意スキーム：ECDH（X25519, X448, P-256, P-386, P-521）

iii) プロトコル名：TLS 1.3
f) 暴露に対する保護（例えば、鍵の機密性、物理セキュリティ）鍵は、OpenSSL が動作するプロセスのメモリ上で一時的に使用され即破棄される
g) 改ざんに対する保護（例えば、MAC 又はデジタル署名）79

鍵合意一時的プライベート鍵は OpenSSL が動作するプロセスのメモリ上だけで使用されることにより保護される。鍵合意一時的公開鍵も受信後はメモリ上で処理されることにより保護されるh) 鍵を使用し得るアプリケーション
Web Server（Apache HTTP Server）、TLS 1.3i) 鍵の使用が許可されないアプリケーションh)で指定したアプリケーション以外は使用を許可しないj) 鍵保証（key assurances）
対称鍵保証（Symmetric key assurances）

i)

該当無し
ii)

非対称鍵保証（Asymmetric key assurances）
ECDH の場合、当該楕円曲線上の点であり、特異な点でないことを確認する

iii) ドメインパラメタ有効性チェック
鍵合意は、TLS 1.3 で規定されているドメインパラメタを使用している。規定
された番号で合意し、ドメインパラメタの値自体を伝送しないので、有効性は
保証される
D.04

⚫ 署名のプライベート鍵と公開鍵の保管方法は PKCS#8 形式のパスワード付き暗号化状態で保存する⚫ 証明書は X.509 を使用する。伝送は、TLS 1.3 を使用する

4.3

鍵情報の保護方針①

メタデータ要素内に含まれている情報の保護方法の決定⚫

暗号学的プロセスを利用する場合

項目 FR 番号 Framework Requirements の内容
D.05 FR6.3

メタデータ要素の鍵保護（Key Protections）で使用されるそれぞれの暗号メカニズムに対して、CKMS 設計は、以下を明記しなければならない：
i. 暗号アルゴリズム
ii. 鍵パラメタ
iii. 鍵識別子
iv. 保護値（protection value）: この要素は、完全性保護、機密性保護、又はソース認証（source authentication）の保護値（protection value）を含む。例えば、適切に実装された MAC
又はデジタル署名技術は、完全性保護やソース認証（source
authentication）を提供し得る。
v. 保護が適用された時期

80

SP800-130
6.2.1 節vi. 保護が検証された時期
D.06 FR6.5

メタデータ要素のメタデータ保護（Metadata Protections）で使用

6.2.1 節されるそれぞれの暗号メカニズムに対して、CKMS 設計は、以下を明記しなければならない：
i. 暗号アルゴリズム
ii. 鍵パラメタ
iii. 鍵識別子
iv. 保護値（protection value）（例：MAC、デジタル署名）
v. 保護が適用された時期
vi. 保護が検証された時期
一般に、特に鍵とメタデータがひとまとめにされる場合、鍵とメタデータに対して同じメカニズムが使用される。
D.07 FR6.7

メタデータ要素の信頼関係保護で使用されるそれぞれの暗号メカニ

6.2.1 節ズムに対して、CKMS 設計は、以下を明記しなければならない：
i. 暗号アルゴリズム
ii. 鍵パラメタ
iii. 鍵識別子
iv. 保護値（protection value）（例：MAC、デジタル署名）
v. 保護が適用された時期
vi. 保護が検証された時期⚫

信頼プロセスを利用する場合

項目 FR 番号 Framework Requirements の内容
D.08 FR6.4

メタデータ要素の鍵保護（Key Protections）で使用される暗号学的SP800-130
6.2.1 節ではないそれぞれの信頼プロセスに対して、CKMS 設計は、以下を明記しなければならない：
i. 他のプロセスと区別するために使用されるプロセス識別子
ii. プロセスの説明又はプロセスの説明へのポインタ
D.09 FR6.6

メタデータ要素のメタデータ保護（Metadata Protections）で使用

6.2.1 節される暗号学的ではないそれぞれの信頼プロセスに対して、CKMS
設計は、以下を明記しなければならない：
i. このプロセスを他のプロセスから区別するために使用される
識別子
ii. プロセスの説明又はプロセスの説明へのポインタ
D.10 FR6.8

メタデータ要素の信頼関係保護で使用される暗号学的ではないそれ
ぞれの信頼プロセスに対して、CKMS 設計は、以下を明記しなければならない：

81

6.2.1 節i. このプロセスを他のプロセスから区別するために使用される
識別子
ii. プロセスの説明又はプロセスの説明へのポインタ

解説・考慮点
メタデータ要素内の暗号鍵、メタデータ及びそれらの信頼関係に関して、暗号学的プロセス又は信頼プロセスのいずれかにより保護しなければならない。
CKMS の設計にあたって、項目 D.05～D.07 は、暗号学的プロセスを利用する場合の保護方法に関する要求事項を明確化することを求めたものである。D.05 は暗号鍵の保護、D.06 はメタ
データの保護、D.07 は信頼関係の保護を対象にしている。
項目 D.08～D.10 は、信頼プロセスを利用する場合の保護方法に関する要求事項を明確化することを求めたものである。D.05～D.07 と同様、D.08 は暗号鍵の保護、D.09 はメタデータの保護、D.10 は信頼関係の保護を対象にしている。
なお、D.05～D.07、D.08～D.10 のいずれかが対象である。
CKMS 設計者が管理する必要がある全ての暗号鍵とメタデータは、鍵タイプや使用用途により適切な保護が必要であり、例えば、プライベート鍵は復号や署名するエンティティ以外には知られることが無いように保管することが必要である。また、鍵タイプによってはメタデータとの組
み合わせによりその暗号鍵の完全性を確保する場合もあるため、とりわけそのような鍵タイプの暗号鍵ではメタデータの管理も安全な鍵情報の管理を実施するために重要となる。そのため、D.02 で暗号鍵とメタデータの関連付けの手段を利用するとしたメタデータについては、どのような関連付けの手段を利用し、両者の関連性が正しいことを保証するかについての具体的な方法を示すことが求められる。
本節では、暗号鍵やメタデータ、信頼関係の保護方針を明確にすることで、鍵情報が安全に管理されていることを確認することを意図している。
具体的には、保護手段として暗号メカニズムを使用している場合は、そこで利用 している具体的な暗号アルゴリズムや鍵パラメタなど、D.05～D.07 の項目を明確化する必要である。D.05 は暗号鍵に対する、D.06 は関連付けられたメタデータに対する、完全性、機密性及びソース認証（source authentication）の保護が対象であり、D.07 は、暗号鍵とメタデータが正しく関連付けられていることを保証するために、その暗号鍵とメタデータとの信頼関係の保護が対象である。
なお、これらは同じメカニズムで保護される場合もあれば、別のメカニズムで保護することもある。さらには、暗号鍵とメタデータが同時に関連付けて保護され、信頼関係保護が暗黙的に提供されている場合もある。
保護手段として信頼プロセスを使用している場合は、そこで利用している具体的なプロセスについて D.08～D.10 の項目を明確化することが必要である。
なお、以上の内容は、D.02、D.03 での記載内容と整合していなければならない。

82

《トイモデルと記載例》
本節のトイモデルは 4.2 節と同じである。このトイモデルでは、D.02 において、「信頼プロセ
スはプライベート鍵の保護のために root 権限でプライベート鍵ファイルを保存し、OS のユーザ管理機能で root 以外のユーザはファイルにアクセスできなくし、暗号学的プロセスはデジタル署
名を利用して公開鍵やメタデータの完全性を保護する」こととしている。
その方針に従い、本トイモデルが利用している、具体的な暗号メカニズムを使用した保護手段についての情報を D.05～D.07 に、具体的な信頼プロセスを使用した保護手段についての情報を
D.08～D.010 にそれぞれ記載する。
以上のトイモデルにおける記載例は、以下の「施設内 Web サーバシステムにおける記載例」のようになる。
施設内 Web サーバシステムにおける記載例
D.05

署名公開鍵の保護
i. 暗号アルゴリズム
ECDSA

ii. 鍵パラメタ
P-256
iii. 鍵識別子
公開鍵のハッシュ値
iv. 保護値（protection value）
デジタル署名v. 保護が適用された時期
日本時間 2023 年 5 月 8 日 00:00:00

vi. 保護が検証された時期
日本時間 2023 年 5 月 8 日 00:00:00
D.06

署名の鍵ペアのメタデータの保護
i. 暗号アルゴリズム
ECDSA

ii. 鍵パラメタ
P-256
iii. 鍵識別子
公開鍵のハッシュ値
iv. 保護値（protection value）
デジタル署名v. 保護が適用された時期
日本時間 2023 年 5 月 8 日 00:00:00

vi. 保護が検証された時期
日本時間 2023 年 5 月 8 日 00:00:00
83

D.07

署名の鍵ペアとメタデータの関係性の保護
i. 暗号アルゴリズム
ECDSA

ii. 鍵パラメタ
P-256
iii. 鍵識別子
公開鍵のハッシュ値
iv. 保護値（protection value）
デジタル署名v. 保護が適用された時期
日本時間 2023 年 5 月 8 日 00:00:00

vi. 保護が検証された時期
日本時間 2023 年 5 月 8 日 00:00:00
D.08

Web サーバでの署名プライベート鍵のファイルは、root 権限でのみアクセス可能。このアクセス権限は Linux のパーミッションを利用して実現している

D.09

Web サーバでの署名処理の入力として利用されるメタデータの管理に関するファイル
は、root 又は Web サーバ管理ユーザ権限でのみアクセス可能。このアクセス権限は Linuxのパーミッションを利用して実現している

D.10

D.09 での保護方法により、メタデータ要素の信頼関係も保護している84

資料５－１CRYPTREC暗号リストの改定について

今次のCRYPTREC暗号リスト改定（旧“全面改定”）に至る主な経緯
１. リストの全面改定を実施、今後のリスト改定方針の大枠を決定（2012年度暗号技術検討会）

・2003年に策定した「電子政府推奨暗号リスト」を、「電子政府推奨暗号リスト」、「推奨候補暗号リスト」、「運用監視暗号リスト」の３リストで構成する「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」に再構成。
・「CRYPTREC暗号リスト」の次回の全面改定は10年後を目途に実施する等、今後のリスト改定方針の大枠を決定。

２. 2023年目途のリスト改定方針を決定（2020年度暗号技術検討会）

・2023年目途のリスト改定に当たり、３リスト構成を維持する方針、技術分類の構成を維持する方針を決定。
・上記改定に当たり、暗号技術の公募は行わない方針を決定。

３. 2023年目途のリスト改定等に適用する新たな基準を決定（2021年度暗号技術検討会）

・「推奨候補暗号リスト」から「電子政府推奨暗号リスト」へ昇格させる暗号アルゴリズムを選定する際の、暗号アルゴリズムの利用実績による選定基準（別紙１）を決定。
※ 上記基準決定後の「CRYPTREC 暗号リスト」移行ルールは別紙２のとおり。

４. 2023年のリスト改定に係る具体的改定内容を検討（2022年度暗号技術活用委員会）

・ 2022年度に暗号技術活用委員会が実施した暗号アルゴリズム利用実績調査の結果を踏まえ、暗号技術活用委員会において、「推奨候補暗号リスト」から「電子政府推奨暗号リスト」への昇格候補として暗号技術検討会に推薦する暗号アルゴリズム（別紙３）を決定。

５. 2023年のリスト改定に係る意見募集の公示案を決定（2022年度第1回暗号技術検討会）

・暗号技術活用委員会において決定された暗号技術検討会に推薦する暗号アルゴリズム（別紙３）を踏まえて、意見募集において公示する
CRYPTREC暗号リストの改定案を決定した。

「電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)」(案)に対する意見募集に寄せられたご意見並びにそれらに対するデジタル庁、総務省及び経済産業省の考え方（暗号技術検討会事務局案） (資料5-2)
及びCRYPTREC暗号リスト(改定版)(暗号技術検討会事務局案) (資料5-3)をご審議いただきたい。

暗号アルゴリズムの利用実績による選定基準
考慮項目
採用実績

別紙１

選定目安
以下のいずれかを満たす場合、昇格の検討対象に含める。なお、採用実績は、
5年ごとに実施予定の大規模アンケート調査による「利用実績調査」

必要に応じて、事務局が（大規模アンケート調査によらずに）情報収集する「利用実態確認」
により確認するものとする。
① 利用実績調査の結果、電子政府推奨暗号リストに掲載されている 電子政府推奨暗号リスト掲載の（同一カテゴリの）暗号技（同一カテゴリの）暗号技術の採用実績と遜色がないことが確認さ 術の採用実績と同等以上の採用実績がある推奨候補暗号リれた場合
スト掲載の暗号技術を昇格検討対象とする。
② 利用実績調査又は利用実態確認の結果、電子政府システムや重要イ 必要に応じて、利用実績調査に代わって、各府省庁等へのンフラ等、日本の基幹システムにおいてすでに利用されていること 照会を実施し、照会結果（クローズドな利用を含め）を基が確認された場合に昇格検討対象を選定する。
利用実績調査又は利用実態確認の結果、③～⑤のいずれかが確認された 「複数」「利用者が多い（主要な）」というキーワードの場合：
両方を十分に満たし、明らかな採用促進が確認された場合③ 利用者が多い主要な汎用製品群の複数に搭載されるなど、明らかに には、必要に応じて、昇格検討対象とする。
※「複数」の意味は、必要条件として「2個以上が必要」と採用が進展していると判断された場合④ 利用者が多い主要なオープンソースソフトウェアの複数に搭載され いうことであって、「2個以上あればよい」という十分条件るなど、明らかに採用が進展していると判断された場合としての意味ではないことに留意⑤ 利用者が多い主要なサービスやプロトコルの複数で利用されるなど、明らかに採用が進展していると判断された場合

標準化実績 以下を満たす場合、昇格の検討対象に含める。
⑥ 利用実績調査の結果、電子政府推奨暗号リストに掲載されている 電子政府推奨暗号リスト掲載の（同一カテゴリの）暗号技（同一カテゴリの）暗号技術の採用実績と遜色がないことが確認さ 術の採用実績と同等以上の採用実績がある推奨候補暗号リれた場合
スト掲載の暗号技術は昇格検討対象とする。
3

CRYPTREC 暗号リスト移行ルール

別紙２

4

暗号技術検討会に推薦する暗号アルゴリズム
暗号アルゴリズムの技術分類
公開鍵暗号（署名）ハッシュ関数

暗号利用モード（秘匿モード）
認証暗号
エンティティ認証

推薦する暗号アルゴリズム
EdDSA
SHA-512/256
SHA3-256
SHA3-384
SHA3-512SHAKE128SHAKE256
XTS
ChaCha20-Poly1305
ISO/IEC 9798-4

別紙３

資料５－２「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗号リスト）」（案）に対する意見募集に寄せられたご意見並びにそれらに対するデジタル庁、総務省及び経済産業省の考え方（暗号技術検討会事務局案）

「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗号リスト）」（案）に対する意見の募集で寄せられたご意見について○ 意見募集期間：令和５年３月９日～令和５年３月２３日○ 提出意見総数： ４件（１） 個人 ４件（２） 法人・団体 ０件

項目

頂いたご意見

ご意見に対する考え方【意見１】入力データについて全般（意見）アルファベットの大文字と小文字を区別して認識するタイプの暗号を導入するのは、どうでしょうか。
（理由）より、セキュリティレベルが上ると思うから、です。
【個人１－１】CRYPTREC 暗号リストに掲載している暗号技術
では、入力データや鍵等はビット列として取り扱います。

【意見２】表の体裁について
電子政府推奨暗号リスト（意見）表の左上の枠を加えるのは、どうでしょうか。
（理由）枠が抜けているため、です。
【個人１－２】

ご指摘を踏まえ、表の改ページ箇所を修正いた
しました。

項目

頂いたご意見

ご意見に対する考え方【意見３】DSA について
電子政府推奨
暗号リスト（意見）DSA に関しては「電子政府推奨暗号リスト」ではなく「運用監視暗号リスト」にリストするべきではないか？
（理由）NIST FIPS186-5（ドラフト）では以下の扱いとなっているため。
デジタル署名アルゴリズム (DSA)
この標準の以前のバージョンでは、DSA が指定されていました。この規格は、DSA を承認しなくなりました。
デジタル署名の生成。 DSA は、事前に生成された署名を検証するために使用できます。
この規格の実装日。 DSA の仕様については、FIPS 186-4 [20] を参照してください。
ーー
4 The Digital Signature Algorithm (DSA)
Prior versions of this standard specified the DSA. This standard no longer
approves DSA for digital signature generation. DSA may be used to verify
signatures generated prior to the implementation date of this standard. See FIPS
186-4 [20] for the specifications for DSA.
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf【個人２】

頂きました御意見は、今後の検討課題とさせて
頂きます。

項目

頂いたご意見

ご意見に対する考え方【意見４】SHA-1 について
運用監視暗号
リスト

SHA-2 への移行が十分進んだことを考慮し、SHA-1 は廃止してよいと思う。
【個人３－１】

頂きました御意見は、今後の検討課題とさせて頂きます。

【意見５】3-key Triple DES について
運用監視暗号
リスト

AES への移行が十分に進んだ点や、現在脆弱性が指摘されている点も加味すると、3DES は廃止するべきだと思う。
【個人３－２】

頂きました御意見は、今後の検討課題とさせて頂きます。

【意見６】CBC について
電子政府推奨暗号リスト

以下、「「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗 暗号利用モード（秘匿モード）CBC の暗号技術自号リスト）」の改定案」に意見を行う。
体の安全性は CRYPTREC により確認されており、電子政府推奨暗号リストへの掲載を維持する＞1 頁
ことが適当と考えます。
＞電子政府推奨暗号リスト
なお、暗号技術の利用時に安全性を確保する方「暗号利用モード」の「秘匿モード」に「CBC」が含まれているが、CBC は、かなりの 法については、CRYPTREC で作成している「TLS
数、かなり多くの場合（TLS1.2 を含んでいる場合も多い）で危険という報告が行わ 暗号設定ガイドライン」等において示しています。
れているので、電子政府推奨暗号リストへの掲載は停止すべきと考える。
（条件によっては脆弱性が発揮されない場合もあると思われるが、そもそも CBCを利用しない方が安全と思われる。TLS などにおいては（TLS1.2 以降において）基本として全く CBC を利用しない方が望ましいと思われる。CBC の掲載は問題あるものと思われる。）
意見は以上である。
【個人４】

資料５－３
CRYPTREC LS-0001-2022

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）（暗号技術検討会事務局案）
令和●年●月●日
デジタル庁・総務省・経済産業省
電子政府推奨暗号リスト
暗号技術検討会 1 及び関連委員会（以下、「CRYPTREC」という。）により安全性及び実装性能が確認された暗号技術 2 について、市場における利用実績が十分であるか今後の普及が見込まれると判断され、当該技術の利用を推奨するもののリスト。
なお、利用する鍵長について、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 5の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。
技術分類

暗号技術
DSA
ECDSA
EdDSA
RSA-PSS（注１）
RSASSA-PKCS1-v1_5（注１）
RSA-OAEP（注１）
DH

署名
公開鍵暗号
守秘
鍵共有
（注２）

64ビットブロック暗号
共通鍵暗号

128ビットブロック暗号
ストリーム暗号

ECDH
該当なし
AES
Camellia
KCipher-2
SHA-256
SHA-384
SHA-512
SHA-512/256

ハッシュ関数

SHA3-256
SHA3-384
SHA3-512SHAKE128（注12）
SHAKE256（注12）（次ページに続く）

1

デジタル庁統括官、総務省サイバーセキュリティ統括官及び経済産業省商務情報政策局長が有識者の参集を求め、暗号技術の普及による情報セキュリティ対策の推進を図る観点から、専門家による意見等を聴取することにより、デジタル庁、総務省及び経済産業省における施策の検討に資することを目的として開催。
2
暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
5
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

1

技術分類

暗号技術
CBC
CFB
CTR

秘匿モード
暗号利用モード

OFB
XTS（注17）
認証付き秘匿モード（注13）

CCM
GCM（注４）CMAC
HMAC
ChaCha20-Poly1305

メッセージ認証コード
認証暗号

ISO/IEC 9798-2
ISO/IEC 9798-3
ISO/IEC 9798-4

エンティティ認証（注１）「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/pdf/policy/general/angou_ikoushishin.pdf（平成25年３月１日現在）（注２）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注４）

初期化ベクトル長は96ビットを推奨する。

（注12） ハッシュ長は256ビット以上とすること。
（注13） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
（注17） ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用
途はストレージデバイスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。

2

推奨候補暗号リスト
CRYPTRECにより安全性及び実装性能が確認され、今後、電子政府推奨暗号リス
トに掲載される可能性のある暗号技術 3 のリスト。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 6の規定に合致する鍵長を用いることが求められることに留意すること。
技術分類

暗号技術

署名
守秘

該当なし
該当なし

鍵共有

ハッシュ関数

PSEC-KEM（注５）
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1CIPHERUNICORN-A
CLEFIA
Hierocrypt-3
Enocoro-128v2
MUGI
MULTI-S01（注７）
該当なし

秘匿モード
認証付き秘匿モード（注14）メッセージ認証コード
認証暗号
エンティティ認証該当なし
該当なし
PC-MAC-AES
該当なし
該当なし

公開鍵暗号

64ビットブロック暗号（注６）

共通鍵暗号

128ビットブロック暗号

ストリーム暗号

暗号利用モード（注５）

KEM (Key Encapsulating Mechanism) – DEM (Data Encapsulating Mechanism) 構成
における利用を前提とする。

（注６）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注７）

平文サイズは64ビットの倍数に限る。

（注14） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

3

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
6
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

3

運用監視暗号リスト
実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったと
CRYPTRECにより確認された暗号技術 4のうち、互換性維持のために継続利用を容認するもののリスト。互換性維持 7以外の目的での利用は推奨しない。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 8の規定に合致する鍵長を用いることが求められることに留意
すること。
技術分類
公開鍵暗号

共通鍵暗号

暗号技術

署名
守秘

該当なし
RSAES-PKCS1-v1_5（注８）（注９）

鍵共有
64ビットブロック暗号（注15）
128ビットブロック暗号
ストリーム暗号

該当なし
3-key Triple DESRIPEMD-160
SHA-1（注８）
該当なし

ハッシュ関数
暗号利用モード

該当なし
該当なし

秘匿モード

認証付き秘匿モード（注16）メッセージ認証コード
認証暗号
エンティティ認証

該当なし
CBC-MAC（注11）
該当なし
該当なし

（注８）

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月 情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/pdf/policy/general/angou_ikoushishin.pdf（平成25年３月１日現在）（注９）

TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める。

（注11） 安全性の観点から、メッセージ長を固定して利用すべきである。
（注15） CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。
（注16） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

4

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
7
既に稼働中のシステムやアプリケーション等との間での相互運用を継続すること
8
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

4資料５－４
CRYPTREC LS-0001-2012R8

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）
平成25年３月１日
デジタル庁・総務省・経済産業省（最終更新：令和５年３月８日）

電子政府推奨暗号リスト
暗号技術検討会 1 及び関連委員会（以下、「CRYPTREC」という。）により安全性及び実装性能が確認された暗号技術 2 について、市場における利用実績が十分であるか今後の普及が見込まれると判断され、当該技術の利用を推奨するもののリスト。
なお、利用する鍵長について、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 5の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。
技術分類

暗号技術
DSA
ECDSA
RSA-PSS（注１）

署名

RSASSA-PKCS1-v1_5（注１）
RSA-OAEP（注１）

公開鍵暗号
守秘
鍵共有
64ビットブロック暗号（注２）
共通鍵暗号

DH
ECDH
該当なし

128ビットブロック暗号

AES
Camellia

ストリーム暗号

KCipher-2
SHA-256
SHA-384
SHA-512
CBC
CFB
CTR
OFB

ハッシュ関数

秘匿モード
暗号利用モード
認証付き秘匿モード（注13）

CCM
GCM（注４）
CMAC
HMAC
該当なし

メッセージ認証コード
認証暗号

ISO/IEC 9798-2
ISO/IEC 9798-3

エンティティ認証

1

デジタル庁統括官、総務省サイバーセキュリティ統括官及び経済産業省商務情報政策局長が有識者の参集を求め、暗号技術の普及による情報セキュリティ対策の推進を図る観点から、専門家による意見等を聴取することにより、デジタル庁、総務省及び経済産業省における施策の検討に資することを目的として開催。
2
暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
5
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

1

（注１）

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf（平成25年３月１日現在）（注２）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注４）

初期化ベクトル長は96ビットを推奨する。

（注13） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

2

推奨候補暗号リスト
CRYPTRECにより安全性及び実装性能が確認され、今後、電子政府推奨暗号リス
トに掲載される可能性のある暗号技術 3 のリスト。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 6の規定に合致する鍵長を用いることが求められることに留意すること。
技術分類
公開鍵暗号

暗号技術

署名
守秘

EdDSA
該当なし

鍵共有

PSEC-KEM（注５）
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1CIPHERUNICORN-A
CLEFIA
Hierocrypt-3
Enocoro-128v2
MUGI
MULTI-S01（注７）64ビットブロック暗号（注６）

共通鍵暗号

128ビットブロック暗号

ストリーム暗号

ハッシュ関数

SHA-512/256
SHA3-256
SHA3-384
SHA3-512SHAKE128（注12）
SHAKE256（注12）

秘匿モード
認証付き秘匿モード（注14）メッセージ認証コード

XTS（注17）
該当なし
PC-MAC-AES

認証暗号
エンティティ認証

ChaCha20-Poly1305
ISO/IEC 9798-4

暗号利用モード（注５）

KEM (Key Encapsulating Mechanism) – DEM (Data Encapsulating Mechanism) 構成
における利用を前提とする。

（注６）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注７）

平文サイズは64ビットの倍数に限る。

（注12） ハッシュ長は256ビット以上とすること。
（注14） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
（注17） ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用
途はストレージデバイスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。

3

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
6
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

3

運用監視暗号リスト
実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったと
CRYPTRECにより確認された暗号技術 4のうち、互換性維持のために継続利用を容認するもののリスト。互換性維持 7以外の目的での利用は推奨しない。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 8の規定に合致する鍵長を用いることが求められることに留意
すること。
技術分類
公開鍵暗号

共通鍵暗号

暗号技術

署名
守秘

該当なし
RSAES-PKCS1-v1_5（注８）（注９）

鍵共有
64ビットブロック暗号（注15）
128ビットブロック暗号
ストリーム暗号

該当なし
3-key Triple DESRIPEMD-160
SHA-1（注８）
該当なし

ハッシュ関数
暗号利用モード

該当なし
該当なし

秘匿モード

認証付き秘匿モード（注16）メッセージ認証コード
認証暗号
エンティティ認証

該当なし
CBC-MAC（注11）
該当なし
該当なし

（注８）

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月 情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf（平成25年３月１日現在）（注９）

TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める。

（注11） 安全性の観点から、メッセージ長を固定して利用すべきである。
（注15） CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。
（注16） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

4

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
7
既に稼働中のシステムやアプリケーション等との間での相互運用を継続すること
8
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

4変更履歴情報
変更日付
変更箇所
平成27年 （注10）３月27日

変更前の記述変更後の記述128-bit RC4は、SSL（TLS1.0 互換性維持のために継続利用を以上）に限定して利用するこ これまで容認してきたが、今後はと。
極力利用すべきでない。SSL/TLS
での利用を含め、電子政府推奨暗号リストに記載された暗号技術への移行を速やかに検討すること。
SHA-512/256
平成28年 推奨候補暗号リスト 該当なし
SHA3-256
３月29日 (技術分類：ハッシュ
SHA3-384
関数)
SHA3-512SHAKE256（注12）（注12）[新規追加]
ハッシュ長は256ビット以上とすること。
平成29年 推奨候補暗号リスト SHA-512/256
SHA-512/256
３月30日 （技術分類：ハッシュ SHA3-256
SHA3-256
SHA3-384
関数）
SHA3-384
SHA3-512
SHA3-512SHAKE256（注12）
SHAKE128（注12）
SHAKE256（注12）
平成30年 （注２）より長いブロック長の暗号が CRYPTREC暗号リスト におい て、
３月29日 （注６）
利用できるのであれば、128 64ビットブロック暗号により、同一ビットブロック暗号を選択する の鍵を用いて暗号化する場合、220
ことが望ましい。
ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生（注15）[新規追加]
成する場合、221 ブロックまでとする。
（注３）
電子政府推奨暗号リ 3-key Triple DES
該当なし
スト（技術分類：共通
鍵暗号）
（注３）
3-key Triple DESは、以下の [削除]条件を考慮し、当面の利用を認める。
１） NIST SP 800-67として規定されていること。
２） デファクトスタンダードとしての位置を保っていること。
運用監視暗号リスト 該当なし
3-Key Triple DES（注１５）（ 技 術 分 類： 共 通 鍵
暗号）
電子政府推奨暗号リ [技術分類の新設]
技術分類：認証暗号
スト
暗号技術：該当なし
推奨候補暗号リスト
技術分類：認証暗号
暗号技術：ChaCha20-Poly1305
運用監視暗号リスト
技術分類：認証暗号
暗号技術：該当なし

5

（注13）（注14）（注16）[新規追加]CRYPTREC暗号リスト掲載のブロ
ック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
暗号技術

電子政府推奨暗号リ 名称
スト（見出し）推奨候補暗号リスト（見出し）
運用監視暗号リスト（見出し）
令 和 ２ 年 推奨候補暗号リスト 該当なし
12月21日 （ 技 術 分 類： 暗 号 利
用モ ード 秘匿モ ード）（注17）[新規追加]

XTS（注17）

ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用途はストレージデバ
イスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。
該当なし

令 和 ３ 年 運用監視暗号リスト 128-bit RC4（注10）
４月１日 （ 技 術 分 類： 共 通 鍵
暗号）
（注10）
互換性維持のために継続利 [削除]
用をこれまで 容認して きたが、今後は極力利用すべきで な い 。 TLS で の 利 用 を 含
め、電子政府推奨暗号リストに記載された暗号技術への移行を速やかに検討すること。
令和４年 文書クレジット
総務省・経済産業省
デジタル庁・総務省・経済産業省
３月３０日 推奨候補暗号リスト 該当なし
EdDSA
（ 技 術 分 類： 公 開 鍵
暗号 署名）
電子政府推奨暗号リ 暗号技術検討会及び関連委 暗号技術検討会及び関連委員会
スト（本文）
員会（以下、「CRYPTREC」と （以下、「CRYPTREC」という。）にいう。）により安全性及び実装 より安全性及び実装性能が確認さ性能が確認された暗号技術 れた暗号技術について、市場におについて、市場における利用 ける利用実績が十分であるか今
実績が十分であるか今後の 後の普及が見込まれると判断さ
普及が見込まれると判断さ れ、当該技術の利用を推奨するもれ、当該技術の利用を推奨 ののリスト。なお、利用する鍵長について、「暗号強度要件（アルゴリするもののリスト。
ズム及び鍵長選択）に関する設定基準」の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。

6

電子政府推奨暗号リ 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及びスト（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」5定基準」
5CRYPTREC, 暗号強度要件（アルゴリズム及電子政府推奨暗号リ 該当なし
び鍵長選択）に関する設定基準,
スト（脚注）
https://www.cryptrec.go.jp/list.html
推奨候補暗号リスト CRYPTREC に よ り 安 全 性 及 CRYPTRECにより安全性及び実装（本文）
び実装性能が確認され、今 性能が確認され、今後、電子政府
後、電子政府推奨暗号リスト 推奨暗号リストに掲載される可能に掲載される可能性のある 性のある暗号技術のリスト。なお、
本リストに記載されている暗号技
暗号技術のリスト。
術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」の規定に合致する鍵長を用いることが求められることに留意すること。
推奨候補暗号リスト 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及び（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」6定基準」
6CRYPTREC, 暗号強度要件（アルゴリズム及推奨候補暗号リスト 該当なし
び鍵長選択）に関する設定基準,（脚注）
https://www.cryptrec.go.jp/list.html
運用監視暗号リスト 実際に解読されるリスクが高 実際に解読されるリスクが高まる（本文）
まるなど、推奨すべき状態で など、推奨すべき状態ではなくなっはなくなったとCRYPTRECに たとCRYPTRECにより確認されたより確認された暗号技術のう 暗号技術のうち、互換性維持のた
ち、互換性維持のた めに継 めに継続利用を容認するもののリ
続利用を容認するもののリス スト。互換性維持以外の目的でのト。互換性維持以外の目的で 利用は推奨しない。なお、本リストに記載されている暗号技術を利用の利用は推奨しない。
する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」の規定に合致する鍵長を用いることが求められることに留意すること。
運用監視暗号リスト 互換性維持
互換性維持7（本文）
7
既に稼働中のシステムやアプリケーション等
運用監視暗号リスト 該当なしとの間での相互運用を継続すること（脚注）
運用監視暗号リスト 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及び（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」8定基準」
8CRYPTREC, 暗号強度要件（アルゴリズム及運用監視暗号リスト 該当なし
び 鍵 長選 択） に 関す る 設 定基 準,（脚注）
https://www.cryptrec.go.jp/list.html
令 和 ５ 年 推奨候補暗号リスト SC2000
３月８日 （ 技 術 分 類： 共 通 鍵
暗号）

[削除]
（提案会社からの取下げ申請を承認したことによる）

7

資料６2023 年度暗号技術評価委員会活動計画(案)1. 活動目的
CRYPTREC 暗号リストに掲載されている暗号技術や電子政府システム等で利用される暗号技術の安全性維持及び信頼性確保のために安全性及び実装に係る監視及び評価を行う。

2. 活動概要(1) 暗号技術の安全性及び実装に係る監視及び評価
下記の通り、暗号技術の安全性に係る監視・評価 及び 実装に係る技術の監視・評価を実施する。
① CRYPTREC 暗号リストの監視国際会議等で発表される CRYPTREC 暗号リストの安全性及び実装に係る技術（暗号モジュールに対する攻撃とその対策も含む）に関する監視を行い、会議や ML を通して報告する。
② 電子政府推奨暗号リストからの運用監視暗号リストへの降格、並びに、推奨候補
暗号リスト及び運用監視暗号リストからの危殆化が進んだ暗号の削除に係る検討
CRYPTREC 暗号リストの安全性に係る監視活動を継続的に行い、急速に危殆化が進んだ暗号技術やその予兆のある暗号技術の安全性について評価を行う。
また、リストからの降格や削除、注釈の改訂が必要か検討を行う。
③ CRYPTREC 注意喚起レポートの発行
CRYPTREC 暗号リストの安全性及び実装に係る技術の監視活動を通じて、国際会議等で発表された攻撃等の概要や想定される影響範囲、対処方法について早期に公開することが望ましいと判断された場合、注意喚起レポートを発行する。
④ 推奨候補暗号リストへの新規暗号（事務局選出）の追加に係る検討
標準化動向に鑑み電子政府システム等での利用が見込まれると判断される暗号技術の追加を検討する。
⑤ 新技術等に関する調査及び評価
将来的に有用になると考えられる技術やリストに関わる技術について、安全性・性能評価を行う。必要に応じて、暗号技術調査ワーキンググループによる調査・評価、または、外部評価による安全性・性能評価などを行う。

 NIST の PQC 標準化において第 4 ラウンドが進行中であることから、引き続き、
暗号技術調査ワーキンググループ（耐量子計算機暗号）を設置して、耐量子
計算機暗号に関する最新動向を把握する。また、「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新についても当該ワーキンググループで検討し、更新を行う。
 2021 年度に承認された「軽量暗号ガイドライン更新方針」に従って、「CRYPTREC
暗号技術ガイドライン(軽量暗号)」2023 年度版の案を完成させる。
(2) 暗号技術の安全な利用方法に関する調査（技術ガイドラインの整備、学術的な安全性の調査・公表等）
暗号技術を利用する際の技術面での注意点に関する調査、新技術の安全性・性能に関する調査・評価を行う。

3.活動スケジュール
暗号技術評価委員会は、2 回の開催を予定する。
回

開催日

議案
 暗号技術評価委員会活動計画の具体的な進め方に関する審議第 1 回 2023 年 6 月中旬〜7 月上旬

 各暗号技術調査ワーキンググループの活動
計画(案)の審議
 軽量暗号ガイドライン更新のための調査・評価に関する審議 暗号技術評価委員会活動報告(案)についての審議
 各暗号技術調査ワーキンググループの活動

第 2 回 2024 月 2 月中旬～3 月上旬

報告(案)の審議、及び、各ガイドライン(案)に関する審議 軽量暗号ガイドライン更新のための調査・評価結果に関する審議以上資料７2023 年度 暗号技術活用委員会活動計画（案）1.

活動目的
暗号技術活用委員会では、情報システム全般のセキュリティ確保に寄与することを目的として、暗号の取り扱いに関する観点から、運用ガイドライン／ガイダンスの作成を行う。

2.

活動概要

（１） 暗号鍵管理ガイダンスの拡充
暗号鍵管理ガイドラインの拡充を目的として進めていた暗号鍵管理ガイダンスについて、2021 年度・
2022 年度に引き続いて暗号鍵管理ガイダンス WG を設置し、2022 年度発行版では記載を見送った部分の拡充を行う。2022 年度版の内容見直しも含め、2024 年度完成を目標とする。

（２） 暗号利活用のための新たなガイダンスの作成
2022 年度の活用委員会での議論を踏まえて、暗号利活用に向けた有用なガイダンステーマを一つ又は二つ選定し、新たなガイダンスの作成に着手する。おおむね 2 年程度での完成を想定して執筆作業を行う。

[2023 年度完成を目指すガイドライン／ガイダンス]⚫

TLS 暗号設定ガイドラインのアップデート[おおむね 2024 年度完成を目指すガイドライン／ガイダンスの候補]
同種のガイドライン／ガイダンスを作成している団体／組織などとの連携（リエゾン、joint WG）も含
めて体制を検討し、新たなガイドライン／ガイダンスを作成する（以下は、候補例）
。

3.

⚫

クラウドにおける鍵管理ガイダンス（例えば、日本クラウドセキュリティアライアンス（CSA））⚫

暗号化消去ガイダンス（例えば、データ適正消去実行証明協議会（ADEC））⚫

認証についてのガイダンス（例えば、FIDO アライアンス、OpenID ファウンデーション）

活動スケジュール
活用委員会の開催日程・議題については、以下のとおり、年 2 回の委員会開催を予定する。

1

回

開催日

議案（予定）◼ 委員長互選◼ 2023 年度活用委員会活動計画の確認

第1回

2023 年 7 月初旬◼ 暗号鍵管理ガイダンス WG 活動計画の審議◼ 「TLS 暗号設定ガイドライン」についての見直し検討◼ 「暗号利活用のための新たなガイダンス」についての検討◼ 「TLS 暗号設定ガイドライン」についての見直しとりまとめ

第2回

2022 年 3 月上旬◼ 暗号鍵管理ガイダンス WG 報告◼ 「暗号利活用のための新たなガイダンス」についての中間とりまとめ◼ 2023 年度暗号技術活用委員会活動報告案について

以上

2

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

２０２３年３月

１. 目次１. はじめに ......................................................................... 3
２. 暗号技術検討会開催の背景及び開催状況 ............................................. 4
２.１. 暗号技術検討会開催の背景 .................................................... 4
２.２. CRYPTRECの体制 .............................................................. 4
２.３. 暗号技術検討会の開催実績 .................................................... 6
３. 各委員会の活動報告 ............................................................... 8
３.１. 暗号技術評価委員会 .......................................................... 8
３.１.１. 活動の概要 ............................................................. 8
３.１.２. 暗号技術の安全性及び実装に係る監視及び評価 ............................. 8
３.１.３. 自主取下げに係る電子メールによる審議と結果 ............................. 8
３.１.４. 暗号技術調査ワーキンググループ（耐量子計算機暗号）...................... 9
３.１.５. 暗号技術調査ワーキンググループ（高機能暗号） .......................... 14
３.１.６. 「CRYPTREC暗号技術ガイドライン（軽量暗号）」更新に関わる活動............ 16
３.１.７. 暗号技術評価委員会の開催実績 .......................................... 18
３.２. 暗号技術活用委員会 ......................................................... 20
３.２.１. 活動の概要 ............................................................ 20
３.２.２. 2022年度の活動内容 .................................................... 20
３.２.３. 暗号技術活用委員会の開催状況 .......................................... 25
４. 今後のCRYPTRECの活動について .................................................... 26

2

１. はじめに
情報通信技術の急速な発展により、自動車、家電、医療、農業、工場など様々な分野で、あらゆるモノがネットワークに繋がるIoT社会が到来し、サイバー空間と実空間の高度な融合により、多様なニーズにきめ細やかに対応したモノやサービスを提供できる社会への産業構造の変化が進みつつある。一方で、IoT機器の普及に伴うサイバー攻撃の起点の増加や、サイバー攻撃自体の巧妙化・複雑化が続く中で、サイバー攻撃の影響が実空間にまで到達するリスクも増していくと考えられる。このような産業構造、社会の変化に伴うサイバー攻撃の脅威の増大に対応したセキュリティ確保が求められる中、暗号技術は既に様々な製品やサービスに組み込まれ、セキュリティを支える基盤技術として欠かせないものであるが、IoT機器から得られる大量のデータの流通・連携を支える上でも、その重要性は一層増すと考えられる。
このような社会の変化に伴い、CRYPTRECにおいても、これまで取り組んできた暗号アルゴリズムのセキュリティ確保を引き続き推進することに加えて、暗号アルゴリズムを利用したプロトコルのセキュリティ確保のための活動拡大や、情報システム全体のセキュリティ確保に向けた暗号技術の利活用のための情報提供等の貢献が求められている。
2022年度の各委員会の活動として、暗号技術評価委員会では、同委員会の下に設置された暗号技
術調査WG（耐量子計算機暗号）及び暗号技術調査WG（高機能暗号）において、それぞれ耐量子計算機暗号及び高機能暗号に関するガイドラインを作成した。また、軽量暗号ガイドラインについては、
ガイドライン更新のための基となる調査のため、軽量暗号技術に対する安全性評価及び実装性能評価を実施し、標準化動向についても併せて調査した。また、暗号技術調査WG（耐量子計算機暗号）では、「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図を更新した。暗号技術活用委員会では、CRYPTREC暗号リストの改定に向けた
利用実績に関する評価、暗号利活用のために作成すべきガイダンス候補の検討を行った。また、同委員会の下に設置された暗号鍵管理ガイダンスWGにおいて、「暗号鍵管理ガイダンス」の構成を見直しつつ、2022年度版の作成を行った。なお、「量子コンピュータ時代に向けた暗号の在り方検討タ
スクフォース」は2022年度開催しなかった。これらの2022年度の活動の詳細については、国立研究開発法人情報通信研究機構及び独立行政法人情報処理推進機構が取りまとめる「CRYPTREC Report
2022」を参照いただきたい。
今後も暗号技術を用いた情報システム及び情報社会全体のセキュリティ確保のために、成果物の検討や情報発信等を行っていく所存である。
末筆であるが、暗号技術検討会及び関係委員会等に御協力いただいた構成員、オブザーバの方々をはじめ、関係者の皆様に心から謝意を表する次第である。
2023年3月
暗号技術検討会
座長 松本

3

勉

２. 暗号技術検討会開催の背景及び開催状況
２.１. 暗号技術検討会開催の背景
暗号技術は情報セキュリティの基盤技術であり、その安全性を暗号技術の専門家により技術的、専門的な見地から客観的に評価することが重要である。電子政府のセキュリティ確保のためには、安全性に優れた暗号技術を利用することが不可欠である。
このため、総務省及び経済産業省は、客観的な評価により安全性及び実装性に優れると判断される暗号技術をリスト化し、各府省に対してその利用を推奨することにより、高度な安全性と信頼性に支えられ、国民が安心して利用できる電子政府の構築に貢献することを目指し、2001年5月に最初の暗号技術検討会を開催した。
暗号技術検討会において2003年2月に策定された電子政府推奨暗号リストは、2013年3月に改定が行われ、CRYPTREC暗号リストとして発表され、2023年4月に再改定を行っている。その後においても、電子政府推奨暗号等の安全性を評価・監視し、暗号技術の更なる普及促進を行うため、2021年9月に発足したデジタル庁、総務省及び経済産業省は、継続的に暗号技術検討会を開催している。

２.２. CRYPTRECの体制
CRYPTRECとは、Cryptography Research and Evaluation Committeesの略であり、デジタル庁、
総務省及び経済産業省が共同で開催する暗号技術検討会（座長：松本勉横浜国立大学教授）と、国立研究開発法人情報通信研究機構（NICT）及び独立行政法人情報処理推進機構（IPA）が共同で開催する委員会から構成される暗号技術評価プロジェクトをいう。
2022年度のCRYPTRECにおいては、暗号技術評価委員会では、同委員会の下に設置された暗号技術
調査WG（耐量子計算機暗号）及び暗号技術調査WG（高機能暗号）において、それぞれ耐量子計算機
暗号及び高機能暗号に関するガイドラインを作成した。また、軽量暗号ガイドラインについては、
ガイドライン更新のための基となる調査のため、NIST Lightweight Cryptography Projectのファイナリストを対象とした安全性評価及び実装性能評価を実施した。なお、安全性評価に関しては、
ISO/IEC標準規格として29192シリーズで規格化された軽量メッセージ認証コードの1つである
Tsudik's keymodeも追加対象とした。また、標準化動向についても併せて調査した。また、暗号技術調査WG（耐量子計算機暗号）では、「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図を更新した。暗号技術活用委員会では、CRYPTREC
暗号リストの改定に向けた利用実績に関する評価、暗号利活用のために作成すべきガイダンス候補の検討を行った。また、同委員会の下に設置された暗号鍵管理ガイダンスWGにおいて、「暗号鍵管理
ガイダンス」の構成を見直しつつ、2022年度版の作成を行った。

4

暗号技術検討会
座長：松本 勉 横浜国立大学教授（事務局：デジタル庁、総務省、経済産業省）

量子コンピュータ時代に向けた暗号の在り方検討タスクフォース

暗号技術評価委員会

暗号技術活用委員会

委員長：高木 剛 東京大学教授（事務局：NICT、IPA）

委員長：松本 勉 横浜国立大学教授（事務局：IPA、NICT）

暗号技術調査WG（高機能暗号、耐量子計算機暗号）

図2.2-1 2022年度CRYPTREC体制図

5

暗号鍵管理
ガイダンスWG

２.３. 暗号技術検討会の開催実績
2022年度の暗号技術検討会は、CRYPTREC 暗号リストの改定に係る承認、意見募集の実施方法及びその後の対応に係る承認等を行うために第1回を開催し、暗号技術評価委員会、暗号技術活用委
員会の活動報告、CRYPTREC暗号リストの改定に係る審議、暗号技術検討会2022年度報告書に係る承認等を行うために第2回を開催した。
【第 1 回】2023年2月27日（月）～2023年3月8日（水）（書類審議）（主な議題）
・公募提案暗号の自主取下げ要望に対する取り扱いルールの策定並びに「ECDSA、 ECDH 及びSC2000」の取扱いについて・CRYPTREC 暗号リストの改定について・意見募集の実施方法及びその後の対応について（概要）
・CRYPTREC暗号リストの改定について、原案のとおり承認された。
・意見募集の実施方法及びその後の対応について、原案のとおり承認された。
【第 2 回】2023年3月30日（木）9:00～11:00（主な議題）
・2022年度暗号技術評価委員会 活動報告について【報告】・CRYPTREC暗号技術ガイドライン（耐量子計算機暗号）及び CRYPTREC暗号技術ガイドライン（高機能暗号）について【承認】・2022年度暗号技術活用委員会 活動報告について【報告】・暗号鍵管理ガイダンスについて【承認】・「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」（案）に対する意見募集に寄せられたご意見に対するデジタル庁、総務省及び経済産業省の考え方（暗号技術検討会事務局案）並びにCRYPTREC暗号リストの改定版（暗号技術検討会事務局案）について【承認】
・2023年度暗号技術評価委員会活動計画 (案) について【承認】・2023年度暗号技術活用委員会活動計画 (案) について【承認】・暗号技術検討会 2022年度 報告書（案）について【承認】（概要）・2022年度暗号技術評価委員会について事務局より活動報告を行った。
・CRYPTREC暗号技術ガイドライン（耐量子計算機暗号）及び CRYPTREC暗号技術ガイドライン（高機能暗号）について事務局より説明が行われ、原案のとおり承認された。
・2022年度暗号技術活用委員会について事務局より活動報告を行った。
・暗号鍵設定ガイダンスについて事務局より説明が行われ、原案のとおり承認された。
・「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」（案）に対する意見募集に寄せられたご意見に対するデジタル庁、総務省及び経済産業省の考え方（暗号6技術検討会事務局案）並びにCRYPTREC暗号リストの改定版（暗号技術検討会事務局案）について事務局より説明が行われ、原案のとおり承認された。
・2023年度暗号技術評価委員会活動計画 (案) について事務局より説明が行われ、原案のとおり承認された。
・2023年度暗号技術活用委員会活動計画 (案) について事務局より説明が行われ、原案のとおり承認された。
・暗号技術検討会 2022年度 報告書（案）について事務局より説明が行われ、議論結果を追記することとした上で承認された。

7

３. 各委員会の活動報告
３.１. 暗号技術評価委員会
３.１.１. 活動の概要
暗号技術評価委員会は、CRYPTREC暗号リストに掲載されている暗号技術や電子政府システム等で利用される暗号技術の安全性維持及び信頼性確保のために安全性及び実装に係る監視及び評価を行う。主要な検討課題は以下のとおりである。
・ 暗号技術の安全性及び実装に係る監視及び評価
・ 暗号技術の電子政府推奨暗号リストからの降格
・ 暗号技術に関する注意喚起レポートのCRYPTRECホームページへの公表
・ 推奨候補暗号リストへの新規暗号（事務局選出）の追加
・ 新世代暗号に係る調査
また、次期CRYPTREC暗号リストとは別文書として、耐量子計算機暗号、高機能暗号、及び、軽量暗号に関するガイドラインを作成する。基本方針は以下のとおりである。
・ 耐量子計算機暗号に関するガイドラインを作成するため、2021-2022年度に、耐量子計算機暗号に関するワーキンググループを設置し。当該ガイドラインを作成した。
・ 高機能暗号に関するガイドラインを作成するため、2021-2022年度に、高機能暗号に関するワーキンググループを設置し、当該ガイドラインを作成した。
・ 軽量暗号に関するガイドラインについては、2016年度に作成した「CRYPTREC暗号技術ガイド
ライン（軽量暗号）」の更新のため、2022年度は、掲載されている暗号方式に関わる安全性解析について、2017年度以降の技術動向調査を行う。2023年度中を目途に現ガイドラインを更新する。
これらの課題について2022年度に行った具体的な検討内容を、以下のとおり報告する。

３.１.２. 暗号技術の安全性及び実装に係る監視及び評価
学会等での情報収集に基づくCRYPTREC暗号等の監視活動を行った。監視報告の詳細については、
CRYPTREC Report 2022（暗号技術評価委員会報告）に掲載する。

３.１.３. 自主取下げに係る電子メールによる審議と結果
ECDSA、ECDH及びSC2000の応募暗号について取り下げの申請があったため、暗号技術評価委員会
として以下の対応を行った。
表2：取り下げへの対応
理由
ECDSA及びECDH

取り扱いを応募暗号技術からCRYPTRECが選出した暗号技術に変更し、現状
通り、電子政府推奨暗号リストに記載しておくことは妥当であると判断す8

る。仕様書の参照先についても変更無しとする。
SC2000

応募社の判断を尊重し、取り下げを認める。推奨候補暗号リストから当該暗号技術を削除することは妥当であると判断する。

３.１.４. 暗号技術調査ワーキンググループ（耐量子計算機暗号）
大規模な量子コンピュータが実用化されても安全性を保てると期待される暗号（耐量子計算機暗号:PQC）の研究開発及び標準化などが各国で進められている。そこで、2020年度第2回暗号技術検討会において、耐量子計算機暗号ガイドラインを作成するために暗号技術調査ワーキンググループ(耐量子計算機暗号)（以下：PQC WG）を設置することが承認された。また、「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新を
PQC WG で実施することが承認された。
そして、2021年度、2022年度の2年間で耐量子計算機暗号ガイドラインを作成した。
2021年度のPQC WGの活動ではガイドライン作成の準備として、耐量子計算機暗号に関する研究
動向調査を行い、ガイドライン執筆方針を以下のように定めた。
⚫

耐量子計算機暗号のスコープ
公開鍵暗号を中心にまとめる。

⚫

耐量子計算機暗号に関する現状調査
ガイドライン及び調査報告書に記載する耐量子計算機暗号を5分類とし、さらに耐量子計算
機暗号の活用方法をガイドラインのみに記載する。これらの項目に関する情報を調査した。

⚫

ガイドライン及び調査報告書の目次案
i.

導入

ii.

PQC の活用方法（ガイドラインにのみ記載）

iii.

格子に基づく暗号技術iv.

符号に基づく暗号技術

v.

多変数多項式に基づく暗号技術

vi.

同種写像に基づく暗号技術vii.

ハッシュ関数に基づく署名技術➢iii 章以降の構成 (A 章の場合)
A.1．安全性の根拠となる問題（例：LWE問題、シンドローム復号問題）
A.2．代表的な暗号方式（例：Regev暗号、McEliece暗号）
A.3．主要な暗号方式
A.3.1．暗号方式1（例：CRYSTALS-KYBER, Classic McEliece）
A.3.2．暗号方式2
A.3.3．暗号方式3・・・
A.4. まとめ9そして、2022年度暗号技術評価委員会において、2022年度のPQC WGの活動として下記2点について実施する活動計画が承認された。
⚫

耐量子計算機暗号のガイドラインの執筆⚫

「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新

それらの成果（３．１．４．１～３．１．４．２節）は2022年度第2回暗号技術評価委員会にて報告され、了承された。
３.１.４.１. 耐量子計算機暗号に関するガイドラインの作成方針

耐量子計算機暗号ガイドライン及び調査報告書
耐量子計算機暗号ガイドラインは、暗号理論に精通していない利用者を対象とし、耐量子計算機
暗号に関する調査報告書は、暗号理論の研究者や技術者を対象とし、基本的には耐量子計算機暗号
ガイドラインは調査報告書から技術的詳細を省き、その一部を抜粋したものする。ただし、暗号理論に精通していない利用者のために、耐量子計算機暗号の活用方法を耐量子計算機暗号ガイドライ
ンでは記載し、調査報告書には記載しない。
耐量子計算機暗号ガイドライン及び調査報告書に記載する暗号方式の選定基準
公開鍵暗号方式である主要な耐量子計算機暗号（NIST PQC標準化への提案方式等）を記載するが、対象となる暗号方式は PQC WG によって承認されたものである。
ガイドラインの章立て
1

2

3

4

はじめに
1.1

耐量子計算機暗号(PQC) の必要性について

1.2

PQC の研究及び標準化等に関する動向

1.3

本調査における代表的なPQC の5 種類の分類を調査対象として選択した理由

PQC の活用方法
2.1

暗号の利用形態

2.2

各利用形態における課題

2.3

各利用形態における対策

格子に基づく暗号技術
3.1

格子に基づく暗号技術の安全性の根拠となる問題

3.2

代表的な格子に基づく暗号方式

3.3

格子に基づく主要な暗号方式: CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON

3.4

格子に基づく暗号技術に関するまとめ

符号に基づく暗号技術
4.1

符号に基づく暗号技術の安全性の根拠となる問題
10

5

6

7

4.2

代表的な符号に基づく暗号方式

4.3

符号に基づく主要な暗号方式: Classic McEliece, BIKE, HQC

4.4

符号に基づく暗号技術に関するまとめ

多変数多項式に基づく暗号技術
5.1

多変数多項式に基づく暗号技術の安全性の根拠となる問題

5.2

代表的な多変数多項式に基づく暗号方式

5.3

多変数多項式に基づく主要な暗号方式: UOV

5.4

多変数多項式に基づく暗号技術に関するまとめ同種写像に基づく暗号技術
6.1

同種写像に基づく暗号技術の安全性の根拠となる問題

6.2

代表的な同種写像に基づく暗号方式

6.3

同種写像に基づく主要な暗号方式: SQISign6.4

同種写像に基づく暗号技術に関するまとめ

ハッシュ関数に基づく署名技術
7.1

ハッシュ関数に基づく署名技術の安全性の根拠となる問題

7.2

代表的なハッシュ関数に基づく署名方式

7.3

主要な具体的なハッシュ関数に基づく署名方式: XMSS, SPHINCS

7.4

ハッシュ関数に基づく署名技術に関するまとめ

３.１.４.２. 「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図の更新「素因数分解の困難性に関する計算量評価」、「楕円曲線上の離散対数計算の困難性に関する計算量評価」の予測図（以下単に「予測図」という。）は公開鍵暗号方式のセキュリティパラメータの選択について検討を行うため、2006年度に設置された暗号技術調査WG（公開鍵暗号）において作成された。2019年度暗号技術評価委員会において、今後の予測図の取扱いについて審議し対応方針（「今後の予測図の取扱い」「今後の公開鍵暗号のパラメータ選択」）を決定した。2022年度において、対応方針の説明文をより一般の読者に読みやすくなるよう、以下のとおり修正した。
予測図の取扱い対応方針<今後の予測図の取扱い>(1) いわゆるムーアの法則を仮定して外挿線を年度末からプラス20年後まで従来通り直線で引き、評価に大きな変動がないと考えられる限りにおいては、安全サイドに倒した評価として予測
図 ※を当面の間更新していく。
<今後の公開鍵暗号のパラメータ選択>(2) 公開鍵暗号のパラメータ選択に関する対応方針については、安全性以外にも相互接続性など、運用上の観点もあるため、暗号技術評価委員会だけではなく、暗号技術検討会、暗号技術活用委員会や関係各所などを含めて検討する。
※予測図は各国・国際標準化機関等により示されている主要な暗号技術の安全性基準と比較すると、11

より現状に則した評価であり、危殆化時期がそれらよりも先に延びるものとなっている。
予測図の更新について
素因数分解問題の困難性および楕円曲線上の離散対数問題の困難性に関する計算量評価に大幅な進展はなかったため、TOP500.orgにおける2022年6月・11月のベンチマーク結果を追加して予測図の更新を行った（図3.2-1及び図3.2-2）。

図3.2-1：素因数分解の困難性に関する計算量評価（2023年1月更新）1

1

スーパーコンピューターの性能の伸びに関する外挿線は僅かであるが鈍化してきている。

12

図3.2-2：楕円曲線上の離散対数計算の困難性に関する計算量評価（2023年1月更新）2

2

スーパーコンピューターの性能の伸びに関する外挿線は僅かであるが鈍化してきている。

13

３.１.５. 暗号技術調査ワーキンググループ（高機能暗号）
公開鍵暗号は、アプリケーションが多様となりその活用が広まっている。その中で、従来の公開鍵暗号よりも機能が向上した高機能暗号を利用してアプリケーションに適用することが有効と考えられている。そこで、2020年度第2回暗号技術検討会において高機能暗号ガイドラインを作成するために暗号技術調査ワーキンググループ（高機能暗号）（以下「高機能暗号WG」という）を設置することが承認された。
そして、2021年度、2022年度の2年間で高機能暗号ガイドラインを作成した。
2021年度の高機能暗号WGの活動ではガイドライン作成の準備として、高機能暗号のスコープの明確化、技術に関する調査、アプリケーションに関する調査を行い、ガイドライン執筆方針を以下のように定めた。
⚫

高機能暗号のスコープ
高機能暗号を「従来の暗号技術に対して、機能が追加・向上されるなどの優位性を主張する
暗号、および、従来の暗号技術では困難であった事象を解決できるなどの新規機能を有することを主張する暗号技術」とした。

⚫

高機能暗号技術に関する現状調査
ガイドラインに記載する高機能暗号を 3 分類、17 項目とし、それぞれの項目について“技術”、“活用事例”、“標準化”を調査した。

⚫

高機能暗号のアプリケーションに関する調査
日本電気株式会社、三菱電機株式会社に対して 2022 年度にヒアリングを実施することとし、
日本電気株式会社にはプライバシ保護、三菱電機株式会社についてはＤＢ関連のデータ保護のアプリケーションの事例を紹介していただくこととした。

そして、2022年度暗号技術評価委員会において、2022年度の高機能暗号WGの活動として下記2点について実施する活動計画が承認された。
⚫

2021 年度に作成した目次案に沿ったガイドラインの執筆⚫

高機能暗号のアプリケーションに関するヒアリング調査および調査内容のガイドラインへの反映

それらの成果（３．１．５．１～３．１．５．２節）は2022年度第2回暗号技術評価委員会にて報告され、了承された。
３.１.５.１. 2021年度に作成した目次案に沿ったガイドラインの執筆
ガイドラインの作成
高機能暗号ガイドラインは、高機能暗号を導入することを考えている技術開発者や、コンソーシ
アム・標準化団体に関与する技術者などを読者として想定し、暗号理論に精通していない方々を対象として執筆した。
ガイドラインに記載する暗号方式の選定基準及び候補について
主要な高機能暗号方式として、対象となる暗号方式は暗号技術調査ワーキンググループ（高機能暗号）によって承認されたものである。
14

ガイドラインの章立て
１．

はじめに

２．

高機能暗号技術とその活用法

２．１ 高機能暗号とは
２．２ 高機能暗号の種類と分類
２．３ 高機能暗号はどこに使えるか、その有用性
２．４ 高機能暗号の活用事例と標準化動向
２．４．１ 守秘関連の暗号技術の活用事例と標準化動向
２．４．２ 認証・署名関連の技術の活用事例と標準化動向
２．４．３ その他の技術の活用事例と標準化動向
２．４．４ 活用事例から見た高機能暗号の利用方法
参考文献
３．

主な高機能暗号技術のアルゴリズム・プロトコルとその性能

３．１ 守秘関連の高機能暗号技術
３．１．１ IDベース暗号
３．１．２ 属性ベース暗号
３．１．３ 放送型暗号
３．１．４ 準同型暗号
３．１．５ プロキシ再暗号化
参考文献
３．２ 認証・署名を目的とした高機能暗号技術
３．２．１ 属性ベース署名
３．２．２ 集約MAC、マルチMAC、集約署名、マルチ署名
３．２．３ グループ署名
３．２．４ リング署名
３．２．５ しきい値署名
参考文献
３．３ その他の高機能暗号技術
３．３．１ 秘密分散
３．３．２ マルチパーティ計算－秘密分散ベース
３．３．３ マルチパーティ計算－Garbled Circuitベース－
３．３．４ ゼロ知識証明
３．３．５ Oblivious Random Access Machine（ORAM）
３．３．６ Private Information Retrieval（PIR）
３．３．７ 検索可能暗号
参考文献
４．

おわりに
15

３.１.５.２. 高機能暗号のアプリケーションに関するヒアリング調査および調査内容のガイドラ
インへの反映2021年度の高機能暗号WGにおいて、高機能暗号によって既存技術より効率的になる分野、既存技術でカバーできていない分野などで、高機能暗号の活用が期待される分野を整理する。この活動の一環として、より深くアプリケーション、応用例を知るためにエンドユーザのヒアリングを検討した。そして、2022年度第1回、第2回の高機能暗号WGにおいて、以下のヒアリングを実施した。
① 日本電気株式会社：秘密分散を利用した医療データ活用② 三菱電機株式会社：検索可能暗号＆属性ベース暗号
ヒアリングは、発表、質疑形式で行った。
このヒアリング内容は、本ガイドラインの“２．４．４章活用事例から見た高機能暗号の利用方法”に掲載したが、ヒアリング先である企業、団体、個人の宣伝とはならないように、できるだけ、
企業、団体、個人名などを削除できるようにし、ヒアリング先に了解を得た。

３.１.６. 「CRYPTREC暗号技術ガイドライン（軽量暗号）」更新に関わる活動
３.１.６.１. 背景
2019年度に設置された量子コンピュータ時代に向けた暗号の在り方検討タスクフォースにて、「CRYPTRECにおいて、軽量暗号はCRYPTREC暗号リストには組み込まず、別途ガイドラインという形で取り扱う」ことが決定され、2020年度第2回暗号技術検討会にて、2016年度に作成した「CRYPTREC
暗号技術ガイドライン（軽量暗号）」（以下、「2016年度版ガイドライン」という）を2023年度中を目処に更新することが承認された。2021年度第2回暗号技術評価委員会においてその更新方針が承認された。
当該更新方針に従い、今年度は、NIST軽量暗号プロジェクト（NIST Lightweight Cryptography
Project . 以下、「NIST LWC」という）のファイナリスト10方式（ASCON, Elephant, GIFT-COFB,
Grain-128AEAD, ISAP, PHOTON-Beetle, Romulus, SPARKLE, TinyJAMBU, Xoodyak）を対象とした安全性評価及び実装性能評価を外部評価により実施した。なお、安全性評価に関しては、これら10方式に加え、ISO/IEC標準規格として 29192シリーズで規格化されている軽量メッセージ認証コードの1つであるTsudik's keymodeも対象としていた。また、軽量暗号に関わる NIST公開文書やISO/IECなどの標準化動向に関わる調査を外部評価により実施した。その外部評価実施内容を報告する。
なお、2023年2月7日に、NIST LWC 最終選考結果が発表され ASCON が選ばれた。
３.１.６.２. 実施概要
安全性評価、実装性能評価、標準化動向調査、それぞれについて外部評価により以下のとおり実
施した。
16

⚫

安全性評価：NIST LWCファイナリストに選定された10方式とISO/IEC標準規格として承認されたTsudik's keymode の安全性に関する調査及び評価を実施した。

⚫

実装性能評価：NIST LWCファイナリストに選定された10方式の実装性能（ハードウェア及びソフトウェア）に関する調査及び評価を実施した。

⚫

標準化動向調査：軽量暗号を取り巻く標準化動向(CAESAR プロジェクト、ISO/IECの軽量暗号関連カテゴリ、NIST LWCなど)の調査を実施した。

３.１.６.３. 調査結果概要[安全性評価結果概要]
NIST LWCファイナリストに選定された 10方式と ISO/IEC標準として規格化されたTsudik's
keymodeの安全性評価について、2022年9月現在における調査結果を次のとおり表にまとめた。
特定の場合を除き、安全性を脅かす攻撃が存在しない方式
ASCON,

Elephant,

GIFT-COFB,

安全性を脅かす方式が存在しない方式

Grain-

128AEAD, ISAP, PHOTON-Beetle, Romulus,

TinyJAMBU, Tsudik's keymode

SPARKLE, Xoodyak
TinyJAMBUでは、関連鍵設定の場合に現実的な計算量での偽造攻撃が実行可能である。本攻撃が成立するような関連鍵の使用を避けることでTinyJAMBUの安全性を確保できることを確認した。
Tsudik's keymodeでは、使用するハッシュ関数が伸長攻撃と呼ばれる攻撃を許す場合に偽造攻撃が実行可能となるという既知の脆弱性が存在する。伸長攻撃が実行不可能なハッシュ関数を使用することでTsudik's keymodeの安全性を確保できることを確認した。
[実装性能評価結果概要]
それぞれの方式に関する現時点での実装性能を確認した。
⚫

ハードウェア実装：回路面積とスループット性能に着目して評価した。例えば、Xilinx 社 のArtix-7 上では、TinyJAMBU の回路面積が小さいこと、SPARKLE は比較的面積コストが大きくなることなどを確認した。

⚫

ソフトウェア実装：レイテンシ、コードサイズ、RAMサイズなどに着目し評価した。例えば、低リソースプラットフォーム (Arm Cortex-M0)上では、Elephant が最もレイテンシが高く、TinyJAMBU、Xoodyak、ASCON、SPARKLE が低レイテンシであることが分かった。コートサイズは、ASCON が最も大きく、他の候補暗号方式には大きな差は見られなかった。RAM の使用量は、コンパイル時の静的なメモリサイズのレポートから、どのアルゴリズムも約 1kByte程度であった。

17

[標準化動向調査結果概要]
CAESAR プロジェクト、ISO/IECの軽量暗号関連カテゴリ、NIST LWC などの状況を調査し、まとめた。調査結果により、軽量暗号をとりまく現状を確認した。例えば、2016年度版ガイドラインに掲載されている SIMON と SPECK については、ISO/IECの軽量暗号のカテゴリで議論されていたが、結果として軽量暗号としてはISO/IEC標準規格として承認されず、自動認識・データキャプチャ技術に関する仕様で利用可能な軽量暗号方式として規格化されていることを確認した。
また、評価指標に関して、安全性評価については、提案方式の設計根拠が十分に提示されない場
合に第3者による評価が十分に行えないと判断され、評価対象から外されるなどの事例があった。
実装性能評価については、従来論文ごとに異なる環境や測定シナリオで示されることが多くあったが、近年は AES-GCM や SHA-256 など広く世界で利用されているアルゴリズムとの比較などにより統一的な測定フレームワークを用いて実施することが一般化されてきていることが分かった。
３.１.６.４. 外部評価報告書に対する暗号技術評価委員会の見解実施した外部評価報告書は、今年度に目的としていた調査対象の暗号方式に対して、安全性・実装性能・標準化動向の調査として十分な内容を含んでいると考えられることから、本報告書をCRYPTREC の技術調査報告書とすることが了承された。
３.１.６.５. 来年度の計画
2021 年度第 2 回暗号技術評価委員会において承認された更新方針に従い、暗号技術評価委員会
事務局によりガイドラインの更新案を編集し、ドラフト版について外部有識者にガイドラインとして掲載内容の適切性や情報の過不足などについてレビュー頂き、完成版を 2023 年度暗号技術評
価委員会で審議する予定である。

３.１.７. 暗号技術評価委員会の開催実績
2021年度、暗号技術評価委員会は計2回開催した。各回会合の概要は表3.2-5のとおりである。
表3.2-5 暗号技術評価委員会の開催状況
回

開催日

議案
◼

暗号技術評価委員会活動計画の具体的な進め方についての審
議

◼
第1回

2022年7月26日

暗号技術調査ワーキンググループ（耐量子計算機暗号）の活動計画案の審議◼

暗号技術調査ワーキンググループ（高機能暗号）の活動計画
案の審議◼

外部評価（軽量暗号に関するガイドライン係る技術動向調査）
実施についての審議18◼

監視状況報告◼

自主取下げに係る電子メールによる審議内容と結果の報告◼

暗号技術調査ワーキンググループ（耐量子計算機暗号）の活動内容の報告◼
第2回

2023月2月27日

暗号技術調査ワーキンググループ（高機能暗号）の活動内容の報告◼

軽量暗号ガイドラインに係る技術動向調査結果の報告◼

監視状況報告◼

CRYPTREC Report 2022作成について◼

CRYPTRECシンポジウム開催について

19

３.２. 暗号技術活用委員会
３.２.１. 活動の概要
2022年度の活動概要は以下の通りである。詳細については、CRYPTREC Report 2022暗号技術活用委員会報告3を参照されたい。
(1) 利用実績に関する評価
2022年度はCRYPTREC暗号リストの改定が予定されており、その際、推奨候補暗号リストから
電子政府推奨暗号リストへの昇格にあたって利用実績に基づいた選定が行われることが決まっている。
そこで、IPAが実施する「暗号アルゴリズムの利用実績に関する調査」による調査結果に基づき、2021年度に承認された利用実績による選定基準の下で利用実績に関する評価を行う。
(2) 暗号鍵管理ガイダンスの作成
暗号鍵管理ガイドラインの拡充を目的として、2021年度に取りまとめた作業の進め方に基づ
き、暗号鍵管理ガイダンスWGにて暗号鍵管理ガイダンスを作成する。
(3) 暗号利活用のために作成すべきガイダンス候補の検討
暗号利活用のために作成すべきガイダンス候補を検討し、今後の執筆に向けた準備を行う。

３.２.２. 2022年度の活動内容
３.２.２.１. 利用実績に関する評価
IPAが実施した暗号アルゴリズム利用実績調査の結果、及び2021年度に承認された利用実績に基づく選定基準（選定ルール）（下表）に基づき、現在の推奨候補暗号リストに掲載のアルゴリズムの
うち、電子政府推奨暗号リスト掲載への推薦候補案について検討・選定し、暗号技術検討会に推薦した。
【検討方針】
IPAが実施した暗号アルゴリズム利用実績調査4では、現在の推奨候補暗号リストに掲載のアルゴ
リズムのうち、EdDSAのみアンケートによる利用実績調査の対象外であった。
このため、「EdDSA」以外の「推奨候補暗号リスト」に掲載の暗号アルゴリズムについては「利用実績調査（考慮項目①～⑥）」結果に基づいて判定し、「EdDSA」については「利用実態確認（考慮項
目②～⑤）」結果に基づいて判定することとした。

3
4

CRYPTREC Report 2022 暗号技術活用委員会報告, https://www.cryptrec.go.jp/promo_cmte.html
IPA、「暗号アルゴリズムの利用実績に関する調査報告書」の公開、https://www.ipa.go.jp/security/fy24/reports/cryptrec/cryptoalgorithm/crypt_usageper_report.html

20表

利用実績に基づく選定基準（選定ルール）

考慮項目

選定目安

採用実 以下のいずれかを満たす場合、昇格の検討対象績に含める。なお、採用実績は、⚫ 5 年ごとに実施予定の大規模アンケート調

査による「利用実績調査」⚫ 必要に応じて、事務局が（大規模アンケート

調査によらずに）情報収集する「利用実態確認」
により確認するものとする。
① 利用実績調査の結果、電子政府推奨暗号リ 電子政府推奨暗号リスト掲載の（同一
ストに掲載されている（同一カテゴリの）暗 カテゴリの）暗号技術の採用実績を同号技術の採用実績と遜色がないことが確認 等以上の採用実績がある推奨候補暗された場合

号リスト掲載の暗号技術を昇格検討対象とする。

② 利用実績調査又は利用実態確認の結果、電 必要に応じて、利用実績調査に代わっ子政府システムや重要インフラ等、日本の て、各府省庁等への照会を実施し、照基幹システムにおいてすでに利用されてい 会結果（クローズドな利用を含め）をることが確認された場合基に昇格検討対象を選定する。

利用実績調査又は利用実態確認の結果、③～⑤ 「複数」「利用者が多い（主要な）」のいずれかが確認された場合：というキーワードの両方を十分に満③ 利用者が多い主要な汎用製品群の複数に搭 たし、明らかな採用促進が確認された
載されるなど、明らかに採用が進展してい 場合には、必要に応じて、昇格検討対ると判断された場合象とする。

④ 利用者が多い主要なオープンソースソフト ※「複数」の意味は、必要条件としてウェアの複数に搭載されるなど、明らかに 「2個以上が必要」ということであっ採用が進展していると判断された場合て、「2個以上あればよい」という十

⑤ 利用者が多い主要なサービスやプロトコル 分条件としての意味ではないことにの複数で利用されるなど、明らかに採用が 留意
進展していると判断された場合標準化 以下を満たす場合、昇格の検討対象に含める。
実績⑥ 利用実績調査の結果、電子政府推奨暗号リ 電子政府推奨暗号リスト掲載の（同一
ストに掲載されている（同一カテゴリの）暗 カテゴリの）暗号技術の採用実績を同号技術の採用実績と遜色がないことが確認 等以上の採用実績がある推奨候補暗された場合

号リスト掲載の暗号技術は昇格検討対象とする。
21

【電子政府推奨暗号リスト掲載への推薦候補案】⚫

エンティティ認証、ハッシュ関数、署名を除いた技術分類について：

技術分類

推薦候補

推薦しない候補理由

公 開 鍵 鍵共有

該当なし

PSEC-KEM⚫ 他の鍵共有と比較して優位な

暗号利用実績があるとは認められない

共 通 鍵 64 ビ ッ ト ブ 該当なし

CIPHERUNICORN-E⚫ 他の 64 ビットブロック暗号と暗号

Hierocrypt-L1

比較して優位な利用実績があMISTY1

るとは認められない

ロック暗号⚫ 他の 128 ビットブロック暗号

128ビットブ 該当なし

CIPHERUNICORN-A

ロック暗号

CLEFIA

と比較して優位な利用実績がHierocrypt-3

あるとは認められない

SC2000⚫ 他のストリーム暗号と比較しス ト リ ー ム 該当なし

Enocoro-128v2

暗号

MUGI

て優位な利用実績があるとは

MULTI-S01

認められない認証暗号

ChaCha20-

該当なし

Poly1305
暗 号 利 秘匿モード

XTS⚫ 考慮項目①②④について、利用実績があると認められる該当なし⚫ 考慮項目①②④について、他

用 モ ーの秘匿モードと比較して利用ド

実績があると認められるメッセージ認証コード

該当なし

PC-MAC-AES⚫ 他のメッセージ認証コードと比較して優位な利用実績があるとは認められない⚫

エンティティ認証について：

技術分類

推薦候補

推薦しない候補

理由

エンティティ認証

ISO/IEC 9798-

該当なし⚫ 考慮項目①②において、他のエ4ンティティ認証と比較して利用実績があると認められる⚫

ハッシュ関数について：

技術分類

推薦候補

推薦しない候補

理由

ハッシュ関数

SHA-512/256

該当なし⚫ 考慮項目④において、他のハ22

SHA3-256

ッシュ関数と比較して利用実

SHA3-384

績があると認められる

SHA3-512SHAKE128SHAKE256⚫

EdDSA について：

技術分類

推薦候補

推薦しない候補理由

公 開 鍵 署名

EdDSA

該当なし

⚫ 考慮項目④において、他の署暗号名と比較して利用実績があると認められる３.２.２.２. 自主取下げ申請への対応
富士通株式会社から取下げ申請があったSC2000について、審議の結果、暗号技術検討会でCRYPTREC暗号リストからの取下げルールを整備することを条件に、申請を了承することとした。
３.２.２.３. 暗号鍵管理ガイダンスの作成
暗号鍵管理検討の初めとして、暗号鍵管理が必要なシステムの設計者向けに、暗号鍵管理の設計で明記する事項や考慮する点などを解説することを目的としたガイダンスである。本ガイダンスの位置づけと想定読者は以下の通りとする。
位置づけ⚫

暗号鍵管理機能を持つシステム設計者のガイダンスを作成する。このガイダンスは 2020 年に発行した「暗号鍵管理システム設計指針（基本編）」を詳しく解説することを中心に作成
する⚫

暗号鍵管理で必要となる項目について、シンプルなモデルを例示し説明する⚫

シンプルなモデルを用いた説明においては、鍵管理における要求や思想が理解できるような記載を行う⚫

暗号鍵管理における特に注意すべきリスクを説明する

想定読者⚫

暗号鍵管理機能を持つシステム設計者

2022年度版暗号鍵ガイダンスの章構成は以下のとおりである。具体的には、本ガイダンスは「暗号鍵管理システム設計指針（基本編）」で記載が求められる項目について検討する際の有用な副読本となることを目的として書かれている。
23

1. はじめにイントロダクションとして、暗号鍵管理の重要性、及び本ガイダンスの位置づけについて説明している。
2. 暗号アルゴリズム運用のための暗号鍵管理オペレーション対策
暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用のための暗号鍵管理
オペレーション対策」における検討項目についての解説・考慮点を記載している。具体的には、CKMSにおいてどのように暗号鍵が管理されるかを対象にしており、暗号鍵の生成から廃棄までのライフサイクル全期間にわたって暗号鍵を管理するのに必要となる機能や運用方法を取り決める検討項目を取り扱っている。また、簡単なモデル（トイモデル）としてS/MIMEをモデルに取り上げ、記載例を示した。
3. 暗号アルゴリズムの選択
暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズムの選択」における検討項
目についての解説・考慮点を記載している。具体的には、暗号アルゴリズムや鍵長を選択に関する重要なポイントの解説、特にCRYPTREC暗号リスト（電子政府推奨暗号リスト）、暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準や暗号鍵設定ガイダンスを参考に選択することを推奨している。また、Webブラウザをクライアントとするクライアント－サーバシステムをモデルにした記載例を示した。
4. 暗号アルゴリズム運用に必要な鍵情報の管理
暗号鍵管理システム設計指針（基本編）での「暗号アルゴリズム運用に必要な鍵情報の管理」における検討項目についての解説・考慮点を記載している。ここでは、3章で決定した暗号アルゴリズムを運用するときに必要な鍵情報の管理の説明、具体的には管理すべき全ての鍵を明確にし、その鍵とメタデータの保護方法についての解説・考慮点を記載している。また、関係者がアクセス可能なWebサーバの鍵設定・管理をモデルにして記載例を示した。
３.２.２.４. 暗号利活用のために作成すべきガイダンス候補の検討
2023年度以降に作成すべきガイドライン／ガイダンスの候補について、以下の視点を踏まえ、検討を行った。今回の議論を踏まえ、どのガイドライン／ガイダンスを作成するかを2023年度活動計
画に反映することを決定した。
検討にあたっての視点⚫

どのようなガイドライン／ガイダンスが求められているか⚫

CRYPTREC がメインで作るのがよいか、それとも他の組織（IPA、業界団体など）がメイン
で／共同で作るのがよいか⚫

暗号技術の切り口メインで有用なガイドライン／ガイダンスになるか（暗号以外の部分がメインになったりしないか）

24

候補に挙がったガイドライン／ガイダンスのテーマ
1

認証についてのガイダンス（特に二要素認証）

2

身元（本人）確認のためのガイダンス（例えばeKYC）

3

電子メールに関するガイドライン／ガイダンス4

クラウドにおける鍵管理ガイダンス

5

組込機器の開発における、暗号プロトコル（例：認証プロトコル）のパラメータ選定基準

6

経営層も含めた人達を対象にした、暗号技術の啓発ドキュメント

7

暗号の使い方に関するガイドライン（ガイダンス）

8

PKIガイドライン（ガイダンス）

9

暗号化消去

10 DNSの暗号に関わるガイドライン（ガイダンス）
11 暗号資産12 eシール
13 APIに関するガイドライン／ガイダンス
14 高機能暗号の標準化
15 耐量子計算機暗号のガイダンス
16 耐量子計算機暗号への移行に関するガイダンス
17 FIDOなどの普及促進を促すガイダンス
18 リモート署名などの普及促進を促すガイダンス
19 暗号化消去などの普及促進を促すガイダンス
20 TLS暗号設定ガイドラインのアップデート
21 運用ガイドラインやガイダンスに求められるニーズ／課題の整理

３.２.３. 暗号技術活用委員会の開催状況
2022年度の暗号技術活用委員会での審議概要は表の通りである。
表
回

メール

開催日

2022年7月7日～ 7月15日

暗号技術活用委員会の開催状況

議案⚫ 2022 年度暗号鍵管理ガイダンス WG 活動計画について25

⚫ 2022 年度暗号技術活用委員会活動計画について⚫ 暗号アルゴリズム利用実績調査の中間報告について

第一回⚫ 2022 年度暗号鍵管理ガイダンス WG 活動計画について

2022年8月4日⚫ 暗号鍵管理ガイダンス WG 進捗報告について⚫ 運用ガイドライン／ガイダンス候補について⚫ 暗号アルゴリズム利用実績調査の最終報告について

第二回

2022年12月20日⚫ 電子政府推奨暗号リスト掲載への推薦候補案について⚫ 暗号鍵管理ガイダンス WG 進捗報告について⚫ 運用ガイドライン／ガイダンス候補について⚫ 暗号鍵管理ガイダンス WG 活動報告

第三回

⚫ 運用ガイドライン／ガイダンス候補について

2023年3月14日⚫ 2022 年度暗号技術活用委員会活動報告案について

４. 今後のCRYPTRECの活動について
CRYPTRECでは、暗号アルゴリズムの安全性確保やその利活用に係る議論のみならず、鍵管理の安全な運用に向けた取組など、暗号をとりまく環境変化に応じた新たなニーズへの対応などに取り組むこととしている。2023年度もCRYPTREC暗号リストの改定を必要に応じて行うべく、その改定に向けた検討を進めていく。
暗号技術評価委員会においては、耐量子計算機暗号ガイドラインが完成したところであるが、NISTのPQC標準化において第4ラウンドが進行中であることから、引き続き耐量子計算機暗号に関する最新動向を把握する必要がある。また、現在、軽量暗号に関するガイドラインの更新に向けた検討中であり、次年度完成させる予定である。暗号技術活用委員会においては、2022年度版暗号鍵管理ガイダンスを完成させたところであるが、「暗号鍵管理システム設計指針（基本編）」に記載がありながら今回解説・考慮点の記載を見送った部分の拡充を行う。また、TLS暗号設定ガイ
ドラインのアップデートを実施するとともに、2022年度活用委員会での議論を踏まえ、暗号利活用に向けた新たな有用なガイダンス作成に着手する予定である。
暗号技術検討会
座長：松本 勉 横浜国立大学教授（事務局：デジタル庁、総務省、経済産業省）

量子コンピュータ時代に向けた暗号の在り方検討タスクフォース

暗号技術評価委員会

暗号技術活用委員会

委員長：高木 剛 東京大学教授（事務局：NICT、IPA）

委員長：松本 勉 横浜国立大学教授（事務局：IPA、NICT）

暗号鍵管理
ガイダンスWG

暗号技術調査WG（耐量子計算機暗号）

図4-1 2023年度CRYPTRECの体制図（予定）26