準同型な支払先アドレスとPay-to-Contractプロトコル

準同型なアドレスとは、秘密鍵s, 公開鍵aとしたときに、
秘密鍵をn倍したnsに対応する公開鍵がnaとなる性質のことを言っているようです。

この性質を満たすのはビットコインで使用されている楕円曲線を使った鍵生成システムです。
　上記論文は、ECサイトでのビットコイン利用について主眼をおいているようです。
　特にECサイトへの攻撃シナリオについて

図１．従来のECサイトでの購入スキーム(参考文献１より）

１．　ECサイト等において、Webショップがハッキングされて支払い先アドレスがハッカーのものに書き換えられる

２．　購入者の入力した配達先アドレスがハッカーのものに書き換えられる

などの中間者攻撃（man-in-the-middle)が有りえます。

またDoS攻撃なども考えており、これはECサイトのダウンなどサーバー負荷の問題です。

これらを解決するために、BIP-175で提案されているようなアドレス導出スキームを使うことが提案されています。

このアドレス導出は、予めECサイト（販売者）側の公開鍵を公開し、それを購入者が取得していることを前提とします。

購入の流れ

　　まず、購入者は希望の商品をあるサイトにアクセスし、そのサイトの注文一覧を取得します。
購入者側では、その中から欲しいものを選び、注文内容を構造化したデータ（JSONなど）に入力し、それをハッシュ関数でハッシュ化します。
　さらに、このハッシュ化した文字列と公開鍵を使い、BIP32の階層決定性ウォレットの手法と同じ様に、子公開鍵を導出します。
　この新たな公開鍵に対応するビットコインアドレスに対し、購入者は送金します。

送金したあと、販売者側に注文内容の構造化したデータを別のチャネルで送信します（メールなど）。

では購入者はどうやって入金されたのを確認し、そのBTCを入手できるのでしょうか？

　　ここで重要なのがさきほど出た準同型性です。構造化した購入データのハッシュ値を使って、秘密鍵でも同様の鍵導出スキームを使うことができるのです。この導出スキームの結果得られる秘密鍵は、先に購入者が送金したアドレスの公開鍵に対応します。

　つまり、販売者はこの秘密鍵を使って、送金されたビットコインを引き出すことができるのです。

これらのプロセスのキモは、すべて購入者側で送金アドレス作成処理と注文内容確定が行われていることです。

　中間者攻撃はこれによって防がれています。

なので、このプロトコルに従った取引を行えば、いままでの販売者側で都度入金アドレスを生成して表示するプロセスを省くことができ、よりセキュリティを高めることができるのです。

Pay-to-Contractによる購入スキーム(参考文献１より）

従来との違い

このプロトコルは、従来のSSLによるセキュリティを前提としたECサイトと購入者の注文フローに相当するものを、ビットコインプロトコルのレイヤーに落として実現可能にしたものである。
中間者攻撃を排除できる点で、従来のSSLによるやり取りよりも優れている。
販売者や購入者のネットワーク外部に対する匿名性を高めることができる。
- トランザクション・アドレスからは宛先が誰なのかわからない。
販売者は、独自のサイトを持つ必要がなく、自分の公開鍵と販売物一覧のデータをどこかのハブとなるサイトに公開さえすればよい。

利点

販売者にとっては自分のECサイトについてセキュリティが破られても被害が出にくい。
- セキュリティに神経質になりすぎなくてもいい
- 販売用の公開鍵さえ配布すればよく、複雑なサーバー構成等がいらない。
- 公開鍵に紐付けられるreputation（評価値）の高評価が溜まれば、ユーザーが増える
購入者にとっては、
- ECサイトへの攻撃のせいで、偽のアドレスへ送ってしまう可能性がゼロに近くなる。
- 自分の注文で入力した住所がハッカーによって書き換えられる心配が無い。
- 「注文内容を入力した構造化データ」はそのままレシートになり、そのデータを元に導出したアドレスへの送金トランザクションは、注文への入金証明になる。（販売者のデータベースとの照合などが不要）
  -　公開鍵へのreputationが数値化されていれば、販売者の信頼度がわかりやすい。

問題点

購入者側でアドレスを生成するため、専用のプログラムが必要になる。
セキュリティを高めるためには、ハードウェアウォレット内部でそれらを行う必要があり、新しいハードウェアウォレットを開発しなけばならない。

　解決策・改善案

一つ目の問題点については、各自ダウンロードする共通ソフトウェアを作ってしまうのが考えられます。独自のウォレット（論文中ではLabeled Wallet）を作ってフリー配布するなどの手段が考えられますが、開発コストと、ユーザー側のダウンロードの手間があります。また、購入者のPCにマルウェア等が入り込んだ場合はセキュアではありません。TrezorやLedger等でマルウェアによるアドレス書き換えが起こった事件があるので、現実的な脅威です。
　Chrome拡張でも脅威は変わりませんが、発行元の証明などがあれば配布はやりやすい可能性があります。
2つ目については、Trezorなどがこのプロトコルに対応する新製品を出すのを待つ、、、という話になってしまいます。Pay-to-Contractを使った決済のニーズがあればありえるかもしれません。

参考文献

図は１の論文より引用