知るべきこと: |
– Miniscript を使用すると、バックドアの悪用を不可能にするビットコイン ソフトウェア ウォレットを構築できます。 Ledger が Miniscript をサポートする最初の商用ハードウェア ウォレット メーカーであることを嬉しく思います。
– 追加機能は、ユーザー エクスペリエンスを損なうことなく実装できます。 |
ハードウェア署名デバイスは、次のようなさまざまな一般的な攻撃ベクトルからユーザーを保護するように設計されています。
- 不正アクセスとシード抽出
- 関連するソフトウェアウォレットに感染するマルウェア
- デバイス自体のソフトウェアの脆弱性
他のビジネスと同様に、デバイスを次のような形で製造することがメーカーの最大の利益になります。 アンブレイカブル できる限り。 この使命を達成することが最も重要であり、レジャーのようなセキュリティ会社は、その実績に基づいて構築された評判に依存しています。
ただし、一部のユーザーは依然として懸念を抱いているかもしれません。 企業自体が隠蔽することを妨げるものは何か 裏口 デバイスの中では?
自主隔離中、私たちは、 信用しない, 私たちは確認します.
しかし、ユーザーはできるでしょうか 本当に デバイスにバックドアがないことを確認しますか?
それがこの記事で掘り下げる重要な質問です。 より正確には、この記事では次のトピックについて扱います。
- バックドアとは何なのか、バックドアがないことを証明することが不可能ではないにしてもなぜ難しいのか。
- なぜユーザーだけがこのリスクから身を守ることができるのか。
- miniscript がどのようにしてビットコインウォレットのこの課題に対する実用的な解決策を可能にするのか。
ハードウェアウォレットとして初めてサポートされることにより、 ミニスクリプト、私たちは開発者が安全なソリューションを構築し、業界全体をアップグレードするよう促し、そのようなシステミックリスクが現実化する可能性を排除したいと考えています。
構築方法 バックドア不可能 署名デバイス
はっきり言っておきますが、それはできません。
潜在的なバックドアから身を守るには、上で概説したものとは異なる攻撃モデルが必要です。このシナリオでは、敵はベンダー自体、または破損した内部関係者である可能性があります。
この問題に対する解決策としてよく宣伝されるのがオープンソースです。つまり、コードを検査できれば、何が問題になる可能性があるのでしょうか?
ただし、真実はさらに複雑です。 ベンダーがハードウェアを組み立てるので、その中にバックドアが完全に含まれる可能性があります。 ハードウェアは、特定の時点でソフトウェアを無視し、代わりに悪意のあるコードを実行するように設計されている可能性があります。
汎用コンピューティング デバイス (ラップトップや携帯電話など) で実行されるソフトウェアとは異なり、ハードウェアを精査することは、今日のテクノロジーでは事実上不可能です。 たとえハードウェア仕様が回路内のすべてのゲートの詳細を備えた完全なオープンソースだったとしても、特定のチップが仕様に従って構築されているかどうかを検証するには、依然として高価な機器が必要になります。
ハードウェアウォレットをバックドアする方法
ここでは、悪意のあるハードウェア ベンダーがバックドアを導入するために使用できる最も簡単な方法をいくつか紹介し、パワー ユーザーが今日自分自身を守ることができる方法をいくつか紹介します。
シード生成
多くのデバイスでは、シード (シードとも呼ばれます) を生成する機能が提供されています。 秘密の回復フレーズ) を使用して、デバイス上で直接 真の乱数ジェネレータ.
😈 邪悪なデバイスは、ランダムに見えても実際には攻撃者にとって予測可能なシードを生成する可能性があります。
🛡️ パワー ユーザーは、オフラインでニーモニックを生成することで、この問題を回避できます。 さらに、堅牢な パスフレーズ ハードウェア ベンダーが予測できない完全に独立したシードを生成することもできます。 その代償として、ユーザーはニーモニック ワードに加えてパスフレーズも適切にバックアップする必要があります。
公開鍵の導出
ハードウェアウォレットは、 公開鍵 (とも呼ばれます xpubs、の略 拡張公開鍵 で定義されている BIP-32を選択します。 xpubs コインを受け取るための可能なアドレスを生成するために使用されます。
😈 邪悪なデバイスは、シードから得られた正しい公開鍵の代わりに、攻撃者が管理する公開鍵を返す可能性があります。
🛡️ ユーザーは派生したものを検証できます xpub 別のオフラインデバイス上で。 ただし、他のデバイスでシードに入力すると、それ自体のリスクが伴います。 セキュリティ意識の高いユーザーは、シードにアクセスしたデバイスを危険とみなし、場合によってはデバイスを破壊する可能性があります。 一般的なユーザーは、追加のリスクを管理しながらこの手順を正しく実行するのに苦労する可能性があります。
情報の漏洩
An エアギャップ 悪意のあるデバイスや侵害されたデバイスによる秘密キーの流出を防ぐソリューションとして頻繁に提案されます。 結局のところ、デバイスが外部と通信できなければ、有害なことは何もできませんよね?
全然違います!
デバイスは使用中いつでも通信でき、署名を生成します。 これらの署名は最終的にトランザクション内に送信され、ブロックチェーン上に永久に保存されます。
署名は、少なくとも 64 バイトのランダムに見えるバイト文字列です。 ただし、複数の有効な署名が同じメッセージに対応する可能性があるため、悪意のあるデバイスは、複数の署名を生成し、どれを公開するかを選択することにより、署名が生成されるたびに数ビットの情報を通信する可能性があります。
😈 不正なデバイスは、多くのトランザクションにわたって、攻撃者にシードを明らかにする非ランダムな署名を生成する可能性があります。
このようなバックドアのインストールに成功した攻撃者は、シード全体を再構築するのに十分な情報を得るまで、悪意のある署名がブロックチェーン上に現れるのを待つだけで済みます。
🛡️ ECDSA 署名の場合、ノンスを決定論的に導出する標準化された方法を使用します (次のように) RFC6979) 生成された署名が予期されたものと一致することが検証されれば、この攻撃は阻止されます。 ただし、これを確実に行うには、XNUMX 番目のデバイスに同じシードをロードする必要があり、前のセクションで説明したのと同じ実際的な問題が発生します。
🛡️ 興味深いアプローチは、次のような賢い方法を使用することです。 力 デバイスは実際にランダムなノンスを選択します。 この目的のためのプロトコルとして知られています。 抗exfil or 盗難防止、現在、Blockstream Jade および ShiftCrypto BitBox02 ハードウェア ウォレットに実装されています。 続きを読む シフトクリプトのブログ、このような攻撃がどのように実行されるかについての技術的な説明も含まれています。
さて、それでは希望はないのでしょうか?
上記の防御策🛡️のほとんどは、自分自身を守るために、ユーザーが明示的で侵入的なアクションを実行することを要求します。それは、シードを自分で生成する(基本的に、脳を使ってハードウェアウォレットの機能を置き換える)か、追加のデバイスを利用して計算が正しく実行されることを確認するかのいずれかです。
ただし、exfil 対策プロトコルは際立っています。ハードウェア署名者と外部世界との間には常にマシンが介在するため、このマシンが支援できるのです。 ハードウェア署名者との対話型プロトコルを通じて、次のことができます。 強制します 真にランダムなノンスを使用することで、最終的な署名を大幅に操作する可能性が減少または排除されます。
このブログ投稿では、主に次のタイプの対策に興味があります。UX を大幅に悪化させる戦略は、パワー ユーザーにとって魅力的である可能性がありますが、問題を解決する可能性が高くなります。 もっと悪い 実際には、技術的に熟練していないユーザーがほとんどです。
セキュリティモデル
ハードウェア署名者向けの標準モデル
ハードウェア署名者のメーカーは、さまざまな潜在的な脅威からユーザーを保護することを目指しています (詳細については、「 脅威モデル)。 この記事では、次のように要約できる XNUMX つの非常に重要なプロパティに焦点を当てます。
ユーザーが承認前に画面上の情報を理解し、確認していれば、だまされて資金損失を引き起こす行動を起こすことはありません。
機密性の高いアクション、特に署名には承認が必要です。 すべての資金を使い果たすトランザクションなど、マルウェアが任意のメッセージの署名を生成できる場合、シードの保護は無駄になってしまいます。
ソフトウェアウォレットが完全に侵害された場合でも、上記の特性が当てはまらなければならないことを強調することが重要です。 ラップトップや携帯電話の画面に表示される内容は信頼できません。 マルウェアはアドレスを置き換えたり、どのアドレスが自分のものであるかについてユーザーを騙したり、トランザクションを提示しながら署名のために別のトランザクションをデバイスに転送したりする可能性があります。
したがって、ハードウェア署名デバイス上で実行されるファームウェアとアプリケーションは、本質的にソフトウェア ウォレットを考慮します。 信頼できない そして信頼できない。
ソフトウェアウォレットのバックドア対策セキュリティモデル
このセクションでは、役割を完全に反転します。 ここでデザインしたいのは、 ソフトウェアウォレット ハードウェアメーカーが資金を盗んだり損失を引き起こしたりするのを防ぎます。 たとえデバイスが完全に悪意のあるものであっても.
したがって、これは デバイス: むしろ、それはの特性です。 ソフトウェアウォレット 設定。 次のように要約できます。
ソフトウェアウォレットが侵害されない限り、ハードウェアメーカーはユーザーに資金を失わせることはできません。
これは、上で詳述した標準的なセキュリティ モデルと直接矛盾するため、直観に反するように思えるかもしれません。 しかし、「バックドアがない」ということは、「やるべきことをきちんとやっている」ということです。 ソフトウェアウォレットなので、 太陽 署名デバイスと外界との間のインターフェイスであり、バグやデバイスの明示的な侵害が原因であっても、不正行為に対する保護を強制できる唯一の場所です。
このモデルは、悪用可能なバグなど、デバイスの障害を大幅に超えて拡張されることに注意してください。 この場合、デバイスが積極的に資金損失を引き起こそうとするシナリオ内で動作しています。
もちろん、メーカーが侵害に成功した場合は保護することはできません。 両言語で デバイスと、ソフトウェアウォレットを実行するマシンも同様です。 したがって、特にハードウェアを製造しているのと同じベンダーによって構築されている場合には、ソフトウェアウォレットがオープンソースで監査可能であることを確認することが絶対に重要です。
ミニスクリプトの役割
Miniscript により、ウォレット開発者はビットコイン スクリプトの高度な機能を最大限に活用できるようになります。 ミニスクリプトが解き放つ驚くべき可能性の概要については、以下を参照してください。 以前のブログ投稿。 こちらもお聞きになりたいかもしれません Stephan Livera ポッドキャストのエピソード 452 ミニスクリプトがビットコインの世界に何をもたらすかについての議論のために。
Ledger Bitcoin アプリは、2.1.0 年 2023 月に展開された 2023 リリース以降、ミニスクリプトをサポートしています。マイアミで開催された Bitcoin 1.0 カンファレンスで、Wizardsardine は、Ledger Bitcoin アプリの XNUMX リリースを発表しました。 リアナウォレット、ミニスクリプトに基づいて最初にデプロイされたウォレット。
この投稿の基本的な考え方は、ビットコイン ウォレット アカウントは XNUMX つだけで保護できるのではなく、次の方法で保護できるということです。 の試合に キー。 これにより、キーの全体的な障害や漏洩が発生しても致命的ではない、柔軟なセキュリティ フレームワークが可能になります。
マルチシグについての思索
マルチシグは、セルフカストディ ソリューションの強度を大幅にアップグレードします。 ビットコイン スクリプトのプログラム可能性を活用することで、XNUMX つだけではなく複数のキーを必要とするウォレットの作成が可能になります。 あ k-の-n マルチシグウォレットには以下の組み合わせが必要です k 有効な署名、合計 n 可能性のあるもの。
ただし、マルチシグはユーザーに UX の負担を与え、新たなエラーの機会をもたらします。 3-of-3 マルチシグ設定では、別々の場所に安全にバックアップされた XNUMX つの異なるキーが関与し、強力なセキュリティを提供します…しかし、それはまた、たとえ キーを紛失すると、コインは永久にアクセスできなくなります。
したがって、より冗長性を提供するセットアップ (2-of-3 や 3-of-5 など) がより一般的になる傾向があります。XNUMX つのキーが失われた場合でも、他のキーで回復が容易になります。 ただし、これにはトレードオフが伴います。XNUMX つのキーが知らないうちに侵害されると、全体のセキュリティが大幅に低下します。
好きな会社 カーサ および 未連邦首都 は、顧客の少数の鍵を保管するセルフカストディ ソリューションに特化しています。 また、オンボーディング プロセスを通じてユーザーをガイドし、技術者以外のほとんどのユーザーにとって困難になる可能性がある保管システムの使用を簡素化することで、ユーザーを支援します。
Miniscript およびタイムロックされたリカバリ パス
Liana はミニスクリプトを使用して、複数の支出方法を持つウォレットを作成します。
- すぐに利用できる主要な支出条件。
- 一定期間後に利用可能になる XNUMX つ以上の追加の支出条件 (いわゆる タイムロック).
これにより、多くの興味深い使用例が可能になります。
- 回復: 主要な支出パスとしてシングルシグネチャまたはマルチシグのいずれかを備えた標準ウォレット。 ただし、別の回復メカニズム (異なるシードを持つキー、マルチシグ、技術に精通した友人、管理者) が 6 か月後に利用可能になります。
- ガバナンス: 取締役が 2 名いる会社は、会社の財務部門に 2/6 を確立できます。 意見の相違がある場合には、信頼できる弁護士が XNUMX か月後に資金にアクセスできるようになります。
- 減衰するマルチシグ: ウォレットは 3-of-3 として開始され、2 か月後に 3-of-6 に移行し、1 か月後に 3-of-9 になります。
- 自動継承: 6 か月後の回復経路には、2 人の子供のうち 3 人が含まれます。 おそらく、相続人が合意に達しない場合に備えて、1年後のXNUMX回目の回復経路には公証人が関与することになるでしょう。
リマーク: 上記のすべての例では、 相対タイムロック、これはコインの年齢 (つまり、資金が最後に移動されたとき) を指します。 その代償として、タイムロックの有効期限が近づいている場合、ユーザーは忘れずにコインを(自分自身に送信して)使う必要があります。
これらはほんの数例ですが、miniscript がビットコインの可能性を実現するための重要な前進であることを読者に納得させるのに十分なはずです。 プログラム可能なお金.
ウォレットポリシーの登録
複数のキー (マルチシグ、またはより洗練されたミニスクリプトベースのソリューション) を利用するビットコイン ウォレット アカウントの場合、そのアカウントに属するアドレスを識別するようにデバイスをトレーニングすることが重要です。 これは、ユーザーが正しいアドレスから送受信していることを確認するためにデバイスが支援できる唯一の方法です…
ポリシーと xpubs 信頼できるバックアップに対する連帯署名者の確認は不可欠ですが、比較的時間がかかります。
幸いなことに、これは一度だけ行う必要があるということです。
ポリシーに名前を付けて登録すると (例では「Decaying 3of3」)、そのようなポリシーが採用されるたびにデバイスがそのポリシーを認識できるようになります。
技術的な詳細に興味がある場合は、次のサイトで詳細情報を見つけることができます。 BIP提案.
ポリシーのバックアップ
注意すべき重要な側面の XNUMX つは、マルチキー ポリシーではサブセットが許可されているということです。 秘密鍵 トランザクションを承認するための知識、 を 公開鍵 (および 正確な ポリシー)が必要です。
ただし、シードとは異なり、ポリシーと公開キーのバックアップのリスクははるかに低くなります。誰かがそれを発見したとしても、そのポリシーに関連付けられたすべてのトランザクションを追跡できる可能性があります。 これは理想的ではありませんが、プライバシーが重要です。 − コインを失うほど悲惨ではなく、潜在的な攻撃者にとっては魅力的ではありません。 したがって、ポリシーの複数のコピーをホット ウォレットに保存する、ポリシーを印刷してさまざまな場所に保存する、暗号化してクラウド ストレージに保存する、などはすべて実行可能な戦略です。
バックドア不可能なシングルシグネチャウォレット
一歩下がってみましょう。 マルチシグネチャウォレットについて説明しましたが、ここでは基本に戻ってシングルシグネチャウォレットを作成します。 より正確に言えば、私たちは次のような財布を望んでいます。 感じています および ルックス 初期セットアップ段階後の単一署名ウォレットと同様です。 それでも、私たちは、たとえメーカーが悪意を持ったものであっても 😈 、ハードウェア署名デバイスが予測不可能な方法で動作する場合でも、メーカーが資金を盗むことができないウォレットを作成することを目指しています。
このアプローチは、マルチシグネチャウォレットに対して簡単に一般化できます。
以下の例は、と呼ばれる言語で記述されます。 方針、ミニスクリプトではなく。 ポリシーは人間にとって読みやすく、考えやすく、自動ツールを使用してミニスクリプトにコンパイルできます。 ミニスクリプトとポリシーについて詳しく読む.
ハードウェア ウォレットは標準のセキュリティ モデルで保護できます。 Miniscript は、バックドア対策セキュリティ モデル (そしてそれ以外にも!) でユーザーを保護できます。
ステップ XNUMX: 現状維持
これは、現在ほとんどのユーザーが使用しているポリシーです。ハードウェア ウォレットで生成されたシードから派生した単一のキーです。
pk(key_ledger)
もちろん、バックドアがないことを証明する方法はありません。
ステップ XNUMX: キーを XNUMX 倍にする
最初のステップは簡単です。
and(pk(key_ledger), pk(key_client))
ここでは、 key_client
ユーザーのマシン上で生成されるため、 ホットキー。 本質的には、2-of-2 マルチシグ設定です。 重要な点は、ユーザーがあまり対話しないことです。 key_client
: ソフトウェアウォレットはこのキーを生成し、ウォレットのバックアップに含めて、必要なときにいつでも署名します(たとえば、ユーザーがハードウェア署名者との署名で忙しいときなど)。
これはすでに非常に興味深いことに思えます。資金は、 key_client
、ハードウェア ベンダーは利用できません。 たとえ邪悪なベンダーがデバイス内のキーを完全に知っていたとしても、ソフトウェアウォレットを実行するマシンを侵害するなどして、ユーザーを明示的にターゲットにしない限り、資金を移動することはできません。
ただし、問題があります。ウォレットのオンボーディング中、ハードウェア署名者は公開キー (xpub) を生成できる唯一のエンティティです。 key_ledger
財布に使用されています。 したがって、デバイスは意図的に 間違った xpub は攻撃者によって制御され、その後署名を拒否します (または署名できなくなります)。 おそらく、これはかなり極端な攻撃シナリオです。バックドア作成者は資金を盗むことができず、できるのはユーザーを個別にターゲットにして身代金を要求することだけです (「半分払ってくれれば、お金を取り戻すのを手伝います」)。
より現実的に言えば、これにより間違いが間違いの可能性が高まります。現在、XNUMX つのシード/秘密鍵があり、次のものが必要です。 両言語で 過ごせるようにするために。 どちらかを失うと、コインは永久にロックされます。
ステップ XNUMX: タイムロックされたリカバリ
特定のタイムロック後にのみアクセスできる、別個の回復キーを導入します。 and(older(25920)
, pk(key_recovery))
, ここで、25920 は 6 か月間のおおよそのブロック数です。 完全なポリシーは次のようになります。
or(
and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)
これは前のシナリオと似ていますが、次のようなひねりが加えられています。 key_ledger
or key_client
何らかの理由で利用できなくなった場合 (最も一般的なのは、シード バックアップの喪失です!)、 回復経路 6か月後にアクセス可能になります。
いくつかのオプションがあります key_recovery
、それぞれに独自のトレードオフがあります。
a. 別のものを使用 ホットキー。 これは、ユーザーがタイムロックをリセットすることを忘れない限り、実用的な解決策です。 ただし、ホット キーが危険にさらされた場合 (このシナリオは一般に非常にあり得ると考えられます!)、攻撃者はタイムロックが期限切れになるとすぐに資金へのアクセスを試み、正当な所有者との競争を開始する可能性があります。
b. 別のハードウェア署名デバイスを使用します。 これは堅牢なソリューションであり、必要に応じて別のベンダーと組み合わせて使用できます。 ただし、ユーザー エクスペリエンスの観点から、セットアップが複雑になり、ユーザーのコストが増加します。
c. 信頼できる外部サービスを使用します。 ソフトウェアウォレットは、外部サービスから xpub をインポートし、それを次のように使用できます。 key_recovery
。 このサードパーティは、タイムロックが期限切れになった場合にのみ信頼されるため、一部のユーザーにとっては魅力的なトレードオフとなる可能性があります。
前述したように、タイムロックのある他のポリシーと同様に、ユーザーがタイムロックの有効期限が切れる前にコインを忘れずに更新することが重要です。
ステップ XNUMX: 信頼できないサードパーティ
両方のアイデア (a) と (c) を組み合わせてみましょう。回復パスにはローカル ホット キーが必要です。 key_recovery_local
、と key_recovery_remote
半信頼されたサービスでホストされている。 タイムロックも保持します。
or(
and(pk(key_ledger), pk(key_client)),
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote))
)
)
これにより、回復サービスに必要な信頼のレベルが低下します。 ただし、注意する必要があります。サービス自体がブロックチェーンを監視し、UTXO を検出する可能性があります。結局のところ、サービスは私たちに key_recovery_remote
xpub を使用して、から派生した公開鍵を含む UTXO をスキャンできます。 key_recovery_remote
。 彼らは、たとえタイムロックが期限切れになる前であっても、また私たちが彼らのサービスを利用したことがなかったとしても、私たちの財務履歴について知ることができます。
リマーク: タップルート ツリーは、特定のポリシーについてこのプライバシーの問題を排除できますが、常にそうであるとは限らず、特定のポリシーに基づいて慎重に評価する必要があります。
ステップ XNUMX: 第三者の目をくらます 🙈
回復サービスが当社の財務履歴を知ることを防ぐために、回復サービスから送信された公開鍵を使用する代わりに、 ブラインドxpub 技術 ここでmflaxmanによって詳しく説明されています。 つまり、使用する代わりに、 key_recovery_remote
私たちのポリシーでは、31 つの XNUMX ビット乱数を選択します。 a
, b
, c
, d
( 盲目要因)、次のものを使用します BIP-32 派生公開鍵:
key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d
追加することも重要です key_recovery_remote
、そして盲目な要因 a
, b
, c
および d
今後の参照のためにバックアップに保存します。
回復サービスを利用する必要がある場合は、その旨を明らかにします。 a
, b
, c
, d
彼らへ。 それまでは、キーが自分のファイルから派生したものであることを発見する方法はありません。 key_recovery_remote
ブロックチェーン上で公開されています。4 つの盲目要素の可能な組み合わせの数は次のとおりです。 2^(31*4) = 2^124
、そのため、すべてをブルートフォースすることが不可能になります。
ステップ XNUMX: ホットキーが多すぎると火傷する可能性があります 🔥
ソフトウェアウォレットをバックドア不可能にすることに成功しました。 ただし、別の問題が発生しました。どちらの支出条件も、ローカルで生成された、 ハードウェアウォレットによって検証されていないキー。 したがって、ホスト マシンが侵害されると、公開鍵を使用してポリシーを登録するように誘導される可能性があります。 key_client
および key_recovery_local
ただし、ランダムで無関係な秘密キーをバックアップに入れます(覚えておいてください、 キーはバックアップの一部です!)。
これにより、基本的にすべての資金がウォレットに送金されます。 使えない署名に必要な秘密鍵を制御する人は誰もいないためです。
この問題を解決するには、いくつかの解決策があります。
- オンボーディング中、バックアップを紙に印刷した後、別のデバイスを使用して、バックアップの秘密ホット キーと公開ホット キーが実際に一致していることを確認できます。 このアプローチでは、再構築と署名に必要なすべてのキーを確実に持っているため、問題は解決されます。
- さらに長いタイムロック (9 か月、38880 ブロック) を持つ別の支出条件を追加することもできます。
key_ledger_failsafe
ハードウェアデバイスから。 このようにして、他のすべてが失敗する絶対的な最悪のシナリオでは、単一の署名デバイスのセキュリティに頼ることになります。 通常の操作では、最初のタイムロックが期限切れになることはありません。したがって、XNUMX 番目のタイムロックも期限切れになりません。
XNUMX 番目のアプローチでは、最終的なポリシーは次のようになります。
or(
and(pk(key_ledger), pk(key_client)),
or(
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote_blind))
),
and(older(38880), pk(key_ledger_failsafe))
),
)
このソフトウェア ウォレットの構成は、最初に主張したセキュリティ特性をすべて満たしています。 さらに、主要な支出が減少した場合の回復手段も提供します。 key_ledger
失われています。 あると嬉しい機能!
バックドア不可能なソフトウェアウォレットへのオンボーディング
このような複雑なポリシーを使用したウォレットのユーザー エクスペリエンスはどのようなものになるでしょうか? 簡単な概要は次のとおりです。
- ユーザーはソフトウェア ウォレットを開き、新しいアカウントの作成を開始します。
- ソフトウェアウォレットは、ユーザーに署名デバイスを接続するよう促し、xpub を取得します。
key_ledger
およびkey_ledger_failsafe
. - ソフトウェアウォレットは自律的に key_client ホットキーを生成します。
- ソフトウェアウォレットが取得するのは、
key_recovery_remote
共同署名サービスからキーを指定することも、ユーザーが別の方法でキーを指定できるようにすることもできます。 オプションで、key_recovery_remote_blind
前述した盲検技術を使用します。 - ソフトウェアウォレットは、正確なミニスクリプトポリシー、すべてのxpub、および拡張秘密キーを含むポリシーバックアップを生成します。
key_client
ホットキー。 このバックアップは安全に保存されます (たとえば、紙に印刷したり、別のデバイスに保存したり)。 - 最後に、ソフトウェア ウォレットはユーザーにデバイスにポリシーを登録するように指示します。 ユーザーはバックアップを(紙またはソフトウェアウォレットによって制御される画面以外の媒体上で)クロスチェックします。
ソフトウェア ウォレットは上記の手順のほとんどを管理するため、ユーザーの関与は、マルチシグネチャ ウォレットの設定に現在必要とされる予想される労力よりも負担になりません。
適切な UX が構築されれば、オンボーディングには数分しかかかりません。 ソフトウェア ウォレットが完成すると、一般的なシングルシグネチャ ウォレットと非常によく似たユーザー エクスペリエンスを提供できます。 これが、miniscript がすべてを変える方法です。つまり、ユーザーの視界から消えることです。
主根の改善
Ledgerは、2.1.0月にリリースされたビットコインアプリのバージョンXNUMX以降、ミニスクリプトをサポートしています。 タップルート アドレスへの受信とタップルート アドレスからの支出のサポートは、 タップルートソフトフォーク 2021 年 XNUMX 月に、ロードマップの次のステップであるタップルートのミニスクリプト サポートの最後の仕上げを行っています。
Taproot は、この記事で紹介したアプローチの使いやすさに大きな影響を与えます。 主要な支出パスが単一キーの支出条件である場合、回復支出パスの存在は、それらが利用されない限りブロックチェーン上で検出できません。 これにより、標準的な支出経路の指紋が完全に排除され、プライバシーが大幅に向上します。 さらに、標準的な支出パスが可能な限りコスト効率よく支出されるようになるため、スケーラビリティが向上します。 これは、回復パスが使用されない限り、回復パスの存在によって追加のコストが発生することはないことを意味します。 これは、支出時にすべての支出条件を含むスクリプト全体を公開する必要がある SegWit トランザクションからの大幅なアップグレードです。
最後に、次のようなより高度なプロトコル ムシグ2 (最近標準化されました)そして フロスト タップルートのキーパスを強化します。 Schnorr 署名に基づいて構築されたこれらのプロトコルにより、単一の 集約公開鍵 を表すために使用できます n-の-n マルチシグネチャまたは k-の-n 閾値スキーム。 これにより、今日では特定のマルチシグ スクリプトで表されることが一般的になっている場合でも、タップルート キーパスの使用が可能になります。
結論
この記事では、miniscript がソフトウェア ウォレットに解き放つ広大な設計空間のうち、小さな (しかし重要な) ニッチな領域を探ります。
私たちは、ミニスクリプトを使用して「バックドア不可能な」ソフトウェア ウォレットを作成する方法を示し、同時に悲惨なキーの損失を防ぐ追加の回復パスも追加しました。 ハードウェア署名デバイスはバックドア対策セキュリティ モデルを強制することはできませんが、ミニスクリプトをサポートすることで、まさにそれを実行するソフトウェア ウォレットが可能になります。
マルチシグネチャ スキーム、タイムロック、ブラインド xpub、ホット キーの組み合わせを巧みに利用することで、セキュリティ、プライバシー、堅牢性のバランスをとった安全なウォレット構成を実証しました。
さらに、セットアップの複雑さが UX の大きな追加負担につながるわけではないため、ユーザー エクスペリエンスに悪影響を与えることなくこれが可能であると主張しました。
私たちは、miniscript が次世代のビットコイン セルフ カストディの可能性を解き放つことに興奮しています。
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
- プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
- プラトンESG。 自動車/EV、 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
- ブロックオフセット。 環境オフセット所有権の近代化。 こちらからアクセスしてください。
- 情報源: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript
- :持っている
- :は
- :not
- :どこ
- $UP
- 1
- 2021
- 2023
- 30
- 7
- 9
- a
- 能力
- できる
- 私たちについて
- 上記の.
- 絶対の
- 絶対に
- アクセス
- アクセス
- アクセス可能な
- 従う
- アカウント
- Action
- 行動
- 積極的に
- 実際に
- 加えます
- 追加
- 添加
- NEW
- さらに
- アドレス
- 高度な
- 後
- に対して
- 年齢
- 援助
- 目指す
- すべて
- 許す
- ことができます
- 沿って
- 既に
- また
- しかし
- 常に
- an
- および
- 発表の
- 別の
- どれか
- 何でも
- アプリ
- 訴える
- 現れる
- アプローチ
- アプローチ
- 承認
- 近似
- です
- 間違いなく
- 主張した
- 記事
- AS
- 側面
- アシスト
- 関連する
- At
- 攻撃
- 監査可能
- 認める
- 自動化
- 自律的に
- 利用できます
- バック
- 裏口
- 支持された
- バッキング
- バックアップ
- バランス
- ベース
- 基本
- 基本的に
- の基礎
- BE
- なぜなら
- になる
- になる
- 開始
- さ
- 以下
- BEST
- の間に
- 越えて
- Bitcoin
- ビットコイン財布
- ビットコイン財布
- ブロックチェーン
- ブロック
- ブロックストリーム
- ブログ
- 両言語で
- 脳
- もたらす
- 放送
- バグ
- ビルド
- 内蔵
- 負担
- 焼く
- ビジネス
- 忙しい
- 焙煎が極度に未発達や過発達のコーヒーにて、クロロゲン酸の味わいへの影響は強くなり、金属を思わせる味わいと乾いたマウスフィールを感じさせます。
- by
- 呼ばれます
- 缶
- できる
- 注意深い
- 場合
- 例
- 壊滅的な
- 原因となる
- 原因
- 注意
- 一定
- 挑戦する
- チャンス
- 変化する
- 子供達
- チップ
- 選択する
- 選択する
- 主張した
- はっきりと
- クラウド
- コード
- コイン
- 組み合わせ
- 組み合わせ
- コマーシャル
- コマンドと
- 一般に
- 伝える
- 企業
- 会社
- 会社の
- コンプリート
- 完全に
- 複雑な
- 複雑さ
- 損害を受けた
- 妥協する
- 計算
- コンピューティング
- 懸念事項
- 条件
- 条件
- 講演
- お問合せ
- コンセンサス
- その結果
- 検討
- 見なさ
- 含まれている
- 制御
- controls
- 納得させる
- 正しい
- 破損した
- 費用
- 可能性
- コース
- 作ります
- 作成
- 創造
- クリエイター
- 重大な
- 重要な側面
- 重大な
- 現在
- カストディアン
- 親権
- Customers
- 危険な
- 衰退
- 減少
- 考える
- 定義済みの
- 需要
- 実証
- 展開
- 派生
- 説明
- 設計
- 設計
- 希望
- 詳細
- 詳細な
- 細部
- 検出
- 開発者
- デバイス
- Devices
- 異なります
- 難しい
- 減少する
- 直接に
- 取締役
- 消えていく
- 悲惨な
- 発見する
- 発見する
- 議論する
- 議論
- 表示される
- do
- ありません
- そうではありません
- 行われ
- 原因
- 間に
- 各
- 容易
- 簡単に
- 努力
- どちら
- 排除する
- 排除
- ほかに
- 強調する
- 採用
- enable
- 使用可能
- 可能
- end
- 強制します
- 十分な
- 確保
- 確保する
- 入る
- 魅力的
- 全体
- 完全に
- エンティティ
- 装置
- エラー
- 特に
- 本質的な
- 本質的に
- 確立する
- 等
- 評価
- さらに
- EVER
- あらゆる
- すべてのもの
- 正確に
- 例
- 例
- 興奮した
- 実行します
- 実行された
- 運動
- 存在
- 予想される
- 体験
- 期限切れ
- 悪用する
- 探検する
- export
- 拡張する
- 外部
- 極端な
- 容易にする
- 要因
- 失敗
- 不良解析
- かなり
- 秋
- 遠く
- 特徴
- 特徴
- 2月
- 少数の
- ファイナル
- ファイナンシャル
- 財務履歴
- もう完成させ、ワークスペースに掲示しましたか?
- 名
- フレキシブル
- フリップ
- フォーカス
- フォロー中
- 次
- に前進
- フォワード
- 4
- フレームワーク
- 頻繁に
- 友人
- から
- フル
- 完全に
- 機能性
- ファンド
- 資金
- さらに
- 無駄な
- 未来
- 一般的用途
- 一般に
- 生成する
- 生成された
- 生成
- 生成
- 世代
- 与えられた
- Go
- 行く
- 良い
- 素晴らしい
- 大いに
- 持っていました
- 半分
- Hardware
- ハードウェアデバイス
- ハードウェアの財布
- ハードウェア ウォレット メーカー
- ハードウェア財布
- 有害な
- 持ってる
- 持って
- 助けます
- それゆえ
- history
- 希望
- host
- 主催
- HOT
- 認定条件
- しかしながら
- HTTP
- HTTPS
- 巨大な
- 人間
- アイデア
- 理想
- 考え
- 識別する
- if
- 直ちに
- 影響
- 影響を与える
- 実装
- import
- 重要
- 不可能
- 改善します
- in
- 含ま
- 含めて
- 組み込む
- 増加
- 信じられない
- 確かに
- 独立しました
- 個別に
- 産業を変えます
- 情報
- 本質的に
- 初期
- 内部
- インサイダー
- インスパイア
- インストールする
- を取得する必要がある者
- 故意に
- 対話
- 相互作用的
- 関心
- 興味がある
- 興味深い
- インタフェース
- に
- 紹介する
- 導入
- 紹介します
- 押し付けがましい
- 関与
- 関与
- 問題
- IT
- ITS
- 自体
- ただ
- 一つだけ
- キー
- キー
- 知っている
- 知識
- 既知の
- 風景
- 言語
- ノートパソコン
- 姓
- 後で
- 弁護士
- リード
- LEARN
- 学習
- 最低
- 元帳
- 左
- 正当な
- less
- う
- レベル
- 活用
- ような
- 可能性が高い
- リンク
- リストされた
- ローディング
- ローカル
- 場所
- ロック
- 長い
- より長いです
- 見て
- のように見える
- 失う
- 負け
- 損失
- 損失
- 失われた
- 機械
- メイン
- 大多数
- make
- 作る
- 作成
- マルウェア
- 管理する
- 管理する
- 操作する
- 方法
- メーカー
- メーカー
- 多くの
- 3月
- 一致
- 五月..
- 手段
- 措置
- メカニズム
- ミディアム
- 言及した
- 単に
- メッセージ
- メッセージ
- 方法
- メソッド
- マイアミ
- かもしれない
- ミニスクリプト
- 少数
- 分
- ミッション
- ミス
- お金
- モニタリング
- ヶ月
- 他には?
- さらに
- 最も
- 主に
- 移動
- ずっと
- の試合に
- マルチシグ
- しなければなりません
- 名
- 近づいている
- 必要
- 必要
- 必要とされる
- ニーズ
- マイナスに
- ネットワーキング
- 決して
- 新作
- ニュース
- 次の
- nice
- いいえ
- 非技術的な
- 通常の
- 11月
- November 2021
- 今
- 数
- 番号
- 取得する
- of
- 提供
- 提供すること
- オファー
- オンライン
- on
- 新人研修
- かつて
- ONE
- もの
- の
- 開いた
- オープンソース
- 開きます
- オペレーティング
- 業務執行統括
- 機会
- オプション
- or
- 注文
- その他
- さもないと
- 私たちの
- でる
- 概説
- 外側
- が
- 全体
- 概要
- 自分の
- 所有者
- 紙素材
- 最高の
- 部
- 特に
- パーティー
- path
- 支払う
- 実行する
- おそらく
- 期間
- 永久に
- 相
- 電話
- 場所
- 場所
- プラトン
- プラトンデータインテリジェンス
- プラトデータ
- ポイント
- ポイント
- ポリシー
- 方針
- 人気
- の可能性
- 可能
- おそらく
- ポスト
- 潜在的な
- :
- 電力
- 実用的
- 事実上
- 練習
- 正確な
- 正確に
- 予測する
- 予測可能な
- プレゼンス
- 現在
- PLM platform.
- 防ぐ
- を防止
- 前
- 前に
- 主に
- 主要な
- printing
- 事前の
- プライバシー
- プライベート
- 秘密鍵
- 秘密鍵
- 問題
- 問題
- 手続き
- プロセス
- 作り出す
- 生産された
- 生産する
- 正しく
- プロパティ
- 財産
- 提案された
- 守る
- 保護された
- 保護
- 保護
- プロトコル
- 受験する
- 提供します
- 提供
- 公共
- 公開鍵
- 公開鍵
- パブリッシュ
- 公表
- 出版
- 目的
- 置きます
- パッティング
- 質問
- レース
- ランダム
- 身代金
- むしろ
- リーチ
- 読む
- リーダー
- 実現
- 理由
- 受け入れ
- 最近
- 認識する
- 記録
- 回復
- 指し
- 登録
- 登録された
- 登録
- 相対的に
- リリース
- リリース
- 頼る
- 覚えています
- replace
- 表す
- で表さ
- 評判
- 必要とする
- の提出が必要です
- 必要
- 結果として
- リテンションを維持
- return
- 明らかにする
- 右
- リスク
- リスク
- リスキーな
- ロードマップ
- 堅牢な
- 丈夫
- 職種
- 役割
- ランニング
- runs
- 同じ
- 言う
- スケーラビリティ
- スキャン
- シナリオ
- スキーム
- スキーム
- シュノール
- 画面
- スクリプト
- 二番
- セクション
- 安全に
- しっかりと
- セキュリティ
- シード
- シーズ
- を求める
- 思われる
- と思われる
- SegWit
- 自己管理
- 送信
- 敏感な
- 送信
- 別
- サービス
- セッションに
- いくつかの
- ショート
- すべき
- 示されました
- 符号
- 署名
- 重要
- 著しく
- 署名
- サイン
- 同様の
- 簡単な拡張で
- 単純化
- から
- 小さい
- スマート
- So
- ソフトウェア
- 溶液
- ソリューション
- 解決する
- 一部
- 誰か
- すぐに
- 洗練された
- ソース
- スペース
- 特化する
- 特定の
- 仕様
- 過ごす
- 支出
- 標準
- スタンド
- 開始
- Status:
- 手順
- ステップ
- まだ
- ストレージ利用料
- 保存され
- 保存
- 作戦
- 力
- 文字列
- 強い
- 奮闘
- 成功した
- 首尾よく
- そのような
- まとめる
- スーパーチャージ
- サポート
- 支援する
- サポート
- 想定
- 全身の
- システミックリスク
- システム
- タックル
- 取る
- 主人公
- ターゲット
- ターゲット
- 技術的
- 技術的に
- テクノロジー
- 条件
- より
- それ
- コイン
- アプリ環境に合わせて
- それら
- 自分自身
- その後
- そこ。
- それによって
- したがって、
- ボーマン
- 彼ら
- 物事
- 考える
- 三番
- この
- それらの
- 脅威
- 三
- しきい値
- 介して
- 従って
- 時間
- 時間がかかる
- 〜へ
- 今日
- 今日の
- あまりに
- 豊富なツール群
- トピック
- トータル
- に向かって
- トレース
- 追跡する
- 実績
- トレーニング
- トランザクション
- 取引
- 遷移
- 翻訳する
- 財務省
- 樹木類
- true
- 信頼
- 信頼されている
- 信頼できない
- 真実
- ツイスト
- 2
- 典型的な
- できません
- わかる
- 解き放つ
- 異なり、
- アンロック
- ロック解除
- 予測できない
- まで
- アップグレード
- us
- 使いやすさ
- つかいます
- 中古
- ユーザー
- 操作方法
- users
- 使用されます
- 活用する
- 利用された
- 活用
- ux
- 検証
- 多様
- さまざまな
- 広大な
- ベンダー
- 検証
- 確認する
- バージョン
- 非常に
- 実行可能な
- 極めて重要な
- 脆弱性
- wait
- 財布
- 財布
- 欲しいです
- ました
- 仕方..
- 方法
- we
- した
- この試験は
- いつ
- たびに
- かどうか
- which
- while
- 全体
- なぜ
- Wikipedia
- 意志
- 以内
- 無し
- 言葉
- 世界
- でしょう
- 書かれた
- 間違った
- 年
- まだ
- You
- あなたの
- あなた自身
- ゼファーネット
- ゼロ