IMES DISCUSSION PAPER SERIES⪏䝍䞁䝟䞊ᛶ䛻ᇶ䛵䛟䝕䝆䝍䝹㏻㈌
䜴䜷䝺䝑䝖䛾◊✲ືྥ䇷༏ྡᛶ䛸㏱᫂ᛶ䛾୧❧䛻ྥ䛡䛶䇷

䛚䛚䛴䛛

䛒䛝䜙

኱ሯ㻌 ⋹ 㻌Discussion Paper No. 2022-J-9

INSTITUTE FOR MONETARY AND ECONOMIC STUDIESBANK OF JAPAN᪥ᮏ㖟⾜㔠⼥◊✲ᡤ㻌䛈103-8660 ᮾி㒔୰ኸ༊᪥ᮏᶫᮏ▼⏫ 2-1-1㻌㻌㻌᪥ᮏ㖟⾜㔠⼥◊✲ᡤ䛜ห⾜䛧䛶䛔䜛ㄽᩥ➼䛿䝩䞊䝮䝨䞊䝆䛛䜙䝎䜴䞁䝻䞊䝗䛷䛝䜎䛩䚹㻌https://www.imes.boj.or.jp㻌↓᩿䛷䛾㌿㍕䞉」〇䛿䛤㐲៖ୗ䛥䛔䚹㻌ഛ⪃㸸 ᪥ᮏ㖟⾜㔠⼥◊✲ᡤࢹ࢕ࢫ࢝ࢵࢩ࣭࣮ࣙࣥ࣌ࣃ࣮࣭ࢩ
࣮ࣜࢬࡣࠊ㔠⼥◊✲ᡤࢫࢱࢵࣇ࠾ࡼࡧእ㒊◊✲⪅࡟ࡼࡿ◊✲ᡂᯝࢆ࡜ࡾࡲ࡜ࡵࡓࡶࡢ࡛ࠊᏛ⏺ࠊ◊✲ᶵ㛵➼ࠊ㛵㐃ࡍࡿ᪉ࠎ࠿ࡽᖜᗈࡃࢥ࣓ࣥࢺࢆ㡬ᡝࡍࡿࡇ࡜ࢆពᅗࡋ
࡚࠸ࡿࠋࡓࡔࡋࠊࢹ࢕ࢫ࢝ࢵࢩ࣭࣮ࣙࣥ࣌ࣃ࣮ࡢෆᐜࡸពぢࡣࠊᇳ➹⪅ಶே࡟ᒓࡋࠊ᪥ᮏ㖟⾜࠶ࡿ࠸ࡣ㔠⼥◊✲ᡤࡢබᘧぢゎࢆ♧ࡍࡶࡢ࡛ࡣ࡞࠸ࠋ

IMES Discussion Paper Series 2022-J-92022 ᖺ 10 ᭶⪏䝍䞁䝟䞊ᛶ䛻ᇶ䛵䛟䝕䝆䝍䝹㏻㈌䜴䜷䝺䝑䝖䛾◊✲ືྥ㻌䇷㻌 ༏ྡᛶ䛸㏱᫂ᛶ䛾୧❧䛻ྥ䛡䛶㻌 䇷㻌
㻌
䛚䛚䛴䛛

䛒䛝䜙

኱ሯ 㻌 ⋹ *㻌

せ᪨㏆ᖺࠊࢹࢪࢱࣝ㏻㈌࡟㛵ࡍࡿ◊✲㛤ⓎࡀάⓎ໬ࡋ࡚࠸ࡿࠋࢹࢪࢱࣝ㏻㈌࡟ࡣࠊ࣐ࢿ࣮ࣟࣥࢲࣜࣥࢢཬࡧࢸࣟ㈨㔠౪୚࡬ࡢᑐᛂ࡜ࡋ࡚ࠊ⛎༏ࡉࢀࡓࢹ࣮ࢱࢆ㛤♧࡛ࡁࡿᛶ㉁ࡀồࡵࡽࢀࡿࡇ࡜࠿ࡽࠊ༏ྡ࡛ࡢྲྀᘬࢆྍ⬟࡜ࡍࡿᛶ㉁㸦༏ྡᛶ㸧ࢆࡶࡓࡏࡓ࠺࠼࡛ࠊᚲせ࡟ᛂࡌ࡚ྲྀᘬࡢෆᐜࢆ㛤♧࡛ࡁࡿᛶ㉁㸦㏱᫂ᛶ㸧ࢆ☜ಖ࡛ࡁࡿࡇ࡜ࡀᮃࡲࡋ࠸ࠋ◊✲ࢥ࣑ࣗࢽࢸ
࢕࡛ࡣࠊ1980 ᖺ௦࠿ࡽ༏ྡᛶ࡜㏱᫂ᛶࢆ୧❧ࡍࡿࢺ࣮ࢡࣥᆺࢹࢪࢱࣝ
㏻㈌ࡀ◊✲ࡉࢀ࡚ࡁ࡚࠾ࡾࠊࣈࣟࢵࢡࢳ࢙࣮ࣥࢆᇶ┙࡜ࡍࡿࢹࢪࢱࣝ㏻㈌࡬ࡢᛂ⏝ࡶ◊✲ࡉࢀጞࡵ࡚࠸ࡿࠋࡋ࠿ࡋࠊ࢔ࣥࢳ࣐ࢿ࣮ࣟࣥࢲࣜࣥࢢ
➼ࡢ♫఍ⓗせồࢆ‶ࡓࡍ㏱᫂ᛶࡢᢏ⾡≉ᛶࡣ᫂ࡽ࠿࡛࡞ࡃࠊᬯྕᢏ⾡ࡔࡅ࡛♫఍ⓗせồ࡟ᛂ࠼ࡿ༏ྡᛶ࡜㏱᫂ᛶࡢ୧❧ࡣ㞴ࡋ࠸ࠋࡑࡇ࡛ࠊᮏ✏࡛ࡣࠊ㏱᫂ᛶࢆᰂ㌾࡟ᐇ⌧࡛ࡁࡿྍ⬟ᛶࡢ࠶ࡿ⌮ㄽᇶ┙࡜ࡋ࡚ࠊ᭱㏆ᥦ᱌ ࡉ ࢀ ࡓ ᐇ ⾜ ド ㊧ ௜ ࢭ ࢟ ࣗ ࢔ ࣉ ࣟ ࢭ ࢵ ࢧ (Attested Execution Secure
Processor, Pass, Shi and Tramér, 2017) ࡟ᇶ࡙ࡃ᪉ᘧࡢᐇ⌧ྍ⬟ᛶࢆ⪃ᐹࡍࡿࠋ㏆ᖺࡢࢫ࣐࣮ࢺࣇ࢛ࣥ࡟ᦚ㍕ࡉࢀࡓ⪏ࢱࣥࣃ࣮ᢏ⾡ࡣࠊࡇࡢ⌮ㄽࡀồࡵࡿ⌮᝿ⓗ࡞ࣉࣛࢵࢺࣇ࢛࣮࣒ࡢせ௳ࢆ࡯ࡰ‶ࡓࡋ࡚࠾ࡾࠊ༏ྡᛶ
࡜㏱᫂ᛶࢆ୧❧ྍ⬟࡛࠶ࡿ࡜⪃࠼ࡽࢀࡿࠋ
࣮࣮࢟࣡ࢻ㸸ᬯྕ㈨⏘ࠊド㊧ᐇ⾜ࢭ࢟ࣗ࢔ࣉࣟࢭࢵࢧࠊ⪏ࢱࣥࣃ࣮ᢏ⾡ࠊ
ࢹࢪࢱࣝ㏻㈌࢛࢘ࣞࢵࢺࠊ㏱᫂ᛶࠊ༏ྡᛶ
JEL classification: E49ࠊL86ࠊL96ࠊZ00*᝟ሗࢭ࢟ࣗࣜࢸ࢕኱Ꮫ㝔኱Ꮫᩍᤵ㸦E-mail: otsuka@iisec.ac.jp㸧ᮏ✏ࡣࠊ➹⪅ࡀ᪥ᮏ㖟⾜㔠⼥◊✲ᡤᐈဨ◊✲ဨࡢᮇ㛫࡟⾜ࡗࡓ◊✲ࢆࡲ࡜ࡵࡓࡶࡢ࡛
࠶ࡿࠋᮏ✏ࡢసᡂ࡟ᙜࡓࡗ࡚ࡣࠊḈ஭ᖾ୍ᩍᤵ(஑ᕞ኱Ꮫ) ࠿ࡽ᭷┈࡞ࢥ࣓ࣥࢺࢆ㡬ᡝࡋࡓࠋࡲࡓࠊ㔠⼥◊✲ᡤࢫࢱࢵࣇ࡟㈗㔜࡞ࢥ࣓ࣥࢺࢆ㡬ᡝࡋࡓࠋࡇࡇ࡟グࡋ࡚ឤㅰࡋ
ࡓ࠸ࠋࡓࡔࡋࠊᮏ✏࡟♧ࡉࢀ࡚࠸ࡿពぢࡣࠊ➹⪅ಶே࡟ᒓࡋࠊ᪥ᮏ㖟⾜ࡢබᘧぢゎࢆ♧ࡍࡶࡢ࡛ࡣ࡞࠸ࠋࡲࡓࠊ࠶ࡾ࠺࡭ࡁㄗࡾࡣࡍ࡭࡚➹⪅ಶே࡟ᒓࡍࡿࠋᮏ✏ࡣࠊ2022
ᖺ 4 ᭶ 15 ᪥᫬Ⅼࡢ᝟ሗࢆඖ࡟ᇳ➹ࡉࢀࡓࠋ目次
R はじめにRk デジタル通貨ウォレットの安全性
URV コールドウォレット X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
イ
デジタル通貨の保管・移動に必要なデータの保護 X X X X X X X X X X X
ロ
取引実行時の本人意思の確認（quaAqua） X X X X X X X X X X X X X X
UkV スマートフォンにおけるデジタル通貨ウォレット X X X X X X X X X X X X X X X
イ
実現が見込まれるセキュリティ機能 X X X X X X X X X X X X X X X X X X X
ロ
取引実行時の本人意思の確認（quaAqua） X X X X X X X X X X X X X X

k
k
k
j
8
8
e

j 耐タンパー性に基づく匿名性・透明性両立の先行研究
URV トークン型デジタル通貨における二重支払いへの対策 X X X X X X X X X X X X X
UkV a+?MQ`` 署名 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
UjV a+?MQ`` ブラインド署名 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
イ
ブラインド署名によるデジタル通貨トークンの発行・使用 X X X X X X
ロ
トークンの使用における匿名性 X X X X X X X X X X X X X X X X X X X X X
U9V 追跡可能 a+?MQ`` ブラインド署名 X X X X X X X X X X X X X X X X X X X X X X X X
U8V オブザーバー方式の構成 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

d
N
Ry
RR
RR
Rj
Rj
Re

9 実行証跡付セキュアプロセッサによる柔軟な匿名性・透明性
URV 概要 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
イ
仮定 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
ロ
理想機能 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
UkV 内部記憶のあるプログラムの難読化（aii27mH P#7mb+iBQM） X X X X X X X X X
イ
概要 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
ロ
内部記憶を持つプログラムの難読化の構成 X X X X X X X X X X X X X X X
UjV 実行証跡付セキュアプロセッサによる匿名性と透明性の両立 X X X X X X X X X

RN
RN
RN
ky
kj
kj
kj
kN

8 まとめ

jk

参考文献

jj

R

はじめに

未来のデジタル通貨は、利用者が自身の個人情報を自らコントロールできる性質を持つことが望ましい。一方で、現金が持つ高い匿名性を実現すべきか否かは議論が分かれている。
匿名性のないデジタル通貨が普及すれば、発行体や関係者に悪意がない場合でも、規制当局
や取引当事者による利用者のデータの保護の失敗等によるセキュリティリスクを排除できない。他方、デジタル通貨は高額の資金を瞬時に移動できることから、少なくとも金融機関に求めていたものと同程度あるいはそれ以上のアンチマネーロンダリング（JG）やテロ資金供与への対策（*6h）が求められる。そこで、本稿では、デジタル通貨ウォレット機能を担う多様なオープンソースプログラムの開発を推奨し、規制当局が JGf*6h 対応ルールを満たすオープンソースプログラムを選別したホワイトリストを公開することで、利用者がこのホワイトリストの中から信頼できるものを選択して自身の耐タンパーウォレットにインストールして実行するシナリオを想定する。耐タンパーウォレット内で動くプログラムをオー
プンソース化することで、当局による過度なプライバシー侵害等への不信感を払拭しつつ、社会的に合意の取れた JGf*6h 対応ルールの技術的強制による遵守を同時に達成できるシステム（_2;mHiQ`v h2+?MQHQ;v）の実現可能性を考察する。この際、デジタル通貨による資金決済において JGf*6h ルールが適切なプログラムによって正しく履行されたことを、取引当事者や規制当局等が検証可能とするための枠組みとして、近年提案された実行証跡付
セキュアプロセッサ USbb- a?B M/ h`Kû`- kyRdV の応用を提案する。
デジタル通貨に関する研究では、これまでも匿名での取引を可能とする性質（匿名性）と必要に応じて取引の内容を開示させることができる性質（透明性）の両立が議論されてきた。特に、（R）支払者は匿名で取引が可能であるが、受領者についてはデジタル通貨の換金にあたり金融機関に対して匿名性をもたないもの U*?mK- RN3kc *?mK- :`Qi?Qz M/ JQb2`- kykRV、（k）通常の取引は全て匿名だが、裁判所等の令状に基づき、特定の人物に関わる取引や特定の取引を指定して当事者を開示できる機能を備えたもの Uai/H2`- SBp2i2m M/ *K2MBb+?RNN8V 等が提案されているR 。これらは、暗号理論で実現できる信頼性の高い方式で、JG
や *6h にも一定の効果が期待される。
匿名性と透明性の両立に関して、本稿ではより現実的な選択肢として、耐タンパー技術を用いたデジタル通貨ウォレット技術に注目する。耐タンパー技術は、半導体デバイスの回路
構造のランダム化やチップ損傷の検知機能に関する技術であり、暗号伴等の機密情報を半導体チップ（セキュアエレメント）の内部に格納することで、機密情報を保護しながら、デジタ
ル署名等の暗号処理を行う技術である。A* カードや aAJ カード等で古くから利用されているが、当時はあらかじめ固定化されたプログラムを半導体デバイス内に埋め込む必要があった。近年では、事後的にプログラムの更新や新規導入が可能な設計となっており、こうした半導体デバイスとして、2aAJk や 62HB* チップj がスマートフォンに搭載されるようになっている。プログラム可能な耐タンパーデバイスは、:HQ#HSHi7Q`K9 が定めた仕様に従っているものが多く、それらは :S@a18 と総称されている。マイナンバーカードのスマートフォン搭

R

他方、ブロックチェーンで実現されている匿名性 U"2M@abbQM 2i HX- kyR9c Jtr2HH- kyR8c >2BHKM 2i HXkyRdc "ɃMx 2i HX- kykyV は、透明性を考慮していないものが多く U大塚- kykkV 、透明性の実現を目指した研究
UJBiMB M/ PibmF- kykyV は少ない。
k
2aAJ, 2K#2//2/ am#b+`B#2` A/2MiBiv JQ/mH2
j
62HB* チップ, 交通系 A* カードやおサイフケータイとして利用されている耐タンパーデバイス。
9
セキュアエレメント技術の標準化を推進する非営利民間企業。
8:S@a1, :HQ#HSHi7Q`K 仕様に準拠したセキュアエレメント。

R載プロジェクトe でも、:S@a1 にマイナンバーカードの機能を搭載し、スマートフォンだけで確実なリモート個人認証（2Eu*）を実現するためのインフラ作りが進められている。デ
ジタル通貨においても、スマートフォンに搭載された :S@a1 等の耐タンパー技術を利用する
ことにより、スマートフォンならではの利便性や受容性を背景にして、匿名性と透明性を両立するデジタル通貨の実現が期待される。
以下、本稿では、k 節において、スマートフォンの :S@a1 でデジタル通貨ウォレットを実現する際の安全性を考察する。続く j 節では、耐タンパーデバイスを用いて、透明性の高い取引の実行を利用者に強制するオブザーバー（P#b2`p2`）方式 U"`M/b- RNNjV を紹介する。
9 節では、任意のプログラムを搭載可能な耐タンパーデバイスの暗号学的なモデルである実行証跡付セキュアプロセッサ USbb- a?B M/ h`Kû`- kyRdVd を紹介し、デジタル通貨の匿名性と透明性を両立する技術の実現可能性を考察する。

k

デジタル通貨ウォレットの安全性

デジタル通貨のスキームは、デジタル通貨を発行する主体とその利用者で構成される。デ
ジタル通貨の利用者は、デジタル通貨ウォレット（以下、ウォレット）と呼ばれるデバイスを利用してデジタル通貨の保管や移動を行う。そのため、ウォレットには、（R）デジタル通貨の保管や移動に必要となるデータの保護、（k）取引実行時の本人意思の確認が求められる。
以下では、暗号資産での利用が普及しているコールドウォレット3 を例に、
（R）と（k）の機
能がどのように実現されているかを概観する。

URVイ

コールドウォレット
デジタル通貨の保管・移動に必要なデータの保護

ブロックチェーンをベースとする暗号資産取引では、暗号資産の保管や移動を暗号処理
によって行っている。すなわち、ウォレットには秘密伴が保管されており、それを用いて生成したデジタル署名を取引内容に付して送付すると、ブロックチェーンネットワークによって暗号資産の移動が行われる。このように、ウォレット内に暗号資産そのものが保管されているわけではないが、秘密伴によって暗号資産を移動できるという点で、ウォレット内での秘密伴の管理が暗号資産の管理に直結しているといえる。一般的なコールドウォレットは耐タンパーデバイスで実現されており、秘密伴は耐タンパーデバイスの内部で生成され、正規以外の方法では外部に取り出すことができない構成になっている。
また、"Bi+QBM や 1i?2`2mK では、ブロックチェーン上で複数のアカウントを扱うことが可能であり、その際には対応する秘密伴を複数管理する必要がある。また、暗号資産の流れを秘匿することを目的に、アカウントを使い捨てにすることも可能であり、そうした場合にも秘密伴を多く管理する機構が求められる。こうした機構を実現するウォレットとして、Reマイナンバーカードの機能のスマートフォン搭載等に関する検討会（総務省）、?iiTb,ffrrrXbQmKmX;QX
DTfKBMnbQbBFBfF2MFvmfKvMmK#2`nbK`iT?QM2fBM/2tX?iKHd
ii2bi2/ 1t2+miBQM a2+m`2 S`Q+2bbQ`USbb- a?B M/ h`Kû`- kyRdV の訳語に、原語のままとする案や実行証明機能付きセキュアプロセッサなどの訳語も検討したが、本論文では現在の実行証跡付セキュアプロセッ
サとした。
3
暗号資産の分野では、インターネットから切り離して保管できるデバイスをコールドウォレット、インター
ネットに常時接続して利用するタイプをホットウォレットと呼んでいる。コールドウォレットは、暗号資産の移動時にのみシステムに物理的に接続するものであるため、不正アクセスのリスクが相対的に低い。

k

 

* 
&'" + )&'"( ) !#"* 
&'" + )&'"()"$# %

"&'"()・・・", 
&'" +), 
&'" +)* 
&'" + )UV コールドウォレットの一例（出典：#Bi+QBMXQ`;）"

"



"



"

-

"
"



"



"

"

-

・
・
・

"

"

, 
&'" +)



・
・
・

  

・・・
"

"

"

・
・
・


"-

U#V >. ウォレット（"AS@jk）の仕組み（出典：?iiTb,ff;Bi?m#X+QKf#Bi+QBMf#BTbf#HQ#fKbi2`f#BT@yyjkXK2/BrBFB）

図 R, 暗号資産における伴管理技術
つのマスター乱数シード USV から全ての伴を導出する階層型決定性ウォレット（>.@qHH2i,>B2``+?B+H .2i2`KBMBbiB+ qHH2iN ）が普及している。決定性とは、同じマスター乱数シードを用いる限り、常に同じ伴を導出できる性質である。階層型決定性ウォレットであれば、紛失または故障によりウォレットが使用不能になった際でも、使用開始時に出力されるマスター
乱数シード S を保管しておくことでRy 、いつでも別のウォレットに伴を再構成することができる。また、伴は図 R（#）に示すようなマスター乱数シード S を根とするツリー構造を持ち、アドレスで使用する伴は、マスター乱数シード S から一意に特定できるようになっている。
取引実行時の本人意思の確認（quaAqua）

ロ

デジタル通貨のスキームでは、サーバと利用者間で取引内容の通信が行われる。取引実行時に利用者の意思を確認するにあたっては、サーバから送られた通信内容が利用者に正確に表示され、かつ、利用者の入力内容が改ざんされずにサーバに伝達されるといった、人間とシステムとの間の安全な通信路の構築が極めて重要となる。これはトラステッド・パス
N>.@qHH2i の基本仕様は "AS@jkU"Bi+QBM AKT`Qp2K2Mi S`QTQbHb）で定義される。"AS とは、ビットコイ
ン開発者らによって作成されたビットコインシステムを改善するための提案のことであり、議論や投票を経てビットコインコミュニティにおける標準規格となっているものもある。
Ry
耐タンパーデバイス内で生成された S は、使用開始時に限って取り出すことが可能であり、別の耐タン
パーデバイスに複製保管しておくことができる。ただし、安全な実装では、使用開始後に S を取り出すことは
できない。

j

図 k, 利用者@サーバ間の通信路と攻撃箇所

ULiBQMH *QKTmi2` a2+m`Biv *2Mi2`- lXaX- RN38V として、RN3y 年代から提唱されている概念であるが、多くのコンピュータシステムにおいて実現が困難であるのが実情である。例えば、フィッシングやインターネットバンキングにおける不正アクセスは、トラステッド・パスの構築が困難であるために起こりうるものである。
デジタル通貨を発行する主体のサーバ（以下、サーバ）と利用者の端末（耐タンパーデバ
イス）からなるシステムを例に挙げ、サーバが端末に送信したメッセージを利用者が承認す。なお、耐タンパーデバイスは、暗号、認証、伴管理の j つの機能を有る手順を考える（図 k）
しているものとする。サーバがメッセージを暗号化して端末に送信すると、端末はメッセー
ジを復号してディスプレイに表示する。利用者は表示内容を確認し、キーボード等から暗証番号を打ち込むことにより承認を与え、メッセージに対する利用者の署名が生成される。このとき、サーバから秘密伴を管理している耐タンパーデバイスまでの経路は暗号技術等で保護することができる。しかし、システムがマルウェアに感染等していた場合、メッセージが耐タンパーデバイスで復号されて平文になったところで表示を変更される（攻撃 R）リスクがあるほか、利用者の入力内容が改ざんされる（攻撃 k）リスクもある。このように、耐タ
ンパーデバイスを用いた場合であっても、マルウェアへの感染等により利用者が意図しないメッセージに対して署名してしまうリスクがある。攻撃 R、攻撃 k に対抗する技術的な対策
により、利用者が確認している表示内容と、耐タンパーデバイスの署名内容を一致させる性
質を、quaAqua（q?i uQm a22 Ab q?i uQm aB;M）と呼ぶ。容易に見えて、実は達成が困難な性質である。
この問題に対処するために、q2B;QH/ らは、表示機能に加え「PE」と「キャンセル」の k
つの入力ボタンを備えた la" デバイスを試作した Uq2B;QH/ 2i HX- kyy3V。本 la" デバイス
は、S* に接続してサーバとの間で hGa（h`MbTQ`i Gv2` a2+m`Biv）認証を行うことで､サーバと la" デバイスの間に暗号通信による安全なチャネルを確立し、経路上の S* に存在する
マルウェア等に妨害されることなく、サーバから送信された情報をそのまま la" デバイス上
で表示／確認することで確実に quaAqua を達成するものである。これは、図 k の枠内にある通信､暗号／認証／伴管理､入力／表示の機能を一体化した専用の耐タンパーデバイスで構成することにより、攻撃 R、攻撃 k に対抗してサーバのメッセージを確実に利用者に伝達する解決策になっている。
コールドウォレットにも同様の機能を備えているものが多い。図 R（）に示すように、一般的なコールドウォレットにも、液晶表示とボタンが装備されている。これは、先行研究と同じく、通信､暗号／認証／伴管理､入力／表示の全ての機能を一体のデバイスとして実現す
るアプローチに従っている。このアプローチは安全性を高める最も確実な方法だが、専用のデバイスを準備しなければならないことからコストや利便性の面で課題が残る。

9

UkV
イ

スマートフォンにおけるデジタル通貨ウォレット
実現が見込まれるセキュリティ機能

スマートフォンには複数のセキュリティハードウェアが備わっている。代表的なものには、h11RR や、前述の 62HB* チップがある。特に、h11 は多くの _J プロセッサに搭載され、一般のアプリケーションから隔離された処理が可能なことから、生体認証や暗号処理な
どの Pa 標準のセキュリティ機能の実装に用いられている。一方、62HB* チップは、** 認証（AaPfA1* R89y3）Rk における onoLX8Rj 等の網羅的なペネトレーションテスト（攻撃耐性の評価）を通過したチップである。以前は、電子マネー・交通系 A* 等の専用チップであったが、kyRN 年からは :S@a1 としての機能が導入され、多様なアプリケーションに利用できるようになった。kyRN 年冬から M/`QB/ スマートフォンへの搭載が開始され、kykR 年末時点では国内で新たに発売されたほぼ全ての M/`QB/ スマートフォンに :S@a1 が搭載されている。
加えて、マイナンバーカードのスマートフォン搭載での検討状況R9 を考慮すると、スマー
トフォン内の :S@a1 にウォレットを搭載することが可能であり、その場合には以下の機能も組み込める可能性がある。

RX 生体認証による本人確認
M/`QB/ 端末の生体認証機能は、前述の h11 を用いた暗号伴管理機能（*`vTiQP#D2+i）と連動することで、生体認証が受理されたことを暗号伴による認証プロトコルで証明することができる。これは、生体認証が受理されない限り *`vTiQP#D2+i 内の伴を利用できないように構成するものであり、暗号伴を用いた認証プロトコルが成功すれば、端末に正しい生体が提示されたことを外部から推定できる。こうした機能を用いた生体認証の規格には 6A.PR8 があり、リモートからの本人認証に広く利用されている。また、
マイナンバーカードのスマートフォン搭載に関する検討では、この機能を用いて、パス
ワードによる認証を生体認証に置き換え可能とすることが計画されているRe 。同様に、
デジタル通貨ウォレットのロック解除にも、フィッシングによる漏洩リスクの高いパスワードではなく、生体認証による本人確認を安全に用いることが考えられる。
kX タッチ動作による支払い
スマートフォンの多くには L6*Rd が備わっており、対面販売や自動販売機に対してもタッチ動作によるデジタル通貨ウォレットからの支払いが技術的に可能である。マイナンバーカードのスマートフォン搭載に関する検討では、L6* 経由で受信されたメッRRh11, h`mbi2/ 1t2+miBQM 1MpB`QMK2Mi。安全な処理を実行するための隔離実行環境を備えたプロセッサ。
_J の h`mbiwQM2、AMi2H の a:s（aQ7ir`2 :m`/ 1ti2MbBQMb）等。
Rk**（*QKKQM *`Bi2`B）は国際標準規格 AaPfA1* R89y3 で規定された Ah システムのセキュリティ保証
レベル定める規格であり、各国で ** を用いたセキュリティ認証制度が運用されている。
RjonoLX8 とは、o（脆弱性評定）クラスの oL 脆弱性分析ファミリである。8 は最高レベルの脆、?iiTb,
弱性分析を示す。例えば、以下の文献を参照。AS：スマートカードへの攻撃能力の適用（p2` kXN）
ffrrrXBTX;QXDTfb2+m`BivfDBb2+f?`/r`2f/Q+mK2Mibf**."@kyRj@y8@yyknCXT/7、kyRj 年 8 月。
R9
総務省, 第 R 次とりまとめ 〜電子証明書のスマートフォン搭載の実現に向けて〜 kyky 年 Rk 月 R8 日。
R86A.P（6bi A.2MiBiv PMHBM2）は、6A.P アライアンスが定めるリモート認証の規格。
Re
総務省, マイナンバーカードの機能のスマートフォン搭載等に関する検討会（第 8 回）､ kykR 年 j 月 j 日。
Rd
L6*, L2` 6B2H/ *QKKmMB+iBQM。スマートフォンのタッチ動作による無線通信のインターフェイス。

8

セージを :S@a1 内の CSEA アプレットR3 にルーティング（経路指定）することで、住民票のコンビニ交付や健康保険証等による資格確認等への応用が検討されているRN 。

jX 紛失／盗難や機種変更時の対応
スマートフォン紛失・盗難時の対応として、スマートフォンの通信機能を使い、遠隔から :S@a1 内の情報を消去することが技術的に可能であるRN 。これは従来の A* カードにはなかった機能であり、利用者に一定の安心感を与えられる機能であると思われるky 。
マイナンバーカードのスマートフォン搭載に関する検討では、機種変更の際、新しいス
マートフォンの :S@a1 で新たに伴情報を生成すると共に、古いスマートフォン内の伴情報を遠隔消去するよう検討が進められているRN 。機種変更時には、古いスマートフォンの所有者であることを確認するのではなく、マイナンバーカードによって本人確認を行う方向で検討が進められており、スマートフォン紛失・盗難への対策が講じられる予定である。デジタル通貨のケースにおいても、古いスマートフォンの :S@a1 内の伴情報を消去する機能は必要となるが、加えて、新旧機種間でのデジタル通貨（を管理する暗号伴）の移動が確実に行われることの保証が必要なため、機種変更の手順はより複雑になると想定される。例えば、前述の階層型決定性ウォレットを採用し、マ
イナンバーカードの伴を用いてマスター乱数シードを暗号化してクラウド等で管理しておくことで、クラウドから新しいスマートフォンにマスター乱数シードを復元するなどの手順が考えられる。

:S@a1 によって上記セキュリティ機能を達成できると見込まれるが、:S@a1 はスマートフォンに常時接続されていることから、ウォレットにはマルウェア等からの不正な署名要求が寄せられるリスクがある。そのため、必要な時だけ接続するコールドウォレットと比較してリスクが高く、不要な署名要求を識別して拒絶する機能が不可欠である点には留意が必要である。以下、:S@a1 のリスクについて考察する。
取引実行時の本人意思の確認（quaAqua）

ロ

スマートフォンに搭載するウォレットは、:S@a1 内にアプレットの形で実装され、取引内容の入力・表示は M/`QB/ TT に分離した形で実装される。quaAqua を達成するためには、これらが一体として動作し、正しい取引内容を表示すると共に、本人意思に沿った入力を :S@a1 に正しく伝達する機構が必要となる。以下では、:HQ#HSHi7Q`K 規格に定義されているアクセス制御機構を用いて quaAqua を達成する方式を説明する。この機構は多くのスマートフォン Pa（M/`QB/ Pa、BPa 等）に既に標準実装されており、スマートフォン上の特定のアプリと :S@a1 を一体化して動作させることができるようになっている。
:HQ#HSHi7Q`K 規格におけるアクセス制御機構は、図 j に示す構造になっている。ここで、セキュアエレメント（a2+m`2 1H2K2Mi、:S@a1）は物理的にはデバイス内に埋め込まれているが、機能的にはデバイスと分離されているため図では外側に描かれている。スマートR3

マイナンバーカードの CSEA 機能を実現する Cp アプレットで :S@a1 内に格納されている。
総務省, マイナンバーカードの機能のスマートフォン搭載等に関する検討会（第 k 次とりまとめ）､ kykk
年 9 月 R8 日。
ky
ただし、通信が常時遮断された環境では機能せず、:S@a1 内の情報の利用休止や消去には確実な本人確認が求められることから利用停止までの時間差が生じ、紛失／盗難リスクを完全に回避できる技術ではないことには注意が必要である。
RN

e

kR
フォン上のアプリである .2pB+2 TTHB+iBQM にはコード署名（aB;Mim`2）が付与されておkk
り、それを ++2bb *QMi`QH 1M7Q`+2` が認識し、セキュアエレメントへのアクセス制御を実行する。セキュアエレメントの内部は、製造者が事前に設定した Abbm2` a.（発行者セキュリ
ティドメイン）と、セキュアエレメントの利用目的に応じて導入可能な TTHB+iBQM S`QpB/2`a.（サービス提供者セキュリティドメイン）に分かれている。それぞれの a. は異なる伴で記憶空間が暗号化され、a. を越えて機密情報が漏洩しないように隔離された空間となっている。各 TTHB+iBQM S`QpB/2` a. は、固有のアクセス制御ルールが格納されたデータベース _@*（++2bb _mH2 TTHB+iBQM *HB2Mi）を保持し、アクセス制御ルールを満たすアクセ
ス要求だけが TTHB+iBQM S`QpB/2` a. 内でデジタル署名や決済処理などの機密情報を扱う
a1 TTHB+iBQM に接続される。各 _@* のルールは、Abbm2` a. 内の _@J（++2bb _mH2
TTHB+iBQM Jbi2`）に統合され、アクセス制御ルール全体の無矛盾性が検証された後にデバイス内の ++2bb *QMi`QH 1M7Q`+2` と共有される。
次にアクセス制御機構の動作をより詳しく述べる。アクセスを許可されるアプリケーショ
ンは、事前に _@* のアクセス制御データkj にコード署名を検証するための公開伴を登録しておく。++2bb *QMi`QH 1M7Q`+2` は、この公開伴で .2pB+2 TTHB+iBQM のコード署名を検証できる場合に限り、対応する TTHB+iBQM S`QpB/2` a. 内の a1 TTHB+iBQM へのアクセスを許可する U:aJ bbQ+BiBQM- kyRRV。こうした機構により、リパッケージ攻撃k9 等で紛らわ
しいフィッシングアプリが起動されたとしても、_@* にコード署名検証用の公開伴が登録されていない同アプリは a1 TTHB+iBQM にアクセスできないことが保証されるk8 。
以上から、攻撃 R（メッセージが耐タンパーデバイスで復号されて平文になったところで表示を変更されるリスク）に関しては、暗号／認証／伴管理を担う :S@a1 とスマートフォ
ンアプリをアクセス制御機能により一体化することにより、対策を講じることができる。
また、攻撃 k（利用者の入力内容が改ざんされるリスク）に関しては、改ざんした表示を重ねて錯誤させるスクリーンオーバレイ攻撃ke が主要な攻撃として知られている。ただし、こうしたリスクは比較的早くから認識され、Pa による対策も進んでいる。例えば、M/`QB/eXy
以降の Pa ではパーミッションを取得したアプリケーションでなければスクリーンオーバレ
イを実行できない仕様に改善されている。

j

耐タンパー性に基づく匿名性・透明性両立の先行研究

本節では、:S@a1 を基盤としたウォレットの構成を前提として、匿名性と透明性を兼ね備えたデジタル通貨の実現方法を考察する。
オブザーバー方式とは、利用者による不正を防止するために、耐タンパーデバイスを利用者
kR
ソフトウェアに対して製造元が付したデジタル署名。利用者はデジタル署名の検証により、ソフトウェアの真正性と流通経路で改ざんされていないことを確認することができる。
kk
セキュアエレメントに格納されているアクセスルールを取得し、それらのルールを適用して制限するソフトウェア。
kj
アクセス制御データ（++2bb *QMi`QH .i）は、アクセスを許可するコード署名検証用の公開伴データ。
k9
既存の正規アプリに悪意のあるコードを組み込み再配布する行為。
k8
アクセス制御機構（図 j 中 ++2bb *QMi`QH 1M7Q`+2`V は M/`QB/ Pa の一部として実装されている。このため、端末を lLGP*E1. 状態にし、_QQi 化した状態の M/`QB/ Pa を改ざんすればアクセス制御機構を無効化することも可能ではあるが、通常、利用者が意図的に実施しない限り、この操作は困難となるように設計されている端末が多い。
ke
実行中の他のアプリやウィンドウに別のウィンドウを重ねて表示する攻撃であり、本来のウィンドウをクリックしているようにみせかけて実際には別のウィンドウをクリックさせるもの。

d図 j, スマートフォン（.2pB+2）上のアプリ（.2pB+2 TTHB+iBQM）から :S@a1（a2+m`2 1H2K2Mi）
へのアクセス制御機構 U出典, :HQ#HSHi7Q`K- kyR9Vのオブザーバー（監視者）として利用するものである。オブザーバーを利用者の端末に搭載することで、透明性の高い取引の実行を利用者に強制することができる U*?mK M/ S2/2`b2MRNNjc "`M/b- RNNjV。具体的には、トークンの二重支払いが発生した際にのみ事後的に利用者の特定を可能にすることで、匿名性kd と透明性をデジタル通貨のスキームに持たせるものである。本節では、オブザーバー方式によってデジタル通貨の使用を一回のみに制限する義務（二重支払いの防止）を技術的に強制する例を示すk3 。
なお、本稿では銀行がデジタル通貨の発行や償還を担うことを想定している。銀行は本人確認済みの預金者（利用者）に対して、預金口座の残高を減じることで見合いのデジタル
通貨をトークンとして発行する。また、預金者（受け手／店舗）からトークンを受け入れたら当該預金者の預金口座に相当額を加算し、当該トークンを償還・償却することを想定している。これは、デジタル通貨の発行・利用・償還においてクローズドループ型（図 9）を想kd*?mK や "`M/b ら U*?mK M/ S2/2`b2M- RNNjc "`M/b- RNNjV のオブザーバー方式における匿名性とは、支払者の匿名性のみを実現するものであり、トークン償還銀行に対する受領者の匿名性はない。Ny 年代当時の耐タンパーデバイスは、出荷前に耐タンパーデバイス内のプログラムを固定し、出荷後は変更を加えさせないことで安全性を高めるという考え方が主流であったため、当時は、シンプルで完結した方式を提示しなければならなかった。一方、後述する実行証跡付セキュアプロセッサ方式では、前述の :S@a1 に代表されるよ
うな、出荷後に耐タンパーデバイス内のプログラムを変更しても安全性を保つことができる機構を前提とする、
kyyy 年代以降に確立した考え方に基づいているため、プログラムにより受け取り側の匿名性や顕名性を自在にコントロールすることができる。
k3
この考え方は、裁判所の令状がある場合のみ匿名取引の取引内容を開示する義務を強制するエスクロー
キャッシュ等 Uai/H2`- SBp2i2m M/ *K2MBb+?- RNN8c 6mDBbFB M/ PFKQiQ- RNN3c #2 M/ P?Fm#Q- kyyRVへの応用も考えられる。

3

定していることを意味するkN 。

図 9, 銀行預金とクローズドループ型トークンの構成

URV

トークン型デジタル通貨における二重支払いへの対策

トークン型デジタル通貨とは、物理的な現金の代わりに暗号処理を施した「トークン」と呼ばれるデータを受け渡すことによって金銭価値を移転させる方式である。トークン型では、トークンの複製による二重払い（複製したトークンを支払いに使用すること）への対策が重要となる。
二重支払いへの対策には、これまで大きく k つの方式が研究されている。R つ目はトークン償還銀行が支払い済みトークンのリストを保有し、店舗がトークンを受け取る際にトークン償還銀行に問い合わせる方式である。これには、全ての取引に対してオンラインで迅速に回答することが求められるため、トークン償還銀行に高速大容量なサーバ設備の設置が求められる。k つ目は店舗がトークンを受け取る際にトークン償還銀行に照会せずに二重支払いを抑止もしくは防止しようとするものである。抑止する方法としては、トークン生成時に支払者の A. を暗号化して埋め込むことで、二重支払いされた k つのトークンから支払者 A.
を特定できるようにするアプローチ U*?mK 2i HX- RNNyc PFKQiQ M/ P?i- RNNkc "`M/bRNNjV があるjy 。また、防止する手法としては、耐タンパーデバイスでトークンの使用を R 回に制限するすることで二重払いを防止するアプローチがある。
ここで紹介するオブザーバー方式は、トークン償還銀行に照会することなく二重支払いを防ぐ上記 k つの方法を融合した方式である。オブザーバーが耐タンパー性を有する場合には、トークンの使用を R 回に制限することで二重支払いのリスクを排除できるほか、万が一、耐タンパー性が無効化された場合であっても、二重支払いが検出された場合には支払者の A.
を事後的に特定することができる。
以下では、まず、トークンの偽造耐性に用いられる a+?MQ`` 署名を説明するjR 。デジタ
ル署名は秘密伴を用いて生成され、秘密伴と対をなす公開伴を用いることで、デジタル署名の生成者を特定すると共にメッセージの改ざんの有無を検証することができる技術である。
トークン偽造耐性とは、トークン発行銀行以外によるトークンの生成および改ざんが困難であることを指し、シリアル番号にトークン発行銀行のデジタル署名を施すことで構成することができる。
（j）では、デジタル通貨に匿名性を持たせる方式として提案された a+?MQ`` ブ
ラインド署名を紹介する。a+?MQ`` ブラインド署名は、ユーザがランダムに選んだシリアル
番号を知らせることなく、トークン発行銀行にデジタル署名を付与させることができる方式である。トークン発行銀行による署名とトークンとの対応関係を秘匿できることから、トークン発行銀行とトークン償還銀行が結託して追跡を試みても、支払に利用されたトークンかkN

クローズドループ型は、トークンの流れが一方向であり、利用者と店舗の役割が異なるタイプをいう。利用者が店舗に支払ったトークンは銀行に還流され、トークンに見合いの現金が店舗の銀行口座に振り込まれる。
これに対し、オープンループ型は、店舗や利用者間の転々流通を可能とするタイプを指す。
jy
この分野の包括的なサーベイは、U中山他- RNNdc 中山- RNN3c 中山・太田・松本- RNNNV に詳しい。
jR
デジタル署名には _a や 1*.a など様々な方式があるが、ここではオブザーバーの考え方を具体的に解説するために、U"`M/b- RNNjV がベースとしている a+?MQ`` 署名を紹介する。

N表 R, 本稿で紹介するデジタル通貨技術の比較
トークンの

透明性

匿名性

偽造耐性

二重支払いの支払ルール

多様なルール

事後検知

の強制

の強制

a+?MQ`` 署名

〇

なし

なし

なし

なし

a+?MQ`` ブラインド署名

〇

〇

なし

なし

なし

追跡可能 a+?MQ`` ブラインド署名

〇

〇

〇

なし

なし

オブザーバー

〇

〇

〇

〇

なし

実行証跡付セキュアプロセッサ

〇

〇

〇

〇

〇

らその利用者を特定することが困難となっている。さらに、（9）において、トークンの二重支払いを行った利用者を特定可能とする追跡可能 a+?MQ`` ブラインド署名を紹介する。そのうえで、（8）では、オブザーバー方式を紹介し、次節で実行証跡付セキュアプロセッサを利用したデジタル通貨について考察を行う。なお、以下で紹介する方式の比較は表 R を参照さ
れたい。

UkV

a+?MQ`` 署名

トークン型のデジタル通貨は、乱数をトークンのシリアル番号として用い、シリアル番号に対してトークン発行銀行のデジタル署名を施すことで実現される。
本節では、オブザーバー方式の基本となる a+?MQ`` 署名を説明する。a+?MQ`` 署名は、乗法群上の離散対数問題の困難性に安全性の根拠をもつ方式である。離散対数問題とは、g とh が与えられたときに、x = HQ;g h となる x を求める問題である。つまり、a+?MQ`` 署名は、
公開伴 h に対して、離散対数の解となる秘密伴 x (= HQ;g h) を知っていることの証明であり、x を知らないものによる偽造が困難である。UPFKQiQ- RNNkc SQBMi+?2pH M/ ai2`M- kyyyc
a2m`BM- kyRkc "H/BKibB M/ GvbvMbFv- kyRjV。
なお、システムパラメータとして、素数位数 q の乗法群 G と生成元 g ∈ G が定められ、公開伴の生成元 ; が公開されているほか、署名者は予め秘密伴@公開伴ペア (x, h = g x ) を計算し、公開伴 h を検証者に通知しているものとするjk 。
【署名生成】

Ç 署名者は、秘密伴@公開伴ペア (x, h = g x ) を計算し、公開伴 h を全利用者に通知する。
Ç 署名者は、乱数 w ∈ Z∗q を用いて、a = g w を計算する。
Ç 署名者は、秘密伴 x を用いて、メッセージ m と a のハッシュ値 c = H(m, a) に対し、
r = cx + w を計算する。
Ç 署名者は、(a, r) をデジタル署名として発行する。

jk
本節の演算は基本的に乗法群 G 上で行われるものとする。ただし、加法を含む演算は法 q の有限体 Zq 上
で行う。

Ry

【署名検証】

Ç 検証者は、検証者はメッセージ m とデジタル署名 (a, r) を受信し、ハッシュ値 c = H(m, a)を計算する。
Ç 検証者は、署名者の公開伴 h に対して、g r = hc a が成立することを検証し、秘密伴 xを知りうる署名者によるデジタル署名であることを確認するjj 。

UjVイa+?MQ`` ブラインド署名
ブラインド署名によるデジタル通貨トークンの発行・使用

ブラインド署名とは、署名対象となるメッセージを署名者にみせることなく署名してもらう手法である。ブラインド署名を利用したデジタル通貨では、利用者が生成したシリアル
番号に対する銀行のブラインド署名をトークンとして利用する。発行体である銀行がトークンの元となる情報を発行するが、これを用いた計算により利用者がトークンを構成するため、
トークン情報と元情報との対応関係はトークン発行銀行とトークン償還銀行に対して秘匿される。それゆえ、トークンが匿名性を持つことになる。すなわち、トークンを構成する情報を見ても利用者を特定できない。以下では、トークン発行銀行とトークン償還銀行を区別せず、銀行と呼ぶ。なお、システムパラメータとして、素数位数 q の乗法群 G と生成元 g ∈ G が定められ、公開伴の生成元 g が公開されているほか、銀行は予め秘密伴@公開伴ペア (x, h = g x )を計算し、公開伴 h を全利用者に通知しているものとする。
【トークンの発行（図 8）】Ç 銀行は、乱数 w ∈ Z∗q を用いて a = g w を計算し、利用者に送る。
Ç 利用者は、乱数 u, v ∈ Z∗q を用いて a = au g v を計算する。
Ç 利用者は、c = H(a2`BH, a ) と c = c /u を計算し、c を銀行に送る。なお、a2`BH は利用者が任意に選んだトークンのシリアル番号、H はハッシュ関数とする。
Ç 銀行は、秘密伴 x を用いて r = cx + w を計算し、利用者に送るj9 。
Ç 利用者は、r = ru + v を計算する。
Ç 利用者は、(a2`BH, a , r ) をトークンとして保管する。
【トークンの使用】

Ç 利用者は、店舗にトークン (a2`BH, a , r ) を送信する。

Ç 店舗は、c = H(a2`BH, a ) を計算し、銀行の公開伴 h に対して g r = hc a が成立すれば、トークンを受理する。成立しない場合には、取引を中断する。
Ç 店舗は銀行にトークンを送金する。銀行においても上記検証式が成立することを確認したうえで、トークンに見合いの現金を店舗の口座に入金する。

左辺 = g r = g cx+w = hc a = 右辺。
秘密伴はトークンの金額に応じて用意されている。つまり、A 円分のトークンは xA を用いて生成される。
トークンを受け取った店舗は、hA (= g xA ) を用いて検証することでトークンの金額を確認することができる。
jj
j9

RR

図 8, a+?MQ`` ブラインド署名

a+?MQ`` ブラインド署名（図 8）は、k つの乱数 u, v ∈ Z∗q によって、銀行から見える値(a, c, r) をブラインド（ランダム化）された j つの値 (a , c , r ) に変換する。この変換により、銀行は自分にとって既知の (a, c, r) から (a , c , r ) を特定することはできないj8 。
図 e は銀行から見える値（銀行 oB2r）と利用者が内部で計算する値（利用者 oB2r）の違いを示したものである。銀行 oB2r に現れる変数 (a, c, r) と、利用者 oB2r に現れる変数 (a , c , r )は共に図 e に示した検証式 URV（署名の正当性の検証）を満たす正しい銀行の署名である。しかし、支払いに利用したトークンを特定可能なシリアル番号は銀行 oB2r には含まれない。このため、銀行は償還されたトークンのシリアル番号をみても、どの利用者が使用したものであるかを知ることはできない。利用者 oB2r から得られる署名のみがメッセージ a2`BH への銀行の署名je となり、これがシリアル番号 a2`BH をもつトークン (a2`BH, a , r ) となる。最下段の k つの検証式は、銀行が自らの秘密伴や乱数を用いて署名したものであることを検証する式（左）と、利用者が自ら発行した乱数を用いて銀行の署名をブラインドしたものであることを検証する式（右）に相当する。
銀行 oB2r（x, wを秘密に保持V

a=gc (= c /u)
r = cx + w
w

利用者 oB2r（u, v を秘密に保持Va = au g v (= g uw+v )c = H(a2`BH, a )r = ru + v (=
 (cx + w)u + v)

→
←
→





g r = hc a

g r = hc a∵ g r = (g x )cu g uw+v

URV

図 e, 銀行 oB2r と利用者 oB2r の相違
a, c, r とも Zq の元であることから、いずれも q 通りの値をとる。従って、制約がなければ、(a, c, r) の組
み合わせは最大 q 3 通りの値を取り得る。ただし、a+?MQ`` 署名では、(a, c, r) の変数のうち k つが決まれば図 eに示した検証式 URV により、残りの変数が一意に決まるため、(a, c, r) が取り得る組み合わせは q 2 通りである。
このとき、別の変数 u, v ∈ Zq により、(a, c, r) から (a , c , r ) が全単射で変換されるため、(a , c , r ) が取り得
る値も q 2 通りとなり、検証式を満たす全ての値をとりえる。すなわち、(a, c, r) から (a , c , r ) を特定する情報は得られない。
je
利用者は c ではなく c を u で除した c を銀行に送り、銀行は c をメッセージハッシュ値として署名を生成するため、銀行は a2`BH を特定することができない。なお、c の計算に H(a2`BH, a V のように a をハッシュ計算に加えるのは、プロトコルに従って a を決めてから r を求めさせるため U62B;2- 6Bi M/ a?KB`- RN33V
である。
j8

Rk

(a0 , c0 , r0 )(ab , cb , rb )(a1 , c1 , r1 )(a1−b , c1−b , r1−b) (a1 , c1 , r1 )(a0 , c0 , r0 )URV b = 0 のとき(ab , cb , rb )(a1−b , c1−b , r1−b)

UkV b = 1 のとき

図 d, 匿名性を破れるか否かを試すゲーム
ロ

トークンの使用における匿名性

ここで、銀行（署名者）がトークンから利用者の情報を得ることができるかを考える。具体的には、銀行 oB2r(a, c, r) と利用者 oB2r(a , c , r ) を k つずつ提示し、両者の対応関係を当てるゲームを行う。銀行の正解率が 1/2 より高い場合には、トークンから元の署名の情報が洩れているということであり、銀行がトークンから利用者を特定できる可能性が生じる。
より具体的に説明すると以下のとおりである。銀行は出題者と共にトークン生成プロト
コルを実行し、k つの署名 (a0 , c0 , r0 )- (a1 , c1 , r1 ) を生成する。出題者は、その k つの署名に対応するトークンを銀行に提示するが、提示する順番はランダムに選んだ b ← {0, 1} を用いて
(ab , cb , rb )- (a1−b , c1−b , r1−b) とする。銀行は提示されたトークンを見て、b が 0 であるか 1 であるかを推定する。
図 d に示すように、正解が b = 0 の時は左側のストレートになり、正解が b = 1 の時は右側のクロスの対応になる。前述のように、乱数 u, v ∈ Z∗q により、(a, c, r) は (a = au g v , c =cu, r = ru + v) に写像され、検証式を満たす (a, c, r) の組全体への全単射となる。u, v の値に応じてストレートとクロスのいずれの対応もありえることから、銀行がこのゲームで勝利できる確率は、ランダムな推測確率である 1/2 と僅かな差もつけられない。このことは、銀行がブラインド署名を用いて発行したトークンは暗号学的な意味での匿名性（mMHBMF#BHBiv
や #HBM/M2bb などと言う）が保たれることを意味している。

U9V

追跡可能 a+?MQ`` ブラインド署名

a+?MQ`` ブラインド署名により取引の匿名性を保つことができたが、二重支払いを行った
利用者を特定するためには別途工夫が必要となる。トークンの発行体は利用者に預金口座を提供しており、利用者 A. を管理していると想定できるため、トークン発行時に利用者 A. を埋め込むことで二重支払いを行った利用者を特定することができる。本節で紹介する追跡可能 a+?MQ`` ブラインド署名を利用したデジタル通貨は、取引の匿名性を保ちつつ、上記の課
題を解決したものである U"`M/b- RNNjVjd 。
システムパラメータとして、素数位数 q の乗法群 G と生成元 g, g1 , g2 ∈ G が定められ、(g, g1 , g2 , q) が公開されているほか、銀行は予め秘密伴@公開伴ペア (x, h = g x ) を計算し、公開伴 h を全利用者に通知しているものとする。以下で示すように、生成元 g はトークンの生
成（銀行の署名）に用いられ、生成元 g1 , g2 は二重支払時の利用者の特定に用いられる。

jd

二重支払いの防止については、トークン発行銀行で店舗からの還流（償還）時に過去の利用履歴の確認は可能であるが、店舗段階での確認は本方式では不可能である。次節のオブザーバー方式では、デジタル通貨ウォ
レットのデバイスにおいて検証可能であり、その仕組みを解説する。

Rj【セットアップ】Ç 利用者は、トークンの発行要請ごとに乱数 u1 ∈ Z∗q を選び、I = g1u1 を計算して銀行に送る。
Ç 銀行は、利用者が口座保持者であることが確認できれば、z = (Ig2 )x を利用者に送る。
x は銀行の秘密伴であり、z は利用者 A. を表す Ig2 に対して銀行が発行した利用者証明書である。
【トークンの発行（図 3UV）】

Ç 銀行は、乱数 w ∈ Z∗q を用いて、a = g w と b = (Ig2 )w を計算し、a, b を利用者に送る。
Ç 利用者は、乱数 s, u, v ∈ Z∗q と利用者 A. をブラインドした A = (Ig2 )s を用いてj3 、z  = z s , a = au g v , b = bsu Av を計算する。
Ç 利用者は、乱数 x1 , x2 ∈ Z∗q を用いて、B = g1 x1 g2 x2 を計算する。さらに、c = H(A, B, z  , a , b )と c = c /u を計算し、c を銀行に送る。
Ç 銀行は、秘密伴 x を用いて r = cx + w を計算し、利用者に送る。
Ç 利用者は、r = ru + v を計算する。
Ç 利用者は、(A, B, z  , a , b , r ) をトークンとして保管する。
本方式では、生成元を g とした h = g x を銀行の公開伴とするブラインド署名と、生成元を (Ig2 ) とした利用者証明書である z = (Ig2 )x が銀行の公開共有する暗号伴の生成に用いるデータを伴とみなせることを利用したjN ブラインド署名の k つが登場する。いずれも、ブラインド署名の対象となるメッセージは (A, B, z  , a , b ) であり、そのハッシュ値 c を用いる。

U#V トークンの使用（TvK2Mi）UV トークンの発行（Bbbm2）

図 3, 二重支払時に追跡可能な a+?MQ`` ブラインド署名(Ig2 )s = g1u1 s g2s は、各生成元のべき u1 s と s の比 u1 s/s = u1 を一定に維持したまま、利用者 A. を表す

Ig2 を秘匿する。仮に、(g1u1 g2 )s = (g1u2 g2 )s を満たすような、別の利用者 A. g1u2 g2 に偽装する u2 , s を見つけられたとすると、システムパラメータ g1 , g2 の間の離散対数 HQ;g1 g2 = (u1 s − u2 s )/(s − s ) を求めることができてしまう。これは離散対数問題を破ることになり矛盾である。すなわち、利用者がブラインド後の利用者
A. である A = (Ig2 )s に対して、g1 - g2 のそれぞれのべきである u1 s- s を知っている状態でいるためには、素直に利用者 A. である Ig2 を s 乗してブラインドする以外に方法がないことを意味する。次のステップで計算する B = g1x1 g2x2 と併せて、支払い時に店舗に対して g1 と g2 の生成元のそれぞれで個別に証明させることで、利用者が u1 s- s を知っていることを店舗が検証する。
jN
正確には、銀行は離散対数 x = HQ;g h と離散対数 x = HQ;(Ig2 ) z の k つの値を “知っていること” かつ同
じ値 UxV であることを、x を明かさずに証明（S`QQ7 Q7 EMQrH2/;2）することを利用した k つのブラインド署
名、である。
j3

R9

前者は公開伴 h に対するブラインド署名 (h, a , r )、後者は z  を公開伴にみたてたブラインド。いずれも c と r が共通して
署名 (z  , b , r ) となっている（表 k の二行目利用者 pB2r を参照）
用いられている。ブラインドあり（銀行 oB2r）とブラインドなし（利用者 oB2r）を合わせると、以下の 9 つの検証式が成立する。
表 k, 銀行が発行する k つのブラインド署名
生成元g, 公開伴h 生成元Ig2 , 利用者証明書z
銀行 oB2rg r = hc a
(Ig2 )r = z c b
利用者 oB2r
g r = hc a
Ar = z  c b
表 j, ブラインド署名における銀行 oB2r と利用者 oB2r の対応
銀行 oB2r（x, wを秘密に保持）

z = (Ig2 )xb = (Ig2 )w
c (= c /u)
r = cx + w(Ig2 )r = z c b

利用者 oB2r（s, u, v を秘密に保持）−→z  = z s (= (Ig2 )sx = Ax )

−→
←−
−→

b = bsu Av (= (Ig2 )s(uw+v) = Auw+v )c = H(A, B, z  , a , b )r = ru + v (= (cx + w)u + v)

Ar = z c b
UkV




∵ Ar = A(cx+w)u+v = z cu Auw+v = z c b

【トークンの使用（図 3U#V）】

Ç 利用者は、店舗にトークン (A, B, z  , a , b , r ) を送信する。
Ç 店舗は、乱数 d ∈ Z∗q を利用者に送る。
Ç 利用者は、r1 = d(u1 s) + x1 と r2 = ds + x2 を計算し、r1 と r2 を店舗に送る。
Ç 店舗は、c = H(A, B, z  , a , b ) を計算し、g r = hc a , Ar = z c b （銀行の署名）とg1r1 g2r2 = Ad B （利用者 A. の追跡可能性の証明）が成立すれば、トークンを受理する。
成立しない場合には、取引を中断する。
Ç 店舗は銀行にトークンを送信する。銀行においても上記の署名検証式が成立し、かつ過去に使用されたことのないトークンであることが確認できれば、トークンに見合いの現金を店舗の口座に入金する。
銀行 oB2r における (z, b, c, r) と利用者 oB2r における (z  , b , c , r ) は、いずれも a+?MQ``
ブラインド署名と同じ (c, r), (c , r ) で検証式 UkV を満たすところがポイントである。a+?MQ``
ブラインド署名との違いは、利用者 oB2r における (z  , b , c , r ) が乱数 (s, u, v) でブラインドされている点であり、これにより利用者の A. をランダム推測以上に効率よく推定することはできないようになっている。
【二重支払者の特定】
次に、二重支払いされたトークンが銀行に還流されたとき、その k つのトークンから利用者の A. を特定する手順を説明する。なお、二重支払いでは、同じトークン (A, B, z  , a , b , r )が使用されるが、トークン使用時に店舗から発行された k つの d = d ∈ Zq に対して、検証
式を満たす r1 , r2 , r1 , r2 が発行されている状態となる。ここで、d はトークンが使われた初回

R8

時に店舗で発行された乱数であり、d は同一トークンの二度目の利用において店舗で発行された乱数である。

Ç 銀行は、トークン (A, B, z  , a , b , r ) と、支払いに使用された (d, r1 , r2 ) と (d , r1 , r2 ) を入手する。
Ç 銀行は、u1 = (r1 − r1 )/(r2 − r2 ) を計算し、登録時の I = g1u1 と照合して利用者を特定する。
なお、r1 , r2 , r1 , r2 に対しては、9 つの未知数 u1 , s, x1 , x2 に対して、以下の 9 つの式が Zq上で成立していることから、式を解いて u1 = (r1 − r1 )/(r2 − r2 ) を求めることが可能である。

r1 = d (u1 s) + x1 ,r1 = d (u1 s) + x1 ,r2 = ds + x2
r2 = d s + x2

UjV
U9V

以上により、ブラインド署名により利用者の匿名性を確保しつつ、二重支払いが行われた際には利用者の A. を特定できるスキームが構築できる。しかし、これは不正を働いた利用者の A. を事後的に特定できるというものであり、不正そのものを防止するスキームとはなっていない。できれば、二重支払いを未然に防止できることが望ましい。

U8V

オブザーバー方式の構成

オブザーバーは、銀行から利用者（端末）に供与された耐タンパーデバイスであり、利用者の匿名性を確保しながら、銀行が利用者に求めるルール（ここでは二重支払いの禁止）を遵守させることを目的としている。オブザーバーには、前節までの追跡可能 a+?MQ`` ブラ
インド署名の仕組みに加えて、デバイス中のオブザーバーが関与する署名の仕組みが追加される。具体的には、利用者からトークン発行の依頼を受けた銀行は利用者 A. を埋め込んだトークン（の元になる情報）を利用者に送り返す際に、利用者の A. と利用者のオブザーバーの A. の両方を埋め込む。これにより、支払いの際にオブザーバーの関与が必要となる。さらに、オブザーバーに一度しか支払いに関与しないようプログラムしておくことにより、二重支払いを未然に防ぐことができる。また、万が一、オブザーバーの耐タンパー性が崩れ9y 、オブザーバーの秘密伴が漏洩したことにより二重支払いを店舗が未然に検出することが不可能になったとしても、前出のケースと同様、銀行への償還段階での署名検証により二重支払
いした利用者を特定することは可能である。
システムパラメータとして、素数位数 q の乗法群 G と生成元 g, g1 , g2 ∈ G が定められ、(g, g1 , g2 , q) が公開されているほか、銀行は予め秘密伴@公開伴ペア (x, h = g x ) を計算し、公開伴 h を全利用者に通知しているものとする。
【オブザーバーのセットアップ（図 N）】

Ç 利用者は、乱数 u1 ∈ Z∗q を選び、g1u1 を計算して銀行に送る。
Ç 銀行は、利用者が口座保持者であることが確認できれば、次の手順でオブザーバーをセットアップする。
Ç オブザーバーは、内部で乱数 o1 ∈ Z∗q を選び、AO = g1 o1 を計算して AO を銀行に送る。
Ç 銀行は、I = AO g1u1 を計算し、z = (Ig2 )x を利用者に送る。
Re図 N, オブザーバーのセットアップ。

図 Ry, オブザーバー方式における匿名性と二重支払防止（透明性）の両立【トークンの発行（図 Ry）】

Ç 銀行は、秘密伴 x と乱数 w ∈ Z∗q を用いて、a = g w 、b = (Ig2 )w を計算し、(a, b) を利用者に送る。
Ç 利用者は、乱数 s, u, v ∈ Z∗q を用いて、z  = z s , A = (Ig2 )s - a = au g v - b = bsu Av を計算する。
Ç 利用者は、オブザーバーから B O = g1 o2 を受け取る。なお、o2 ∈ Z∗q は取引ごとにオブザーバーが選んだ乱数である。
Ç 利用者は、乱数 x1 , x2 , e ∈ Z∗q を用いて、B = g1x1 g2x2 · (AO )es B O を計算する。さらに、c = H(A, B, z  , a , b ) と c = c /u を計算し、c を銀行に送る。
Ç 銀行は、r = cx + w を計算し、利用者に送る。
Ç 利用者は、r = ru + v を計算する。
Ç 利用者は、(A, B, z  , a , b , r ) をトークンとして保管する。
9y
耐タンパーデバイスから秘密伴を漏洩させるには前出の onoLX8 等のペネトレーションテストを凌ぐ攻撃を実施しなければならず、通常は困難であると考えられている。

Rd

【トークンの使用（図 Ry）】

Ç 利用者は、店舗にトークン (A, B, z  , a , b , r ) を送信する。
Ç 店舗は、乱数 d ∈ Z∗q を利用者に送る。
Ç 利用者は、乱数 e ∈ Z∗q を生成し、d = s(d + e) をオブザーバーに送る。
Ç オブザーバーは、r1 = d o1 + o2 を利用者に送る。
Ç 利用者は、r1 = r1 + d(u1 s) + x1 と r2 = ds + x2 を計算し、r1 と r2 を店舗に送る。
Ç 店舗は、c = H(A, B, z  , a , b ) を計算し、g r = hc a , Ar = z  c b （銀行の署名の検証）と g1r1 g2r2 = Ad B（トークンの追跡可能性の証明）が成立すれば、トークンを受理する。
成立しない場合には、取引を中断する。
Ç 店舗は銀行にトークンを送金する。銀行においても上記の署名検証式が成立し、かつ過去に使用されたことのないトークンであれば、トークンに見合いの現金を店舗の口座に入金する。
オブザーバー方式は、追跡可能 a+?MQ`` ブラインド署名を応用したものであるが、利用者の A. を表す I の構成が異なる。これは、オブザーバーが生成した情報 AO = g1o1 が I に追加
され、I = g1u1 +o1 の形式となるためである。ここで、u1 は利用者 A. を示す g1u1 の秘密伴であり、o1 はオブザーバー A. を示す AO の秘密伴になっており、k つの A. を合成した I = g1u1 +o1
に関する秘密伴は、利用者とオブザーバーの両者が協力しなければ合成できない構造になっていることに注意して欲しい。これに伴い、下表のように A, B, z  の値も変更される。

I
A
B
z

追跡可能 a+?MQ`` ブラインド署名
g1u1(Ig2 )s = (g1u1 g2 )s
g1x1 g2x2(Ig2 )x = (g1u1 g2 )x

→
→
→
→

オブザーバー方式
AO g1u1(Ig2 )s = (AO g1u1 · g2 )s
g1x1 g2x2 · (AO )es B O(Ig2 )x = (g1u1 g2 · g1o1 )x

トークン受領時における店舗側の検証式は、次のように確認できる。
r  +d(u1 s)+x1 ds+x2
g2
(d o +o ) d(u s)= g1 1 2 g1 1 g2ds g1x1 g2x2
= (AO )d B O (g1u1 )ds g2ds g1x1 g2x2= (AO )s(d+e) B O (g1u1 )ds g2ds g1x1 g2x2= (AO g1u1 g2 )ds (AO )se B O g1x1 g2x2
d

g1r1 g2r2 = g11

=A B

U8V

【二重支払者の特定】

Ç 銀行は、トークン (A, B, z  , a , b , r ) と、支払いに使用された (d, r1 , r2 )、および新たな支払いに使われようとしている (d , r1 , r2 ) を入手する。
Ç 銀行は、o1 + u1 = (r1 − r1 )/(r2 − r2 ) を計算し、g1u1 +o1 とセットアップ時の I = AO g1u1と照合して利用者を特定する。
R3

二重支払いの際には、追跡可能 a+?MQ`` ブラインド署名と同様、
R つのトークン (A, B, z  , a , b )に対して、k つの店舗による k つの異なるチャレンジ d, d に対応する以下の値 (r1 , r2 )- (r1 , r2 )が銀行に還流してくることから、下記 k つの式により、o1 + u1 = (r1 − r1 )/(r2 − r2 ) が計算できる。これを使って g1u1 +o1 を求めることにより、セットアップ時の I = AO g u1 と照合して利用者を特定することができる。

r1 = s(d + e)o1 + o2 + d (u1 s) + x1 ,r1 = s(d + e)o1 + o2 + d (u1 s) + x1 ,r2 = ds + x2
r2 = d s + x2

UeV
UdV

上記のとおり、オブザーバー方式は、耐タンパーデバイスを利用者端末に搭載させることで、RV 利用者に二重支払いさせないよう強制するほか、kV 仮に耐タンパー性が崩れて二重支払いが行われたとしても、A. の追跡が可能なスキームになっている。仮に、銀行が不正なオブザーバーを導入し、利用者の A. を不正に特定しようとしても、オブザーバーの oB2r と店舗の oB2r は完全に切り離されていることから、オブザーバーの oB2r から支払先を特定するこ。すなわち、利用者の匿名性は、利用者が端末を適切に運用するとはできない（図 Ry 参照）
限り暗号学的に保護される。

9

実行証跡付セキュアプロセッサによる柔軟な匿名性・透明性

前節で整理したオブザーバー方式は、デジタル通貨の二重支払いを行わないよう利用者の行動を強制する方式であった。これに対し、本節で紹介する実行証跡付セキュアプロセッ
サ USbb- a?B M/ h`Kû`- kyRdV は、任意のプログラムを耐タンパーデバイスで実行させる方式に関する理論である。近年、h11 などの隔離実行領域が利用可能になってきたことや、:S@a1 や hSJ（h`mbi2/ SHi7Q`K JQ/mH2）などのプログラマブル・セキュアエレメントが普及してきたことを受けて、それらの安全性を学術的に取り扱うために整備された。

URV
イ

概要
仮定

実行証跡付セキュアプロセッサについては、最新の耐タンパーデバイスに一定の仮定をもたせることで、後述の「内部記憶を持つプログラムの難読化」を実現可能であることが証明されている USbb- a?B M/ h`Kû`- kyRdV。これは既存の h11 や :S@a1 を実行証跡付セキュアプロセッサと見做すことができれば、銀行がオブザーバーを難読化ソフトウェアとして配布し、利用者が自分のデバイスにダウンロードして実行することで、銀行が要請する二重支払防止機能を利用者のデバイスで確実に実行させることができることを示している。本節では、実行証跡付セキュアプロセッサに求められる仮定について述べる。

RX 耐タンパー性を有するセキュアプロセッサが端末に具備されている。
耐タンパー性は、サイドチャネル攻撃等の非侵襲型攻撃や、リバースエンジニアリング
やフォールトインジェクション攻撃等の侵襲型攻撃に対して、内部に保存された暗号伴や機密情報を外部に漏洩しないという性質である。理論的に安全な構成方法は知られてRN

いないが、現実的には、6ASa R9y9R や ** 認証（AaPfA1* R89y3）における onoLX8等の網羅的なペネトレーションテストを通過したものを「耐タンパー性を有する」と呼ぶことが多い。

kX セキュアプロセッサにアクセス可能なプログラム／デバイスが限定されている。
セキュアプロセッサは内部にホワイトリスト `2; を持ち、セキュアプロセッサにアクセス可能なプログラム／デバイス P を識別する機能があると仮定する USbb- a?B M/h`Kû`- kyRdV。具体的には、k 節 UkV ロ で述べたコード署名が付されたスマートフォ
ンアプリおよびスマートフォンデバイスが P に、_@* に登録されたコード署名検証
用の公開伴データの集合が `2; に該当する。

jX 外部からプログラムを導入でき、実行結果には必ず証跡（ii2biiBQM）が付与される。
本仮定は、実行証跡付セキュアプロセッサに特有のものとなる。現在の h11 や :S@a1
等の多くのセキュアプロセッサは外部からプログラムを導入可能である。また、これらのセキュアプロセッサが必ずしも実行結果に証跡を付与しているとは限らないが、導入するプログラムの構成を工夫することで容易に証跡（実行証跡、実行結果に対する
デジタル署名）を付与することができる USbb- a?B M/ h`Kû`- kyRdV。

9X 匿名で実行証跡が付与される（MQMvKQmb ii2biiBQM）。
前述の実行証跡は、セキュアプロセッサに関する匿名性を保った状態で署名できることを仮定する。すなわち、実行証跡からセキュアプロセッサを特定することはできな
いと仮定する。現実には、不正なデバイスによる実行証跡を特定できるよう失効リスト（`2pQ+iBQM HBbi）を配布することが求められるため、セキュアプロセッサの匿名性についてはより詳細な議論が必要である。AMi2H a:s 等では特殊なグループ署名 U"`B+F2HH
M/ GB- kyRyV を導入し9k 、実行証跡の匿名性と不正デバイスが出力した実行証跡の失効を両立させる方式を実装している。ここでは議論を単純化するために、全セキュア
プロセッサが共通の公開伴 KTF と秘密伴 KbF を共有し、デジタル署名に用いた伴からセキュアプロセッサを特定できないと仮定し、不正デバイスの追跡等には言及しないこととする。
実行証跡付セキュアプロセッサの仮定は、特に RX と kX が強い仮定となるが、市場に広く普及している h11 や :S@a1 などのデバイスは k 節 UkV ロ で述べたように安全性や機能面の拡張が進んで来ており、十分とは言えないまでも、実行証跡付セキュアプロセッサに必要な仮定をほぼ満たしている。
ロ

理想機能

上記を仮定した際に想定される実行証跡付セキュアプロセッサの理想機能 Gii を定義する。ここで、Σ は仮定 jX と 9X に対応するデジタル署名アルゴリズムであり、署名生成用の伴9R

6ASa は 62/2`H AM7Q`KiBQM S`Q+2bbBM; aiM/`/b の略。6ASaR9y は、米国連邦政府の暗号モジュールが満たすべきセキュリティ要件を記載した政府調達基準。
9k.B`2+i MQMvKQmb ii2biiBQM（.）U"`B+F2HH- *K2MBb+? M/ *?2M- kyy9V もしくは 1M?M+2/ S`Bp+v
A.（1SA.）U"`B+F2HH M/ GB- kyRyV と呼ばれ、活発に研究されている。. や 1SA. はグループ署名の一種である。特定グループの誰かが署名したことは確認できるが、誰かは特定できないというグループ署名の標準的な特徴に加え、グループ署名の管理者であっても署名から署名者を特定できないという性質を有する。この性質により、チップ製造者であってもプライバシーを侵害できない。

kyKbF によるメッセージ m の署名は Σ. aB;MKbF (m) と表される9j 。また、`2; は、Gii を使用可
能なプラットフォーム P の全体集合 UP ∈ `2;V と定義する99 。
Gii は以下の 9 つのインターフェイスを持つ（図 RRUV）。最初の k つはどのプラットフォー
ムでも利用可能なインターフェイスだが、残りの k つは特定のプラットフォーム P ∈ `2; のみが利用可能な制限されたインターフェイスである。
RX 初期化 BMBiBHBx2
実行証跡に用いるデジタル署名の秘密伴と公開伴のペア (KbF, KTF) を生成し、内部記
憶 T を空集合 ∅ に初期化する。

kX 署名検証伴の取得 ;2iTF()
実行証跡の署名検証用の伴 KTF を出力する。

jX プログラムの登録 BMbiHH(idx, T`Q;) 7`QK bQK2 P ∈ `2;
プログラム T`Q;98 を実行証跡付セキュアプロセッサに登録し、T`Q; に固有のメモリ空間
K2K を割り当てる。T`Q; を登録する際のセッション A. である idx に対して、(idx, T`Q;K2K) の組をエンクレーブ（2M+Hp2）と呼ぶ。エンクレーブの識別子 eid をランダムに生成し、プラットフォーム P 毎に区別して内部記憶 T に登録する。
−→
T [eid, P] := (idx, T`Q;, 0 )9X プログラムの実行 `2bmK2(eid, BMT) 7`QK bQK2 P ∈ `2;eid- P で指定されるエンクレーブに格納された T`Q; を、入力 BMT に対して実行し、その結果 QmiT を以下の形式の実行証跡として出力する。
(idx, eid, T`Q;, QmiT, σ)
ここで σ は実行証跡付セキュアプロセッサの実行証跡であり、以下のデジタル署名ア
ルゴリズムで計算される。

σ ← Σ. aB;MKbF (idx, eid, T`Q;, QmiT)
実行証跡付セキュアプロセッサが実行されると、その実行結果には必ず QmiT とそのデジ
タル署名 σ が含まれる。デジタル署名により、QmiT が実行証跡付セキュアプロセッサ Gii で実行されたことが第三者によって検証可能となる。
9j
デジタル署名アルゴリズム Σ は存在的偽造不能性（1l6@*J）を満たすと仮定している。存在的偽造不能性は、デジタル署名に関する最強の安全性である。具体的には、セキュリティパラメータ（例えば伴長など）の多項式で表される実行ステップ数に制限された（署名用の秘密伴を知らない）攻撃者が、自由に選んだメッ
セージの署名を得られる条件下（署名オラクルへのアクセスが許される条件下）で、署名検証用の公開伴の情報と多数のメッセージと署名の組から得られる情報を用いて、それらに含まれない新しい署名を自らの力で偽造できる確率が無視できるほど小さいという性質を言う。また、署名検証アルゴリズム Σ. o7KTF (σ) は署名検証伴（公開伴）KTF による署名 σ の検証式を表し、署名が正しければ R を出力し、そうでなければ y を出力する。
99
a:s 等が搭載された S* や M/`QB/ 端末等で実行される一般のプログラムをプラットフォーム P と呼ぶ。
実用上は、k 節 UkV ロ．で述べたコード署名とアクセス制御機構でアクセス許可された正規アプリケーションプ
ログラムがプラットフォーム P に対応し、正規アプリケーションプログラム全体の集合が `2; に対応する。
98
セキュアプロセッサ内で実行するプログラム。h11 ではそれぞれのプロセッサ用のバイナリコードであり、:S@a1 等の耐タンパーデバイスでは Cp アプレットが想定される。

kR

UV 実行証跡付セキュアプロセッサの理想機能 Gii

U#V T`Q;Q#7 の機能

図 RR, 実行証跡付セキュアプロセッサの理想機能 Gii と内部記憶を持つプログラムの難読化

kk

UkV
イ

内部記憶のあるプログラムの難読化（aii27mH P#7mb+iBQM）
概要

難読化 U"`F 2i HX- kyyRc :QH/rbb2` M/ _Qi?#HmK- kyydV とは、与えられたプログラ
ムを、解析が困難なプログラムに変換することである。理想的に難読化されたプログラムは、
手元のプロセッサで実行されているにも関わらず、あたかもブラックボックスの中で計算されているかのように、内部の計算過程からは何も有益な情報が得られない。そのため、攻撃者はブラックボックスの外部から観測できる入力と出力だけから内部の処理を推定する外ない状況に置かれる。このような性質を達成する理想的な難読化を、仮想ブラックボックス難読化 U"`F 2i HX- kyyRV と呼ぶ。仮想ブラックボックス難読化されたプログラムによる計算
は、手元のプロセッサで実現できる秘密計算になっている。
例えば、プログラム内部に伴がハードコードされているケースについて、入力された暗号文を内部で復号し、復号されたデータを用いて行った計算結果を再暗号化して出力するプロ
グラム f を考える。入出力は暗号化されているため、適切な暗号化アルゴリズムが用いられていれば、入出力からは秘密計算の内容を推測することは困難である。しかし、内部の計算過程がホワイトボックスで、f のプログラムコードにアクセスできる攻撃者であれば、伴を抽出することで内部で行われている処理を知ることができる。仮想ブラックボックス難読化が実現できれば、f の内部処理がブラックボックス化されることにより、内部にハードコー
ドされた伴が取り出されないことが保証され、プログラム f は安全に秘密計算される。
さらに、内部記憶を持つプログラムの難読化とは、データベースのように内部に記憶を持つプログラムに、難読化の概念を拡張したものであり、内部記憶とプログラムコードの両方にアクセスできる攻撃者に対しても、入出力から得られる以上の情報を攻撃者に与えないものをいう。前述の秘密計算は、内部に記憶を持たない関数的な計算を想定していたが、内部記憶を持つプログラム（以下、履歴依存プログラム）の仮想ブラックボックス難読化は、内部にデータベース等の記憶を持ち、入力履歴に応じて出力値が変化するタイプのプログラ
ムに対しても、プログラムにハードコードされた伴や内部記憶の内容を取り出されることなく、あたかもブラックボックス内部で実行されているかのように攻撃者から見える難読化を指す。
仮想ブラックボックス難読化は、ソフトウェアのみでは実現できないことが理論的に証明されている U"`F 2i HX- kyyRV。そのため、難読化の定義を緩和したり、破壊できない耐タンパー技術があると仮定を追加するなどの対応により達成可能な難読化を模索している U例
えば、:QH/rbb2` M/ _Qi?#HmK- kyydV。
ロ

内部記憶を持つプログラムの難読化の構成

サーバ S とクライアント C がそれぞれ Gii を具備している状況を考える。C が履歴依存プログラム f を難読化して S に送付し、S に f を実行させる状況を想定する。目標は、S に
f の入出力から得られる情報以上の情報を与えないことである。
難読化の構成は、図 Rk に示すように（）登録と（#）実行の二段階に分かれている。図
Rk に記載している T`Q;Q#7 の各関数を集約したものが図 RRU#V であり、この T`Q;Q#7 を S のGii に BMbiHH することで、任意の履歴依存プログラム f の難読化が実現される。
（イ）難読化した履歴依存プログラム f の登録 S に対する f の難読化は、C と T`Q;Q#7 間で伴を共有し、共有した伴で関数 f を暗号化して送信のうえ、T`Q;Q#7 に登録されることで実施される。関数 f の登録の処理は、大きくわけると、S の Gii に T`Q;Q#7 をインストール（以kj下の R ∼ j ）、C と T`Q;Q#7 間での暗号伴 sk の共有（以下の 9 ∼ 8 ）、sk による f の暗号化とT`Q;Q#7 への送信（ e 、 d ）、T`Q;Q#7 における f の登録（ 3 ）からなる。
R Gii から C に難読化実行のメッセージを送信：利用者は、自分の端末（C ）内の理想機

能（Gii ）を起動し、Gii から（C にインストールされている）S と交信するためのア
プリに対して、「関数 f を難読化せよ」とのメッセージ ( “Q#7mb+i2” , f ) を送信する。C
内のアプリがこのメッセージを受け取ると、a ∈ Zp とセッション識別子 sid ∈ Z をランダムに生成する9e 。

k S と共有する暗号伴の生成に用いるデータを送信：C から S に sid と「g a を入力として伴交換せよ」とのメッセージ (sid, ( “F2v2t” , g a )) を送信する。

j S の Gii に T`Q;Q#7 をインストール：S に具備された実行証跡付セキュアプロセッサで−→ある Gii で BMbiHH(sid, T`Q;Q#7 ) を実行する。これにより、Gii 内部に 0 に初期化さ−→れたメモリ領域が確保され、エンクレーブ (sid, T`Q;Q#7 , 0 ) が生成される。このエンク
レーブに対応する識別子 eid がランダムに生成され、サーバ S が利用可能なエンクレー
ブとして、Gii の記憶領域 T に登録される。
−→
T [eid, S] := sid, T`Q;Q#7 , 0

9 T`Q;Q#7 によって暗号伴の生成に用いるデータと実行証跡を C に送信： S の Gii 間で`2bmK2(eid, ( “F2v2t” , g a )) を実行すると、Gii のエンクレーブ処理で T`Q;Q#7 ( “keyex” , g a )が実行される。T`Q;Q#7 は、入力 ( “F2v2t” , g a ) が与えられると、内部で乱数 b ∈ Zp を生成し、.B{2@>2HHKM 伴
sk := (g a )bを計算して内部に記憶（biQ`2）し9d 、(g a , g b ) を出力する93 。この値には Gii による実行証跡として署名 σ が施され、計算に用いた T`Q;Q#7 や sid, eid と共に以下の形式で出
力される。

 

sid, eid, T`Q;Q#7 , g a , g b , σ
U3V

8 Gii から実行証跡を検証する伴を入手：C は実行証跡を検証するために、C の Gii から

検証伴 KTF を取得する。
e 実行証跡を検証し関数を暗号化：KTF を用いてステップ 9 で出力される実行証跡 σ を検証し、 R で生成した a を用いて .B{2@>2HHKM 伴

sk := (g b )aを計算する。これにより、T`Q;Q#7 と C の間で .B{2@>2HHKM 伴 sk (= g ab ) が共有できる。C は、伴 sk を用いて履歴依存プログラム f の暗号文 ct = 1.1M+sk (f ) を作成する。なお、1.1M+sk (f ) は、秘密伴 sk による f の暗号化関数である。
9e

セッション識別子は、プラットフォームが複数の同一プログラムをインストールする場合に、それらを互いに区別するために用いる。
9d
T`Q;Q#7 内部で記憶（biQ`2）された sk は、Gii の変数 K2K の更新として出力され、記憶領域 T に保存される。
93 a b(g , g ) の一方の g a は C の作成した公開伴、他方の g b は T`Q;Q#7 側で作成した公開伴である。ステップ
9 では T`Q;Q#7 が .B{2 >2HKM 伴 sk = (g a )b を計算したが、ステップ e でも C が持つ a と g b を併せて、同
じ .B{2 >2HKM 伴 sk = (g b )a を計算し、両者の共有伴とする。

k9

d 暗号化した関数を送信：C は、S に、( “Q#7mb+i2” , ct) を送信する。
3 T`Q;Q#7 において関数を登録：S が `2bmK2(eid, ( “Q#7mb+i2” , ct)) の実行を Gii に指示すると、T`Q;Q#7 にメッセージ ( “Q#7mb+i2” , ct) が送信される。T`Q;Q#7 内部では、伴 sk
を用いて ct から f が求められ、(f, bi := ⊥) が格納される。ここで bi は履歴依存プロ
グラム f の内部記憶であり、この時点でメモリ領域が確保され、初期値として未定義
値 ⊥ を想定している。問題がなければ PE を出力する。bi の値は K2K に代入され、Giiの記憶領域 T に保存される。f の出力である PE には署名 σ が付され、計算に用いた
T`Q;Q#7 や sid, eid と共に以下の形式で出力される。また、この出力は C に送信される。

(sid, eid, T`Q;Q#7 , PE, σ)UNV（ロ）難読化した履歴依存プログラム f の実行
R C から S に「x を入力として計算せよ」とのメッセージ ( “+QKTmi2” , x) が届くと、Giiの `2bmK2(eid, ( “+QKTmi2” , x, ⊥)) を起動し、eid で指定されたエンクレーブを使って
f (x, ⊥) の計算9N を要求する。

k Gii は eid に対応する T`Q;Q#7 を T から取り出し、T`Q;Q#7 に ( “+QKTmi2” , x, ⊥)) メッ

セージを送る。T`Q;Q#7 は以下の式を実行し、出力 y と更新後の状態 bi を得る。

(y, bi ) = f (x, bi)
T`Q;Q#7 の出力は実行証跡 σ と共に以下の形式で表され、Gii の QmiT に反映される。
(sid, eid, T`Q;Q#7 , y, σ)

URyV

また、更新後の状態 bi は Gii の K2K に出力され、記憶領域 T に保存される。
以上から、実行証跡付セキュアプロセッサの機能として Gii が実現されていれば、以下が達成できることが示される。

RX Gii に導入したプログラム（例えば T`Q;Q#7 ）との間に、.B{2@>2HHKM 伴共有等によりセキュアチャネルを構築できる8y 。
kX プログラムはオープンソースプログラムでも良い（T`Q;Q#7 はオープンソースの例）。
前項 R の性質より、オープンソースで配布したプログラムであっても、後から実行証跡を確認することで、セキュアチャネルを構築できる。そのため、デジタル通貨ウォ
レットやマイナンバーカードによる個人認証のためのプログラムをオープンソースで配布しておけば、利用者は手元にある実行証跡付セキュアプロセッサを用いてプログ
ラムを導入することができる。オープンソースであれば、プログラム機能が多くの人の目に触れることから、実行証跡付セキュアプロセッサ内部で実行されているプログ
ラムの動作への信頼を確保しやすいというメリットもある。
ここで、⊥ は証明で用いるために技巧的に導入された入力で、y = ⊥ を入力すると y = f (x, y) のように、
第 k 入力の y がそのまま f の出力となる。ここでは詳細を割愛する。
8y
実行証跡付セキュアプロセッサでは、Gii の実行証跡を確認することにより、T`Q;Q#7 の生成した伴であることを外部から確認できる。実行証跡付セキュアプロセッサを用いない一般的な構成では、プログラムを A*
カード等に組み込んで、A* カードの中に伴を入れて配布するなどの手順を踏む必要がある。
9N

k8

jX オープンソースプログラム T`Q;Q#7 を介して、任意の履歴依存プログラム f を難読化して Gii に実行させることができる。
実行証跡付セキュアプロセッサをベースに画期的な機能や性能を実現する研究も現れている。例えば、1FB/2MU*?2M; 2i HX- kyRNV は、実行証跡付セキュアプロセッサを用いて、
1i?2`2mK のスマートコントラトの実行状態の秘匿を達成し、同時にスループットを数百倍に向上させている。これにより、資産残高や企業秘密を秘匿したスマートコントラクトを実現できる。1FB/2M では、実行証跡付セキュアプロセッサの内部状態を暗号化してブロック
チェーンに掲示することで、実行証跡付セキュアプロセッサ間での内部状態の共有を実現するといった興味深いアイディアが提案されている8R 。
また、これまでの節で紹介したデジタル通貨ウォレットやオブザーバーは、Gii のオープ
ンソースプログラムとして実現できる。以下の節では、実行証跡付セキュアプロセッサの機
能 Gii を利用して匿名性と柔軟な透明性を実現する方式について述べる。

8R

更新後の内部状態が暗号文されてブロックチェーンに掲載されていることを S`QQ7 Q7 Sm#HB+iBQM と呼ばれる手法で実行証跡付セキュアプロセッサに検証させ、受理された時のみ、次の状態更新を許可することで、一貫性を保つ形で共有状態を実現している。

ke

kd

k3
[>6?QL# oW



図 Rk, Gii を用いた内部記憶を持つプログラムの難読化の構成 C ೉ಡԽͨ͠ཤྺґଘϓϩάϥϜG ͷ࣮ߦ

K/! o(/! oBF>-\  o

:o D$$0V$o E%HR8%o&1 2o ;@I1 @E<+ 8%8 oo &1 ooo8%8o<RO@ o8%8 o@E<+2;@
&1 ooo I1 o@E<+ o8%8 o^lmn 3, 4I1 &o 1 @o E<+ <o RO@odafbegchk

C"GP7"o(/! o>6?QL# oW K/! o(/! oBF>-\* Z U  

 B ೉ಡԽͨ͠ཤྺґଘϓϩάϥϜG ͷొ࿥ O `j_i]0)o Yo N.$:o D$NTD:o Yo$5J$oY HO oo X HO o
HOo HOo
D$NTD:o Yo :o D$$0V$o =9ASM' Xo Yo  o



UjV

実行証跡付セキュアプロセッサによる匿名性と透明性の両立

これまで見てきたように、実行証跡付セキュアプロセッサの理想機能として定義される
9 つのインターフェイス（初期化,BMBiBHBx2、署名検証伴の取得,;2iTF、プログラムの登録,BMbiHH、プログラムの実行,`2bmK2）を耐タンパーデバイスに実装するだけで、オープン
ソースプログラムとの伴共有、履歴依存プログラムの仮想ブラックボックス難読化といった、非常に強力なセキュリティ機能を耐タンパーデバイスに持たせることができる。これらの機能を利用すれば、プログラムの形でさまざまな社会的ルールを柔軟に実装できるため、匿名性と JGf*6h 等の透明性を両立するデジタル通貨の技術基盤を担うことができると考えられる。
その実現例として、実行証跡付セキュアプロセッサを用いてオブザーバー方式を拡張したデジタル通貨の構成例を図 Rj に示し、その実行シーケンス例を図 R9 に示す。この構成は以下の特徴を持つことを想定している。

RX ウォレット T`Q;W 及びオブザーバー T`Q;O はオープンソースで配布され、利用者や店舗が信頼するプログラムを選択して利用する。
kX T`Q;O 、T`Q;W は Gii に BMbiHH して実行証跡付セキュアプロセッサ内で実行される。
jX 実行結果には、プログラム名と共に実行証跡として匿名のデジタル署名（.、1SA.
等）が施される。ただし、二重支払等のルール違反が発覚した場合には、当該デバイスの発行するデジタル署名の匿名性が解除する伴が公開され、当該デバイスから支払われたデジタル通貨はこの伴を用いて違反デバイスを特定することにより銀行や店舗で受け取りを拒否できるとする。
9X T`Q;O は二重支払いの防止等の安全性と透明性等の社会要請8k を守ることを主目的とする。
8X T`Q;W は利用者の資産とプライバシー8j 等の利用者の権利を守ることを主目的とする。
実行証跡付セキュアプロセッサの製造や供給は少数の企業や場合によっては政府機関に限られることが想定される。こうした製造者・供給者は、利用者の資産やプライバシーを操作する権限を持つ可能性があることから、実行される機能に対する信頼を確保することが極めて重要である。例の構成では、Gii の機能を用いてウォレット T`Q;W 及びオブザーバー T`Q;Oをオープンソースで公開可能とすることで、実行される機能の信頼の確保を試みている。
T`Q;W は k 節（k）で述べた伴管理機能や、紛失／盗難時の対応、生体認証機能、quaAqua
機能などを備えた基本的なデジタル通貨ウォレット機能を達成するプログラムを想定している。これに対して、T`Q;O は監督当局が求める透明性を匿名支払条件として組み込んだプロ
グラムであり、取引毎に匿名支払条件を満たすか否かの判定を実施し、条件を満たさない場
合は当局への報告などの必要な義務を履行させることを想定している。すなわち、オブザー
バー方式のように、二重支払いを未然に防ぐ機能に限定することなく、匿名支払条件を自由に T`Q;O にプログラムし、匿名支払条件を満たす時に限り支払プロトコルに協力するように条件を拡張することを考える89 。
8k

監督当局が、使用可能なオープンソースプログラムを複数認定し、そのリストを事前に公開していることを想定している。
8j
取引の相手や内容に関するプライバシーは、T`Q;O に対しても秘匿することが望ましい。
89"`M/b らのトークン型デジタル通貨 U"`M/b- RNNjV をベースに議論を進めてきたが、実行証跡付セキュ

kN

図 Rj, 実行証跡付セキュアプロセッサによる柔軟な匿名性と透明性のバランス（構成例）

図 R9, 実行証跡付セキュアプロセッサによる柔軟な匿名性と透明性のバランス（シーケンス例）jy例として、Ryy 万円以上の国際送金では支払者 A. の報告を必要とする条件を想定する。すな
わち、Ryy 万円未満もしくは国内送金である取引は匿名で実施し、条件を満たさない場合は監督当局への報告を義務化するケースを考える88 。ただし、T`Q;O が取引内容に直接アクセス可能な
場合は匿名支払条件の判定は自明だが、プライバシー保護の観点から、T`Q;O に全ての取引内容を開示することは望ましくない。そこで下記プロトコルでは T`Q;O が「支払金額 < 100万円」
や「支払相手 ∈ 国内居住者」などの匿名支払条件を満たすか否かの証明を利用者や店舗のT`Q;W に対して要求し、対応する T`Q;W が条件の成立／不成立のみをゼロ知識証明で伝える構成としている。同様に、店舗 S も T`Q;W  - T`Q;O を Gii にインストールしており、T`Q;W 
は S の資産／プライバシーを保護することを目的にプログラムされており、T`Q;O は S がルールを遵守して虚偽の証明を行わないことを監視していると想定している。例では、国内居住者でないことを証明するにあたり、T`Q;W  による非居住証明に T`Q;O が協力する様子を示している8e 。
匿名支払条件を満たす場合は、オブザーバー方式によるプロトコルに従って支払を実行する。匿名支払条件を満たさない場合は、T`Q;W に対して監督当局への報告を要求する。その際、T`Q;W は取引内容を監督当局に報告し、監督当局から報告済みであることの証明書（報告証明）を取得して T`Q;O に提示する。これを受けて T`Q;O がプロトコル実行に協力し、国際。
送金が実行される。具体的なプロトコルのシーケンス例は以下のとおりである（図 R9 参照）

Ç 店舗 S は、利用者 C に Rky 万円を請求する。
Ç 利用者 C は、T`Q;W に Rky 万円の支払いを指示する。
Ç T`Q;W は、追跡可能 a+?MQ`` ブラインド署名により Rky 万円のトークン (A, B, z  , a , b , r )を生成し、トークン、T`Q;W 、実行証跡 σ を T`Q;W ʼ に送信する。T`Q;W ʼ は、乱数 d、T`Q;W 、実行証跡 σ を T`Q;W に返信する。
Ç T`Q;W は、T`Q;O に乱数 dʼ 、T`Q;W 、実行証跡 σ を送信する。
Ç T`Q;O は T`Q;W に対して、支払金額が Ryy 万円未満であること、もしくは支払相手が国内居住者であることの条件を満たしているか否かの証明を要求する。
Ç T`Q;W は支払い金額が Ryy 万円未満でないことをゼロ知識証明で示す。
Ç T`Q;W は T`Q;W ʼ に対し、支払相手となる店舗 S が国内居住者であるか否かの証明を要求する。
アプロセッサに内蔵するプログラムは、様々なデジタル通貨方式に合わせて設計できるため、ブロックチェーン
上で実装される分散台帳をベースとするデジタル通貨に対しても適用可能であると見られる。例えば、高橋ら
は、実行証跡付セキュアプロセッサに基づいて非中央集権型ブロックチェーン上で転々流通性を持つマイクロペイメント（Ryy 円以下の少額決済を実現する電子決済技術。ブロックチェーンでは取引をブロックチェーンに登録するために相対的に高額な手数料が必要となるため、複数の決済をまとめて登録する技術や確率的に少数の決済のみを選択して登録する技術などが提案されている）を実現している UhF?b?B M/ PibmF- kykRV。
88
利用者と店舗がそれぞれ T`Q;W - T`Q;O を公開プログラムから選択して、それぞれの端末の Gii にインストールしている状況を想定する。利用者と店舗の T`Q;W , T`Q;O を区別するため、店舗がインストールしたプログラムを T`Q;W  , T`Q;O と表記する。本来、これらは同一種類のプログラムである必要はなく、それぞれが任意に公開プログラムから選択してインストールすると仮定すべきであるが、その際には互いに相手のプログラムがルールに沿ったものであるか否かを検証する必要が生じ、複雑になるため本節では単純化して、同一種類の T`Q;W 、T`Q;O がインストールされていると想定する。
8e
国内非居住者であることの証明には、住民票等の公的機関が発行した検証可能証明書（o2`B}#H2 *`2/2MiBH）
が必要だが、検証可能証明書は多くのプライバシー情報を含むため、本人を特定できない形で非居住者であるという事実だけを証明する属性証明書あるいは派生証明書（.2`Bp2/ *`2/2MiBH）だけを提示することが望ましい。このためには、派生証明書が検証可能証明書から正しく作られたことを保証する仕組みが必要であり、その仕組みについては自己主権型アイディンティティ（a2H7@aQp2`2B;M A/2MiBiv）等の概念で盛んに研究されている。実行証跡付セキュアプロセッサに基づく構成法については UJQ`BvK M/ PibmF- kykk-#V 等の研究
がある。

jR

Ç T`Q;W ʼ は T`Q;O に店舗 S が国内居住者でないことをゼロ知識証明で示す。
Ç T`Q;O は匿名支払条件を検査する。
Ç T`Q;O は T`Q;W に当局への報告を指示する。
Ç T`Q;W は報告証明の取得を行う。
Ç T`Q;W は T`Q;O に報告証明、T`Q;W 、実行証跡 σ を送付する。
Ç T`Q;O は T`Q;W に乱数と実行証跡を送付する。
Ç T`Q;W は T`Q;W ʼ に k つの乱数 (r1 , r2 )、T`Q;W 、実行証跡 σ を送付する。

8

まとめ

本稿では、デジタル通貨の安全性のほか、匿名性と透明性の両立についてウォレット技術の最新動向から概観した。具体的には、まず、スマートフォンに搭載されている耐タンパー
デバイスを活用して、デジタル通貨の保管や移動に必要となるデータの保護と、取引実行時における本人意思の確認を行う方法について整理を行った。A* カードやコールドウォレット
は、利用時のみ S* 等と接続して利用することから、ネットワークに接続していない限りサイバー攻撃を受けるリスクはないが、スマートフォンや S* 端末に内蔵された耐タンパーデ
バイスは常時インターネットに接続されている状態であり、耐タンパー性を維持するための対策が求められる。近年は、プログラム可能な耐タンパーデバイスがスマートフォンや S*
端末等を中心に広く普及しており、デジタル通貨のウォレットとしての活用が大いに期待されるところである。
さらに、こうした耐タンパーデバイスを用いて二重支払いを未然に防止するオブザーバー
方式を紹介したうえで、近年提案された実行証跡付セキュアプロセッサを用いたデジタル通貨スキームを提案した。オブザーバー方式は、二重支払いが行われたときにのみ利用者を特定可能にするという、固定されたアルゴリズムを前提とした方式であった。デジタル通貨ス
キームに対する JGf*6h 等の社会要請を踏まえれば、より柔軟な透明性を実現できることが望ましい。もちろん、社会要請を満たす透明性条件を明確に定義できれば、今後の研究の進展によって、匿名性と透明性を両立する技術について、社会的に合意の取れた技術が出現する可能性は残されている。
本稿で紹介した実行証跡付セキュアプロセッサは、耐タンパー技術に関する強い仮定を必要とするものの、導入するプログラムの特徴を柔軟に設計することで多様な Jhf*6h 対応ルールをオブザーバーに設定できることから、各種の匿名デジタル通貨に透明性を導入でき、社会的に合意のとれた匿名デジタル通貨システムの構築に道を拓くものである。本稿の議論が、デジタル通貨の発展の一助となれば幸甚である。

jk

参考文献
#2- JbvmFB M/ JBvFQ P?Fm#Q UkyyRV ǳS`Qp#Hv a2+m`2 6B` "HBM/ aB;Mim`2b rBi?
hB;?i _2pQ+iBQM-Ǵ BM /pM+2b BM *`vTiQHQ;v @ aA*_uSh kyyR- oQHX kk93 Q7 G2+im`2
LQi2b BM *QKTmi2` a+B2M+2- TTX 83jĜeykX
"H/BKibB- 6Qi2BMB M/ MM GvbvMbFv UkyRjV ǳPM i?2 a2+m`Biv Q7 PM2@qBiM2bb "HBM/
aB;Mim`2 a+?2K2b-Ǵ /pM+2b BM *`vTiQHQ;v @ aA*_uSh kyRj- oQHX 3kdy- TTX 3kĜNNX
"`F- "Qx- P/2/ :QH/`2B+?- _mbb2HH AKT;HBxxQ- ai2p2M _m/B+?- KBi a?B- aHBH SX o/@?M- M/ E2 uM; UkyyRV ǳPM i?2 UAKVTQbbB#BHBiv Q7 P#7mb+iBM; S`Q;`Kb-Ǵ BM /pM+2b
BM *`vTiQHQ;v @ *_uShP kyyR- oQHX kRjN Q7 G2+im`2 LQi2b BM *QKTmi2` a+B2M+2- TTX RĜR3X"2M@abbQM- 1HB- H2bbM/`Q *?B2b- *?`BbiBM :`KM- Jii?2r :`22M- AM JB2`b- 1`Mh`QK2`- M/ J/`b oB`x UkyR9V ǳw2`Q+b?, .2+2Mi`HBx2/ MQMvKQmb SvK2Mib 7`QK
"Bi+QBM U1ti2M/2/V-Ǵ kyR9 A111 avKTQbBmK QM a2+m`Biv M/ S`Bp+v- TTX 98NĜ9d9X"`M/b- ai27M URNNjV ǳlMi`+2#H2 Pz@HBM2 *b? BM qHH2ib rBi? P#b2`p2`b U1ti2M/2/ #@bi`+iV-Ǵ BM /pM+2b BM *`vTiQHQ;v @ *_uShP ǶNj- oQHX ddj Q7 G2+im`2 LQi2b BM *QKTmi2`
a+B2M+2- TTX jykĜjR3X"`B+F2HH- 1`MB2- CM *K2MBb+?- M/ GB[mM *?2M Ukyy9V ǳ.B`2+i MQMvKQmb ii2biiBQM-Ǵ
S`Q+22/BM;b Q7 i?2 RRi? *J *QM72`2M+2 QM *QKTmi2` M/ *QKKmMB+iBQMb a2+m`Biv- TTXRjkĜR98X"`B+F2HH- 1`MB2 M/ CBM;iQ GB UkyRyV ǳ1M?M+2/ S`Bp+v A. 7`QK "BHBM2` SB`BM; 7Q` >`/@r`2 mi?2MiB+iBQM M/ ii2biiBQM-Ǵ kyRy A111 a2+QM/ AMi2`MiBQMH *QM72`2M+2 QM
aQ+BH *QKTmiBM;- TTX de3Ĝdd8X"ɃMx- "2M2/BFi- a?b?MF ;`rH- J?/B wKMB- M/ .M "QM2? UkykyV ǳw2i?2`, hQ@r`/b S`Bp+v BM  aK`i *QMi`+i qQ`H/-Ǵ BM 6BMM+BH *`vTiQ;`T?v M/ .i a2+m`BivTTX 9kjĜ99jX*?mK- .pB/ URN3kV ǳ"HBM/ aB;Mim`2b 7Q` lMi`+2#H2 SvK2Mib-Ǵ BM /pM+2b BM *`vT@
iQHQ;v, S`Q+22/BM;b Q7 *_uShP Ƕ3k- TTX RNNĜkyjX
*?mK- .pB/- *?`BbiBM :`Qi?Qz- M/ h?QKb JQb2` UkykRV ǳ>Qr iQ Abbm2  *2Mi`H "MF
.B;BiH *m``2M+v-Ǵ `sBp- oQHX #bfkRyjXyyk89X*?mK- .pB/ M/ hQ`#2M S`v/b S2/2`b2M URNNjV ǳqHH2i .i#b2b rBi? P#b2`p2`b-Ǵ BM
/pM+2b BM *`vTiQHQ;v ― *_uShPǶ Nk- TTX 3NĜRy8X*?mK- .pB/- "2`i /2M "Q2`- 1m;ĕM2 pM >2vbi- aiB; JDǠHbM2b- M/ /`B ai22M#22F URNNyV
ǳ1{+B2Mi P|BM2 1H2+i`QMB+ *?2+Fb-Ǵ BM /pM+2b BM *`vTiQHQ;v ― 1l_P*_uSh Ƕ3NTTX kN9ĜjyRX
*?2M;- _vKQM/- 6M w?M;- C2`M2D EQb- q``2M >2- LB+?QHb >vM2b- LQ? CQ?MbQM- `B
Cm2Hb- M/`2r JBHH2`- M/ .rM aQM; UkyRNV ǳ1FB/2M,  SHi7Q`K 7Q` *QM}/2MiBHBiv@
S`2b2`pBM;- h`mbirQ`i?v- M/ S2`7Q`KMi aK`i *QMi`+i 1t2+miBQM-Ǵ kyRN A111 1m`Q@
T2M avKTQbBmK QM a2+m`Biv M/ S`Bp+v U1m`QaSV- TTX R38ĜkyyX
jj

62B;2- l`B2H- KQb 6Bi- M/ /B a?KB` URN33V ǳw2`Q@FMQrH2/;2 T`QQ7b Q7 B/2MiBiv-Ǵ CQm`MH
Q7 *`vTiQHQ;v- oQHX R- LQX k- TTX ddĜN9X
6mDBbFB- 1BB+?B`Q M/ hibmFB PFKQiQ URNN3V ǳS`+iB+H 1b+`Qr *b? a+?2K2b-Ǵ A1A*1h`Mb+iBQMb QM 6mM/K2MiHb Q7 1H2+i`QMB+b- *QKKmMB+iBQMb M/ *QKTmi2` a+B2M+2boQHX 13R@- TTX RRĜRNX
:HQ#HSHi7Q`K UkyR9V ǳa2+m`2 1H2K2Mi ++2bb *QMi`QH pRXR-Ǵ :HQ#HSHi7Q`K .2pB+2 h2+?@
MQHQ;v- .Q+mK2Mi _272`2M+2, :S.naS1nyRjX:QH/rbb2`- a?} M/ :mv LX _Qi?#HmK UkyydV ǳPM "2bi@SQbbB#H2 P#7mb+iBQM-Ǵ BM h?2Q`v
Q7 *`vTiQ;`T?v- oQHX 9jNk Q7 G2+im`2 LQi2b BM *QKTmi2` a+B2M+2- TTX RN9ĜkRjX
:aJ bbQ+BiBQM UkyRRV :aJ L6* >M/b2i SAb _2[mB`2K2Mi aT2+B}+iBQM o2`bBQM kXyTTX RĜ93X>2BHKM- 1i?M- G22M Ha?2MB#`- 6Qi2BMB "H/BKibB- H2bbM/` a+7m`Q- M/ a?`QM :QH/@#2`; UkyRdV ǳhmK#H2"Bi, M lMi`mbi2/ "Bi+QBM@*QKTiB#H2 MQMvKQmb SvK2Mi >m#-Ǵ
BM L2irQ`F M/ .Bbi`B#mi2/ avbi2K a2+m`Biv avKTQbBmK, AMi2`M2i aQ+B2ivX
Jtr2HH- :`2;Q`v UkyR8V ǳ*QM}/2MiBH i`Mb+iBQMb-Ǵ l_G, ?iiTb,ffT2QTH2XtBT?XQ`;f;`2;f+QM7B/2MiBHnpHm2bXitiX
JBiMB- hibmQ M/ FB` PibmF UkykyV ǳh`+2#BHBiv BM S2`KBbbBQM2/ "HQ+F+?BM-Ǵ A111
++2bb- oQHX 3- TTX kR8djĜkR833X
JQ`BvK- EQB+?B M/ FB` PibmF UkykkV ǳii2bi2/ 1t2+miBQM a2+m`2 S`Q+2bbQ`@#b2/
`+?Bi2+im`2 7Q` a2H7@aQp2`2B;M A/2MiBiv avbi2Kb S`2b2`pBM; S`Bp+v-Ǵ 暗号と情報セキュ
リティシンポジウム Ua*Aa kykkVX
JQ`BvK- EQB+?B M/ FB` PibmF Ukykk#V ǳS2`KBbbBQMH2bb "HQ+F+?BM@"b2/ av#BH@_2bBbiMi a2H7@aQp2`2B;M A/2MiBiv liBHBxBM; ii2bi2/ 1t2+miBQM a2+m`2 S`Q+2bbQ`b-Ǵ kykk
A111 AMi2`MiBQMH *QM72`2M+2 QM "HQ+F+?BM U"HQ+F+?BM ǶkkVX
LiBQMH *QKTmi2` a2+m`Biv *2Mi2`- lXaX URN38V*`Bi2`BX

h`mbi2/ *QKTmi2` avbi2K 1pHmiBQM

PFKQiQ- hibmFB URNNkV ǳS`Qp#Hv a2+m`2 M/ S`+iB+H A/2MiB}+iBQM a+?2K2b M/ *Q`@
`2bTQM/BM; aB;Mim`2 a+?2K2b-Ǵ /pM+2b BM *`vTiQHQ;v @ *_uShP ǶNk- oQHX d9y- TTX
jRĜ8jXPFKQiQ- hibmFB M/ ExmQ P?i URNNkV ǳlMBp2`bH 1H2+i`QMB+ *b?-Ǵ BM /pM+2b BM*`vTiQHQ;v ― *_uShP ǶNR- TTX jk9ĜjjdX
Sbb- _72H- 1HBM2 a?B- M/ 6HQ`BM h`Kû` UkyRdV ǳ6Q`KH #bi`+iBQMb 7Q` ii2bi2/
1t2+miBQM a2+m`2 S`Q+2bbQ`b-Ǵ BM /pM+2b BM *`vTiQHQ;v ― 1l_P*_uSh kyRd- TTXkeyĜk3NX
SQBMi+?2pH- .pB/ M/ C+[m2b ai2`M UkyyyV ǳa2+m`Biv `;mK2Mib 7Q` .B;BiH aB;Mim`2b
M/ "HBM/ aB;Mim`2b-Ǵ CQm`MH Q7 *`vTiQHQ;v- oQHX Rj- LQX j- TTX jeRĜjNeX
j9

a2m`BM- uMMB+F UkyRkV ǳPM i?2 1t+i a2+m`Biv Q7 a+?MQ``@hvT2 aB;Mim`2b BM i?2 _M/QKP`+H2 JQ/2H-Ǵ 1l_P*_uSh- oQHX dkjd- TTX 889Ĝ8dRX
ai/H2`- J`Fmb- C2M@J`+ SBp2i2m- M/ CM *K2MBb+? URNN8V ǳ6B` "HBM/ aB;Mim`2b-Ǵ
BM /pM+2b BM *`vTiQHQ;v @ 1l_P*_uSh ǶN8- oQHX NkR Q7 G2+im`2 LQi2b BM *QKTmi2`
a+B2M+2- TTX kyNĜkRNX
hF?b?B- hBb2B M/ FB` PibmF UkykRV ǳS`Q##BHBbiB+ JB+`QTvK2Mib rBi? h`Mb72`#BH@
Biv-Ǵ BM kei? 1m`QT2M avKTQbBmK QM _2b2`+? BM *QKTmi2` a2+m`Biv ě 1aP_A*a kykRoQHX RkNdk Q7 G2+im`2 LQi2b BM *QKTmi2` a+B2M+2- TTX jNyĜ9yeX
q2B;QH/- h?QKb- h?Q`bi2M E`KT- _2iQ >2`KMM- 6`MF >ƺ`BM;- S2i2` "m?H2`- M/
JB+?2H "2Mib+? Ukyy3V ǳh?2 wm`B+? h`mbi2/ AM7Q`KiBQM *?MM2H ě M 1{+B2Mi .2@
72M+2 ;BMbi JM@BM@i?2@JB//H2 M/ JHB+BQmb aQ7ir`2 ii+Fb-Ǵ BM h`mbi2/ *QKTmiBM;
M/ h`mbi BM AM7Q`KiBQM h2+?MQHQ;B2b ě h`mbi Ƕy3- TTX d8ĜNRX
大塚玲 UkykkV ǳブロックチェーンを利用した暗号資産の安全性と匿名性：原理と限界-Ǵ 金
融研究- oQHX 9R- LQX R- TTX RĜ8eX
中山靖司 URNN3V ǳ電子マネー技術と特許-Ǵ 金融研究所ディスカッション・ペーパー- LQX
RNN3@C@jjX
中山靖司・太田和夫・松本勉 URNNNV ǳ電子マネーを構成する情報セキュリティ技術と安全性評価-Ǵ 金融研究- oQHX R3- LQX k- TTX 8dĜRR9X
中山靖司・森畠秀実・阿部正幸・藤崎英一郎 URNNdV ǳ電子マネーの一実現方式について-Ǵ 金
融研究- oQHX Re- LQX k- TTX d8Ĝ3eXj8