パート 2: 元帳回復の起源 - 株式を安全に配布する |台帳

プラトン再発行

フォロワー： 0

のブログシリーズの第 XNUMX 部へようこそ。元帳の回復の創世記！私たちの目標は、シードリカバリサービスを構築する際に遭遇する多くの技術的ハードルと、Ledger Recover が安全な設計とインフラストラクチャを使用してそれらをどのように解決するかを調査することです。

前編では、シークレットリカバリフレーズを分割してバックアップする方法と、Ledger Recover がそれをどのように実行するかを調べました。 Pedersen 検証可能な秘密の共有.

XNUMX つの株式を持っているので、次の質問は次のとおりです。 これらをバックアッププロバイダーに安全に配布するにはどうすればよいでしょうか? 実際、送信中に悪意のある当事者がすべての共有を傍受した場合、そもそもシードを分割する目的が無効になります。サイバーセキュリティでは、これを「中間者攻撃、攻撃者があなたと受信者の間に立ち、通信を改ざんして秘密を明らかにしようとします。

Ledger Recover を使用する場合、シードの送信は安全な配布メカニズムを通じて実行されます。これは、後で徹底的に説明するいくつかの暗号化ツールと数学的概念に依存しています。

まず、当面の問題をより詳しく説明します。次に、Ledger Recover がシード共有をバックアッププロバイダーに安全に配布するために活用するいくつかの暗号化ツールと数学的概念を紹介します。

中間宅配便: 現実世界の例

悪意のある仲介者から身を守る最も明白な方法は、一切の仲介者を持たないことです。自分で友人の家まで歩いて行くことも、閉鎖された同じ場所に友人を集めて分け前を渡すこともできます。しかし、あなたが同じ場所に配置されておらず、遠距離の知人に共有物を送りたい場合、これは非常に困難になります。

私たちが通信するネットワーク (郵便サービスなど) が本質的に信頼できないと仮定すると、盗聴者が私たちの秘密共有を決して盗まないことをどのように保証できるでしょうか?

アリスとボブ、そして悪名高きイブという XNUMX 人の有名な暗号人物を紹介する時が来ました。アリスにはボブと共有したい秘密があり、信頼できない配達員であるイブを通じてそれを送信する以外に選択肢はありませんでした。暗号的な言葉で言えば、 アリスとボブは、お互いに安全な通信チャネルを確立して、秘密を安全に交換したいと考えています。

アリスとボブができることは次のとおりです。

アリスは自分の秘密を箱に入れ、個人用の南京錠でロックしてからボブに送ります。
ボブは箱を受け取るとこう付け加えます。自分の南京錠を受け取り、送り返します。
アリスは、最後にもう一度送る前に、自分の鍵を使って箱から南京錠を取り出すことができます。
プロセスを完了するには、ボブはキーを使って南京錠を外し、ついにアリスから秘密を取り出します。

交換の間ずっと、イブが箱を手に持っているときはいつでも、それはアリスの鍵かボブの鍵、またはその両方によって常に保護されていました。

これは素晴らしいスタートではありますが、このシナリオには解決すべき問題がいくつか残っています。

相互認証: アリスとボブは、それぞれの南京錠が本当に相手から渡されたものであることを確認する確実な方法を必要としています。そうしないと、イブがそれを自分の箱と南京錠と交換し、アリスまたはボブを騙して自分が相手であると信じ込ませることができます。
前方秘匿性: イブが鍵のかかった箱を盗み、その後アリスまたはボブの鍵を盗んだ場合、彼女は元の秘密を取り戻すことができます。その代わりに、将来の長期キーの漏洩によって古い盗まれたパケットが危険にさらされないようにする必要があります。
プライバシーの保護: このシナリオでは、アリスとボブの住所が宅配業者に公開されます。このプロセスのデジタル版では、受信者について何も開示しないプロトコルが必要です。

デジタルメッセージの保護

デジタルセキュリティでは、 安全なチャネル XNUMX 者間でデータを転送する方法です 認証された そのようなデータの当事者秘密および 整合性 が保証されています。安全なチャネルを使用すると、攻撃者が通信を盗聴したり改ざんしたりすることはできません。

Ledger Recover のバックアップと復元のプロトコルは、 セキュアチャネルプロトコル、またはSCP。対称暗号化および非対称暗号化、証明書、デジタル署名など、最新の暗号化ツールボックスの複数のツールを使用します。
次のセクションでは、これらすべての概念について簡単に説明します。これにより、Ledger Recover で使用されるセキュリティスキーム全体を理解できるようになります。

対称暗号化: 強力だが制限のあるツール

二者間で交換されるデータの機密性を保証するために、通常、データは同じ秘密鍵を使用して暗号化および復号化されます。
このプロセスは次のように呼ばれます 対称暗号化、 これは、安全なチャネルの XNUMX つ以上の特性を保証する単一の秘密鍵を含むプリミティブの研究です。

対称暗号化は通信を保護する強力なツールではありますが、明らかな制限がいくつかあります。アリスがいくつかの暗号化されたメッセージをボブと交換したいとします。彼女はまず秘密鍵を選択し、それをボブと共有してから、メッセージの送信を開始します。
もちろん、問題は次のとおりです。アリスはどのようにして秘密鍵をボブと安全に共有するのでしょうか? 誰かが鍵を手に入れた場合、アリスとボブの通信は機密ではなくなります。
アリスはボブに直接会って鍵を渡すこともできますが、この場合、詮索好きな耳を避けて話し合いをしてはどうでしょうか?

デジタル通信の場合、対称キーを共有し、保護されたデータ交換を開始するための安全な方法が必要です。現代暗号学の XNUMX 人の巨人の研究を紹介する時が来ました。ホイットフィールド・ディフィーおよびマーティン・ヘルマン.

非対称暗号化: プライベートな部分を隠す

Diffie-Hellman鍵合意

ディフィーとヘルマンは、公開キー暗号化を使用して、通信を保護するための新しいアプローチを考案しました。彼らは、暗号化と復号化のための XNUMX つの異なるキーを持つプロトコルを定義しました。 XNUMX つのキーは一般的に次のように呼ばれます。 公開鍵と秘密鍵、データの暗号化/復号化および署名/検証に使用できるペアを形成します。

公開鍵と秘密鍵
公開キー暗号化は、ほとんどのデジタルセキュリティの基礎です。これはウェブ上でユーザーを保護するために使用され、すべてのパブリックブロックチェーン上のコインとトークンの所有権を証明する方法でもあります。

このトピックについて詳しくは、Ledger Academy をご覧ください。!

私たちにとって本当に魅力的なのは、Diffie と Hellman が公開鍵暗号を使用して対称鍵を配布することを提案した方法です。として知られる彼らの方法 ディフィー・ヘルマン鍵交換、 共有秘密について最終的に合意するための XNUMX つの当事者間のやり取りで構成されます。適切に実行された場合、盗聴者は盗聴した情報から同じ共有秘密を計算することはできません。

TL;DR は、上の図ではイブは数学的に秘密を解明できないということです。 k は、アリスとボブのすべての通信にアクセスできるにもかかわらずです。この共有秘密が盗聴者から安全である理由を理解するには、集団理論を少し掘り下げる必要があります。

Diffie-Hellman 鍵交換のセキュリティは、巡回群に関する離散対数問題の複雑さに依存しています。循環グループは、単一の要素によって生成されるグループです。
簡単に言うと、アリスとボブは次の手順を実行して共有秘密に同意します。 k:

アリスとボブは循環グループについて合意する G 秩序ある n 要素によって生成される g
アリスはランダムに数字を引く 0 < a < n そして送る pa = ga ∈G ボブへ
ボブはランダムに数字を引きます 0 < b < n そして送る pb = gb ∈G アリスへ
アリスは共有秘密を計算します k =(pb )a ∈G
ボブは共有秘密を計算します k =(pa )b ∈G

プロトコルの安全性は発見の難しさに依存します k =gab 与えられた g, ga, gb。これは計算ディフィー・ヘルマン仮定 (CDH)。 CDH は解決が難しいという仮説は、次のことを前提としています。離散対数問題解決するのは難しいです。

このスキームでは、共有秘密は盗聴から安全ですが、交換されるデータの出所については保証がありません。対話を安全に行うために、アリスとボブは何らかの方法でお互いの身元を証明する必要があります。

相互認証とデジタル署名

手書きの署名は通常、文書の内容を確認して受け入れるために使用されます。署名を作成できるのは署名者だけですが、署名がどのようなものかを「知っている」人なら誰でも、文書が正しい人によって署名されたことを確認できます。

デジタル署名は同様の特性を持ちながら、非対称暗号化を活用することで追加の強力な保証を提供します。

信頼性: メッセージが指定された公開キーに対応する秘密キーで署名されたことを誰でも検証できます。
否認防止: 署名者はメッセージに署名して送信したことを否定できません。
統合性: メッセージは送信中に変更されませんでした。

今、限り 私たちは公開鍵を知っており、信頼しています 特派員のデジタル署名を検証することで、すべてのメッセージの信頼性を確認できます。
ただし、実際のケースでは、ほとんどの場合、通信相手のことをよく知っていないか、セキュリティ上の理由から秘密鍵と公開鍵のペアを定期的に変更する必要がある場合があります。これには、次のような形での検証と信頼の追加レイヤーが必要になります。証明書、エンティティの説明とその公開キーが含まれています。

各証明書は親公開鍵によって署名されます。私たちが常に信頼するルート認証局 (またはルート CA) を持つことにより、連続したデジタル署名を使用して信頼のチェーンを作成できます。

楕円曲線: 次のレベルの公開鍵暗号化

楕円曲線暗号 (ECC) は、暗号化や署名スキームなどの暗号アプリケーションに楕円曲線を使用する公開鍵暗号のサブ領域です。
現在理解されている数学に基づいて、ECC は、次のような以前の公開キー暗号化システムよりもはるかに安全な基盤を提供します。 RSA.

同じセキュリティレベルでも、ECC は他の非対称暗号システムと比べてキーの長さが短いため、リソースが限られている組み込みシステムに適しています。
さらに詳しく知りたい場合は、この記事楕円曲線をより深く理解するのに役立ちます。

楕円曲線の次数
要素の順序 g グループの値は、Diffie-Hellman 鍵交換の重要なパラメータです。グループが楕円曲線の場合、その要素は点であり、その次数は、初期値でループする前にそれ自体に追加できる回数になります。
この加算は通常の実数の合計とは何の関係もありませんが、同様の加法性の性質があることに注意してください。

楕円曲線を見てみましょう E: はい2 =×3 + 2x +3 野原を越えて 𝔽97 例として。離散関数としては、下図の点で表されます。という点に焦点を当てていきます P =(3, 6) およびそのすべての倍数。

5 以降はそれがわかります。P、最初に戻り、前と同じポイントに到達します。スカラーの値が何であっても P を乗算すると、常に 5 つの初期点のいずれかに到達します。
したがって、次の順序 P は 5 で、生成されるサブグループにはちょうど 5 つの点が含まれます。ただし、暗号アプリケーションの場合、次数は 5 よりもはるかに大きいため、ランダム性が高まります。

すべてをマッシュアップ: 認証付き ECDH

これで、優れた鍵交換プロトコルを作成するために必要なツールがすべて揃いました。 楕円曲線ディフィーヘルマン (ECDH).

ECDH は、楕円曲線暗号を使用してキーペアと共有秘密を生成することにより、上で説明した Diffie-Hellman キー交換を実装する標準化された暗号スキームです。

まず、楕円曲線とその生成点を選択します。その後、両者は信頼できる証明書を交換し、これによりそれぞれの公開鍵の信頼性を検証できるようになります。認証されると、次のように計算される共有秘密 k を生成できます。

k = dA 。 dB 。 G
dA: アリスの秘密鍵
dB: ボブの秘密鍵
G：ECポイント

を達成するために 前方の秘密 プロパティでは、アリスとボブの両方のキーのペアは一時的である必要があります。つまり、それらはその場で生成され、プロトコルの XNUMX 回の実行に使用されます。楕円曲線ディフィーヘルマンエフェメラル (ECDHE) について話します。このシナリオでは、一時キーはデバイス上の静的キーと HSM の両方によって署名され、キーの強力な認証が可能になります。たとえ将来的に静的キーへの不正アクセスが発生したとしても、一時キーで保護されている交換機に復号化機能は付与されません。

さらに、デバイスの静的キーを安全なチャネル内に隠すことにより、プロトコルに注目すべき機能強化を実装しました。この予防措置により、攻撃者がデバイスの静的証明書を可視化することができなくなり、バックアップ/復元操作中に使用される一意の識別子の漏洩につながる可能性があります。

Ledger Recover に戻る: シードの旅

さて、少し休憩しましょう。

私たちはセキュリティと数学の両方に関連する多くのトピックを取り上げてきました。その結果、安全でないネットワーク上でも安全に通信するためのプロトコルが完成しました。これまでに見てきたことを要約しましょう。

XNUMX つのエンティティは、 ユニークな秘密 おかげ ECDHE、これは Diffie-Hellman 鍵合意プロトコルの実装であり、 一時的なキー 前方機密性を保護するため。各エンティティができることは、 本物であることを確認する 彼らの特派員のイニシャルのおかげで 証明書の検証.

Ledger Recover の場合、セキュアチャネルプロトコルを利用して XNUMX つのセキュアチャネルを確立しました。これらのチャネルは、デバイスを各バックアッププロバイダーおよびオーケストレーターに接続します。これらのすべてにはハードウェアセキュリティモジュール (HSM) が装備されています。

各アクターは、信頼チェーンのルートとして機能する台帳証明書によって署名された個人証明書を保持します。ユーザーのデバイスが最初にバックアップを実行する意図を Orchestrator に送信すると、認証された ECDHE が開始されます。これらの下に mTLS オーケストレーターは、セッション中に、将来の安全なチャネルをユーザーの特定のバックアップ要求に結び付ける情報と、後でシードの復元を実行するときに検証が要求されるユーザーの ID を送信します。

HSM を使用して秘密を保護する
私たちはそれを回避しようと努めますが、場合によってはサーバー上でシークレットを保存し、処理する必要があります。サーバーとそのアクセスを保護することは簡単な作業ではないため、これは危険を伴う可能性があります。このリスクを軽減するために、セキュリティを重視する企業や業界では、ハードウェアセキュリティモジュール。これらは、暗号キーを保護し、暗号処理を提供する特殊なハードウェアです。 HSM については、このブログシリーズの後半でさらに詳しく説明します。

最終的に、操作全体の最も重要な部分を実行する準備がすべて整いました。 ユーザーのシードの XNUMX つのシェアを送信します。

もう一度、新しい安全なチャネルを作成しますが、今回はユーザーのレジャーデバイスとバックアッププロバイダーの HSM の間に作成されます。 直接に。シード共有は、正しい宛先に到達することを保証しながら、エンドツーエンドの暗号化チャネルで最終的な保管場所に送信されます (ここで、Pedersen 秘密共有の検証可能性が導入されました) 一部1 便利です）。
ユーザーのデバイスはバックアッププロバイダーの HSM を XNUMX つずつ認証し、バックアッププロバイダーは、この特定のバックアップリクエストを開始した固有の公式 Ledger デバイスと交換していることを認識します。
ユーザーのデバイスとバックアッププロバイダーの HSM 以外の誰も、オーケストレーターであっても、相互認証されたセキュアチャネルの対称キーによって暗号化されたシード共有を見ることはありません。

安全に受け取られ、保管されていますか?

このパートでは、いくつかの新しい概念を導入しましたが、その中にはかなり技術的なものもあります。これらの概念はそれぞれ、交換の機密性と完全性を保証する安全な送信を確立するために必要です。ネットワークの安全性とは関係なく、 改ざんや傍受を恐れることなく秘密の共有を送信できるようになりました。それはかなりのアップグレードです！