Shamir's Secret Sharing と Drop のハイブリッドモデル
ウォレットが鍵をどう守るかは、技術的な選択に見えます。しかしそれは人についての選択でもあります。誰があなたのお金を動かせるのか、誰がそれを失いうるのか、そしてあなたは誰を信頼しなければならないのか。技術的な決定は、道徳的な決定です。
セキュリティモデル のページでは、Drop があなたの鍵をどう守るかを説明しています。このページでは、その背後にある1つの決定を取り上げます。鍵を分割する最も一般的な方法である Shamir's Secret Sharing をなぜ使わないのか、そしてその選択にどんな代償があるのかです。
Shamir's Secret Sharing の概要
Shamir's Secret Sharing（SSS）は、秘密鍵をシェアと呼ばれる断片に分割し、復元に必要な数を選べるようにします。たとえば3つのうち任意の2つです。それより少ないシェアしか持たない人は鍵について何も知ることができず、シェアを1つ失っても鍵は失われません。この方式は1979年に考案され、業界全体で使われています。
典型的な SSS ウォレットでは、1つのシェアをあなたのデバイスに、1つをプロバイダーに置き、もう1つのリカバリーシェアをあなた自身が保管します。
Drop は代わりに鍵を2つのシェアに分割し、常に両方が必要です。SSS のように、秘密鍵を復元できる追加のシェアはありません。
3つの決定
予備のシェアは誰が保管するのか
SSS では、あなたです。シェアを1つ失ってもよいことが SSS の最大の魅力ですが、それはどこかに保管された予備に依存します。ファイル、クラウドストレージ、印刷したコードなどです。失くしたり、漏れたりしうるものが1つ増えます。
Drop では、予備のシェアはなく、あなたが追加で保管するものもありません。
代償：シェアを失うことは許されないため、バックアップの保持は当社と、あなたの2台目のデバイスの役割になります。
何かが盗まれたとき、誰に確認が求められるのか
SSS では、誰にも求められない可能性があります。リカバリーシェアがデバイスのシェアと同じ場所、つまり同じスマートフォン、同じクラウドアカウント、同じノート PC のバックアップに置かれていれば、その1か所に侵入した人が鍵全体を手にします。2つのシェアで足りるため、承認のステップも、上限も、アラートもありません。
Drop では、コピーされたファイルや盗まれたバックアップだけでは決して足りません。対応するパスキー があれば、あなたの側のシェアはそのパスキーなしでは役に立たず、当社のサービスはあなたのパスキーが承認したリクエストに対してのみ、もう一方のシェアを開示します。
計算でどれだけ問題が起こりうるのか
SSS では、想像以上に多くあります。SSS は、通常のテストでは見つからないミスの余地がある演算に依存しています。丁寧に作られ広く使われている Privy のオープンソースライブラリに対する独立した監査では、想定より少ないシェアで秘密の一部を復元できる場合があることが判明しました。Privy はこれを修正し、その内容を公開しました。また SSS は、シェアが誤っていることを検知できません。不正なシェアを結合すると、警告なしに別の鍵が生成されます。
Drop では、2つのシェアは考えうる最も単純な方法で結合されます。これにより、1つのシェアだけでは何もわからないという、SSS が評価されている性質を保ちつつ、誤りが起こる余地ははるかに小さくなります。Drop はさらに、復元された鍵があなたのウォレットのアドレスと一致することを、使用前に確認します。
代償：柔軟性です。「3つのうち任意の2つ」は、まさにその追加の演算によって得られるものです。
代償をどう補うか
- 当社側に3つのバックアップコピー。 現在、暗号化されたサーバー側シェアのバックアップコピーを3つ保持しており、今後レプリカを増やす可能性があります。1つはバックアップ用データベース、1つは分離・隔離された別の AWS アカウントのデータベース、1つはオフラインのハードウェアにあります
- あなたの側に2台目のデバイス。 パスキーのバックアップ でデバイスをペアリングしておけば、1台を失ってもアクセスを失いません
- 出口。 秘密鍵はいつでもエクスポート できます。それ以降、そのコピーを守るのはあなただけです