はじめに
ドキュメントの内容を確認したいだけだったので、各プロセスの定数の説明は全てスキップしました。
元のドキュメントを最後に置きますので、確認したい方はそちらをどうぞ。

1 はじめに

1.1 技術ガイドラインの主題と目的

本技術指針（Technische Richtlinie, TR）の対象は、中央銀行デジタル通貨（CBDC）である。
CBDC は、公的機関（例：中央銀行）によって発行・管理される電子的な貨幣である。
中央銀行など）によって現金と同じように発行・管理される電子マネーである。
いわゆる「暗号通貨」と間違えられることはない。
.
CBDC は現金のすべての特徴を置き換えることはできませんが、以下のような場合には、現金 を補完することができます。
CBDCは、現金のすべての特徴を置き換えることはできませんが、追加的な機能を提供し、さらなるユースケースを促進するような場所では、補完することができます。
付録 A「CBDC と現金の比較」は、CBDC と現金の比較を示しています。
本報告書の目的は、CBDC が現金の利点を可能な限り発揮できるよう、IT セキュリティの基礎を固めることです。
CBDCを導入する可能性を残しつつ、現金の利点をできるだけ忠実に示すための IT セキュリティの基礎を築くことである。
本 TR の目的は、CBDC エコシステムの運用を支援するバックエンドシステムの高水準の IT セキュリティを確保するための要件を記述することである。
CBDC のエコシステムは、中央銀行が運用するバックエンドシステム、ウォレットプロバイダーがエンドユーザーに提供するフロントエンド機能、交換ポイントから構成される。
プロバイダー、中央銀行以外の第三者によって運営される可能性のある交換ポイント、そして潜在的に追加的なサービスプロバイダーから構成されます。
潜在的には、その他のサービスプロバイダーも含まれます。
実施された場合、CBDC のエコシステムは重要なインフラストラクチャを構成します。
このTRは、CBDCエコシステムが様々な攻撃に耐えられることを保証します。
さらにセキュリティー・バイ・デザイン（Security-by-Design）の目標の実施に加えて、本 TR はプライバシーの側面も考慮します。

1.2 テクニカルガイドラインの範囲

本ガイドラインは、CBDC のエコシステムの異なる構成要素及びプロセスをカバーする 2 つの部分から構成される。
本書は本 TR の第 1 部を構成し、CBDC のエコシステムを支援するために中央銀行が運用するバックエンドシステムに焦点を当てる。
要求事項が作成されているプロセスは、以下のものをカバーしています。
この用語の詳細については、2.2.4.2「トークン・ベースのアプローチと口座ベースのアプローチ」を参照されたい。
(「アカウント・ベースのアプローチ」を参照）。
いくつかのプロセス、特に支払いは、強くユーザー主導で行われます。
対応する要件は、TR Frontend [1]に記載されている。
TRの2つの部分のより詳細な区別は，2.1「ライフサイクル，実体及び構成要素」に記載されている。

本 TR のこの部分の範囲は、CBDC バックエンドのコアシステムに限定され、コアシステムの上に構築 される追加機能（2.2.2「高次機能」参照）については考慮しない。
コアシステムの上に構築された追加機能（2.2.2「高次機能」参照）は考慮しない。
さらに暗号通貨は、公的機関によって発行・管理されていないため、本 TR の対象外とする。
さらにまた，本 TR には，データ保護要件に関する網羅的な取り扱いは含まれておらず、本 TR への準拠は、必ずしも一般データ保護規則（GDPR）[2]への準拠を意味するものではない。
同様に、本 TR には、KYC（Know Your Customer）及びマネーロンダリング防止（Anti-Money Laundering）規制への言及がいくつか含まれている。
(AML）規制への言及があるが、その旨の明示的な規定は本 TR の適用範囲ではない。

1.3 技術指針の概要

本 TR の本編の構成は以下の通りである：「2.1 ライフサイクル、エンティティ及びコンポーネント」では、CBDC ライフサイクルの一般的な設計アプローチを紹介する。
2.2 「一般的な考慮事項」では、特に IT セキュリティに関して、特定の設計上の選択（2.2.4 「技術的な設計上の選択」を参照）の意味など、様々な包括的なトピックについて議論する。
2.3 「高レベルのセキュリティ分析」では、高レベルの観点からのセキュリティ分析を行う。

実際の要件は、3.Requirements に含まれ、3 つのカテゴリーに分類されます（図 1 参照）。
まず、CBDC のライフサイクルに沿った一般的な CBDC の機能を支える様々なプロセスに関する要件は、3.1「機能的要件」に記載されています。
これらを補完するのが包括的な要求事項です。
これらの要件は、3.2「取引に関連するセキュリティ要件」に記載されています。
3.3 「一般的なセキュリティ要件」には、CBDC のバックエンド機能を実現するために必要 な IT システム及びそれを支える連邦情報セキュリティ局（Federal Office for Information Security）のプロセスの高水準のセキュリティを確保するための要件が含まれています。
これらの要件は、ライフサイクルのどのプロセスにも特化したものではなく、一般的なものである。
特に、本セクションでは情報セキュリティマネジメントシステムなどの組織的対策に関する要求事項、暗号化、要員、IT システム、物理的セキュリティなどの資源・設備に関する要求事項、及び運用に関する要求事項を提供します。
物理的セキュリティ、運用ワークフローに関する要求事項などである。

すべてのセクションにおいて、本報告書は3段階のアプローチを採用している。
このアプローチは、まず、果たすべき一般的な目的を設定し、当該プロセスの次に、その目的に対処し、脅威を緩和するためのより具体的な要求事項を提示する。
次に、目的に対処し、脅威を緩和するために、より具体的な要求事項を提示する。
根拠目的、脅威、要求事項のマッチングを提供する理論的根拠には、次のような目的がある。
→要求事項の完全性と妥当性を保証する目的
"Off "という接尾辞の付いた要件は、オフラインの機能を含む CBDC システムにのみ適用されます。
技術的特性と具体的なアクションに関する CBDC と現金の比較は以下の通りです。
付録 A「CBDC と現金の比較」。

1.4 用語

このテクニカルガイドラインでは、要求事項がどの程度強制的であるかを区別するために、表 2 に定義したモーダル動詞を使用する。

本テクニカルガイドラインでは、表2に定義されたモーダル動詞を用いて、要求事項の強制の程度を区別するために使用する。

モーダル動詞 →説明
・SHALL →この語は、その実装が絶対的な要求事項であることを意味する。
・SHALL NOT →この語は、実装が絶対的な禁止事項であることを意味する。
・SHOULD →この語は、実装が絶対要件であることを意味する。技術的な制約のために、実装が現在実行不可能である。
・SHOULD NOT →この語句は、実装が絶対的な禁止事項であることを意味する。
この文言は、実施することで安全な運用にリスクがないことが実証されない限り、または、技術的な制約のために、禁止された実施方法の防止が現在実行不可能である。
・MAY →この語は、実施が任意であることを意味する。

2 セキュリティ要件の概要

2.1 ライフサイクル、エンティティ及び構成要素

CBDC ノートのライフサイクルは様々な段階から構成されます。
ライフサイクル全体を通して、異なる技術コンポーネントが使用されます。
原則的に、ライフサイクルが考えられます。
詳細な議論については、2.2.4「技術的設計の選択」を参照されたい。

01 作成　発行元がCBDC貨幣を作成
02 流通　CBDC貨幣が交換ポイントに配布される
03 交換　利用者はCDBC貨幣を他の貨幣と交換する（AMLとKYCの対象となる）
04 ストレージ 利用者がCBDC貨幣を財布に保管
05 支払　CBDC貨幣は支払いに使用される
06 妥当性チェック CDBC貨幣は、（オンラインであればいつでも、確認機関により）有効性チェックの対象となる。
07  更新 必要に応じて、発行者は利用者が適用できるように更新を提供する。
08 取り消し 失効権限によりCDBC貨幣が破棄される
09 リカバリー（オプション）失効権限によりCDBC貨幣が破棄される
→08と09は中央銀行が行うので、利用者の手持ちの貨幣を自由に無効化できる、ということですね

このテクニカルガイドラインは、以下に示す設計と実体のセットに基づいている。
この技術指針は、以下に示す設計とエンティティ群に基づいている。
必要なライフサイクルのフェーズに基づき、それぞれの機能を実行するための適切な役割を紹介している。

テクニカルガイドラインは、CBDC のライフサイクルにおける全ての重要なプロセスは、中央銀 行が管理・運営することを求めています。
はじめに、中央銀行によって一定の価値の CBDC 紙幣が作成されます（1）。
その後、CBDC 紙幣は一つまたは複数の交換ポイントに配布されます。
この作成と配布の2つのプロセスの発行は、中央銀行が管理・運営する発行体という公認団体によって行われます。
中央銀行によって管理・運営される。

利用者は両替所とやりとりをして、(3) CBDC 紙幣と他の形態の貨幣を交換することができます。
注)本 TR は、交換ポイントの正確な性質を規定するものではない。
例えば、商業銀行のような仲介業者によってホストされるかもしれませんし、民間企業によって提供されるトップアップ端末の形態をとるかもしれません。
同様に、仲介業者を介さない CBDC のライフサイクルが望まれるのであれば、中央銀行自体にあるサービスであってもよいでしょう。
両替所は中央銀行が管理・運営する必要はありません、
しかし、KYC 及び AML 規制に準拠する必要があります。
技術的なレベルでは、CBDC 紙幣を他の貨幣と交換することは、以下のように構成されます。
技術的なレベルでは、CBDC 紙幣と他の貨幣との交換は、CBDC の支払いとそれぞれの貨幣の取引から成り立ちます。

利用者は CBDC 紙幣を受け取ると、それをハードウェア部品に保存(4)します。これらのコンポーネント（対応するファームウェアまたはソフトウェアを含む）をウォレットと呼びます。
ウォレットはハードウェアトークン（例えば
スマートカードなど）、コンシューマ・デバイス（スマートフォンなど）上で実行されるもの、あるいは他のハードウェアやより大規模なITシステムに組み込まれ、付加的な機能を発揮するもの（例．
システム（POS端末など）に組み込まれることもある。ウォレットの実装は様々である。
ウォレットは、異なる機能性とセキュリティレベルを満たすために、異なる実装が使用される可能性がある。
ウォレットは以下の支払いを可能にします。

流通(2)、交換(3)および支払い(5)は、取引、すなわち、ある価値があるユーザーから別のユーザーに一定の価値が移転されるプロセスです。
これらすべての取引において、関係する CBDC貨幣の有効性は、確認機関である中央銀行が運営・管理するバックグラウンド・システム によってチェックされ、確認されます（6）。
確認機関によって運営・管理されます。
CBDC ソリューションがオフライン取引のための機能を含んでいる場合、適切な状況下 でこのオンライン有効性チェックを省略することも可能です。
オフライン決済を可能にするために、適切な状況下でこのオンライン有効性チェッ クを省略することも可能です。
その場合は、ローカルに保存された情報を使用したオフライン有効性チェッ クに置き換えられます。
ただし、このようなオフライン決済に関する特定の情報は記録され、最終的にはオンライン有効性チェックを受けなければならない。

CBDC貨幣は、技術的進歩、特に基礎となる暗号アルゴリズムに関する進歩を考慮し、更新することができる(7)。
更新は発行者によって行われ、利用者によって適用される。
アップデートは発行者によって提供され、利用者によって適用されます。
ただし、このような更新は、発行者の権限に属さないため、大きな設計変更を実施することはでき ません。

中央銀行は、例えば通貨管理の手段として、(8) CBDC 紙幣を失効させることができる。
CBDC貨幣の失効は中央銀行が管理・運営する失効当局という権限のある機関によって行われます。
中央銀行が管理・運営します。

オプション機能として、紛失したりアクセスできなくなったりした CBDC貨幣を復元することができます。
回収は中央銀行が管理・運営する機関によって行われます。

図 2 に CBDC のライフサイクルの概要と関係主体を示します。

このテクニカルガイドラインのパートでは、中央銀行が管理・運営するバックエンドシステムについて検討する。
発行(1 )及び 流通(2)、確認(6)、更新の提供(7)、失効(8)および回復(9)の可能性をサポートし、交換(3)および決済(5)の側面に関する要件も含んでいる。
それと決済(5)に関する要件が含まれており、これらは中央銀行の責任となる。
対照的に、TRフロントエンド[1]は以下をカバーしている。→ユーザー側の保管(4)、支払い(5)、更新の適用(7)のプロセス
ウォレットとウォレットプロバイダーに対する要求事項を設定する。

2.2 留意すべき事項

2.2.1 責任の委譲
3つの「要件」に定められた要件の責任者を割り当てる場合、この技術ガイドラインでは、「中央銀行」という用語を使用して、ITセキュリティに対する最終的な責任を明確にしています。
CBDCシステムは、対応する中央銀行にあります。それにもかかわらず、実際には中央銀行は、その責任の一部または全部を他の支援機関に委任する可能性があると予想する。
ITインフラを運用し、中央銀行の指示を受ける。
明確な法的および組織的プロセスは、支援事業体が委任されたすべての要件を満たしていることを保証するために必要になります。
しかし、そのようなプロセスは、この技術ガイドラインの範囲外です。

2.2.2 高レベルの機能
本書に含まれる要件は、CBDC のバックエンドのコアシステムに関するものです。
技術的なバックボーンを提供します。
実際に実装される際には、CBDCエコシステムは更なる機能を含み、追加アプリケーション層としてコアシステムの上に構築された更なるサービスを提供することができます。
追加アプリケーション層としてコアシステムの上に構築された更なるサービスを提供することができます。
例えば、あらかじめ定義された条件が満たされたときに自動的にトリガーしたり（しばしばプログラマビリティと呼ばれます）、あるいは、以下のような場合に支払いを禁止したりするサポートが含まれます。
特定の目的のためだけに発行されたウォレットが、その許可された範囲外で使用された場合の支払いの禁止、およびエンドユーザーに提供されるカストディサービスなどが含まれる。

以下に列挙する技術的要件は、コア・システムのセキュリティを確保するという目的に限定されている。
そのセキュリティを確保し、その結果、潜在的なより高度なサービスのための信頼できる基盤を提供するという目的に限定される。
特に、本文書は、コア・セキュリティ要件に直接抵触しない限り、より高度なサービスを排除するものではない。
特定の上位サービスが、他の考慮事項により所轄の規制当局によって制限または排除される可能性があろうがなかろうが、本書はそのようなサービスを排除しない。
それによって制限されるか、または除外されるかどうかは、本文書の範囲外である。

2.2.3 暗号アジリティ
具体的な実装の如何に関わらず、CBDC システムは全てのプロセスの IT セキュリティを確保するために暗号プロトコルとアルゴリズムを多用します。
特に、CBDC 貨幣自体は、その完全性と真正性を保護するために暗号化アルゴリズムを使用します。
偽札の使用を防止します。
特定の暗号プロトコルとアルゴリズムが攻撃に対して提供できるセキュリティのレベルは、静的なものではなく、時間とともに低下していく。
これは、計算能力の漸進的な向上、アルゴリズムや技術の改善、そして予期せぬセキュリティの向上によるものである。
また技術の向上、そして予期せぬセキュリティ侵害が原因である。
全体として、これは以下のような軍拡競争につながる。
伝統的な中央銀行の貨幣（つまり現物の現金）に存在するものと同様の軍拡競争につながる。
現物の現金には一定のセキュリティー機能があり、攻撃者はそれを複製して、発見されずに偽札を使うことができるようにしなければならない。
検知されずに偽札を使用できるようにするために、攻撃者はそれを複製しなければならない。
時が経つにつれて、攻撃者のスキルや設備は進化し、既存のセキュリティ機能を変更したり、新しい機能を追加したりする必要が出てくる。
それに対する望ましいセキュリティ・レベルを維持するためには、既存のセキュリティ機能を変更したり、新しい機能を追加したりしなければならなくなる。

同じ要件がCBDCノートにも発生し、セキュリティ保証が失われる前に暗号プロトコルとアルゴリズムを更新する必要がある。
セキュリティの更新は、パラメータの変更だけでなく、アルゴリズムやプロトコルをより高いセキュリティ保証を持つ別のものに置き換えることでも構成される。
このようなアップデートを効率的に実行するためのプロセスが必要である。
次のような予測が必要である。
アルゴリズムのセキュリティ保証が切れる正確な時期の予測は不可能である。
数年以上先まで見通すと、予測の不確実性は大きくなる。
セキュリティ・レベルの急激な悪化は、原理的には常に起こりうる。
このためセキュリティ・バイ・デザインの原則に従い、CBDC のバックエンドシステムには最初から更新プロセスが不可欠でなければなりません。
それは、CBDC が将来も安全に使用できることを保証するために、最初からバックエンドシステムに不可欠な部分となります。

2.2.4 技術的設計の選択
本節では、ライフサイクルのいくつかの重要な側面、関係する主体、構成要素についてコメントと説明を行う。
エンティティおよびコンポーネントに関するコメントを提供する。
特に、いくつかの箇所で基本的な設計上の選択をしなければならない。
これらの設計上の選択の多くは、次のようなトレードオフに関する一般的な決定である。
過度な監視と、AML や KYC を目的とした正当な監視機能とのトレードオフに関する一般的な決定となる。
不正や不祥事を軽減するための措置とのトレードオフに関する一般的な決定である。
このような決定は、極めてセンシティブなものである。
利用者が CBDC に寄せる信頼の度合いに強く影響します。
さらに、これらの決定はシステムの IT セキュリティに直接影響を与えるものではありません。
それを管理する能力に影響を与えるかもしれません。
しかし、このような選択はシステムの設計に大きな影響を与えるため、最初から考慮しなければならない。
このため、本セクションでは、それぞれの問題点とトレードオフについて説明し、技術的なレベルでいくつかの代替案を提示する。
ただし、セキュリティーが強く懸念される場合は例外であり、設計上の選択を強制するものではありません。
そのような選択はすべて、管轄する当事者、とりわけ、以下のような既存の法律への適合を保証しなければならない立法者に委ねられている。
GDPR[2]のような既存の法律への適合性を確保しなければならず、さらに、以下のような選択も行わなければならない。
さらに、影響を受けるすべての関係者の正当な利益と、利用者の CBDC に対する信頼に対する影響を考慮した上で、このような選択をしなければなりません。

2.2.4.1 支払いとウォレットの匿名性
最初のトレードオフは、個人ユーザーが保有する支払いとウォレットに関連する匿名性のレベルに関するものです。
既存の中央銀行の貨幣としての現金の特徴の1つは、それがユーザーに提供するほぼ完全な匿名性です。これは、現金と既存のほとんどの電子決済との最大の違いの1つでもあります
原則として、すべての支払いを完全に可視化するソリューション。
ユーザーが完全な監視を受けることなく支払いを実行する正当な利益。
同様に、次のことは明らかです。
完全匿名CBDCは、既存のKYC規則やAML規制に抵触し、悪用される可能性があります
違法な目的によるものとして。

このジレンマに対処するための一般的なアプローチの1つは、異なるタイプのウォレットを使用することです。
必要な個人情報の量によっては、ウォレットは
一定の制限(例えば、保管されている金額、1回あたりの支払い回数など)の対象となる支払い(それを行う
日、取引ごとまたは日ごとの金額)、またはそのような制限なし(一般的なものを除く)の機能をつける。
中央銀行がそれらを課すのに適していると判断した場合の制限です。
このアプローチは、(少なくとも)2つのウォレットの種類になります:個人情報を必要とせず、制限に直面している完全に匿名のウォレットと完全に追跡可能でありながら制限を受けないパーソナライズされたウォレット。

この技術ガイドラインは、TR Frontend [1] の 2 種類のウォレットの技術要件を列挙しています。
いずれにせよ、最終的な選択と技術的な実装は明確に文書化されなければならず、すべてのウォレットはトランザクションに参加できるように一意の識別子を持っている必要があります。
完全に匿名のウォレットの場合、これはトランザクションごとに変化する一時的なIDである可能性があります。

2.2.4.2 トークンベースのアプローチとアカウントベースのアプローチ
第二に、ウォレット内のCBDC貨幣を整理するには、2つの異なるアプローチがあります。
トークンベースのアプローチでは、各CBDC貨幣を、保管または転送可能な個別のトークンとして扱います。
古典的な紙幣に似ています。
一方、アカウントベースのアプローチでは、ウォレットはユーザーのアカウントの合計残高ですが、個々のCBDC貨幣はありません。
一方のアプローチを他方よりも優先しているという認識を与えないように、TRのこの部分では「アカウント」と「トークン」という用語を使用せず、代わりに「CBDC貨幣」と説明します。
つまり、「CBDC貨幣」とは、CBDCの一定量を表すデータを指します。
特に、アカウントベースのアプローチでは、アカウントは1つのCBDC貨幣として扱われ、その一部はトランザクションで使用され、すべての入ってくるCBDC貨幣が自動的に集約されます(3.2.1「CBDCノート全般」および3.2.4「CBDCノートの転送」を参照)。

口座を独自のCBDC貨幣として見ることは、特定の技術的側面では便利かもしれませんが、アカウントベースのアプローチとトークンベースのアプローチの間には、考慮しなければならない違いがあります。
通常、アカウントベースのアプローチには、AML規制とより簡単に互換性があると考えられているという利点があります:例えば、ユーザーの総残高を表すCBDC紙幣が一定額に達した場合、ウォレットはそれ以上の支払いの受け取りを拒否する可能性があり、ユーザーが保有できるCBDCの金額に制限が課せられます。
ただし、トークンベースのアプローチでは、ユーザーの総残高に関する明示的な情報はありません。
したがって、制限を適用するには、ウォレット側で、保管しているCBDC紙幣の総量に追いつくために、いくつかの追加措置が必要になります。

2.2.4.1「支払いの匿名性」に見られるように、ウォレットにはさまざまな程度の匿名性があります。
一方、CBDCのメモは、所有者に関する情報を明らかにすることは想定されていません。
トークンベースのアプローチでは、CBDC紙幣とウォレットの間には自然な違いがあるため、この一見すると矛盾な事は簡単に解決される可能性があります。
ただし、アカウントベースのアプローチを採用する実装では、トランザクションで個人情報が漏洩しないように、パーソナライズされた可能性のあるウォレットとそこに保存されているアカウントとの間の厳密な分離を維持するように注意する必要があります。

この分離はプライバシーを維持するために重要ですが、セキュリティ上の問題を引き起こします:支払いを認証し、二重支払いを避けるために、すべてのトランザクションと関連するCBDCノートは、バックグラウンドの有効性チェックに合格する必要があります(3.2.2「CBDCノートの有効性チェック」を参照)。
トークンベースのアプローチでは、この妥当性チェックは個々のCBDCノート自体に対して実行できます。
しかし、アカウントベースのアプローチでは、受け取ったすべてのCBDCノートが合計残高にマージされるため、さらなる取り決めがなければ、元のCBDCノートを追跡したり、その有効性の証明を保存したりすることができなくなります。
代わりに、このアプローチでは、トランザクションの有効性に対する信頼が、ウォレット所有者の正しい認証に対する信頼に置き換えられることがよくあります。
ただし、これは上記のプライバシーに関する考慮事項と矛盾するため、実装で解決する必要があります。
いずれにせよ、実装は、CBDCノートを合計残高にマージしても、オンライン接続が確立されるまでチェックを延期する必要がある場合でも、有効性チェックを実行するために必要な情報が破棄されないようにする必要があります。

2.2.4.3 CBDC 紙幣の失効
第 3 の問題は、CBDC 紙幣の失効プロセスに関するものです。
本 TR にいう失効とは、作成プロセスと対をなすものであり、CBDC 紙幣の最終的な無効化と物理的な破棄を意味します。
流通する CBDC 紙幣の価値を管理する手段として、失効は以下の特別な主体によってのみ 行われなければなりません。
上記のように、中央銀行が管理・運営する特別な組織である失効機関によってのみ実行されなければなりません。
それでもなお、CBDC紙幣を失効させる失効当局の権限はどこまで及ぶのかという疑問が残ります。
特に、適切な状況下において、裁判所の判決に基づき、失効当局は利用者の財布にある CBDC 紙幣を失効させることができると決定することができます。そのような機能を実装することは可能でしょう。
特定の CBDC 紙幣に対してこの機能をトリガーすると、その CBDC 紙幣を保管するウォレットが失効 。当局権限とのインターネット接続を確立した時点で有効となります。

しかし、このように機能を実装することは重大な結果をもたらすでしょう。
第一に、もし利用者が、自分の財布の中で所持している CBDC 紙幣がいつ失効するかわからないという恐怖を抱かなければならなくなれば、利用者の CBDC に対する信頼を強く損なうことになります。このような信頼の喪失を是正するためには、裁判所の判決にリンクさせるだけでは実質的な効果は得られないでしょう。
第二に、セキュリティの観点から、この実装に反対する説得力のある議論があります。もしこのような形で機能が実装されれば中央銀行が運営する失効機関は、巧妙な攻撃者の格好の標的となるだろう。
失効権限をコントロールすれば、無数のユーザーのウォレットから相当な額の資金を失効させることができる。
これは、少なくとも金融システムの部分的な崩壊を引き起こす可能性が高い。
失効権限が十分に保護されていれば、攻撃が成功する可能性は低いかもしれないが、不可能ではない。
セキュリティの観点からは、「デザインによるセキュリティ」の原則に反する、あまりにも大きなリスクである。

このため、本テクニカルガイドラインでは、失効処理機関は自らが所持する CBDC 紙幣のみを失効処理することができると定めています。
中央銀行が CBDC 紙幣の失効を希望する場合、これらの CBDC 紙幣が失効される前にまず失効当局に移管されることを確認しなければなりません。
必要であれば、法的措置（差し押さえ、差押えなど）をとって譲渡を強制しなければなりません。
CBDCシステム自体には、利用者の同意や通知なしに利用者からCBDC紙幣を没収する技術的手段はありません。

フロントエンド側では、中央銀行の要求に応じて、特定のウォレットを CBDC エコシステムへの参加からブロックし、そこに存在する CBDC 紙幣を凍結することができることに注意してください。
しかし、もしそのような機能が存在し、使用されていたとしても、ブロックされたウォレットに存在する CBDC 紙幣はこの方法で失効したり無効になったりすることはなく、その所有者も変わりません。

2.2.4.4 オフライン決済
第四に、オフライン決済をどの程度まで、どのような条件下で可能にするかを決定しなければならない。
セキュリティの観点からは、オフライン決済ではライフサイクルで説明したような包括的な有効性チェッ クができないため、決済が不正に操作されるリスクがやや高くなる。
このリスクは、強固な暗号プロトコルとアルゴリズム、および適切なハードウェア保護を使用することで、大幅に軽減することができる。
また、オフライン決済では AML 目的での監視ができない。
一方、オフライン決済の可能性は、即時決済を可能にすることで、システムの使いやすさと可用性を高める、
また、バックグラウンド・システムやインターネット接続に良性または悪性の障害が発生した場合でも、決済は実行される。
オフライン決済を可能にすることで、不測の事態が発生した場合にもフォールバックが可能になる。
問題点を軽減しつつメリットを享受する説得力のある方法は、オフライン決済を認めるが、一定の制限（例：金額、決済回数、時間）を設けることである。

本書では、オフライン決済を含まない CBDC システムをベースラインと考えます。
同時に、オフラインペイメント機能を含む CBDC システムが満たすべき追加的な要件も示しています。これらの要件は、各要件のセクションの末尾に記載されていて接尾辞が付されています。

2.2.4.5 更新メカニズム
第 5 の設計上の選択肢は、更新機能の実装に関するものです。
更新された CBDC 紙幣は、元の CBDC 紙幣と同じ要件に適合しなければなりません。
特に、発行者から発信されたものであることが検証可能でなければなりません。
これを実現する方法はいくつか考えられます：
一つの方法は、仕様の更新に従って発行者が新しく作成した CBDC 紙幣とレガシー CBDC 紙幣を交換するよう利用者に求めることです。
このような交換は、ユーザーと交換ポイントとの間の通常の交換取引として組織することができます。
ユーザーがレガシーCBDCノートを失効機関に配信する2番目のトランザクションにバインドされます。更新された CBDC 紙幣は他のすべての CBDC 紙幣と同じライフサイクルに従いますので、 同じ要件を満たすことになります。
しかし、このアプローチで重要な点は、プライバシーの保護です。
単純に考えれば、利用者は、同じ価値の交換を受ける権利を得る前に、CBDC 紙幣の価値を開示する必要があります。
プライバシーの観点からは、これは非常に望ましくありません。
従って、このアプローチを採用する実装は、更新処理においてユーザが更新を希望する CBDC 紙幣の情報が漏れないようにするための追加的な手段を実装しなければなりません。

別のアプローチでは、ウォレットにアップデートを担当させることができる。
すべてのウォレットは発行者から新しい仕様について知らされます。
その後、あるウォレットがレガシーCBDCノートを検出するたびに、そのウォレットはアップデートを適用することができます。
ほとんど、あるいは全くユーザが操作することなく更新を適用することができます。
CBDC 紙幣にアップデートを適用することは、発行者が先験的に関与せず、オンライン接続を必要としないことに注意してください。
しかし、この方法では、既存の CBDC 紙幣を変更する権限をウォレットに与える必要があります。
このような許可は、更新プロセス自体の悪意のある実装やバグによるものだけでなく、更なる攻撃への入り口を開く可能性があるため、CBDC システムに深刻なセキュリティリスクをもたらします。
このアプローチをとる実装は、更新プロセスを安全にカプセル化し、すべての変更が発行者の 更新仕様に適合していることを証明できなければなりません。
これは、CBDC バックグランドシステムの関与なしには達成できないことが予想され、オフライン・アップデート機能の一見した利点が否定されることになる。

2.2.4.6 復旧プロセス
最後に、紛失した CBDC貨幣のオプションの復元プロセスについて議論する必要があります。
このプロセスは、CBDC貨幣へのアクセスが不可逆的に失われた場合に、CBDC貨幣を復元するこ とを可能にします。
これは、保存されていたハードウェアが破壊された場合、対応する認証要素がないまま紛失または盗難された場合（発見者や窃盗犯がアクセスできない）、あるいは認証要素そのものが破壊された場合、回復不能なまでに紛失または盗難された場合です。
これは、物理的に破壊された現金を取り戻すことに相当し（現金が紛失または盗難されても、発見者や窃盗犯はそれを使用することができる）、したがって、現金と比較してCBDCの利点を提供することになる。
しかし、そのような機能を安全に実装できるかどうかは明らかではありません。
明らかに、それぞれの CBDC 紙幣へのアクセスが実際に失われ、その回復を要求するユーザーがその正当な所有者であることを確認する必要があります。
これは原理的には実現可能かもしれませんが、おそらく全ての決済フローを強力に監視し、そのデータを保持する必要があり、（一部の）取引に対する匿名性の要求と相反し、完全にパーソナライズされたウォ レットでのみ可能です。
本テクニカルガイドラインでは、リカバリープロセスを利用できるかどうかについては決定していない。
しかし、そのようなプロセスを含めることを決定した場合、3.1.7 「リカバリ（OPTIONAL）」に規定される要件を満たさなければならない。

2.3 ハイレベルのセキュリティ分析

CBDC システムのセキュリティに関するこのハイレベルな分析は、2.1「ライフサイクル、エンティティ及びコンポーネント」で説明したライフサイクルに従います。
ライフサイクルの各プロセスは、セキュリティ要件が大きく異なる。
特に、セキュリティ目標の重要性、攻撃が成功した場合の結果、考慮すべき攻撃者のタイプに関係します。
以下の分析は、重要な側面の概要を提供し、一般的な状況についての直感を与えるにすぎない。
網羅的なリストとして理解されるものではありません。

CBDC貨幣が作成されるとき、その完全性と真正性はシステムにとって最も重要です。
もし敵対者によってこれらの性質が侵害されれば、個人的な利益のために大量の偽札を作成することが可能になります。
極端な例では、非常に大量の偽札が以下のような目的で使用される可能性がある。
地政学的緊張が高まっているときに、金融システムのかなりの部分を不安定化させるために使われるかもしれない。
その結果、特に暗号鍵を侵害することによって CBDC 紙幣の完全性や真正性を破壊する攻撃を阻止するために、強力な技術的・組織的対策が講じられなければなりません。
このような複雑な攻撃を仕掛けるには専門知識が必要であるため、国家的敵対者はこのプロセスに最も適した攻撃者である。

CBDC 紙幣が配布される場合、すべての通信相手の真正性を技術的・組織的対策によって確保しなけれ ばならない。
このプロセスで攻撃が成功すれば、攻撃者は大金を盗むことができるかもしれません。
攻撃者の能力を考慮する必要があるのは、国家的な敵対者と潜在的な組織犯罪です。
更新プロセスは、セキュリティの保証を失う CBDC 紙幣をより安全な代替物に置き換えることを可能にし、それ自体が重要なセキュリティ対策となります。
更新の真正性と完全性はシステムの基本です。
これを侵害することは、大規模な偽札の作成、あるいは意図的なセキュリティホールの導入とそれに続く他のプロセスへの攻撃を可能にします。
このプロセスには、国家レベルの敵対者や潜在的な組織犯罪が最も関係している。

2.2.4.3 「CBDC 紙幣の失効」で説明したように、CBDC 紙幣を無効にするためには失効権限が CBDC 紙幣を所有している必要があるという CBDC 紙幣の失効に関するシステム設計は、攻撃対象領域を強く制限します。
失効権限を破壊しても、不当な行為や通貨供給の変更は可能です。
これは、国民国家の敵対者が狙うかもしれません。しかし、さらなるプロセス（例えば支払い）が破壊されない限り、大規模な攻撃は不可能です。

交換取引では、相互作用する当事者の完全性と真正性が非常に重要である。
攻撃が成功すれば、おそらく相当な額の金銭を盗むことができる。
取引所取引は、マネーロンダリングを容易にするために、組織犯罪の興味深いターゲットになる可能性が高い。
利用者のプライバシーを守り、追跡を防ぐためには、取引に関する情報の機密性も重要である。

回収プロセス自体は任意である。
さらに、適切なレベルのプライバシーを保ちながら、すべてのセキュリティ要件を満たす方法で実施できるかどうかは不明である。
回収機関が提供するデータの完全性と信憑性は非常に重要である。
このプロセスを使用して回収できる金額が無制限である場合、回収権限を危うくすれば、多額の金銭を盗むことが可能になる。
紛失した CBDC 紙幣の回復を要求するユーザにとっても、完全性と真正性は同様に重要です。
攻撃が成功すれば、敵が一度も所持したことのない CBDC 紙幣を不正に回収することができます。

決済プロセスは、ユーザが CBDC のバックエンドシステムと直接やり取りする際に頻繁に使用す る唯一のプロセスです。
そのため、このプロセスの可用性は基本的なものであり、様々な状況において確保されなければなりません。
サービス拒否攻撃は、決済プロセスのスループットを低下させたり、停止させたりする可能性があ るため、考慮しなければならない。
オフライン決済機能の存在は、決済プロセスの可用性の重要度評価を下げるのに役立つ。
交換された情報の完全性と真正性も、決済データの機密性と同様に非常に重要である。
決済プロセスの完全性と真正性を攻撃されると、おそらく相当額の金銭が盗まれる可能性がある。
組織犯罪や軽犯罪者は、ソーシャル・エンジニアリングを利用してユーザーを騙し、意図しない支払いを確認させる可能性がある。
対策としては、ユーザーに簡潔な情報を表示することで、これを防ぐ必要がある。
決済プロセスを支える暗号プロトコルとアルゴリズムといった。
組織犯罪のような有能な敵対者は、（CBDC 紙幣をコピーして何度も使用する、つまり二重支出攻撃を行うことによって）多額の金銭を盗んだり作り出したりする可能性があるからです。
卑劣な犯罪者や不誠実な利用者は、オフライン機能を悪用し、制限を迂回して窃盗や資金洗浄を行おうとするかもしれません。

3 要求事項

3.1 機能的要件

3.1.1 主な目的
CBDC の主な目的は、現金のデジタル補完を利用者に提供することです。
従って、CBDC システムの適用範囲には、中央銀行が実行する追加的なバックグラウンドプロセス（CBDC 紙幣の作成、配布、更新、失効など）だけでなく、関連する全ての取引タイプ（支払い、CBDC 紙幣と他の形態の貨幣との交換など）を決済するための十分な機能を含まなけれ ばなりません。
中央銀行が実行する追加的なバックグラウンド処理（CBDC 紙幣の作成、配布、更新、失効など）を含みます。
システムの複雑さ、ひいては攻撃の可能性を最小化するために、これ以上の機能は避けるべきです。

例外として、CBDC 貨幣を紛失した場合やアクセス不能になった場合のオプションの復旧プロセスがあります。
本テクニカルガイドラインは、そのような回復プロセスを実施すべきか否かについて、何ら勧告を行うものではありません。
しかし、そのようなプロセスを導入することは、利用者の匿名性に深刻な影響を与える可能性が高いことに留意する必要があります、
また、既存の法律（CFR[3]第7条及び第8条等）との抵触が生じる可能性がある。
詳細については、3.1.7項「リカバリー（オプション）」を参照のこと。
.
コア機能の範囲について包括的な概観を提供するために、本節では例外的に CBDC システム全体、すなわちバックエンドとフロントエンドについて検討します。
異なる機能に対する明示的な要求事項は、CBDC バックエンドシステムに関するものであれば本書の後続の節で、そうでなければ TR Frontend [1]で扱います。

(3.1.1.1 オブジェクト→省略
3.1.1.2 悪影響→省略
3.1.1.3 要件→省略
3.1.1.4 根拠→省略)

3.1.2 創造
CBDC 紙幣の供給に関する主権は常に中央銀行にあります。
したがって、中央銀行は CBDC 紙幣の作成を管理し、実行する唯一の主体であり（3.1.4「失効」 も参照）、流通する CBDC 紙幣の全体的な価値を高めることにつながります。
取引の中で必要となる CBDC 紙幣の生成（3.2.4「CBDC 紙幣の譲渡」参照）は、流通する CBDC 紙幣の価値を一定に保つため、決して同等ではありません。

作成された CBDC 紙幣の累積価値は中央銀行が管理する情報であり、流通するCBDC 紙幣に関する洞察を可能にする可能性があるため、本 TR では先験的に機密情報として扱います。
注)これは、規制上の要件または経営上の決定により、この情報の開示が義務付けられる可能性を排除するものではありません。

(3.1.2.1 オブジェクト→省略
3.1.2.2 悪影響→省略
3.1.2.3 要件→省略
3.1.2.4 根拠→省略)

3.1.3 分配
セキュリティ上の理由から、発行者と利用者の直接のやり取りを禁止する役割分担を導入する。
その代わりに、新たに作成されたCBDC 紙幣は、まず流通取引によって専用の交換所に移され、流通に提供されます。
このプロセスを実行する簡単な方法は、CBDC紙幣を中央銀行から商業信用機関の交換ポイントに移すことです。
しかし、CBDC 紙幣を発行者から中央銀行の別の場所にある交換ポイントに内部譲渡することも、同様に選択肢となるでしょう。

技術的な観点からは、CBDC 紙幣の流通は決済取引と見なすことができます。
しかし、関係者の地位が高く、また譲渡された CBDC 紙幣の価値が大きい可能性があるため、 分配プロセスは、特に大規模なリソースを持つ高度に熟練した攻撃者による攻撃の標的になる可能性が高いです。
従って、セキュリティの観点からは、流通取引と通常の支払取引を別個に扱うことが合理的です。
特に、影響力の大きい攻撃を阻止するためには、関係する交換ポイントを十分なレベルで識別・認証することが最も重要である。
さらに、流通と支払を分離することで、匿名送金や（該当する場合）オフライン取引（3.1.8「支払」参照）のような支払取引に対して、より強力なデータ保護対策を実施することも可能である。

本セクションで定めるセキュリティ要件に加え、銀行法および規制は、流通プロセス、特に参加当事者の識別と認証、および取引の透明性に関して、さらなる要件を課すことができる。

(3.1.3.1 オブジェクト→省略
3.1.3.2 悪影響→省略
3.1.3.3 要件→省略
3.1.3.4 根拠→省略)

3.1.4 失効
CBDC 紙幣の流通を停止する場合はいつでも、その CBDC 紙幣を永久に無効にすることで失効処理を 開始することが失効処理機関の責任です。
失効処理機関への攻撃が成功した場合、失効された CBDC 紙幣が再び流通する可能性があります。
この脅威を軽減するために、失効局は決済機能をサポートしないものとします。
トランザクションを防止するために、失効権限では決済機能をサポートしてはならない（Purp.Req.5 参照）。
さらに、失効した CBDC 紙幣は合理的な時間内に物理的に破棄されなければならない。

2.2.4.3「CBDC 紙幣の失効」の議論に従い、ユーザーウォレットに存在する CBDC 紙幣は失効してはならない。
特に、操作ミスやウォレットに対する攻撃の結果、CBDC 紙幣が不注意に無効化されることを防がなければならない。
これらのリスクを軽減するために、CBDC 紙幣を失効させる前に失効機関に譲渡することが要求されます。
このような譲渡は、利用者の同意がなければ行うことができません。

失効は流通する CBDC 紙幣の供給に影響を及ぼすため、通貨供給の主務官庁である中央銀行の一部である失効当局は、失効処理を管理・実行する唯一の主体でなければならない。
失効した CBDC 紙幣に関する情報は、流通する CBDC 紙幣の価値全体を把握するために利用される可能性があるため、機微情報として扱われます（3.1.2「作成」も参照）。
この情報を開示すべきかどうかは、本 TR の範囲外です。

トランザクションの過程において、CBDC 紙幣はより高額なCBDC 紙幣を形成するために集約されることがあ ります（3.2.4「CBDC 紙幣の譲渡」参照）。
この場合、価値の小さい CBDC 紙幣は廃棄され、その総数は減少します。
このプロセスは、価値の小さい CBDC 紙幣を廃棄し、その総数を減らすことになりますが、本節で定義される失効プロセスと決して同等ではありません。
失効は CBDC 紙幣全体の価値を下げますが、破棄は価値を一定に保ちます。

フロントエンド側では、中央銀行の要求に応じて、特定のウォレットを CBDC エコシステムへの参加 からブロックすることができ、そのウォレットに存在する CBDC 紙幣は凍結されます（TR Frontend [1]を参照）。
しかし、そのような機能が実装され使用される場合、ブロックされたウォレットに存在する CBDC 紙幣はこのように失効したり無効になったりすることはなく、その所有者も変わりません。

(3.1.4.1 オブジェクト→省略
3.1.4.2 悪影響→省略
3.1.4.3 要件→省略
3.1.4.4 根拠→省略)

3.1.5 両替
両替とは、CBDC 紙幣を他の貨幣に両替するため、またはその逆の目的で、利用者と両替所との間で行われる取引です。
両替所は専門業者によって運営されています。
対照的に、利用者が他の個人利用者とCBDC 紙幣を交換する場合、この取引は交換に分類されず、支払いに分類されます（3.1.8「支払」参照）。

本セクションでは、主に CBDC 紙幣と同じ通貨を表す他の種類の貨幣との間の交換について考えます。
しかしながら、本セクションの要件は、ある通貨を表す CBDC 紙幣と異なる通貨を表す CBDC 紙幣または他の種類の貨幣との交換にも同様に適用することができます。
しかし、この場合、2 つの通貨システムをリンクさせるための追加的な措置が必要になる可能性が高いです。

交換ポイントの形態はさまざまである。
例えば、商業銀行のような仲介業者によってホストされる場合もあれば、民間企業によって提供されるトップアップ端末の形態をとる場合もあります。
同様に、仲介業者を介さない CBDC のライフサイクルを望むのであれば、中央銀行自体に設置されたサービスとすることもできます。

交換ポイントは攻撃の標的として狙われる可能性があるため、通常の決済トランザクションと比較して、交換ポイントに追加的な要件を課すことは合理的である。
しかし、交換ポイントの運営者は必ずしも CBDC のバックエンドシステムの一部ではないため（例えば、交換ポイントが商業銀行によって運営されている場合）、本文書では交換ポイントに対する具体的な要件は記載していません。
その代わり、取引所の運営者は、銀行部門における既存の IT セキュリティ及び AML 規制を遵守しなければなりません。
中央銀行が自ら交換所を運営することを選択しない限り、交換所に関する中央銀行の責任は、CBDC 紙幣を送金する機能を提供することによって交換を促進し、必要なバックエンドサービス、特に確認機関を運営し、交換所の信頼性を検証することに限定されます。
無効な CBDC 紙幣が交換に使用された場合、セキュリティ上の問題が生じます。
特に、オフライン取引が可能であり、オフラインシナリオで交換が行われる場合、この脅威は顕在化する可能性があります。
取引所では、CBDC 紙幣を他の種類の貨幣に交換することも、その逆も可能です。

最初のケースでは、攻撃者が交換ポイントを騙して無効な CBDC 紙幣、例えば既に使用された CBDC 紙幣を受け取らせることができれば、その見返りに CBDC のエコシステムの外部に 存在する金銭を受け取ることになり、バックエンドシステムによる検知 を逃れることができます。
確認機関は、CBDC 紙幣を他の種類の貨幣に交換する取引において、常にオンラインで有効性チェックを行うことを義務付けることで、そのような不正交換のリスクを軽減することができます。

第2の場合、利用者が他の種類の偽造紙幣を使用することは可能な攻撃であるが、これは本TR の範囲ではないため、両替所が適切な手段を用いて防止しなければならない。
利用者は、このシナリオでは、交換拠点から無効な CBDC 紙幣を受け取るリスクに直面する。
しかし、この攻撃は適切な組織的手段を用いて軽減することができる。
特に交換ポイントの信頼性を保証することです。
その結果、この場合、オンライン有効性チェックの要件は緩和される可能性があり、これはプロセスの可用性を向上させ、ひいてはエンドユーザーの金融包摂を促進することにもつながります。

利用者の識別と透明性に関する規制要件が適用される場合もあるが、第三者に対する利用者のプライバシーは常に保証されなければならない。

(3.1.5.1 オブジェクト→省略
3.1.5.2 悪影響→省略
3.1.5.3 要件→省略
3.1.5.4 根拠→省略)

3.1.6 更新
CBDC 貨幣は時間とともにセキュリティ保証を失います。
その理由は様々で、攻撃者の計算能力の漸増から、アルゴリズムや技術の改善、予期せぬセキュリティ侵害に及びます。
セキュリティ・インシデントを未然に防ぐため、中央銀行は使用されている暗号のセキュリティ保証を積極的に監視しなければなりません。
使用されている暗号プロトコル、アルゴリズム、パラメータのセキュリティ保証を積極的に監視し、必要な場合はいつでも、セキュリティアップデートをCBDC貨幣にできるだけ早く提供しなければなりません。

ユーザは自分の CBDC貨幣にアップデートを適用することができ、推奨されなければならない。
アップデートを適用するプロセスをどのようにモデル化するかは設計上の選択であり（2.2.4.5「アップデートのメカニズ ム」を参照）、以下のいずれかのことを意味します。
既存の CBDC 紙幣は新しい仕様に合わせてウォレットによって変換されるか、またはユーザは更新版と引き換えに CBDC 紙幣を中央銀行に返却することができます。

レガシー CBDC 紙幣と新 CBDC 紙幣の両方を取引に使用できるよう、適切な更新期間を定めなけれ ばなりません。
ただし、レガシー CBDC 紙幣が取引に使用できなくなる期限を設けなければなりません。
この措置は利用者に不便をもたらしますが、攻撃者が安全でないレガシー CBDC 紙幣を操作し、その後、更新メカニズムを使って有効な新紙幣と交換することを防ぐために必要です。
さらに、ウォレットプロバイダーは、たとえアップデートがそのセキュリティに影響を与えないとしても、レガシーCBDC紙幣を無期限にサポートすることは期待できません。
政治的な理由から、CBDC 紙幣が事実上無効となるだけでなく、事実上無効となる最終期限は、望ましくないか、あるいは現行法に違反する可能性があります。
この場合、前述の攻撃は CBDC システムの内部からは検知できないので、CBDC のバックエンドシステ ムの外部で、期限切れの CBDC 紙幣を利用者に補償するための組織的措置を講じることができます。
しかしセキュリティ上、重要な更新については、更新期間が終了した後に CBDC貨幣とその所有者の真正性を確実に検証することは不可能です。
したがって、このような補償の仕組みが悪用されるリスクは慎重に評価されなければなりません。

例えば、一般的な CBDC のプロセスにほとんど影響を与えないCBDC貨幣の仕様の小規模な変更や、一刻を争うセキュリティパッチなどを提供することがあります。
そのエンティティの集合とその責任を変更することを含む、主要な設計変更は、発行者が更新を提供する可能性があります。

CBDC のライフサイクルにおけるエンティティ及び責任の変更を含む大きな設計変更、又は 2.2.4 節「技術的な設計の選択」の議論に関連する設計変更は、裏付けが必要です。
その議論に関連するものは、政治的な決定に裏打ちされる必要があり、発行者の権限には属さない。
これらはすべて、その重要性と範囲に応じて、そして実施に要する労力に応じて、異なる扱いが必要である。
さらに、CBDC貨幣の現行バージョンとの互換性を確保するために、ウォレットや同様のインフラは
さらに、CBDC 紙幣の現行バージョンとの互換性を確保するために、中央銀行が CBDC 紙幣に対して実施するいかなる変更にもタイムリー に対応できなければなりません。
ウォレット・アプリケーションのバグ修正など、ウォレット・インフラストラクチャ全般に関するその 他の更新プロセスについては、TR Frontend [1]でより詳細に扱われています。

(3.1.6.1 オブジェクト→省略
3.1.6.2 悪影響→省略
3.1.6.3 要件→省略
3.1.6.4 根拠→省略)

3.1.7 回復（オプション）
オプションとして、CBDC バックエンドサービスは、ユーザが不可逆的にアクセスの可能性が失われ た CBDC メモを復元するためのプロセスを含むことができます。
これは、CBDC ノートが保存されていたハードウェアが破壊された場合、対応する認証要素を持たずに紛失または盗難された場合（そのため、潜在的な発見者や窃盗犯はアクセスできない）、あるいは認証要素自体が破壊、紛失または盗難された場合に起こり得ます。
破壊、紛失、盗難された認証要素を再発行するために、CBDC貨幣を再発行したり、部分的に破壊されたハードウェアに保存されている CBDC貨幣にアクセスしやすくするために、例えばハードウェアベンダ側で帯域外のプロセスが存在する場合があります。
しかし、このような場合でも、各 CBDC貨幣へのアクセスの可能性は取消不能に失われることはありませんし、回復プロセスの範囲には含まれません。
復旧プロセスでは、利用者は CBDC 紙幣の原本のコピーと同価値の代用品を入手することになります。

このような（任意の）プロセスが悪用されないようにするためには、CBDC 紙幣の回収を要求するユ ーザーが実際にその所有者であることを保証しなければなりません。
CBDC 紙幣にアクセスすることなく信頼できる所有者証明を提供できるのは、すべての支払いフローが相当程度監視され、回復手続きを実行する当事者がそれぞれのデータにアクセスできる場合のみです。このことは、また、（一部の）取引について匿名性を確保することと、効果的な回収プロセスを提供する事との間のトレードオフは考えにくいです。
別の問題は、（該当する場合）オフラインの支払いに関連して生じます。
そこでは、ユーザーがまだアクセス可能な CBDC 紙幣を回収することによって、その手続きが悪用される可能性があります。
その場合、元のコピーは、回復されたコピーの使用を妨げることなくオフラインの支払いに使用することができ、二重支出攻撃となります。
回復プロセスを含めるかどうかを決定する際には、これらの問題とその影響、特に利用者のプライバシ ーへの影響を十分に考慮しなければならない（2.2.4.6「回復プロセス」の議論も参照）。

(3.1.7.1 オブジェクト→省略
3.1.7.2 悪影響→省略
3.1.7.3 要件→省略
3.1.7.4 根拠→省略)

3.1.8 決済
様々なユースケースを通して広く使用され、高い実用性を持つために、CBDC の決済機能は全ての関連するデバイス間での決済をサポートしなければなりません。
本テクニカルガイドラインのこの部分については、全てのデバイスが適切な CBDC ウォレットを装備してい なければならないと仮定するだけで十分です。
デバイスとウォレットの相互運用性に必要な要件の詳細は、TR Frontend [1]に記載されています。

CBDC 紙幣をある事業体から別の事業体へ譲渡する場合は常に、偽造、盗難、操作された CBDC 紙幣の検出を目的とした有効性チェックを受けます。
たとえ CBDC ソリューションがオフライン決済の機能を提供していても、高水準のセキュリティを実現するために、このチェックには一般的に確認機関とのオンラインインタラクションが含 まれます（3.2.2「CBDC 紙幣の有効性チェック」及び 3.2.4 「CBDC 紙幣の譲渡」参照）。

他の取引タイプ（分配や交換など）とは対照的に、即時決済やオンライン接続を必要としない決済の需要があることが予想される。
オフライン決済の機能が存在する場合、実現可能なスループットやスケーラビリティに対する要件が課されるだけでなく、ローカルに保存された情報のみに基づいてオフラインで有効性をチェックする必要も生じる。
しかし、このようなオフライン決済、特に連続したオフライン決済は、二重使用攻撃の高いリスクをもたらす。
本テクニカルガイドラインでは、このリスクを軽減するための手段をいくつか紹介しており、 3.2.3 「二重支出」で取り扱っている。
特に、組織的な防御策として、オフライン取引は一定の最大数または金額に制限されることがある。

ユーザーに受け入れられるかどうかも、匿名での支払いが可能かどうかにかかっている。
この問題は、TR Frontend [1]で詳しく扱われている。

(3.1.8.1 オブジェクト→省略
3.1.8.2 悪影響→省略
3.1.8.3 要件→省略
3.1.8.4 根拠→省略)

3.2 取引関連のセキュリティ要件

3.2.1 CBDC 貨幣一般
CBDC 貨幣は、ある価値を持ち、ある所有者と暗号的に結合された情報の一部です。
CBDC 貨幣とその所有者との結びつきは、CBDC 貨幣を安全なハードウェア（例：セキュアエレメント） に保管し、暗号認証に成功した後でのみアクセスを許可することで達成することができます。
ただし、本テクニカルガイドラインは、同レベルのセキュリティを実現する他の実装方法を明確に排除するものではありません。
2.2.4.2「トークン・ベースのアプローチとアカウント・ベースのアプローチ」の記述を想起してください。
口座の合計か、取引中に他のウォレットに送金される口座の一部であると理解されます。
アカウントベースのアプローチにおける CBDC 紙幣は、文脈に応じて、ユーザのアカウントの合計か、取引中に他のウォレットに送金されるその一部であると理解されます。

(3.2.1.1 オブジェクト→省略
3.2.1.2 悪影響→省略
3.2.1.3 要件→省略
3.2.1.4 根拠→省略)

3.2.2 CBDC貨幣の有効性チェック
有効性チェックはトランザクションの正しさを保証し、攻撃を防ぐための基本的な要素です。
トランザクションが有効になる前に、受信側のウォレットは送信側のウォレットと CBDC ノートの有効性チェックを行います。
妥当性チェックはいくつかのサブルーチンで構成され、送信者のウォレットが真正でありブロックされていないこと、関係する CBDC貨幣が構文的に正しく真正であること、そのバージョンが現在サポートされていること、その所有者が取引を開始したこと、その CBDC 貨幣が改訂されていないこと、CBDC 紙幣が失効していないこと、CBDC 紙幣が過去に使用されていないこと、などを検証します。
失効していないことの証明は、3.1.4「失効」の要求事項で一般的にカバーされます。
この要件は、CBDC 紙幣が失効機関に譲渡された後、利用者が CBDC 紙幣又はそのコピーに再びアクセスすることを禁止しています。
しかし、失効プロセスの実装によっては、CBDC 貨幣自体または確認機関が、CBDC貨幣が無効にされたかどうかを証明する追加情報を保存することが考えられます。
有効性チェックは、該当する場合、そのような情報を含むべきです。

有効性チェックは、CBDC システムがオフライントランザクションのための機能を含んでいれば、オンラインバージョンとオフラインバージョンの両方で実行することができます。
オンラインの有効性チェックは確認機関に関連情報を問い合わせますが、オフラインの有効性チェック（該当する場合）は、ウォレットにローカルに保存され、ウォレットがオンライン接続を確立した時に更新される情報に基づきます。
ローカル情報に基づくこのようなチェックは、互換性や構文エラーなどのリスクを軽減するのには十分ですがウォレットを完全に制御している攻撃者には耐えられません。
したがって、オフラインの有効性チェックは、二重支出攻撃に対抗するために、適切なハードウェア対策によってサポートされなければならない（参照：3.2.3「二重支出」）。

その結果、オンライン有効性チェックはより高度なセキュリティを提供し、オフライン有効性チェックはインターネット接続が確立できない場合にオフライン決済を可能にする。

(3.2.2.1 オブジェクト→省略
3.2.2.2 悪影響→省略
3.2.2.3 要件→省略
3.2.2.4 根拠→省略)

3.2.3 二重支出

CBDC 紙幣の二重使用とは、同じ CBDC 紙幣を複数枚取引に使用し、その全てが有効性チェッ クに合格することを意味します。
これは、1 枚の CBDC 紙幣が不正に発見されることなく複数回使用されることを意味します。
二重支出を防ぐことが最も重要です。
なぜなら、二重支出を防ぐことは、攻撃者が自分の金融財産を増やすことを可能にするだけでなく、流通する貨幣の全体量を無秩序に変化させ、大規模に行われた場合には金融システムの不安定化につながるからです。

二重支出の検出と防止、すなわち CBDC 紙幣が既に使用されたかどうかをオンラインシナリオで実現するための様々なアプローチがあるかもしれませんが、それはオフライン決済のサポート（2.2.4.4 「オフライン決済」参照）とは容易に互換性がありません。
オフライン決済（2.2.4.4「オフライン決済」参照）との互換性はありません。攻撃者が自分のウォレットに CBDC 紙幣をコピーし、そのコピーを複数の独立したオフラインの支払いに使用した場合、それぞれの受信者は矛盾する取引に気付くことができず、不正行為を発見する可能性はありません。

本テクニカルガイドラインでは、オフライン決済をサポートするシステムにおける二重支出のリスクを軽減するための3段階の対策を紹介している：

第一に、ハードウェア的な対策の実施を規定することで、CBDC 紙幣のコピーの厳密な防止を目指す。

第二に、各 CBDC 紙幣は、それが派生し、オンライン取引に使用された最後の CBDC 紙幣を参照しなければなりません（3.2.1「CBDC 紙幣一般」参照）。
不正行為の可能性があります。
この要件により、第 1 層のハードウェア対策にセキュリティ違反があった場合に実行可能な可能性のある不正は、オンライン有効性検査でも検出される可能性があります。
例えば、攻撃者がオンライン取引で入手したCBDC 紙幣のコピーを複数作成することに成功したとします。
全てのコピーは同じ有効なオンラインの先祖を参照するため、検出されることなくオフライン取引で使用されるかもしれません。
オフラインの有効性チェックは、先祖への参照が互いに矛盾していることを検出することはできません。
しかし、コピーの1つがオンライン取引で使用されるとすぐに、確認機関に通知され、その先祖を使用済みとみなす。
他のコピーは、有効なオンライン先祖が欠けているため、オンライン有効性チェックを通過できなくなる。

第三に、連続したオフライン取引の回数を制限することは、CBDC 紙幣が第二層のオンライン有効性チェックを繰り返しすることを回避し、防止することが目的となります。

(3.2.3.1 オブジェクト→省略
3.2.3.2 悪影響→省略
3.2.3.3 要件→省略
3.2.3.4 根拠→省略)

3.2.4 CBDC 紙幣の譲渡
3.1「機能要件」で定義されたプロセスのうち、分配、交換及び支払は、ある主体から別の主体への CBDC 紙幣の譲渡を伴います。
本節では、これら全ての取引に適用される一般的な要求事項を取り扱います。

取引に関与する主体は、個人または企業ユーザー、信用機関、中央銀行だけでなく、適切な CBDC ウォレットを保有するその他の主体でもかまいません。全ての可能性をカバーするために、本節では「送り手」と「受け手」という一般的な用語を用います。トランザクションを実行するためには、送信者と受信者は何らかの ID で特定されなければなりません。IDはトランザクションの詳細にも表示され、送り手と受け手に必要な透明性を提供する。
IDはまた、意図された、あるいは確認されたトランザクションに関する必要な透明性を送り手と受け手に提供するために、トランザクションの詳細に表示される。
しかし、本セクションの要件では、IDが一時的であるか永続的であるか、あるいはユーザーの実名と関連付けられているかどうかは重要ではない。
さまざまなタイプのIDに関する議論については、TR Frontend [1]を参照のこと。

利用者は通常、CBDC 紙幣の価値と完全に一致しない金額の支払いを行います。
そのため、取引に必要な金額に合わせて CBDC 紙幣を分割する必要がある場合があります。
このような場合、送金側と受取側で CBDC 紙幣の総数が異なり、取引内で新たな CBDC 紙幣が生成される可能性があります。
同様に、価値の小さい CBDC 紙幣の多数でユーザの財布が一杯になるのを避けるため、取引に複数の CBDC 紙幣が含まれる場合、取引プロセスはそのような断片をより大きな CBDC 紙幣に自動的に再集約することがあります。
そうすると、価値の小さい CBDC 紙幣は、集約された CBDC 紙幣を優先して廃棄され、CBDC 紙幣の総数が減ります。
しかし、このようなCBDC貨幣の生成または廃棄は、3.1.2「生成」および3.1.4「失効」に従ったCBDC券の生成または失効に相当するものではありません。
CBDC 紙幣の生成または廃棄は、流通する CBDC 紙幣の総価値を変化させるものではなく、再分配に過ぎません。

CBDCのバックエンドシステムはほとんどの、あるいはすべての取引に関与しますが、要求事項の実装が少なくとも部分的にはウォレットの責任になることは明らかです。
特に取引がオフラインシナリオで実行される場合、CBDC バックエンドシステムは取引が決済される前に介入することができません。
この場合、関係するウォレットがセキュリティ要件が満たされていることを確認することが重要です。
特に困難な状況は中断の場合に発生し、全ての関係するウォレットが一貫した方法で部分的に実行された オフライン取引を復元する必要があります。
以下の要件は、ウォレットと CBDC バックエンドシステム間の信頼された協力によって実施される必要のある、トランザクショ ン固有の要件として理解されなければなりません。
これらはTR Frontend [1]に詳述されているウォレットとウォレットプロバイダの役割と責任に関する一般的な要件を補完するものです。

(3.2.4.1 オブジェクト→省略
3.2.4.2 悪影響→省略
3.2.4.3 要件→省略
3.2.4.4 根拠→省略)

3.2.5 失敗した有効性チェックの監視
Val.Req.12 により、ウォレットプロバイダーは、失敗した有効性チェックに関するログ情報の定期的な報告書を確認機関に提出することが要求される。
これは、ウォレットプロバイダがウォレットアプリケーションのセキュリティを維持する責任を免除するものではありませんが（TR Frontend [1]を参照）、CBDC システムの中で、確認機関がセキュリティに関連する活動を最も包括的に概観できる存在であることを意味します。
不審な行動や重大な失敗の増加は、その原因の精査の引き金となります。

CBDC 決済システムのセキュリティと堅牢性を保護するために、安全でない可能性のあるウォレットや悪意のあるユーザーをブロックする必要が生じることがあります。
ブロックは、検出されたセキュリティ上の脅威が緩和されるまでの一時的なものである場合もあれば、悪意のある行為者を対象とする場合は恒久的なものである場合もあります。
中央銀行は必要な措置を調整すべきであるが、特にウォレットがオフライン決済を無効にするよう求められたり、PKI 内で特定のウォレット証明書を失効させたりする場合は、通常、他のエンティティの協力が必要になることに注意すること。

セキュリティが最優先される一方で、中央銀行は CBDC 決済システムの利用を過度に制限しな いように注意する必要があります。

(3.2.5.1 オブジェクト→省略
3.2.5.2 悪影響→省略
3.2.5.3 要件→省略
3.2.5.4 根拠→省略)

3.3 一般的なセキュリティ要件

3.3.1 情報セキュリティ管理システム
中央銀行は、ISO/IEC 27001 [5]に従った情報セキュリティマネジメントシステム（ISMS）を導入しなければならない。
ISO/IEC 27001 [5]では、情報セキュリティは「情報の機密性、完全性、可用性の保持、情報の機密性、完全性及び可用性の保持」と定義されている；
加えて、「真正性、説明責任、否認防止、信頼性などの他の特性も含まれることがある」と定義されている。
さらに、ISMSは「ビジネスリスクアプローチに基づき、情報セキュリティを確立し、実施し、運用し、監視し、レビューし、維持し、改善するための全体的なマネジメントシステムの一部」と定義されている。

ISMSは、すべての一般的なセキュリティ要件を維持するために、その設計が十分に定義され、安全であることを要求し、支援し、実施について定期的にレビューを行うことを要求する。

例えば、3.3.8「信頼できる担当者」や3.3.9「ロギングと監視を支援する強固なITシステム及びネットワーク」）。
それにもかかわらず、より完全な全体像を示すために、本テクニカルガイドラインの各項目に含めているが、本項に従って ISMS を実施した後では、これらの要求事項を満たすために必要な追加的な労力は 限定的であることが予想される。
逆に、以下のセクションは、関連する要求事項をすべて含む ISMS の包括的な代用と考えるべきではない。
むしろ、IT-Grundschutz [6]の方法論のもと、標準やモジュールなどの追加文書を検討することが必要であろう。

以下のセクションでは、中央銀行にさまざまな責任を割り当てる。
ここでも、「中央銀行」という用語は、2.2.1「責任の委譲」という意味で理解されるべきであり、中央銀行に代わってITインフラの一部を運用するなど、支援事業体に特定のタスクを委任する選択肢が残されています。

(3.3.1.1 オブジェクト→省略
3.3.1.2 悪影響→省略
3.3.1.3 要件→省略
3.3.1.4 根拠→省略)

3.3.2 危機管理とインシデント対応
このセクションでは、緊急事態宣言やCBDCバックエンドサービスの侵害などのインシデントの原因となるサービスについて説明します。
したがって、このセクションでは、ビジネス継続性とインシデント処理の要件に焦点を当てます。

(3.3.2.1 オブジェクト→省略
3.3.2.2 悪影響→省略
3.3.2.3 要件→省略
3.3.2.4 根拠→省略)

3.3.3 適切な暗号対策
CBDCバックエンドサービスの完全性、真正性、機密性は、最先端の暗号技術の使用に依存しています。
これには、適切なハードウェアコンポーネント、鍵マテリアルと鍵ライフサイクル管理(3.3.4「鍵マテリアルの安全な取り扱いと保存」参照)、暗号化アルゴリズムとプロトコル、およびそれらのパラメータ化と実装が含まれます。
これらの暗号対策は、科学の進歩を考慮に入れるために定期的なメンテナンスが必要です。
最先端の推奨事項は、技術ガイドラインと標準に記載されています。

(3.3.3.1 オブジェクト→省略
3.3.3.2 悪影響→省略
3.3.3.3 要件→省略
3.3.3.4 根拠→省略)

3.3.4 鍵となる資料の安全な取り扱いと保管
鍵資料の安全な保管は、情報の機密性、情報及びデータオブジェクト、特に CBDC貨幣の完全性及び真正性を維持するために不可欠である。
安全な保管を実施することにより、中央銀行は鍵資料の機密性と完全性を維持します。

(3.3.4.1 オブジェクト→省略
3.3.4.2 悪影響→省略
3.3.4.3 要件→省略
3.3.4.4 根拠→省略)

3.3.5 安全な通信
安全な通信は、さまざまな種類の攻撃を可能にするメッセージ(トランザクションデータなど)の侵害から保護するために不可欠です。
安全な通信は、3.3.3「適切な暗号化対策」に従った安全なプロトコルとアルゴリズム、および3.3.4「鍵マテリアルの安全な取り扱いと保存」に従った対応する鍵の安全な取り扱いに依存しています。

(3.3.5.1 オブジェクト→省略
3.3.5.2 悪影響→省略
3.3.5.3 要件→省略
3.3.5.4 根拠→省略)

3.3.6 担当者の認証
認証は、担当者がCBDCバックエンドサービスにアクセスする際に重要な役割を果たします(例:キーマテリアルに関連するプロセスの場合)。
認証手段を個人に安全にバインドするために使用される識別プロセスは、重要なコンポーネントです。

(3.3.6.1 オブジェクト→省略
3.3.6.2 悪影響→省略
3.3.6.3 要件→省略
3.3.6.4 根拠→省略)

3.3.7 役割管理
中央銀行は、役割管理の枠組みを確立し、明確な責任を割り当て、内部犯行による攻撃のリスクを軽減する対応プロセスを設計することによって、CBDC のバックエンドサ ービスにおける関連する側面が適切にカバーされるようにしなければなりません。
また、内部犯行による攻撃リスクを軽減することができる。

(3.3.7.1 オブジェクト→省略
3.3.7.2 悪影響→省略
3.3.7.3 要件→省略
3.3.7.4 根拠→省略)

3.3.8 信頼できる人材
中央銀行は、特に CBDC のバックエンド業務における重要なプロセスで働く全ての職員が適切な資格を有し、信頼できることを保証しなければならない。

(3.3.8.1 オブジェクト→省略
3.3.8.2 悪影響→省略
3.3.8.3 要件→省略
3.3.8.4 根拠→省略)

3.3.9 ロギングと監視をサポートする強固なITシステムとネットワーク
CBDC のバックエンドサービスにおける重要なプロセスに使用される IT システムが保護されていない場合、攻撃者はそれらにアクセスすることができます。
これは、重要な暗号鍵の漏洩につながる可能性があり、例えば、以下のような結果を招く可能性があります。
最悪の場合、不正な CBDC貨幣が発見されない可能性。
重要な IT システムにアクセスした攻撃者は、同様に CBDC のバックエンドサービスの可用性を著しく損なう可能性。
攻撃者がシステムやアプリケーションレベルのログファイルの操作に成功した場合、そのような攻撃は全く追跡できないかもしれません。
その結果、CBDC に対する信頼を失うことになります。
中央銀行は、下請け業者も含め、その管理下にあるサービスに対して必要な対策を確保する責任があります。

(3.3.9.1 オブジェクト→省略
3.3.9.2 悪影響→省略
3.3.9.3 要件→省略
3.3.9.4 根拠→省略)

3.3.10 アプリケーションレベルのロギングとアーカイブ
流通中または過去に流通した CBDC 紙幣の累積価値を管理・監視するため、中央銀行は、ログ・アーカイブシステムを導入しなければなりません。
さらに、ロギング及びアーカイブシステムは、プロセスの失敗及びセキュリティインシデント（例えば、不正な従業員による攻撃）の検知及び調査に役立ちます。

ロギングと監視をサポートするハード化された IT システムとネットワーク」で説明した一般的なロギング手順は、ネットワークとオペレーティングシステムレベルで実行されますが、このセクションでは、CBDC バックエンドサービスのアプリケーションレベルでのロギングについて説明します。

ログに記録され、保管される必要がある一連の情報は、中央銀行によって定義され、GDPR [2]のArt.GDPRの第5条及び第6条[2]、並びに適用される財務データ保持方針に準拠しなければならない。

(3.3.10.1 オブジェクト→省略
3.3.10.2 悪影響→省略
3.3.10.3 要件→省略
3.3.10.4 根拠→省略)

3.3.11 物理的及び環境的セキュリティ
CBDCバックエンドシステムのサービスを中断することなく、機密データを保護するためには、重要なインフラやストレージメディアを、意図的または非意図的な故障、損傷、紛失、誤用などから物理的に保護する必要があります。
特に、中央銀行は、その施設、特に重要な暗号鍵を保管および使用するための重要なサーバーまたはハードウェアが配置されている領域へのアクセスを制限するものとします。

(3.3.11.1 オブジェクト→省略
3.3.11.2 悪影響→省略
3.3.11.3 要件→省略
3.3.11.4 根拠→省略)

3.3.12 サービスの可用性
CBDC のバックエンドサービスを正しく運用するためには、高い可用性が不可欠です。
サービスの可用性は、CBDC エコシステムの他の関係者に対して提供されなければなりません。
可用性に関する正確な要件は、プロセスに固有であり、3.1「機能要件」に定義されています。

(3.3.12.1 オブジェクト→省略
3.3.12.2 悪影響→省略
3.3.12.3 要件→省略
3.3.12.4 根拠→省略)

3.3.13 スケーラビリティ
CBDCが大規模に利用されるためには、十分な高スループットと低遅延を実現し、十分な数のユーザとトランザクションを処理できることが必要です。
CBDCのこれらの機能が、例外的な状況や使用パターンに関する誤った仮定のために(一時的に)不十分な場合でも、システムは引き続き安全であり、該当する場合は、機能の調整が不当な遅延なく可能でなければなりません。

(3.3.13.1 オブジェクト→省略
3.3.13.2 悪影響→省略
3.3.13.3 要件→省略
3.3.13.4 根拠→省略)

3.3.14 ドキュメント
CBDCバックエンドサービスの関連側面を明確かつ簡潔に文書化することは、その実装と運用における矛盾や曖昧さを避けるために必要です。
文書は、現在の状況を確実に反映するために定期的に更新されるものとします。

(3.3.14.1 オブジェクト→省略
3.3.14.2 悪影響→省略
3.3.14.3 要件→省略
3.3.14.4 根拠→省略)

略語のリスト(補足資料より)

この後のページは補足的な内容が載っています。
その中で略語一覧だけ紹介します。

AML マネーロンダリング防止
CBDC 中央銀行デジタル通貨
GDPR 一般データ保護規則
IDS 侵入検知システム
ISMS 情報セキュリティマネジメントシステム
KYC 顧客を知る
TR Technische Richtlinie (技術指針)

大元のドキュメント紹介→
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03179/TR03179-1.pdf?__blob=publicationFile&v=2