署名

クリプトにおける署名とは？

クリプトにおける署名とは、ウォレット、秘密鍵、または承認されたアカウントが、特定のトランザクション、メッセージ、注文、投票、スマートコントラクトのアクションを承認したことを示すデジタル証明です。

手書きの署名とは異なり、クリプト署名は暗号学によって作成され、秘密鍵を公開せずにソフトウェアで確認できます。

公式のNISTデジタル署名標準では、デジタル署名は不正なデータ変更を検出し、署名者の身元を認証するために使用されると説明されています。

ブロックチェーンシステムでは、署名は、秘密鍵を管理する人物またはシステムが特定のデータを承認したことを証明します。

このため、ユーザーはブロックチェーン自体にユーザー名、パスワード、銀行型の認証コードを入力せずに暗号資産を送付できます。

ウォレットがトランザクションに署名し、ネットワークはその署名が資金を支出またはアクションを実行しようとするアカウントに対応することを検証します。

署名は、署名者がトランザクションを理解していたことを証明するものではありません。

署名済みデータに対して、秘密鍵、ウォレット、またはコントラクトベースのアカウントが有効な承認を生成したことを証明します。

簡単に言えば、クリプト署名は「このウォレットがこの正確なアクションを承認した」とブロックチェーンまたはアプリケーションに伝える数学的な承認です。

署名がクリプトで重要な理由

クリプトの所有権は従来のアカウントログインシステムではなく、暗号学的承認に基づくため、署名は重要です。

公式のEthereumアカウントのドキュメントでは、アカウントは公開鍵と秘密鍵のペアを使用し、秘密鍵はメッセージおよびトランザクションの署名に使用されると説明されています。

ユーザーがトランザクションに署名すると、ブロックチェーンは秘密鍵を確認せずに、アカウント所有者がトランザクションを承認したことを確認できます。

このため、署名はセルフカストディにおける最も重要な構成要素の一つです。

署名がなければ、ブロックチェーンは誰がコインを移動し、トークンを承認し、ガバナンスで投票し、報酬を請求し、スマートコントラクトとやり取りできるかを安全に判断できません。

署名により、ユーザーがウォレットから直接アクションを承認できるため、分散型アプリケーションも実現します。

スマートコントラクトは、署名済みpermit、注文、承認、投票を受け入れ、その承認に基づいてロジックを実行できます。

ブリッジ、マルチシグウォレット、アカウント抽象化システムも、リクエストが有効かの判断に署名を利用する場合があります。

ユーザーにとって署名は、実際の資産、権限、権利が変更される前の最終段階となることが多いため重要です。

開発者にとって署名は、脆弱な署名フローが一つでも、プロトコル全体をリプレイ攻撃、フィッシング、不正実行にさらす可能性があるため重要です。

クリプト署名の仕組み

クリプト署名は、ウォレットソフトウェアが秘密鍵を使用して特定のトランザクションまたはメッセージに署名すると作成されます。

まず、ウォレットは承認が必要なデータを準備します。

次に、ウォレットはブロックチェーンの署名ルールに従ってそのデータをハッシュ化またはエンコードします。

秘密鍵はデジタル署名アルゴリズム内で使用され、署名を生成します。

署名はトランザクションに添付されるか、メッセージとともに提出されます。

他のソフトウェアは、署名、署名済みデータ、公開鍵またはアドレスを使用し、署名が有効かを確認できます。

データが変更された場合、同じ署名は変更済みデータに対して検証できなくなるはずです。

つまり、署名は承認とデータ完全性の両方を保護します。

有効な署名は、署名者が曖昧な一般的意図ではなく、特定のペイロードを承認したことを証明します。

そのため、ユーザーはウォレットが何への署名を求めているのかを正確に確認すべきです。

秘密鍵

秘密鍵はクリプト署名を作成する秘密の値です。

秘密鍵にアクセスできる人は通常、トランザクションに署名し、関連アカウントから資産を移動できるため、決して共有しないでください。

ブロックチェーンは通常、紛失した秘密鍵をリセットできないため、秘密鍵はメールのパスワードとは異なります。

ウォレットは、ユーザーがアカウントをバックアップできるよう、秘密鍵の管理をシードフレーズまたはリカバリーフレーズに変換することがよくあります。

公式のBitcoinウォレットセキュリティガイドは、秘密鍵の管理が資金の管理に不可欠であるため、ユーザーにウォレットを保護するよう警告しています。

秘密鍵がデータに署名する際、秘密鍵自体がウォレットまたは署名デバイスの外へ出る必要はありません。

このため、ハードウェアウォレットは、秘密鍵をコンピュータやスマートフォンから隔離したまま署名を作成できます。

秘密鍵が盗まれると、攻撃者は有効な署名を作成でき、ブロックチェーンはそれらの署名を正当なものとして扱う可能性があります。

したがって、署名の安全性は秘密鍵の安全性から始まります。

公開鍵

公開鍵は、対応する秘密鍵によって作成された署名を他者が検証できるようにする値です。

通常の暗号学的前提の下では秘密鍵を明らかにしないため、公開鍵は共有できます。

多くのブロックチェーンアドレスは、公開鍵または公開鍵ハッシュから導出されます。

署名は、署名者が公開鍵またはアドレスに関連する秘密鍵を管理していたことを証明できます。

ただし、そのアドレスが別のプロセスを通じてIDと結び付けられていない限り、署名者の現実世界における身元を証明するものではありません。

たとえば、有効な署名はウォレットアドレスの管理を証明できますが、署名者が信頼できることを証明するものではありません。

公開鍵と署名は、中央のアカウント管理者なしに所有権を支えるために連携します。

これが、暗号資産をピアツーピアで移転できる主な理由の一つです。

公開鍵は管理を検証し、秘密鍵は管理を作り出します。

トランザクション署名

トランザクション署名は、ブロックチェーントランザクションに添付される署名です。

必要な署名者がトランザクションの内容を承認したことを証明します。

Bitcoinでは、署名は、支出者がスクリプトルールに基づき特定の出力を支出する権限を持つことの証明に役立ちます。

公式のBitcoinトランザクション開発者ガイドでは、Bitcoinはsecp256k1曲線によるECDSAを使用すると説明されています。

Ethereum系システムでは、トランザクション署名により、アカウントがnonceを使用し、手数料を支払い、価値を送付し、コントラクトデータを呼び出すことを承認します。

Solanaでは、実行される指示に応じて、トランザクションに複数アカウントの署名が必要となる場合があります。

公式のSolanaトランザクションのドキュメントでは、各署名者が64バイトのEd25519署名を提供すると説明されています。

必要なトランザクション署名が欠落または無効であれば、ネットワークはトランザクションを拒否すべきです。

このため、トランザクション署名は不正送金を防ぐ中核です。

メッセージ署名

メッセージ署名とは、直ちにオンチェーントランザクションにならない可能性があるメッセージへの署名です。

ユーザーは、分散型アプリケーションへのログイン、ウォレット所有権の証明、オフチェーン注文の承認、ガスを支払わない投票、後で使用するpermitの作成のためにメッセージへ署名する場合があります。

メッセージ署名は、直ちにトランザクションをブロードキャストしない場合があるため、無害に感じられることがあります。

ただし、スマートコントラクトまたはアプリケーションが後に受け入れる場合、署名済みメッセージは強力なアクションを承認できる可能性があります。

たとえば、署名済みpermitにより、別のアドレスが特定のルールの下でトークンを支出できる場合があります。

署名済み注文により、後に取引が執行される場合があります。

署名済み請求により、誰かが配布コントラクトからトークンを受け取れる場合があります。

メッセージ署名は実際の金銭的意味を持ち得るため、ユーザーはメッセージプロンプトを注意深く読むべきです。

ガスレス署名はリスクフリーな署名を意味しません。

署名と署名検証の違い

署名は署名者が作成する証明です。

署名検証は、その証明が有効かを確認するプロセスです。

署名は、ウォレットが秘密鍵またはアカウントルールを使用してデータを承認する際に行われます。

検証は、ノード、ウォレット、アプリケーション、スマートコントラクト、サーバーが、署名が想定された署名者およびメッセージと一致することを確認する際に行われます。

安全なクリプト承認には両方の手順が必要です。

検証されない署名は有用ではありません。

正しい署名がない検証プロセスは、アクションを拒否すべきです。

ユーザーは通常、ウォレットプロンプトを通じて署名を経験し、検証はバックグラウンドで行われます。

開発者は、誤った検証ルールが本来受け入れるべきでない署名を受け入れる可能性があるため、両方を理解しなければなりません。

ECDSA署名

ECDSAはElliptic Curve Digital Signature Algorithmの略です。

BitcoinおよびEthereum系システムでは、アカウントおよびトランザクション署名にsecp256k1曲線上のECDSAが一般的に使用されます。

ECDSA署名は通常、ソフトウェアが秘密鍵が署名済みデータを承認したことを検証できる署名値で表されます。

Ethereum系の署名には、署名から署名者の公開鍵またはアドレスを復元するのに役立つリカバリー値が含まれることがよくあります。

ECDSAはクリプトで広く使用されていますが、慎重に実装する必要があります。

署名時の弱い乱数またはnonceの再利用は秘密鍵を露出させる可能性があります。

不適切な署名検証は、可鍛性またはリプレイの問題を生む可能性があります。

開発者はカスタムECDSAコードではなく、成熟した暗号ライブラリを使用すべきです。

ユーザーは、有効なECDSA署名が鍵の管理を強く証明する一方、署名済みアクションの安全性を証明するものではないことを理解すべきです。

Schnorr署名

Schnorr署名は、一部のBitcoin関連の文脈および他の暗号システムで使用される別の種類のデジタル署名です。

BIP-340 Schnorr署名仕様は、secp256k1曲線用のSchnorr署名方式を定義しています。

Schnorr署名は、特定のシステムにおいて、より単純な集約特性や明確な署名設計などの利点を支援できます。

Bitcoinでは、Schnorr署名はTaproot時代の改善と関連しています。

署名集約および関連設計は、高度なユースケースの一部でデータサイズを減らし、プライバシーを改善できる可能性があります。

通常のウォレット利用では、ユーザーがECDSAとSchnorrを手動で選択することは通常ありません。

ウォレット、スクリプトタイプ、ネットワークルールが、適用される署名方法を決定します。

開発者と上級ユーザーは、異なる署名方式に異なるルールと安全性の前提があることを理解すべきです。

署名形式は、ブロックチェーンのセキュリティアーキテクチャの一部です。

Ed25519署名

Ed25519は、通常のトランザクション署名でSolanaを含む複数のブロックチェーンシステムが使用するデジタル署名方式です。

Ed25519署名はコンパクトかつ効率的であり、高スループットのブロックチェーン環境に有用です。

Solanaトランザクションでは、トランザクションメッセージで署名者として指定されたアカウントからの署名が必要です。

これらの署名は、必要な権限者が指示を承認したことを証明します。

Solana開発者にとって、アカウントがプログラムへ正しく渡されたと仮定するだけでは不十分です。

署名者権限が必要な場合、プログラムは正しいアカウントが署名したかも確認しなければなりません。

署名者チェックの欠落は、深刻なスマートコントラクトまたはプログラムの脆弱性になり得ます。

ユーザーは、Ed25519署名も承認イベントであることを覚えておくべきです。

誤ったトランザクションを承認すれば、資産が移動したり権限が付与されたりする可能性があります。

署名ペイロード

署名ペイロードとは、署名される正確なデータです。

トランザクションの場合、ネットワークにより、送信者情報、受取人情報、価値、手数料、nonce、チェーンID、指示、コントラクトデータ、その他のフィールドを含む可能性があります。

メッセージの場合、ログインチャレンジ、注文詳細、承認金額、期限、nonce、ガバナンス投票を含む可能性があります。

同じ秘密鍵は多数の異なるペイロードに署名できるため、意味は正確なペイロードから生じます。

そのため、何を承認するか理解できない場合、ユーザーは曖昧または読めないデータに署名すべきではありません。

あるペイロードへの署名は、別のペイロードに対して有効となるべきではありません。

優れた署名標準は、ペイロードを明確かつ文脈固有のものにします。

不適切な署名設計は、署名を再利用可能、混乱を招くもの、危険なものにする可能性があります。

クリプトでは、ペイロードが指示であり、署名が承認です。

署名ハッシュ

署名ハッシュとは、署名するデータのハッシュです。

ハッシュ化は、署名アルゴリズムが処理する前にデータを固定サイズのダイジェストへ変換します。

これにより署名の効率が高まり、わずかなデータ変更でも異なる署名結果となることを保証する助けになります。

ブロックチェーンおよび標準ごとに、異なるハッシュ化およびエンコードルールを使用します。

Bitcoinのトランザクション署名、Ethereumの型付きデータ署名、Solanaのトランザクション署名は、すべて同じ形式ではありません。

開発者は、対象ネットワークと署名標準に対する正しいハッシュルールを使う必要があります。

誤ったハッシュに署名または検証すると、署名が失敗する、または危険な不一致を生む可能性があります。

ユーザーは通常ハッシュを直接見ることはありませんが、ウォレットとアプリケーションが正しく構築することに依存しています。

正しいデータがハッシュ化され署名された場合にのみ、署名には意味があります。

Ethereumの署名データ

Ethereumは、メッセージおよび型付きデータに複数の署名形式をサポートしています。

公式のERC-191署名データ標準は、Ethereumコントラクトで署名データを処理する標準形式を定義しています。

ERC-191は、署名済みメッセージと生のトランザクションを区別し、署名データをより安全に処理するのに役立ちます。

公式のEIP-712型付き構造化データ標準は、型付き構造化データをハッシュ化して署名する方法を定義しています。

EIP-712は、署名プロンプトをより読みやすく、より文脈固有のものにできるため重要です。

型付きデータ署名には、アプリケーション、チェーン、コントラクト、バージョン、アクション詳細などのドメイン情報を含めることができます。

正しく実装される場合、これは異なるアプリケーションまたはネットワーク間のリプレイリスク低減に役立ちます。

読みやすいプロンプトでもリスクのあるアクションを承認し得るため、ユーザーは型付きデータ署名を注意深く確認すべきです。

標準は明確性を改善しますが、注意の必要性を置き換えるものではありません。

スマートコントラクト署名

スマートコントラクトウォレットは、単純な秘密鍵アカウントとは異なる署名ロジックを使用できます。

公式のERC-1271署名検証標準は、特定のハッシュに対して署名が有効かをコントラクトが確認する方法を定義しています。

スマートコントラクトウォレットでは、複数の承認、支出上限、セッションキー、復旧ルール、ガバナンスベースの承認が必要となる場合があるため、これは重要です。

通常の外部所有アカウントは、秘密鍵で直接署名を作成できます。

スマートコントラクトウォレットは、コントラクトロジックを通じて承認を検証する場合があります。

単純なアカウント署名だけをサポートするアプリケーションは、スマートコントラクトウォレットで機能しない可能性があります。

アカウント抽象化の拡大に伴い、署名システムはより柔軟になっています。

公式のEthereumアカウント抽象化ロードマップでは、アカウント抽象化によりウォレットのプログラム可能性を高められると説明されています。

この環境では、署名は鍵、グループ、ルールセット、スマートコントラクトアカウントポリシーによる承認を意味し得ます。

マルチシグ

マルチシグウォレットでは、アクションを実行する前に複数の署名または承認が必要です。

たとえば、ウォレットは3人中2人、5人中3人の署名者を必要とする場合があります。

盗まれた鍵が1つだけでは資金移動に不十分となる可能性があるため、マルチシグシステムは単一鍵リスクを低減します。

トレジャリー、プロトコル管理者ロール、カストディワークフロー、チーム管理資金で広く使用されています。

マルチシグ構成も、明確なトランザクションレビューと署名者の独立性に依存します。

複数の署名者が同じ悪意あるトランザクションを承認した場合でも、トランザクションは実行される可能性があります。

したがって、マルチシグの安全性には技術面と運用面の両方があります。

優れたマルチシグ運用には、別々のデバイス、別々の人物、明確なポリシー、トランザクションシミュレーション、慎重なアドレス確認が含まれます。

複数の署名は安全性を高められますが、人間の判断の必要性をなくすものではありません。

しきい値署名

しきい値署名は、必要な数の参加者が協力して一つの有効な署名を生成する暗号システムです。

オンチェーンで複数の個別署名を表示する場合がある単純なマルチシグとは異なり、しきい値署名は一つの通常の署名として表示されることがあります。

チェーンと実装に応じて、プライバシーの改善、データサイズの削減、機関向けカストディ設計の支援が可能です。

しきい値署名では、どの一人の参加者も完全な署名秘密情報を単独で保持する必要がないため、単一鍵リスクを低減できます。

一方で、参加者が正しく協調する必要があるため、運用上の複雑さが生じることもあります。

あまりに多くの参加者がオフライン、侵害、または利用不能となる場合、しきい値システムは失敗する可能性があります。

ユーザーは、しきい値署名を使用するウォレットまたはサービスの背後にあるカストディモデルを理解すべきです。

主な考え方は、一つのデバイスまたは人物に完全な管理権を与えずに、署名権限を分散できることです。

しきい値署名は、クリプト署名が1つの鍵と1つのウォレットを超えた高度なセキュリティ設計を支援できることを示しています。

署名とトークン承認

トークンまたはアプリケーションが署名済み承認フローをサポートする場合、署名はトークン承認を許可できます。

通常のトークン承認は、オンチェーントランザクションとして送信されることがよくあります。

署名済み承認は、オフチェーンで作成され、後に別の当事者またはコントラクトが提出できる場合があります。

これは時間と手数料を節約できる可能性がありますが、ユーザーを混乱させる可能性もあります。

ユーザーは、実際には支出権限を付与しているにもかかわらず、単にメッセージに署名しているだけだと考える場合があります。

関連する場合、署名済み承認にはトークン、所有者、支出者、金額、nonce、期限、チェーン、検証コントラクトを含めるべきです。

これらのフィールドが欠ける、または不明確な場合、ユーザーはより大きなフィッシングおよびリプレイリスクに直面します。

ユーザーは承認署名を承認トランザクションと同様に慎重に扱うべきです。

支出権を付与する署名は、直接トランザクションと同じくらい危険となる可能性があります。

署名とガバナンス

ガバナンスシステムは、投票の収集、投票権の委任、提案アクションの承認に署名を使用できます。

オフチェーン投票では、ユーザーが選択を表す構造化メッセージに署名することがよくあります。

これにより、取引手数料を減らし、参加を容易にできる可能性があります。

ただし、ガバナンス署名は実際のプロトコル上の決定に影響し得ます。

署名済み投票は、トレジャリー支出、アップグレード、パラメーター変更、コミュニティの決定に影響する可能性があります。

ユーザーは承認前にガバナンス署名プロンプトを注意深く読むべきです。

開発者は、署名ペイロードに提案識別子、チェーン情報、投票選択、期限、ガバナンスドメインデータを含めるべきです。

優れたガバナンス署名システムは、曖昧さとリプレイリスクを低減します。

有効なガバナンス署名はウォレットの承認を証明するものであり、十分な情報に基づく同意を証明するものではありません。

署名とブリッジ

多くのブリッジシステムは、クロスチェーンメッセージ、出金、ミント、バーン、ロック済み資産のリリースを承認するために署名を使用します。

ブリッジは、バリデーター、リレイヤー、委員会、しきい値署名者、または別の検証システムからの署名に依存する場合があります。

ブリッジ署名が偽造、リプレイ、または不正に検証された場合、資産が不適切にリリースまたはミントされる可能性があります。

ブリッジ署名ペイロードには、送信元チェーン、送付先チェーン、メッセージID、トークン、金額、受取人、nonce、ドメインの文脈を含めるべきです。

ブリッジは異なる安全性の前提を持つシステムを接続するため、高リスクです。

有効なブリッジ署名の強度は、ブリッジの署名者セット、検証ルール、カストディモデル、スマートコントラクトの安全性に依存します。

署名を使用しているという理由だけで、ブリッジが安全だと考えるべきではありません。

署名は多くのブリッジ設計に必要ですが、完全なブリッジセキュリティの保証ではありません。

クロスチェーン署名は、誤りが複数のネットワーク上の資産に影響する可能性があるため、慎重な設計が必要です。

署名のリプレイリスク

リプレイリスクは、有効な署名が本来有効であるべきでない場所で再利用される場合に生じます。

署名データにチェーンIDが含まれない場合、一方のチェーン用の署名が別のチェーンで再利用される可能性があります。

署名データに検証コントラクトアドレスが含まれない場合、一方のコントラクト用の署名が別のコントラクトで再利用される可能性があります。

署名データにnonceが含まれない、またはnonceが使用済みとして記録されない場合、一つの注文用の署名が繰り返し再利用される可能性があります。

リプレイリスクは、署名設計における最も重要な危険の一つです。

開発者は、nonce、期限、ドメインセパレーター、チェーンID、コントラクトアドレス、アクションタイプ、使用済み署名の追跡によりリプレイリスクを低減します。

ユーザーは、曖昧な署名を避け、署名詳細を表示する信頼できるインターフェースを使用することでリプレイリスクを減らします。

署名は数学的に有効でも、誤った文脈で受け入れられる場合は危険です。

優れた署名は、具体的で、制限され、意図した目的以外で再利用しにくいものです。

署名の可鍛性

署名の可鍛性とは、特定の条件下で、同じメッセージと署名者に対して複数の署名値が有効となることを指します。

システムが各有効署名には一つの形式しかないと仮定する場合、問題となる可能性があります。

ECDSAベースのシステムでは、開発者は可鍛性リスクを低減するため、正規署名ルールを使用することがよくあります。

可鍛性は、リプレイ追跡、トランザクションID、注文マッチング、署名の一意性に関する前提に影響する可能性があります。

大半のユーザーは、ウォレットとライブラリが処理するため、この問題を直接目にすることはありません。

ただし、スマートコントラクト、注文システム、検証ロジックを構築する開発者は理解する必要があります。

成熟したライブラリの利用は、署名ルールを手動で実装するより安全です。

署名の可鍛性は、小さな暗号学的詳細が大きなプロトコル上の問題を生み得ることを示しています。

署名は数学的な面とプロトコル固有の面の両方で有効でなければなりません。

署名とフィッシング

フィッシングは、署名に関する最大のユーザーリスクの一つです。

フィッシングサイトは、攻撃者に利益をもたらすトランザクション、permit、メッセージ、承認、注文にユーザーをだまして署名させる可能性があります。

ユーザーがだまされていても、署名は完全に有効である場合があります。

公式の暗号資産詐欺に関するSEC投資家アラートは、詐欺師がクリプトの人気を利用して被害者を詐欺へ誘導すると警告しています。

クリプトのフィッシングは、緊急性、偽の報酬、偽のサポート、偽のエアドロップ、偽の復旧ページ、コピーされたウェブサイトデザインに依存することがよくあります。

ウェブサイトがプロフェッショナルに見えるからといって、署名が安全だと考えるべきではありません。

ユーザーは、ドメイン、コントラクトアドレス、ウォレットプロンプト、支出者アドレス、トークン金額、メッセージの目的を確認すべきです。

ウォレットに生の16進データまたは不明確なテキストが表示される場合は、特に注意してください。

署名フィッシングが成立するのは、ブロックチェーンが善意ではなく有効な署名を受け入れるためです。

署名とハードウェアウォレット

ハードウェアウォレットは、接続されたコンピュータまたはスマートフォンから秘密鍵を隔離したまま署名を作成するデバイスです。

これにより、マルウェアが秘密鍵を盗むリスクを低減できる可能性があります。

ハードウェアウォレットでも、ユーザーは署名するアクションを承認する必要があります。

ユーザーが悪意あるトランザクションを承認した場合、ハードウェアウォレットはその悪意あるアクションに対する有効な署名を作成する可能性があります。

このため、ハードウェアウォレットの画面、トランザクションプレビュー、明確な署名詳細が重要です。

ブラインド署名では、デバイス上で完全に読めないデータをユーザーが承認する可能性があるため、リスクがあります。

ハードウェアウォレットは鍵の保護を改善しますが、トランザクション内容の理解を保証するものではありません。

可能な限り、デバイス上で受取人アドレス、トークン承認、コントラクト呼び出し、金額を確認すべきです。

最も安全な署名とは、ユーザーがリクエストを理解した後に保護された鍵で作成される署名です。

署名とアカウント抽象化

アカウント抽象化は、ウォレットシステムにおける署名の仕組みを変えます。

すべてのアカウントが一つの標準的な秘密鍵署名形式に依存する代わりに、スマートアカウントはカスタム承認ルールを定義できます。

スマートアカウントは、パスキー、セッションキー、マルチシグルール、支出上限、ソーシャルリカバリー、時間制限、その他のプログラム可能な条件を使用できます。

適切に実装される場合、これはユーザー体験とセキュリティを改善できる可能性があります。

一方で、アプリケーションはコントラクトベースの署名ルールを理解しなければならないため、検証はより複雑になります。

ERC-1271および類似のアプローチは、アプリケーションがスマートコントラクトウォレットからの署名を検証するのに役立ちます。

スマートアカウントが一般化するにつれ、署名の意味は、一つの鍵が一つのアクションを承認することから、ウォレットポリシーがアクションを承認することへ広がる可能性があります。

プログラム可能なウォレットでも実際の資産移動を承認できるため、ユーザーはすべての承認済み操作を重大なものとして扱うべきです。

アカウント抽象化は署名を柔軟にしますが、自動的にリスクフリーにするものではありません。

署名とスマートコントラクトのセキュリティ

署名を受け入れるスマートコントラクトは、慎重に記述されなければなりません。

関連する場合、コントラクトは想定された署名者、署名済みアクション、金額、受取人、nonce、期限、チェーンID、検証コントラクトを確認すべきです。

これらのフィールドのいずれかが欠ける場合、署名が再利用されたり誤って解釈されたりする可能性があります。

コントラクトは期限切れの署名を拒否し、使用済みnonceを適切に記録すべきです。

アプリケーションで想定される場合、スマートコントラクトウォレットもサポートすべきです。

署名検証のバグにより、攻撃者が適切な承認なしに報酬を請求し、注文を実行し、支出を承認し、投票し、資金を出金できる可能性があります。

署名ベースのフローは、通常ユーザー、悪意あるユーザー、リプレイ試行、期限切れ、誤ったチェーン、誤ったコントラクト、誤った署名者でテストすべきです。

監査人は署名ロジックを高リスク領域としてレビューすべきです。

スマートコントラクトセキュリティでは、署名はしばしば暗号学的形式のアクセス制御です。

署名でよくある間違い

よくある間違いの一つは、メッセージへの署名が常に無害だと考えることです。

2つ目は、意味を理解せずに生データを承認することです。

3つ目は、ウォレット接続とウォレット署名を混同することです。

4つ目は、支出者に気付かずに署名済みpermitを通じてトークン支出権限を付与することです。

5つ目は、ウェブサイトが見慣れたロゴを使用しているため、署名プロンプトを信頼することです。

6つ目は、nonceまたは期限のない署名済みメッセージを構築することです。

7つ目は、署名ペイロードにチェーンIDとコントラクトアドレスを含めないことです。

8つ目は、スマートコントラクトウォレットの署名をサポートしないことです。

9つ目は、監査済みライブラリではなくカスタム署名コードを使うことです。

10個目は、有効な署名が署名者の意図やすべてのリスクの理解を証明すると考えることです。

署名のメリット

1つ目のメリットは、秘密鍵を公開せずに安全なトランザクション承認を行えることです。

2つ目は、ウォレット所有権の証明です。

3つ目は、署名済みデータに対する不正変更からの保護です。

4つ目は、セルフカストディの支援です。

5つ目は、スマートコントラクト、DeFi、NFT、ガバナンス、ステーキング、ウォレットログインとの互換性です。

6つ目は、特定のオフチェーンまたは遅延アクションに対するガスレス承認です。

7つ目は、マルチシグおよびしきい値型セキュリティ設計の支援です。

8つ目は、従来のパスワードデータベースなしでの分散型認証の改善です。

9つ目は、強力なリプレイ保護で設計される場合のシステム間協調です。

10個目は、署名がデジタル所有権を暗号学により執行可能にすることです。

署名のリスクと限界

1つ目のリスクは、盗まれた秘密鍵が有効な署名を作成できることです。

2つ目は、だまされたユーザーが悪意あるトランザクションまたはメッセージに署名する可能性があることです。

3つ目は、署名データに十分な文脈がない場合のリプレイです。

4つ目は、読みにくいウォレットプロンプトです。

5つ目は、署名の可鍛性または不適切な検証ロジックです。

6つ目は、脆弱なウォレットソフトウェアまたは安全でない署名デバイスです。

7つ目は、偽サイトと偽のサポートアカウントによるフィッシングです。

8つ目は、署名がドメイン固有でない場合のクロスチェーン混乱です。

9つ目は、署名を受け入れるスマートコントラクトのバグです。

10個目は、有効な署名が承認を証明するものであり、安全性、公平性、収益性を証明するものではないことによる誤った安心感です。

ユーザー向けベストプラクティス

署名する前に、すべてのウォレットプロンプトを読んでください。

署名リクエストを承認する前に、ウェブサイトのドメインを確認してください。

署名がログイン、承認、送付、permit、注文、投票、または別の金融アクションを対象とするかを確認してください。

生の16進メッセージや不明確なプロンプトには注意してください。

トークンの支出者アドレスと承認金額を注意深く確認してください。

未知のリンク、偽のエアドロップ、偽のサポートアカウント、プライベートメッセージからの緊急リクエストへの署名は避けてください。

必要に応じて、大きな残高にはハードウェアウォレットまたはより強力なカストディ構成を使用してください。

実用的な場合は、高額資産の保管ウォレットと日常的に利用するウォレットを分けてください。

ウォレットの利用状況に照らして合理的な場合は、不要な承認を取り消してください。

署名は気軽なクリックではなく、承認であることを覚えておいてください。

開発者向けベストプラクティス

可能な限り、カスタム形式ではなく確立された署名標準を使用してください。

読みやすい構造化署名が適切な複雑なEthereum系承認には、EIP-712型付きデータを使用してください。

関連する場合、チェーンID、検証コントラクト、nonce、期限、署名者、受取人、金額、アクションタイプを含めてください。

期限切れ署名と使用済みnonceを拒否してください。

信頼できる暗号ライブラリを使用し、十分な専門知識なしにカスタム署名復元ロジックを書かないでください。

ユーザーがスマートコントラクトウォレットを通じてやり取りする可能性がある場合、ERC-1271をサポートしてください。

ウォレット、ネットワーク、ブラウザ、ライブラリ、エッジケースをまたいで署名をテストしてください。

専門家ではないユーザーにも理解できる明確なプロンプトを作成してください。

署名ベースの承認経路を慎重に監査してください。

署名を単なるユーザーインターフェース機能ではなく、アクセス制御の一部として扱ってください。

FAQ

クリプトにおける署名とは何ですか？

クリプトにおける署名とは、ウォレット、秘密鍵、または承認済みアカウントが、トランザクションやメッセージなどの特定のデータを承認したことを示すデジタル証明です。

クリプト署名は手書きの署名と同じですか？

いいえ。クリプト署名は秘密鍵で作成される数学的な承認であり、手書きの署名は法的または個人的な身元に結び付く物理的な印です。

署名で秘密鍵は公開されますか？

いいえ。適切なデジタル署名は、秘密鍵を公開せずに秘密鍵の管理を証明します。

署名によって暗号資産は移動しますか？

はい。トランザクション署名は暗号資産を移動でき、一部のメッセージ署名はトークン支出や注文執行などの後続アクションを承認できる場合があります。

トランザクション署名とメッセージ署名の違いは何ですか？

トランザクション署名はオンチェーントランザクションを承認します。一方、メッセージ署名はログイン、permit、投票、注文、その他のオフチェーンまたは遅延アクションに使用される可能性があるデータを承認します。

Bitcoinはどの署名アルゴリズムを使用しますか？

Bitcoinは歴史的にsecp256k1曲線によるECDSAを使用しており、Taproot関連の文脈ではSchnorr署名もサポートしています。

Solanaはどの署名アルゴリズムを使用しますか？

Solanaのトランザクション署名では、必要な署名者によるEd25519署名が使用されます。

有効な署名でも危険な場合がありますか？

はい。悪意ある承認、送付、permit、注文、ブリッジメッセージ、スマートコントラクトアクションを承認する場合、有効な署名でも危険となる可能性があります。

署名のリプレイとは何ですか？

署名のリプレイとは、有効な署名が、本来有効であるべきでない場所、時間、チェーン、コントラクト、アクションで再利用されることです。

署名時に安全性を高めるにはどうすればよいですか？

ウォレットプロンプトを読み、ドメインを確認し、支出者アドレスを確認し、曖昧なメッセージを避け、信頼できるウォレットを使い、理解できない署名を拒否することで安全性を高められます。

結論

クリプトにおける署名とは、秘密鍵、ウォレット、またはスマートアカウントルールが、特定のトランザクションまたはメッセージを承認するために作成するデジタル承認です。

署名により、ネットワークは秘密鍵を公開せずに誰がアクションを承認したかを検証できるため、署名はブロックチェーン所有権の基盤です。

署名は、トランザクション、メッセージログイン、トークンpermit、オフチェーン注文、ガバナンス投票、ブリッジメッセージ、マルチシグウォレット、スマートコントラクトウォレット、アカウント抽象化システムで使用されます。

ブロックチェーンごとに、ネットワークおよび文脈に応じてECDSA、Schnorr、Ed25519などの異なる署名方式が使用されます。

署名は鍵ベースの承認を証明しますが、署名者がアクションを理解したことや、コントラクトが安全であることを証明するものではありません。

署名済みデータは資産を移動し、権限を付与し、将来のアクションを承認する可能性があるため、ユーザーはすべての署名リクエストを重大な承認イベントとして扱うべきです。

開発者は、明確なペイロード、ドメイン分離、リプレイ保護、期限、nonce、成熟したライブラリ、読みやすいユーザープロンプトを用いて署名フローを設計すべきです。

初心者にとって、クリプト署名はウォレットによる暗号学的な承認として理解するのが適切です。

上級ユーザーにとって、署名は秘密鍵、公開鍵、ハッシュ、署名標準、スマートコントラクト、リプレイ保護、カストディセキュリティを結び付ける認証および完全性の仕組みです。

クリプト用語集の文脈では、署名とは、ブロックチェーンアクションを承認し、セルフカストディ、トランザクション、スマートコントラクトとのやり取り、分散型IDを可能にするデジタル証明を意味します。

重要なポイントは、署名が暗号資産の所有権を機能させる一方、安全な署名には安全な秘密鍵、明確なウォレットプロンプト、信頼できるインターフェース、強力な標準、承認前の慎重なユーザーレビューが依然として必要であることです。