SSP リレーに見えるもの、見えないもの

SSP は二台構成の財布です。ブラウザ拡張が一方の鍵を、携帯がもう一方の鍵を持ち、どちらも単独では資金を動かせません。けれどもその二台は互いに話をする必要があり、そのために私たちが運用している「リレー」と呼ばれるサーバーを通します。

そのサーバーは、居心地の悪い問いを立てるのにふさわしい場所です。すべてが財布の会社の運用する基盤を通るのなら、その会社には正確に何が見えているのか。

もっともな問いであり、安心させる答えではなく具体的な答えに値します。そこで、コードに実際に書かれていることを示します。

リレーは何も署名できない

いちばん大切なところから始めます。

リレーが秘密鍵を受け取ることは一度もありません。暗号化された形でも、分割された形でも、どんな形でも。財布の鍵はブラウザ拡張に留まり、鍵アプリの鍵は携帯に留まります。ネットワークを渡るのは公開鍵と、未署名のデータと、すでにあなたの端末上で作られた署名だけです。

これは方針上の約束ではなく、構造上のものです。二者のうち二者によるマルチシグは資金を動かすのに両方の署名を要し、リレーはそのどちらの鍵も持っていません。完全に悪意あるリレー――私たちのものでも、乗っ取られたものでも、攻撃者に差し替えられたものでも――は、なお有効な取引を作れません。作るには、送られたことのない秘密が要るからです。

それが保証です。以下はすべて、リレーが実際に扱うもの――より狭い、けれども本当に空ではない集合――についての話です。

何が通り、どれだけ留まるのか

リレーは四種類の記録を保持します。うち二つは自ら消えます。

同期データ。二台を対にするときのものです。チェーン、あなたの財布の識別子、鍵アプリの拡張公開鍵、そこから導かれる WK 識別子、公開ノンス、生成されたアドレス、そして署名付きの復旧用 xpub を運びます。

動作データ。何かに署名しているときのものです。チェーン、導出パス、あなたの WK 識別子、動作の種別、ペイロードそのもの、そして関係する UTXO を運びます。

この二つのコレクションはどちらも MongoDB に expireAfterSeconds: 900 と設定された TTL インデックスを持ちます。十五分です。ほかに何が起ころうとデータベースが記録を消します。誰かが忘れずに走らせねばならない掃除の仕事ではなく、プライバシー方針の中の約束でもありません。インデックスであり、データベース自身が強制します。

プッシュ通知のトークン。承認すべきものがあるときに携帯を起こすためのものです。これは残ります。十五分ごとに失効する通知トークンは役に立たないからです。

復旧用 xpub。識別子ごとに一つ、失効はまったくありません。これは意図的であり、コードにもそう書かれています。両方のアプリがたまたま起きている短い時間だけでなく、財布が必要なときにいつでも取りに行けるように存在します。

私たちがはっきり言うべき部分

その同期ペイロードをもう一度見てください。拡張公開鍵が入っています。

xpub は支払い用の鍵ではなく、取引を承認できません。けれども無ではありません。口座の xpub からは、その口座が将来使うすべてのアドレスを導けます。つまりそれを持つ者は、そのチェーンの残高と取引履歴のすべてを眺められる。その口座におけるあなたの金銭生活への読み取り権限です――チェーン上のプライバシーが避けることで成り立っている、まさにその結びつきです。

動作ペイロードも同じだけ実体があります。あなたが署名しているあいだ、リレーは未署名の取引を扱います。お金がどこへ、いくら、どの出力から行くのか。

ですから正直な要約は「リレーには何も見えない」ではありません。こうです。

リレーはあなたのお金を使えない。そして一度につき十五分のあいだ、あなたがそれで何をしているかを見られる。

十五分という窓が緩和策であり、意味のある緩和策です。ひとつの場所にどれだけ履歴が溜まりうるかを区切ります。けれどもその窓のあいだデータはそこにあり、私たちは「非保管型」という語に、それが勝ち取っていない修辞の仕事をさせるより、はっきり言うほうを選びます。

借りる値打ちのある設計原則

復旧サービスに、どんな図よりもうまく構造を捉えた注記があります。

財布はその署名を、自ら導いた識別子の公開鍵に対して検証する。したがってこの保管場所は信頼されない。

復旧用 xpub は、SSP Key がそれに対して作った分離署名とともに保管されます。財布が取り出すとき、財布は識別子の公開鍵を自分で導き、署名を自分で確かめます。もしリレーが別の xpub を返したなら――乗っ取りでも、不具合でも、意図的な差し替えでも――署名は検証を通らず、財布はそれを拒みます。

リレーに依存するソフトウェアは、リレーを信頼できない管として扱います。自分で運用する基盤の上に築くとき、それが正しいやり方です。自分のサーバーが誤っても、それが利用者の問題にならないという意味だからです。どの財布を評価するときにも探すべき型でもあります。「行儀よくすると約束しているか」ではなく、「その会社のサーバーが行儀悪く振る舞ったら何が起きるか」。

敵対的なリレーに実際できること

本当の脅威の形については具体的であるほうがよい。

観察はできます。 TTL の窓の内側で、あなたの xpub と保留中の取引を。これはプライバシーの露出であって、盗難の危険ではありません。

検閲はできます。 端末間のやり取りを通さず、通常の流れで新しい取引に署名できなくする。厄介で妨げになります――そして何かを失うのとは違います。鍵は依然としてあなたのもの、資金は依然としてチェーン上にあり、復旧の道はまさにリレーが無いかもしれないからこそ用意されています。

嘘はつけますが、たいてい失敗します。 復旧用 xpub の差し替えは、上に述べた署名の確認に阻まれます。あの検証が効いてくるのはこのためです。

署名はできません。 鍵が無ければ署名は無く、取引も無い。

現実的な最悪は監視と妨害であって、喪失ではありません。保管型のサービス――そこでの対応する最悪は「お金が消えた」です――に比べれば、はっきり良い位置です。それは「誰にも何も見えない」と同じではなく、この二つを混ぜることこそ、人が自分のプライバシーについて誤った像を抱く道筋です。

見えている部分について、できること

対にすることが何を露わにするか理解すること。 あるチェーンを同期するとは、そのチェーンの xpub がリレーを通るということです。二台構成の設計がそもそも働くための代価です。

窓は短いが、ゼロではないと覚えておくこと。 一動作につき十五分は上限であって、不在ではありません。

復旧用 xpub は恒久のものとして扱うこと。 設計上、失効なしに保管され、検証可能な署名の付いた公開鍵の材料です――けれども持続します。あとで気づくのではなく、知っておくべきことです。

保証ではなく構造で判断すること。 どの財布のサーバーについても、有用な問いは会社が慎み深さを約束しているかではありません。サーバーが嘘をついたときソフトウェアが気づくかどうかです。私たちのものは応答を信じるのではなく署名を確かめます。そしてそれは私たちの言を信じずとも、コードで読めます。

いちばん理解してほしいのは、この取引の形です。二台構成の財布には調整のための通路が要り、調整のための通路とはメタデータが溜まる場所です。私たちはそれをデータベースが強制する失効で区切り、クライアントがサーバーを疑うように設計しました――けれども正直に言えば、リレーには本物のものが短いあいだ見えており、どれほど注意深い構造もその数をゼロにはしません。